Live DVR and segment availability (IOP Guidelines 4.4.3.3)

[arjen4157]

Have you read the FAQ and checked for duplicate open issues?:

Yes.

What version of Shaka Player are you using?:

v2.3.3

Can you reproduce the issue with our latest release version?:

Yes, both debug/release versions: Shaka Player v2.3.3

Can you reproduce the issue with the latest code from master?:

Haven't tested.

Are you using the demo app or your own custom app?:

The demo app.

https://shaka-player-demo.appspot.com/demo/#asset=https://live.unified-streaming.com/smptebitc/smptebitc.isml/.mpd;lang=en-US;build=debug_compiled

If custom app, can you reproduce the issue using our demo app?:

What browser and OS are you using?:

firefox/edge/chrome on win64,. It doesn't seem to be OS or browser related.

What are the manifest and license server URIs?:
(NOTE: you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
(NOTE: a copy of the manifest text or an attached manifest will not be enough to reproduce your issue, and we will ask you to send a URI instead)

https://live.unified-streaming.com/smptebitc/smptebitc.isml/.mpd

What did you do?

The behaviour is reproducible using the demo app and the follow asset:

https://shaka-player-demo.appspot.com/demo/#asset=https://live.unified-streaming.com/smptebitc/smptebitc.isml/.mpd;lang=en-US;build=debug_compiled

Playback starts but then stops after about 12 seconds. Audio and video fragments are still loaded and the MPD gets requested as well. The player shows the 'buffering' animation.

What did you expect to happen?

Playback to continue.

What actually happened?

The player shows the 'buffering' animation. When hitting load again it plays again for 12 seconds.

Additional info:

This is a live presentation with a timeShiftBufferDepth of 5 minutes, uses UTC time offsets and has a UTCTiming element. The SegmentTemplate describes the current available DVR window using the SegmentTimeline representation.

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 timeshift buffer are no longer announced in the MPD.

The Period start is moved by changing the Period@Start attribute and the @presentationTimeOffset and S values are updated such that the Segment Information is not modified over an MPD update.

See also: DASH IF Interoperability Guidelines 4.4.3.3.

The issue is most likely related to the above. Any insights are most appreciated.

If you need any additional information, please feel free to ask.

Thanks,

Arjen

[TheModMaker]

We don't support changing the Period@start attribute. Although this is allowed by both the DASH spec and the IOP, it doesn't represent a common use case and there are other ways to achieve the same thing. We require keeping the Period@start the same throughout the presentation, but you could still change the segment list and use startNumber to indicate when segments are dropped from the manifest.

[sandersaares]

FYI @arjen4157 DASH-IF is currently discussing removal of this practice from the list of implementation guidelines. See Dash-Industry-Forum/DASH-IF-IOP#160

In general, the fact that segments are outside the time shift buffer should be enough to prevent them from being accessed - there is no need to modify segment addressing parameters just to make expired segments not be used.

[TheModMaker]

@arjen4157 Does this answer all your questions? Can we close the issue?

[arjen4157]

@TheModMaker Yes, it does. Thanks for the replies.

Note: I've updated the stream mentioned above, so it's not relevant for this issue anymore.

[ismena]

@arjen4157 Glad we were able to help, please reach out in the future if something comes up :)