[Bug 757961] baseparse: do not overwrite header buffer timestamps

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757961

--- Comment #17 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
The original bug:

1) flacparse receives a header buffer with dts=none, pts=none
2) baseparse has next-dts and next-pts variables that it gets from the incoming
buffers and tries to preserve them on the output. next-dts is initialized as
segment.start. As the first buffer has no dts, the next-dts is kept as
segment.start
3) the output from flacparse (the header buffer) has its dts set to
segment.start and is pushed

This was confusing collectpads interleaving (now fixed)

The patch was to ignore this re-timestamping done by baseparse on the hope that
header buffers would keep their timestamp=None from upstream.

But this introduced a regression because h264parse uses the header flag on
buffers that have timestamps (SPS/PPS/SEI) and the new behavior of skipping
retimestamping of header buffers breaks the whole stream timestamping.


I agree with Tim that we should revert this for 1.6 and keep only the
collectpads one that also fixes the issue with flacparse. For master I'm unsure
of what to do until now. I think the original behavior of having header buffers
with dts=segment.start or next-dts is better than the current one, considering
what it made h264parse do.

We should also revisit h264parse header flag usage to make sure it isn't
marking too much as headers.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.