[Bug 679466] [0.11] GStreamer doesn't support negative DTS
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Jul 6 00:41:04 PDT 2012
https://bugzilla.gnome.org/show_bug.cgi?id=679466
GStreamer | gstreamer (core) | 0.11.x
Tim-Philipp Müller <t.i.m> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
CC| |t.i.m at zen.co.uk
Ever Confirmed|0 |1
OS/Version|Mac OS |All
--- Comment #1 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-07-06 07:40:59 UTC ---
Some background:
<d>: If your PTS starts with 0, yes, your first (or more) DTS will be negative
<e>: d, it doesn't make anay sense whatsoever.
<e>: it'll only be negative if you already suppress the decoding latency
<d>: do what now?
<d>: you mean, what you get from x264?
<e>: x264 returning negative DTS
<d>: what do you mean by "decoding latency"?
<e>: because of reordered frames
<e>: IPBPP => 1 frame delay
<d>: yes, and that is why DTS is (PTS-1 frame) for non-B pictures
<d>: er,well, PTS - N frames
<e>: and for keyframes ?
<e>: it's never PTS == DTS ?
<d>: no. it's DTS = (PTS - 1)
<e>: not according to 99.9999% of the streams I've seen
<d>: are they reordering pictures?
<e>: let's put it another way. If they weren't reordering pictures, you'd
always have DTS == PTS. And if they were reordering pictures, you'd almost
never have PTS == DTS
<d>: if you reorder, PTS == DTS for B frames.
* e scratches head
<d>: say you have a standard coding sequence (in presentation order) IBBBP
<d>: reordered, it is IPBBB
<e>: right
<d>: in order for the BBB frames to go out on time, you have to start decoding
one frame early:
<d>: (I)PBBB
<d>: so I has a negative DTS, DTS(P) is the same as PTS(I)
<d>: and the B frames have DTS == PTS
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list