In the case that cubeb is disabled we do not need to offer the dummy device on android because will leave gUM request thinking that everything is good, which will create other side effects. Also the special handling for android increases the complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3026
--HG--
extra : moz-landing-system : lando
MediaCodec products out of order buffers for some Twitch (60fps)
streams. Detecting and discarding these frames asap to make the
buffers available to codec sooner, reducing the chances of
starvation.
Differential Revision: https://phabricator.services.mozilla.com/D2977
--HG--
extra : moz-landing-system : lando
Note that right now aBuffer.Obj() will never be a cross-compartment wrapper anyway, because that can only happen when we're calling a WebIDL constructor, and this is not a constructor.
If we can't reach the outer window from the document, then also can't reach the chrome <browser> either.
Therefore, there's no point in firing the event.
Differential Revision: https://phabricator.services.mozilla.com/D2891
--HG--
extra : moz-landing-system : lando
This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
The MediaCache reads content by block of BLOCK_SIZE bytes (currently 32kB). As such, if a content being fetched is less than BLOCK_SIZE, it will always be fully read from offset = 0. We can then seek within this buffered content regardless of the underlying HTTP connection supporting request-range or not.
test_bug686942.html is ultimately testing a racy behaviour: it attempts to seek into a resource that isn't always seekable (http.js doesn't report Range -Request support for small files). The seekable range becomes then the buffered range which at the time of loadedmetadata may not be set yet.
Differential Revision: https://phabricator.services.mozilla.com/D3028
--HG--
extra : moz-landing-system : lando
Only allow top-level video document to autoplay in order to avoid autoplay from
video document which is in the iframe.
MozReview-Commit-ID: BbyjviK1BRK
--HG--
extra : rebase_source : f84421e27c6029dd3733f3c5a5d329b1755a0ee3
This is done by ensuring that all methods is called are usable off the main thread and creating the required preference accessors.
Differential Revision: https://phabricator.services.mozilla.com/D2790
Since the syntax of Accept-Range is a comma-separated list of tokens, we need to check each token to see if it's equal to "bytes".
This patch simply use nsHttp::FindToken to find the token "bytes".
--HG--
extra : rebase_source : d1a0aa4dcfad038c23d6a848cffded6f8c559864
If PeerConnection initialization terminates early due to an excpetion localIdp, and remoteIdp aren't created.
This causes another exception in close(). The patch checks that they each exist in close before attempting to
access them.
Differential Revision: https://phabricator.services.mozilla.com/D2686
--HG--
extra : moz-landing-system : lando
Summary: When removing frames from the trackbuffer we may remove frames outside the original removal interval as we must remove all frames depending on the removed frames.
Differential Revision: https://phabricator.services.mozilla.com/D2837
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This also returns to using a single convolver for processing of mono input,
which introduces complexity in up-mixing the state of the convolver when a
second channel is added.
MozReview-Commit-ID: KeBrAswQbtF
--HG--
extra : rebase_source : d793bd967e0291069e4e6cc418de53c4b4cf3253
This is done by implementing a fake cubeb backend that implements the subset of
operations we need, while offering an API to be able to control what this
backend is doing.
Because we're reimplementing the private cubeb API, it is necessary to copy
part of a cubeb internal header, and mimick exactly how the vtable mechanism to
do the dynamic dispatch to the diffferent backends in cubeb works. This is not
ideal but works.
When the cubeb API functions are called (from deep in the Gecko process), we
re-bind the call to the mock cubeb backend object and behave exactly like a
normal backend (calling various callbacks and returning fake objects).
Finally, we inject this mock cubeb backend to the running Gecko process (in lieu
of the real one that would have been picked) by setting the global sCubebBackend
variable via a private API exposed only in the test in CubebUtils.h.
MozReview-Commit-ID: 8ZbJhl7pZ2t
--HG--
extra : rebase_source : 922a03fa84803ed04aed633795a54b8d2a305e15
Also, clear the array that's been passed in before appending the new devices.
MozReview-Commit-ID: BTnwzyKBrb5
--HG--
extra : rebase_source : 23dbd11720804a30188389bc4408be4b40ad70b2
This is for testing purposes only. Defining ENABLE_SET_CUBEB_BACKEND before
including CubebUtils.h will expose the function. This is not to be set outside
of test files.
MozReview-Commit-ID: D0V8oLj9xo6
--HG--
extra : rebase_source : e80d4c01ff3b28c300de1e6819477ea732c2f157
This is slightly slower, especially if the main thread is busy, but it's cleaner
and actually safe.
MozReview-Commit-ID: 4C2FalxmE3L
--HG--
extra : rebase_source : 3f1341397bede31fcc35dab5a0cbf59b893f9b81
For an AudioCallbackDriver, the number of input channels is immutable, and
passed at construction, so that it's less necessary to rely on global state.
MozReview-Commit-ID: F9TL1H92z3W
--HG--
extra : rebase_source : 5193488592ca97273eb2b6f43d4c7a0e4beb0a33
The MSG now can feed microphone data to all its input listeners. This paves the
way for multiple input device, if we feel it's needed at some point, but does
not implement it.
The method for adding/removing inputs are also cleaned up.
MozReview-Commit-ID: 9OX4Da6Gjq2
--HG--
extra : rebase_source : 043c486e53f9220ae61fd788ed86064ba723f1a4
Add new log module which allow us to debug by using "MOZ_LOG=Autoplay:5".
MozReview-Commit-ID: 9CG5JyCw21G
--HG--
extra : rebase_source : c71c4bbed88b07a7803d93b661bfeac37cb94035
The logic here intends to (as is written in the comment) append one block of
silence to the track to allow for us to underrun one full scratch buffer.
The code doesn't match this behavior however, because if we are not underrunning
by less than a block, we end up appending *less* than a block. This causes us to
append at a later time as the scratch buffer can swallow more (up to a full
block) than we appended.
Without processing this seems to work because of timing and ordering, but
with processing (aec/agc/ns) we tend to add 71
(512 for an iteration - 441 packed) samples of silence,
leaving us to hit the assert with a 44% ((128-71)/128) chance during subsequent
iterations.
Differential Revision: https://phabricator.services.mozilla.com/D2644
--HG--
extra : moz-landing-system : lando
This results in a speed improvement of about 6% on the "Convolution reverb"
webaudio-benchmark (measured with Linux x86_64 build on Skylake).
MozReview-Commit-ID: 94W6h3qE1tB
--HG--
extra : rebase_source : f6fe4f3fa0338a90a1e389450134027d9389af09
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
In present web extension design (both Firefox and Chrome), background script can autoplay.
We don't want to break this design, so we would always allow it to autoplay.
MozReview-Commit-ID: 9BfWgll7PNx
--HG--
extra : rebase_source : 7996daa06c31a84a2aea9008daa9bddfcde98c74
When a transceiver is stopped, its mid should not be reused by a new transceiver.
Differential Revision: https://phabricator.services.mozilla.com/D2518
--HG--
extra : moz-landing-system : lando
Presumably the Rust portion of this will have to land externally first and
then be imported, but I have no idea how or where to submit it.
MozReview-Commit-ID: 2gzQbRKxaZ9
--HG--
extra : rebase_source : 582e41200e69ff3722585c7664ddd122eb0de2fe
extra : intermediate-source : e0a021b27d2c66d46ba973d66d1360678411da26
extra : source : 6d18a8bd5ee351da1a0cdfaa63f49706a2f95ba3
Presumably the Rust portion of this will have to land externally first and
then be imported, but I have no idea how or where to submit it.
MozReview-Commit-ID: 2gzQbRKxaZ9
--HG--
extra : source : 6d18a8bd5ee351da1a0cdfaa63f49706a2f95ba3
extra : histedit_source : aa7995595e2699d53f1dc60410b90cfd0d4a5c4e
Presumably the Rust portion of this will have to land externally first and
then be imported, but I have no idea how or where to submit it.
MozReview-Commit-ID: 2gzQbRKxaZ9
--HG--
extra : rebase_source : 05924114b7ff1c48ce0c4584469b3b2ef0bc26cb
Allow autoplay for video document when user is directly viewing a video/audio by visiting
its url.
MozReview-Commit-ID: GnSxx32h6hm
--HG--
extra : rebase_source : 0890f7f3e80711b35c65a6f32d7ce960de76d20e
We'd like to add telemetry to help inform the decision as to how enabling
block autoplay will affect video playback in the wild.
Our data science team would also like some input to help them estimate the
rate at which our shield study would receive pings, and the telemetry
collected here will help them estimate that.
We'd like to collect the following, on a per session basis:
* Count of the number of top level content documents loaded, as denominator for
other stats collected here.
* Count of the number of top level content documents which contained (directly
or in a descendant document) playback of an audible media element.
* Count of the number of top level content documents which contained (directly
or in a descendant document) a muted media element that was paused by the
autoplay policy because it tried to unmute and it wasn't allowed to autoplay
audibly.
* Count of the total number of audible autoplay videos that would have not been
allowed to play if block autoplay was enabled. We'd either prompt for
permission on these videos, or block outright depending on user's settings.
* Count of the total number of audible autoplay videos that would have been
allowed to play if block autoplay was enabled.
MozReview-Commit-ID: vHWJPyqHjT
--HG--
extra : rebase_source : e1f22ec83fda8b65d78f1de9f02cf060d424019c
MediaRawData is never subclassed, so it's pointless to have these
methods be virtual.
--HG--
extra : rebase_source : ef55196831f5ff96e75b46f304541e1cb8fafada
extra : source : ccef9e2643a19668dc06426aa0e55ed5d61ae535
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
--HG--
extra : rebase_source : 72ebe662f76fb6c9d8be1f753890601aac440061
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
Summary:
We've hit stack overflows while decoding, in particular for av1. This increases
the thread size for the platform decoder threads, while leaving the others at
their default values.
Reviewers: jya
Tags: #secure-revision
Bug #: 1474684
Differential Revision: https://phabricator.services.mozilla.com/D2226
--HG--
extra : rebase_source : d03a91e93910fac5458f18f43398d76b736bbee6