Bug: none
Change-Id: I99aab901c2d43c98e603deaa60cc2803be656a67
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377780
Auto-Submit: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43928}
This is to ensure that the device_scale_factor stored per frame is the
latest one according to the system settings and not an old value.
Bug: chromium:383946052
Change-Id: I11e6342201678451554e6883ded48999fd996743
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377541
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43924}
Purpose is to allow sending feedback every 25ms even if link capacity is
unknown.
Bug: webrtc:377222395
Change-Id: I8379cab964cf1d414aab9581e34e209303bd975c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376701
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43918}
All build target resources will be moved there in a second step.
Change-Id: Iadbb582e133feb375399c839870c7b298f3934c6
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/377282
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43913}
This was a killswitch for AV1E_SET_MAX_CONSEC_FRAME_DROP_MS_CBR. The feature has been enabled for over six months and has proven to be working.
Bug: webrtc:351644568
Change-Id: Ifa02e72284c562298e3e5560dbc27f28a9e02819
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375863
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43903}
Update to use similar bitrate limits as VP9, depending on whether QP
from encoder is trusted or not.
Bug: chromium:392060821
Change-Id: I305182fecf7acfe84dbd2e049f9ce712a7a30ede
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376762
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43898}
This field trial was enabled by default for a long while.
Bug: webrtc:42234783
Change-Id: If050f88a3649c43d895110f4f68160f020f854e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376421
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43885}
Since the device_scale_factor is usually exposed as a float in chromium,
we want to keep it same here for consistency.
Bug: chromium:383946052
Change-Id: I8d055ca0fcac623f59dcf96eb3cee15efc23b2ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376700
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43869}
In all the other functions `monitor_id` is a global id from range [0..total monitor count), but each DxgiAdapterDuplicator always assumes that it gets a local id from range [0..adapter monitor count).
Bug: chromium:395807060
Change-Id: I4bb232ee5d83f09859534f813111446763fe9fc9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376840
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43867}
When using GDI to capture windows, not only will the target window be
captured, but all owned windows of the target window will also be
captured, and the captured results of the owned windows will be drawn
onto the captured result of target window.
GDI (BitBlt or PrintWindow) cannot capture windows with WS_EX_LAYERED
attribute, so when the owned window has this attribute, the area of the
owned window in the result is black.
After modification, if the owned window has the WS_EX_LAYERED attribute,
it will not be captured or drawn.
Bug: webrtc:394380765
Change-Id: I5f0c7d31809a353377b0aa52452634b46247af5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376360
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#43851}
This is to fix build error when we set use_libcxx_modules=true in
chromium.
Bug: chromium:40263312
Change-Id: I7dd87e43823f33f70c6c8e15f4c64df7d231f021
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376003
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Auto-Submit: Takuto Ikuta <tikuta@google.com>
Cr-Commit-Position: refs/heads/main@{#43845}
This is a reland of commit e20fbb00d0e0219b710da24664e81a10b12c703a
which failed due to CHECK failing on monitor_id in
DxgiDuplicatorController::GetDeviceScaleFactor(). This has now been
fixed in this CL by removing the check for greater than 0 and instead
returning std::nullopt.
Original change's description:
> Get DeviceScaleFactor for the captured monitor/screen
>
> Accesses DeviceScaleFactor using the windows API
> GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
> CL, this value is propagated to
> DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
> frame metadata.
>
> In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
> the device scale factor changes.
>
> Design doc: go/expose-captured-surface-resolution
>
> Bug: chromium:383946052
> Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Palak Agarwal <agpalak@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43827}
Bug: chromium:383946052
Change-Id: Iffcc889b9a560695302f71623e3e929ecb2489fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376061
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43832}
This reverts commit e20fbb00d0e0219b710da24664e81a10b12c703a.
Reason for revert: Breaks WebRTC roll to Chromium, see:
https://chromium-review.googlesource.com/c/chromium/src/+/6218060
Example of error: https://ci.chromium.org/ui/p/chrome/builders/ci/win-arm64-rel-ready/51821/test-results?sortby=&groupby=
Original change's description:
> Get DeviceScaleFactor for the captured monitor/screen
>
> Accesses DeviceScaleFactor using the windows API
> GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
> CL, this value is propagated to
> DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
> frame metadata.
>
> In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
> the device scale factor changes.
>
> Design doc: go/expose-captured-surface-resolution
>
> Bug: chromium:383946052
> Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Palak Agarwal <agpalak@google.com>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43827}
Bug: chromium:383946052
Change-Id: I3065b278939ca0e686ee6da0f0721082bc0c99e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375902
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43829}
Accesses DeviceScaleFactor using the windows API
GetScaleFactorForMonitor and adds it to the DesktopFrame. In a follow-up
CL, this value is propagated to
DesktopCaptureDevice::Core::OnCaptureResult where it is added to the
frame metadata.
In a follow-up CL, add RegisterScaleChangeEvent to get notified whenever
the device scale factor changes.
Design doc: go/expose-captured-surface-resolution
Bug: chromium:383946052
Change-Id: I363af33c569419d95ddf31a0cc2f9cecf6fb0c7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374344
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Palak Agarwal <agpalak@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43827}
This change expands on https://webrtc-review.googlesource.com/c/src/+/374420 to cover the error produced when copying microphone samples.
Change-Id: I7aa58c9c9ac175d5f4cfdb60bbd3f16334c03c1b
Bug: webrtc:390314937
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375540
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Peter Hanspers <peterhanspers@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43826}
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}
NetworkStateEstimator is not used by WebRTC from receive side.
ReceiveSidesCongestionController::SetTransportOverhead is not needed either since NetworkStateEstimator is removed.
Note, CongestionControlFeedbackGenerator is used with RFC 8888 only and feedback frequency will be refactored in later cl.
Bug: webrtc:42220808
Change-Id: I08980aa19117e1de7a9b7896d05d07715dd9f962
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375460
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43821}
There can be error log each frame when maximum playout delay sent with the frame exceed delay derived from the av-sync.
In such scenario prefer to limit the playout delay by the one attached to the received frame.
Bug: b/390043766
Change-Id: Ia57969df72f7a649e5a9280d5bb29986f5ea14b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374284
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43814}
Since Xrandr depends on Xrender, it needs to be explicitely listed before, otherwise linkers may not find the Xrender symbols.
Bug: None
Change-Id: Ifb1e82f63e1fc1645979c14b65e3beab06637cb8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375428
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Florent Castelli SE <fcastelli@nvidia.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43808}
This flip default behavior for webrtc users that create packetizers without help of RtpSenderVideo class.
Bug: webrtc:42226301
Change-Id: I42fe696039334672b7d0b0ed1f87a52c3f6bf5ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374883
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43807}
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}
Experimentation shows only a slight increase in bitrate due to improved
BWE. There's no negative side-effects we have been able to see so far.
This CL flips the experiment to default-on but is kept around as a
kill-switch until the next milestone just in case something unexpected
is discovered.
Bug: webrtc:42226301
Change-Id: I4a0b1c85e912b909d7bff58d78966cf161857f7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374182
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43773}
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}
Matlab files extension is the same as ObjC, which is .m
This makes clang-format think that those files are ObjC and then it
wrongly formats them, leading to output that doesn't compile at all.
It's a known issue and the solution is to disable it in Matlab files.
I don't want to disable ObjC in whole folders, because of 2 reasons:
1) I want ObjC to be properly formatted if new files are added in the
future
2) C++ header files are interpreted as ObjC and it will disable their
formatting
According to clang documentation
(https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code), we can disable formatting inline.
However, comments in Matlab are prefixed with `%` and not `//`, so I
thought of a kinda hacky solution, which is `% // clang-format off`, and
it works perfectly.
No-Iwyu: Includes didn't change and it isn't related to formatting
Bug: webrtc:42225392
Change-Id: I281462fd1aecd3ff0428e6ee974514ebabc696ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374060
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43700}
After applying this change, I reformatted the previously formatted files
and verified no changes were applied.
Bug: webrtc:42225392
Change-Id: I6079e1e85d94ae2bc892db1db81bc8223b3a08b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374040
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43698}
Update unit tests to follow video_rtp_depacketizer_h264's behavior of
setting is_first_packet_in_frame. This flag might be used to determine
if a frame can be assembled.
Bug: webrtc:384391181
Change-Id: I6750c20056e426e12c1d4e21eea4c641def7cfbd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/373168
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43669}
Follow H.265 spec section 7.4.2.4.4 to set is_first_packet_in_frame flag
in rtp header, to make sure we only set it to true when corresponding
NALU can be the first NALU in a frame.
Bug: chromium:384391181
Change-Id: I082c38513d9d213f8d354633539028b57777368f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372742
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@{#43651}
When echo controller factories are updated, it would be possible to pass Environment into EchoCanceller3 and thus rely on propagated field trials.
Bug: webrtc:369904700
Change-Id: Iba9c04edbaab23277874234bd289e2c37625b1c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372040
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43614}
There is one RTCP receiver per receive stream. Therefore, only handle a
received CongestionControlFeedback in the RTCP receiver corresponding to
the first SSRC in the report.
Bug: webrtc:42225697
Change-Id: I9bc0009cb6840cddeaca25f39c597bc2c13a3604
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372280
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43613}
With this CL, the decision if an RTP packet should be sent as ect(1) is made in RtpControllerSend depending on if RFC 8888 has been negotiated and if CCFB is received with ECN enabled.
Since webrtc does not yet adapt to ECN feedback, packets are sent as ECT(1) until the first feedback is received.
Change-Id: Iddf63849328afbe54a7c8f921f2e8db134aeff6a
Bug: webrtc:42225697
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367388
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43609}
