Implement HTMLMediaElement.fastSeek(), basically by changing all the
MediaDecoderReader::Seek() overrides to not call
MediaDecoderReader::DecodeToTarget(), and have MediaDecoderReader::DecodeSeek()
call DecodeToTarget() if we're doing an accurate (non-fast) seek.
Update gizmo.mp4 to have a keyframe every second, instead of only 1 keyframe at
the start of stream. This makes the unit test I added more useful for mp4...
I pushed most of the seek target clamping logic in MediaDecoder up into
HTMLMediaElement, so that we're clamping in fewer places. Note
MediaDecoderStateMachine::Seek() still sanity checks the seek target.
We have to update the currentTime/MediaDecoder playback position after a seek
completes now, rather than assuming the seek always got it exactly right.
Removed those pesky assertions about seek target lying in the first frame after
seek, since actually sometimes the media doesn't have samples for all streams
after a seek (either due to the media being encoded like that, or because of a
bug in the platform's decoder, not entirely sure).
Green: https://tbpl.mozilla.org/?tree=Try&rev=b028258565e2
Implement HTMLMediaElement.fastSeek(), basically by changing all the
MediaDecoderReader::Seek() overrides to not call
MediaDecoderReader::DecodeToTarget(), and have MediaDecoderReader::DecodeSeek()
call DecodeToTarget() if we're doing an accurate (non-fast) seek.
Update gizmo.mp4 to have a keyframe every second, instead of only 1 keyframe at
the start of stream. This makes the unit test I added more useful for mp4...
I pushed most of the seek target clamping logic in MediaDecoder up into
HTMLMediaElement, so that we're clamping in fewer places. Note
MediaDecoderStateMachine::Seek() still sanity checks the seek target.
We have to update the currentTime/MediaDecoder playback position after a seek
completes now, rather than assuming the seek always got it exactly right.
Removed those pesky assertions about seek target lying in the first frame after
seek, since actually sometimes the media doesn't have samples for all streams
after a seek (either due to the media being encoded like that, or because of a
bug in the platform's decoder, not entirely sure).
Green: https://tbpl.mozilla.org/?tree=Try&rev=b028258565e2
Add a MediaShutdownManager and have that as the only xpcom-shutdown
observer. This then shutsdown the MediaDecoders, and blocks waiting for
the media state machine's shared thread to complete shutdown before
exiting from the xpcom-shutdown observer. This ensures that the
MediaDecoder infrastructure does not use XPCOM on any thread after XPCOM
has shutdown, which is a logical error.
Add a MediaShutdownManager and have that as the only xpcom-shutdown
observer. This then shutsdown the MediaDecoders, and blocks waiting for
the media state machine's shared thread to complete shutdown before
exiting from the xpcom-shutdown observer. This ensures that the
MediaDecoder infrastructure does not use XPCOM on any thread after XPCOM
has shutdown, which is a logical error.
Add a MediaShutdownManager and have that as the only xpcom-shutdown
observer. This then shutsdown the MediaDecoders, and blocks waiting for
the media state machine's shared thread to complete shutdown before
exiting from the xpcom-shutdown observer. This ensures that the
MediaDecoder infrastructure does not use XPCOM on any thread after XPCOM
has shutdown, which is a logical error.
We monitor the stream's output current time via a new MediaStreamListener
owned by DecodedStreamData. We also track its main-thread Finished status.
While we're writing to a DecodedStreamData stream that hasn't finished its
output, we stay in the DECODER_STATE_COMPLETED state so we can keep updating
video and firing timeupdates.
GetClock() uses the DecodedStreamData stream's current time as the source for
the clock if there is one.
--HG--
extra : rebase_source : aba1d092d3d347e26ebd823d61fcbfa40a8cd1fe
