MediaDecoder::DecodeError invokes MediaDecoder::Shutdown, which shuts down the
state machine. Given the sync dispatch, this means that this is basically already
what's happening.
MediaDecoder::DecodeError invokes MediaDecoder::Shutdown, which shuts down the
state machine. Given the sync dispatch, this means that this is basically already
what's happening.
There are two callers of FlushDecoding - One is shutdown (where we already use
promises to wait for the queue to go idle via BeginShutdown), and the other is
dormant (see the comment).
The previous setup is wacky, and can cause the notification to reach the state
machine before the promise rejection, which causes us to stall intermittently.
We also take the opportunity to be a bit less trigger happy when we fire it
in MediaSourceReader.cpp.
CLOSED TREE
Backed out changeset 584d91ffdf88 (bug 1135424)
Backed out changeset d86806ea63f4 (bug 1135424)
Backed out changeset e52401d30a67 (bug 1135424)
Playback position used in calculating buffering time is set
during metadata reading. This is at end of file for the
video in the bug. As a result the buffering data is always
wrong.
Changed to not setting position during metadata - it is set
during frame playback anyway.
Also changes buffering timeout to 15s from 30s.
This means that we can get rid of the code to recheck state after dropping the
monitor. We'll remove the other monitor drop from this method in a subsequent
patch.
This has two implications:
* We no longer need to pipe mQueuedSeekTarget through MDSM::Seek to get the
appropriate clamping.
* MDSM::Seek doesn't _need_ to be called on the main thread anymore.
The model we're moving towards is one where the MDSM can just disconnect all of
its promises, send a ResetDecode down the pipe, and start doing something
unrelated.
I traced this back to something 2011 or earlier and then gave up. Given that we're
doing an exact microsecond comparison here this is almost certainly dead code in
every case except for the one where the media is paused and JS does
|el.currentTime = el.currentTime|. And in that case, I think running through the
regular seek machinery is probably fine.
For some reason the current code is resetting it twice - once explicitly and
once with the AutoSetOnScopeExit. To make matters worse, we have a monitor drop
between the two. So when DecodeSeek runs on the decode task queue but SeekCompleted
runs on the state machine thread, we can start another DecodeSeek during the monitor
drop, and then clobber it with the AutoSeetOnScopeExit, causing us to hang.
This is a non-issue with the patches in bug 1135170, but necessary to make the
patches in this bug independently green.
This already gets incoded in the DECODER_STATE_DORMANT case of RunStateMachine,
which will run momentarily on the state machine thread. Doing this allows us to
avoid calling StopPlayback on the main thread.
This is necessary because we're going to want to start disconnecting sample
and seek requests directly from the state machine thread, and the machinery
asserts that disconnection happens on the same thread as resolution.
More generally, this is the right thing to do architecturally, and will help
wean us off the monitor.
