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
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
