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}
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}
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}
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}
Holdback window can be specified as absolute time and in terms of packet
send times. Example:
WebRTC-TaskQueuePacer/Enabled,holdback_window:20ms,holdback_packet:3/
If current conditions have us running with 2000kbps pacing rate and
1250byte (10kbit) packets, each packet send time is 5ms.
The holdback window would then be min(20ms, 3*5ms) = 15ms.
The default is like before 1ms and packets no take into account when
TQ pacer is used, parameters have no effect with legacy process thread
pacer.
Bug: webrtc:10809
Change-Id: I800de05107e2d4df461eabaaf1ca04fb4c5de51e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233421
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35266}
* Make VideoSendStream and VideoSendStreamImpl construction non-blocking.
* Move ownership of the rtp video sender to VideoSendStream.
* Most state is constructed in initializer lists.
* More state is now const (including VideoSendStreamImpl ptr)
* Adding thread checks to classes that appear to have had a race before
E.g. RtpTransportControllerSend. The change in threading now actually
fixes an issue we weren't aware of.
* Moved from using weak_ptr to safety flag and made some PostTask calls
cancellable that could potentially have been problematic. Initalizing
the flag without thread synchronization is also simpler.
This should speed up renegotiation significantly when there are
multiple channels. A follow-up change will improve SetSend as well
which is another costly step during renegotiation.
Bug: webrtc:12840
Change-Id: If4b28da5a085643ce132c7cfcf80a62cd1a625c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221105
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34224}
This is a reland of 89cb65ed66
... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
... and 2072b87261
Reason for revert: Failing DuoGroupsMediaQualityTest due to missing
TaskQueuePacedSender::EnsureStarted() in google3.
Fix: This CL adds the logic behind TaskQueuePacedSender::EnsureStarted,
but initializes with |is_started| = true. Once the caller in google3 is
updated, |is_started| can be switched to false by default.
> Original change's description:
> Reason for revert: crashes due to uninitialized pacing_bitrate_
> crbug.com/1190547
> Apparently pacer() is sometimes being used before EnsureStarted()
> Fix: Instead of delaying first call to SetPacingRates(),
> this CL no-ops MaybeProcessPackets() until EnsureStarted()
> is called for the first time.
> Original change's description:
> > [Battery]: Delay start of TaskQueuePacedSender.
> >
> > To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> > only upon RtpTransportControllerSend::EnsureStarted().
> >
> > More specifically, the repeating task happens in
> > TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> > task_queue_.PostDelayedTask().
> >
> > Bug: chromium:1152887
> > Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33421}
>
> Bug: chromium:1152887
> Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#33554}
Bug: chromium:1152887
Change-Id: Ie365562bd83aefdb2757a65e20a4cf3eece678b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213000
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33629}
This reverts commit 2072b87261.
Reason for revert: Causing test failure.
Original change's description:
> Reland "[Battery]: Delay start of TaskQueuePacedSender." Take 2
>
> This is a reland of 89cb65ed66
> ... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
>
> Reason for revert: crashes due to uninitialized pacing_bitrate_
> crbug.com/1190547
> Apparently pacer() is sometimes being used before EnsureStarted()
> Fix: Instead of delaying first call to SetPacingRates(),
> this CL no-ops MaybeProcessPackets() until EnsureStarted()
> is called for the first time.
>
> Original change's description:
> > [Battery]: Delay start of TaskQueuePacedSender.
> >
> > To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> > only upon RtpTransportControllerSend::EnsureStarted().
> >
> > More specifically, the repeating task happens in
> > TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> > task_queue_.PostDelayedTask().
> >
> > Bug: chromium:1152887
> > Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33421}
>
> Bug: chromium:1152887
> Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#33554}
TBR=hbos@webrtc.org,sprang@webrtc.org,etiennep@chromium.org
Change-Id: I430fd31c7602702c8ec44b9e38e68266abba8854
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1152887
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212965
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33559}
This is a reland of 89cb65ed66
... and f28aade91dcc2cb8f590dc1379ac7ab5c1981909
Reason for revert: crashes due to uninitialized pacing_bitrate_
crbug.com/1190547
Apparently pacer() is sometimes being used before EnsureStarted()
Fix: Instead of delaying first call to SetPacingRates(),
this CL no-ops MaybeProcessPackets() until EnsureStarted()
is called for the first time.
Original change's description:
> [Battery]: Delay start of TaskQueuePacedSender.
>
> To avoid unnecessary repeating tasks, TaskQueuePacedSender is started
> only upon RtpTransportControllerSend::EnsureStarted().
>
> More specifically, the repeating task happens in
> TaskQueuePacedSender::MaybeProcessPackets() every 500ms, using a self
> task_queue_.PostDelayedTask().
>
> Bug: chromium:1152887
> Change-Id: I72c96d2c4b491d5edb45a30b210b3797165cbf48
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208560
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33421}
Bug: chromium:1152887
Change-Id: I9aba4882a64bbee7d97ace9059dea8a24c144f93
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212880
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33554}
This avoids the pacer thread waking up at 5ms interval if a
PeerConnection is created without actually using media.
The TaskQueuePacedSender solves the problem too, this CL is mostly a
safeguard in case we still find issues when turning it on...
Can be turned off by setting field trial "WebRTC-LazyPacerStart" to
"Disabled".
Bug: webrtc:10809
Change-Id: I8501106e608eccb14487576f24bdceaf3f324d80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183982
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32101}
For now the capping is experimental and applied via a field trial.
Bug: webrtc:11434
Change-Id: Id8e6e9b948f099a0940974a9a431b5b0a43c32f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171226
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30909}
Instead of passing only the local- and remote network IDs the whole
NetworkRoute is forwarded to TransportFeedbackAdapter that can then
use more detailed information to distinguish routes.
Bug: webrtc:11434
Change-Id: I48f36aa1177822d20c2b556dcc2275f6145ed845
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171581
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30895}
Add a new API in RTPSenderInterface, to be called from the browser side
to insert a frame transformer between the Encoded and the Packetizer.
The frame transformer is passed from RTPSenderInterface through the
library to be eventually set in RTPSenderVideo, where the frame
transformation will occur in the follow-up CL
https://webrtc-review.googlesource.com/c/src/+/169128.
Insertable Streams Web API explainer:
https://github.com/alvestrand/webrtc-media-streams/blob/master/explainer.md
Design doc for WebRTC library changes:
http://doc/1eiLkjNUkRy2FssCPLUp6eH08BZuXXoHfbbBP1ZN7EVk
Bug: webrtc:11380
Change-Id: I46cd0d8a798c2736c837e90cbf90d8901c7d27fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/169127
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30642}
This is a reland of 086055d0fd
ANA was accitendly disabled even when transport sequence numbers were
negotiated due to a bug in how the audio send stream is configured. To
solve this we simply continue to always allow enabling ANA and leave it
up to the application to ensure that it's not used together with receive
side estimation.
Original change's description:
> Reland "Only include overhead if using send side bandwidth estimation."
>
> This is a reland of 8c79c6e1af
>
> Original change's description:
> > Only include overhead if using send side bandwidth estimation.
> >
> > Bug: webrtc:11298
> > Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> > Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> > Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> > Reviewed-by: Ali Tofigh <alito@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30382}
>
> Bug: webrtc:11298
> Change-Id: I33205e869a8ae27c15ffe991f6d985973ed6d15a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167524
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30390}
Bug: webrtc:11298
Change-Id: If2ad91e17ebfc85dc51edcd9607996e18c5d1f13
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167883
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30413}
This is a reland of 8c79c6e1af
Original change's description:
> Only include overhead if using send side bandwidth estimation.
>
> Bug: webrtc:11298
> Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30382}
Bug: webrtc:11298
Change-Id: I33205e869a8ae27c15ffe991f6d985973ed6d15a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167524
Reviewed-by: Ali Tofigh <alito@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30390}
This reverts commit 8c79c6e1af.
Reason for revert: Introduced a Bug that can happen if the include overhead state changes between pushing and poping a packet from the pacer packet queue.
Original change's description:
> Only include overhead if using send side bandwidth estimation.
>
> Bug: webrtc:11298
> Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30382}
TBR=saza@webrtc.org,ossu@webrtc.org,sprang@webrtc.org,srte@webrtc.org,alito@webrtc.org
Change-Id: I0cacbc26408b7bec5bc3855a628e62407c081117
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11298
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167523
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30383}
This reverts commit d61338fa6e.
Reason for revert: Causing a build break:
webrtc/call/BUILD:300:1: Undeclared inclusion(s) in rule 'webrtc/call:rtp_sender':
this rule is missing dependency declarations for the following files included by 'call/rtp_transport_controller_send.cc':
'webrtc/modules/congestion_controller/rtp/transport_feedback_demuxer.h'
Original change's description:
> Reland "Extracts ssrc based feedback tracking from feedback adapter."
>
> This is a reland of 08c46adc1e
>
> Original change's description:
> > Extracts ssrc based feedback tracking from feedback adapter.
> >
> > This prepares for moving TransportFeedbackAdapter to TaskQueue.
> >
> > Bug: webrtc:9883
> > Change-Id: Ib333f6a6837ff6dd8b10813e8953e4d8cd5d8633
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162040
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30076}
>
> Bug: webrtc:9883
> Change-Id: Ia74a3b1fba4d83eece9b0eb6475d6e6aecb65700
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162201
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30266}
TBR=sprang@webrtc.org,srte@webrtc.org
Change-Id: I7f3f872c7ff863a37ad8dca08051fe1e04671bfb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9883
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166182
Reviewed-by: JT Teh <jtteh@webrtc.org>
Commit-Queue: JT Teh <jtteh@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30270}
This is a reland of 08c46adc1e
Original change's description:
> Extracts ssrc based feedback tracking from feedback adapter.
>
> This prepares for moving TransportFeedbackAdapter to TaskQueue.
>
> Bug: webrtc:9883
> Change-Id: Ib333f6a6837ff6dd8b10813e8953e4d8cd5d8633
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162040
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30076}
Bug: webrtc:9883
Change-Id: Ia74a3b1fba4d83eece9b0eb6475d6e6aecb65700
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162201
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30266}
This prepares for moving TransportFeedbackAdapter to TaskQueue.
Bug: webrtc:9883
Change-Id: Ib333f6a6837ff6dd8b10813e8953e4d8cd5d8633
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162040
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30076}
The trials are always set when a Call instead is created by a
CallFactory, but a lot of unit tests creates instances directly.
This CL updates those call site. There is still a fallback in place
in RtpTransportControllerSend, since there are down-stream usages that
need to be clean up. After that, we'll remove the fallback.
Bug: webrtc:10809
Change-Id: I0aacf0473317bcd64252dd43d93c42de730e2ffa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160408
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29978}
This will be immediately useful to guarantee consistent state across
components referencing the pacer, but will be a net benefit overall
imo.
Bug: webrtc:10809
Change-Id: I49630696f757a832ccf2e4c8597193bf087ce53b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159885
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29859}
