With block size 128, rounding `128` to end of next block gives `256`, which is
not what we want when running MSG iterations. That could mean over-iterating and
buffering unnecessary amounts of silence.
MozReview-Commit-ID: vW14l2ygRy
--HG--
extra : rebase_source : 8aeedc8958e646f9730c9163447e3355a73fd42e
Gecko only ever had de-zippering for DelayNode.delayTime. It has been decided in
[0] to remove all de-zippering, for consistency.
[0]: https://github.com/WebAudio/web-audio-api/issues/76#issuecomment-107679878
MozReview-Commit-ID: FK9Erwxth05
--HG--
extra : rebase_source : caccac28456191e68c980b12159ed310ce18e149
This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b
This is already true for the audio sources. It should be for all.
Crashtests showed that shutting down amidst the async init can lead to
double-stops. It is impossible to completely protect yourself from them without
waiting for all queued operations to resolve (results to become known) before
taking action. Doing that would require a refactor in MediaManager and cause
higher latency for device operations so it seems like the wrong way to go.
MozReview-Commit-ID: 5Cci6whzTL7
--HG--
extra : rebase_source : 18efef4e294ac2b02753721ca5813bcbf63e3111
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : 4a7e8c1217b0db3879312d4b33dc74227e969608
Post landing of bug 1193394 test_autoplay_policy_activation was failing.
This is because we weren't clicking the child frame properly in the test.
Fix the test, and re-enable.
MozReview-Commit-ID: Ius4GWIX8Ng
--HG--
extra : source : f2ef9db8bbcf8a045b6da1e7f7e283e234174401
extra : amend_source : 4e0790690f077c0b20537da131d9a9e337394112
The following tests all hardcoded a special value for Timer Precision Reduction.
browser/components/extensions/test/xpcshell/test_ext_browsingData_cookies_cache.js
browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js
browser/components/resistfingerprinting/test/mochitest/test_animation_api.html
browser/components/resistfingerprinting/test/mochitest/test_reduce_time_precision.html
devtools/client/sourceeditor/test/browser_codemirror.js
dom/animation/test/css-animations/test_animation-currenttime.html
dom/animation/test/mozilla/test_transition_finish_on_compositor.html
dom/media/test/test_video_stats_resistfingerprinting.html
dom/tests/mochitest/ajax/jquery/test_jQuery.html
netwerk/test/unit/test_race_cache_with_network.js
Of these, only test_video_stats_resistfingerprinting.html begins failing when Jitter is enabled.
So disable jitter for that test.
Additionally, dom/midi/tests/test_midi_packet_timing_sorting.html began failing
with Jitter, so we disable it there. (We could easily modify the test so it began
passing, but this would reduce the effectiveness of the test.)
MozReview-Commit-ID: 2kipxV6wYv9
--HG--
extra : rebase_source : ce8236d918eb620c5198cbe86fc726c47f5747f8
These two tests had intermittent orange failures. The logging shows
that the suspend happens but the `ended` event is never received.
Test re-written on the presumption that `ended` event is fired and
lost between checking `video.ended` and registering `ended` event in
`waitUnitEnded()`
MozReview-Commit-ID: GnAFADFOJje
--HG--
extra : rebase_source : 2e9d79e328bbc007ea4f9a7a9dce070619d9e32f
I can't for the life of me figure out how we get into the situation
where the block change list is empty here, or how we can get past some
of the existing null checks in the code, but we can at least add some
more checks to hopefully ensure we don't crash...
MozReview-Commit-ID: 168G94IyrWt
--HG--
extra : rebase_source : b6ada7bfb755ae285f0010bd6eff2e305fc5fbf0
I can't for the life of me figure out how we get into the situation
where the block change list is empty here, or how we can get past some
of the existing null checks in the code, but we can at least add some
more checks to hopefully ensure we don't crash...
MozReview-Commit-ID: 168G94IyrWt
--HG--
extra : rebase_source : 6918da94d4f42adad1978055ea49e7040e069368
Autoplay of audible media should be blocked in documents until they have a user
gesture in them, or in a same-origin parent document. This patch adds tests for
those cases.
MozReview-Commit-ID: B4FQhPOukId
--HG--
extra : rebase_source : 38d77ce42ec5f4edb0119ba2ccf03f53cd8cdb00
The logging added in this patch was landed to help debug very rare shutdown
failures on android, but the logging runs on other platforms and is annoying.
No one is looking at fixing the rare shutdown problem on Android. So remove the
logging until fixing the shutdown failure becomes a priority.
FFVPXRuntimeLinker could not handle file paths that contain characters outside the current system code page on Windows. This patch will fix it by using wide char APIs.
MozReview-Commit-ID: 9ES1xFELjDs
--HG--
extra : rebase_source : 4bdc082bd6db9263b41fe74d524e0a4d98802ea8
extra : intermediate-source : 8afa22df3893c678884e3a0811fb6c82790c1a3c
extra : source : c6f916a967a78e176bdb699a85e194bbdc372bce
If a camera returns no capabilities we interpret it as it being able to handle
any capability we throw at it. However, we also end up trying to start it with
the default capability of 0x0@0. This often works, but we can crash when
rescaling it to the chosen target capability 0x0@0.
With this patch we inject up to two default capabilities, one at 640x480@30 and
one at 1280x720@30. With constraints present we'll try to adjust these defaults
so they fit within the constraints while at the same time preserve the
aspect ratio given by prefs.
MozReview-Commit-ID: 3mr7Li5TTbV
--HG--
extra : rebase_source : c525c2fd8d60f5dece548216caefc4976e9afb0b
This will lead to less ipc calls, hopefully speeding up getUserMedia for many
devices.
This also lets us inject any hardcoded capabilities into the candidateSet in
the future (read: next patch).
MozReview-Commit-ID: HjIhRK1nVA1
--HG--
extra : rebase_source : f58e16c45f7bd6738ce0a0527dc86854f804bc7b
Remove references to the mp4parse_log() method which was
removed in this release. Instead we default to the logging
implementation provided by libgkrust.
MozReview-Commit-ID: KKzeEcB5UiP
--HG--
extra : rebase_source : 2777f13a006c09afb82772475d25245b2752524c
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
It seems reasonable to assume that when a page has been granted permission
to capture camera/microphone, the user intends it to play audible media.
MozReview-Commit-ID: 1RdsPK1vRPt
--HG--
extra : rebase_source : 688b68c29d73f117a2cc376233d664bc9cdb5d52
Not all devices have capabilities. Our code is already setup to handle that
case by defaulting to a capability with width,height,maxFPS=0 and propagating
the failure to start.
MozReview-Commit-ID: AZJKZeBrYC2
--HG--
extra : rebase_source : f1030fc97416f9b3b8e363edcbf440f6f250c749
Getting zeroes here is rare, but the numbers come from a platform API so no
guarantees are given for them. This patch makes it as permissive as possible.
MozReview-Commit-ID: 2bjPRzhk1L7
--HG--
extra : rebase_source : 0a3bf122f79d4ff69c0d471dde32d5865edbfce5
Usually, mShouldFallbackIfError has been reset to false in DataCallback()
before Stop() is called. However, if fallback to a system clock driver due to
cubeb error had already occurred, then mShouldFallbackIfError would not have
been reset, and Stop() is still called. With mShouldFallbackIfError still
true, a cubeb error in stop would have created another fallback thread.
I expect that resetting mShouldFallbackIfError in Stop() would also be an
effective alternative solution, but resetting on StateCallback() happens
earlier, which would be an advantage if any additional errors could possibly
be reported to StateCallback().
MozReview-Commit-ID: E9j7PQmS3O4
--HG--
extra : rebase_source : 200993c9e99475101c429005cfadb7260df29067
This adds back the `framerate` update that was removed in bug 1299515.
It also fixes a threading issue (not really an issue, but it broke the
documented policy) where Start() wrote to mCapability without holding mMutex.
MozReview-Commit-ID: Jda5moNhlkM
--HG--
extra : rebase_source : a8f27f064b9f818eb29aa72a18605786c474631b
Most importantly, this reduces the number of copies to 1 in the common case.
In a case where we are rescaling because there are competing gUM requests
this does two copies, where one is the crop-and-scale operation itself.
In the worst case we do two allocations, but with a buffer pool and a recycling
ImageContainer we allocate very rarely in practice.
MozReview-Commit-ID: B0Et4wZol9n
--HG--
extra : rebase_source : e0950a53278336773570c9e989a21392195f8898
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
Before bug 1299515 we assigned stream and track id in Allocate(), meaning that
any Deallocate() had a guarantee of them being set.
This changed to require an extra step of SetTrack() to assign stream and
track id. Deallocate() needs to handle this, which it does with this patch.
MozReview-Commit-ID: Js0cXXOR2Bb
--HG--
extra : rebase_source : f90dc1345ae0c034d2237d771630055729180df4
- add new component_id field to NrIceCandidatePair
- add the candidate pair component_id to RTCIceCandidatePairStats in
RecordIceStats_s
- add new column in ice stats table for component id
- sort ice stats by component id first
MozReview-Commit-ID: J89ZIYEUyRk
--HG--
extra : rebase_source : 681a5afa1303b4e377fcc14d099ce0b3d852f22c
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
I hit this during local tests. It's a fine invariant but it doesn't hold in
forced shutdown.
MozReview-Commit-ID: HtoiGwf7IMI
--HG--
extra : rebase_source : 707de2fe08ccad99a06dab00969e2f140e63abad
With the added invariant that NotifyPull() needs a MediaStreamListener present
to not underrun, we need SetPullEnabled() and AddListener() to stay in sync by
using the same signaling mechanism.
MozReview-Commit-ID: 49KWdiTOG98
--HG--
extra : rebase_source : d0ad44d7ce431aa792c4908f96baf0c0920dbe90
This modifies mediaCaptureWindowState() to say whether a camera or microphone is
actively captured or not. Note that this is not the same as the device being
on or off. If we disallow a device from being off while disabled, we still
notify chrome that we're not actively capturing.
MozReview-Commit-ID: B1taormqc3j
--HG--
extra : rebase_source : 292d323c4b9711cc242170f5c5c139bb87658c44
This wires up the disabling of a track with actually stopping the device if we
allow it.
This is possible for:
- Camera (enabled by default, controlled by pref
"media.getusermedia.camera.off_while_disabled.enabled")
- Microphone (disabled by default, controlled by pref
"media.getusermedia.microphone.off_while_disabled.enabled")
Screen-, app-, or windowsharing is not supported at this time.
On disabling, there's a delay before the device is ordered to stop. This is
now defaulting to 3 seconds but can be overriden by prefs
"media.getusermedia.camera.off_while_disabled.delay_ms" and
"media.getusermedia.microphone.off_while_disabled.delay_ms".
The delay is in place to prevent misuse by malicious sites. If a track is
re-enabled before the delay has passed, the device will not be touched until
another disable followed by the full delay happens.
MozReview-Commit-ID: D4nZWzrYZGm
--HG--
extra : rebase_source : 6a54fa450bd435ed65de2a30b66d25f4a5e8241e
This is the larger change for this bug. In order to turn off a device on
disabling we want to Stop() it without ending the attached track.
To allow this, this patch breaks out track-creation from Start() to SetTrack()
and moves track-ending logic from Stop() to Deallocate().
It is a programming error to Start() or Stop() a MediaEngineSource that hasn't
seen a SetTrack().
MozReview-Commit-ID: 3KzmuDjCAH0
--HG--
extra : rebase_source : 361d9b9c2a818ce51fa90d88950d5992c51407c6
The scope of flattening this hierarchy quickly grows large, so this patch does
a couple more things:
- Creates a pure interface MediaEngineSourceInterface and a base class
MediaEngineSource with common defaults and refcount support (no state!)
- Breaks out some of the helper classes to dedicated files, e.g.,
AllocationHandle, MediaEnginePrefs.
- Clarifies the threading model (written on one thread *and* under lock,
read under either)
- Fixes style, indentation, include-sorting in the affected files
- Adds comments, especially for clarifying what responsibilities methods have,
and thread usage of class members
- Changes Monitors to Mutexes since we only use them as Mutexes anyhow
- Makes MediaEngineRemoteVideoSource no longer a shared source since we now
support scaling in this source and CamerasChild can act as a broker of frames.
This greatly simplifies it. The only shared source is now
MediaEngineWebRTCMicrophoneSource, so the sharing specific common methods have
been moved to that source.
MozReview-Commit-ID: KeVZQo6gLm2
--HG--
rename : dom/media/webrtc/MediaEngine.h => dom/media/webrtc/MediaEnginePrefs.h
extra : rebase_source : c785a5feb896312912170475d6b8d997e712e48f