GNOME Bugzilla – Bug 768900
urisourcebin/dashdemux: Multi-period playback problem
Last modified: 2018-11-03 11:47:59 UTC
Playbin3 based dash playback has problem on multi-period case. I guess that current urisourcebin expects following sequence will happen [dashdemux found next period] -> [add new srcpad] -> [push eos to old srcpad] Is it correct understanding? The problem on current playbin3 based dash multi-period is that, a srcpad of dashdemux push eos before the dashdemux constructs new srcpad... So, urisourcebin pass it to downstream. What is correct approach for this? I think dashdemux may delay pushing EOS if next period exist. It can be reproduced using this commend, period change at around 4min. gst-play-1.0 http://dash.edgesuite.net/dash264/TestCases/5a/nomor/1.mpd
Created attachment 331644 [details] urisourcebin.log
Created attachment 331645 [details] [review] adaptivedemux-Delaying-eos-event-if-next-period-exis.patch
Please could anybody review this patch? we cannot play some multi-period DASH with playbin3...
I wrote a patch for this a while back, that still needs a little work. It's in bug 758257 and should fix this, and more.
(In reply to Jan Schmidt from comment #4) > I wrote a patch for this a while back, that still needs a little work. > > It's in bug 758257 and should fix this, and more. Thanks a lot :) I'll looking for your patch
Created attachment 342417 [details] [review] adaptivedemux: Do not return FLOW_EOS if next period exists Urisourcebin expects new pads before detecting EOS event when advancing periods (If not, eos event will be pushed to downstream elements). To ensure it, do not return FLOW_EOS immediately.
This seems to work fine in master without the patch. Can you confirm ?
It only sort-of works fine in current master. If the new pads preroll data fast enough on a connection it can work because urisourcebin connects new pads. On slower connections, the pipeline will randomly EOS. I'm not sure this patch is quite right though. It seems strange to propagate EOS all the way here just to unconditionally convert it back to FLOW_OK. Can you provide some debug log of GST_DEBUG=adaptivedemux*:6 encountering this situation?
Created attachment 343602 [details] LOG file
Created attachment 343603 [details] [review] [DO NOT MERGE] print log
(In reply to Jan Schmidt from comment #8) The problem is still there in master. And I think bug 758257 patches does not cover this condition yet, in my opinion. Also, following line might have similar condition, possibly. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/adaptivedemux/gstadaptivedemux.c#n3785 Mostly, segment download for audio finished before that of video. So, the audio stream pushes EOS.
For easy debugging, attachment 343603 [details] [review] was applied for extracting log.
Hello Jan Schmidt I'm keeping on testing HLS/DASH on top of bug 758257 patches. Anyway, both with/without bug 758257 patches cases, HLS bitrate switching also shows similar "early EOS" issue sometimes. https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/adaptivedemux/gstadaptivedemux.c#n3766
I can't seem to reproduce this anymore with the following stream. Can you confirm ? USE_PLAYBIN3=1 gst-play-1.0 http://dash.edgesuite.net/dash264/TestCases/5a/nomor/1.mpd
(In reply to Edward Hervey from comment #14) > I can't seem to reproduce this anymore with the following stream. Can you > confirm ? > > USE_PLAYBIN3=1 > gst-play-1.0 http://dash.edgesuite.net/dash264/TestCases/5a/nomor/1.mpd I can still reproduce it on master. USE_PLAYBIN3=1 gst-play-1.0 http://dash.edgesuite.net/dash264/TestCases/5a/nomor/1.mpd then, seek to around 3 min, and wait :) Note that, period will be changed around 4 min 10 sec.
-- 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-base/issues/277.