GNOME Bugzilla – Bug 612773
gst-ffmpeg aborts in ff_find_unused_picture
Last modified: 2010-10-25 17:14:16 UTC
Created attachment 156046 [details] ffmpeg:5 messages from test run everything built from git current as of the time of this post, and with CFLAGS="-g" for toplevel projects, in addition to --with-ffmpeg-extra-configure="--disable-optimizations" for gst-ffmpeg log collected, and crash expressed by: gst-launch --gst-debug="ffmpeg:5" --gst-debug-no-color playbin2 uri=file:`pwd`/\[gg\]_CANAAN_-_02_\[9D948DC4\].mkv video-sink="navseek seek-offset=240 ! timeoverlay ! autovideosink" 2> 5.log && tail -n 1000 5.log > spew.log you seek once and wait at least 3 minutes for the abort, depending on the frame you seek from it can take a decent amount of time. you can also just let it play from the beginning for at least 6 minutes (it _will_ abort, it just has to run through a bunch of frames, you cant seek right to the abort) (file is easily located by name, and other videos in the series (aside from 01) exhibit the same problems in different places, ask if you need pointers, __tim on irc has it already) tried with and without this patch from upstream http://trac.perian.org/browser/trunk/Patches/ffmpeg-larger-internal-buffer.diff it makes aborts happen after a longer time, but they still occur backtrace for aborted thread:
+ Trace 220940
Thread 3 (Thread 0x7ffff02bb910 (LWP 5611))
Let's quote the sources here: /* We could return -1, but the codec would crash trying to draw into a * non-existing frame anyway. This is safer than waiting for a random crash. * Also the return of this is never useful, an encoder must only allocate * as much as allowed in the specification. This has no relationship to how * much libavcodec could allocate (and MAX_PICTURE_COUNT is always large * enough for such valid streams). * Plus, a decoder has to check stream validity and remove frames if too * many reference frames are around. Waiting for "OOM" is not correct at * all. Similarly, missing reference frames have to be replaced by * interpolated/MC frames, anything else is a bug in the codec ... */ If anything this is a bug in ffmpeg or in the file you're using. Could you file this bug against ffmpeg at https://roundup.ffmpeg.org ?
the bug does not present itself in ffplay, only in combination with gstreamer, I've had this discussion several times with people on both sides, I should have posted the bug first, but I didn't, the way gst staggers frame releases eventually ends up with it holding too many outstanding frames and aborting
i have a bit of a conundrum here now; i have some new material that aborts very fast and at the beginning of the file in the same manner, but it does NOT do it with HEAD at the time of this post, it still does it with the original file (Canaan), it should be easy to provide a sample of this new file; but it is not broken on HEAD, though they seem to touch the same bits (in the new file it aborts just before it hits a good 4 seconds of black frames)
alright, i played the now working file in some silly attempt to actually watch it, and it aborts later even with HEAD, same problem; gst isn't releasing frames and ffmpeg is aborting eventually in _unused_picture
its not a fix, and it'll eventually get hit again, but increasing the original value in the manner of ffmpeg-larger-internal-buffer.diff to 256 pushed it out this by chance is hitting a lot of video files i actually want to watch and its a bit of a problem :|
*** Bug 613848 has been marked as a duplicate of this bug. ***
*** Bug 613916 has been marked as a duplicate of this bug. ***
*** Bug 614227 has been marked as a duplicate of this bug. ***
this doesn't happen if i use ximagesink, though there are _long_ pauses in the video at the same places it would abort() before, perhaps xvimagesink and the other sinks are accepting too many frames, and it eventually gets ahead of ffmpegs free frames?
this bug seems slightly dependent on playback speed, more easily triggerable on slower machines, or machines that are just fast enough to play a given file; but not ones that play them without effort
NAK hmmhh, core 2 duo 3GHz here...
*** Bug 623305 has been marked as a duplicate of this bug. ***
If people want us to investigate further into this issue we'll need: * full GST_DEBUG=2,ffmpeg:5 log of failure * new backtrace * all of this using latest gst-ffmpeg pre-release (0.10.10.4) compiled with internal ffmpeg
just watched the entire file i started this bug regarding, and it didn't do it at all; i'll have to report back when i've watched all of the rest of them, if you expect it to be fixed from your message, do you know what patch may have done it?
just watched all of them, no aborts; though there was a LOT of judder after a pause that took a minute or two to work itself out (demuxer?) dunno if its proper to close this bug with the dupes or anything, if anyone knows better go ahead and do so, will reopen if it ever occurs again
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!