GNOME Bugzilla – Bug 482660
h264 playback is not smooth
Last modified: 2015-07-13 10:55:06 UTC
Please describe the problem: When playing h264 encoded video, playback is not as smooth as it should be (or as it is when using mplayer or vlc or other players). People on IRC were talking about out-of-order buffers and timestamps that are causing this problem. Please fix this. Steps to reproduce: 1. Play any h264 encoded file. Apparently the used container-format is not important. Actual results: The file plays but it's jerky, sluggish, not smooth or whatever you want to call it. Expected results: I would expect the file to play as smooth as it does in other players like mplayer. Does this happen every time? Happens with every h264 encoded file using latest cvs. Other information: I uploaded a sample file here: http://wolpzone.de/dir/vortex/test_h264.mkv
It plays quite good for me with latest CVS version, while it is affected by the problems you describe in the 0.10.2 release version. In particular the fix for bug 342962 seems to work wonders, in my opinion. Are you sure you are actually using a CVS snapshot of gst-ffmpeg? I created a live ebuild for myself to use in Gentoo and H.264 encoded movies and your sample file are perfectly playable now with gst-launch playbin and totem. Related to that, why haven't we seen a new release of gst-ffmpeg for a year now?
Even with CVS playback is not exactly smooth.
It seems the parser is fixed in newer ffmpeg. When we update the snapshot we should take a look again at using the parser for h264 instead of using our workaround.
I was wondering if there is any news on this bug? Currently Ubuntu 7.10 is affected by this bug as well - https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10-ffmpeg/+bug/121279 - and I fear that this bug will still be present in Ubuntu 8.04 if nothing is done. This is quite an annoying bug because it requires you to remove totem-gstreamer in favor of totem-xine, or use VLC media player, or anything else if you want to watch H.264 encoded video files. Or is it expected that this bug will be fixed within a few months?
> I was wondering if there is any news on this bug? Currently Ubuntu 7.10 is > affected by this bug as well (...) and I fear that this bug will still be > present in Ubuntu 8.04 if nothing is done. We expect this to get fixed with the next ffmpeg update, which is being worked on afaik.
I think this is fixed already with gst-ffmpeg 0.10.3, isn't it?
Is this a duplicate of bug 342962?
No it is not. This bug is neither a duplicate of 342962 nor has the problem been fixed. The "solution" to Bug 342962 apparently fixes playback of some files, but I was told on IRC that a final solution that gets rid of this problem is still in the works. If you want to see for yourself, just download the sample file attached to this bug report. It plays with some ugly jerkyness even with latest CVS (try comparing it to how it plays in mplayer for example).
Created attachment 103136 [details] [review] patch to fix the problem This patch copies the input timestamp to the picture object so that ffmpeg can correctly keep track of it. This fixes all of my problems.
* ext/ffmpeg/gstffmpegdec.c: (gst_ffmpegdec_init), (gst_ffmpegdec_open), (gst_ffmpegdec_get_buffer), (gst_ffmpegdec_release_buffer), (gst_ffmpegdec_video_frame), (gst_ffmpegdec_sink_event), (gst_ffmpegdec_chain): Rewrite timestamping code to let ffmpeg track timestamps. Fixes #482660, #337866.
*** Bug 494056 has been marked as a duplicate of this bug. ***
While this fix certainly helped a lot, I still think that the problem hasn't been completely fixed. When I currently play back video's with the latest Totem and GStreamer in Ubuntu's 8.04 development branch, I can still clearly notice that video files encoded in H.264 are not playing completely smooth, when compared with playing them back in Media Player Classic on Windows XP, on the same computer. I have checked this with multiple video files over a longer period of time, and I'm very sure of what I see. Has anyone experienced the same? I have used the following method for comparing how fluent playback is. I downloaded an anime fansub (many anime series use still images which are then scrolled to save costs on animation, and IMHO the effect that playback is not smooth is most clearly seen when these still images are scrolled) - http://bt.mymenclave.com/torrents/%5BConclave-Mendoi%5D_Mobile_Suit_Gundam_00_-_19_%5B1280x720_H.264_AAC%5D%5BD5269143%5D.mkv.torrent - (a file of 344 MB, download with Bittorrent, sorry that I don't have a better example). I have both Ubuntu 8.04 with the latest updates and Windows XP as a multiboot on my PC. On Ubuntu I use Totem with GStreamer, on Windows I use Media Player Classic shipped inside the Community Codec Pack - http://www.cccp-project.net/ - and played back the file I just mentioned with both players. At 3:20 in the video file, you can a black background with a space ship moving slowly. If I watch this scene with Media Player Classic, the ship moves fluently. If I watch the scene with Totem, the ship movement seems to be stuttering, not fluent. This is just one example to illustrate the problem still is not completely eradicated, I have watched more video files and I constantly notice the difference between playing back with Totem and Media Player Classic. I'd really appreciate it if anyone could verify this.
@ #12 - are you using ALSA dmix? If so, you should possibly try (as a test) using the hardware device directly, or pulseaudio.
I'm kind of a newb in this area and am experiencing these playback issues also. I'm not sure I understand how that patch is supposed to be applied. Can someone explain?
there is still a problem left, since ffmpeg now uses the timestamps on the buffers as PTS values, formats like AVI (and maybe matroska?) that set DTS values as timestamps are not smooth anymore. I was going to implement some code in gst-ffmpeg to detect if the timestamps are DTS or PTS and then do some different algorithm for setting smooth timestamps. This would be the short-term solution until we manage to put DTS values somewhere on buffers.
(In reply to comment #13) > @ #12 - are you using ALSA dmix? If so, you should possibly try (as a test) > using the hardware device directly, or pulseaudio. > I don't know exactly what you mean, the backend used by GStreamer? After some googling I figured out I can change the backend which is used by GStreamer with gstreamer-properties, right? And how do I use the hardware device directly? When I opened gstreamer-properties, I saw that the "Default Output" was set to "Autodetect", "Default Input" to "ALSA". When I changed both output and input to "PulseAudio", closed gstreamer-properties and tried to play the video file again, it didn't make any difference. But I don't get it, ALSA provides device drivers for sound cards, and PulseAudio is a sound server, how are they related to a problem with unsmooth video?
The feedback of 'samples played' from the audio device is used to generate the clock that schedules video frames onto the screen. ALSA dmix is known to provide really jittery feedback, which results in jittery frame display, which is most visible during large, slow movement as you described.
This was not yet fixed. Keeping it open because matroska seems to be using DTS as the timestamps.
don't see any obvious problems anymore with latest patch in CVS other than the jitter caused by bad audio API implementations: * ext/ffmpeg/gstffmpegdec.c: (gst_ffmpegdec_class_init), (gst_ffmpegdec_setcaps), (check_keyframe), (gst_ffmpegdec_video_frame), (gst_ffmpegdec_sink_event), (gst_ffmpegdec_set_property): Detect DTS or PTS as timestamps. This is done by tracking frame reordering on the output and making sure that timestamps don't go backwards. Fixes #482660.