I discovered this bug when testing the yt MSE Codec Tests, we fail on the test case 4 (DurationAfterAppendOpusAudio). The failure reason is because we didn't dispatch durationchange event correctly.

Base on the spec,

When the length of the media resource changes to a known value (e.g. from being unknown to known, or from a previously established length to a new length) the user agent must queue a media element task given the media element to fire an event named durationchange at the media element.

However, we only dispatch the durationchange event after loading the metadata, see here. In the test case4, we failed to load the metadata so that the durationchange event was never dispatched.

Fixing this can also fix the other failure yt cases (21/39/60/81).

So in the yt-MSE test case4, they created two buffers, one for audio and one for video (this one seems no need to be created, because they only test audio in that test), but only append the init segement for the audio buffer.

As they created two buffers, we need to receive the init segment on both buffers in order to make the media source as active, which would eventually trigger finishing loading metadata. On that test, it only feeds the media source with audio data for one buffer so media element would never finish loading metadata. Therefore, we won't dispatch durationchange as well.

In this case, when only having data in one source buffer, is it qualified to this part the length of the media resource changes to a known value in the spec?

if the user agent initially estimated the media resource's duration instead of determining it precisely, and later revises the estimate based on new information, then the duration would change and the durationchange event would be fired.

This mentions the possibility of determining the estimated duration in the beginning, which can be done before finishing loading the metadata. So I think we should decouple the metadata load and the duration change, the duration can be determined before loading metadata.