[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

--- Comment #4 from John Chang <r97922153 at gmail.com> ---
Dear Thiago:

Thanks a lot for your suggestion.

I think one application may happen for live TV. In this case the content
provider will insert advertisements into some predefined time slots among the
main program.

Since the advertisements obviously differ from main program (maybe the main
program has several audio tracks (adaption sets) in different languages but the
advertisement is quite simple to have a single one), it is convenient to make
the advertisements be a series of periods which are independent from the main
program.

About your comment, from my previous trace, the download loop does download for
each period. Once a specific stream has reached the end of a period (completed
download for this period), in gst_adaptive_demux_stream_download_loop the
return value of gst_adaptive_demux_stream_update_fragment_info() will be
GST_FLOW_EOS.
So we enter the switch logic and case GST_FLOW_EOS. The check for the EOS of
gst_adaptive_demux_combine_flows will insure that we will go to the next period
only when all active streams have done the download for current period. At this
moment, if it is a live streaming and we have a next period, we advance to
enter it. Otherwise, we do wait for the manifest’s update (expect a new period
will appear later) or return EOS if the manifest finally out of date.

I think the flow within this patch seems to correspond to your suggestion. Am I
right?
Or if there is something I missed which could make the patch better, please
kindly leave your variable suggestions here; thank you~

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