GNOME Bugzilla – Bug 471370
Critical warning when playing unsupported file type
Last modified: 2008-01-18 08:32:56 UTC
$ totem --g-fatal-warnings ~/Music/non-utf8-test/01\ -\ Gyllene\ Tider\ -\ Kung\ Av\ Sand.mp3 ** Message: don't know how to handle audio/mpeg, mpegversion=(int)1, layer=(int)[ 1, 3 ], rate=(int)[ 8000, 48000 ], channels=(int)[ 1, 2 ], parsed=(boolean)true ** CRITICAL **: gst_missing_decoder_message_new: assertion `gst_caps_is_fixed (decode_caps)' failed aborting... Let me know if the file would be useful. gstreamer-0.10.14-2.fc8 gstreamer-plugins-base-0.10.14-2.fc8 gstreamer-plugins-good-0.10.6-2.fc8 Not sure the backtrace is any useful: (gdb) bt
+ Trace 158714
Could you check if this patch fixes it: http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/gst/playback/gstdecodebin.c?r1=1.98&r2=1.99 If not, could you attach a GST_DEBUG=*:5 debug log?
Patch fixed it. But now it doesn't ask me to download codecs: $ ~/Projects/Cvs/totem/src/totem --g-fatal-warnings ~/Music/non-utf8-test/01\ -\ Gyllene\ Tider\ -\ Kung\ Av\ Sand.mp3 ** Message: Error: Internal data flow error. gstbasesrc.c(1816): gst_base_src_loop (): /play/source: streaming task paused, reason error (-5) I have mpegaudioparse showing up in my plugins. Do you need me to upload the file?
> But now it doesn't ask me to download codecs: > $ ~/Projects/Cvs/totem/src/totem --g-fatal-warnings ~/Music/non-utf8-test/01\ > -\ Gyllene\ Tider\ -\ Kung\ Av\ Sand.mp3 > ** Message: Error: Internal data flow error. > gstbasesrc.c(1816): gst_base_src_loop (): /play/source: > streaming task paused, reason error (-5) > > I have mpegaudioparse showing up in my plugins. Do you need me to upload the > file? File would be great. A GST_DEBUG=*:5 log of the error would be great too.
So, the problem is id3demux (in -good) and/or mp3parse (in -ugly). Basically, the problem does not occur with GStreamer CVS because of this fix which is only in CVS: http://webcvs.freedesktop.org/gstreamer/gst-plugins-good/gst/id3demux/gstid3demux.c?r1=1.29&r2=1.30 It's pretty much harmless and will 'fix' the problem, but I'm not convinced it's the right thing to do (apedemux would need a similar 'fix' too then). The real fix for the underlying problem should be this: http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/gst/mpegaudioparse/gstmpegaudioparse.c?r1=1.69&r2=1.70 http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/gst/mpegaudioparse/gstmpegaudioparse.h?r1=1.19&r2=1.20 (haven't checked if it applies against 0.10.6 or tested whether it fixes the problem by itself).
For some reason both Fedora and Ubuntu have picked up the patch from comment #1, resulting in bugs being reported all over the place because of the problem reported in comment #3 So far I'm aware of the following bugs reported because of this: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-ugly0.10/+bug/136264 https://bugzilla.redhat.com/show_bug.cgi?id=273561 http://bugzilla.livna.org/show_bug.cgi?id=1625 I've tried both fixes suggested in comment #4, the id3demux fix indeed fixes this. I had to backport the mpegaudioparse fix for 0.10.6, that one doesn't seem to help by itself and isn't needed when using the id3demux fix. IOW the id3demux fix by itself is sufficient to fix this, wether or not the mpegaudioparse fix is used doesn't make a difference.
$ rpm -qf /usr/lib64/gstreamer-0.10/libgstmpegaudioparse.so gstreamer-plugins-ugly-0.10.5-1.lvn6 I can't fix mpegaudioparse in Fedora, because gstreamer-plugins-ugly isn't in Fedora, it's in 3rd party repositories. I'll add the id3demux patch to Fedora.
> For some reason both Fedora and Ubuntu have picked up the patch from comment > #1, ... That patch is correct and it's needed to make automatic codec installation work right in some scenarios. It's unfortunate that this caused issues in other places. > I've tried both fixes suggested in comment #4, the id3demux fix indeed fixes > this. Be that as it may, it's not really the Right Thing to do. It's just a hack around the problem. Acceptable as a quick-fix though. A better quick-fix would be to set mpegaudioparse's rank to GST_RANK_NONE (which is what ubuntu did AFAIK). > I had to backport the mpegaudioparse fix for 0.10.6, that one doesn't > seem to help by itself I find that surprising. Maybe you could share the patch that you backported? Just to be sure: the mp3parse sink event function should return TRUE when it queues the newsegment event.
Created attachment 94812 [details] [review] Backported mpegaudio parse patch (In reply to comment #7) > > For some reason both Fedora and Ubuntu have picked up the patch from comment > > #1, ... > > That patch is correct and it's needed to make automatic codec installation work > right in some scenarios. It's unfortunate that this caused issues in other > places. > > I'm not claiming the patch is incorrect, it would just be nice if downstream had waited with picking it up until the other issues were sorted out. > > I've tried both fixes suggested in comment #4, the id3demux fix indeed fixes > > this. > > Be that as it may, it's not really the Right Thing to do. It's just a hack > around the problem. Acceptable as a quick-fix though. A better quick-fix > would be to set mpegaudioparse's rank to GST_RANK_NONE (which is what ubuntu > did AFAIK). > That would result in it never getting automatically loaded, right? That sounds like an even cruder fix then the id3demux one. What kind of functionality loss would this cause? > > > I had to backport the mpegaudioparse fix for 0.10.6, that one doesn't > > seem to help by itself > > I find that surprising. Maybe you could share the patch that you backported? > Just to be sure: the mp3parse sink event function should return TRUE when it > queues the newsegment event. > Attached.
Your patch seems to fix the problem just fine for me (against gstmpegaudioparse.[ch] from the 0.10.6 release), although you'd probably also want http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/gst/mpegaudioparse/gstmpegaudioparse.c?r1=1.62&r2=1.63 to fix the warning about the template caps. Not sure why it doesn't work for you.
> > A better quick-fix would be to set mpegaudioparse's rank to GST_RANK_NONE > > (which is what ubuntu did AFAIK). > > That would result in it never getting automatically loaded, right? Correct, it would result in mp3parse not automatically being plugged into the pipeline by decodebin/playbin any longer. > That sounds like an even cruder fix than the id3demux one. What kind of > functionality loss would this cause? Nothing dramatic. Seeking and duration estimation for variable bitrate mp3s might be a bit less precise without mp3parse. It's not really needed, and hasn't been enabled in the previous releases either.
(In reply to comment #9) > Your patch seems to fix the problem just fine for me (against > gstmpegaudioparse.[ch] from the 0.10.6 release), although you'd probably also > want > > http://webcvs.freedesktop.org/gstreamer/gst-plugins-ugly/gst/mpegaudioparse/gstmpegaudioparse.c?r1=1.62&r2=1.63 > > to fix the warning about the template caps. Not sure why it doesn't work for > you. > Actually since this comment I've been contacted by a livna users which helped me reproduce the problem. So now livna does have my backported patch enabled, I just needed the right sound file to reproduce the problem and to confirm my patch fixes it. Thanks for the other patch fixing the warning!
Ah, great, let's close this then, thanks for confirming it works now.
*** Bug 502171 has been marked as a duplicate of this bug. ***
*** Bug 510267 has been marked as a duplicate of this bug. ***