The new state is set when we're notified by cubeb (which is implemented only in
the mac backend) that it is changing output device under the hood. While the new
state is set, any audio callbacks coming in will be ignored, since there is no
guarantee that they won't come in after the DeviceChanged callback, but before
the device switch starts. A fallback driver is started, if not already running,
at the same time as setting the ChangingDevice audio stream state. The fallback
driver changes the audio stream state back to Starting in its first data
callback after a five millisecond grace period. Then handover to the audio
driver happens as it normally would: the first data callback from the audio
driver sets the audio stream state to Running, and the next fallback data
callback after that stops the fallback driver and tells the audio driver it can
drive the graph.
Differential Revision: https://phabricator.services.mozilla.com/D201195
This adds a test that notifies an audio driver of a device change and waits for
a second without making data callbacks. Then it checks that something else was
iterating the graph during the wait.
Differential Revision: https://phabricator.services.mozilla.com/D200938
WEBRTC_USE_PIPEWIRE is not defined on ppc64 or riscv64 and this will end
up calling VideoCaptureOptions::set_allow_pipewire() that doesn't exist.
Differential Revision: https://phabricator.services.mozilla.com/D201803
Fallback to V4L2 in case of a PipeWire failure. This could mean PipeWire
is not installed or not running. Also fallback to V4L2 in case camera
portal is not available or we failed to get information about available
cameras. We are not going to fallback when the camera access has been
specifically rejected or when camera portal reports there is no camera.
Differential Revision: https://phabricator.services.mozilla.com/D199858
In bug 1866020 we added a workaround for GLES incorrectly rendering
videos with smpte432 color primaries on some Pixel devices. We enabled
this workaround on affected devices when the color space had a value
of 10.
In this bug we have discovered that some affected videos may
alternatively report their color space as 65800, therefore this patch
additionally applies the workaround in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D201380
This reverts commit e25a5f344af32bdd689500bae7b4f24f205ba9f0.
We believe bug 1664063 was causing to hit some broken device reset
handling code.
Differential Revision: https://phabricator.services.mozilla.com/D201658
The change suppresses the clang-tidy warning. This patch doesn't change
the behavior in the release. However, if overflow happens, the
assertions will be triggered in nightly and beta.
Depends on D200887
Differential Revision: https://phabricator.services.mozilla.com/D201610
DAV1DDecoder is the only place using `-EAGAIN` directly. Except
DAV1DDecoder, all all other places in our code uses a macro like
`DAV1D_ERR` or `AVERROR` to negate or detect the POSIX `EAGAIN` error
code, which is a more appropriate approach to handle the error code
dynamically if the underlying macro usages in the libraries changed.
Differential Revision: https://phabricator.services.mozilla.com/D200533
HDCP 2.2 is the version which the video provide usually want to have
in order to stream 4K video securely, so we choose to display whether
the CDM supports HDCP 2.2.
Differential Revision: https://phabricator.services.mozilla.com/D201010
GVST is how these probes sent data in Fenix and is now unnecessary (and doesn't send data in Fenix release) since Firefox Desktop has direct access to Glean. We therefore need to clean them up in some capacity.
Following the recommendations from the GeckoView Streaming (GVST) validation effort, this is a pure Glean api implementation of the metrics that fell under network in geckoview streaming.
Because these were both categorical histograms, to retain previous functionality we've added parallel instrumentation in Glean.
Differential Revision: https://phabricator.services.mozilla.com/D201144
HDCP 2.2 is the version which the video provide usually want to have
in order to stream 4K video securely, so we choose to display whether
the CDM supports HDCP 2.2.
Differential Revision: https://phabricator.services.mozilla.com/D201010
When enaling the media engine playback, we would always start with using
the external state machine. Then fallback to the normal state machine if
the conditions are not met, eg. only enable encrypted media playback, or
the codec types/key system types which the media engine doesn't support.
This kind of transistion should be smooth and always succeed. If not,
then it would probably cause bad effect on the user experience, so we
add the probes to measure the error rate.
Differential Revision: https://phabricator.services.mozilla.com/D198242
When enaling the media engine playback, we would always start with using
the external state machine. Then fallback to the normal state machine if
the conditions are not met, eg. only enable encrypted media playback, or
the codec types/key system types which the media engine doesn't support.
This kind of transistion should be smooth and always succeed. If not,
then it would probably cause bad effect on the user experience, so we
add the probes to measure the error rate.
Differential Revision: https://phabricator.services.mozilla.com/D198242