[Bug 763205] Fix the bug when live streaming a MPD consists of multiple periods

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=763205

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #323234|none                        |needs-work
             status|                            |

--- Comment #3 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
Review of attachment 323234:
 --> (https://bugzilla.gnome.org/review?bug=763205&attachment=323234)

Thanks for the patch, I guess this is the first time we see a live DASH stream
that has multiple periods. Care to say why is this used in the real world? Some
live streaming changing from one event transmission to another?

Anyway, some small changed needed as mentioned below. Check if you agree,
please.

::: gst-libs/gst/adaptivedemux/gstadaptivedemux.c
@@ +2869,3 @@
       /* we push the EOS after releasing the object lock */
       if (gst_adaptive_demux_is_live (demux)) {
+        if (gst_adaptive_demux_combine_flows (demux) == GST_FLOW_EOS &&
gst_adaptive_demux_has_next_period (demux)) {

I think if it has_next_period() then it makes no sense to wait for a manifest
update. So the && should be simplified here.

If there is already a next period the current one should already have all its
segment listed. In this case, the task should be stopped anyway. If the flow
combiner returns EOS then it can already advance to the next period, otherwise
it should just exit and the other pad that is still downloading segments for
this period will move to the next period.

It ends up being pretty similar to what happens when non-live streams have to
change periods.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.