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}
Spec: https://www.w3.org/TR/webrtc-stats/#dom-rtcvideosourcestats-frames
Wiring up the "frames" stats with the cumulative fps counter on the video source.
Tests:
./out/Default/peerconnection_unittests
./out/Default/video_engine_tests
Bug: webrtc:12499
Change-Id: I4103f56ed04cb464f5f7e70fbf2d77c25a867a68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208782
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
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/master@{#33404}
This will allow us to optimize the internal buffers of
webrtc::VideoFrame for the resolution(s) that we actually want to
encode.
Bug: webrtc:12469, chromium:1157072
Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33342}
Apart from making the map smaller, a purpose of this is guaranteeing
that if a module has been deactived it will not receive new packets
from the pacer, which will be needed for deferred sequencing.
Bug: webrtc:11340
Change-Id: I171a13413c5b8d3fa569c2d56bd9a54bff7c7976
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208542
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33335}
Simulcast with one active stream:
Use pixels from single active stream if set (instead of input stream which could be larger) to avoid going below the min_pixel_per_frame limit when downgrading resolution.
Bug: none
Change-Id: I65acb12cc53e46f726ccb5bfab8ce08ff0c4cf78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33309}
This is for better compatibility with thread annotations and how the
histogram data is collected. In the dtor we can make assumptions about
the state of the object, but that context is lost in member methods
even though they're only called from the destructor (and therefore
thread annotations can't "know" that the object is being destructed
inside those calls).
Bug: webrtc:11993
Change-Id: I8b698cc3340fb0db49430da6f7a9b9a02cabf0c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208200
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33295}
In practice, support for multiple sinks is not needed and supporting
the API that allows for dynamically adding/removing sinks at runtime,
adds to the complexity of the implementation.
This CL removes that Add/Remove methods for secondary sinks as well
as vectors of callback pointers (which were either of size 0 or 1).
Instead, an optional callback pointer is added to the config struct
for VideoReceiveStream, that an implementation can consider to be
const and there's not a need to do thread synchronization for that
pointer for every network packet.
As part of webrtc:11993, this simplifies the work towards keeping
the processing of network packets on the network thread. The secondary
sinks, currently operate on the worker thread.
Bug: webrtc:11993
Change-Id: I10c473e57d3809527a1b689f4352e903a4c78168
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207421
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33272}
To avoid unnecessary repeating tasks, CallStats' timer is started only
upon Call::EnsureStarted().
Bug: chromium:1152887
Change-Id: I1015315f42127bf510affc3d22c930b20eac8bba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206880
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33232}
When calculating maximum allowed size for a media packet.
In particular take in account that rtx packet might need to
include mid and repaired-rsid extensions when media packet can omit them.
Bug: webrtc:11031
Change-Id: I3e7bc36437c23e0330316588d2a46978407c8c45
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206060
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33184}
This is a reland of d48a2b14e7545d0a0778df753e062075c044e2a1
The diff of the reland (what caused the tsan error) can be seen
by diffing patch sets 2 and 3. Essentially I missed keeping the calls
to the transport controller on the worker thread. Note to self to add
thread/sequence checks to that code so that we won't have to rely on
tsan :)
Original change's description:
> Prepare to avoid hops to worker for network events.
>
> This moves the thread hop for network events, from BaseChannel and
> into Call. The reason for this is to move the control over those hops
> (including DeliverPacket[Async]) into the same class where the state
> is held that is affected by those hops. Once that's done, we can start
> moving the relevant network state over to the network thread and
> eventually remove the hops.
>
> I'm also adding several TODOs for tracking future steps and give
> developers a heads up.
>
> Bug: webrtc:11993
> Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33138}
Bug: webrtc:11993, webrtc:12430
Change-Id: I4fccaa418d22c2087a55bbb3ddbb25fac3b4dfcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205580
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33153}
This reverts commit d48a2b14e7545d0a0778df753e062075c044e2a1.
Reason for revert: TSan tests started to fail constantly after this CL (it looks like it is flaky and the CQ was lucky to get green). See https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25042/overview.
Original change's description:
> Prepare to avoid hops to worker for network events.
>
> This moves the thread hop for network events, from BaseChannel and
> into Call. The reason for this is to move the control over those hops
> (including DeliverPacket[Async]) into the same class where the state
> is held that is affected by those hops. Once that's done, we can start
> moving the relevant network state over to the network thread and
> eventually remove the hops.
>
> I'm also adding several TODOs for tracking future steps and give
> developers a heads up.
>
> Bug: webrtc:11993
> Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33138}
TBR=nisse@webrtc.org,tommi@webrtc.org
Change-Id: Id87cf9cbcc8ed58e74d755a110f0ef9dd980e298
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11993
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205525
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33145}
This moves the thread hop for network events, from BaseChannel and
into Call. The reason for this is to move the control over those hops
(including DeliverPacket[Async]) into the same class where the state
is held that is affected by those hops. Once that's done, we can start
moving the relevant network state over to the network thread and
eventually remove the hops.
I'm also adding several TODOs for tracking future steps and give
developers a heads up.
Bug: webrtc:11993
Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33138}
We need to be able build chromium with rtc_include_tests = true. It
reveals a lot of targets that are not compatible with chromium but
aren't marked so.
`rtc_include_tests=true` has been considered a way to disable targets for the Chromium build, causing an overload on rtc_include_tests while the meaning of the two GN args (rtc_include_tests and build_with_chromium) should be kept separated.
Bug: webrtc:12404
Change-Id: I2f72825445916eae7c20ef9338672d6a07a9b9ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/203890
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33124}
This will allow for transitioning PacketReceiver callbacks and
network related callbacks from being posted over to the worker thread
and instead can stay on the network thread along with related state.
Bug: webrtc:11993
Change-Id: I38df462d4dee064015c490f2b8f809cb47f23cf1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202039
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33116}
