GNOME Bugzilla – Bug 399264
pipeline fails to preroll with Vorbis/Theora clip
Last modified: 2009-03-31 11:09:16 UTC
The vorbis/theora clip "A New Computer" can be downloaded from http://www.polycrystal.org/lego/movies/A_New_Computer--small.ogg Using decodebin with a push/streaming source causes the following pipeline to often freeze during preroll: gst-launch-0.10 filesrc location=A_New_Computer--small.ogg ! queue ! decodebin name=decode decode. ! queue ! audioconvert ! autoaudiosink decode. ! queue ! ffmpegcolorspace ! videoscale ! autovideosink Note the queue element after the filesrc, if the source element to decodebin allows random access I have been unable to reproduce this freeze. Also, it does not happen with for example this vorbis/theora clip: http://www.polycrystal.org/lego/movies/A_New_Computer--med.ogg I am using Ubuntu Dapper. I first saw this problem with the default installed gstreamer libraries, but upgrading to gstreamer-0.10.11, gst-plugins-base-0.10.11 and gst-plugins-good-0.10.5 does not make a difference. I first saw it inside of an application I am working on, and probing on the pads showed that data buffers were being passed into the theoradec1 element but no buffers come out on its source pad. If this is the case also when using gst-launch I do not know. Note also that this appears to be time-dependent, as using GST_DEBUG="*:5" gst-launch-0.10 ... causes the file to play normally (although very slow). There is some amount of debugging output which causes it to sometimes play and sometimes not, so it is not deterministic, possibly a deadlock. I hope someone else is able to reproduce this.
Can't reproduce this, neither with the GStreamer versions on edgy nor with CVS HEAD, no matter what GST_DEBUG level I use or if I run it in valgrind or not. Running oggz-validate on the file, however, results in these warnings: 399264-A_New_Computer--med.ogg: Error: serialno 1539964527: granulepos 4123 on page with no completed packets, must be -1 serialno 1539964527: granulepos 5888 on page with no completed packets, must be -1 serialno 1539964527: granulepos 5889 on page with no completed packets, must be -1 .... etc. Could you find out what happens in theoradec1 that it never sends things out? (e.g. could be that it is queuing incoming frames because it hasn't gotten one with an granulepos yet, or it could be that is trying to push frames out, but then clipping/dropping them)
Btw, also note that it should be audioconvert ! audioresample ! autoaudiosink (this can cause hangs with gst-launch if your audiosink doesn't support the sample rate produced, e.g. when using dmix for example).
It should note that I am running this on an Intel Core Duo CPU, if this is a thread issue (race condition, deadlock, etc) it's possible it can't happen on a single core cpu. Also, what audio/video sink I use seems to not matter at all. Using fakesink for either produces the same result (although using fakesink for both does not, as it seems the pipeline then plays as fast as possible, and the freeze doesn't occur). Attached is the the debugging output with theoradec:5 and *:3. I'm sorry I can't give you everything at 5, when using that much debugging I can't reproduce the issue. The log ends where it freeze occurs. As you can see, packets are being queued in theoradec, but this happens in the case where the pipeline actually plays as well. It would seem that theora_dec_push_forward is called, but never with a buffer with timestamp. I'm guessing that this info is not enough if you are not able to reproduce the problem, what other information can I provide?
Created attachment 80901 [details] GST_DEBUG="theoradec:5,*:3"
Some more info. Attached is full backtrace at the point where it freezes. I've also provided the xml dump of the pipeline at the time of freeze. Furthermore, the full debug output for oggdemux, vorbisdec and theoradec. The last two lines in the oggdemux log are a result of my adding GstPad *peerpad = gst_pad_get_peer(GST_PAD_CAST (pad)); gchar *padname = gst_pad_get_name (peerpad); GstElement *e = gst_pad_get_parent_element(peerpad); GST_DEBUG ("pushing to pad %s.%s", gst_element_get_name (e), padname); gst_object_unref (e); g_free (padname); just before the innermost for-loop in gst_ogg_demux_activate_chain It indicates that the pipeline freezes while trying to push a buffer to the queue4 element, which is the queue before vorbisdec. This all does seem a lot like a deadlock, but I'm not familiar enough with gstreamer and/or debugging threaded applications to understand where. Perhaps it's possible to tell from the backtrace?
Created attachment 80953 [details] gdb backtrace
Created attachment 80954 [details] vorbisdec:5
Created attachment 80955 [details] oggdemux:5
Created attachment 80956 [details] pipeline at time of freeze
Does this still happen with newer versions? quite a lot has changed since januari this year.
Yes, I can still reproduce this 10 times of 10 with the same pipeline as given above. Since the bug report I have done a fresh reinstall of Ubuntu Gutsy (originally Dapper), but I am still using the same computer (ThinkPad X60s with Intel Core Duo CPU, which may be relevant). Versions currently installed (default packages, not any custom built stuff): gstreamer0.10-alsa 0.10.14-1ubuntu3 gstreamer0.10-doc 0.10.14-1ubuntu3 gstreamer0.10-esd 0.10.6-0ubuntu4 gstreamer0.10-ffmpeg 0.10.2-2ubuntu1 gstreamer0.10-fluendo-mp3 0.10.5.debian-1 gstreamer0.10-gnomevfs 0.10.14-1ubuntu3 gstreamer0.10-gnonlin 0.10.9-1 gstreamer0.10-plugins-bad 0.10.5-4ubuntu1 gstreamer0.10-plugins-bad-multiverse 0.10.5-1 gstreamer0.10-plugins-base 0.10.14-1ubuntu3 gstreamer0.10-plugins-base-apps 0.10.14-1ubuntu3 gstreamer0.10-plugins-good 0.10.6-0ubuntu4 gstreamer0.10-plugins-ugly 0.10.6-0ubuntu2 gstreamer0.10-tools 0.10.14-1ubuntu3 gstreamer0.10-x 0.10.14-1ubuntu3 libgstreamer-plugins-base0.10-0 0.10.14-1ubuntu3 libgstreamer-plugins-base0.10-dev 0.10.14-1ubuntu3 libgstreamer0.10-0 0.10.14-1ubuntu3 libgstreamer0.10-dev 0.10.14-1ubuntu3
6 months later the freeze still happens 10 times out of 10, now with Ubuntu Hardy and GStreamer 0.10.18 gstreamer0.10-alsa 0.10.18-3 gstreamer0.10-esd 0.10.7-3ubuntu0.1 gstreamer0.10-ffmpeg 0.10.3-6 gstreamer0.10-fluendo-mp3 0.10.7.debian-1 gstreamer0.10-gnomevfs 0.10.18-3 gstreamer0.10-plugins-bad 0.10.6-5 gstreamer0.10-plugins-bad-multiverse 0.10.6-1 gstreamer0.10-plugins-base 0.10.18-3 gstreamer0.10-plugins-base-apps 0.10.18-3 gstreamer0.10-plugins-good 0.10.7-3ubuntu0.1 gstreamer0.10-plugins-ugly 0.10.7-3 gstreamer0.10-plugins-ugly-multiverse 0.10.7-1 gstreamer0.10-pulseaudio 0.9.7-2 gstreamer0.10-schroedinger 1.0.1-2 gstreamer0.10-tools 0.10.18-4ubuntu1 gstreamer0.10-x 0.10.18-3 libgstreamer-plugins-base0.10-0 0.10.18-3 libgstreamer-plugins-base0.10-dev 0.10.18-3 libgstreamer0.10-0 0.10.18-4ubuntu1 libgstreamer0.10-dev 0.10.18-4ubuntu1 I'm not sure what can be done given that I'm the only one who can reproduce it.
I just found this bug browsing through the bugs list. I can reproduce the issue just fine. The bug is related to the way decodebin handles it's internal buffers. It tries to grow the buffers to ensure that the amount of buffering is kept as small as possible, but large enough to cope with the muxing offset in the input. In this case, it's failing badly, due to a big FIXME in the queue_underrun_cb function in decodebin.c - the pipeline has underruns on the theora path, but it doesn't trigger the expansion of the vorbis path buffering because it proved to be too difficult to figure out or something. The bug is gone with decodebin2, which uses an internal multiqueue element to manage the buffering. This pipeline works fine, by artificially adding buffering to the vorbis chain gst-launch-0.10 filesrc location=A_New_Computer--small.ogg ! queue ! decodebin name=decode decode. ! queue max-size-time=2000000000 ! audioconvert ! audioresample ! autoaudiosink decode. ! queue ! ffmpegcolorspace ! videoscale ! autovideosink Is using decodebin2 a sufficient fix for you?
Thanks for taking the time to look at this. Judging by http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-decodebin2.html decodebin2 has been in plugins-base since 0.10.16 (2008-01-28). We want to support older versions of GStreamer, but I suppose we can fall back to the old decodebin. The only thing that is a bit worrying is the UNSTABLE classification of the decodebin2 API, are incompatible changes still likely to be made at this point?
The unstable warning has been in the decodebin2 API docs ever since it was introduced, but in fact the API hasn't changed. At this point, I don't think it will, and I've be meaning to discuss with the rest of the team removing the warning from the 0.10.23 release. I think it's unlikely anyone will be fixing decodebin(1) at this stage.
OK, thanks for the information, I'm OK with closing this as WONTFIX if decodebin2 is positioned to be the "official" replacement of decodebin.
Yep, it is. Also, for the record I suspect the reason Tim couldn't reproduce the issue in comment #1 is because he grabbed the wrong file: 399264-A_New_Computer--med.ogg (which works, as comment #0 says) vs http://www.polycrystal.org/lego/movies/A_New_Computer--small.ogg which does not.