Upstream commit: https://webrtc.googlesource.com/src/+/edb9cf3de081106e3327a65c32fd0b3bb3c04998
Cleanup ReportBlockData accessors
Remove deprecated accessors returning time as raw int
Add setters for all fields to simplify usage of this class in tests
Remove unused min/max RTT fields
Bug: webrtc:13757
Change-Id: Ia8966975c15b9a930f54b4db0fc75f7002dcffe1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304461
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40013}
Upstream commit: https://webrtc.googlesource.com/src/+/c8c4a282a666f7462cdd1b4f72635334d5ec37b4
Introduce support for video packet batching.
This CL introduces a new feature enabling video packet send batches.
The feature is enabled via
PeerConnectionInterface
::RTCConfiguration
::MediaConfig
::enable_send_packet_batching.
PacketOptions have been augmented with attribute "batchable" (set for
all video packets) and attribute "last_packet_in_batch" which gives
injected AsyncPacketSockets a chance to understand when a batch begins
and ends.
When the feature is on, packets are collected in RtpSenderEgress. On
reception of OnBatchComplete from PacingController, RtpSenderEgress
sends the collected batch, setting "last_packet_in_batch" to true
in the last packet.
Bug: chromium:1439830
Change-Id: I1846b9d4a8a0efd227d617691213a2e048bdc8a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303720
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40012}
Upstream commit: https://webrtc.googlesource.com/src/+/cb838e2c4e92cf069ba55d4067214bf7f0fc6d59
Move packets into RtpRtcpInterface and RtpSenderEgress.
This CL prepares for send packet batching support in later CLs.
Bug: chromium:1439830
Change-Id: I0bbecfa895aa6d4317ef8049b3789272a440d032
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304282
Auto-Submit: Markus Handell <handellm@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40009}
Upstream commit: https://webrtc.googlesource.com/src/+/0df40d1d14be4a92f0a9e94a186401d0b0b267b8
RSP2: Rename `delay_counter_` -> `oneway_delay_counter_`
There is a lot of different delays tracked by this class. Renaming this
member clarifies what delay it actually tracks.
Bug: webrtc:15085
Change-Id: I8b038ecf84ca262efdc9f69c0f9a2a9eaad81d37
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304402
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40007}
Upstream commit: https://webrtc.googlesource.com/src/+/f66b9f5efe1d10099d8ad1a41fb42476b68dbda6
In RtcpTransceiver pass ReportBlockData instead of rtcp::ReportBlock
rtcp::ReportBlock class is designed for serialization while
ReportBlockData designed for passing report block information across
multiple components.
This slightly reduce how RtcpTransceiver and RtcpReceiver interact with other webrtc components
Bug: webrtc:8239
Change-Id: I582e3d7b32dc6357954b29a1def37e2e72116a74
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304285
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40006}
Upstream commit: https://webrtc.googlesource.com/src/+/9ffd697a88862cde59eaf67d2517571c547e4431
Add killswitch for RTX receive stats
guarding the change in receive stats behind the
WebRTC-Stats-RtxReceiveStats
field trial which acts as a killswitch.
BUG=webrtc:15096
Change-Id: I475a2ce4fe4bddd454aa6477f8818384696c007b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304160
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40005}
Upstream commit: https://webrtc.googlesource.com/src/+/9dfb531f382d61f7e647b82373818034e3e79ad8
Move deprecated Receiver to modules/video_coding/deprecated/
This move further clarifies that the file and its class are deprecated. It also cleans up the modules/video_coding root folder a bit.
No functional changes are intended.
Bug: webrtc:14876
Change-Id: I580e8412d379931bfdf9517e0a8be25c19e0cd32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304100
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40004}
Upstream commit: https://webrtc.googlesource.com/src/+/00ff2bb36a9b7f7fdde606598b64b0af6584af74
Cleanup usasge of ReportBlockData::report_block accessor in audio
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: I751c7fae1b0285eccdff6e0fe85c8e1ea7d7362c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304280
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39992}
Upstream commit: https://webrtc.googlesource.com/src/+/ea33f7f6a3ec68b95ff6a5fae3f861524b3116c1
Cleanup usasge of ReportBlockData::report_block accessor
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: Ia46a2516e26453724eed2e499f475f65df6cd3fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304163
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39990}
Upstream commit: https://webrtc.googlesource.com/src/+/d5b51674a1885f3f89eee7fecac4e74f20d5cd93
Cleanup usasge of ReportBlockData::report_block accessor in pc/
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: I93874c4f54cf62af0c16ae26e2231b8fb49f195d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304161
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39985}
We cherry-picked this in Bug 1828065.
Upstream commit: https://webrtc.googlesource.com/src/+/adf55790b6ecf50c4bb2b2cf7d58441303b9d946
In DeviceInfoDS free the frame duration list after use
Per the docs, the caller is responsible for freeing the memory.
Bug: chromium:1441804
Change-Id: I9aaae493a1a86d8ab4f03930715a643a3c9fb61b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304061
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39983}
We cherry-picked this in Bug 1810949.
Upstream commit: https://webrtc.googlesource.com/src/+/91d5fc2ed6ef347d90182868320267d45cf9525b
Support more pixel formats in v4l2 camera backend
These were tested with gstreamer and v4l2loopback, example setup:
$ sudo v4l2loopback-ctl add -n BGRA 10
$ gst-launch-1.0 videotestsrc pattern=smpte-rp-219 ! \
video/x-raw,format=BGRA ! v4l2sink device=/dev/video10 > /dev/null &
Then conversion was confirmed with video_loopback:
$ ./video_loopback --capture_device_index=3 --logs 2>&1 | grep -i \
capture
Bug: webrtc:14830
Change-Id: I35c8e453cf7f9a2923935b0ad82477a3144e8c12
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291532
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39979}
We cherry-picked this in Bug 1810949.
Upstream commit: https://webrtc.googlesource.com/src/+/32b64e895c0231fe6891a8f6335d66f1dad4f1f5
Improve ergonomics of dealing with pixel formats in v4l2 camera backend
Bug: webrtc:14830
Change-Id: Ib49bf65895fe008e75223abb03867d412c1b5a60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291531
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39976}
Upstream commit: https://webrtc.googlesource.com/src/+/d3eddff30ca7442f16617f392af6a000c26797e2
In ReportBlockData expose RTCP report block properties directly
These accessors would allow to deprecated report_block() accessor and
then would allow to remove redundant RTCPReportBlock and ReportBlock types converging on single
ReportBlockData type to pass that information across WebRTC components
helpers like fraction_lost() and jitter() would also allow to unify conversion of the rtp specific format into more common way of represent such information
Bug: None
Change-Id: I3c97f96affcf83b529095899bd63af007f8b4014
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303880
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39975}
Upstream commit: https://webrtc.googlesource.com/src/+/b03c4a5437f57435167df1804e36148ad32d88bb
Define enable_safe_libcxx in build_overrides/build.gni.
enable_safe_libcxx will be overridable by projects that embed Chrome's
//build using the build_overrides mechanism. All downstream projects
will need to define this new variable so Chrome can stop conditionally
defining enable_safe_libcxx upstream.
Bug: chromium:1385662
Change-Id: I62e8cf7988b76eed48c95c4993f4aea73a164bc7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293981
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39974}
We cherry-picked this in Bug 1810949.
Upstream commit: https://webrtc.googlesource.com/src/+/b1a174041ddf3057f5d6d2f87affa0f11f9413df
Relax VideoCaptureImpl::IncomingFrame size check
When testing manually with gstreamer and v4l2loopback, the incoming
buffer is often larger than the expected size. This change allows
such frames, while still logging the error.
Bug: webrtc:14830
Change-Id: I399aa55af6437d75b50830166a667547f6d144d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291530
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39972}
Upstream commit: https://webrtc.googlesource.com/src/+/8856410b6d54b546bdb3185587474f0f9b3a7c2e
pipewire capturer: Reduce the amount of copying
Improves the capture latency by reducing the amount of
copying needed from the frame. We keep track of the
damaged region of previous frame and union it with
the damaged region of this frame and only copy this
union of the frame over. X11 capturer already has
such synchronization in place.
The change is beneficial especially when there are
small changes on the screen (e.g. clock ticking).
For a 4k screen with 128 cores, I observed the
capture latencies drop from 5 - 8 ms to 0 ms when the
system is left idle. This is in line with the X11
capturer.
Bug: chromium:1291247
Change-Id: Iffb441f9e1902d2658031f5f35b5372ee8e94073
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39968}
Upstream commit: https://webrtc.googlesource.com/src/+/096427e494c6845848733b7605b125ea518ca813
Overwrite frame seq nums when piping encoded frames between RTPReceivers
This allows encoded frames to be written to any encoded insertable
streams writer without needing to somehow set valid RTP sequence
numbers. Assumes streams are using the Dependency Descriptor header ext.
A short term fix while we discuss whether we can remove the sequence
number check in RtpFrameReferenceFinder::ManageFrame.
Bug: chromium:1439799
Change-Id: I3c1d83793cd8b6cae2a8ad2129b3b6daab1d11c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302301
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39966}
Upstream commit: https://webrtc.googlesource.com/src/+/aee5b17f669341d9af03ab4dc15b38382f423628
DecodeSynchronizer: avoid duplicate tick callback registration.
With repeated CreateSynchronizedFrameScheduler/Stop calls, the
DecodeSynchronizer can register & keep multiple callbacks in
the metronome. Fix this to only keep at most one callback
installed.
Fixed: chromium:1434747
Change-Id: I61f67a871339dbcc7560e9d545a5217f361a9b87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303840
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39964}
Upstream commit: https://webrtc.googlesource.com/src/+/272b464e92d08d5abe36af5542f53bd6a82252c5
Allow feeding a Receiver encoded videoframe into a Sender Transform
Instead of crashing with a CHECK fail when an insertable stream of a
Video RTPSender is given a frame from an RTPReceiver's insertable
stream, construct a reasonable analogous sender frame and pass it
through to be decoded.
A small step towards removing the split we have between Sender and
Receiver implementations of TransformableFrameInterface which just
confuses users of the API.
Counterpart to https://webrtc-review.googlesource.com/c/src/+/301181 in
the opposite direction.
Bug: chromium:1250638
Change-Id: If66da7d553f14979ff1c5b4e00bff715f58cfce0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303480
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#39963}
Upstream commit: https://webrtc.googlesource.com/src/+/df4bc33e11df9bcc188195e3b779247c7851883c
Allow EglBase instances to share EGLConnection.
This enables clients of EglBase to keep using it but
share underlying EGLContext with other clients.
go/meet-android-eglcontext-reduction
Bug: b/225229697
Change-Id: I42719f25be7db169c39878b57a5f1487e3c1894e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301941
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39961}
Upstream commit: https://webrtc.googlesource.com/src/+/2b72d847332315f8f8007adb26ab9eb22f5b5eac
stats: fix type of inbound-rtp frames_received
which gets assigned from a uint32_t VideoReceiverInfo::frames_received so should remain an unsigned type
BUG=None
Change-Id: I1db6a3f96c4ff49eee72dcce54eb6fff346c128c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302342
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39958}
Upstream commit: https://webrtc.googlesource.com/src/+/2bd878180addfa325a657588ab6afca30c77aad3
Add delayed packet outage event metric.
Can be used to calculate the average delayed packet outage duration and
number of packet loss events by subtracting from concealment events.
Only used in simulations currently.
Bug: None
Change-Id: I03740a2bcb781af09e28a4d13d9e41c0f84bc506
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303600
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39957}
Upstream commit: https://webrtc.googlesource.com/src/+/ecdedac3dabbbc0345e5a0f98bc2063cd38d236f
Remove NetEq simulation step size restriction.
This should not be relevant anymore and is causing some issues due to
SetMinimumDelay events early in the log.
Bug: None
Change-Id: Ib7e3c624608c9bceaed31bd6669db59887d24659
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303580
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39956}
Upstream commit: https://webrtc.googlesource.com/src/+/17d7eb4d52e847019b7d4bca137afc61fe67ffe4
Do not compile some test targets with chromium
Move copy_to_file_audio_capturer, copy_to_file_audio_capturer_unittest
and test_common under "!build_with_chromium"
Bug: b/272350185, webrtc:15081
Change-Id: Ie3f08e4ce5bec91647e802cc34040df2e01103d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303680
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39954}
We cherry-picked this in Bug 1694304.
Upstream commit: https://webrtc.googlesource.com/src/+/28ac56a415a7513f1ebfb985659bf2012d84df3f
In VideoCaptureDS::Stop() fully stop the device
This makes the device light turn off when stopped.
Bug: webrtc:15109
Change-Id: I1deecbc2463e2e316e01ff1f061ab6b0313c1aa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302200
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39953}
This small change we've been carrying to when ProcessPendingXEvents is called
in WindowCapturerLinux::Capture should not be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D185449
Despite some files being under `third_party`, it's our files, that we can
modify.
We want to include codec headers using `<>` and not `""` because angle bracket
includes from `dist/system_wrappers` and not `dist/include`. The former location
wraps the include in a way that makes the symbols have a default visibility,
while the latter hides the symbol. Because those codecs have been moved to a
different shared library, we need their symbols exported.
Differential Revision: https://phabricator.services.mozilla.com/D176158
Despite some files being under `third_party`, it's our files, that we can
modify.
We want to include codec headers using `<>` and not `""` because angle bracket
includes from `dist/system_wrappers` and not `dist/include`. The former location
wraps the include in a way that makes the symbols have a default visibility,
while the latter hides the symbol. Because those codecs have been moved to a
different shared library, we need their symbols exported.
Differential Revision: https://phabricator.services.mozilla.com/D176158
ManifestParser will read TOML files, if present, when use_toml=True
Added tomlkit as a third_party python package
Added poetry-core and tomlkit to pypi (separately as Bug 1845383, Bug 1844787)
Adds TOML test coverage
Adds tomlkit as a dependency of mozharness (in test_archive.py)
Added tomlkit to virtualenv_modules in testing/mozharness/configs/unittests
Removes dependency on six
testing/tools/mach_test_package_initialize.py
- Corrected SEARCH_PATHS
testing/mozharness/mozharness/mozilla/testing/per_test_base.py
- moved `from manifestparser import TestManifest` into function call
to avoid harness inability to locate the internal artifact
- Removed linter warnings
testing/mozbase/manifestparser/manifestparser/manifestparser.py
- Removed linter warnings
- Updated logger usage pattern
- Simplifed _read logic, refactored get_fp_filename()
- Improve context for `include:` logging message
- Defer `import mozlog` until the point of use
testing/mozbase/manifestparser/manifestparser/toml.py
- Removed linter warnings
- Removed unused logger
- Improved readability of read_toml()
testing/mozbase/manifestparser/manifestparser/ini.py
- Removed linter warnings
- Removed unused logger
testing/mozbase/manifestparser/manifestparser/filters.py
- Removed linter warnings
testing/mozbase/manifestparser/tests/test_chunking.py
- Removed linter warnings
Bumped manifestparser version to 2.2.31
Differential Revision: https://phabricator.services.mozilla.com/D184020
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
This is necessary to reliably detect what rid a given keyframe is for, for the
purposes of resolving promises from RTCRtpScriptTransformer.generateKeyFrame.
Differential Revision: https://phabricator.services.mozilla.com/D180737
This variable can be null when a ChannelSendFrameTransformerDelegate is in use,
because that does an async dispatch to the encoder queue in the handling for
transformed frames. If this is unset while that dispatch is in flight, we
nullptr crash.
Differential Revision: https://phabricator.services.mozilla.com/D180735
This is necessary to reliably detect what rid a given keyframe is for, for the
purposes of resolving promises from RTCRtpScriptTransformer.generateKeyFrame.
Differential Revision: https://phabricator.services.mozilla.com/D180737
This variable can be null when a ChannelSendFrameTransformerDelegate is in use,
because that does an async dispatch to the encoder queue in the handling for
transformed frames. If this is unset while that dispatch is in flight, we
nullptr crash.
Differential Revision: https://phabricator.services.mozilla.com/D180735
There's a `Cython` issue (https://github.com/yaml/pyyaml/issues/601) with `PyYAML` that breaks our `./mach vendor python` in versions of PyYAML `>5.3.1` and `=<6.0`. This issue has been resolved with `PyYAML` version `6.0.1`, and we can just safely upgrade to it (rather than downgrading to `5.3.1` (which has other issues).
Differential Revision: https://phabricator.services.mozilla.com/D183818
This also upgrades to Taskgraph 5.6.2 which relaxes its PyYAML constraint to
>=5.3.1 to avoid conflicts.
Depends on D181899
Differential Revision: https://phabricator.services.mozilla.com/D183777
Upstream commit: https://webrtc.googlesource.com/src/+/d20849d0710783142175551d81dfe0dcbffcf2b1
[M114] sdp: reject duplicate ssrcs in ssrc-groups
while not really covered by
https://www.rfc-editor.org/rfc/rfc5576.html#section-4.2
and using the same SSRC for RTX and primary payload may work
since payload type demuxing *could* be used is not a good idea.
This also applies to flexfec's FEC-FR.
For the nonstandard SIM ssrc-group duplicates make no sense.
This rejects duplicates for unknown ssrc-groups as well.
BUG=chromium:1454860
(cherry picked from commit 6a38a3eb38f732b89ca0d8e36c43a434670c4ef5)
No-Try: true
Change-Id: I3e86101dbd5d6c4099f2fdb7b4a52d5cd0809c5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308820
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Original-Commit-Position: refs/heads/main@{#40292}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309601
Cr-Commit-Position: refs/branch-heads/5735@{#4}
Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
Upstream commit: https://webrtc.googlesource.com/src/+/e46e37b6f831763aceaf5f5bd081a47cbd562890
[M114] Move transceiver iteration loop over to the signaling thread.
This is required for ReportTransportStats since iterating over the
transceiver list from the network thread is not safe.
(cherry picked from commit dba22d31909298161318e00d43a80cdb0abc940f)
No-Try: true
Bug: chromium:1446274, webrtc:12692
Change-Id: I7c514df9f029112c4b1da85826af91217850fb26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307340
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#40197}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308001
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/branch-heads/5735@{#3}
Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
Upstream commit: https://webrtc.googlesource.com/src/+/ecab2a49da48f0279a3b6422dab602614630005e
[m114] Attempt to recycle a stopped data m-line before creating a new one
which avoids an infinitely growing SDP if the remote end rejects
the datachannel section. This will reactivate the m-line even if
all datachannels are closed.
BUG=chromium:1442604
(cherry picked from commit 522380ff734174faab694e1b67c9d20fffa8738e)
No-Try: True
Change-Id: If60f93b406271163df692d96102baab701923602
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304241
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#40029}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305420
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/branch-heads/5735@{#2}
Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
Upstream commit: https://webrtc.googlesource.com/src/+/9d996824465410b4f25cf1d20bdee01d7091533a
[M114] Fix bug of messages being delivered before data channel is open
If the caller calls RegisterObserver() on the network thread while the
state is not kOpen but there are queued received data, those received
data will be immediately delivered to the observer before the state is
transitioned to kOpen, which may break the observer's assertions and
cause problems.
The problem turns out to be that, when SctpDataChannel::RegisterObserver
calls DeliverQueuedReceivedData(), the data will be passed to the
observer without checking the |state_| first, meanwhile
SctpDataChannel::UpdateState does effectively check the state and
null-check |observer_| before delivering the received data. This CL
fixes this by simply making DeliverQueuedReceivedData() also check
`state_ == kOpen`. In case the state transitions to kOpen after
RegisterObserver() is called, the first DeliverQueuedReceivedData()
call will be no-op, while the second DeliverQueuedReceivedData() call
will do the work.
(cherry picked from commit 20838941240536b52e24e47ce99ad6c2175dba1a)
No-Try: True
Bug: chromium:1442696
Change-Id: If25ce6a038d704939b1a8ae73d7ced110448b050
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304687
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#40036}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305380
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/branch-heads/5735@{#1}
Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
Upstream commit: https://webrtc.googlesource.com/src/+/df7df199abd619e75b9f1d9a7e12fc3f3f748775
Clean up IPv6 fixes field trial artifacts.
The fixes have been default enabled, so clean up dead code.
Bug: webrtc:14334
Change-Id: I4967d5ad451ac333c54294fc14bea6c7ba1445e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301180
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39949}
Upstream commit: https://webrtc.googlesource.com/src/+/cde4b67d9d339c5545210be44334725795fa7278
[SourceTracker] Move state to the worker thread, remove mutex.
This is in preparation of using the state that SourceTracker manages
for more things than only getContributingSources. Audio levels reported
via getStats(), aren't consistent with levels reported via getCS.
Since more operations will be derived from the ST owned data, moving
the management of it away from the audio thread, reduces the potential
of contention.
Bug: webrtc:14029, webrtc:7517, webrtc:15119
Change-Id: I553f7e473316a1c61eeb43ded905a18242a04424
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302280
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39943}
Upstream commit: https://webrtc.googlesource.com/src/+/031ebc42e633d2b9b1e0b5dd2ee676800bf86807
Increase RTP send buffer size from 64kb to 256kb.
Assuming 15Mbps video bitrate at 30fps, a single frame is 62500 bytes.
Add to that some fluctuations in encoder output rate and capture fps,
and frames can easily become larger than 64kb.
Given enough bandwidth and the bursty pacer, it will not be uncommon to
send the entire frame in one batch - and if the send buffer is at 64kb
then you will likely get packetloss already in the IPC packet socket,
even before the packet has reached the network card!
It's not entirely clear what the optimal size is, but given that the
receive buffer size was increased from 64kb to 256kb for high bandwidth
receive scenarios and had negligible negative effects I think it's
pretty safe to bump the send buffer to match.
There is a field trial available that can be used as circuit breaker
in case things turn south: WebRTC-SendBufferSizeBytes
Bug: webrtc:14780
Change-Id: I6c786d993181a882e6dce832ff56dc92d2a8a341
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290985
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39942}
We cherry-picked this in Bug 1810949.
Upstream commit: https://webrtc.googlesource.com/src/+/ba41b40461df191624c61f0c98ae76e69fe1d46b
webrtc_libyuv: Add support for more video types for consistency
Bug: webrtc:14830
Change-Id: I0998fb04a03745131f9f5cca878b0cdb46f3b62b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291529
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39940}
Upstream commit: https://webrtc.googlesource.com/src/+/94e5817759e4812190b5a1403f77be58db3d9198
Guard FakeDataChannelController state with the network thread.
Tsan bots detected races since callbacks are being made on the network
thread but tests checked the state from the signaling thread.
Bug: none
Change-Id: If854e44159c56c0d12616e0b62ad92018291ed30
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302281
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39928}
Upstream commit: https://webrtc.googlesource.com/src/+/daaa6ab5a8c74b87d9d6ded07342d8a2c50c73f7
dcsctp: Add handover state for zero checksum
This CL can prepare downstream projects for being aware of
this new handover state.
This was extracted from change 299076.
Bug: webrtc:14997
Change-Id: I35bfbe040ffbaa5d7266eb67d58078b66083337a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302980
Reviewed-by: Sergey Sukhanov <sergeysu@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39927}
Upstream commit: https://webrtc.googlesource.com/src/+/683f3165f95abc345603ef1c2385677a0a70218d
Add slightly more constness to SourceFrame and the embedded AudioFrame
This makes it a bit more clear that values of member variables of
SourceFrame are never directly changed and that doing so is not an
intentional part of the design. Also made use of `SourceFrame` vs
`const SourceFrame` more consistent since the audio frame of a
`const SourceFrame` was being modified in some places.
Accessing the embedded AudioFrame can be done via the const
audio_frame() accessor or via the mutable_audio_frame() accessor when
modifying the frame is needed. This helps with clarifying later on
when downstream code paths such as ones that access the `packet_infos_`
data, can know that it won't be modified for the rest of the frame's
lifetime (thus avoiding having to make copies).
Bug: none
Change-Id: I175cec8fcdb85063239a5f9c299b7878c639f00e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302383
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39926}
Upstream commit: https://webrtc.googlesource.com/src/+/014cbed9d2377ec0a0b15f2c48b21a562f770366
Revert "dcsctp: Negotiate zero checksum"
This reverts commit a736f30a5fddfa9a6af02a0a916da09bcac49d0d.
Due to a downstream project not supporting this
new handover state, it fails. Handover state needs
to be submitted first, then downstream project needs
to be updated, and finally the code changes can be
submitted.
Bug: webrtc:14997
Change-Id: I8551e349408d9bf4eb593cb948279d659467fe20
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302821
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39923}
Upstream commit: https://webrtc.googlesource.com/src/+/a736f30a5fddfa9a6af02a0a916da09bcac49d0d
dcsctp: Negotiate zero checksum
If configured, attempt to negotiate "zero checksum
acceptable" capability, which will make the outgoing
packets have a fixed checksum of zero. Received
packets will not be verified for a correct checksum
if it's zero.
Also includes some boilerplate:
- Setting capability in state cookie
- Adding capability to handover state
- Adding metric to know if the feature is used
This feature is not enabled by default, as it will be
first evaluated with an A/B experiment before making
it the default.
When the feature is enabled, lower CPU consumption for
both receiving and sending packets is expected. How
much depends on the architecture, as some architectures
have better support for generating CRC32 in hardware
than others.
Bug: webrtc:14997
Change-Id: If23f73e87220c7d42bd4f9a92772cda16bc18fcb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299076
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39920}
Upstream commit: https://webrtc.googlesource.com/src/+/51c632c13bd4076d85b51ac4e36c9097000a6e8e
Use GlobalSimulatedTimeController in more webrtc video engine unittests
This removes all "_WAIT" operations in the tests and all uses
of kTimeout for loop+poll check for values.
On my linux box, this also reduces the time it takes to run all
./rtc_media_unittests (in parallel) from about 3500ms, to ~50ms.
(longest running test was WebRtcVideoChannelBaseTest.GetStats)
Bug: none
Change-Id: If544aa10cb0281cb5e5e51fb654db5f45de871da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302343
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39918}
Upstream commit: https://webrtc.googlesource.com/src/+/67f21095446a1a5abaa551dc6f666843b46f7bae
Revert "For AV1, disable error resilience on upper temporal layers. Error resilience is no longer required for upper temporal layers. Disabling error resilience on the upper layers leads to a ~2% PSNR BD-rate gain."
This reverts commit 2080dacfb7946daf79ecd3f69efbd0c9e08b9be2.
Reason for revert: This CL is causing a lot of flakiness on iOS bots
https://ci.chromium.org/p/webrtc/builders/ci/iOS%20Debug%20%28simulator%29
Original change's description:
> For AV1, disable error resilience on upper temporal layers. Error resilience is no longer required for upper temporal layers. Disabling error resilience on the upper layers leads to a ~2% PSNR BD-rate gain.
>
> Bug: webrtc:15106
> Change-Id: Id92d51defbd26c1a77e3c9fe19607e9db4a3e7c1
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302001
> Reviewed-by: Marco Paniconi <marpan@webrtc.org>
> Commit-Queue: Michael Horowitz <mhoro@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39900}
Bug: webrtc:15106
Change-Id: I24515280113ed6681c9766026ec24d689035c031
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301983
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Owners-Override: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39903}
Upstream commit: https://webrtc.googlesource.com/src/+/2080dacfb7946daf79ecd3f69efbd0c9e08b9be2
For AV1, disable error resilience on upper temporal layers. Error resilience is no longer required for upper temporal layers. Disabling error resilience on the upper layers leads to a ~2% PSNR BD-rate gain.
Bug: webrtc:15106
Change-Id: Id92d51defbd26c1a77e3c9fe19607e9db4a3e7c1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302001
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Commit-Queue: Michael Horowitz <mhoro@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39900}
Upstream commit: https://webrtc.googlesource.com/src/+/f9ffd68d8eb3b668056664bf67d0e0c540cd200c
Migrate PostTask+Wait to BlockingCall to avoid deadlock in DegradedCall.
The deadlock happens when the WebRtcCombinedNetworkAndWorkerThread
experiment is running because the worker thread doing the PostTask is
the same thread as the network thread. When using BlockingCall instead
this method will avoid the PostTask and just execute in-line instead
if the experiment is running and otherwise do what the old path did.
As per webrtc:15099, we do not want to increase uses of rtc::Thread in
general, and adding more block-invokes in is also discouraged
(webrtc:12649) so instead of adding new methods to TaskQueueBase we
simply do a static_cast<rtc::Thread*>.
When WebRtcCombinedNetworkAndWorkerThread has launched the blocking
call can be removed because then we're on a single thread always.
Bug: webrtc:15098
Change-Id: I6dcc09bcf6ee0ad12e4beffef3b206989265540b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301880
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39894}
Upstream commit: https://webrtc.googlesource.com/src/+/580b0f944b4ed5aeb73134f3b00fa15ecd457307
Allow feeding a Sender encoded videoframe into a Receiver Transform
Instead of crashing with a CHECK fail when an insertable stream of a
Video RTPReceiver is given a frame from an RTPSender's insertable
stream, construct a reasonable analogous receive frame and pass it
through to be decoded.
A small step towards removing the split we have between Sender and
Receiver implementations of TransformableFrameInterface which just
confuses users of the API.
Bug: chromium:1250638
Change-Id: I02e0f1d9d35c16dc12718927c5200ff7cf4407e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301181
Reviewed-by: Palak Agarwal <agpalak@google.com>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39888}
Upstream commit: https://webrtc.googlesource.com/src/+/61e8b59701125539e918eea89a12084ba23f69b7
Use SendAsync in data channel benchmark.
The same observer implementation was being used for both client and
server but the role is different (sender vs receiver), so I split
the functionality up into two separate classes.
Bug: webrtc:11547
Change-Id: Ia60ab96fb86b4ff61fa7bff5f30d59b6fe0f9746
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300742
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39886}
Upstream commit: https://webrtc.googlesource.com/src/+/aa3c9f297219fd9ff7d75be281cc61b2e4d67bb0
Reland "Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code."
This reverts commit 298313534df2420e079ffc6fc9c6019d01d29a88.
Changes from the original commit:
* Call OnTransportClosed() from TeardownDataChannelTransport_n()
(same as before the original commit)
* Not call OnTransportClosed() from OnTransportChanged() when its
called with nullptr (also preserving the behaviour from before
the original commit).
Original change's description:
> Revert "Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code."
>
> This reverts commit 2ec6a6c57830e06f601607c1b9473ad821b57e07.
>
> Reason for revert: It breaks WPT tests (e.g. https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1361972/overview) blocking the roll into Chromium.
>
> Original change's description:
> > Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code.
> >
> > * DCC = DataChannelController.
> >
> > * Consolidate steps to set the mid and transport name. They're now
> > set at the same time and without a separate PostTask.
> > * Transport sink is now consistently set in DCC
> > * Order of notifications for setting up the transport is now the same
> > regardless of the first time the transport is being set or if it's
> > being replaced.
> > * Made set_data_channel_transport() private.
> >
> > Bug: webrtc:11547
> > Change-Id: I39e89c6e269e6f06d55981d7944678bf23c8817a
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300562
> > Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#39859}
>
> Bug: webrtc:11547
> Change-Id: I0d8d7453b71be80fbf1b7eba7d161336e29de091
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301360
> Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Cr-Commit-Position: refs/heads/main@{#39864}
Bug: webrtc:11547
Change-Id: I8ebbc3d3a12786dff2096350a77e03e98466ff00
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301702
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39884}
Upstream commit: https://webrtc.googlesource.com/src/+/45eae346930aedbf4624d054e0633c94b397b8ec
Revert "dcsctp: Support zero checksum packets"
This reverts commit bd46bb7660fbc9f31799196058f7a1957f50aa31.
Reason for revert: There is a slight performance degradation
pointing to this CL, so revert this to be able to confirm if
it is the culprit.
Original change's description:
> dcsctp: Support zero checksum packets
>
> If configured, the packet parser will allow packets with
> a set checksum of zero. In that case, the correct checksum
> will not even be calculated, avoiding a CPU intensive
> calculation.
>
> Also, if specified when building a packet, the checksum can
> be opted to be not calculated and written to the packet.
> This is to be used when draft-tuexen-tsvwg-sctp-zero-checksum
> has been negotiated, except for some packets during association
> establishment.
>
> This is mainly a preparation CL and follow-up CL will enable
> this feature.
>
> Low-Coverage-Reason: Affects debug logging code not run in tests
> Bug: webrtc:14997
> Change-Id: I3207ac3a626df039ee2990403c2edd6429f17617
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298481
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Victor Boivie <boivie@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39737}
Bug: webrtc:14997
Change-Id: Ie22267abb4bcd25d5af07875eb933c51ed5be853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301580
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39878}
Upstream commit: https://webrtc.googlesource.com/src/+/59d09aeeee3fab525c78ecbf7ed1c27a01fdce43
Move deprecated JitterBuffer to modules/video_coding/deprecated/
This move further clarifies that the file and its class are deprecated. It also cleans up the modules/video_coding root folder a bit.
No functional changes are intended.
Bug: webrtc:14876
Change-Id: Ic3ac439b3dd3492e6c9c85869efa80a6708658ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301521
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39876}
Upstream commit: https://webrtc.googlesource.com/src/+/6cf12bbe327f70652f00c6ac1b0af34085a82719
Fetch encoded QP before releasing output buffer
Before this change we first released output frame buffer in the code path which prepends config buffer to a keyframe and then called getOutputFormat(index). getOutputFormat(index) throws an exception if index points to a released buffer. This change rearranges calls such that getOutputFormat(index) always executed before releaseOutputBuffer(index).
Bug: webrtc:15015
Change-Id: Ia64f5d8e7483aeeb316d1a71c0cb79233f4bbee9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301364
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39874}
Upstream commit: https://webrtc.googlesource.com/src/+/ea1502accbd03d678ff820f522f1e8788625b3e6
Add necessary deps for android video_codec_perf_tests
native_test_jni_onload depends on base_jni which depends on modules/audio_processing:api. This requires to include audio_device_java in pure video targets like video_codec_perf_tests.
Bug: webrtc:14852
Change-Id: I5e7b102fd730801562695bf3f4d5170ec8e59b58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301363
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39873}
Upstream commit: https://webrtc.googlesource.com/src/+/37879e9867c74b63e5adae16baf5397b4dbe122c
[WebRTC-SendPacketsOnWorkerThread] Cleanup RtpTransportControllerSend
MaybeWorkerThread* GetWorkerQueue() and is removed.
Instead all work is expected to be done on the taskqueue used when
creating the RtpTransportControllerSend.
Bug: webrtc:14502
Change-Id: Iedc30efb8de7592611d6d3c5b5c6cd33c17a60c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300867
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39872}
Upstream commit: https://webrtc.googlesource.com/src/+/b812b7a86b2af074e50e8974ed6c274c67d39d73
Delay probes after route change until transport is writable
Ensure probes are not created until after the transport becomes writable even if the network route change.
DTLS negotiation must complete before there is a point in sending probes.
Bug: webrtc:14928
Change-Id: Ib3cb93aef9f38e306b094dd700ed595cf9eb3f32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301362
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39870}
We cherry-picked this in bug 1724900
Upstream commit: https://webrtc.googlesource.com/src/+/4beafa38d546ab6c0bb423c12762f0c4568aa5ce
PipeWire video capture: set device unique ID during initialization
This is what Firefox implementation relies on and I can see that also
the V4L2 implementation is doing the same.
Bug: webrtc:15087
Change-Id: I641062ba879b6ef83e31af79ecc9d06fdae54adb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301320
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39869}
Upstream commit: https://webrtc.googlesource.com/src/+/4ec56a3aa0b402fe37252f326e21cd2909874aa8
VCMJitterBuffer: fix deadlock.
The jitterbuffer would call Flush which takes a mutex from
InsertPacket, which is already under the same mutex. Fix
this by introducing an internal flush method that assumes
a locked state.
The change also adds more thread annotations in case more
problems were present. No more problems were detected.
Fixed: b/277930190
Change-Id: If85609f27f8187ade9370847fecc2bc83d940dd5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301340
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Auto-Submit: Markus Handell <handellm@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39868}
Upstream commit: https://webrtc.googlesource.com/src/+/298313534df2420e079ffc6fc9c6019d01d29a88
Revert "Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code."
This reverts commit 2ec6a6c57830e06f601607c1b9473ad821b57e07.
Reason for revert: It breaks WPT tests (e.g. https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1361972/overview) blocking the roll into Chromium.
Original change's description:
> Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code.
>
> * DCC = DataChannelController.
>
> * Consolidate steps to set the mid and transport name. They're now
> set at the same time and without a separate PostTask.
> * Transport sink is now consistently set in DCC
> * Order of notifications for setting up the transport is now the same
> regardless of the first time the transport is being set or if it's
> being replaced.
> * Made set_data_channel_transport() private.
>
> Bug: webrtc:11547
> Change-Id: I39e89c6e269e6f06d55981d7944678bf23c8817a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300562
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#39859}
Bug: webrtc:11547
Change-Id: I0d8d7453b71be80fbf1b7eba7d161336e29de091
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301360
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#39864}
Upstream commit: https://webrtc.googlesource.com/src/+/0a4a9846fcb3a53484adda8f99e91f26bfab44ae
Extract common codec fields into RtpCodec
This creates the RtpCodec structure for the common fields
used in RtpCodecParameters and RtpCodecCapability.
Remove the unused fields from both that were defined from ORTC
and never implemented as well.
Bug: webrtc:15064
Change-Id: I37b4c83e2051a888fc99cc0d9f7aeb8d74f0421d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301182
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39862}
Upstream commit: https://webrtc.googlesource.com/src/+/58e8cb0553694a999f83508f705cd7184dc50b3b
Removes usage of FrameArrived event for WGC
* Removes a ~60Hz thread-wakeup signal caused by the FrameArrived event
* Initial power measurements shows a reduced power consumption
* No increase in time to first captured packet found
Bug: chromium:1428592
Change-Id: Ia23b5db0c87e70e5b0d6919394494a24d8944493
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301200
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39861}
Upstream commit: https://webrtc.googlesource.com/src/+/2ec6a6c57830e06f601607c1b9473ad821b57e07
Add param to DCC::SetupDataChannelTransport_n, simplify DCC* setup code.
* DCC = DataChannelController.
* Consolidate steps to set the mid and transport name. They're now
set at the same time and without a separate PostTask.
* Transport sink is now consistently set in DCC
* Order of notifications for setting up the transport is now the same
regardless of the first time the transport is being set or if it's
being replaced.
* Made set_data_channel_transport() private.
Bug: webrtc:11547
Change-Id: I39e89c6e269e6f06d55981d7944678bf23c8817a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300562
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39859}
Upstream commit: https://webrtc.googlesource.com/src/+/b9313b958426db681ce5f594ae54edcc0dcc3ab5
Removes usage of the Magnifier API on Windows
This CL removes the usage of the Magnifier screen capture API on
Windows. The idea is to remove the actual source in a second step
once this change lands.
Bug: chromium:1428341
Change-Id: Id2cb25632c7edbea2cf527959b14b27ee00b0e56
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301164
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39856}
Upstream commit: https://webrtc.googlesource.com/src/+/06e214888939ed129989cd8cc3e04b54d166988c
Deflake simulcast flow tests: prevent negative Timestamp exception.
These tests often fail in 'ExtrapolateLocalTime' because the result gives a negative Timestamp.
Here is the stack from https://chromium-swarm.appspot.com/task?id=6173230e67897b10:
PC: @ 0x7f03afdb8e87 (unknown) raise
...
@ 0x55f4a360ba71 352 webrtc::Timestamp::operator+()
@ 0x55f4a47ecaf3 160 webrtc::TimestampExtrapolator::ExtrapolateLocalTime()
Low-Coverage-Reason: coverage isn't that low.
Change-Id: If3e7cbf31d6c4800727b24352ed2c6edc425fc73
Bug: webrtc:15022
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300600
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#39853}
Michael Froman
alwu
Cosmin Sabou
John Schanck
Erich Gubler
Cristian Tuns
Paul Adenot
Jan Grulich
Narcis Beleuzu
Travis Long
Makoto Kato
Cristina Horotan
Stanca Serban
Emilio Cobos Álvarez
Sandor Molnar
Jan-Erik Rediger
Mike Hommey
Mark Hammond
Kershaw Chang
Willy R. Vasquez
Tom Marble
Updatebot
Ben Visness
Gabriele Svelto
Andrew Halberstadt
Byron Campen
Nicolas Silva
ahochheiden
Willy R. Vasquez