[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 #9 from Greg Rutz <greg at gsr-tek.com> 2013-05-20 15:57:35 UTC ---
(In reply to comment #8)
> 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.

I want to clarify this a little bit.  I don't mean to say that
availabilityStartTime is always a clock reference for the segments in this MPD.
 It simply indicates when the segments in the MPD shall be available for
download by the client.  However, section 5.4 does indicate:

"NOTE 3: The second condition above ensures that sufficient media is contained
in each Representation to present the Media Presentation up to Texp(i) for a
client that begins playing each Segment at the earliest possible time (its
availability start time)."

The text in Section 5.4 of ISO-23001-9_2012 clarifies the updating of MPDs in a
way that should allow clients to determine that an MPD update is "consistent"
with the previous MPD and that the client can continue to download segments of
increasing numbers, queuing them behind the last segment downloaded from the
previous MPD rules, and presenting them.

-- 
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.