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.
Attachment #8546933 - Flags: review?(cpearce)
Attachment #8546933 - Flags: review?(cpearce) → review+
4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
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.
Attachment #8546933 - Flags: approval-mozilla-beta?
Attachment #8546933 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.