The renaming of MediaWebspeechRecognitionEnable to
media_webspeech_recognition_enable is to follow the StaticPrefs convention,
because bindings are going to assume that convention.
Differential Revision: https://phabricator.services.mozilla.com/D32942
--HG--
extra : moz-landing-system : lando
Unencrypted samples can carry init data and thus we should set the init data
type regardless of if the sample itself is encrypted (otherwise the init data
info is incomplete for unencrypted samples).
Depends on D32751
Differential Revision: https://phabricator.services.mozilla.com/D32752
--HG--
extra : moz-landing-system : lando
Add another test case for the mp4 key rotation (pssh in fragments) test. In this
case, the test file has a clear (unencrypted) lead. This test seeks to ensure we
don't regress surfacing of init info even if we encounter it for fragments that
start with unencrypted samples.
Add a further check to the key rotation test to ensure that the initDataType is
being surfaced correctly on the encrypted event.
Media files created with shaka packager via:
```
packager-win.exe
in=bipbop.mp4,stream=audio,out=bipbop-clearkey-keyrotation-clear-lead-audio.mp4
in=bipbop.mp4,stream=video,out=bipbop-clearkey-keyrotation-clear-lead-video.mp4
--enable_raw_key_encryption --keys
label=:key_id=00112233445566778899AABBCCDDEEFF:key=00112233445566778899AABBCCDDEEFF
--crypto_period_duration 5 --fragment_duration 5 --clear_lead 3
```
Note that the way shaka packager handles key rotation in this case is just to
left shift the key id and the key. In this case, where crypto_period_duration ==
fragment_duration, a left shift of 1 will take place each time the keys rotate.
This happens once in the test file leaving us with 2 key ids + keys.
Depends on D32750
Differential Revision: https://phabricator.services.mozilla.com/D32751
--HG--
extra : moz-landing-system : lando
test_eme_pssh_in_moof tests if our key rotation works correctly. It currently
does so by using a single video with an audio and video track. This patch
refactors the test so that it does the same thing (all going well), but in a
more extensible way.
The changes in this patch seek to lean more heavily on test harness
functionality in manifest.js and eme.js where possible. This cuts down on some
boilerplate, but means we have to make some concessions in a more verbose
expression of our test media list so the eme.js functions work with it.
Differential Revision: https://phabricator.services.mozilla.com/D32750
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
This async/await-ifies the test to put checks in logical order.
It also, as a drive-by, adds `v.token = token` since this is a cue to the test
framework in manifest.js to mozDumpDebugInfo() on the right element after
timeout of a token.
Differential Revision: https://phabricator.services.mozilla.com/D32114
--HG--
extra : moz-landing-system : lando
This assert can be racy if the following sequence happens:
SetPlaying() -- watch manager schedules SendData()
Stop() -- unwatches mPlaying, resets mStartTime
SendData() -- fails the assert
SendData handles the case where mStartTime is unset at runtime already through the mData check, further making this assert unnecessary.
Depends on D32112
Differential Revision: https://phabricator.services.mozilla.com/D32113
--HG--
extra : moz-landing-system : lando
The following sequence in DecodedStream could lead to a stall for a captured
media element:
- MediaDecoder decodes some data, DecodedStream sends it out
- MediaDecoder pauses for buffering, DecodedStream sees SetPlaying(false)
- MediaDecoder decodes until the end, DecodedStream doesn't send since it's
not playing
- MediaDecoder starts playing again, DecodedStream sees SetPlaying(true)
At the last step above, SetPlaying(true) doesn't trigger SendData() so no data
is sent out. Since all data has already been decoded, nothing can trigger
SendData() anymore. This patch fixes this by calling SendData() on SetPlaying().
Depends on D32111
Differential Revision: https://phabricator.services.mozilla.com/D32112
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
Refactor those tests' structure in order to make them more readable, and add the comment to show what the test purpose is for each test.
Differential Revision: https://phabricator.services.mozilla.com/D31914
--HG--
extra : moz-landing-system : lando
This patch do two things in order to trigger loading for track element and wait for correct event to check track's and cues' status after loading finished.
(1) listen track element's load event
There are some tests listening video's loadedmetadata, but it's wrong. The loading process of media element and track element are completely non-related.
If you would like to check track element's status, you should wait for track element's load event.
(2) enable track explictly
If the text track which has default attribute is added to the media element before the media element starts running automatic track selection [1], then it would be enable by the media element.
Otherwise, you have to enable track explicitly by changing its track mode.
[1] https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks:text-track-7
Differential Revision: https://phabricator.services.mozilla.com/D31913
--HG--
extra : moz-landing-system : lando
Create test elements in HTML beforehand, which can remove unnecessary JS code and make test cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D31911
--HG--
extra : moz-landing-system : lando
It's dead code, because AudioScheduledSourceNode is an abstract class and all
subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32202
--HG--
extra : moz-landing-system : lando
Adding tests to ensure that when cues with overlapping times, the one with earlier end timestamp should disappear when the media time reaches its end time. In this test, we have two cues with overlapping time, when the video starts, both cues should be displayed. When the time passes 1 seconds, the first cue should disappear and the second cues should be still displayed.
Differential Revision: https://phabricator.services.mozilla.com/D31172
--HG--
extra : moz-landing-system : lando
If the amount of cues which are going to be displayed is different from the one we displayed last time, we have to compute cues' display state again because cue's position might be affected by other cues.
Differential Revision: https://phabricator.services.mozilla.com/D31170
--HG--
extra : moz-landing-system : lando
We can actually let `processCue()` to handle rendering cues or cleaning displayed cues, no need to use another way to clear the cue.
The advantages is to make the code cleaner and easier to read, now we just need to know JS side would handle all rendering stuffs for us. We don't need to have different behavior when there is no showing cue.
The way we clear displayed cues are intuitive, we would remove all child nodes under the overlay, which are used to display cues.
Differential Revision: https://phabricator.services.mozilla.com/D31171
--HG--
extra : moz-landing-system : lando
Refactor those tests' structure in order to make them more readable, and add the comment to show what the test purpose is for each test.
Differential Revision: https://phabricator.services.mozilla.com/D31914
--HG--
extra : moz-landing-system : lando
This patch do two things in order to trigger loading for track element and wait for correct event to check track's and cues' status after loading finished.
(1) listen track element's load event
There are some tests listening video's loadedmetadata, but it's wrong. The loading process of media element and track element are completely non-related.
If you would like to check track element's status, you should wait for track element's load event.
(2) enable track explictly
If the text track which has default attribute is added to the media element before the media element starts running automatic track selection [1], then it would be enable by the media element.
Otherwise, you have to enable track explicitly by changing its track mode.
[1] https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks:text-track-7
Differential Revision: https://phabricator.services.mozilla.com/D31913
--HG--
extra : moz-landing-system : lando
