[Bug 762207] flvmux: Ensure we use DTS when clipping running time

[GStreamer (GNOME Bugzilla)]

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

--- Comment #26 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Sebastian Dröge (slomo) from comment #25)
> This actually does not seem to do the right thing in general, and we should
> probably defer this to the muxers as only they can know if doing this
> assumption is ok for their use case or not.
> 
> Problematic for example is if you have a stream that has B frames but only
> DTS. We would then generate a stream that has wrong PTS. And a stream with
> only DTS but no PTS is perfectly valid, a decoder/parser can make up
> sensible PTS for it.
> 
> The other problematic case is if there is a stream that sometimes does not
> have PTS (e.g. only for the very first buffer) but always DTS. We would make
> up PTS that might be completely off based on the actual PTS that are known.
> 
> 
> I think this should be reverted and replaced with either proper PTS/DTS
> conversion in h264parse, or muxer specific solutions if there's something a
> muxer can do about it.

I'm not fully convinced by the argument. First, CollectPad does not send
buffers to parsers or a decoders. For encoded data, it's an endpoint before
encapsulation of the timestamp information. If some of the timestamp
information is missing at this point, it means there is no parser or decoder
that where capable to figuring-out (Matroska demux as a source is a valid
case). You only have two choices left, make a guess or fail. The in-between is
what we had before, which results in worst case scenario (very broken mux).
>From my knowledge, this guess applies at least to FLV and QT. The only muxer I
really know it does not apply, is Matroska, which will use the DTS anyway (in
which case this guess has not side effect). For QT, this guess is already found
in the muxer itself. I don't mind if we go back to hacking FLV muxer, but I do
think it's unfortunate.

About the first timestamp hack, I still believe this hack should not have
existed. While its easy for sink, it's far from elegant to any other elements
that require timestamp information.

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