worker_queue is used in many places and it can be confusing. This queue
is the send transport's worker queue. Rename to send_transport_queue to
reflect that.
Bug: none
Change-Id: I43c5c4cbddaee3dae1ff75aa38dc3ddee6585902
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176362
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31396}
This CL moves webrtc::NackModule to a deprecated folder and annotates
the type with RTC_DEPRECATED.
Since the header should not be used outside of WebRTC, this CL doesn't
created a forward header.
Bug: webrtc:11611
Change-Id: I4d5899d473d78b8c7f4a6a018e2805648244b5f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176360
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31394}
TaskQueuePacedSender::MaybeUpdateStats() is intended to be called when
packets are sent or by a sequence of "scheduled" calls. There should
only be one scheduled call in flight at a time - and that one
reschedules itself if needed when it runs.
A bug however caused the "schedules task in flight" flag to
incorrectly be set to false, leading to more and more schedules tasks
being alive - eating CPU cycles.
This CL fixes that and also makes sure the queue time properly goes
down to zero before the next idle interval check, even if there are no
more packets to send.
Bug: webrtc:10809
Change-Id: I4e13fcf95619a43dcaf0ed38bce9684a5b0d8d5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176330
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31390}
When video frame encoding is done on an external thread (for example in
the case of hardware encoders), the WebRTC TaskQueueBase::Current() is
null; in this case use the worker queue instead to send transformed
frames.
Bug: chromium:1086373
Change-Id: I903ddc52ad6832557fc5b5f76396fe26cf5a88f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176303
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31388}
Previously a histogram was added to track the requested buffer size,
this CL adds a histogram for the actually used buffer size.
Bug: b/157429867
Change-Id: I04016760982a4c43b8ba8f0e095fe1171b705258
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176227
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31385}
This is useful in debugging the latency from a packet
is enqueued until it's sent.
Bug: webrtc:11617
Change-Id: Ic2f194334a2e178de221df3a0838481035bb3505
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176231
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31381}
The Android native audio code asks the OS to provide an appropriate
buffer size for real-time audio playout. We should add logging for this
value so we can see what values are used in practice.
Bug: b/157429867
Change-Id: I111a74faefc0e77b5c98921804d6625cba1b84af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176126
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Andreasson <henrika@chromium.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31368}
gone for a while
BUG=webrtc:5922
Change-Id: Ie5d2f6dbffbc349686dbaf05a378375dbff0dce0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175914
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31352}
This change adds an optional delay to NetEq's output. Note, this is not
equivalent to increasing the jitter buffer with the same extra length.
Bug: b/156734419
Change-Id: I8b70b6b3bffcfd3da296ccf29853864baa03d6bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175110
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31343}
Since locking model has been cleaned up, PacingController can now call
PacketRouter directly - without having to go via PacedSender or
TaskQueuePacedSender.
Bug: webrtc:10809
Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31342}
Use speed 6 for better quality for low resolution, speed 8 for HD for better speed.
This will better balance speed and quality.
Change-Id: I3d8dbd45533471ce58d53c1ac26f92c7b1106259
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175281
Reviewed-by: Marco Paniconi <marpan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Jerome Jiang <jianj@google.com>
Cr-Commit-Position: refs/heads/master@{#31336}
This ended up with needing to fork the current implementation
in order to not break downstream projects that were inheriting
from it. While those get updated, we'll move on with the forked
class.
Bug: webrtc:11581,b/8278269
Change-Id: I05b596cbda71aa5b72894c31a7119d17d4761883
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175500
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31334}
This is a reland of 6b9c60b06d04bc519195fca1f621b10accfeb46b
Original change's description:
> Removes lock release in PacedSender callback.
>
> The PacedSender currently has logic to temporarily release its internal
> lock while sending or asking for padding.
> This creates some tricky situations in the pacing controller where we
> need to consider if some thread can enter while we the process thread is
> actually processing, just temporarily busy sending.
>
> Since the pacing call stack is no longer cyclic, we can actually remove
> this lock-release now.
>
> Bug: webrtc:10809
> Change-Id: Ic59c605252bed1f96a03406c908a30cd1012f995
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173592
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31206}
Bug: webrtc:10809
Change-Id: Id39fc49b0a038e7ae3a0d9818fb0806c33ae0ae0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175656
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31332}
With an optional parameter this allows the task-queue based paced
sender to mimic the old behavior and coalesce sending of packets in
order to reduce thread wakeups and provide opportunity for batching.
This is done by simply overriding the minimum time the thread should
sleep. The pacing controller will already handle the "late wakup" case
and send any packets as if it had been woken at the optimal time.
Bug: webrtc:10809
Change-Id: Iceea00693a4e87d39b0e0ee8bdabca081dff2cba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175648
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31328}
This CL extends the WebRTC testing API to allow audioproc_f -based
testing using a pre-created AudioProcessing object. This is an
important feature to allow testing any AudioProcessing objects
that are injected into WebRTC.
Beyond adding this, the CL also changes the simulation code to
operate on a scoped_refptr<AudioProcessing> object instead of a
std::unique<AudioProcessing> object
Bug: webrtc:5298
Change-Id: I70179f19518fc583ad0101bd59c038478a3cc23d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175568
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31319}
...for the NullDataDumper, WrongCaptureBlockSize and
DISABLED_WrongRenderBlockSize tests. This is to avoid creation
of additional threads on Mac, which can cause issues on asan bots.
Bug: webrtc:11577
Change-Id: I4e6a64d47ec3b0a0e0018b19a0486208ba7e6ae2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175600
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31307}
to convert flags which chains a video frame part of into chain_diffs
Bug: webrtc:10342
Change-Id: I6fb899eae934078223b101c9f85e2ac101980d4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175108
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31306}
adjust zeroing to support more than 64 bits.
Bug: b/156802687
Change-Id: I42448b4dd6d5c04143eb9075cd61317e115ed936
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175564
Reviewed-by: Erik Varga <erikvarga@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31300}
ModuleRtpRtcpImpl::Process seems to be called as many
times as 200 times a second (kRtpRtcpMaxIdleTimeProcessMs == 5).
This CL changes it so that LastReceivedReportBlockMs() is called
once a second instead of potentially every time Process() runs.
This should result in grabbing locks fewer times, however there
are still other call sites for the same lock.
Bug: webrtc:11581
Change-Id: I4c2fd9aa43343fdac2763250ae7f4d2545e98ec2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175350
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31298}
Add TODOs into AV1 encoder wrapper where it suppose to be used.
Bug: webrtc:11404
Change-Id: If049066b84be72829867d5084827a7d275648a7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174806
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31278}
Define VideoHeaderMetadata, containing a subset of the metadata in RTP
video header, and expose it the TransformableVideoFrameInterface, to
enable web application to compute additional data according to their own
logic, and eventually remove GetAdditionalData() from the interface.
Bug: chromium:1069295
Change-Id: Id85b494a72cfd8bdd4c0614844b9f0ffae98c956
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174822
Commit-Queue: Marina Ciocea <marinaciocea@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31265}
In https://webrtc-review.googlesource.com/c/src/+/173704 the overhead
calculations were made more static, so that "volatile" extensions
(those that are not set on every packet) are ignored. The intent, as
the comments specify, was to ignore RepairedRtpStreamId since that is
only used on RTX packets.
This CL makes us actually count that extension as volatile.
Bug: webrtc:10809
Change-Id: If42ae84e4c09ff9112e93f8d872ee890c6253a23
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175010
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31246}
When Chromium displays the selection dialog for screens it gets the thumbnails by calling SelectSource for the first monitor then CaptureFrame, then SelectSource for the next monitor then CaptureFrame, and so on. With 1 or 2 screens this does not show any issues, but with 3 or more screens the program may crash.
The queue of frame buffers is actually just 2 frame buffers that get swapped every time a frame is captured. When you have one monitor both buffers will be sized for it's resolution. When you have two monitor the first buffer is sized for the first monitor and the second buffer for the second monitor. Since the monitors are selected in turn monitors and frame buffers stay matched up and things work fine. With a third monitor the first buffer is sized for the first monitor, but then later reused to capture the third monitor. If the resolution of the third monitor does not match the first we either crash or have extra junk in the frame from when we captured the first monitor.
Bug: chromium:396091
Change-Id: I7b5ee914b02fee48c09422cee1e320396c9550c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174520
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#31229}
When FEC generation is moved to egress, we'll need to poll bitrates from
there instead of the RtpVideoSender. In preparation, refactoring some
getter methods.
For context, see https://webrtc-review.googlesource.com/c/src/+/173708
Bug: webrtc:11340
Change-Id: Ibc27362361ee9640d9fce676fc8e1093a579344f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174202
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31214}
This reverts commit 6b9c60b06d04bc519195fca1f621b10accfeb46b.
Reason for revert: Breaks downstream test
Original change's description:
> Removes lock release in PacedSender callback.
>
> The PacedSender currently has logic to temporarily release its internal
> lock while sending or asking for padding.
> This creates some tricky situations in the pacing controller where we
> need to consider if some thread can enter while we the process thread is
> actually processing, just temporarily busy sending.
>
> Since the pacing call stack is no longer cyclic, we can actually remove
> this lock-release now.
>
> Bug: webrtc:10809
> Change-Id: Ic59c605252bed1f96a03406c908a30cd1012f995
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173592
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31206}
TBR=sprang@webrtc.org,srte@webrtc.org
Change-Id: Ic84eee6097528d0792e3b1f90f36bc78447a0d81
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10809
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174820
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31209}
This CL changes the way that AecDumps are created in APM. Instead
of being injected, they are now created via the API.
This removes the AecDumpFactory from the API surface of APM and
makes the API more explicit.
The CL will be followed by one more CL that deprecates the usage
of the AttachAecDump API also within the audio_processing
and the fuzzer folders.
The CL also moves the aec_dump.* files from the include folder
to the aec_dump folder and changes the build files. The reasons
for this are that
1) The content of aec_dump.h is not really part of the API
surface of APM.
2) Those files anyway needed to be moved to a separate build-
target to avoid a circular build-file dependency caused by
the other changes in this CL
Bug: webrtc:5298
Change-Id: I7dd6b49de76eb44158472874e1d4ae17dca9be54
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174750
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31207}
