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

Fri Aug 29 08:32:45 PDT 2014

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

--- Comment #22 from sreerenj <bsreerenj at gmail.com> 2014-08-29 15:32:42 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > 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.
> 
> Do you know if there is an OSS code somewhere that implement this, or someone
> kind enough to document it? It's all a bit new to me. Would that mean we don't
> have to add latency ? Also, how do we know the pts-dts shift from that ?

In my understanding, If there are buffering_period and picture_timing SEI
messages in the stream, we can utilize the cpb_removal_delay and
dpb_output_delay values to find out the dts/pts. But many streams doesn't
include SEI . So we need to do some calculations. Find out the POC based on
h264 spec section 8.2.1 (this is bit lengthy) . Then some heuristics are
possible, for eg: 1/fps*poc  will give the pts with in an idr period.

We have POC calculation in gstreamer-vaapi:
https://gitorious.org/vaapi/gstreamer-vaapi/source/406aa37373e2b9917714eccd2834a45d18b61fd1:gst-libs/gst/vaapi/gstvaapidecoder_h264.c#L1914

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