New Playback Requirement: Long Duration Playback

[haudiobe]

8.19 Long Duration Playback 8.19.1 Background This requirement addresses the proper playback of a CMAF track over a longer time; in particular, no drift in the playout occurs. The first version of this specification does not define a test for this.

[jpiesing]

Our testing / QA people do not like tests that take a long time to run as a matter of principle. A test that runs for just over an hour might be acceptable as long as there's only one of them and everything else takes less than 5 minutes.

[haudiobe]

What is long enough? How to loop content? We need content, otherwise no specifics.

[dsilhavy]

Suggest to use high resolution and high bitrate content for this test. In my opinion a crucial test for long duration playback is how the MSE and the underlying application "clean" the buffer. In dash.js we define buffer targets and clear the buffer once certain thresholds are reached. For instance only keep 30 seconds of buffer behind the current playhead and 60 seconds in front of the current playhead.

Limited platforms might run into QuotaExceededErrors: If the buffer full flag equals true, then throw a QuotaExceededError exception and abort these step.

[jpiesing]

Suggest to use high resolution and high bitrate content for this test. In my opinion a crucial test for long duration playback is how the MSE and the underlying application "clean" the buffer. In dash.js we define buffer targets and clear the buffer once certain thresholds are reached. For instance only keep 30 seconds of buffer behind the current playhead and 60 seconds in front of the current playhead.

@dsilhavy Which MSE behaviour is referred to here? These tests are really for the MSE implementation & not the app that calls it.

[dsilhavy]

Suggest to use high resolution and high bitrate content for this test. In my opinion a crucial test for long duration playback is how the MSE and the underlying application "clean" the buffer. In dash.js we define buffer targets and clear the buffer once certain thresholds are reached. For instance only keep 30 seconds of buffer behind the current playhead and 60 seconds in front of the current playhead.

@dsilhavy Which MSE behaviour is referred to here? These tests are really for the MSE implementation & not the app that calls it.

I think it depends on what we are expecting here. Do we expect the MSE implementation to "cleanup" the buffer? For instance we might append 60 minutes of media to the buffer. At some point the buffer is "full" and parts need to be removed. Is this the apps responsibility? Or do we expect the MSE to be aware of its limitations and cleanup itself?

From the MSE spec in Prepare Append Algorithm: If the buffer full flag equals true, then throw a QuotaExceededError exception and abort these step.

Meaning: If we do a long duration playback tests here we might need to be aware of the buffer limitations and that the test fails because of unproper buffer management and not because the implementation is not able to handle longterm playback. Consequently, part of this test might include buffer management in the app.

[jpiesing]

Meaning: If we do a long duration playback tests here we might need to be aware of the buffer limitations and that the test fails because of unproper buffer management and not because the implementation is not able to handle longterm playback. Consequently, part of this test might include buffer management in the app.

I agree that a long duration play test would need to include buffer management in the test code.

[haudiobe]

part of new tests