Created attachment 8546933 [details] [diff] [review] Make the DispatchDecodeTasksIfNeeded path handle DECODER_STATE_DECODING_FIRSTFRAME. v1 Once we make MP4Reader reject with WAITING_FOR_DATA, we end up with the following scenario: DecodeFirstFrame requests audio data, and then it gets rejected with WAITING_FOR_DATA. So OnAudioNotDecided does WaitForData, which eventually causes us to be called back in MediaDecoderStateMachine::WaitForDataResolved. That does DispatchDecodeTasksIfNeeded, which currently bails out of our state is DECODER_STATE_DECODING_FIRSTFRAME. The other way to do this would be to add a separate specialized path through all this asynchronicity for DECODER_STATE_DECODING_FIRSTFRAME. But it's not clear to me what that buys us.
Comment on attachment 8546933 [details] [diff] [review] Make the DispatchDecodeTasksIfNeeded path handle DECODER_STATE_DECODING_FIRSTFRAME. v1 Approval Request Comment [Feature/regressing bug #]: MSE [User impact if declined]: Youtube video stalls and sync issues. Less consistent testing. [Describe test coverage new/current, TBPL]: Landed on m-c. [Risks and why]: This does affect non-MSE playback. [String/UUID change made/needed]: None.