GNOME Bugzilla – Bug 784338
fragmenteddemux: EOS sent by application is ignored
Last modified: 2017-07-03 19:33:00 UTC
Sending EOS doesn't close the streaming with souphttpsrc plugin. Reproducable on: - Ubuntu gst ver - 1.8.3 - Centos gst ver - 1.11.2 Steps to reproduce: 1. Run streaming from online source: gst-launch-1.0 -e souphttpsrc location="http://radioitaliasmi-lh.akamaihd.net/i/radioitaliasmi_1@329643/index_1_a-p.m3u8?sd=10&rebase=on" ! decodebin ! fakesink 2. Wait for stream to start; 3. Press Ctrl+C to send EOS; 4. Make sure that pipeline is "Waiting for EOS" stuck.
This is specific to fragmented stream like this one (HLS). The initial souphttpsrc is only used to download the initial playlist, but later hlsdemux will use it's own souphttpsrc to download the rest. As a side effect, the first souphttpsrc is already marked as EOS when this occured, hence the EOS being ignored. I'm not totally sure, but maybe we should set the GST_ELEMENT_FLAG_SOURCE on fragmenteddemux based elements. This way, the bin would forward the EOS to that bin, and then we can implement send_event() that will only care about EOS and drop the rest.
Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 723868 ***
Created attachment 354853 [details] [review] adaptivedemux: Allow application to force EOS Adaptive demuxers are special demuxers that runs their own sources internally. In this patch we flag the demuxer as being a source in order to receive the downstream events. We then handle the EOS event by resetting the internal state and pushing EOS on all pads.
Comment on attachment 354853 [details] [review] adaptivedemux: Allow application to force EOS Wrong bug.