After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 679664 - [matroska demux] wrong time stamp given if divx/xvid encoded in mkv container
[matroska demux] wrong time stamp given if divx/xvid encoded in mkv container
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.29
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-07-10 07:03 UTC by bcxa.sz
Modified: 2012-10-17 15:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bcxa.sz 2012-07-10 07:03:54 UTC
I have one stream whose codec is xvid encoded, which have B picture inside.

I looked at the way of gstreamer native mkv demux to give time stamp:

buffer time = (cluster_time + time) * demux->time_scale;

So the gstreamer native mkv demux will not consider the display order of
frames. 

So in I P B B case (decoding order):
the P timestamp can be 2 second, and B time stamp can be 3 second, even though
the B should be displayed before the P.

And if downstream element think coming buffer time stamp is display time information, then it will be wrong.

So here the 1st question: whether the buffer time stamp from demux element is decoding time stamp or presentation time stamp?

I backed to ffmpeg to see how ffmpeg handle the divx in mkv container: I saw it will detect the frame type and only take B frame's decoding time (the same way as gstreamer native mkv demux caculate from cluster time and block time) as presentation time. For P and I frame, invalid time stamp is given.

Here the 2nd question: whether gstreamer native mkv demux should adopt the same strategy as ffmpeg? detect frame type and give correct PTS as buffer time stamp?
Comment 1 bcxa.sz 2012-07-10 08:06:19 UTC
I forget to say, use gstreamer  native demux has av jerky issue (due to the wrong timing information I think) and use ffmpeg mkv demux the audio and video are fine with good av sync.
Comment 2 Edward Hervey 2012-07-10 08:56:37 UTC
Works fine with http://samples.mplayerhq.hu/Matroska/matrix/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv

Timestamps outputted from demuxer are increasing, decoder detects that and fixes outgoing timestamps.

Please check again with a more recent gst-plugins-good (0.10.31 or better yet git of everything).
Comment 3 Tim-Philipp Müller 2012-10-17 15:25:09 UTC
I think it should be okay in general. I remember some issues a while back, but those should've been fixed for quite some time now. In 1.0 we can signal DTS and PTS separately if needed anyway.

If you have a specific file that doesn't work properly, please make it available for us.