GNOME Bugzilla – Bug 576180
[playbin2] Uses unref'd audiosink volume if using gconfaudiosink & audio sink supports volume
Last modified: 2009-03-24 09:43:41 UTC
Hi, playbin2 currently uses an unref'd volume element in the following scenario: a) playbin2 is created, audio-sink is set to gconfaudiosink. gconfaudiosink uses pulsesink. b) Play some file with audio c) reuse playbin2 for some other files with audio => crash as playsink->audiochain->volume points to an invalid memory area. This is caused by gconfaudiosink creating a new audiosink everytime it goes to PAUSED (or something like that). The problem now is, that playsink sets audiochain->volume only when the chain is created, i.e. it will contain the pulsesink of first file that was played. The proposed fix would be in gstplaysink.c:1518. If create_chain is FALSE we should call some kind of update_audio_chain() function that updates the volume element. Similar issues might also exist for the text/video sinks but I didn't look at them. OTOH this proposed fix will only work if the volume element changes only when the sink is reconfigured. In theory it could change always, so maybe we should add some callback to the sinks that is called when it's a bin and the children are changing (is this signal emitted also if a children of a children of a bin changes?).
FYI there's no crash if the volume element is updated at that line 1518 but as explained above this is no complete fix.
Using the "element-added" signal of the bin won't work though as it can be called with the playsink lock held from gst_play_sink_reconfigure() when doing the state change.
commit 7cf4e3eb1537e9564ed4970e117b34380807d326 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue Mar 24 10:42:04 2009 +0100 playbin2: rescan audio sinks for volume/mute Rescan the audio sinks for the mute and volume properties. fixes #576180.