Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates based on preload branch #1413

Open
wants to merge 9 commits into
base: dev
Choose a base branch
from

Conversation

peaBerberian
Copy link
Collaborator

@peaBerberian peaBerberian commented Mar 20, 2024

The last preload branch (#1407) is a good start for a preload API but is not yet finished and is already getting very big.

I noticed when working on it that several code updates made sense even without the Preload API.

So I decided to isolate those parts in a separate PR, where each commit details one type of update. The main theme is improving code readability:

  • Rename segment_buffer file into the new segment_sink name

    We changed the name of classes from SegmentBuffer to SegmentSink but
    didn't actually update the file names. This is now done.

  • Rely on compat version of TextTrack-related types in remove_cue.ts

  • Provide more precize typing for the SegmentSinksStore's SegmentSinks

  • ContentInit: Rename "settings" into "initSettings"

    To avoid the confusion between several concepts named "settings" in the
    MediaSourceContentInitializer, the settings provided to its
    constructor is now renamed to _initSettings (aligns with
    _initCanceller for its TaskCanceller initialized at instantiation).

  • Rename and factorize some methods of the MediaSourceContentInitializer

    Some private methods of the MediaSourceContentInitializer were
    difficult to follow due to the heavy usage of inner functions with
    unclear names (such as recursivelyLoadOnMediaSource).

    I now tried to isolate some of those and rename the different methods
    called at content load so it makes more sense. Methods in order are:

    start > _setupInitialMediaSourceAndDecryption >
    _onInitialMediaSourceReady > _setupContentWithNewMediaSource >
    _startLoadingContentOnMediaSource
    

    Note: _setupContentWithNewMediaSource and
    _startLoadingContentOnMediaSource are still similarly named, though
    the former just has the task of setting up a reloading logic and then
    calling the latter.

    Note2: _startLoadingContentOnMediaSource is still a huge and complex
    method that we might improve on in the future.

  • Isolate HTMLTrackElement clearing in its own private method

    This is a minor code update to make the NativeTextDisplayer's clean-up
    easier to follow by isolating the DOM-related (TextTrack,
    HTMLTrackElement, HTMLMediaElement) code inside its own private method.

  • Make MainSourceBufferInterface code more readable isolating inner functions

    The callback called on the "updateend" and "error" events on a
    SourceBuffer were previously declared as arrow functions inside the
    constructor.

    This allowed to keep a clear JS context for the this keyword, but it
    made the MainSourceBufferInterface's constructor harder to read.

    I found it more readable to declare both callback as private methods
    instead, with the drawback of having to bind the this explictely.

  • Fix SyncOrAsync util syncValue transfer

    Our SyncOrAsync util is used for cases where a task is >99% of the time
    synchronous, yet <1% of the time asynchronous, and where we don't want to
    incur any overhead/supplementary complexity of awaiting a Promise which
    inherently schedule a microtask when the value is most probably already
    there.

    It worked well for most usages, but it turns out that a task that starts
    as asynchronous would then always lead to the need to rely on Promises,
    even once the task is finished (basically, if it started as an "async
    value" it could never transform itself to a "sync value").

    This does not create any issue but we could gain some minuscule advantage
    (we could argue that SyncOrAsync's advantage is in itself
    minuscule) here by just relying on the value synchronously once the task is
    finished.

We changed the name of classes from *SegmentBuffer to *SegmentSink but
didn't actually update the file names. This is now done.
To avoid the confusion between several concepts named "settings" in the
`MediaSourceContentInitializer`, the settings provided to its
constructor is now renamed to `_initSettings` (aligns with
`_initCanceller` for its TaskCanceller initialized at instantiation).
Some private methods of the `MediaSourceContentInitializer` were
difficult to follow due to the heavy usage of inner functions with
unclear names (such as `recursivelyLoadOnMediaSource`).

I now tried to isolate some of those and rename the different methods
called at content load so it makes more sense. Methods in order are:

```
start > _setupInitialMediaSourceAndDecryption >
_onInitialMediaSourceReady > _setupContentWithNewMediaSource >
_startLoadingContentOnMediaSource
```

Note: `_setupContentWithNewMediaSource` and
`_startLoadingContentOnMediaSource` are still similarly named, though
the former just has the task of setting up a reloading logic and then
calling the latter.

Note2: `_startLoadingContentOnMediaSource` is still a huge and complex
method that we might improve on in the future.
This is a minor code update to make the NativeTextDisplayer's clean-up
easier to follow by isolating the DOM-related (TextTrack,
HTMLTrackElement, HTMLMediaElement) code inside its own private method.
…ctions

The callback called on the `"updateend"` and `"error"` events on a
SourceBuffer were previously declared as arrow functions inside the
constructor.

This allowed to keep a clear JS context for the `this` keyword, but it
made the `MainSourceBufferInterface`'s constructor harder to read.

I found it more readable to declare both callback as private methods
instead, with the drawback of having to bind the `this` explictely.
Our `SyncOrAsync` util is used for cases where a task is >99% of the time
synchronous, yet <1% of the time asynchronous, and where we don't want to
incur any overhead/supplementary complexity of awaiting a Promise which
inherently schedule a microtask when the value is most probably already
there.

It worked well for most usages, but it turns out that a task that starts
as asynchronous would then always lead to the need to rely on Promises,
even once the task is finished (basically, if it started as an "async
value" it could never transform itself to a "sync value").

This does not create any issue but we could gain some minuscule advantage
(well, we could argue that `SyncOrAsync`'s advantage is in itself
minuscule) here by just relying on the value synchronously once the task is
finished.
@peaBerberian peaBerberian force-pushed the misc/updates-based-on-preload branch from 73af7b5 to 9e5ac7b Compare May 2, 2024 14:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant