GNOME Bugzilla – Bug 650516
matroskademux: Pulling data in chunks from upstream delays manual EOS for low-bitrate streams
Last modified: 2018-11-03 14:43:54 UTC
Hi, I tried to run the following pipeline: GST_DEBUG=GST_EVENT*:4 gst-launch -e filesrc location="some file" ! decodebin2 ! xvimagesink sync=true After I pressed the ctrl+c, nothing happend, just the following appeard on the console: Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline 0:00:04.141928579 4293 0x2085080 DEBUG GST_EVENT gstevent.c:269:gst_event_new: creating new event 0x223aa40 eos 86 Waiting for EOS... After ~30 sec waiting the EOS arrived but i think this is not the way it should work... With sync=false it's working but why not with sync=true? Maybe I can attach a sample file that produces the bug.
This would happen if 30 seconds of data are queued somewhere. Does this happen with all files or only with files a specific type? If it happens only for specific files, please attach one of them. Also, could you get a debug log with GST_DEBUG=5 and attach it here?
Created attachment 188096 [details] sample input file
GST_DEBUG=5 debug log: http://dl.dropbox.com/u/21047548/test.debug5
I can't reproduce this here with the latest releases. Could you retry with the latest releases?
Still doing for me with the latest release and the attached sample file. Fresh debug log is here: http://dl.dropbox.com/u/21047548/test.debug5 Check the times: 0:00:08.277007557 ESC[331m 6066ESC[00m 0x1c8e080 ESC[36mDEBUG ESC[00m ESC[00;01;37;41m GST_ELEMENT_PADS gstelement.c:1633:gst_element_send_event:ESC[00m send eos event on element filesrc0 0:00:30.267172349 ESC[331m 6066ESC[00m 0x1ee4010 ESC[36mDEBUG ESC[00m ESC[00m matroskademux matroska-demux.c:2184:gst_matroska_demux_send_event:<matroskademux0>ESC[00m Sending event of type eos to all source pads 0:00:36.264631187 ESC[331m 6066ESC[00m 0x7f717800a220 ESC[36mDEBUG ESC[00m ESC[00;01m bin gstbin.c:945:bin_replace_message:<pipeline0>ESC[00m got new message 0x7f7170003470, eos from xvimagesink0
The problem seems to be that the queues take about 25 seconds of data in your case and the EOS event is a synchronized event, that is handled after all data that was previously pushed downstream was handled. Could you make this file available?
I already attached the sample file in comment #2. Maybe you need something else?
Actually you already did... Ok, I see the problem here. multiqueue inside decodebin2 has about 5 seconds of data queued and matroskademux always pulls data in blocks of 64 kbytes, and as such has 64 kbytes of data queued. This isn't that much usually but for very low bitrate streams like yours, which seems to have about 500 bytes for 5 seconds on average, this is essentially the complete file. And the EOS is only forwarded after matroskademux' buffer is empty and filesrc is used again to get more data.
Maybe some workaround tips for an application? Sending flush start after eos or set the sink to sync=false could help?
What's the big picture here? What are you trying to achieve?
I have a big server side pipeline for streaming some media to client, and before I set this pipeline to null I send an EOS to the filesink. After this I wait for the eos on the sinks then call the set state function. It would be great if the pipeline destroy doesn't take 30 secs long.
(It's been a while...) For queue I added a this property a while back: flush-on-eos : Discard all data in the queue when an EOS event is received Maybe the same for multiqueue would help here?
Maybe not if most data is queued inside matroskademux.
Still happens, even with decodebin3.
-- 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-good/issues/43.