Bug 1435133 introduced a new path where we block autoplay and reject the play()
promise, but we didn't fire a "pause" event. This confuses YouTube's controls.
Additionally, even if we're not in a user generated event handler, we
unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event
handler, but now if play() is called before we've reached loadedmetadata, we
reject the promise if we're not in a non-event handler and bail out early, and
so we'll bless even if not in a user generated event handler. Meaning when we
do reach loadedmetadata, we think we were in a user generated event handler
when play() was originally called, and so we won't reject the play promise.
So this patch ensures we dispatch a "pause" event when we reject the play()
promise here. The WHATWG spec says we should do this when pausing anyway.
Note: calling our interal Pause() function when rejecting the play() promise
here breaks YouTube, as if we do that we fire a "timeupdate" event. So I opted
to manually code to fire the event here instead of just calling Pause()
everywhere we want to ensure we're paused.
MozReview-Commit-ID: 1snkiTnPGih
--HG--
extra : rebase_source : 2c5ca6c0ed7c2dff2fb971cd159cfdc12a8a227f
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 03cefb8edf12b077607ae71aeb999fd0ac966674
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
This outputs to MOZ_LOG and using an MPSC lock-free queue so we can log to a
particular module from any thread.
MozReview-Commit-ID: INtlki4PEJs
--HG--
extra : rebase_source : c1d488fdd65bfa7ede12c12004921415aaaa1d55
extra : source : f9482471bbd83882f8da3f0ce929f72858abfa04
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : 17ef7f95f7205307980dd0924821b005ada06c56
extra : source : eb0a2bb44f95f195343fed284efcdd524a7bb868
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : ee6acf7d046e8ce6e18a53988a4ea308b8d4d44f
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : b4310af51efa83c6670ba4e37433f7a23a575bba
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
This outputs to MOZ_LOG and using an MPSC lock-free queue so we can log to a
particular module from any thread.
MozReview-Commit-ID: INtlki4PEJs
--HG--
extra : rebase_source : c1d488fdd65bfa7ede12c12004921415aaaa1d55
extra : source : f9482471bbd83882f8da3f0ce929f72858abfa04
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
We should not use LoadLibraryA (or more generally "A" functions) on Windows
because it is lossy. Bug 1440886 will introduce a static analysis to prevent
potential misuse of LoadLibraryA, so we need to replace existing usages first.
MozReview-Commit-ID: 6krgrVcSHNW
--HG--
extra : rebase_source : 0e93acecfe0c9ccd2e4ba9ad3126b6ae16433387
Returning UniquePtr is nicer than returning raw pointers, and has the
nice side effect of forcing us to clean up the uses of nsAutoPtr that
were hanging about.
This will resolve several intermittments that were occuring because we would
occasionally get unlucky and have a jitter midpoint of 0, making an unstarted
AudioContext report a CurrentTime of 100us (or 1ms - whatever our clamp value
was.)
MozReview-Commit-ID: 45zXLbB93wP
--HG--
extra : rebase_source : 23ea5964dc49543c2b4ca45890c4c08456e75c73
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : 652d311cb69e6c3ed3b1ba91719e79acb0a4bb9c
The documentation says that the boolean return values from these methods
must be checked. We might as well make the compiler check these things
for us.
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : d6a68579e76f1eda651e38bec5a9ed17c9de3fa4
We don't want to skip all remaining steps. For now it just affects some logging,
but there may be new ones added in the future.
MozReview-Commit-ID: 7fBdgLNT780
--HG--
extra : rebase_source : dc5113298c1dbadd23c19127349a4a66cd460b4c
Test that play() on a media without audio called before
readyState >= HAVE_METADATA will still play.
MozReview-Commit-ID: 1FeDrEfCEum
--HG--
extra : rebase_source : be6d07905aad853ad028eac372e4e380bdeb1a49
extra : source : e98b4a7aaf020fa3d6d59cb0f53680ef6466d154
We have code in the MDSM to toggle on high resolution timers on Windows when we
start/stop playing because the VideoSink relies on being awoken by timers to
update the set of current frames in the compositor's queue, and on Windows 7 we
end up dropping frames due to the timer lag without this.
We assert in the MDSM's destructor that we've turned off high res timers (as
they cause needless battery drain, so we only want them on when we need them),
and the new test_mediarecorder_principals is hitting that assert on Windows. I
think we're missing turning them off when we create a new VideoSink for
outputting to the MSG. That affects the value returned by
MediaDecoderStateMachine->mVideoSink->IsPlaying(), which is what we use to
decide whether we should enable high resolution timers. We track whether we've
enabled high res timers in MDSM::mHiResTimersRequested, and that gets out of
sync with IsPlaying() when we re-create the MediaSink.
Rather than trying to handle all the permutations of places where we need to
turn off high resolution timers in the MDSM, we're better to move the code to
toggle high res timers into the VideoSink, as that's actually where we need to
be sure that we have high resolution timers enabled anyway. It's the VideoSink
after all that is relying on timers for frame update, not the MDSM.
Also remove the media.hi-res-timers.enabled pref, as we haven't needed it.
MozReview-Commit-ID: 9dNxcYxPDZH
--HG--
extra : rebase_source : 6e403d59bb5f1dd0241fe8298a823ba08b1670fb
I changed this test earlier in this set of commits to use
midflight-redirect.sjs so that we get more reliable and predictable cross
origin redirects during the download. Unfortunately this test now times out on
Windows.
This test times out on Windows because midflight-redirect.sjs redirects at 1/4
through the resource, whereas this test expects to be able to play through to
1/5 through the resource, and on Windows that seems to be not reached during
playback. This is likely due to decode latency being higher on Windows.
On top of that, the test's first case can sometimes call MediaRecorder.start()
before the redirect has happened, and before the principal has changed, and so
start() doesn't throw a SecurityError as expected, and the test intermittently
fails.
Additionally, the test's code could be clearer if we used async/await.
So rewrite the test to use async/await, and take advantage of
midflight-redirect.sjs's redirect being more predictable than the old
dynamic_redirect.sjs. Basically, we can be careful to wait for either
"loadedmetadata" or "error" on the media element in order to be more confident
the redirect has or hasn't happened yet.
We still can't be 100% sure that the redirect won't have already happened by
the time our "loadedmetadata" handlers run. It's quite possible that the
download has reached 1/4 through the resource by the time the loadedmetadata
handler has run, so we need to handle the "error" and "loadedmetadata" events
racing.
MozReview-Commit-ID: 8plMjkXgjYt
--HG--
extra : rebase_source : 7305598f40c09219494f3e7150799d8875b7c30e
I'm seeing intermittent failures of test_midflight_redirect_blocked. In this
test, our custom server responds to Firefox's 0- HTTP Byte Range request with a
[0,200] response. When Firefox requests 200-, the server responds with a cross
origin redirect, and then the remainder of the resource.
However sometimes while running test_midflight_redirect_blocked the MP4 demuxer
reads through all 200 bytes while trying to parse metadata before the redirect
has occurred and fed more data into the cache, and so the demuxer thinks it's
hit end of stream, and reports a failure. The demuxer thinks it's hit end of
stream, because we initialize the MediaCacheStream length in
ChannelMediaResource::Open() with the value of the Content-Length HTTP header.
But in an HTTP byte range response, the Content-Length header tells you the
length of the range returned, not the length of the entire resource. The length
of the resource is in the Content-Range header, we need to use that if
available.
So to fix this intermittent test failure, we need to also parse the
Content-Range header in ChannelMediaResource::Open(), and use the length from
that if available.
MozReview-Commit-ID: 29pPRsUvxag
--HG--
extra : rebase_source : ba1ef03d65ebd22698a29d8385f36b4c747ccf43
Problems here:
* The variable `to` is undefined for byte range requests to the end of
the resource, making the math fail. Firefox normally makes ranges requests like
this.
* The bytes.length/4 calculation may not be a whole number, so can
result in a byte range header part of the way between two bytes. We need to
round the length off.
* Instead of re-calculating the contentLength, we can just use the length of
the actual byterange substring being returned. That's clearer.
* test_midflight_redirect_blocked needs the redirect to happen
before metadata has completed loading, but other tests require the redirect to
happen *after* metadata is loaded. So add a redirectAt query parameter for the
requester to control when to redirect.
MozReview-Commit-ID: I6n1NqK0Uze
--HG--
extra : rebase_source : a6bd68fe75cfd4c46f63ca815c5a4e9390bd671a
We have two SJS files; midflight-redirect.sjs and dynamic_redirect.sjs,
which are very similar, but dynamic_redirect.sjs is buggy, so we should
just use midflight-redirect.sjs.
dynamic_redirect.sjs is buggy because it relies on the client doing multiple
HTTP requests to it in order to redirect, but we can't actually guarantee
this. Previously users of it would try things like setting a small MediaCache
size, or only using Ogg for which we expect a seek to the end to calculate
the duration, but I have observed the entire resource being downloaded in
one hit before the media element has finished loading metadata, meaning the
seek (in the Ogg case) can happen without another HTTP request. This is even
with a small MediaCache.
midfligh-redirect.sjs solves this problem by explicitly only returning a
partial response, so the client is forced to make another HTTP request,
which we will serve a redirect to.
MozReview-Commit-ID: 39imyayhnBG
--HG--
extra : rebase_source : 603532e4af0bf304c34739de5b0b243174e3831d
The original test is failing, as it assumed we'd not error when
origins were mixed without CORS, and the original test was using
outdated practises, so rewrite it.
MozReview-Commit-ID: KlOH83GUOk
--HG--
extra : rebase_source : 2c79691fddc93af0e04d8f23fa31ac8588a8d6e1
extra : amend_source : 2989317530f536915f011977c8f34e048410b018
Try to prevent Necko from caching the results of our SJS media responses, as
some of the test that use it rely on the server being hit and serving a
redirect. Sometimes the tests which rely on hitting a redirect in an SJS
where timing out without this, as Necko would cache the response and not
hit the server, and so not hit the redirect.
Also include a noise parameter to increase the likelihood that the URL is
unique, to further reduce the chance that Necko caches the result.
MozReview-Commit-ID: 3cLEiDoh4HG
--HG--
extra : rebase_source : 24c152d46540866f14211fae30f1e59c5d23b6d4
dynamic_redirect.sjs and midflight-redirect.sjs are serving files
with "Content-Type: video/ogg", which is incorrect and could lead
to problems given that we're not always asking it to serve Ogg
files. So include the type be to served as a query parameter.
MozReview-Commit-ID: 5f0PXy8lL3G
--HG--
extra : rebase_source : 757395a21317655422767efe3f7c1923a19c0114
Test that playback works if we don't block, doesn't if we do block, and does
if we do block and CORS is used.
MozReview-Commit-ID: 9PTZXLOdHIU
--HG--
extra : rebase_source : db7f0c61b64990623ef035b266cf052c45df1c76
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : a2f4b7c68b73ecc4c7525d4e41e834f4caf85707
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : f0784c0c5b2e39d2078a5aff72be03b52e413139
extra : intermediate-source : 635153e1dcdc442f8d72727b6fe504842b4ffa31
extra : source : bf011140459cc227c9435e3960770bafb3cecb8e
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
This creates a simulcast stream with an odd resolution. This previously would
have caused a runtime assertion failure and crash.
MozReview-Commit-ID: IsywVOu6UeV
--HG--
extra : rebase_source : 7ad1cbe7dd36ccdd7a05e0c0a83db98a36c8c416
The CanCallerAccess check in the "webidl" version of
nsGlobalWindowOuter::AddEventListener was pointless, because bindings never
call things on outer windows.
MozReview-Commit-ID: 1CGMJ277bPu
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
The code relied on a flag to be set to simply abort. However, that made the code workflow hard to read.
We split each runs so that there's no ambiguity.
MozReview-Commit-ID: LI7pL5p69zu
--HG--
extra : rebase_source : 6c912edf87c13fc6b10a9be6bd57d4ffbf1dfc39
Benchmark had never been intended to be able to process invalid content. However over time Benchmark class has been used extensively by the fuzzing team.
As such, it became necessary to handle errors of all kind.
MozReview-Commit-ID: E0YulHuoiq2
--HG--
extra : rebase_source : a8c5bf2e05d5b4e9c89723cb1e0d71e61f17d501
This allows static analysis to pass for AudioNodeExternalInputStream.cpp.
MozReview-Commit-ID: 9dvllnnODed
--HG--
extra : rebase_source : 0c7665a3240422d52b82c5c2eaa4942be522dcb9
When this test times out, one of the two videos in parallel takes
minutes to start.
MozReview-Commit-ID: AhXsQKDKwOD
--HG--
extra : rebase_source : 3d42329967204c201b9e882b13dafc3149247c79
Add two mochitests to provide coverage for getUserMedia when getting a cubeb
context fails.
- The first test checks that gUM fails with no audio devices returned. In normal
circumstances, without cubeb we do not expect devices to be available. Android
is a notable exception here, due to it having a number of different code paths
during enumaration, and the test attempts to accomodate this.
- The second test checks that if fake streams are enabled, gUM will still return
a stream and that this stream can be used.
MozReview-Commit-ID: Fn6rGi6W9hM
--HG--
extra : rebase_source : b22ccc11cb034242f1a8807cfcae05f5ac2daa05
Add a hidden pref, media.cubeb.force_null_context, that will force CubebUtils
to return a nullptr when asked for the cubeb context. This is to enable testing
of components, simulating the case cubeb were to fail.
MozReview-Commit-ID: Kd9Ksu0GfQJ
--HG--
extra : rebase_source : 0ac7837105dc1005dbd3b02f8768fb3ebf55c11e
Update head.js so that calls to the gUM helper will check the loopback and fake
device prefs and update the frequency output by test devices accordingly. This
should hopefully avoid issues where tests could change prefs, and the output
tone would no longer be correct for the new configuration.
No longer have audioDevice and videoDevice as globals, this way tests
explicitly fetch direct from prefs.
MozReview-Commit-ID: 9jhVScaBfTX
--HG--
extra : rebase_source : 64b17e44ef166983361f94cf7d287faed3c2cdc5
Update the DeviceEnumerationType enum to scoped style enum for safety and
consistency. Add extra logging to aid in debugging test issues.
MozReview-Commit-ID: cm5bdlIcEG
--HG--
extra : rebase_source : bfcae3d49f809edfd0ed6ab3e516b8be0c0d517e
Update head.js so that logic for fake audio and fake video is more granular.
Now code handles fake audio and fake video separately, and will set the fake
pref is either is needed. This allows for a single loopback device to be set
and fake used for the other. Previously both devices needed to be loopback or
fakes would be used.
MozReview-Commit-ID: K4blmPrSVeh
--HG--
extra : rebase_source : 369ea7f788d29a02db68e517d324977f251c9a98
With changes giving loopback devices higher precedence in testing, various tests
in dom/media/tests/mochitest have been updated to accommodate this. Many tests
just worked, but some require tweaks, or to explicitly request fake devices.
Also update webaudio's test_mediaStreamAudioSourceNodeGC test to explicitly use
fake devices. This test does not have the loopback tone exposed to it in JS, so
is unabel to adjust the loopback tone to suit its needs.
Various tests are updated to set fake device prefs instead of requesting via
gUM to move away from non-standard behaviour per bug 1436424.
MozReview-Commit-ID: 5GAVZFzF2hq
--HG--
extra : rebase_source : 27f39e3573eda321025ce0739e1d5f4101fc5d12
This changeset adds a gUM_support.js to dom/media/test/. This file provides
functions to setup prefs for loopback or fake device selection before gUM calls
are made. This is useful for configuring tests and providing an explicit point
of reference for settings, rather than the implicit ones provided by the
harness.
Updates tests so that the new helper functions are called before gUM. This
will result in loopback prefs being set if loopback device names are detected,
if not then fake devices will be used. This also removes the use of the fake
constraint in gUM calls.
Update touched tests to use some more modern JS. No behavioural changes were
made (except in minor cases, but functionality should be the same). These
changes are largely as follows:
- var -> let
- async is used in places where I felt it improved readability
- semicolons added to various event handler assignments
MozReview-Commit-ID: 1HuE8thBA6w
--HG--
extra : rebase_source : b866056b2821436cf34ea683421c200b4bb4e55f
Change the media manager so that if fake and loopback devices are requested,
loopback is preferred. With this change loopback and fake devices can also be
mixed. Since the fake flag is coarse, and does not specify fake audio or video,
we would previously just make everything fake. As loopback sets flags for video
and audio separately, we can now request a single loopback device, while also
setting the fake flag to get a mix. E.g. if we request a loopback audio device,
and set the fake flag, we should get loopback audio and fake video.
This change also attempts to somewhat consolidate where these settings take
place. Previously, EnumerateRawDevices did much of the loopback setup. However,
other steps around fingerprint resistance or fake devices were done in earlier
functions (EnumerateDevices and GetUserMedia). This changeset moves the loopback
setup so that it's more consolidated with the other setup code in these
functions.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 374a6fd0842a430e27c695bcf956e2e072a77fc3
Prior to this patch various bools are used to track if we requst fake or
loopback devices during enumeration. However, since the normal, fake, and
loopback cases are mutually exclusive, a enum can be used. This provides allows
for having descriptive enum values in code and makes clear that the settings are
mutually exclusive.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 498513bdc6673fa299080097364a6d0dff00a073
Stop us potentially keeping a stale device list when updating if we can't get a
cubeb context.
MozReview-Commit-ID: H6GdeNXObWV
--HG--
extra : rebase_source : 48fce949627fa17402336db824374847e1b439e6
Add logging to aid in debugging of our EME ADTS conversion path.
MozReview-Commit-ID: A7Wv8n31V8V
--HG--
extra : rebase_source : 13f20179aa29180047a37a127029d0e28a1c4f80
Update EMEDecoderModule to use 2 as profile number when the given profile is
less than 1 or greater than 4. The CDM doesn't appear to care what values are
given, but 2 was chosen as a safe fallback per discussion on the bug. This
addresses the use case where 0 values are stored in mProfile due to the use of
extended profiles (which are then stored in the mExtendedProfile field).
MozReview-Commit-ID: 5XgabNDsgdf
--HG--
extra : rebase_source : dd66a872aaac2acf4af55f06d3c24f53debe4e63
This prevent potential division by zero should the cast on the argument cause an overflow.
We still limit the mul and div arguments to INT64_MAX.
MozReview-Commit-ID: gHkv6m4zq0
--HG--
extra : rebase_source : 1c27f9a2ecc4c8bf6a763dedf2859e64bf79ea85
Disable time jittering when comparing different AudioContexts because they might look
different.
MozReview-Commit-ID: A3neLqokQ5c
--HG--
extra : rebase_source : b275942db06d3bb8e80bdb6ed5f94299636d1a8f
Apple layout standard has a 1:1 equivalence with the WAVE standard. As such, any streams under 18 channels, properly defining a channel layout, should play on all platform.
Otherwise, as Opus and Vorbis, the result will be platform dependent.
MozReview-Commit-ID: ID6b9u2UNQr
Under 8 channels, the audio will be reordered so it can be playable on any platforms.
Over 8 channels, the channels will be as output by the decoder. Playing of such stream will be platform dependent as neither Opus nor Vorbis define a channel layout with more than 8 channels.
With WebAudio however, the result will be platform independent (as long as you don't attempt to play it)
MozReview-Commit-ID: 93ATiKm9y20
This will allow to create an AudioConfig with an unknown or unsupported channel layout, defaulting instead to the number of channels.
MozReview-Commit-ID: IonLuo9q2a5
If a channel layout is unsupported, the AudioConverter will instead just use the channel count information to leave the data as-is, only trimming extra channels, or inserting silence if needed.
MozReview-Commit-ID: CXOjcSRsRwI
Instead we place it at 32.
Future changes will change the meaning of this limit to when we can deal with channel layout. If outside that limit the audio will be played on a best attempt basis.
MozReview-Commit-ID: EavmmcxjLI0
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
That ChannelLayout uses an AutoTArray internally makes XPCOM report them as leaking when declared as static.
They weren't use outside of ChannelLayout anyway so they can be removed.
MozReview-Commit-ID: KVqdjzvL8pr
It makes no sense to have a case for those as the data structure used (a bitmask) do not allow to represent this channel layout (a channel can only be present once). As such it was a non-functional layout
MozReview-Commit-ID: FjA0fojFcJp
This makes it for future easier conversion for the FFmpeg and Windows WMF decoder, so that we can use their channel map directly.
Also introduce a difference between 2F2 and QUAD, cubeb supports will be added in a future change.
MozReview-Commit-ID: L5NkjeuGslI
Change AudioCallbackDriver::Init() to fallback to a system clock driver if a
cubeb context can not be obtained. This should make driver init more robust in
cases where cubeb init fails and then CubebUtils::GetCubebContext() returns no
context.
MozReview-Commit-ID: IlFPytYacoI
--HG--
extra : rebase_source : 7445ceb49583ee3ae399252e995ce6f012d9da2f
Add logging was added to help diagnose gUM failures and provide more log
coverage of that code path.
MozReview-Commit-ID: A76fjlUVpmn
--HG--
extra : rebase_source : 6f67ab223739474c8dec7a72a1ff322503c4df96
This fixes these two errors:
FileMediaResource.cpp:30:36: error: invalid use of incomplete type ‘class mozilla::AbstractThread’
mCallback->AbstractMainThread()->Dispatch(
MediaTimer.cpp:50:3: error: ‘Unused’ was not declared in this scope
Unused << rv;
MozReview-Commit-ID: WkPZc22dMF
--HG--
extra : rebase_source : 5704eb8bb36398be7aabaded9284b4f7263ef477
Like the other media.cubeb.* prefs, it doesn't need to be a VarCache pref.
MozReview-Commit-ID: A2L8Tf3GAt
--HG--
extra : rebase_source : 86791123613c2f21e4a771c99cb079125495dec3
Test that playback works if we don't block, doesn't if we do block, and does
if we do block and CORS is used.
MozReview-Commit-ID: 9PTZXLOdHIU
--HG--
extra : rebase_source : 9071542f9deb36063aa0de3386a75bc0ad111d20
There's no compelling use case for mid-flight redirects, and Chrome
already blocks it, so there's little point in maintaining it.
Add a hidden pref to toggle blocking, so we can toggle it off during
testing to ensure that we're blocking a working mid-flight redirect.
MozReview-Commit-ID: EnGNmYFr8Uv
--HG--
extra : rebase_source : 3ed71273da24f8f0c8bc24ceede49afa7775650d
Spec: https://webaudio.github.io/web-audio-api/#dom-audionode-channelcount
Google has written a web platform test this is going to be merged soon (we
currently fail it).
MozReview-Commit-ID: 1RpASaIJrhm
--HG--
extra : rebase_source : 42dc8af6e677831d70e84ffc23e738d49549c59d
extra : amend_source : b4c30805157bd9bfd06afdfc8f439fe8de1b6aae
extra : source : e7b5b629fb30c4c8b8708979e926029f4e743420
