This CL ensures that each DesktopFrame's updated-region is expressed in
the frame's own coordinates, where the top-left is always (0, 0).
For example, DesktopFrame::GetFrameDataAtPos() and its callers use
this coordinate system.
Previously, whenever a RANDR monitor with a non-zero offset was
selected, ScreenCapturerX11 would hit some DCHECKs when trying to
copy pixels from previous frames, or when capturing new pixels into
them from XDAMAGE regions.
Bug: None
Change-Id: I7b2e8d0449359ee7b263ad60af193e2bf89aa1f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232085
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35017}
When there is no outstanding data, then next TSN to allocate should
always be one more than what the client has last ACKed.
Bug: None
Change-Id: Ieb8b5b23912d77d96fe3749fb53fd53652d97066
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232002
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35016}
The buffer of reassembled messages in ReassemblyQueue is only to be
used while processing a DATA/I-DATA or FORWARD-TSN as processing these
chunks may result in assembling messages.
When the socket is idle - between API calls - it's supposed to be empty.
Instead of having it as a member in ReassemblyQueue, it could be
provided as an argument to ReassemblyQueue::Add and
ReassemblyQueue::Handle(ForwardTSN), but that would be a quite big
refactoring. That will be investigated separately.
Bug: None
Change-Id: I41238de28f32f2a622c1d045debe3ea11e7c23f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232000
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35014}
The ReassemblyQueue will need to track which messages that have already
been delivered to the client so that they are not re-delivered on e.g.
retransmissions. It does that by tracking which TSNs that those messages
were built from. It tracks that in two variables,
`last_assembled_tsn_watermark` and `delivered_tsns_`, where the first
one represent that all TSNs including and prior this one have been
delivered and `delivered_tsns` contain additional ones when there are
gaps.
When receiving a FORWARD-TSN and asked to forget about some partially
received messages, these two variables were updated correctly, but the
`delivered_tsns_` were left in a state where it could be adjacent to the
`last_assembled_tsn_watermark` - when `last_assembled_tsn_watermark`
could actually have been moved further.
Added consistency check (that would trigger in existing tests) and
fixing the issue.
This bug is quite benign, as any received chunk would've corrected the
problem, and even at this faulty state, the ReassemblyQueue would
function completely fine.
Bug: webrtc:13154
Change-Id: Iaa7c612999c9dc609fc6e2fb3be2d0bd04534c90
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232124
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Sergey Sukhanov <sergeysu@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35013}
This makes it possible to invoke methods on the transceiver object
from any thread.
Also makes a few of the mock observer objects thread-safe, to allow
testing when the main thread is not the signaling thread.
Bug: webrtc:13183
Change-Id: Ic97efef71a21c3075700a028103061032f8d2bcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232120
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35010}
GCC complains that explicit specialization in non-namespace scope
is happening for webrtc::BitstreamReader::Read(). However,
specializationvfor bool isn't used because std::is_unsigned<bool>::value
returns true. Add std::is_same for bool check and enable second
specialization only for bool types.
Bug: chromium:819294
Change-Id: I1873cd59e2737516bd4012fb952da65d6bf3172b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231561
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35007}
This patch adds VPN detection for windows
based on known MAC addresses.
- Cisco AnyConnect
- GlobalProtect Virtual Ethernet
Bug: webrtc:13097
Change-Id: Ia90ee50be0dc2dcd2e6e9de1493fdd2c5e7d9d3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230245
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34997}
The custom callback is intended to override errors, so there's no
point in calling it if the status is ok.
Calling it during an otherwise successful verification was an
unintentional change from:
https://webrtc-review.googlesource.com/c/src/+/196941
This is misleading as the return value isn't even used.
Bug: chromium:1247577
Change-Id: Id74411f7364537a3225021e7631bc9ab962889ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231881
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34994}
The nack threshold feature is unlikely to provide any value, since
reordered packets are rare. This CL also removes the factory method
from the NackTracker class, since it did not add much value.
Bug: webrtc:10178
Change-Id: Ib6bece4a2d9f95bd4298799aaa15627f5c014b61
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231953
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34993}
On the Android and iOS platforms, occasionally crash when using the SimulcastEncoderAdapter.
The Android platform reverted,
In function `SimulcastEncoderAdapter::EncoderContext::Release`,
After executing `encoder_->RegisterEncodeCompleteCallback(nullptr)`
before execute `encoder_->Release()`
If the encoder thread is executed here,
```
// out/xxx/xxx/gen/sdk/android/generated_video_jni/VideoEncoderWrapper_jni.h
JNI_GENERATOR_EXPORT void Java_org_webrtc_VideoEncoderWrapper_nativeOnEncodedFrame(
JNIEnv* env,
jclass jcaller,
jlong nativeVideoEncoderWrapper,
jobject frame) {
VideoEncoderWrapper* native = reinterpret_cast<VideoEncoderWrapper*>(nativeVideoEncoderWrapper);
CHECK_NATIVE_PTR(env, jcaller, native, "OnEncodedFrame");
return native->OnEncodedFrame(env, base::android::JavaParamRef<jobject>(env, frame)); // HERE
}
```
it will cause `native` to nullptr.
iOS also.
Bug: webrtc:13156
Change-Id: Id5563b3fa2c11606ae7b35de56bbaa6adba59b14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231780
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34989}
This is tested by a simple unit test and a new fuzzer that verify that all that can be parsed also can be written.
Bug: webrtc:12000
Change-Id: I461aedf97d3dec6e8916e72110fa097c3b31c27f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231642
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34986}
This is done by not adding missing packets to the NACK list if the number of samples per packet is too large.
Bug: webrtc:10178
Change-Id: If46398d6d05ea35f30d7028040d3b808559e950b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231841
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34984}
The documentation for `OpenPipeWireRemote()` says:
> Open a file descriptor to the PipeWire remote where the camera nodes
> are available. The file descriptor should be used to create a
> pw_core object, by using pw_context_connect_fd.
In `InitPipeWire()` we already successfully requested the FD, but then
went on and used the unrestricted default socket.
This does not matter in non-sandboxed environments, as the stream we
want to use is available from both FDs. In flatpak sandboxes, however,
this requires to give full Pipewire access to the application.
Fix this by simply using the right, restricted FD, and while on it,
also make sure to not leak it.
This change has already landed in downstream in Firefox, see
https://phabricator.services.mozilla.com/D122904https://phabricator.services.mozilla.com/D124508
Bug: webrtc:13152
Change-Id: I3f8995c54c797e1a90a980f231e496a13cbe65b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230803
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34983}
The VP9 encoder may drop a frame internally which will not advance the
frame pattern. Consider the following scenario where only spatial layer
0 and temporal layer 0 is active:
1. Key frame encoded
2. Spatial layer 1 is activated
3. Delta T0 dropped
4. Delta T0 encoded
No S1T0 frame is encoded in (1) since it's not active. When
NextFrameConfig is called in (3) it will say that future frames may
reference T0 on both S0 and S1, but it's then dropped.
On step (4), the SVC controller essentially thinks it's encoding a new
picture and will happily reference the T0 on what it thinks is the first
delta frame. However, this is actually still the key frame and since
there was no S1T0 frame produced it will reference an invalid buffer.
To fix this, only say it's possible to reference a T0 frame after it has
been successfully encoded.
Bug: webrtc:11999, webrtc:13142, chromium:1178444
Change-Id: Iab3d2042ce0b3fa7d952b2831d1a36b1a6613a86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34982}
Unlike libvpx, the VideoBitrateAllocation expects that the bitrate
allocation is separate for each temporal layer. In this instance, if the
bitrates are not separated it will fool the SVC controller into thinking
that all temporal layers are always active.
Bug: webrtc:11999
Change-Id: Ibc33ac00b8b7716c011b94e1ec9c640cedb5274e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231693
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34980}
