[Bug 740575] Fixing DTS in GStreamer

[GStreamer (GNOME Bugzilla)]

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

--- Comment #48 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Matej Knopp from comment #45)
> Hold on a second :)
> 
> In current code, every time you seek you'll get DTS that is before segment
> start (assuming stream with bframes of course). That's not new.

It's not that consistent, x264enc was actually shifting it back and fort
(causing a lot of backward jumps). Also, I'm not sure demuxers are very
consistent either. I think what you get right now is a bit "random".

> 
> No buffer should get dropped because DTS is before segment start. Code that
> drops such buffers should be fixed.

Well, if it was expected to be inside the segment, we could actually drop the
one that should be dropped instead of wasting time and catching up very slowly.
We could of course badger with a second check on the PTS (if present). So both
ways, there is ways to make it more robust.

> 
> Also, DTS running time of first X buffers must be negative, if PTS running
> time of first buffer is 0. Whatever element sync on DTS running time, it
> should be able to handle situation with negative running time.

Of course, this does not change. Remains that we need a way to get the negative
value of the DTS in running time, which is what we are trying to address. And
that means we need to make a choice if DTS should be inside or outside of the
segment. The current gst_segment_to_running_time() (and _full() variant)
currently requires the the passed TS to be inside of the segment. I don't know
if it was made this way for mathematical reason or simply for robustness.

(In reply to Matej Knopp from comment #47)
> In any case, if you do need DTS to be within the segment and use offset for
> this, maybe gst_segment_to_stream_time needs to be fixed to deal offset as
> well.

It's likely a bug yes. You said you are using stream time for some use case you
have. You could make a test case from it, using pad offset to demonstrate the
issue.

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