GNOME Bugzilla – Bug 704427
streamsynchronizer: Assumes that a different stream-id on one stream means a new stream-group (problem when switching streams)
Last modified: 2013-07-22 18:07:42 UTC
Created attachment 249453 [details] Pipeline used when this problem occurs I'm kind of guessing on the component here. I think this is a bug in either playsink or queue. Note: You need to be on the latest version of gst-plugins-good from git for qtdemux to expose both streams in the file I'm using as an example. First, notice how this pipeline runs reasonably fast when streaming: gst-git gst-launch-1.0 uridecodebin \ uri=https://github.com/WebKit/webkit/raw/master/LayoutTests/media/content/counting-subtitled.m4v name=d ! text/x-raw ! \ funnel name=f ! s.text_sink d. ! s.video_sink playsink name=s \ video-sink="fakesink" 'text-sink="fakesink dump=true"' d. ! \ text/x-raw ! f. Now download the file and play it locally and notice how it's so slow it seems to be locked up: wget https://github.com/WebKit/webkit/raw/master/LayoutTests/media/content/counting-subtitled.m4v gst-git gst-launch-1.0 uridecodebin \ uri=file://$PWD/counting-subtitled.m4v name=d ! text/x-raw ! \ funnel name=f ! s.text_sink d. ! s.video_sink playsink name=s \ video-sink="fakesink" 'text-sink="fakesink dump=true"' d. ! \ text/x-raw ! f. The output is generally something like this: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... 00000000 (0x7fdea001ddf0): 4f 6e 65 One New clock: GstSystemClock 00000000 (0x7fdea0018340): 54 77 6f Two # hang for a long time, sometimes print the next subtitle eventually Running it in gdb, I spend a bunch of time in `gst_queue_chain`, looping on `while (gst_queue_is_filled (queue))`. The confusing thing is that there's no reason for the queue to be full, since there's only one queue in the pipeline, and it's connected to a fakesink, which presumably can pull data pretty quickly. I also see similar problems with appsink, so I'm guessing this is some sort of timing issue with queue, but that seems unlikely since queue is such an important element. This problem doesn't occur if we use the default input-selector text-stream-combiner.
This works fine though: gst-git gst-launch-1.0 uridecodebin uri=file://$PWD/counting-subtitled.m4v name=d ! text/x-raw ! funnel name=f ! queue ! fakesink dump=true d. ! text/x-raw ! f.
The problem here is stream-synchronizer: 0:00:00.279953664 6537 0x7f98ac005de0 DEBUG streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_1> Stream 1 changed Because it gets the stream-start events of both text streams alternating, it thinks that the stream-group has changed... and waits for the video stream to finish to switch to the next stream group. Related to bug #704408
Do you know why this manifested itself as the queue being full, instead of as something in streamsynchronizer?
Streamsynchronizer blocks until all streams are finished, and then the upstream queues run full
Using the stream-id to differentiate between different stream groups is conceptionally wrong anyway. Either we should add some kind of "stream-group" field to the stream-start event, or just differentiate based on the sequence number (and make sure all elements properly handle sequence numbers).
commit eaf333248a1d8f206451a30624a0bdee7bc9aac0 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Jul 22 14:12:18 2013 +0200 inputselector: Don't push new stream-start events on stream change unless they all have group ids https://bugzilla.gnome.org/show_bug.cgi?id=704408 commit 2465895266b17d4a1c438d73f84e68d9252ec578 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Jul 22 13:15:09 2013 +0200 streamsynchronizer: Implement grouping of streams via the group-id https://bugzilla.gnome.org/show_bug.cgi?id=704427 https://bugzilla.gnome.org/show_bug.cgi?id=704408
Please reopen if it still doesn't work, I didn't test your specific use case but many others that are related.
It looks like it works now, thanks.