Report that we can play MP3 inside MP4 on Windows Vista and later in
HTMLMediaElement.canPlayType. Chrome and IE on Windows match this behaviour.
Add a test file with MP3 contained inside MP4. Note the B2G emulator can't play
this file, so I added a codecs parameter to the file's mime type so that
decoder backends have to opt-in to testing with it.
Enable playback of MP3 inside MP4 in WMFReader.
Change from reporting the IMFSourceReader's duration inside WMFReader, to
instead report the IMFSourceReader's duration as the media "end time". This is
needed because the MP3-contained-in-MP4 file's first sample output by the
IMFSourceReader has a non-zero timestamp, and the MediaDecoderStateMachine
assumes that the media samples will be in the range
[$firstSampleStartTime, $firstSampleStartTime+$reportedDuration]. But that's
not the case here, the IMFSourceReader seems to output samples in the range
[0,$reportedDuration]. This assumption mismatch means on the
MP3-contained-in-MP4 file we end up trying to seek after what the
IMFSourceReader assumes is the end of the file, which fails and causes
test failures.
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
* * *
Bug 778077 - Fix up MediaOMXReader fastseek to ensure audio stream stays in sync with video stream. r=cajbir
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 'pre-skip' value representing encoder delay in the Opus
format is recorded once in the .opus representation, but for
WebM it's in the file both in the CodecDelay element and in
the CodecPrivate data. We now reject files where these two
fields don't match.
Our detodos.webm file was exactly this sort of mismatched
file. It has been renamed and added to the invalid file list
to verify we now reject it. A new detodos.webm replaces it,
remuxed from detodos.opus with a bugfixed mkvmerge.
Based on a patch by Jan Gerber.
--HG--
rename : content/media/test/detodos.webm => content/media/test/invalid-preskip.webm
This patch introduces two more MP3 test cases to exercise MP3FrameParser:
* vbr-head.mp3: This file contains a Xing header which gives an exact duration
of 10 seconds. However, it only contains 4 MP3 frames total for a real
duration of around 1 second. It is expected that we read the Xing header
and report 10 seconds.
* huge-id3.mp3: This file contains more than 130KB of ID3 tags. When we search
for MP3 frames, we give up after X KB of non-MP3 data. ID3 tags should not
count towards the non-MP3 count, since they can be very large. This test
case makes sure the skipping of ID3 tags works correctly.
The test checks the duration of an MP3 file with variable bitrate. The
MP3 file only contains silence. It uses a high bit-rate encoding for its
first half, a low bit-rate encoding for its second half. The correct
duration is 10 seconds, but an incorrect implementation will return a
much shorter value.
The test checks the duration of an MP3 file with variable bitrate. The
MP3 file only contains silence. It uses a high bit-rate encoding for its
first half, a low bit-rate encoding for its second half. The correct
duration is 10 seconds, but an incorrect implementation will return a
much shorter value.
--HG--
extra : rebase_source : f62cf69a631a276c4e6e96e827ab615367cad877
This doesn't do any verification of the output, just checks
that we load multichannel files and playback completes.
These are public-domain test files created by Tim and Monty
last year. They're not great audio quality, the idea is just
to verify correct speaker mapping.
http://people.xiph.org/~greg/opus_testvectors/opus_multichannel_examples/
