When capturing only one display, it is unnecessary to use
DoDuplicateAll, which allocates bitmap image memory for a rectangle
encompassing all screens and captures all displays. In this case, I
switch to DoDuplicateOne.
I have added an int parameter to GetNumFrameCaptured and
EnsureFrameCaptured to distinguish which display's skip behavior is
currently being executed.
After the modification, when capturing a single monitor in a
multi-monitor environment, only the bitmap image memory of the size of
the captured monitor will be allocated, rather than for all monitors.
Bug: webrtc:391914255
Change-Id: Iee56796c50282beaf1dbeef47f5937fe7fe94a05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375181
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43822}
This change resolves an issue that arises when there is a gap in the
sequence numbers of packets associated with a single frame.
Before this change, the H26x packet buffer could potentially assemble a
frame using only a subset of the packets in the buffer if a packet was
missing in the middle and a packet with a marker bit arrived.
To address this, the change introduces a check before assembling a
frame. This ensures that all packets belonging to a single frame are
correctly collected by iterating backward until the first packet in the
frame is identified.
Bug: webrtc:384391181
Change-Id: I4d09a3d6d569624ece204264cb32e5076ed090a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374183
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43793}
Need to clear frameInfos in case of reinit, as outdated items produce
incorrect decode time. This leds to render timestamps 'in future'
(VCMTiming::RenderTime) and rendering delays (low fps).
Bug: None
Change-Id: Iee569ff74fe3e0ff3610877472756cbbd59aba7a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374680
Auto-Submit: Anna Lemehova <anna.lemehova@gmail.com>
Reviewed-by: Zoé Lepaul <xalep@webrtc.org>
Commit-Queue: Zoé Lepaul <xalep@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43772}
This resolves an issue where when packets appear out of order at the
beginning of a stream, packet_buffer.cc might drop the entire packet
buffer because it detects a "large negative jump" even though the
difference in sequence numbers is very minor and is caused by network
congestion / packet re-ordering. Currently, when the issue occurs, this
can cause video corruption/artifacts. More details and reproduction is
available on the attached webrtc bug report 390329776.
Bug: webrtc:390329776
Change-Id: Idb56eb2e066d596d8afd7ec904359baf0cb3feef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374540
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43753}
For-loop has a 'continue' statement that skips increment of the index.
Added such an increment before 'continue' for the index to keep up with
the for-loop.
I guess current implementation will bug on codecs sequence like:
'red, unknown, opus'
since the subsequent for-loop (the 'red_codec' one) will not be able to
find 'opus'.
Seems like adding second increment statement is the easiest way to fix it.
Bug: None
Change-Id: Iab9cc66cf569458af9fd9ba5b938d83186c78c73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369700
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43488}
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}
