Set actual duration for dynamic contents whose future end is already known #1235
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What to set as a
duration
attribute of the MediaSource and by extension to the HTMLMediaElement is not that simple.For static contents (contents that won't evolve with time) like VoD contents, we just set it to the actual known end of the content (technically it is a little more complex as each track might lead to different durations, but still).
However the problem is with dynamic contents which do evolve.
Traditionally, and like many other players, we've set a very high
duration
attribute when playing dynamic content to prevent encountering side effects of setting that attribute to a lower value, such as not being able to seek to far in the content.The current HTML WHATWG specification actually recommends setting it to
Infinity
, but as we've had some issues with that value, we prefer to set it in most cases to 2^32 instead, which has the best result with most platforms.However when doing those developments, I forgot that there are some cases where the content is dynamic but the actual future end of the content is already known. It can happen with DASH, but it mostly happened with the
"local"
transport, which allows to play content downloaded locally on the device.Here a content that was being played while it was still being loaded would report 2^32 through the
getVideoDuration
API, where we could actually be smarter and set the already-known future end of the content instead.This commit fixes that.
What it does it to detect when the duration reported by the
ContentTimeBoundariesObserver
is the actual end of the content, and if it is, indicate it through itsdurationUpdate
event.This event's payload is then given to the
MediaDurationUpdater
, which will now know whether this is the actual end or whether setting a very high duration is here preferred.