New Playback Requirement: Buffer Underrun and Recovery

[haudiobe]

8.17 Buffer Underrun and Recovery 8.17.1 Background This case addresses if the buffer in play mode runs out of media and is recovering from this situation. Different options are considered: • Stall at fragment boundary and resume with next fragment (decoding order) • Stall at chunk boundary and resume with next chunk • Stall/Underrun, but continue with live timing (so basically in a loss) o For fragment o For chunk

The first version of this specification does not define a test for this.

[haudiobe]

(19/11/06 DPCTF)

• Device Playback Issue, no content issue
• Some work in DASH/CMAF on Resynchronization. But if relevant, needs content spec additions

From Device Playback Spec

• No capabilility required as every platform should support
• No specific content necessary, you can use existing content
• Stimulus needs to be defined requires more details on how to emulate buffer underrun need to implement different cases
• Observation ** needs to be defined, but basically restart after resync has happened

[haudiobe]

merge with low-latency issue #81

[dsilhavy]

This testcase might result in different behavior on platforms:

Some platforms might require a certain amount of frames to be included in the SourceBuffer. For instance, on some platforms it might be required to have a least 0.5 seconds of content in the buffer, otherwise playback stalls. Other platforms might event play single frames in the buffer. Same behavior for stalling, maybe even audio and video specific.

[jpiesing]

This case addresses if the buffer in play mode runs out of media and is recovering from this situation. Different options are considered: • Stall at fragment boundary and resume with next fragment (decoding order) • Stall at chunk boundary and resume with next chunk

For these two, my understanding is that playback should resume when the buffer is filled again. Perhaps the test would simply append 20s of data, start playback, wait for a stalled event & then append another 10s of data before reporting the end of media. Pass would be that the playback resumes after the stall & the remaining 10s of data is played?

• Stall/Underrun, but continue with live timing (so basically in a loss) o For fragment o For chunk

I'm not sure about these two. Is there any UA/MSE implementation behaviour or would it be the player/app responsibility to seek forwards to make up for the duration of the stall? If it would be the latter then there's nothing to be tested.

[dsilhavy]

• Stall/Underrun, but continue with live timing (so basically in a loss) o For fragment o For chunk

I'm not sure about these two. Is there any UA/MSE implementation behaviour or would it be the player/app responsibility to seek forwards to make up for the duration of the stall? If it would be the latter then there's nothing to be tested.

In my opinion that is app logic. Assume playback stalls for 10 seconds in a livestream because of a buffer underrun. Then the buffer is filled again and MSE will continue to play. MSE is not aware of the target live edge or any related live parameters.

In dash.js we frequently check if the player is still in the defined DVR window. If not, we seek back to the initial live edge.

[haudiobe]

part if new test cases