GNOME Bugzilla – Bug 635461
Crash in mad decoder when changing number of audio output channels in Totem while media is running
Last modified: 2010-12-16 09:59:07 UTC
While changing the number of audio channels in Totem while media is in playing state, crash in mad decoder occurs. RFC patch upcoming...
Created attachment 174980 [details] [review] 0001-mad-Check-whether-output-buffer-is-NULL-in-case-of-c.patch This is RFC patch. Fixes the crash, but significant "blump" sound occurs when number of output channels is changed runtime. ;)
Do you have a sample file for reproducing this? The data should only ever be NULL at that point if the number of channels changed to 0 ;)
(In reply to comment #2) > Do you have a sample file for reproducing this? The data should only ever be > NULL at that point if the number of channels changed to 0 ;) It happens with almost all video files that are using mp3 audio stream.
Hm, do you have an URL to a publically available file that shows this behaviour?
http://plaes.org/files/2010-Q4/lola-run.avi
Doesn't crash for me with latest GIT and this pipeline: $ gst-launch-0.10 filesrc location=lola-run.avi ! avidemux ! mpegaudioparse ! mad ! fakesink
I can confirm that somewhere zero sized buffers are created but it doesn't crash for me. audioconvert complains about buffers of wrong size here when changing the totem audio output settings during playback
commit 3dae13383d00b4bc726b86be6e568a61ce03ab68 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Dec 16 10:30:31 2010 +0100 mad: If gst_pad_alloc_buffer() returns a buffer with the wrong size allocate Fixes bug #635461. This should fix the crash in mad, there's still a similar issue in basetransform.
commit 0a74684b41831591e7a71187b59e59a78d0860b9 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Dec 16 10:55:20 2010 +0100 basetransform: Handle downstream giving a buffer with new caps but invalid size This can happen for example when downstream proposed new caps, later proposed the previous caps again which in turn enables passthrough mode in upstream elements and the wrong-sized buffer appears in an element where the caps change never happened. Simply allocate a new buffer in this case. See bug #635461.