[Bug 679443] [0.11] x264enc produces wrong timestamps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=679443
  GStreamer | gst-plugins-ugly | 0.11.x

--- Comment #7 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2013-05-19 16:41:18 UTC ---
It may very well (unfortunately) have introduced other problems/bug/drawbacks,
but "at least" it is consistent with what videoencoder was/is doing/expecting,
which was the intention here.  But feel free to revert (or have it reverted),
though afaics that will also not fix the original problem reported here
(including videoencoder behaviour/assumptions).

There are indeed problems wrt PTS/DTS timestamps, as in the referenced report
(and in a -devel post), such as negative timestamps but IMO also what to do in
case of a missing/unknown PTS and/or DTS, and all sorts of interpolation that
it entails (a major pain in e.g. baseparse and probably others).  In that
respect, we seem to have shifted some fantastic DTS/PTS guesswork coding in
e.g. qtmux to other places (to deal with missing DTS or PTS, e.g. baseparse,
videoencoder, -decoder).  Hopefully, it is at least a bit more reusable in
these latter places now.

In fact, fwiw, the (I feel) still messy PTS/DTS situation in 1.0 makes me a bit
worried about how reliable some ts is at any point (in pipeline).  Also, btw,
note that no longer assuming PTS == DTS is probably going to make things even
harder for some PTS/DTS guesstimating heuristics around.

Suffice to say, any particular spec/agreement probably works, if at least care
is taken so it all "Just Works" in videoencoder-/decoder and baseparse
(including guesstimating etc).

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