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
Support the Opus audio codec in the WebM (Matroska) container.
This is part of the "WebM 2" proposed spec, which also includes
the new VP9 video codec. Alas we weren't able to get concensus
to change the doctype of filename extension to mark the revision
allowing the new codecs.
