W3C home > Mailing lists > Public > public-html-media@w3.org > May 2021

[media-source] Consider relaxing timing of initial HAVE_METADATA transitioning (#275)

From: wolenetz via GitHub <sysbot+gh@w3.org>
Date: Sat, 22 May 2021 00:19:29 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-898673959-1621642767-sysbot+gh@w3.org>
wolenetz has just created a new issue for https://github.com/w3c/media-source:

== Consider relaxing timing of initial HAVE_METADATA transitioning ==
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 the `appendBuffer()` whose parsing reaches the "set the `HTMLMediaElement.readyState` attribute to `HAVE_METADATA` part of step 7 of https://www.w3.org/TR/media-source/#sourcebuffer-init-segment-received until that step is fully completed, including completing media pipeline, decoder, etc. setup and updating the extended `HTMLMediaElement`'s `readyState` to be `HAVE_METADATA` 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 (and the alternative of "faking" a ready pipeline early assumes too much in advance about whether or not the `HTMLMediaElement` will indeed eventually be able to complete that transition to `HAVE_METADATA`).

Note that reaching `HAVE_METADATA` initially in these implementations also means there has been success in configuring a pipeline that is ready to process media matching the metadata. This may be more of a matter for clarification in HTML spec, though it seems to me that delaying `updateend` for any of these interpretations would unnecessarily block the web app from rapidly beginning more buffering.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 22 May 2021 00:19:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 22 May 2021 00:19:36 UTC