RtpVideoSender::OnVideoLayersAllocationUpdated runs on the encoder thread,
checks if it's active, and then posts a task to the transport queue to
update module status.
If SetSending(false) is called on the transport queue before the posted
task runs, the task would previously re-register modules in PacketRouter
even though active_ was false. This lead to dangling pointers in
PacketRouter when the RtpVideoSender was destroyed.
This CL adds an IsActive() check inside the posted task to ensure we don't
re-register modules if the sender has been deactivated.
(cherry picked from commit 77d265670fa7d7f358c86c54704a6e97c27a6005)
Bug: chromium:500767595
Test: RtpVideoSenderTest.PostTaskRaceDoesNotLeadToDanglingPointer
Change-Id: I18827c34bece7f5ebc41d159d9e19e356afbc404
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/462880
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#47384}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/465960
Cr-Commit-Position: refs/branch-heads/7680@{#8}
Cr-Branched-From: d1972add2a63b2a528a6471d447f82e0010b5215-refs/heads/main@{#46853}
RtpVideoSender::OnVideoLayersAllocationUpdated runs on the encoder thread,
checks if it's active, and then posts a task to the transport queue to
update module status.
If SetSending(false) is called on the transport queue before the posted
task runs, the task would previously re-register modules in PacketRouter
even though active_ was false. This lead to dangling pointers in
PacketRouter when the RtpVideoSender was destroyed.
This CL adds an IsActive() check inside the posted task to ensure we don't
re-register modules if the sender has been deactivated.
(cherry picked from commit 77d265670fa7d7f358c86c54704a6e97c27a6005)
Bug: chromium:500767595
Test: RtpVideoSenderTest.PostTaskRaceDoesNotLeadToDanglingPointer
Change-Id: I18827c34bece7f5ebc41d159d9e19e356afbc404
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/462880
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#47384}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/465961
Cr-Commit-Position: refs/branch-heads/7778@{#5}
Cr-Branched-From: ca896b7ffef011bbf6957c99d413c5aac602c99f-refs/heads/main@{#47319}
Update RtpDemuxer to permit signaled SSRCs to override existing learned
SSRC bindings. This prevents registration failures during session
renegotiation when an SSRC, previously identified through payload type
demuxing, is subsequently explicitly signaled.
The demuxer now maintains a set of signaled SSRCs to differentiate
explicit configurations from learned state. Conflict detection is
modified to allow these overrides while maintaining strict checks
between multiple signaled SSRCs. This ensures that explicit signaling
always takes precedence over internally learned bindings, resolving
routing issues during media stream updates.
(cherry picked from commit 186d42a3010981882a8679a145ce36aa84581c78)
Fixed: chromium:503666505
Bug: webrtc:502130956
Change-Id: I551c2b7ee5af18fc9792ee52be08c5349c20b641
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/464220
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Original-Commit-Position: refs/heads/main@{#47446}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/464764
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/branch-heads/7778@{#2}
Cr-Branched-From: ca896b7ffef011bbf6957c99d413c5aac602c99f-refs/heads/main@{#47319}
Shift the responsibility for enabling and disabling payload type
demuxing from the Channel and Transceiver layers to the RtpTransport and
RtpDemuxer layer. This centralizes demuxing logic within the transport
layer.
Moving this logic to RtpTransport allows the SdpOfferAnswerHandler to
apply state changes directly to the transport and not need to go through
the Channel classes.
Key modifications:
- Remove SetPayloadTypeDemuxingEnabled from BaseChannel,
ChannelInterface, and RtpTransceiver.
- Implement SetActivePayloadTypeDemuxing in RtpTransport to manage
demuxer criteria filtering and coordinate with RtpDemuxer.
- Update SdpOfferAnswerHandler to apply demuxing state changes to
RtpTransport instances directly.
- Ensure ResetUnsignaledRecvStream executes on the worker thread
after applying transport state, to clear legacy streams when
demuxing is disabled.
Bug: webrtc:42222117
Change-Id: If02194417dc8e4c3dcf5fda5e969aa81116004e1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/456720
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47318}
ArrayView is an alias to std::span. This change switch to use
std::span directly instead of through the alias.
Search&Replace MakeArrayView and ArrayView with std::span
Search&Replace include "api/array_view.h" with include <span>
Remove <span> include where std::span is not mentioned in the file
Remove build dependencies on array_view target
Bug: webrtc:439801349
Change-Id: I64bbdcf1300126286158ccbeda62c49e0c3ec83f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/460501
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47294}
Also replace "int" with "PayloadType" in a number of interfaces, and
make appropriate adjustments.
This is one step towards controlling the issuing and consumption
of PayloadType values.
Bug: webrtc:360058654
Change-Id: I146bc4e3e9966b98864277eee6f52b75ba10d89a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/460021
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47286}
There was a pattern of having to cast these to size_t when comparing
them to sizes of things. Since these are mostly used for sizing
arrays and lists, it seems logical to make them size_t.
Bug: None
Change-Id: I77e0642dfc0937e6367034af10b27f1ba95b495b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/459400
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47281}
This reverts commit e844bd819c.
Reason for revert: Maybe breaks downstream projects
Original change's description:
> Allow unspecified max allocatable bitrate in VideoSendStreamImpl
>
> If we have no video the can be enabled, based on the VideoEncoderConfig
> (e.g. the max bitrate is <= 0 or all simulcast streams are
> `active=false`) - let the max bitrate be reported as 0 for the sake of
> bandwidth allocation (MediaStreamAllocationConfig).
>
> Previous to this CL, the above conditions would result in an arbitrary
> value of 10Mbps to use as the max allocation limit. When creating a peer
> connection with audio and video configured but the video disabled/muted,
> that would result in the bandwidth estimator trying to send packet
> trains to probe up to 10Mbps, potentially impacting the network and
> disturbing audio even though we have no need for such as high BWE.
>
> Bug: webrtc:494350649
> Change-Id: Id6353fd93c6170610a790c084d75f3b3c5c3ee97
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/449100
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#47220}
Bug: webrtc:494350649
Change-Id: Id3accec77f8bde51c43c3eeb31db68d4f03f7754
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/458722
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47228}
If we have no video the can be enabled, based on the VideoEncoderConfig
(e.g. the max bitrate is <= 0 or all simulcast streams are
`active=false`) - let the max bitrate be reported as 0 for the sake of
bandwidth allocation (MediaStreamAllocationConfig).
Previous to this CL, the above conditions would result in an arbitrary
value of 10Mbps to use as the max allocation limit. When creating a peer
connection with audio and video configured but the video disabled/muted,
that would result in the bandwidth estimator trying to send packet
trains to probe up to 10Mbps, potentially impacting the network and
disturbing audio even though we have no need for such as high BWE.
Bug: webrtc:494350649
Change-Id: Id6353fd93c6170610a790c084d75f3b3c5c3ee97
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/449100
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47220}
This CL moves the usage of receive_time_calculator_ in Call from the
worker thread to the network thread. It extracts the worker thread logic
of DeliverRtpPacket into DeliverRtpPacket_w to allow clearer thread
annotations.
Also includes new g3doc for a simple overview of the RTP receive flow.
Bug: webrtc:11993
Change-Id: I143a548888474b4ebd14a9041d5cb649738e0775
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/454304
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47119}
This refactoring replaces the EncoderSwitchRequestCallback interface
with absl::AnyInvocable in VideoStreamEncoderSettings.
To ensure the callback survives stream recreation, the callback binding
has been moved to RecreateWebRtcStream, relying on a new `send_channel_`
back-pointer within WebRtcVideoSendStream.
Bug: b/478050997
Change-Id: I1f587d563553c4f2f3d8fd02c4d9ed4473829dc4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/454480
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47087}
This is achieved by moving most anonymous namespaces inside the
webrtc namespace and modifying as appropriate.
Bug: None
Change-Id: Iff299c45f92ae5aaa736722ed6630df9ad5525bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/454240
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47077}
Update the pre-decoding part of the RTP packet receive pipeline to allow
DeliverRtpPacket to be called from either the network or worker thread
(network thread preferred moving forward).
This is a step towards moving the full packet processing pipeline to the
network thread. In practical terms, this removes one PostTask for audio
packets when the network and worker threads are configured to be the
same. Architecturally, this moves the PostTask from network to worker,
out of the voice/video receive channel classes and into call (by 1
step).
Key modifications:
* Update Call::DeliverRtpPacket to automatically dispatch tasks to the
worker thread if it is invoked from a different context.
* Shift RtpPacketReceived processing in WebRtcVideoReceiveChannel and
WebRtcVoiceReceiveChannel to the network thread.
* Relocate recv_rtp_extension_map_ to be guarded by the network thread
checker, ensuring header extension identification occurs immediately
upon packet receipt.
* Synchronize extension map updates from the worker thread to the
network thread using a safe task-posting mechanism.
* Modify OnPacketReceived signatures to accept packets by value,
enabling efficient moves across thread boundaries.
Bug: webrtc:11993, chromium:40242052
Change-Id: I2bf80a67632cee6bd553009ea9523499527bc93e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/452900
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#47026}
