This would allow network controllers, GoogCcNetworkController in particular to have access to Environment at construction and thus it can rely on propagated field trials and won't need to fallback to the global field trial string
Bug: webrtc:42220378
Change-Id: I36099522e3866a89a8c8d6303da03f7d5b1cad8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350201
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42260}
This adds a new mode to the ProbeController that sends probes every
second the first 5seconds. Intented usage is before normal media has
started flowing. If enabled, the max allocated bitrat is ignored during
these initial probes.
The purpose is to have a more accurate estimate at the beginning of a
call.
The cl also removes ProbeController::SetFirstProbeToMaxBitrate.
Bug: webrtc:14928
Change-Id: I04feefb2f1b82ff38b35ee2be810f9119c53536a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349924
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42252}
This reverts commit 501c4f37bf.
Patch set 1 contains pure reland.
The reason why we want to do this is because audio can allocate a needed bitrate before video when starting a call, which may lead to a race between the first probe result and updating the allocated bitrate.
That is the, initial probe will try to probe up to the max configured bitrate.
Bug: webrtc:14928
Change-Id: I6a8660da20ac54237f04a29461e03b31bd988bb0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347643
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Erik Språng <sprang@google.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42086}
This reverts commit 33cc83595a.
Reason for revert: Perf bots showed that this cl cause a change in metrics. It looks like it is for the better, but we want this to be behind a field trial.
Original change's description:
> Ignore allocated bitrate during initial exponential BWE.
>
> The reason why we want to do this is because audio can allocate a needed bitrate before video when starting a call, which may lead to a race between the first probe result and updating the allocated bitrate.
> That is the, initial probe will try to probe up to the max configured bitrate.
>
> ProbeController::SetFirstProbeToMaxBitrate will allow the first probe to
> continue up to the max configured bitrate, regardless of of the max
> allocated bitrate.
>
> Bug: webrtc:14928
> Change-Id: I6e0ae90e21a78466527f3464951e6033dc846470
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346760
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#42049}
Bug: webrtc:14928
Change-Id: I56ba58560b6857b6069552c02df822691f7af64d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347622
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42081}
The reason why we want to do this is because audio can allocate a needed bitrate before video when starting a call, which may lead to a race between the first probe result and updating the allocated bitrate.
That is the, initial probe will try to probe up to the max configured bitrate.
ProbeController::SetFirstProbeToMaxBitrate will allow the first probe to
continue up to the max configured bitrate, regardless of of the max
allocated bitrate.
Bug: webrtc:14928
Change-Id: I6e0ae90e21a78466527f3464951e6033dc846470
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346760
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42049}
With this cl
RtpTransportControllerSend::OnAddPacket is instead directly invoked from PacketRouter::SendPacket instead of going via RTP module.
Transport sequence numbers are instead of directly written to header
extension, added to RtpPacketToSendMetaData and written to the extenion
by RTP module.
This is to allow transport sequence numbers without actually sending
them in an extension.
Bug: webrtc:15368
Change-Id: Idd03e02a4257dfc4d0f1898b2803345975d7dad2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344720
Reviewed-by: Erik Språng <sprang@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41974}
RtpTransportControllerSend has access to the same Environment as the caller, and thus can take RtcEventLog directly from it.
Bug: None
Change-Id: I4b20811d3f6de8193c63d6c58d0fe1204b3ec7b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342040
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41864}
Using the Api, BWE components are recreated and new settings can be
applied. Initially, the only configuration available is allowing BWE probes without media".
Note that BWE components are created when transport first becomes writable. So calling this method before a PeerConnection is connected is cheap and only changes configuration.
Integration test in https://webrtc-review.googlesource.com/c/src/+/337322
Bug: webrtc:14928
Change-Id: If2c848489bf94a1f7a5ebf90d2886d90c202c7c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/336240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41687}
If allow_bandwidht_estimation_probe_without_media is true and a writable
video rtp stream with RTX exist, a probe can be sent immediately without
waiting for a large media packet.
Bug: webrtc:14928
Change-Id: Ie2204734f9fe3e6bff9aed4a1f7f8995956d35cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/336000
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41626}
Rename RtpVideoSender::SetActiveModules to SetSending to better match
what it does. When a RtpVideoSender::SetSending(true) RTP packets can be
sent on all associcated RTP streams (simulcast streams).
Move registration of RtpRtcpModules to RtpTransportControllerSend to
allow RtpTransportControllerSend to know when there are sending RTP
streams. Purpose is to in later CLs allow RtpTransportControllerSend to
trigger BWE probes.
Bug: webrtc:14928
Change-Id: Ibf6c040b86713cdc4763c4691b7fd794b251eb49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335961
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41620}
RtpTransportControllerSend uses all 4 utilities of the environment and
thus cleaner to propagate them as single parameter instead of 4 separate
Bug: None
Change-Id: I38932c21a73ea41d4bdf2fa04bf3961a2adb25a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331821
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41422}
This allow exernal applications to control how many packets can be sent relative current BWE.
This is a partial revert of https://webrtc-review.googlesource.com/c/src/+/311102
Bug: chromium:1354491
Change-Id: Ia236aaacc468ddac12341efa555041bb2dfdde62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330580
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41343}
PacingController per default use a burst interval of 40ms. The behaviour can still be overriden by using the method SetSendBurstInterval.
Bug: chromium:1354491
Change-Id: Ie3513109e88e9832dff47380c482ed6d943a2f2b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311102
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41254}
Expect OnNetworkAvailabability to be invoked when the transport becomes writable.
Before this change, ProbeController in GoogCC was expected to be created when the transport is writable or explicitly notifed after creation that network is not writable.
Bug: None
Change-Id: I623b1c34e40a82e912f85b92fea49629e7e72d4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323463
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40975}
NetworkLinkRtcpObserver is similar to RtcpBandwidthObserver but pass
time variables using unit types instead of raw integers.
Bug: webrtc:13757
Change-Id: Iaa0bbe0b108620b3a24013c40e7d9004032e904d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305022
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40087}
Store just the fields that are used by RtpTransportController
Avoid redundand map lookup when updating that information
Bug: webrtc:13757
Change-Id: I1e5a000557bde1735979c1cf8fa762936a64ffd0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305023
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40063}
This CL removes a PostTask in response to packet receipt reception.
This is made possible due to PacketRouter lock removal in
https://webrtc-review.googlesource.com/c/src/+/300964.
Depending on how transport code is organized, this may lead to
possibility of packet receipts arriving in
RtpTransportControllerSend which may re-enter the PacingController's
ProcessPackets method, leading to out-of-order packet sends. Fix
this by detecting re-entry and avoiding a second ProcessPackets call
in the TaskQueuePacedSender.
Bug: chromium:1373439
Change-Id: I24928f2d28a240d0860fe7e4a114cedf1f13d2bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304580
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40017}
MaybeWorkerThread* GetWorkerQueue() and is removed.
Instead all work is expected to be done on the taskqueue used when
creating the RtpTransportControllerSend.
Bug: webrtc:14502
Change-Id: Iedc30efb8de7592611d6d3c5b5c6cd33c17a60c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300867
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39872}
This remove use of MaybeWorkerThread from TaskQueuePacedSender. Instead,
the TaskQueue used when creating the TaskQueuePacedSender is used for
pacing. That is, the "worker thread".
Bug: webrtc:14502
Change-Id: I504f8e634653af6493e609db6e42b07d488fd699
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/300820
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39813}
Under the combined network/worker thread project, tasks
are unnecessarily posted to the same thread.
This CL reaps 90% overhead savings in sent packet feedback
as measured with Perfetto under a 49p Meet call.
The identity of the posted calls was uncovered with WebRTC/Chrome's
new location-aware tracing.
TESTED=presubmit + local Meet calls.
Bug: chromium:1373439
Change-Id: I0c43aa4de884831838747d52b21c45fd360106e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295780
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39484}
Removes the last unused field trial parameters, the legacy pacer code
was removed some time ago so the main flag feature has been a noop
since then.
Bug: None
Change-Id: I5266d54fccb4c5fde05a6895072cd76cd5f7fbd9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293349
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39310}
Address perkj's comments left in
https://webrtc-review.googlesource.com/c/src/+/283420. I was a bit
trigger-happy with the submit button.
Bug: chromium:1354491
Change-Id: Ifd052f75af3763b0b52807c31ea790e3efee921d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283521
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38638}
BurstyPacer is currently controlled via field trials. In order for
Chrome to be able to have burst without relying on a field trial, this
parameter is added.
When all burst experiments have concluded we may be able to have a
hardcoded constant instead, but for now the parameter is added to
RTCConfiguration.
NOTRY=True
Bug: chromium:1354491
Change-Id: I386c1651dbbcbf309c15ea3d3380cf8f632b5429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283420
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38621}
This spills to a few more clasess....
Change-Id: Iea79e3b4ac86b30db6f13da89a47ab7000c5440a
Bug: webrtc:14502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277803
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38334}
Instead of re-using the sender task queue, a new task queue will
suffice.
Bug: webrtc:14445
Change-Id: Ia7395ace2f0bb66bf9e76e3783b208f2cd0385dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275771
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38332}
Instead of using field trials in BitrateProber for probe duration, use values provided in ProbeClusterConfig from GoogCC.
Field trials are instead read in ProbeController.
To avoid having to do a thread jump for every ProbeClusterConfig, RtpPacketPacer interface is changed to RtpPacketPacer::CreateProbeClusters(std::vector<ProbeClusterConfig>
Deprecates field trial "WebRTC-Bwe-ProbingConfiguration"
Change-Id: I3991e4b54770601855a3af2d6a16678f11d41c31
Bug: webrtc:14027
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261265
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36911}
The new TaskQueuePacedSender has been default-on in code since M97, and
there are no further usages of it that I can find. Let's clean this up!
The PacingController and associated tests will be cleaned up in a
follow-up cl.
Bug: webrtc:10809
Change-Id: I0cb888602939add953415977ee79ff0b3878fea5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258025
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36890}
Default holdback-window for non-prio packets is now 5ms, or the expected
pacing time for 3 packets if lower.
This brings wakeup frequency in line with legacy pacer at medium to low
packet rates.
Bug: webrtc:10809
Change-Id: I4045c40ae6b6d50f1ea049f3a26768023f77ec3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257301
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36397}
Update `early_execute_margin` after process packets, and the test case.
Original change's description:
>Pacer: Reduce TQ wake up and improve packet size estimation
>
>The TQ Pacer schedules delayed task according to target time of
>PacingController. It drains all valid ProcessPackets() in single loop,
>denies retired scheduled tasks, and round up the timeout to 1ms.
>
>This CL also improves packet size estimation in TQ Pacer by removing
>zero initialization, and introduces `include_overhead_` configuration.
>
>Tests:
>1. webrtc_perf_tests: MaybeProcessPackets() calls
> 2075147 -> 2007995
>
>2. module_unittests: MaybeProcessPackets() calls
> 203393 -> 183563
>
>3. peerconnection_unittests: MaybeProcessPackets() calls
> 66713-> 64333
>
>Bug: webrtc:13417, webrtc:13437
>Change-Id: I18eb0a36dbe063c606b1f27014df74a65ebfc486
>Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242962
>Reviewed-by: Erik Språng <sprang@webrtc.org>
>Reviewed-by: Henrik Boström <hbos@webrtc.org>
>Commit-Queue: Erik Språng <sprang@webrtc.org>
>Cr-Commit-Position: refs/heads/main@{#36179}
Bug: webrtc:13417, webrtc:13437
Change-Id: I79f2554cf02364b67ce7073698611a3ae337a73b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256145
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Owners-Override: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36283}
When congestion window is used, two different mechanisms can currently
update the outstanding data state in the pacer:
* OnPacketSent() withing the pacer itself, when a packet is sent
* UpdateOutstandingData(), when RtpTransportControllerSend either:
a. Receives an OnPacketSent() callback (increase outstanding data)
b. Receives transport feedback (decrease outstanding data)
This creates a lot of calls to UpdateOutstandingData(), more than one
per sent packet. Each requires locking and/or thread jumps. To avoid
that, this CL moves the congestion window state to
RtpTransportController send - and we only post a congested flag down
the the pacer when the state is changed.
The only benefit I can see is of the old way is we prevent sending
new packets immedately when the window is full, rather than in some
edge cases queue extra packets on the network task queue before the
congestion signal is received. That should be rare and benign.
I think this simplified logic, which is easier to read and more
performant, is a better tradeoff.
Bug: webrtc:13417
Change-Id: I326dd88db86dc0d6dc685c61920654ac024e57ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/255600
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36220}
This CL also removes dependency on the legacy field trial methods.
Bug: webrtc:11926
Change-Id: I53feeee86b92878cf0f2b8ebdce3d101f9e04014
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/255381
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36205}
The TQ Pacer schedules delayed task according to target time of
PacingController. It drains all valid ProcessPackets() in single loop,
denies retired scheduled tasks, and round up the timeout to 1ms.
This CL also improves packet size estimation in TQ Pacer by removing
zero initialization, and introduces `include_overhead_` configuration.
Tests:
1. webrtc_perf_tests: MaybeProcessPackets() calls
2075147 -> 2007995
2. module_unittests: MaybeProcessPackets() calls
203393 -> 183563
3. peerconnection_unittests: MaybeProcessPackets() calls
66713-> 64333
Bug: webrtc:13417, webrtc:13437
Change-Id: I18eb0a36dbe063c606b1f27014df74a65ebfc486
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242962
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36179}
This is a reland of 9d230d54c7
Original change's description:
> (Un/)Subscribe RtpVideoSender for feedback on the transport queue.
>
> * RtpVideoSender now registers/unregisters for feedback callback
> inside of SetActive(), which runs on the transport queue.
> * Transport feedback is given on the transport queue
> * Registration/unregistration for feedback is done on the same
> * Removed the last mutex from TransportFeedbackDemuxer.
>
> Ultimately, this work is related to moving state from the Call
> class, that's related to network configuration, but due to the code
> is currently written is attached to the worker thread, over to the
> Transport, where it's used (e.g. suspended_video_send_ssrcs_).
>
> Bug: webrtc:13517, webrtc:11993
> Change-Id: I057d0e2597e6cb746b335e0308599cd547350e56
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/248165
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35777}
Bug: webrtc:13517, webrtc:11993
Change-Id: I766e569abea8bae96d32267a951fcdc195ced8a7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249782
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35863}
This reverts commit 9d230d54c7.
Reason for revert: Speculative revert to see if it's the cause of a few perf changes (some bad, some not so bad).
Bug: webrtc:13613
Original change's description:
> (Un/)Subscribe RtpVideoSender for feedback on the transport queue.
>
> * RtpVideoSender now registers/unregisters for feedback callback
> inside of SetActive(), which runs on the transport queue.
> * Transport feedback is given on the transport queue
> * Registration/unregistration for feedback is done on the same
> * Removed the last mutex from TransportFeedbackDemuxer.
>
> Ultimately, this work is related to moving state from the Call
> class, that's related to network configuration, but due to the code
> is currently written is attached to the worker thread, over to the
> Transport, where it's used (e.g. suspended_video_send_ssrcs_).
>
> Bug: webrtc:13517, webrtc:11993
> Change-Id: I057d0e2597e6cb746b335e0308599cd547350e56
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/248165
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35777}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:13517, webrtc:11993
Change-Id: I824623b3b1c14f0ca7049a2a0890c6d97b7fb608
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249600
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35815}
* RtpVideoSender now registers/unregisters for feedback callback
inside of SetActive(), which runs on the transport queue.
* Transport feedback is given on the transport queue
* Registration/unregistration for feedback is done on the same
* Removed the last mutex from TransportFeedbackDemuxer.
Ultimately, this work is related to moving state from the Call
class, that's related to network configuration, but due to the code
is currently written is attached to the worker thread, over to the
Transport, where it's used (e.g. suspended_video_send_ssrcs_).
Bug: webrtc:13517, webrtc:11993
Change-Id: I057d0e2597e6cb746b335e0308599cd547350e56
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/248165
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35777}
Before, this call was being made from the SendPacket path of the
pacer. The transport will post a task to the transport queue regardless
so this change moves the lock inside of the demuxer away from the
pacer and over to the transport queue.
Moving forward, the calls to register/unregister with the feedback
demuxer, will occur on the transport queue as well and we can change
the transport OnTransportFeedback() implementation to forward the
calls to the demuxer on the transport queue as well. That will bring
all calls into the same execution context and we won't need a lock.
Bug: webrtc:13517, webrtc:11993
Change-Id: If714ca6d2b164a1a2b6bcb8c99787372064a31a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/248164
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35775}
`TransportFeedbackAdapter` return NULL indicates outstanding data is
unchanged. This CL excludes outgoing retransmitted packets, rtcp packets
and invalid transport feedbacks to wakeup pacer.
Bug: webrtc:13417
Change-Id: Ie94956232c13cd548bb7038b5ce76617756fb207
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238741
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35485}
