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}
Inserting old frames is not an error condition and should not print a warning, and given that it happens all the time it is also very spammy.
Bug: chromium:1066819
Change-Id: Iad2b5edc5e62822c02e2bb2a53d4318f957be3bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173022
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31172}
RtpVideoSender now stores fec type and overhead instead of querying the
generator all the time. Setting of protection parameters and asking for
current bitrate is also now handled just by the VideoFecGenerator
instance, instead of going via RtpVideoSender.
Finally, adds method to query for RtpState in VideoFecGenerator
interface. This avoids an ugly cast that would have been even more
trouble after moving fec generation.
For context, see https://webrtc-review.googlesource.com/c/src/+/173708
Bug: webrtc:11340
Change-Id: Ia5e6cd919e71850c9cc5ed5a4f4417338d577162
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174203
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31166}
This CL introduced 2 new macros that affect the WebRTC OBJC API symbols:
- RTC_OBJC_TYPE_PREFIX:
Macro used to prepend a prefix to the API types that are exported with
RTC_OBJC_EXPORT.
Clients can patch the definition of this macro locally and build
WebRTC.framework with their own prefix in case symbol clashing is a
problem.
This macro must only be defined by changing the value in
sdk/objc/base/RTCMacros.h and not on via compiler flag to ensure
it has a unique value.
- RCT_OBJC_TYPE:
Macro used internally to reference API types. Declaring an API type
without using this macro will not include the declared type in the
set of types that will be affected by the configurable
RTC_OBJC_TYPE_PREFIX.
Manual changes:
https://webrtc-review.googlesource.com/c/src/+/173781/5..10
The auto-generated changes in PS#5 have been done with:
https://webrtc-review.googlesource.com/c/src/+/174061.
Bug: None
Change-Id: I0d54ca94db764fb3b6cb4365873f79e14cd879b8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173781
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31153}
This makes it optional for an echo detector to report metrics through
the getStats interface.
Bug: webrtc:11539
Change-Id: I1fef93b7bf534637b69c16971d38709b3e849a08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174100
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31146}
This CL breaks up the CheckQp() operation into several steps managed
by the inner helper class CheckQpTask, making responding to high or
low QP an asynchronous operation. Why? Reconfiguring the stream in
response to QP overuse will in the future be handled on a separate
task queue. See Call-Level Adaptation Processing for more details:
https://docs.google.com/document/d/1ZyC26yOCknrrcYa839ZWLxD6o6Gig5A3lVTh4E41074/edit?usp=sharing
Instead of "bool AdaptDown()" when high QP is reported,
synchronously returning true or false depending on the result of
adaptation, this CL introduces
void QualityScalerQpUsageHandlerInterface::OnReportQpUsageHigh(
rtc::scoped_refptr<QualityScalerQpUsageHandlerCallback>);
Where
QualityScalerQpUsageHandlerCallback::OnQpUsageHandled(
bool clear_qp_samples);
Instructs the QualityScaler whether to clear samples before
checking QP the next time or to increase the frequency of checking
(corresponding to AdaptDown's return value prior to this CL).
QualityScaler no longer using AdaptationObserverInterface, this class
is renamed and moved to overuse_frame_detector.h.
The dependency between CheckQpTasks is made explicit with
CheckQpTask::Result and variables like observed_enough_frames_,
adapt_called_ and adapt_failed_ are moved there and given more
descriptive names.
Bug: webrtc:11521
Change-Id: I7faf795aeee5ded18ce75eb1617f88226e337228
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173760
Reviewed-by: Evan Shrubsole <eshr@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31140}
This introduces a function AudioProcessingImpl::SetCreateOptionalSubmodulesForTesting to simulate the exclusion of build-optional submodules, and tests of the currently only excludable submodule.
Bug: webrtc:11292
Change-Id: If492606205c9fdc669a6dce3a8989a434aeeed1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173746
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31138}
This CL adds a build flag to allow building the non-test parts
of WebRTC without the audio processing module.
The CL also ensures that the WebRTC code correctly handles
the case when no APM is available.
Bug: webrtc:5298
Change-Id: I5c8b5d1f7115e5cce2af4c2b5ff701fa1c54e49e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171509
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31133}
This CL is functionally a noop but may reduce thread wakupes in some
cases.
In particular, consider a send task scheduled for time T. While waiting
for that, a higher-priority packet than the top of the current queue is
added (e.g. an audio packet), and a send is executed immediately.
After sending, it resets the field indicating that a scheduled task is
expected at time T. It then polls NextSendTime() and schedules a new
task, likely at or very close to T. Causing unnecessary task queue
churn and behavior that is more difficult to reason about.
Bug: webrtc:10809
Change-Id: Ic5706f2cc06df3f27cc3e7b473d4de29a669473b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173700
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31116}
Today when the pacing debt is cleared, we blindly ask for 50 bytes of
padding, which is above a static magic number for RTX payload padding.
Instead, we should adjust the target size based on the current padding
rate. The old pacer sort-of does this, it allows the budget to grow up
to one process interval (usually 5ms).
This CL makes the dynamic pacer also use a duration as target, by
default 5ms to match old pacer but with a trial to allow tweaking it.
This will be important for good behavior due to
https://bugs.chromium.org/p/webrtc/issues/detail?id=11508
Bug: webrtc:10809
Change-Id: I9c14acc5730c6e2e0d7821adf5fb058b8d5487c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173687
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31091}
This was introduced on trial but turned out to perform badly for WebRTC
purposes and never used in production.
Bug: webrtc:9883
Change-Id: Ib72acddf4d90fc9ac042084dddf526c04661f290
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173680
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31085}
https://webrtc-review.googlesource.com/c/src/+/172847
------------ original description --------------
Preparation for ReceiveStatisticsProxy lock reduction.
Update tests to call VideoReceiveStream::GetStats() in the same or at
least similar way it gets called in production (construction thread,
same TQ/thread).
Mapped out threads and context for ReceiveStatisticsProxy,
VideoQualityObserver and VideoReceiveStream. Added
follow-up TODOs for webrtc:11489.
One functional change in ReceiveStatisticsProxy is that when sender
side RtcpPacketTypesCounterUpdated calls are made, the counter is
updated asynchronously since the sender calls the method on a different
thread than the receiver.
Make CallClient::SendTask public to allow tests to run tasks in the
right context. CallClient already does this internally for GetStats.
Remove 10 sec sleep in StopSendingKeyframeRequestsForInactiveStream.
Bug: webrtc:11489
Change-Id: I491e13344b9fa714de0741dd927d907de7e39e83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173583
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31077}
