This is a better place for it and is more appropriate given that it
already exports to mozilla/DataMutex.h. I'll fix the rvalue reference
problems in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D16723
--HG--
rename : dom/media/eme/DataMutex.h => xpcom/threads/DataMutex.h
extra : moz-landing-system : lando
We would only start the AudioContext blocked by our autoplay policy, won't resume AudioContext which is suspended explictly by page.
Differential Revision: https://phabricator.services.mozilla.com/D16613
--HG--
extra : moz-landing-system : lando
In order to separate resume/suspend called from chrome and content side, we need to create new methods.
Differential Revision: https://phabricator.services.mozilla.com/D16612
--HG--
extra : moz-landing-system : lando
The autoplay checking for media element has 4 different phases,
1. check whether media element itself meets the autoplay condition
2. check whethr the site is in the autoplay whitelist
3. check global autoplay setting and check wether the site is in the autoplay blacklist.
4. check whether media is allowed under current blocking model (click-to-play or user-gesture-activation)
Differential Revision: https://phabricator.services.mozilla.com/D16525
--HG--
extra : moz-landing-system : lando
We would like to have different phases checking for autoplay, the first phase is to check media element itself, so we need to move other non-related checkings out from 'IsMediaElementAllowedToPlay()'.
Differential Revision: https://phabricator.services.mozilla.com/D16523
--HG--
extra : moz-landing-system : lando
Using track_id 0 is forbidden by the mp4 spec, however, some sites still serve
media using this track_id. We've been using the 0 track ID to trigger special
handling in the MoofParser where we will parse multiple tracks, and this led us
to be tolerant of tracks using this reserved id (though we likely had some bugs
due to this).
Since sites are using this track_id, and as other browsers (and Firefox until I
broke this) tolerate such media, we should too. In order to do so correctly, we
should no longer us track_id=0 as a special case in the MoofParser, and instead
have an explicit flag, which is what this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D16428
--HG--
extra : moz-landing-system : lando
For some reason that I could not figure out, usage of any https host in these getUserMedia mochitests
on Android causes a network proxy error and will, in this particular case, lead to the iframe not
loading the test page. This causes our test to timeout.
I don't think testing https here is particularly important, and so I'd rather save some
effort for myself and just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D16538
--HG--
extra : moz-landing-system : lando
`document.autoplayPolicy` returns a enum string that can change overtime based on user session activity:
- “allowed” if autoplay is currently allowed.
- “allowed-muted” if muted video autoplay is currently allowed.
- “disallowed” is autoplay is not current allowed.
Differential Revision: https://phabricator.services.mozilla.com/D11543
--HG--
extra : moz-landing-system : lando
Note, we only pass the relevant IV across the IPC boundry. I.e. if the crypto
scheme is cenc we do not pass a constant IV (this is only used by cbcs), and
only pass per sample IVs. For cbcs we do the converse. This means in the CDM
child we're only receiving one IV, which should be appropriate for whatever
scheme (this is similar to how Chromium handle IVs being passed to the CDM).
The CDM child side now writes pattern information to samples it's preparing for
CDM.
With these changes we should be passing all the information required to handle
cbcs to the CDM.
Differential Revision: https://phabricator.services.mozilla.com/D16459
--HG--
extra : moz-landing-system : lando
During review of bug 1458538, :bz noted that our event dispatching code could be
simplified by using DOMEventTargetHelper::DispatchTrustedEvent. As this was not
done during that bug, driveby fix here while we're making other changes.
Differential Revision: https://phabricator.services.mozilla.com/D14571
--HG--
extra : moz-landing-system : lando
Driveby change to bring our logging here in line with out other logging.
Depends on D14488
Differential Revision: https://phabricator.services.mozilla.com/D14489
--HG--
extra : moz-landing-system : lando
Using track_id 0 is forbidden by the mp4 spec, however, some sites still serve
media using this track_id. We've been using the 0 track ID to trigger special
handling in the MoofParser where we will parse multiple tracks, and this led us
to be tolerant of tracks using this reserved id (though we likely had some bugs
due to this).
Since sites are using this track_id, and as other browsers (and Firefox until I
broke this) tolerate such media, we should too. In order to do so correctly, we
should no longer us track_id=0 as a special case in the MoofParser, and instead
have an explicit flag, which is what this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D16428
--HG--
extra : moz-landing-system : lando
Although we don't define BUILD_ARM_NEON on aarch64 (bug 1303952), aarch64
supports NEON, so we should turn on NEON for AudioNodeEngine.
OpenMAX DL doesn't support aarch64 since we modify some codes. So FFTBlock.h
still use ARM32 only.
Also, MSVC cannot use arm_neon.h header, doesn't allow
`float32x4_t zero = {0, 0, 0, 0};` and throws compiler warning.
So we need some workarounds to use this on MSVC.
Differential Revision: https://phabricator.services.mozilla.com/D16278
--HG--
extra : moz-landing-system : lando
As setting `mSuspendCalled` is enough to prevent the stream from starting, we have no need to apply unnessary audio context operation to MSG. In addition, it can avoid incorrect AudioContext's state because of out of order resume/suspend operation (https://bugzilla.mozilla.org/show_bug.cgi?id=1285290).
Differential Revision: https://phabricator.services.mozilla.com/D15679
--HG--
extra : moz-landing-system : lando
If media element is used as a source for AudioContext, we would try to start AudioContext which was not allowed
to start when media element starts playing.
Differential Revision: https://phabricator.services.mozilla.com/D14593
--HG--
extra : moz-landing-system : lando
In order to call this method on other situations, rename it to 'StartBlockedAudioContextIfAllowed()'.
Differential Revision: https://phabricator.services.mozilla.com/D14592
--HG--
extra : moz-landing-system : lando
Processing MediaCodec output in Android binder threads while flushing
in task queue could cause race condition and leftover frames. Dispatch
the processing to task queue ensures all frames prior to flushing will
be cleared (by mDecodedData.Clear()) or ignored (by mInputInfos.Clear()).
Also consolidate all flushing operations in one task to avoid frame
insertion between emptying mDecodedData and mInputInfos.
Differential Revision: https://phabricator.services.mozilla.com/D15228
--HG--
extra : moz-landing-system : lando
Ehsan Akhgari
Jeff Muizelaar
Paul Adenot
Coroiu Cristina
Alastor Wu
John Lin
Bryce Van Dyk
Sylvestre Ledru
Johann Hofmann
Nico Grunbaum
Cosmin Sabou
Brindusan Cristian
Andreas Pehrson
David Major
Csoregi Natalia
Ryan VanderMeulen
Michael Froman
Makoto Kato
Noemi Erli
arthur.iakab