+ /* filterRecordData wants to work on multiples of blocksize.
+ if it returns a negative result, it means that this many bytes should be skipped
+ *in front* of the buffer. Then, it will be called again. with the newer, shorter buffer.
+ if filterRecordData wants to skip more data then currently available, it must do that internally.
+ Skipped bytes will also not be output.
+
+ if it returns a positive result, that means that only these many bytes should be used
+ in the buffer.
+
+ In either case, current_span_remaining is given as a reference and can be modified. (Of course it
+ doesn't make sense to decrement it to a non-zero value unless you return 0 because that would just
+ skip some data). This is probably a very special application for fast-forward, where the current
+ span is to be cancelled after a complete iframe has been output.
+
+ we always call filterRecordData with our full buffer (otherwise we couldn't easily strip from the end)
+
+ we filter data only once, of course, but it might not get immediately written.
+ that's what m_filter_end is for - it points to the start of the unfiltered data.
+ */
+
+ int filter_res;
+
+ do
+ {
+ filter_res = filterRecordData(m_buffer + m_filter_end, m_buf_end - m_filter_end, current_span_remaining);
+
+ if (filter_res < 0)
+ {
+ eDebug("[eFilePushThread] filterRecordData re-syncs and skips %d bytes", -filter_res);
+ m_buf_start = m_filter_end + -filter_res; /* this will also drop unwritten data */
+ ASSERT(m_buf_start <= m_buf_end); /* otherwise filterRecordData skipped more data than available. */
+ continue; /* try again */
+ }
+
+ /* adjust end of buffer to strip dropped tail bytes */
+ m_buf_end = m_filter_end + filter_res;
+ /* mark data as filtered. */
+ m_filter_end = m_buf_end;
+ } while (0);
+
+ ASSERT(m_filter_end == m_buf_end);
+
+ if (m_buf_start == m_buf_end)
+ continue;
+
+ /* now write out data. it will be 'aligned' (according to filterRecordData).
+ absolutely forbidden is to return EINTR and consume a non-aligned number of bytes.
+ */