[media-source] MSE-in-Workers: Track enable/selection change behavior needs clarity (#281)

wolenetz has just created a new issue for https://github.com/w3c/media-source:

== MSE-in-Workers: Track enable/selection change behavior needs clarity ==
MSE-in-Workers feature issue is #175 

The "Changes to selected/enabled track state" section makes sense in the REC v1 spec for Window-only MSE and HTMLMediaElement.

This issue tracks figuring out what to do with such state management if MSE is in a DedicatedWorker, while the HTMLMediaElement remains in Window.

Assuming apps might need information about tracks in either context, and similarly may wish to change the state of them, how best can this be done in the specification?

Scenario:
Simultaneous track selection of different video tracks in each of the Window (media element) and DedicatedWorker (MSE): These changes can affect what the extended HTMLMediaElement's seekable and buffered attributes return:
* A track, when selected, should (at some point soon) ensure the track's SourceBuffer is or becomes a member of the activeSourceBuffers. Likewise, a deselected track should (at some point soon) ensure that if there are no other selected/enabled/etc tracks from the deselected track's SourceBuffer, that that SourceBuffer is removed from the activeSourceBuffers list.
* `seekable` and `buffered` are conditioned upon information from the current activeSourceBuffers list.
* So, simultaneous track changes can race under the message passing mechanism [*].
* Even with a single track change by the Window side, the round-trip of potentially updated buffered and seekable information could be delayed.

It's probable that this scenario will not be solved by forcing all implementations to make such changes atomically[*]. While some do (like Chrome's prototype implementation), the solution might be a non-normative note that apps may need to be aware of how potential delays in buffered, seekable, etc information resulting  from scenarios like this might occur. A potential handler might need to round-trip the necessary information on the application side with message passing there.

[*] In Chrome's prototype implementation so far (apart from this track stuff which is not yet fully implemented in worker), micro-locking is used for most of the communication, rather than the potentially slower message posting/handling mechanism allowed by the MSE-in-Worker spec (in my upcoming PR for the initial spec draft, there will be a "Cross-context communication model" section describing that mechanism). Th

Please view or discuss this issue at https://github.com/w3c/media-source/issues/281 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 25 June 2021 21:19:58 UTC