-
Notifications
You must be signed in to change notification settings - Fork 133
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Allow seeking through
seekTo
before the HTMLMediaElement is ready
As #1600 signalled, there's currently no practical way to update the initial position (configured through the `startAt` `loadVideo` option) until `startAt` has actually been applied. More generally, it's not possible to perform a `seekTo` call until the initial seek has been performed on the content (the `seekTo` call will just be ignored). This commit proposes the following code updates to improve on that situation: 1. Tangentially related, we now schedule a JavaScript micro-task right at `ContentTimeBoundariesObserver`'s instantiation so the caller can catch `events` that were previously synchronously sent (I'm thinking here of the warnings for the `MEDIA_TIME_BEFORE_MANIFEST` and the `MEDIA_TIME_AFTER_MANIFEST` codes). Without this, we would wait for the next playback observation, which could happen a whole second later. 2. I noticed that the position indicated through the `startAt` `loadVideo` option was bounded so it's inside the `[minimumPosition, maximumPosition]` range (as obtained from the Manifest). As [stated here](#1600 (comment)) I personally think this is suboptimal. In my opinion, we should let the initial position go outside the range of the Manifest and let the application do its thing based on `MEDIA_TIME_BEFORE_MANIFEST` / `MEDIA_TIME_AFTER_MANIFEST` events. As to not totally change the behavior, I've only done so for dynamic contents (contents for which segments are added or removed, like live and contents that are being downloaded locally). VoD contents continue to have the previous behavior for now. 3. I added a "seek-blocking" mechanism to the `MediaElementPlaybackObserver` and made all seek operations, including the one from `seekTo` go through it. The idea is that when it is blocked (as it is initially), we'll delay any seek operation (by marking it as a "pending seek") and only seek to the last one of those once the `unblockSeeking` method is called (when the RxPlayer considers that the initial seek should be done). I also had to add `getPendingSeekInformation` method, sadly. I feel that we could do without it if we're smarter about things, but I wanted to avoid changing too much code here. I also thought about reworking the initial seek so it is completely handled by the `MediaElementPlaybackObserver` - as it could make everything simpler - but I chose for now to implement that less disruptive "seek-blocking" mechanism for now. Note that technically, we could still have an application directly updating the `HTMLMediaElement.property.currentTime` property, or even a web feature such as picture-in-picture doing that. I ensured that this eventuality did not break anything. Still, there will be a preference for pending seeks performed through the `MediaElementPlaybackObserver` over such "HTML5 seeks" performed during that time (if there is a "pending seek", we will apply it regardless of if an "HTML5 seek" happened since then). I'm now unsure if the `getPosition` or `getCurrentBufferGap` API should now return that planned position. I did nothing for those yet.
- Loading branch information
1 parent
2ca74e6
commit 8bb2583
Showing
6 changed files
with
178 additions
and
55 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters