[Bug 700491] [dashdemux] Handle cases where minimumUpdatePeriod sets the period length

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=700491
  GStreamer | gst-plugins-bad | git

--- Comment #8 from Greg Rutz <greg at gsr-tek.com> 2013-05-20 15:44:32 UTC ---
I don't think minimumUpdatePeriod has any real relationship with the duration
of the Period.  According to ISO 23009-1_2012, Section 5.4:

"If the attribute MPD at miniumUpdatePeriod is present updates to the MPD are
expected and restricted in a sense that at the location where the MPD is
available at a certain time, the MPD is also valid for the duration of the
value of the MPD at minimumUpdatePeriod attribute."

Basically, all this says is that the current MPD shall remain valid for entire
duration encompassed by minimumUpdatePeriod (from the time that the MPD was
retrieved).  In the case of our "live" dynamic MPDs, this means that the client
can continue to download segments according to the current template until the
client reads a new MPD and sees a change.

Since the Period has no duration (which would be the case in a "live" service),
the client just continues to download segments.  The MPD at minimumUpdatePeriod
could be 10 minutes.  If there is no real change to the structure of the MPD at
that time, the MPD at availabilityStartTime and the new
SegmentTemplate at startNumber should align very closely with what the client is
already doing and the client just keeps on going.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.