[gstreamer-bugs] [Bug 587799] h264parse not chopping the correct timestamp

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #3 from Lin YANG <oxcsnicho at gmail.com> 2009-12-10 17:19:56 UTC ---
I agree with Mark. According to what I know, timing info is often absent from
raw h264 stream and the only thing we rely on is the frame rate and the picture
order count (POC). (There may even be samples where frame rate is not available
at all; but even in such cases some commercial parser, like Elecard stream eye,
can still get meaningful time stamp estimates. I don't know how they do it.)

As what I know, the current h264parse is not parsing timing info even if it
exists, given a raw h264 stream. I think there is still something the parser
can do, like when the frame rate is available and the POCs are provided.

My concern here is that the POC is not necessarily mono increasing; I don't
know how to reflect that in the current framework. That why I propose to
calculate estimated time stamp and write on the buffers. With this we can solve
the problem that some muxers like mpegtsmux relies critically on the time stamp
of the buffers to interleave A/V data correctly. But maybe forcing frame rate
suffices for this purpose in most cases. Need some experiments to see if this
works. Does the mentioned element that generates time stamp basing on frame
rate exist now? Or we need to write a new one?

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