Originally we used node id from PipeWire as an unique device name and
while this works, it will change everytime PipeWire is restarted. This
has an impact on default camera selection, where for example Firefox can
automatically request a camera device that was used before, but this can
break with the next PipeWire restart.
This is a simple backport of an WebRTC upstream change.
Upstream commit: a5d71009ac1dce7da23813dc9413c03073cfa8ca
Differential Revision: https://phabricator.services.mozilla.com/D228635
Many proposals have been merged into the wasm-3.0 branch of the
WebAssembly spec repo. It currently represents the state of the art of
wasm, which we keep up with - proposals that are officially standardized
but not yet super widely implemented.
Basing our spec tests on this reduces duplication across proposal repos
and should help us catch spec problems earlier.
This patch reworks the spec test generator slightly to handle some new
module definition syntax, and removes proposals which have already been
merged into wasm-3.0.
Differential Revision: https://phabricator.services.mozilla.com/D227573
The change is preparation for Bug 1927658.
Add io-surface and dependent crates. io-surface is already audited at supply-chain/audits.toml.
Differential Revision: https://phabricator.services.mozilla.com/D227235
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
There were trivial failures in some urlbar tests due to the weather suggestions
changes that are the reason for this vendor, plus some ingest metrics changes in
this revision:
7e71b6a672
Differential Revision: https://phabricator.services.mozilla.com/D227271
We may need to teach our vendoring script how to deal with sub-repos under
libwebrtc/third_party to make this easier. However, this is how we arrive
at this import:
Our previous vendoring update to third_party/libwebrtc/third_party was in:
5350f0a3629f - Bug 1855330 - pt2 - vendor libwebrtc/third_party from build-31edcc46d68.
This was the version of third_party/libwebrtc/third_party corresponding to
Michael Froman - Bug 1867099 - Vendor libwebrtc from 5ee308b449
Do restore on moz-libwebrtc:
./mach python dom/media/webrtc/third_party_build/restore_patch_stack.py --repo-path .moz-fast-forward/moz-libwebrtc
cd .moz-fast-forward/moz-libwebrtc
git show 5ee308b449:DEPS # we want the DEPS file from the last time we vendored libwebrtc/third_party
Look for:
'src/third_party/crc32c/src':
'https://chromium.googlesource.com/external/github.com/google/crc32c.git@fa5ade41ee480003d9c5af6f43567ba22e4e17e6',
wget fa5ade41ee.tar.gz
tar xzf fa5ade41ee480003d9c5af6f43567ba22e4e17e6.tar.gz
mkdir third_party/libwebrtc/third_party/crc32c/src
mv crc32c-fa5ade41ee480003d9c5af6f43567ba22e4e17e6/* \
crc32c-fa5ade41ee480003d9c5af6f43567ba22e4e17e6/.* \
third_party/libwebrtc/third_party/crc32c/src
rmdir crc32c-fa5ade41ee480003d9c5af6f43567ba22e4e17e6
rm fa5ade41ee480003d9c5af6f43567ba22e4e17e6.tar.gz
Differential Revision: https://phabricator.services.mozilla.com/D225890
Upstream commit: https://webrtc.googlesource.com/src/+/28b793b4dd275bf2b901b87e01c0ee8d4f5732fc
[Merge-130] Fix LibvpxVp9Encoder simulcast bug.
As of [1], a single VP9 encoder instance can produce simulcast 4:2:1.
When it does, the EncodedImage has its simulcast index set (0, 1, 2).
The bug is that if you then go back to a single encoder instance,
either because you're doing singlecast or because you're doing
simulcast with scaling factors that are not power of two (not 4:2:1),
then the simulcast index which was previously set to 2 is not reset due
to the old code path never calling SetSimulcastIndex.
Example repro:
1. Send VP9 simulcast {180p, 360p, 720p}, i.e. 4:2.1.
2. Reconfigure to {180p, 360p, 540p}, i.e. no longer 4:2:1.
What should happen: all three layers are sent.
What actually happened: 180p is not sent and the 540p layer flips flops
between 180p and 540p because the EncodedImage says simulcast index is
2 for both encodings[0] and encodings[2].
The fix is a one-line change: `SetSimulcastIndex(std::nullopt)` in the
case that we don't have a `simulcast_to_svc_converter_` that sets it
(0, 1, 2) for us.
[1] https://webrtc-review.googlesource.com/c/src/+/360280
(cherry picked from commit a6fbb35ac1849c5cd823ec90121d92fc5b776b35)
Bug: chromium:370299916
Change-Id: I94ce1a0bde43ef56cba930cb69b744877bbd4bf9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363941
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#43109}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364302
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/branch-heads/6723@{#2}
Cr-Branched-From: 13e377b804f68aa9c20ea5e449666ea5248e3286-refs/heads/main@{#43019}
Upstream commit: https://webrtc.googlesource.com/src/+/dfd8f570cd069d502c2ea923256ef835971e97b5
Adds a WebRTC.DesktopCapture.Win.WgcDirtyRegionSupport UMA for diagnostic purposes.
Checks if the DirtyRegionMode property is present in GraphicsCaptureSession and logs a boolean histogram with the result.
Detecting support for this property means that the WGC API supports
dirty regions and it can be utilized to improve the capture
performance and the existing zero-herz support.
See also https://issues.chromium.org/issues/347991512 for more details
on how to detect support for dirty regions in WGC.
Bug: chromium:40259177
Change-Id: Ia316c4ece54bd93cfef1fa23c199675c64143f76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362240
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43015}
Upstream commit: https://webrtc.googlesource.com/src/+/97c594fafe3991ee0b4307516f37320ddd6ebc72
Add field trial for late PT allocation
Note: Does not include code for the actual late allocation
of PTs.
Bug: webrtc:360058654
Change-Id: Iaa6bd2db2f974aad84fe1ae9c1aca5aea5d1d25e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362320
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43014}
