Some frames are already marked as 'timing frames' via video-timing RTP header extension. Timestamps along full WebRTC pipeline are gathered for these frames. This CL implements reporting of these timestamps for a single
timing frame since the last GetStats(). The frame with the longest end-to-end delay between two consecutive GetStats calls is reported.
The purpose of this timing information is not to provide a realtime statistics but to provide debugging information as it will help identify problematic places in video pipeline for outliers (frames which took longest to process).
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2946413002
Cr-Commit-Position: refs/heads/master@{#18909}
* Remove the ReleaseDecoder and Release methods that were used in combination with deleting the decoder object. Now simply deleting the object does the right thing.
* Remove 'friend' relationship between the two classes since they don't need to touch each other's state directly anymore.
* Use std::unique_ptr for holding pointers and transferring ownership.
These changes were previously reviewed here:
https://codereview.webrtc.org/2764573002/
BUG=webrtc:7361, 695438
Review-Url: https://codereview.webrtc.org/2966823002
Cr-Commit-Position: refs/heads/master@{#18908}
The implementation of this method did not follow the description in
the method comment. It was supposed to delete all packets in a range
[A, B], but if at least one packet in the buffer had a timestamp lower
than A, then no packets at all were discarded. This is now fixed.
BUG=webrtc:7937
Review-Url: https://codereview.webrtc.org/2969123003
Cr-Commit-Position: refs/heads/master@{#18903}
1) Function responsible for receiving feedback, digesting data and deciding switch scenarios.
2) Function which enters Startup mode.
3) Function which exits Startup mode.
4) Function which calculates, whether or not full bandwidth is reached.
BUG=webrtc:7713
Review-Url: https://codereview.webrtc.org/2924603002
Cr-Commit-Position: refs/heads/master@{#18901}
This CL addresses the issue of echo leakage of low level
echoes by making the echo canceller more restrictive for
that scenario.
BUG=webrtc:7930
Review-Url: https://codereview.webrtc.org/2969943002
Cr-Commit-Position: refs/heads/master@{#18884}
The complexity test for the audio processing module have long proven
to give false alarms of complexity regressions for which no related
changes can be identified. Attempts to address that has improved the
that, but the tests do still give false alarms.
This CL deactivates the complexity tests until a better way of
testing this is available.
BUG=chromium:713507, webrtc:5846,webrtc:6685,webrtc:7712
Review-Url: https://codereview.webrtc.org/2897403006
Cr-Commit-Position: refs/heads/master@{#18879}
We'd like to remove all occurrences of WEBRTC_TRACE and delete the
macro! One logging mechanism is enough.
AudioConferenceMixer is scheduled for removal and is one of the
things tracked by bugs.webrtc.org/4690. The logging is changed to not
block webrtc:5118
NOTRY=True
Bug: webrtc:5118
Change-Id: Ibad1ae45e8af1ba5bbe253d4c693ecf9e7c422ac
Reviewed-on: https://chromium-review.googlesource.com/518172
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18876}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
The only manual edit is to add an include of webrtc/rtc_base/checks.h in
webrtc/modules/audio_device/android/opensles_common.h, which likely
was needed due to changed include paths due to 'git cl format'.
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2969653002
Cr-Commit-Position: refs/heads/master@{#18871}
Also adds some full stack test variants with the experiment enabled.
BUG=webrtc:7694
Review-Url: https://codereview.webrtc.org/2949553002
Cr-Commit-Position: refs/heads/master@{#18869}
The CL in https://codereview.webrtc.org/2918333002/ enabled
FecTest.FlexfecTest and also added a sequence number offset between
the FEC packets and the media packets. This was to simulate that the
sequence numbers were generated from different spaces, i.e., that they
belong to different SSRCs.
The test does not account for sequence number wraparound, which means
that it could fail when the sequence number offset realization was large.
This CL fixes the problem by ensuring that the offset always lies in
[0, 2^15].
This CL also fixes spelling of UlpfecTest.
BUG=webrtc:7912
TESTED=ninja -C out/Debug && third_party/gtest-parallel/gtest-parallel --gtest_filter="*Flexfec*" -r 1000 out/Debug/modules_tests
Review-Url: https://codereview.webrtc.org/2966753002
Cr-Commit-Position: refs/heads/master@{#18863}
This CL exposes the parameter for adjusting the AEC3 performance
for large rooms.
Bug: webrtc:7519
Review-Url: https://codereview.webrtc.org/2967603002
Cr-Commit-Position: refs/heads/master@{#18862}
(This got reverted because of a problem with the Opus encoder parts.
Re-landing without changes.)
BUG=webrtc:7837
Review-Url: https://codereview.webrtc.org/2950453002
Cr-Commit-Position: refs/heads/master@{#18855}
This was previously reverted, because external projects were using the
internal webrtc::AudioEncoderOpus class and broke when it was renamed.
This re-land avoids renaming it immediately, to give those projects
time to adapt. It also has to revert some of the changes I had made to the
Config struct, since that was also used by the same external projects.
BUG=webrtc:7831
Review-Url: https://codereview.webrtc.org/2948483002
Cr-Commit-Position: refs/heads/master@{#18852}
Due to the implementation of the analog AGC in the audio
processing module, the detection for the analog gain done in AEC3
fails on some platforms where there is no analog gain to control.
This CL removes that functionality until the AGC behavior has
been corrected.
Bug: webrtc:7910, chromium:738322
Change-Id: Ibdbe1e02252387dfd94b36ba7471f5c56ae27f48
Reviewed-on: https://chromium-review.googlesource.com/556040
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18850}
This CL loosens the requirement on the API jitter in APM
that can be tolerated without affecting the AEC3 performance.
BUG=webrtc:7911,chromium:738323
Review-Url: https://codereview.webrtc.org/2967493004
Cr-Commit-Position: refs/heads/master@{#18849}
Leaving compatibility script in webrtc/tools/compare_videos.py to
avoid breaking our video quality tests in Chromium.
Forwarding GN targets are left in webrtc/tools/BUILD.gn.
BUG=webrtc:7855
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2965593002
Cr-Commit-Position: refs/heads/master@{#18848}
[This CL is a rebase of an original CL by solenberg@:
https://codereview.webrtc.org/2948763002/ which in turn was a
rebase of an original CL by peah@:
https://chromium-review.googlesource.com/c/527032/]
Allow an external audio processing module to be used in WebRTC
This CL adds support for optionally using an externally created audio
processing module in a peerconnection. The ownership is shared
between the peerconnection and the external creator of the module.
As part of this the internal ownership of the audio processing module
is moved from VoiceEngine to WebRtcVoiceEngine.
BUG=webrtc:7775
Review-Url: https://codereview.webrtc.org/2961723004
Cr-Commit-Position: refs/heads/master@{#18837}
Remove video codec settings from CodecParams (and rename to ProcessParams).
Removes intermediate step of configuring video settings via CodecParams.
BUG=webrtc:6634
Review-Url: https://codereview.webrtc.org/2956243002
Cr-Commit-Position: refs/heads/master@{#18830}
Reason for revert:
Fix RtpStreamReceiver to not recover RTX packets with incorrect SSRC.
Original issue's description:
> Revert of Only compare sequence numbers from the same SSRC in ForwardErrorCorrection. (patchset #5 id:120001 of https://codereview.webrtc.org/2893293003/ )
>
> Reason for revert:
> Breaks fuzzer.
>
> Original issue's description:
> > Only compare sequence numbers from the same SSRC in ForwardErrorCorrection.
> >
> > Prior to this CL, the ForwardErrorCorrection state would be reset whenever
> > the difference in sequence numbers of the last recovered media packet
> > and the new packet (media or FEC) was too large. This comparison did not
> > take into account that FlexFEC uses a different SSRC for the FEC packets,
> > meaning that the the state would be reset very frequently when FlexFEC
> > is used. This should not have led to any major problems, except for a
> > decreased decoding efficiency.
> >
> > This CL verifies that whenever we compare sequence numbers in
> > ForwardErrorCorrection, they do indeed belong to the same SSRC.
> >
> > BUG=webrtc:5654
> >
> > Review-Url: https://codereview.webrtc.org/2893293003
> > Cr-Commit-Position: refs/heads/master@{#18399}
> > Committed: 1476a9d789
>
> TBR=stefan@webrtc.org,holmer@google.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:5654
>
> Review-Url: https://codereview.webrtc.org/2919313005
> Cr-Commit-Position: refs/heads/master@{#18446}
> Committed: 92732ecc5cR=stefan@webrtc.org
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2918333002
Cr-Commit-Position: refs/heads/master@{#18827}
Don't disable fec for packets without timing frames extension
even if they are marked as belonging to timing frames.
BUG=webrtc:7894
Review-Url: https://codereview.webrtc.org/2956263002
Cr-Commit-Position: refs/heads/master@{#18826}
Reland the base->rtc_base without adding stub headers (will be
done in follow-up CL). This preserves git blame history of all files.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: Iea3bb6f3f67b8374c96337b63e8f5aa3e6181012
Reviewed-on: https://chromium-review.googlesource.com/554611
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18821}
This refactoring takes a careful approach to avoid rushing the change:
* stub headers are left in all the old locations of webrtc/base
* existing GN targets are kept and now just forward to the moved ones
using public_deps.
The only exception to the above is the base_java target and its .java files,
which were moved to webrtc/rtc_base right away since it's not possible
to use public_deps for android_library.
To avoid breaking builds, a temporary Dummy.java file was added to
the new intermediate target in webrtc/rtc_base:base_java as well to avoid
hitting a GN assert in the android_library template.
The above approach should make the transition smooth without breaking
downstream.
A helper script was created (https://codereview.webrtc.org/2879203002/)
and was run like this:
stub-headers.py -s webrtc/base -d webrtc/rtc_base -i 7634
stub-headers.py -s webrtc/base/numerics -d webrtc/rtc_base/numerics -i 7634
Fixed invalid header guards in the following files:
webrtc/base/base64.h
webrtc/base/cryptstring.h
webrtc/base/event.h
webrtc/base/flags.h
webrtc/base/httpbase.h
webrtc/base/httpcommon-inl.h
webrtc/base/httpcommon.h
webrtc/base/httpserver.h
webrtc/base/logsinks.h
webrtc/base/macutils.h
webrtc/base/nattypes.h
webrtc/base/openssladapter.h
webrtc/base/opensslstreamadapter.h
webrtc/base/pathutils.h
webrtc/base/physicalsocketserver.h
webrtc/base/proxyinfo.h
webrtc/base/sigslot.h
webrtc/base/sigslotrepeater.h
webrtc/base/socket.h
webrtc/base/socketaddresspair.h
webrtc/base/socketfactory.h
webrtc/base/stringutils.h
webrtc/base/testbase64.h
webrtc/base/testutils.h
webrtc/base/transformadapter.h
webrtc/base/win32filesystem.h
Added new header guards to:
sslroots.h
testbase64.h
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
R=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2877023002 .
Cr-Commit-Position: refs/heads/master@{#18816}
A recent update of Windows 10 blocks IDXGIAdapter::EnumOutputs() in session 0,
so ScreenCapturerWinDirectx::IsSupported() always returns false in session 0. We
should ensure ScreenCapturerWinDirectx can respond correctly in session 0.
Meanwhile, this change looses the requirement of DirectX capturer: it still
works if some of the video adapters do not support DirectX 11 or
IDXGIOutputDuplication. This issue usually happens when handling a virtual video
adapter.
BUG=webrtc:7809
Review-Url: https://codereview.webrtc.org/2937663003
Cr-Commit-Position: refs/heads/master@{#18797}
Dont do a normal AimdRateControlUpdate update after a probe. Only set result.updated if the bitrate estimate has changed.
BUG=webrtc:7866
Review-Url: https://codereview.webrtc.org/2949203002
Cr-Commit-Position: refs/heads/master@{#18785}
This CL corrects the initialization of the AEC3, as well
as for the other submodules in the whole audio processing module
in the sense that it properly update the submodule states also
for the case when reinitialization is trigger from the render
side of the audio processing module.
Bug: chromium:736889,webrtc:7879
Change-Id: I423e963835d0c3227caa8e186b29031bcb912515
Reviewed-on: https://chromium-review.googlesource.com/549315
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18784}
Patch set 1 is a reland + trivial rebase.
Patch set >= 2 contains bug fixes.
> Original issue's description:
> > Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
> >
> > That however exposes a bunch of failed test, so this CL also fixed a few other things:
> > * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> > * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> > * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> > * Fix test
> >
> > BUG=7664
> >
> > Review-Url: https://codereview.webrtc.org/2883963002
> > Cr-Commit-Position: refs/heads/master@{#18473}
> > Committed: 6431e21da6
BUG=webrtc:7664
Review-Url: https://codereview.webrtc.org/2953053002
Cr-Commit-Position: refs/heads/master@{#18782}
This CL corrects the computation of the delay headroom so that
it is only updated when the delay is updated. This is important
as otherwise a too large headroom will be reported, which then
could cause buffer access issues.
Bug: webrtc:7878, chromium:736893
Change-Id: Ib37cb608b064dd5d4df3f8fc423448ee80ed0106
Reviewed-on: https://chromium-review.googlesource.com/549335
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18781}
