Bugzilla

I'd like to add more context here. In the original design, the media engine would communicate with the [external state machine](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/ExternalEngineStateMachine.h#37-50) directly. Media engine side would send [different events](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/ExternalEngineStateMachine.cpp#1071-1088) to the state machine to control how many input it needs. The amount of data we store in advance is controlled by [MFMediaEngineStream::HasEnoughRawData()](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineStream.cpp#271-274,495-497), and we have different threshold for [audio](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineAudioStream.cpp#93-98) and [video](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineVideoStream.cpp#209-214).

However, as we use `MediaFormatReader` as an intermediate bridge to access demuxed data, its internal mechanism sometime would interrupt our original design. In a special situation, even if the media engine sends `Audio/VideoEnough` to the state machine, the media format reader still keep sending input sample to the media engine, which causes the problem mentioned in the [comment 0](https://bugzilla.mozilla.org/show_bug.cgi?id=1879417#c0).

The reason is because that the format reader has its [own mechanism](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/MediaFormatReader.cpp#2556) to determine whether it needs to send more input. If the media engine hasn't created its dcomp handle, we won't return any output to the format reader, so it would keep sending more input to the media engine.

I'd like to add more context here. In the original design, the media engine would communicate with the [external state machine](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/ExternalEngineStateMachine.h#37-50) directly. Media engine side would send [different events](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/ExternalEngineStateMachine.cpp#1071-1088) to the state machine to control how many input it needs. The amount of data we store in advance is controlled by [MFMediaEngineStream::HasEnoughRawData()](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineStream.cpp#271-274,495-497), and we have different threshold for [audio](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineAudioStream.cpp#93-98) and [video](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineVideoStream.cpp#209-214).

However, as we use `MediaFormatReader` as an intermediate bridge to access demuxed data, its internal mechanism sometime would interrupt our original design. In a special situation, even if the media engine sends `Audio/VideoEnough` to the state machine, the media format reader still keep sending input sample to the media engine, which causes the problem mentioned in the [comment 0](https://bugzilla.mozilla.org/show_bug.cgi?id=1879417#c0).

The reason is because that the format reader has its [own mechanism](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/MediaFormatReader.cpp#2556) to determine whether it needs to send more input. If the media engine hasn't created its dcomp handle, we won't return any output to the format reader, so it would keep sending more input to the media engine. When I said `won't return any output`, that means the decoded promise would be [resolved with an empty array](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/media/platforms/wmf/MFMediaEngineStream.cpp#549,556) without a actual decoded data.