MSE-in-Workers: Consider (eventually) transitioning attached element to error upon termination of MediaSource's worker/what should media element do?

[wolenetz]

MSE-in-Workers feature issue is #175

This issue tracks discussing whether or not the HTMLMediaElement should do any error transition upon the termination of the DedicatedWorkerGlobalScope that owns the attached MediaSource.

The Chromium experimental implementation just leaves the element's readyState, networkState and error attributes as they were prior to the termination, and simply forces the element's seekable and buffered attributes to each return an empty TimeRange. This is sufficient to prevent unexpected playback of a resource that is no longer available. Note that the termination of the worker is typically caused either by worker.terminate() or DedicatedWorkerGlobalScope.close() from the application side, or as part of teardown of the dedicated workers owned by a Window that is terminating.

There may be important edge cases where the app may not know the MediaSource's worker scope is terminated, when it needs to. Hence this issue to discuss and see if an explicit error transition on the element would be useful in this case.

Note that such error transition might not occur until sometime after the termination of the worker has completed, since the termination steps are run in parallel with whatever is running on the element's context, so there will still be a window of time where the app might get empty buffered or seekable TimeRanges and not immediately know why, even if there were some eventual error transition of the element later due to the worker's termination.

[wolenetz]

Note, this corresponds to the discussion on the feature issue (#175) beginning at https://github.com/w3c/media-source/issues/175#issuecomment-721395481 -- specifically, this issue tracks the first question:

If the DedicatedWorker MediaSource's context is terminated (e.g. worker.terminate()), then the main thread element still remains connected, but seekable and buffered range information reset. There is no other immediate error exposed to the main-thread media element. Would you prefer other behavior in this scenario?

[wolenetz]

Due to mitigating security issues related to over-optimized cross-context communication in the Chromium experimental implementation, it will soon instead cache a recent value of each of seekable and buffered.

Edited: This doesn't fully enable the media element to continue to operate on previously buffered state after the attached MediaSource's execution context has been terminated: the experimental Chromium implementation of this removes the underlying track buffers associated with each SourceBuffer of a MSE-in-Worker whose worker context has destructed while still attached to a not-yet-destructed media element and media element's context is still alive. As such, even though the mitigation caches seekable and buffered, it will still respond with empty ranges if the worker's context has been destroyed.

The question remains:

• Give some error eventually to the media element (if it's still considering itself attached to the objectUrl of the MediaSource that was attached but whose context has been destroyed)?
• Or retain the underlying track_buffers of such a MediaSource (and continue to report the cached seekable and buffered values) until detachment?
• Or continue with the approach of the current experimental Chromium implementation (silently report nothing buffered nor seekable once worker context is gone)?

[wolenetz]

Requesting this be discussed at Sept 14 Media WG meeting.

[chrisn]

Minutes from 14 Sep 2021 meeting: https://www.w3.org/2021/09/14-mediawg-minutes.html#t05