You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 20, 2022. It is now read-only.
if paused/skipped back, fragementInfo requests are only sent until duration has been reached
DVRWindow is assumed to cover full duration.
I think this opens room for some errors:
To my knowledge, the "duration" for a live stream is meant as an estimate to , for example, allow players to scale a timeline control. It is not actually a hard limit for the duration of the stream, nor does it imply a DVR Window size.
This one has an estimated duration of 60 minutes, current duration ~6 minutes and a DVR Window of 5 Minutes, so first 62 seconds are no longer accessible.
I'm really not sure how to properly handle this, but my feeling is that trying to treat live streams w/ duration as static is just not a good fit.
continuing fragemntinfo requests when hitting the estimated duration would make things better, but still wouldn't cover DVRWindowSize smaller than estimated duration.
The text was updated successfully, but these errors were encountered:
Hi,
Yes, we made the choice to consider start-over streams as 'static' streams with progressive duration.
One reason was to enable 'ended' event to be raised at end of content.
It seems not to be easy to be compatible with all use cases and encoders.
If you have any official specification about MSS start-over streams, please let us know.
Also if you have any suggestion to improve support for start-over streams, please do not hesitate.
MSS Live Streams with duration specified in the manifest are special-cased as "startOver" stream(s).
I think this opens room for some errors:
To my knowledge, the "duration" for a live stream is meant as an estimate to , for example, allow players to scale a timeline control. It is not actually a hard limit for the duration of the stream, nor does it imply a DVR Window size.
This manifest has an estimated duration of 5 minutes, an actual duration of ~13 minutes and a DVR Window covering the whole event.
This one has an estimated duration of 60 minutes, current duration ~6 minutes and a DVR Window of 5 Minutes, so first 62 seconds are no longer accessible.
I'm really not sure how to properly handle this, but my feeling is that trying to treat live streams w/ duration as static is just not a good fit.
continuing fragemntinfo requests when hitting the estimated duration would make things better, but still wouldn't cover DVRWindowSize smaller than estimated duration.
The text was updated successfully, but these errors were encountered: