This commit fixes the issue of video playback in slow motion caused by VCMTiming being unable to provide the correct rendering time in
scenarios of continuous network packet loss
WANT_LGTM=mbonadei
Bug: webrtc:376183208
Change-Id: I63617068506e536c4b812215ea084eec18e8ee06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367000
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43392}
This reverts commit 3753c8190e3f0aca6758a5521e33f8b5d4f09ab4.
Reason for revert: Break assembling of hardware encoded h264 P frame on
weak network condition.
Original change's description:
> h264: fix first_packet_in_frame logic for multislice in a single rtp packet
>
> a frame must be (or should be) first when it contains either SPS (but not just PPS),
> is an IDR or is a slice with first_mb_in_slice == 0.
>
> Fixes an edge case where a STAP-A with SPS, PPS and multiple slices of an IDR fit
> into a single RTP packet which can happen with small 320x196 frames
>
> BUG=webrtc:352379280,webrtc:346608838
>
> Change-Id: Ic6dea6c81db759d0d7ddd4054407103fd791f6c5
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357121
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#42652}
Bug: webrtc:368335257
Change-Id: I07725c78be628bff71b79b8b9369677e39f5f5ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363080
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43062}
When a value is set in RtpEncodingParameters::codec, the corresponding
payload_type will be set in the SDP a=rid: line.
a=rtpmap:96 VP8/90000
...
a=rtpmap:97 VP9/90000
...
a=rid:r0 send pt=96
a=rid:r1 send pt=97
Bug: webrtc:362277533
Change-Id: Ia9688a5fc83c53cf46621d97e87f8dd363a4d7f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43049}
Fixed issue with network interfaces due to a missing return value in the
"nw_path_enumerate_interfaces(...)" block. Exposed in iOS 18,
RTCNetworkMonitor::initWithObserver will only enumerate the first
interface, instead of all device interfaces
Bug: webrtc:359245764
Change-Id: Ifb9f28c33306c0096476a4afb0cdb4d734e87b2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359541
Auto-Submit: Corby <corby.hoback@gmail.com>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42818}
There is a race condition on reading
`ObjCNetworkMonitor::_network_monitor` field.
The `ObjCNetworkMonitor::OnPathUpdate()` checks its nullability
on the org.webrtc.RTCDispatcherNetworkMonitor thread BEFORE the
`ObjCNetworkMonitor::Start()` assigns it on the network_monitor thread.
In addition, this field is neither atomic nor protected by mutex so its
last assigned value is not guaranteed to be visible to
another [reading] thread.
Bug: webrtc:355238623
Change-Id: I1a05215111cc873b7d4931824e18f281aebfb91f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357880
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42778}
std::optional<T>::emplace() without an initializer is broken on clang++
with gnu libstdc++. this workarounds the bug by removing the
absl::optional wrapping, which is actually pointless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227
Bug: chromium:41455655
Change-Id: I05354e57cc4cdda3fa6d3cd23f46462b69cc3bee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355900
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42561}
Bug: webrtc:15719
Change-Id: I7daf8ee5b90fbe9f1246f1d99211ffa0d8a19f73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41503}
When the specified device was not found in GetDevicesInfo,
SetPlayoutDevice/SetRecordingDevice will never return a (-1) error.
Bug: None
Change-Id: I9ac71cf72f7876c1c54ee593f184aa4007dba22f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320500
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40768}
This can be helpful in various situations, such as debugging with an
unrestricted Pipewire socket or for downstream projects like
B2G/Capyloon. Additionally it will help once we move from the camera
portal to the more generic device portal.
Original patch by Fabrice Desré <fabrice@desre.org>
Bug: webrtc:15464
Change-Id: Iae6802f242d68244bca85947cb15ef3eee923ab0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318642
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40706}
This avoids the need of hard coding the values to use networkIgnoreMask on Android platform.
Bug: None
Change-Id: Ib5e860913cec2c6d41cfa1b778cb122d0bfe1300
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311780
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40541}
Referencing this type directly is not allowed when building
with the macOS 14.0 SDK.
Other usages in webrtc follow this inline pattern too so
going with this instead of "auto" which also works.
Change-Id: I84a0ba9c78e83843bc73c71c642caca75750f127
Bug: chromium:1454356
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308560
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40313}
CFStringFromCString is useful, however if we have a static C string, we can use the defined macro CFSTR to create a CFString at runtime instead.
Bug: None
Change-Id: I54b3f590b3ab07858409af27b817013c98556ded
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293060
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Seija K. <doremylover123@gmail.com>
Cr-Commit-Position: refs/heads/main@{#39341}
We found that the legacy assumption for H264 which assumed that
simulcast streams would use 2x width ratios in unnecessary as the
encoder has since been fixed to handle multiple ratios.
H264 encoder still works even if this assumption is invalid
Bug: None
Change-Id: I9caacf78d26c8215b94858a2d8674ec4cd64e96e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286940
Reviewed-by: Mirta Dvornicic <mirtad@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39072}
removes cached pixelbufferpool and instead retrieves current pool from the compressionSession each time (as recommended by apple docs)
Bug: webrtc:14688
Change-Id: I2244e69e7f32b912021db0905b9d5867d0bf6357
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284240
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38920}
The DCHECK crashes debug builds running some applications such as Webex.
Bug: None
Change-Id: I0061286c4c1d04964678a00014896f1fccd4685d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276460
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38644}
A bug in the id being searched for inside OpenSSLStreamAdapter::SslCipherSuiteToName prevented the lookup from ever succeeding.
This resulted in this stat being unavailable when calling PeerConnection::GetStats(). To fix the problem, look for (0x03000000L | cipher_suite) which matches what the BoringSSL codepath is doing.
Bug: webrtc:14596
Change-Id: Ic36d77dbc4c2378fbde1e2f21a9f5bd735b36741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38460}
Currently if you want to obtain the stats for a specific sender/receiver
in Android, you need to call peerConnection.getStats() and filter
manually the result by sender.
pc.getStats(receiver/sender) exists in c++ and ios but was not exposed
in Android
Bug: webrtc:14547
Change-Id: I9954434880f0f93821fcd2e2de24a875e8d136ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275880
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38428}
Re-enabled multithreaded encoding using OpenH264, as the issue described in crbug.com/583348 no longer applies.
Bug: webrtc:14368
Change-Id: I5ae768a6edf3b40d99c13fb4ee4662626c993a66
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271820
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37837}
Resolves an issue where, in Chrome, WebRTC event logs do not capture outgoing packets for video receivers because no reference to the event log was passed to the video receiver.
Bug: webrtc:14338
Change-Id: Ia33ce6f2d69a0e341530648b10a08516dc53abf3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271080
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37746}
Before this change the full screen application handler was failing to
detect PowerPoint going into presentation mode, resulting in the editor
window continuing to be shared rather than the intended behavior of
sharing the presentation itself.
Fix this by always looking for the PowerPoint full screen presentation
window, regardless of whether the editor window is still open. In
the current version of PowerPoint, the editor stays open during
presentation.
Bug: chromium:1231437
Change-Id: I1b21e263d25320cc236d127d22d4d64bb52fcbda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269560
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37632}
This allows builds on non-x86 architectures such
as ppc64el.
Bug: webrtc:14057
Signed-off-by: Timothy Pearson <tpearson@raptorcs.com>
Change-Id: Ie2c1023d2c1d041ba1d140f06af432ed9e9f7432
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262002
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36856}
Resolving https://bugs.chromium.org/p/webrtc/issues/detail?id=14023
At the moment, in DelayBasedBwe the time deltas are rounded to the
nearest millisecond. This change makes sure the numbers are passed as
doubles as expected by the TrendlineEstimator.
Change-Id: I68882547fb19af0e67e7b5d8de4159083a54d7eb
Bug: webrtc:14023
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261320
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36806}
With some slightly broken webcams, it's possible that the select()
returns with a timeout or no event. In that case, the v4l2 thread
never returns. To fix this, just check if quit_ is set and exit
unconditionally in that case.
https://bugzilla.mozilla.org/show_bug.cgi?id=1752326
Bug: None
Change-Id: Ic07ce15afd0016ff9f967c2cf64e646c20127457
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251540
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36200}
This collision can occur when we have
asymetrical send and receive codecs. This is the case in the current
code base with the VP9 codec familly but is not visible untill more
codecs are added.
Added Nutanix Inc. to AUTHORS.
Bug: chromium:1291956
Change-Id: I09d3f76161d984d2a3edf721639753bffd4947b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250034
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35944}
This reverts commit 3babb8af238a531cbff27951604b09bb78b762cd.
Reason for revert:
- Causes regressions to transceivers, see https://crbug.com/1291956 for more information, including tests to reproduce the issue.
This CL is not a pure revert. While it reverts everything else, it does
keep the new enum value (kProfilePredictiveHigh444). This is as to not
break Chromium which already depend on it. It is not listed in the
kProfilePatterns though so the enum value should never be applicable.
Original change's description:
> Added support for H264 YUV444 (I444) decoding.
>
> Added Nutanix Inc. to the AUTHORS file.
>
> PS#1 is a reland of "Added support for H264 YUV444 (I444) decoding." https://webrtc-review.googlesource.com/c/src/+/234540
>
> Bug: chromium:1251096
> Change-Id: I99a1b1e4d8b60192ff96f92334a430240875c66c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235340
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35684}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1251096, chromium:1291956
Change-Id: Ib4d8ea4898f9832914d88e7076e6b39da0c804ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249791
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35835}
Added Nutanix Inc. to the AUTHORS file.
PS#1 is a reland of "Added support for H264 YUV444 (I444) decoding." https://webrtc-review.googlesource.com/c/src/+/234540
Bug: chromium:1251096
Change-Id: I99a1b1e4d8b60192ff96f92334a430240875c66c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235340
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35684}
