Prior to this patch various failure paths, e.g., runTest() from
mediaStreamPlayback.js would call SimpleTest.finish() twice.
This patch fixes this so no path will call finish only on failure (and not on
success) to make responsibilities clear. This applies to PeerConnectionTest.run
and runTestWhenReady.
runTestWhenReady will be in charge of calling finish for all paths through the
test framework. Its callers runTest and runNetworkTest will stop calling finish.
The responsibility for calling networkTestFinished is moved from
PeerConnectionTest.run to runNetworkTest since the latter calls
startNetworkAndTest which is the analogous start function. At the same time,
networkTestFinished stops calling through to finish since that is now the
responsibility of runTestWhenReady.
All users of the relevant APIs are updated to comply. In many cases related code
is modernized and cleaned up to support the new pattern and to improve
readability.
Differential Revision: https://phabricator.services.mozilla.com/D110405
Expands the EME telemetry test to cover two additional cases.
1. The EME media is loaded but before playback the src is switched to unecrypted
media. In this case, we don't expect encrypted playtime to be recorded, but
we will still collect clearkey playtime as the element still has clearkey
media keys attached.
2. Same as the above, but where the media keys are also cleared. In this case we
do not expect either encrypted or clearkey time to be recorded.
Differential Revision: https://phabricator.services.mozilla.com/D110550
This changeset adds a test to verify that playtime telemetry related to EME is
gathered after playing an encrypted file. It does so by checking that the
VIDEO_ENCRYPTED_PLAY_TIME_MS and VIDEO_CLEARKEY_PLAY_TIME_MS are the same as the
VIDEO_PLAY_TIME_MS after playing an encrypted file (this may not always happen
in the wild, but should hold for test).
To support this test I've added a new eme helper file `eme_standalone.js` this
is an EME helper with no extra dependencies. This allows it to be used in normal
mochitests and browser mochitests, rather than just one or the other. It is also
not coupled with the media mochitests (and `manifest.js`) unlike our existing
EME helpers, so should be more portable.
Differential Revision: https://phabricator.services.mozilla.com/D110446
This is the file attached to the bug, trimmed right after the first cluster:
> truncate --size=66250 ~/lost-delirious-beautiful-1-trimmed.webm
Differential Revision: https://phabricator.services.mozilla.com/D109706
Because the `pause` event does not ensure timing of the current frame displayed
switch the test to instead rely on the `ended` event which should provide a more
reliable timing.
Also update a comment and the title of the test to more specifically reflect its
intention.
Differential Revision: https://phabricator.services.mozilla.com/D107891
This patch
- adds several test files derived from bipbop.mp4. These files are re-encodes
that used vp8 and opus. One reference file is added with metadata that is
correct, and several others are added with bad metadata (it doesn't match the
stream resolution).
- adds these files to the `gPlayTests` to ensure we can play them.
Differential Revision: https://phabricator.services.mozilla.com/D107723
This file tickles some asserts due to it containing fuzzed data that leads to
our WebM parser getting extremely large timestamps.
Differential Revision: https://phabricator.services.mozilla.com/D105505
For YUV 422 video, when we are sampling UV planes at half the resolution of the
Y plane, we can interpolate from 2 samples for the UV planes as an approximation
of the 4 samples, allowing us to better pack the math into SIMD vectors and
substantially reduce the number of multiplications.
Differential Revision: https://phabricator.services.mozilla.com/D105137
This patch stops serializing the cluster size in the cluster header, meaning
that we can push single frames to a blob, even when they are in an open cluster.
This will decrease latency when the MediaRecorder is recording a video track.
This also lets us remove the previous hack we had in place for decreasing the
latency - namely to set a short keyframe interval when the timeslice was short.
With this removed, video quality will go up for short timeslices.
This could have an impact on which players support our encoded videos. Manual
tests show ourselves, Chrome and ffplay handling this change without issues.
Differential Revision: https://phabricator.services.mozilla.com/D95731
CLOSED TREE
Backed out changeset 12ee10496a34 (bug 1629381)
Backed out changeset b0eba102423a (bug 1629381)
Backed out changeset 383fec2e815c (bug 1629381)
As we can only snapshot a telemetry histogram in the chrome process, we have to make them measurable in the chrome process and write a chrome mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D101266
There are several functions related with an element's visibie state, which are confusing. So this patch is going to make them clearer and remove unnecessary function.
- `IsVisible()` : add description to mention that the visibility state is only for layout level, which doesn't represent the actual visible state.
- rename `IsHidden()` to `IsActualInvisible()` : make it represent the actual visible state of an element.
- remove `IsActive()` : current two callers of `IsActive()` only care about if the page is inactive or not, it doesn't care about if page hidden or not. So we can call the owner doc's method directly.
Differential Revision: https://phabricator.services.mozilla.com/D101107
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
In D96896, we chose to suspend video decoding before starting video in order to avoid the race where the video decode is completed by the time it should be suspended.
However, it causes another issue which is affecting the play promise, because we would only resolve the play promise when we have enough data that is related with decoding.
Therefore, in this patch, I choose not to wait until video reaches to the end, instead to wait `timeupdate` to ensure that the video is still playing after resuming video decoding.
If we don't rely on looping to the end, then we don't need to start video from `3` second which is used to shorten the time before video reaches to the end. That gives us more time to reach the completed state (6s, the video's duration) which should prevent us hitting the race again.
Differential Revision: https://phabricator.services.mozilla.com/D97800
Provide coverage that ensures we can:
- Call navigator.requestMediaKeySystemAccess() and receive access
- Call createMediaKeys on the access object
in iframes that are same and different origin.
This should work when waiting for an iframe to fire the load event, but I also
provide a case for if we do not wait for load. It's undesirable to not wait for
the load, but we've historically worked in this case (if this was intentional is
not clear to me). So providing such a test allows for coverage of this case as
long as we want to continue supporting it. Said test will be red as of this
patch, but an immediate follow up will restore our compat with this case.
Differential Revision: https://phabricator.services.mozilla.com/D97321
As `mozentervideosuspend` would only be dispatched when we're in buffering or decoding state, we would miss the event if MDSM already entered other state. eg. completed state.
Differential Revision: https://phabricator.services.mozilla.com/D96896
PDMFactory::CreateDecoder is changed to return a MozPromise that will contain the MediaDataDecoder once created.
This will allow to later make RemoteDecoderManager fully asynchronous and no longer require an IPC sync call to start the RDD process.
We also modify the WebrtcMediaDataDecoderCodec to never create a decoder on the main thread, which could cause deadlocks under some circumstances.
Differential Revision: https://phabricator.services.mozilla.com/D96364
