Closed Bug 1120017 Opened 6 years ago Closed 6 years ago

Make MediaDecoderStateMachine::DispatchDecodeTasksIfNeeded operate properly while doing first-frame decodes

Categories

(Core :: Audio/Video, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla37
Tracking Status
firefox36 --- fixed
firefox37 --- fixed

People

(Reporter: bholley, Assigned: bholley)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

No description provided.
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+
https://hg.mozilla.org/mozilla-central/rev/02ab5234c39e
Status: NEW → RESOLVED
Closed: 6 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.