-
Notifications
You must be signed in to change notification settings - Fork 132
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Decide the position and autoplay status of a Reload in the Initializer
This commit performs a small modifications so that the `Stream` module, when asking for the current content to be "reloaded" (that is: to replace its MediaSource, generally both for compatibility reasons and to ensure buffers are flushed), no longer needs to either calculate the position to reload to nor if it should auto-play after the reload. This is a simplification of a "reload" event from the point of view of the `Stream`. A "reload" there now is mostly done "in-place" (with a possible time offset to apply, e.g. to re-play the last second after changing the audio track, the `Stream` could be asking for a `timeOffset` of `-1`) and playback characteristics are mostly kept as they were before the reload. The position and playing status is now computed by the `MediaSourceContentInitializer`, which is the actual module doing the reloading logic, based on the position and playing status at the time the reload order was received. This is important in our current Proof-of-Concept of running the RxPlayer in a worker: Calculating the current position and playing status was in the end done synchronously by asking the `HTMLMediaElement` on the page. In a worker, we do not have access to the `HTMLMediaElement`, thus that data cannot be accessed synchronously if the module asking for it is running on the worker (and the `Stream` fully runs in the worker). By keeping such logic closer to the higher level of the RxPlayer's internal architecture (closer to the API, further from the core), we greatly facilitate the possibility of splitting that logic between main thread (`HTMLMediaElement` management) and worker (`Stream`, `MediaSource` management when MSE-in-worker is available). The `MediaSourceContentInitializer` itself is on that matter splitted into two parts: a part in the main thread, the other in the worker. Even if that Proof-of-Concept is not actually merged in the future, this small modification still makes sense, at least to me.
- Loading branch information
1 parent
7f8cba7
commit f218733
Showing
5 changed files
with
98 additions
and
93 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