GNOME Bugzilla – Bug 580810
Stuttering and crash with some H.264 files
Last modified: 2010-08-06 12:44:16 UTC
I have a few Matroska files containing H.264 video and AAC audio which cause severe hiccups and finally an abort, with the following message: ERROR ffmpeg :0:: Internal error, picture buffer overflow Backtrace from the abort is:
+ Trace 214943
I have put the beginning of one such file (8MB) on my webserver at: http://www.tdb.fi/~tdb/GH13.mkv It's the beginning of Ghost Hound episode 13, as fansubbed by Shinsen-Subs. Please think before downloading, I only have 1Mbit upstream and I hope to not get it bogged. The crash can be obtained with: gst-launch-0.10 filesrc location=GH13.mkv ! matroskademux ! ffdec_h264 ! appsink sync=false The sync=false is optional, but makes it reach the crash point much faster (6 seconds vs. a minute).
This looks to be one of the following upstream FFMPEG bugs (all of which are reported as "fixed" in current SVN) https://roundup.ffmpeg.org/roundup/ffmpeg/issue334 https://roundup.ffmpeg.org/roundup/ffmpeg/issue335 https://roundup.ffmpeg.org/roundup/ffmpeg/issue336 https://roundup.ffmpeg.org/roundup/ffmpeg/issue337 Judging from comments in the bugs, the fix *might* be as simple as applying http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=960369c0a41c84ecd0130ce127fbe80a05b25da9 (or it may well depend on a bunch of stuff before that, or possibly gstreamer's copy of ffmpeg might be significantly out of sync, rendering it not applicable)
The patch does not apply as is; furthermore, it seems that it is already included in gst-ffmpeg's snapshot of ffmpeg, with some additional changes. I tried updating ffmpeg to the latest svn version, but that didn't change anything at all. When running with xvimagesink, I also get a bunch of these: ERROR ffmpeg :0:: number of reference frames exceeds max (probably corrupt input), discarding one I can't see any connection to either of the problems though.
QoS seems to make ffmpeg fail. diabling qos on the videosink makes this file play back perfectly. I'll see why it's happening.
matroskademux was sending segment updates that caused output timestamps to fall outside of the clipping region and this caused QoS to drop frames and mess up the ffmpeg state. commit 608a920771e698d5a43f8c4f800e57173a9165e8 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Jun 5 13:47:15 2009 +0200 ffmpegdec: don't do QoS on invalid timestamps When we convert the timestamp to running_time, don't try to do QoS on invalid times. Fixes #580810
I can still reproduce this bug using the 0.10.8 release of gst-ffmpeg, which includes the above fix. Can anyone else confirm? (or perhaps there is something wrong with my set-up?). gstreamer-0.10.24 gst-plugins-bad-0.10.14 gst-plugins-base-0.10.24 gst-plugins-good-0.10.16 gst-plugins-ugly-0.10.12 gst-plugins-ffmpeg-0.10.8 The original sample file still aborts for me (not always at the same point), along with the occasional stuttering, and disabling qos on the video sink doesn't seem to help.
I can confirm that it doesn't work with latest GIT although Wim's commit is there and our internal ffmpeg copy also has all changes that Tim referenced above. It's stuttering and aborting after some time with: 0:00:56.875466287 18243 0xcd2ae0 ERROR ffmpeg :0:: Internal error, picture buffer overflow Abgebrochen Backtrace:
+ Trace 217452
This works fine for me with current git, both in playbin/totem and with fakesink sync=false. Please re-open if you can still reproduce it.