[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 #15 from Peter Maersk-Moller <pmaersk at gmail.com> 2014-08-29 07:28:05 UTC ---
(In reply to comment #14)
> (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

Did you forget to include the diagram?

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