MSE-in-Workers: Centrally define the window/worker HTMLMediaElement<->MSE API communication mechanism

[wolenetz]

MSE-in-Workers feature issue is #175.

This issue tracks clarifying and centrally defining the communication mechanism(s) necessary for interoperable implementations MSE-in-Workers.

The initial draft spec (https://github.com/wolenetz/media-source/tree/mse-in-workers-initial-spec) has repeated large blocks of text, rather than concise reusable references, to describe the communication mechanisms in a black-box fashion. Clarity would be greatly improved, I think, if the mechanism and constraints were described in a separate section in detail in the spec.

Example of an instance that would be improved:

Set recent duration and recent live seekable range respectively to be what the duration and live seekable range were recently, with no greater delay than what would be perceived by a message listener in Window if the most recent update to duration or live seekable range had been sent from the DedicatedWorkerGlobalScope to the Window using postMessage(message, options). Note: This allowance for delay acknowledges that the HTMLMediaElement may not have direct access to the current values of duration and live seekable range when the MediaSource is in a different execution environment. Instead of forcing all implementations to block multiple execution environments until the HTMLMediaElement can reliably retrieve the precise current values of duration and live seekable range, this allowance lets both proceed under assumptions of message passing coherency that are no worse than what is allowed to the application code running in these different execution environments.

Potential improvement:

• On changes to live seekable range or duration, if in the worker, run New Algorithm X to communicate the change to the HTMLMediaElement in the window context.
• New Algorithm X would use some Well-defined internal, nonexposed MessageChannel pair established at attachment time to send the change message, with a handler in the window context that would update an internal recent duration and recent live seekable range cache for the media element.
• Add a note in New Algorithm X describing why this cache is useful and that it can lag behind the actual state in the worker.
• Add a note in New Algorithm X indicating that implementations MAY use internal communication channels that are faster than MessageChannels for on-demand querying the current live seekable range and duration. (Chrome's experimental implementation includes this optimization with careful locking and cross-thread data sharing abstractions.)

Various other places would need similar, including some that communicate from window HTMLMediaElement to worker MSE.

Currently, the following are known places in the feature draft spec that could use this improvement:

• Worker to Window: recent live seekable range (for seekable attribute value determination)
• Worker to Window: recent duration (for seekable attribute value determination)
• Worker to Window: recent intersection ranges (for HTMLMediaElement's buffered attribute value determination)
• Worker to Window: track creation, removal, and enabled/selected/showing state changes (for populating window-side mirrors of the worker MSE tracks and updating the HTMLMediaElements track lists).
• Window to Worker: track removal and enabled/selected/showing state changes involving window-side mirrors of the worker MSE tracks (for updating MSE tracks, tracklists and activeSourceBuffers list changes).
• Window to Worker: HTMLMediaElement error occurrence

[wolenetz]

Steps in the [=attaching to a media element=] will need similar clarification.