[Bug 659489] h264parse: Calculate PTS from DTS (and vice-versa)

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Aug 29 07:21:53 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=659489
  GStreamer | gst-plugins-bad | git

--- Comment #19 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-08-29 14:21:47 UTC ---
That reminds me the last question I have about this, shall be fix the timestamp
if something is detected wrong ? Obviously if both timestamp are present, we
will keep them and avoid the extra latency required to do the derivation.
Here's the missing graphic:

https://software.intel.com/sites/default/files/pts-dts_shift_explain.gif

Basic rules for H264 is that for B-Frames, pts == dts. P frames (when in
decoded order) are moved after the following B-Frames. This create a gap at the
start, hence the required initial shift. We should detect if there is possible
presence of B-Frames or not, I think there some buffer depth value that can
tell use that. We also need to report our latency accordingly, as it won't be
negligible in live pipeline. Anyone knowns special details, trick for this ?

-- 
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