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
While FFmpeg function signatures tend not to change between versions of FFmpeg,
class layouts can change dramatically. We include libavcodec, libavformat,
and libavutil headers here so that we don't accidentally build against the wrong
binary interface.
This takes care of automatic track selection for tracks with
the default attribute specified. However, it does not take
into account any user preferences set through Firefox such
as default language.
This makes it more clear what part of the code is triggering the ReadyState
to be what it is. I.E. Tracks added through the HTMLMediaElement::AddTextTrack
method should have a ReadyState of "Loaded" and so it's more clear for
function to specify that. Vice versa for TrackElements which add TextTracks
with a default ReadyState of "None".
- This allows us to pass around ReadyState values. It also makes the type
explicit which will save us from potentially shooting ourselves in
the foot.
- I also renamed 'READY_STATE_NONE' and 'READY_STATE_ERROR' to
'NotLoaded' and 'FailedToLoad' respectively in the enum. This is to
avoid some name collision errors we were having. It also makes it more
clear where in the spec this is as these names are the spec's names
for the TextTrack enum.
This makes more sense as the READY_STATE values in the spec are always
referred to be 'text track readiness states' not HTMLTrackElement
readiness states.
