Created attachment 349681 [details] [review]
adaptivedemux: Support period change in live playlist

Created attachment 349682 [details] [review]
dashdemux: Fix sync of updated manifest from previous one

_get_next_fragment_timestamp() returns relative timestamp to period start.
But gst_mpd_client_stream_seek() uses absolute MPD timeline.

Following MPD has 85sec update period and each period has 3min duration.
http://vm2.dashif.org/livesim/periods_20/testpic_2s/Manifest.mpd

Current adaptive/dash demux has two issues.
One is, period change is possible only static mpd. And when mpd is updated, period start does not considered. So, after updating mpd, abnormal segments are fetched. (e.g., go back to the first segment of period)

Created attachment 371899 [details] [review]
adaptivedemux: Support period change in live playlist

Rebase. The reported issue is still there

Review of attachment 371899 [details] [review]:

Can you put more details in the commit message explaining what those changes do (something like "it was previously doing ... whereas we need ... and therefore we do ...")

Created attachment 371926 [details] [review]
adaptivedemux: Support period change in live playlist

Regardless of LIVE or VOD, "a manifest has next period but 
currently EOSed" state is meaning that it's time to advance period.

Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.

Created attachment 371927 [details] [review]
dashdemux: Fix sync of updated manifest from previous one

Add some comment in code

Attachment 371926 [details] pushed as a8cb766 - adaptivedemux: Support period change in live playlist
Attachment 371927 [details] pushed as 9956f22 - dashdemux: Fix sync of updated manifest from previous one