1098030 - Getting OnNotDecoded() with WAITING_FOR_DATA during DECODER_STATE_DECODING_FIRSTFRAME hangs the state machine

Status: NEW

(Core :: Audio/Video: Playback, defect)

Description

[Matt Woodrow (:mattwoodrow)]

It looks like StartBuffering doesn't do anything when we're supposed to be decoding the first frame, so we stay in the same state and never request another decode.

Adding DECODER_STATE_DECODING_FIRSTFRAME to the check in StartBuffering doesn't work because mDecodeStartTime is null, and asserts when we try subtract it.

I also assume we'd need to go back into FIRSTFRAME mode once we finish buffering, not into normal DECODING.

Comment 1

[Jean-Yves Avenard [:jya]]

For the record. There's been no change in the existing MDSM logic with the addition of the DECODER_STATE_DECODING_FIRSTFRAME state.

Just the DECODER_STATE_DECODING_METADATA code was split in two.

After a buffering, it was always going back to DECODING, even if DECODING_METADATA wasn't complete

Comment 2

[Bobby Holley (:bholley)]

With my changes in bug 1119456, this is rearing its head again.

Specifically, 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 MDSM::WaitForDataResolved. That does DispatchDecodeTasksIfNeeded, which doesn't know how to handle DECODER_STATE_DECODING_FIRSTFRAME.

jya, should we just make DispatchDecodeTasksIfNeeded handle DECODER_STATE_DECODING_FIRSTFRAME? Note that this also entails removing the assertion of (mState > DECODER_STATE_DECODING_FIRSTFRAME) in Ensure{Audio,Video}DecodeTaskQueued. Or do we want to do something else?

Comment 3

[Jean-Yves Avenard [:jya]]

the assertion mState > DECODER_STATE_DECODING_FIRSTFRAME was really only put there to keep 100% equivalence to the code before bug 1065827.

Fundamentally there should be no difference in the actual handling of decoding the first frame compare to the following decodes. How it's done now is just legacy where we did everything only after the first frame had been decoded.

The only important stuff (that caused me lots of grief in failing tests) was to make sure that any pending seek only occurs after the first frame has been decoded (and start and end times have been set).
If you don't, lots of reds appear :)