GNOME Bugzilla – Bug 723868
adaptivedemux: Handle users _eos event
Last modified: 2018-11-03 13:21:04 UTC
Currently if the user sends an EOS to a pipeline with hlsdemux in it, it will basically be ignored, we should manage to detect when an EOS as been sent by the user itself, and properly handle it.
Can you elaborate on the use case? Sending EOS to the pipeline will be ignored because hlsdemux already received an EOS from upstream when the playlist file finished.
For example to produce valid files when transcoding into mp4 from an HLS stream you need EOS to be properly sent downstream before stopping the pipeline.
(In reply to comment #2) > For example to produce valid files when transcoding into mp4 from an HLS stream > you need EOS to be properly sent downstream before stopping the pipeline. I'm assuming you want it to finish on some user interaction as it should EOS properly once the stream ends. Right?
Not sure how to fix this. The source and upstream of hlsdemux is already EOS, sending an EOS event to the pipeline will send it to all sources. So hlsdemux never gets anything in this situation.
hlsdemux/adaptivedemux could flush-start/stop upstream after receiving the initial EOS. Then we'd just need to make basesrc push a forced EOS event through directly if the task is already pause for some reason (made a patch for that to try it, seems to work). Only problem is that there's no upstream flush-stop, so we can't flush-stop without upstream source's co-operation. Alternatively, maybe adaptivedemux could just do a flushing seek with start=stop=0 and FLAG_SEGMENT after receiving EOS (from a non-streaming thread of course), to fire up the basesrc thread again and make it do the flush-start/stop dance without sending anything else or going EOS thus keeping the path open for a second EOS.
*** Bug 769297 has been marked as a duplicate of this bug. ***
*** Bug 784338 has been marked as a duplicate of this bug. ***
As described in bug 784338, a third option is to set the SOURCE flag on the fragmenteddemux element and implement a handler for the EOS.
Created attachment 354854 [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. https://bugzilla.gnome.org/show_bug.cgi?id=784338
Just a note, while this patch works, I just notice I forgot that send_event for EOS shall be asynchonous. I'll revisit later to find out how we can do that, right now it blocks the user thread for quite some time.
Review of attachment 354854 [details] [review]: ::: gst-libs/gst/adaptivedemux/gstadaptivedemux.c @@ +610,3 @@ + + GST_MANIFEST_LOCK (demux); + gst_adaptive_demux_reset (demux); This function sends EOS on all pads already, so the later chaining to bin default implementation is redundant. Though, the EOS has the wrong segnum. This also means that calling reset need to be queued somehow.
Created attachment 354855 [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. This handling is done asynchronously to avoid blocking user thread.
Attachment 354855 [details] pushed as 8a070cf - adaptivedemux: Allow application to force EOS
Comment on attachment 354855 [details] [review] adaptivedemux: Allow application to force EOS I've pushed this one slightly by accident, and validate showed that it's not ready yet. So it's now reverted, sorry for the noise. commit 2f8980d70d7e56463bcebe46f092648a8231bdbc Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Fri Jul 7 17:20:38 2017 -0400 Revert "adaptivedemux: Allow application to force EOS" This reverts commit 8a070cf9aff8a122b1a52597441bab61c0476ef9.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/132.