MPD Update Size

[haudiobe]

From Hulu discussed at the MPEG Meeting:

As per the discussion of our proposal m42527-v1-m42527.zip (Patch method for Media Presentation Description updates) on Tuesday’s MPEG DASH session, we are asked for provide more details in terms of the following aspects. Please check our clarifications as follows.

Q: Why do we have so large MPDs? A: The biggest reason is feature enablement:

1. Users should always have the ability to exercise their start over rights for an airing program in its entirety and long form events, movies and sports, can be upwards of 4-5 hours.
2. Rollover program to program must be seamless, the player cannot be re-initialized as this would cause a buffer and devices do not have the resource to maintain multiple players. A secondary reason for this is our use of segment timelines instead of segment indexing, even with repeat counts in the timeline, the timelines can grow quickly as period cuts occur and segment sizes vary

Q: Why do we refresh the MPD so frequently? A: The MPD is the source of truth for the stream, it must reflect all known segment data as it is made available. For our SegmentTimeline elements to reflect the latest state, each new segment must be added and the players must poll at the expected segment duration, 4-10 seconds.

Q: Does X-Link help? A: In general X-Link in a dynamic media presentation is very complicated, particularly persistence of resolved data across MPD reload. Our investigation showed it would require complex client logic to managa multiple additional timelines outside of the main MPD instead of directly replacing the in-manifest element. In the end we determined the complexity and overhead of this implementation could not be justified in comparison to the patching mechanism.

[haudiobe]

(Thomas) Write a document how small MPDs can be done. On the Segment Timeline, using the main client as documented in the IOP, and extend the segment address based local computation, you would only need to update the MPD once you get an MPD expiry pointing to new period. (Zacharia) check the problems with the main live operation as documented in the IOP

[technogeek00]

We reviewed the Main Live as written out in IOP and went back to our original discussion notes:

• The best description of what we use is a Simple/Main live hybrid, we use the update polling mechanism of Simple, but use $Time$ instead of $Number$ without client side extension
• We could take advantage of S@t + S@d to manually extend the timeline client side, this would reduce the polling to only expiration points signaled by emsg value 1 boxes or segment/network failure conditions where a manifest update must be done for safety, but would not change the overall resource cost of the update for the network or client
• Investigation shows that our client and network diversity is high enough such that there will always be a client requesting a full update, meaning we don't anticipate a reduction in server load by taking this approach
• The emsg events with value 2 and 3 are incompatible with our system as they assume a 1-1 correlation between segments and manifests. In reality the same segment can be used in varying forms of manifests, such that a Patch or Full MPD within the segment may be an inaccurate update for clients consuming the segment

We do believe the client based timeline extension from Main Live could be used in parallel with our patching approach to further reduce network polling, and we may very well explore this soon, but we do still believe our proposed patching approach addresses our primary concern of client and network resource consumption in ways that the Main Live implementation cannot.