low-latency-playback-over-gap

[yanj-github]

low-latency-playback-over-gap required observation from spec is: 1) Every sample contained in CMAF Chunks CC[k,1,1] to (CC[k,1,exceed] +/- stall_tolerance_margin), and every sample contained in CMAF Chunks CC[k,1,omit_end+1] to end of presentation, in increasing presentation time order. 2) The playback duration shall match the duration of the CMAF Track, i.e., TR[k,S] = TR[k,1] + td[k] taking into account: ○ Missing starting and ending frames. ○ Potential start frames being rendered before playback. ○ Frozen last frame after the playback ended. ○ The duration of the gap, only for "vod" mode. ○ The stall tolerance margin stall_tolerance_margin.

The spec required to be reviewed for both "vod" and "live" mode as this is unclear. When "vod" mode I GUESS that it should have a gap in playback and the observation wording should be similar to Random access from one place in a stream to a different place in the same stream. Recorded test in plugfest is in "live" mode. It is not clearly stated from the spec that what observation should be made in this mode. What I observed from recording is that the playback started from beginning and it stopped at frame 120, then it jumped to frame 251 and played till 368 then jumped back again to frame 251 then played till the end. The duration from frame 251 till 368 is repeated.

I would like to get help to define what is expected and update the spec wording accordingly.

[jpiesing]

I don't know who wrote this and what was meant by "vod". I don't know why the concept is even introduced and would propose to remove it.

If the content is shown from frame 1 to M and then from P to Q then IMHO the comparison should be between something like this;

(TR[M]-TR[2]) + (TR[Q]-TR[P+1]) and td[] - ( T[P] - T[M] ) - (T[2]-T[1]) - (T[P+1]-T[P])

There may be an off-by-one somewhere in that.

[jpiesing]

From the DPCTF spec ...

MSE implementations do not handle such gaps natively. Instead, playback will stall a few milliseconds before the gap. Note that the concrete point at which the playback will stall depends on the platform/browser implementation. To continue playback, players are required to manually jump over such gaps by seeking to the start of the next buffered range object. In addition, player Implementations need to consider the type of content. For VoD content, the seek can be triggered immediately. For live content, the player needs to maintain a consistent live edge. Consequently, the player shall wait for the duration of the gap before performing the seek.

This is true but, in practice, the WAVE tests are always effectively VoD as the complete content being played always exists. There's no reason why a WAVE test cannot always seek past the gap, it's not like there's any risk of a 404. I think this is outside the scope of what WAVE tests.

● playback_mode: Defines the mode of playback which is either "live" or "vod". In vod mode the player immediately seeks over gaps while in live mode the waiting time before the seek is equal to the duration of the gap (to keep a consistent live edge).

We should consider removing this. Waiting before doing the seek is completely artificial in this context and doesn't test anything.

● Perform a seek to range.start(1) ○ playback_mode = vod: Seek immediately. ○ playback_mode = live: Set a timeout equal to gap_duration before seeking.

Consider deleting the reference to playback_mode and the 2 sub-bullet-points.

2) The playback duration shall match the duration of the CMAF Track, i.e., TR[k,S] = TR[k,1] + td[k] taking into account: ○ Missing frames. ○ Potential start frames being rendered before playback. ○ Frozen last frame after the playback ended. ○ The duration of the gap, only for "vod" mode. ○ The stall tolerance margin stall_tolerance_margin.

I think the above includes a number of timings which are implementation specific and would be hard to describe. I think the following would be a lot simpler.

2) The playback duration shall match the duration of the CMAF Track, i.e., TR[k,S] = TR[k,1] + td[k] taking into account: ○ Missing frames. ○ Potential frames being rendered before playback at the start of the content and at the resumption of playback after the gap. ○ Frozen frames at the end of the content and at the end of playback before the gap.

This last edit (only) is implemented in Draft-CTA-5003-Ae-v2.05. The other edits to remove references to "vod" mode are included only as comments.

[haudiobe]

I believe the VOD and live mode is different. What does it test:

1) in VOD you append data right away and advanced the timeline. 2) in live you wait until you append. only then you advance.

There may be issues in 1 and 2 that are different. In 1, you need to restart playback quickly. In 2, you need to make sure that the buffer is not frozen, disconnected, but is maintained until data is available again. I added some more text in the observation in v2.07.

[haudiobe]

● Load as many CMAF Chunks starting from CC[k,j,omit_end + 1] of the track such that the buffer duration reaches max_buffer_duration. ● Confirm that two ranges in the SourceBuffer exist with: ○ range.start(0) = 0 ○ range.end(0) = min(min_buffer_duration,df[k,i=1]) ○ range.start(1) = range.end(0) + gap_duration ○ range.end(1) = max_buffer_duration

We need to differentiate here on the difference between VOD and live. This emulates VOD. For live data is NOT available and buffer stays empty for some period if time (close to gap_duration). Check with @dsilhavy . It may be that the live test is already tested elsewhere.

[jpiesing]

My impression is that the live case here is very close to "Buffer Underrun and Recovery" but the VOD case is different.

• In the VOD case, the data after the gap can be appended even before the data before the gap has been played. Hence when the browser reaches the gap, there is already data after the gap.
• In the live case, the data after the gap cannot be appended before it would logically exist which means when the browser reaches the gap, there is no data after the gap. In fact the browser may not reach the gap because playback may stall before the last frame before the gap is output. This is not quite the same as "Buffer Underrun and Recovery" as that starts appending CMAF fragments without a gap but this has a gap.

My conclusion is that we need to preserve the VOD / live split - or duplicate this test into one VOD and one live.

For live, we need to change the spec text quoted by @haudiobe above so that this only happens after playback stalls.

[yanj-github]

Currently "VOD" mode test is missing. https://github.com/cta-wave/dpctf-tests/blob/master/test-config.json

I am happy with the duration check from spec r2.07:

_The playback duration shall match the duration of the CMAF Track, i.e., TR[k,S] = TR[k,1] + td[k] taking into account: ○ Missing frames. ○ Potential frames being rendered before playback at the start of the content and at the resumption of playback after the gap. ○ Frozen last frame at the end of the content and at the end of playback before the gap. ○ Skipped frames between exceed and omitend. ■ For VOD, the duration is shorted by the ommitted frames ■ For Live, the duration is identical to the track playback

For VOD, detected duration will be compared with track_duration - ommitted frames and also taking into account for ending and starting frame which might be shown for longer and the resumption of playback. For live, detected duration will be compared with track_duration. But NOT taking into account for ending and starting frame at the gap. Correct me if we are expecting delay at the gap.

[jpiesing]

Here is a proposal to re-organise "live" and "vod" to more accurately reflect what is meant. Extract of CTA-5003-A Device Playback Spec v2 Final for github 125 (3).docx

We should consider how these relate to the test case for buffer underrun and recovery and if we need that one as well as VOD and live here.

[haudiobe]

DPCTF 24/06/05

• implementation Jon looks good
• @haudiobe to implement
• Do we need both modes for testing? @dsilhavy can you check if either live or vod is mimicing an existing test?! Is live underrun and restart? Vod seems different.
• @haudiobe implements in spec and adds a note that only VOD is tested by default as live is mimicing

[haudiobe]

Implemented here in v2.08