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}
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}
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}
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}
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}
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}
This reverts commit c623495fd1ff90aada0eb625af91ec17843fefd0.
Reason for revert: Need to look into failure in remoting_unittests in Chrome (Webrtc/ConnectionTest.SecondCaptureFailed/0). It looks like the order FrameBuffer2 calls into VCMTiming while receiving frames and updating playout delay values, needs to be synchronized better.
Original change's description:
> Remove playout delay lock.
> Now update the playout delay and related stats on the worker thread.
>
> This was previously reviewed here:
> https://webrtc-review.googlesource.com/c/src/+/172929/
>
> With the exception of reducing unnecessarily broad
> lock scope in one function in rtp_rtcp_impl.cc
> and added comments in rtp_streams_synchronizer.h
>
> Bug: webrtc:11489
> Change-Id: I77807b5da2accfe774255d9409542d358f288993
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174200
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31193}
TBR=tommi@webrtc.org,sprang@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:11489
Change-Id: I9149025d2fc10686314e6d4e89d1b92125650c36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174757
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31197}
Now update the playout delay and related stats on the worker thread.
This was previously reviewed here:
https://webrtc-review.googlesource.com/c/src/+/172929/
With the exception of reducing unnecessarily broad
lock scope in one function in rtp_rtcp_impl.cc
and added comments in rtp_streams_synchronizer.h
Bug: webrtc:11489
Change-Id: I77807b5da2accfe774255d9409542d358f288993
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174200
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31193}
Max encoder bitrate in WebRTC and OpenH264 are different settings. In
WebRTC it is a cap for encoder target bitrate whilst in OpenH264 it is
a peak bitrate. I.e. OpenH264 is allowed to produce bitrate up to
iMaxBitrate for short time interval. That is not what WebRTC expects.
https://webrtc.googlesource.com/src/+/5ee6967c4edc667688d736c27db6f2e7be00dd0a
disabled encoders re-initialization on min/max bitrate change. Reinit of
some HW encoders takes hundreds of milliseconds and causes video freeze.
I missed that max bitrate is used by OpenH264. This caused regression
described in webrtc:11543.
This change sets iMaxBitrate=UNSPECIFIED_BIT_RATE (which is the default
value). Settings iMaxBitrate=UNSPECIFIED_BIT_RATE disables the frame
dropping logic based on that parameter. But the encoder still will drop
frames based on buffer fullness, https://source.chromium.org/chromium/chromium/src/+/master:third_party/openh264/src/codec/encoder/core/src/ratectl.cpp;l=806-807
Bug: webrtc:10773, webrtc:11543
Change-Id: I728be49e0df8a0d9a8f4438299e4c7b4c1497a78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174745
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31192}
Modernise function to unified MOCK_METHOD macro, delete few deprecated functions on the way.
Remove default constructors to stress they do nothing special
Bug: None
Change-Id: Ie126f38f0589acb65886f25f754ca575c17af29b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174583
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31191}
while helpful by itself, it is also a preparation
for adding unittests for (to be added) svc features of the encoder.
Bug: webrtc:11404
Change-Id: I62b0645f44579f21f228d406a206b4c01d80dd02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174580
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31189}
Call is instantiated on what we traditionally call the 'worker thread'
in PeerConnection terms. Call statistics are however gathered, processed
and reported in a number of different ways, which results in a lot of
locking, which is also unpredictable due to the those actions themselves
contending with other parts of the system.
Designating the worker thread as the general owner of the stats, helps
us keeps things regular and avoids loading unrelated task queues/threads
with reporting things like histograms or locking up due to a call to
GetStats().
This is a reland of remaining changes from https://webrtc-review.googlesource.com/c/src/+/172847:
This applies the changes from the above CL to the forked files and
switches call.cc over to using the forked implementation.
Bug: webrtc:11489
Change-Id: I93ad560500806ddd0e6df1448b1bcf5a1aae7583
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174000
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31186}
This interface has a couple of issues. Primarily for me, it makes it
difficult work with the paced sender as we need to either temporarily
release a lock or force a thread-handover in order to avoid a cyclic
lock order.
For video in particular, its behavior is also falky since header sizes
can vary not only form frame to frame, but from packet to packet within
a frame (e.g. TimingInfo extension is only on the last packet, if set).
On bitrate allocation, the last reported value is picked, leading to
timing issues affecting the bitrate set.
This CL removes the callback interface and instead we simply poll the
RTP module for a packet overhead. This consists of an expected overhead
based on which non-volatile header extensions are registered (so for
instance AbsoluteCaptureTime is disregarded since it's only populated
once per second). The overhead estimation is a little less accurate but
instead simpler and deterministic.
Bug: webrtc:10809
Change-Id: I2c3d3fcca6ad35704c4c1b6b9e0a39227aada1ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173704
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ali Tofigh <alito@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31185}
