After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738198 - multiqueue: Does not wake up not-linked streams on EOS
multiqueue: Does not wake up not-linked streams on EOS
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 1.4.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-10-09 05:36 UTC by Andrei Sarakeev
Modified: 2014-10-24 19:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch (1.83 KB, patch)
2014-10-09 05:36 UTC, Andrei Sarakeev
reviewed Details | Review
graph (466.83 KB, image/png)
2014-10-09 08:57 UTC, Andrei Sarakeev
patch (812 bytes, patch)
2014-10-16 06:20 UTC, Andrei Sarakeev
committed Details | Review

Description Andrei Sarakeev 2014-10-09 05:36:59 UTC
Created attachment 288092 [details] [review]

GST_DEBUG=uridecodebin:5 gst-launch playbin uri=... flags=1

EOS from audio not handled => chain not drained.
Comment 1 Sebastian Dröge (slomo) 2014-10-09 08:19:53 UTC
Why is there no EOS event for the audio part of the decode chain though? Downstream should return not-linked here, which should cause it to continue sending buffers and then EOS in the end.

Seems like a bug in some other element to me.

Do you have a debug log you could attach or some further information?
Comment 2 Andrei Sarakeev 2014-10-09 08:45:05 UTC
GST_DEBUG=uridecodebin:5 gst-launch playbin uri=file:///home/andy/Videos/Havana_Lover.avi

Конвейер подготовлен (PREROLLED)…
Установка конвейера в состояние PLAYING…
New clock: GstPulseSinkClock
0:00:00.222932379 14957 gsturidecodebin.c:1114:decoded_pad_event_probe:<decodebin0:src_0> found bitrate 6778720
0:00:00.223237573 14957 gsturidecodebin.c:1069:configure_stream_buffering:<uridecodebin0> overall bitrate 6781820
0:00:09.982328529 14957  gsturidecodebin.c:1780:proxy_drained_signal:<uridecodebin0> drained signaled !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Получен маркер EOS («конец потока») от элемента «playbin0».
Execution ended after 0:00:10.010184526

disable audio with flags=1

GST_DEBUG=uridecodebin:5 gst-launch playbin uri=file:///home/andy/Videos/Havana_Lover.avi flags=1

Конвейер подготовлен (PREROLLED)…
Установка конвейера в состояние PLAYING…
New clock: GstSystemClock
0:00:00.180728769 15059 gsturidecodebin.c:1114:decoded_pad_event_probe:<decodebin0:src_0> found bitrate 6778720
0:00:00.180763336 15059 gsturidecodebin.c:1069:configure_stream_buffering:<uridecodebin0> overall bitrate 6781820
Получен маркер EOS («конец потока») от элемента «playbin0».
Execution ended after 0:00:09.979593098
Comment 3 Sebastian Dröge (slomo) 2014-10-09 08:52:48 UTC
Why exactly does this happen though? What is the flow-return of the disabled audio chains, and why don't they get an EOS?
Comment 4 Andrei Sarakeev 2014-10-09 08:57:46 UTC
Created attachment 288100 [details]
Comment 5 Andrei Sarakeev 2014-10-09 08:58:20 UTC
see GstTee/audiotee in attachment graph
Comment 6 Sebastian Dröge (slomo) 2014-10-09 09:03:20 UTC
Yeah, so you would get not-linked there... but nonetheless the audio chain should get an EOS event.
Comment 7 Andrei Sarakeev 2014-10-09 09:12:53 UTC
'setup_next_source' function does not work in '3636:drained_cb'
next group in paused state.
Comment 8 Andrei Sarakeev 2014-10-16 06:20:18 UTC
Created attachment 288636 [details] [review]

When the last linked stream ends, but remains non-linked stream, the hightime is not updated, and this non-linked stream will not wake up
Comment 9 Sebastian Dröge (slomo) 2014-10-20 10:34:53 UTC
commit ee93c807e1caa1701fb173f2e26da80913e6fd9d
Author: Andrei Sarakeev <>
Date:   Thu Oct 16 10:13:14 2014 +0400

    multiqueue: Wake up any waiting streams if the current one goes EOS
    Otherwise we might have unlinked streams waiting.
Comment 10 Sebastian Dröge (slomo) 2014-10-20 10:35:25 UTC
I've added locks around that code as required, otherwise merged as is. Thanks for the patch and debugging this!