This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
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.
* Update vtt.js to the newest version which has the capability
of reporting back ParserErrors.
* Update the update-vtt.js script a bit as well since
the symbols that it exports have changed a bit since the last import.
Some of the general information it outputs has since changed as well
like where the repo exists.
* Update WebVTTListener to set the track readiness state
to 'failed to load' if the WebVTT file is not loaded correctly.
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
to remove any implication that the function might be for calculating
the number of output channels for an AudioNode.
--HG--
extra : transplant_source : %D9%12%BB%23n%92%EB%F7%1Df%11%3F%04%B4z%606%ADT%3A
The difference from Blink here is that Blink plays silence for if element
channel counts are > 32, but here more channels are down-mixed. Media stream
channel counts are also fixed to 2 in Blink, but that restriction is not
applied here.
Leaving the "inline" const static/class member initialization of
MaxChannelCount left missing symbols with gcc 4.7.3.
--HG--
extra : transplant_source : %C9%BA%84%0F%E8%89%E2%85p%B8%28%EF%E9M%CC%81%B9ob/
The extra null samples were mostly harmless, and may have even helped avoid
bug 983062 sometimes, but caused the "Samples missing" assertion to fail.
--HG--
extra : transplant_source : M%D6%B4ra2%AE%DA%EC%82%E1%D8_%83%9F%FBw%F2%ECh
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
