GNOME Bugzilla – Bug 342962
[ffdec_h264] jerky playback of h264 in matroska and quicktime
Last modified: 2008-03-17 18:21:34 UTC
I have a file here (from a user on irc) - h.264 in matroska - which plays back with extreme jerkiness. mplayer manages fine. Filename is "Mai-HiME_01.DD\(H264.AAC\)\[KAA\]\[0DA03A69\].mkv.5MB.SAMPLE.mkv"; I don't have much upstream bandwidth here, so bug me for it during the day some time if you want a copy. I'd guess it's a timestamping issue in matroskademux, but that's unverified.
> I'd guess it's a timestamping issue in matroskademux, but that's unverified. Re-assigning to -good then ;)
Moving to gst-ffmpeg. The problem is in timestamping in gst-ffmpeg. In this case, it's just using the timestamps from the demuxer. However, the demuxer produces buffers out of order (which is correct and fine), and so gst-ffmpeg outputs out-of-order timestamps (NOT fine!), leading to frames being dropped. So, someone needs to rewrite timestamping in gst-ffmpeg. I also noticed that with filesrc ! matroskademux ! ffdec_h264 ! xvimagesink, there were lots of decoding errors. These went away with a queue between decoder and sink; suggests a refcounting error somewhere.
Mike, does it play correctly with latest gst-ffmpeg cvs ? If not can you put the file somewhere ?
No, doesn't seem any better with current cvs. mplayer is fine. See irc for the file.
I can confirm that this is still happening as of the most recent version. A mkv video file with h.264 video still plays noticeably slower with gstreamer than with mplayer or xine. Also, its extremely noticeable when comparing a 1080p quicktime h.264 file to a 480p matroska h.264 file.
This bug was added almost a year ago now, and the status is still "UNCONFIRMED". Is anyone working on this bug? It affects thousands of files in circulation today, and the problem is growing as Matroska is only getting more and more popular. Below is a link to a sample, if anyone needed that. http://81.225.6.251/stuff/mai-otome_zwei_01_sample.mkv
Playback with gstreamer-ffmpeg is poor. It is jerky and does not seek well in WMV files. Please, someone, put some time into fixing gstreamer-ffmpeg. It is vital that these plugins work decently for gstreamer to gain adoption.
> Playback with gstreamer-ffmpeg is poor. It is jerky and does not seek well in > WMV files. Please, someone, put some time into fixing gstreamer-ffmpeg. It is > vital that these plugins work decently for gstreamer to gain adoption. I am not sure what seeking in WMV files has to do with jerkiness when playing back H264-in-matroska. There's a separate bug open for the WMV seeking issue (filed for asfdemux in gst-plugins-ugly).
As of this commit, we have the same problem for H.264 in quicktime: revision 1.189 date: 2007-03-28 17:17:27 +0200; author: bilboed; state: Exp; lines: +30 -4 * gst/qtdemux/qtdemux.c: (gst_qtdemux_prepare_current_sample), (gst_qtdemux_chain), (qtdemux_parse_samples): * gst/qtdemux/qtdemux_dump.c: (qtdemux_dump_ctts): * gst/qtdemux/qtdemux_dump.h: * gst/qtdemux/qtdemux_fourcc.h: * gst/qtdemux/qtdemux_types.c: Process 'ctts' atoms, which are present in AVC ISO files (.mov files with h264 video). Use the offset present in 'ctts' to calculate the PTS for each packet and set the PTS on outgoing buffers. Fixes #423283 Changing summary to reflect this.
Created attachment 87393 [details] [review] First go at fixing the issue First go at fixing the issue. The trick is that for formats where we know the incoming buffers might be out-of-order, we store up to the two previous incoming buffer timestamps and durations. Then when we have a buffer to output, we take: * The smallest incoming timestamp * The earliest incoming duration I've tried this against several h264 in qt and h264 in mkv and seems to work fine, along with seeking.
2007-05-02 Edward Hervey <edward@fluendo.com> * ext/ffmpeg/gstffmpegdec.c: (gst_ffmpegdec_init), (gst_ffmpegdec_open), (gst_ffmpegdec_save_incoming_values), (gst_ffmpegdec_get_best_values), (gst_ffmpegdec_video_frame), (gst_ffmpegdec_sink_event): Fix timestamping for out-of-order incoming buffers. Instead of blindly copying the incoming buffer timestamps on the outgoing buffers we cache the latest 2 incoming buffer timestamps and duration and make a wise choice as to what the outgoing buffer timestamp and duration should be. Fixes #342962
is this really fixed for more than 2 consecutive bframes ? (doesnt seem so from the patch notes) The couple (highres) h264 movies I have still stutter regulary (though not continuously) while CPU-Utilization always stays below 50%. Its of course worlds better than before, but still far from mplayer or VLC smoothness.
There are other patches that fixed it more thoroughly in Bug #482660.