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
The MediaDecoderStateMachine frees the Decoder during its own
shutdown. If the the MediaDecoderStateMachine for an MP3 file
gets cleaned up before the MP3 frame parser is finished, the
OmxDecoder operates with an invalid Decoder.
With this patch, the MediaDecoderStateMachine informs the
OmxDecoder to clear the decoder field. The MP3 parser logic
detects this case and returns.
--HG--
extra : rebase_source : 0a00de3cf7b95ede77408e5d43cccbcd706750cd
On FirefoxOS, the Android libraries estimate the duration of MP3 streams
by examining the first MP3 frame header. This only works for streams with
constant bit rate. For streams with variable bit rate, a too short or too
long duration is computed.
This patch adds support for parsing MP3 frame headers. The decoder handles
file streams by reading them at once at the beginning and parsing them
immediately. Network streams are updated when a new fragment arrives.
On FirefoxOS, the Android libraries estimate the duration of MP3 streams
by examining the first MP3 frame header. This only works for streams with
constant bit rate. For streams with variable bit rate, a too short or too
long duration is computed.
This patch adds support for parsing MP3 frame headers. The decoder handles
file streams by reading them at once at the beginning and parsing them
immediately. Network streams are updated when a new fragment arrives.
--HG--
extra : rebase_source : bffb9447a5fdba4145e83f5aeb3c2accfb7872d6
If we don't support this in any way, then we get into trouble when there is
plenty of compressed data buffered but for some reason video decoding falls
behind (maybe there was a short period where the video data wasn't available).
Audio playback continues normally, but MediaOmxReader keeps making one call
to ReadAudio and one to ReadVideo, and if each call to ReadAudio decodes at
least as much as the calls to ReadVideo, video decoding can never catch up
to the current audio playback position. So video never plays. And when the
video decoding point gets far enough away from the audio decoding point,
horrible things start to happen, such as video and audio reading completely
different parts of the media cache and interfering with the caching mechanism
(which assumes audio and video reads are close together).
This patch approximates keyframe skipping, and is basically just a way for
MediaOmxReader::DecodeVideoFrame to decode more than one frame at a time
if we need video decoding to catch up.
To prevent pathological situations, we cap both the maximum number of frames
decoded per DecodeVideoFrame and the amount of time we spend in the method
(excluding the time for the last frame).
--HG--
extra : rebase_source : cba95c537fe97df5b696581be8233b6e9cffb70b
