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

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #20 from sreerenj <bsreerenj at gmail.com> 2014-08-29 14:34:39 UTC ---
(In reply to comment #19)
> 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 ?

It is possible to find out the POC value based on h264 specification which will
give you the exact display order for each frame (This is bit complicated if you
follow the spec as it is). Then find out the pts based on this POC.

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