GNOME Bugzilla – Bug 302017
possible segfault
Last modified: 2005-05-01 10:15:38 UTC
gst-ffmpeg muxers send EOS in the _loop() function, using this piece of code: av_write_trailer (ffmpegmux->context); url_fclose (&ffmpegmux->context->pb); ffmpegmux->opened = FALSE; gst_element_set_eos (element); The url_fclose() will send EOS to the peer pads downstream (filesink, usually; see gstffmpegprotocol.c). The problem here is that this will emit EOS on filesink, to which applications may respond (some applications have attached EOS handlers to filesink instead of to the containing pipeline). This may be followed, in that same context, by a state change, which will re-trigger the url_fclose() in the _state_change() handler, causing a segfault. The simple solution is to set the opened flag to FALSE before calling url_fclose(): av_write_trailer (ffmpegmux->context); ffmpegmux->opened = FALSE; url_fclose (&ffmpegmux->context->pb); gst_element_set_eos (element); that makes it all work as expected. The same change is needed in _state_change() as well, although I don't think that can lead to a segfault.
done.