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
OmxDecoder refers to MediaResource, which must be released on
the main thread. This patch changes the MP3 parser logic to send
a runnable to the main thread for releasing OmxDecoder.
If the decoder has been cleaned up, there is no point in further
parsing the MP3 file. This patch makes the I/O logic stop in that
case.
The patch also fixes a bug where the beginning of an MP3 chunk was
parsed multiple times if the chunk is larger than 4 GiB.
--HG--
extra : rebase_source : d247ed3995991d362c51a0666274e9de3b90b7d2
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
Reading large MP3 files from a slow medium, such as an SD card, takes
several seconds. This is too long for interactive applications like the
music app.
With this patch, the OmxDecoder reads large MP3 file in smaller chunks
and hands over each chunk individually to the MP3 parser. Reading the
file is done in the I/O thread, which is allowed to block, parsing is
done on the main thread.
The current chunk size is 8 MiB, which is small enough to not cause any
delay.
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.
MP3 streams consist of small frames, with each frame containing the
audio data of a few hundred milliseconds. The actual duration of the
encoded audio can among frames.
Each frame consists of a 4-byte frame header, some optional extra
information, and the audio data. The MP3 frame parser walks over the
content of an MP3 stream, computes the duration of each frame from
the frame header, and sums them up to the streams complete duration.
The MP3 frame parser does not decode the actual audio data.
Reading large MP3 files from a slow medium, such as an SD card, takes
several seconds. This is too long for interactive applications like the
music app.
With this patch, the OmxDecoder reads large MP3 file in smaller chunks
and hands over each chunk individually to the MP3 parser. Reading the
file is done in the I/O thread, which is allowed to block, parsing is
done on the main thread.
The current chunk size is 8 MiB, which is small enough to not cause any
delay.
--HG--
extra : rebase_source : 4effb86db481c405a97760cd98f4218dde42104d
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
MP3 streams consist of small frames, with each frame containing the
audio data of a few hundred milliseconds. The actual duration of the
encoded audio can among frames.
Each frame consists of a 4-byte frame header, some optional extra
information, and the audio data. The MP3 frame parser walks over the
content of an MP3 stream, computes the duration of each frame from
the frame header, and sums them up to the streams complete duration.
The MP3 frame parser does not decode the actual audio data.
--HG--
extra : rebase_source : 1b101d8f9bf73e62672933d0f5d20253d7b25491
