[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 #14 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-08-28 23:17:11 UTC ---
(In reply to comment #12)
> Can someone explain why should the PTS be set based on DTS? I can't think of a 
> case where in DTS will be present for a frame but not PTS

If you have a raw h264 stream, it is expected to be store in decoding order, so
the easiest way to generate timestamp, is to set first DTS to 0, and then
increment with the desired frame duration (from framerate). This gives you a
stream with only DTS. By figure-out out the needed reordering, you should be
able to figure-out the PTS (and vis-versa). Luckily that direction will never
hit issues with negative timestamp. Here's an interesting diagram that may help
understanding. It show the presence of this pts-dts shift that exist, in order
to allow B frames to have pts == dts. For the other direction, me might endup
having to ship the PTS format, in order to prevent the DTS from being negative

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