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 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.)