Live channel and start over of programs
With a long catchup-buffer on a server it is possible not only to provide live content, but also programs from the timeline.
In particular, we have the following use cases
- live
- a program completely in the past
- an ongoing program which has not yet ended
For the live case, a dynamic manifest with a sliding window is used. The manifest can either use SegmentTemplate with
For the second case, a program in the past, all segments are available, and a static manifest corresponding to the segment interval can be provided and played.
The third case is more challenging. In this case, at the time a user starts to play the asset the full asset is not available so the manifest must be dynamic and describe the content from the startTime up to the live point. As time progress, the live point moves up to the stopTime at this time the manifest no longer grows, and the asset transitions into case two. This means that there are no more updates of the manifest.
To be able to test the scenarios in players, the DASH-IF live-source-simulator has been extended with the possibility to specify a startTime and stopTime in the manifest URL. The startTime should be in the past, but the stopTime could be either in the past or in the future. An issue here is that since the live point progresses one must always generate new absolute start and stopTimes to be able to test this behaviour. To remedy this problem, the “Location” element is used. If this element is provided in the manifest, the player should refetch the manifest from the URL specified in the “Location”, and then use the new URL for any future update.
We can thus introduce new relative startTime and stopTime values in the URL to the simulator, which it translates into absolute URLs and return in the Location element.
A few example URLs are:
https://livesim.dashif.org/livesim-dev/startrel_-60/stoprel_-20/timeoffset_0/testpic_2s/Manifest.mpd
https://livesim.dashif.org/livesim-dev/startrel_-20/stoprel_20/timeoffset_0/testpic_2s/Manifest.mpd
These URLs both point to 40s time slice of a live channel, but the first one is all in the past (-60s, -20s) relative now, while the second is still ongoing (-20s, 20).
The timeoffset_0 is a parameter introduced to keep the reference media time 1970-01-01 (it is not well tested for other values).
The URLs above return DASH MPDs using
The expected player behaviour is that the player should play these assets without problem.
The content in the past is essentially a VoD asset and should play as such with a full scrub bar of 40s (may be 42s or similar depending on when the relative manifest was fetched)
The ongoing program is more of a challenge. The MPD is dynamic, but with a specified mediaPresentationDuration and it will change into static once the stopTime has been passed.
Since the manifest is dynamic, one could expect the player to start to play from the live-point, but the desired behaviour is normally to start to play fromt the start-point so that there is not a different behaviour in the case 1. and 2. This is also what is done in the Shaka-player (triggered by the presence of mediaPresentationDuration), but not, at least yet, in dash.js. Another means to control this would be by an anchor in the MPD (not supported in Shaka-player).