Various issues with multi-period live streams

[joeyparrish]

@perses added to #285 with a specific manifest that did not work. That manifest had three interesting features:

1. Used <Location> to track sessions across manifest updates (Support <Location> for MPD updates #298)
2. Used presentationTimeOffset for the first period (Fix presentationTimeOffset handling in v2 #297)
3. Added new Period during manifest updates to extend the timeline

Now that 1 & 2 are solved, I have found that 3 does not work.

Technical details: presentationTimeline.duration_ grows as the manifest is updated, but video.duration does not.

[ct1n]

Since commenting on #285 I've realized that what I said about there being a difference between PTO and the first segment timestamp is quite probably wrong: DASH-IF Interoperability Points (http://dashif.org/w/2015/04/DASH-IF-IOP-v3.0.pdf) states, in section 4.4.3.3:

In order to make the MPD joining friendly and to remove data that is available in the past,
any segments that have fallen out of the time shift buffer may no longer be announced in
the MPD. In this case, the Period start may be moved by changing one or both,
MPD@availabilityStartTime and Period@start. However, this requires that the
@startNumber, @presentationTimeOffset and S values need to be updated such
that the Segment Information according to section 4.3.2.2.6 is not modified over an MPD
update.

This means we should probably update our server to have the Period start and PTO to match the new first segment (e.g., instead of Period start PT0S, PTO 5000, first segment ts 10000 we should have Period start PT5S, PTO 10000, first segment ts 10000).

However, I'm not sure this has any effect on shaka (note that the effective timestamp, availabilityStartTime + periodStart + ts - PTO, is the same).

[joeyparrish]

The stream in question is not treated as live because even though the duration grows, it has a finite duration.

If streaming catches up to the current duration, we call endOfStream(), after which duration can no longer be extended.

[joeyparrish]

@perses, if the format of this manifest is not in a stable state, I will stop work and wait for you to fix it. May I ask what product is generating this content?

While you are working on your server, please test on the latest Shaka from the master branch. It supports multiple periods, presentationTimeOffset, and <Location>. To temporarily work around the endOfStream issue, edit shaka.media.StreamingEngine.prototype.update_ and change this:

  // Check if we've buffered to the end of the presentation.
  if (timeNeeded >= timeline.getDuration()) {

to this:

  // Check if we've buffered to the end of the presentation.
  if (timeNeeded >= timeline.getDuration() && 0) {

Once your server and manifest format are in a state you are happy with, please let us know and we will work to find a more permanent solution for this endOfStream issue.

[joeyparrish]

@perses, while you are making changes, you should add an AdaptationSet id. Without this, Shaka can't be certain that the AS from one manifest matches the other, and therefore can't merge the timelines correctly.

[joeyparrish]

Actually, on second look, Representation IDs are unique within the Period according to the spec. AdaptationSet IDs should not be required. We'll fix that.

[joeyparrish]

One more bug on our end: your presentation should not be considered to have a finite duration. We'll fix that as well.

[ct1n]

Thanks for looking into this!
Our server is called "AIS Streamer" and is used for server-side ad insertion by a lot of broadcasters.

We've tried the player with these 3 commits but it seems it's not working anymore. Before it was playing about one minute (including proper period switching) and stopping. Not it's not playing at all.

[ct1n]

In the end we've decided not to implement the recommendation from DASH-IF Interoperability Points according to which we should update period start and PTO when segments are removed from the beginning. It doesn't sound like it's mandatory and it causes problems in both Shaka (we previously thought it didn't but there are apparently issues), and other players. It also seems more logical to keep them at their initial value as this provides more information.

We've updated the server at http://31.14.160.192:8000/ah/manifest.mpd with a new version. The only real difference is that the availabilityStartTime has been fixed between updates (it used to drift by one or two seconds). Further updates to the way our manifests look will be minor, if any.

We're happy to say that with #315 we have uninterrupted, smooth playback, for many hours (as long as we have tested).

Thanks very much for your help!

[joeyparrish]

No problem. I'll ask that #315 close #310, then. Thanks for working with us on this.