Open wolenetz opened 3 years ago
Note that with MSE-in-Workers (#175), information like duration and track metadata may propagate to the HTMLMediaElement
at slower rate than atomically during initialization segment received algorithm (running in a MediaSource Worker), by nature of the algorithm running in a different context than the main window. So this relaxation of legacy main thread element duration == main thread mediasource duration requirement wouldn't conflict with MSE-in-Workers specification/expectations of delay in main thread media element duration eventually matching what worker-thread mediasource duration was.
Requesting this be discussed at Sept 14 Media WG meeting.
See also #215
Minutes from Sept 14 2021 discussion: https://www.w3.org/2021/09/14-mediawg-minutes.html#t06
Minutes from 8 Nov 2022 discussion: https://www.w3.org/2022/11/08-mediawg-minutes.html#t04. Next step was to create a PR to relax the timing for HAVE_METADATA
and HAVE_CURRENT_DATA
.
Some implementations, including Chromium, have a media pipeline on distinct thread(s)/process(es) versus the web apps' thread(s). Delaying the relevant
updateend
associated with theappendBuffer()
whose parsing reaches the "set theHTMLMediaElement.readyState
attribute toHAVE_METADATA
part of step 7 of https://www.w3.org/TR/media-source/#sourcebuffer-init-segment-received until that step is fully completed is not done in some implementations, so the application can buffer more media faster while the pipeline is still transitioning in parallel.This issue tracks standardizing some allowance for this behavior, as allowing improved application buffering agility is probably a good idea.
-editted: The delay in Chromium is slightly less than I had thought (decoder setup doesn't necessarily block initial transition to
HAVE_METADATA
, but the metadata notification from MSE to the media element still hops threads through the pipeline.)