For example, zero rtt may be reported to:
BitrateControllerImpl::OnReceivedRtcpReceiverReport:
- SendSideBandwidthEstimation::UpdateReceiverBlock
- SendSideBandwidthEstimation::UpdateUmaStats
BitrateAllocator::OnNetworkChanged:
- ProtectionBitrateCalculator::SetTargetRates
Re-add check that was removed in https://codereview.webrtc.org/2422063002.
BUG=webrtc:6692
Review-Url: https://codereview.webrtc.org/2552883010
Cr-Commit-Position: refs/heads/master@{#15486}
Reason for revert:
There was a bug in the implementation where the adapter could get stuck at really low resolutions. That has now been fixed.
Original issue's description:
> Revert of Add ability to scale to arbitrary factors (patchset #7 id:120001 of https://codereview.webrtc.org/2555483005/ )
>
> Reason for revert:
> Issue discovered with scaling back up.
>
> Original issue's description:
> > Add ability to scale to arbitrary factors
> >
> > This CL adds a fallback for the case when no optimized scale factor produces a low enough resolution for what was requested. It also ensures that all resolutions provided by the video adapter are divisible by four. This is required by some hardware implementations.
> >
> > BUG=webrtc:6837
> >
> > Committed: https://crrev.com/710c335d785b104bda4a912bd7909e4d27f9b04f
> > Cr-Commit-Position: refs/heads/master@{#15469}
>
> TBR=magjed@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6837
>
> Committed: https://crrev.com/7722a4cc8d31e5e924e9e6c5c97412ce8bbbe59d
> Cr-Commit-Position: refs/heads/master@{#15470}
R=magjed@webrtc.org
BUG=webrtc:6837,webrtc:6848
Review-Url: https://codereview.webrtc.org/2558243003
Cr-Commit-Position: refs/heads/master@{#15485}
Also deletes one call to CongestionController::pacer.
BUG=None
Review-Url: https://codereview.webrtc.org/2542113003
Cr-Commit-Position: refs/heads/master@{#15479}
This moves some GN check configurations out of .gn to individual targets.
The now checked target is:
"//webrtc/modules/audio_processing/*",
BUG=webrtc:6828
NOTRY=True
R=kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2558813003
Cr-Commit-Position: refs/heads/master@{#15475}
This CL breaks out the output sample rate calculation from
webrtc::AudioMixerImpl. A new OutputRateCalculator interface is added
to make the sample rate configurable. There are at least three reasons
for this change:
1. The mixer will be used for an internal project, in which no
resampling is done after the mixing. There the sample rate should
be static. Currently, it can differ across mix iterations and
depends on the number of audio sources. If there are no sources,
the WebRTC mixer behavior is to produce silence at 48 kHz.
2. A planned change to WebRTC will make audio processing steps
happen at constant sample rates. A configurable sample rate
calculator will make the transition simpler for the mixer.
3. The current mixer design is a single large file. Behavior is not
always simple to change (e.g. as in this case to mix at a
constant rate), unrelated behavior can be broken, reusing the
mixer in internal projects is tricky. Using DI for the sample
rate calculation solves parts of these issues.
Changes:
The protected mixer c-tor now takes
unique_ptr<OutputRateCalculator>. The current output rate calculation
is moved to DefaultOutputRateCalculator. A new factory method
AudioMixerImpl::CreateWithOutputRateCalculator is added. The old
factory method passes the default rate calculator.
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2557713006
Cr-Commit-Position: refs/heads/master@{#15472}
Reason for revert:
Issue discovered with scaling back up.
Original issue's description:
> Add ability to scale to arbitrary factors
>
> This CL adds a fallback for the case when no optimized scale factor produces a low enough resolution for what was requested. It also ensures that all resolutions provided by the video adapter are divisible by four. This is required by some hardware implementations.
>
> BUG=webrtc:6837
>
> Committed: https://crrev.com/710c335d785b104bda4a912bd7909e4d27f9b04f
> Cr-Commit-Position: refs/heads/master@{#15469}
TBR=magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6837
Review-Url: https://codereview.webrtc.org/2557323002
Cr-Commit-Position: refs/heads/master@{#15470}
This CL adds a fallback for the case when no optimized scale factor produces a low enough resolution for what was requested. It also ensures that all resolutions provided by the video adapter are divisible by four. This is required by some hardware implementations.
BUG=webrtc:6837
Review-Url: https://codereview.webrtc.org/2555483005
Cr-Commit-Position: refs/heads/master@{#15469}
This makes it obvious that cricket::Codec should not be
instantiated; only subclasses should be instantiated.
BUG=none
Review-Url: https://codereview.webrtc.org/2546363002
Cr-Commit-Position: refs/heads/master@{#15468}
It should be 'JNIEXPORT rettype JNICALL' not 'rettype JNIEXPORT JNICALL'.
BUG=webrtc:6660
Review-Url: https://codereview.webrtc.org/2557793003
Cr-Commit-Position: refs/heads/master@{#15467}
BitBlt returns a BOOL value, which should be taken care in ScreenCapturerWinGdi.
Meanwhile, this change also replaces assert() / abort() with RTC_DCHECK() /
RTC_CHECK() / RTC_NOTREACHED().
This change cannot fix the bug, the reason of the issue is still unknown, but it
is still the right thing to do.
In ScreenCapturerIntegrationTest, each frame will be captured at most 600 times.
Since the test case fails, which means the ScreenCapturerWinGdi consistently
returns a white frame for 600 times under a certain state. With this change,
instead of returning white frame, ScreenCapturerWinGdi will return a temporary
error. But I do not think a ScreenCapturerWinGdi can automatically recover by
retrying.
BUG=webrtc:6843
Review-Url: https://codereview.webrtc.org/2553353002
Cr-Commit-Position: refs/heads/master@{#15465}
Create the RtpReceiver.Observer which is a Java wrapper over the webrtc::RtpReceiverObserverInterface.
The callback function onFirstPacketReceived will be called whenever the first audio or video packet it received.
BUG=webrtc:6742
Review-Url: https://codereview.webrtc.org/2531333003
Cr-Commit-Position: refs/heads/master@{#15464}
This moves some GN check configurations out of .gn to individual targets.
The now checked targets are:
"//webrtc/api/*",
"//webrtc/audio/*",
"//webrtc/modules/audio_coding/*",
Many targets were fixed by adding dependencies, but the ones that
requires more refactorings are left with the check_includes attribute
set to false instead.
Make //webrtc/test:test_support a public dep of //webrtc/test:test_main
to avoid having to add that to all users of it.
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2556943003
Cr-Commit-Position: refs/heads/master@{#15461}
This makes it possible to use << and RTC_CHECK_EQ with this class.
BUG=none
Review-Url: https://codereview.webrtc.org/2554003002
Cr-Commit-Position: refs/heads/master@{#15456}
These functions are identical. BoringSSL added these APIs, then OpenSSL
1.1.0 added similar ones but with slightly longer names. We're
standardizing on the OpenSSL names to avoid API skew.
BUG=none
Review-Url: https://codereview.webrtc.org/2550423004
Cr-Commit-Position: refs/heads/master@{#15455}
A trivial change to remove a deprecated comment.
BUG=chromium:314516
Review-Url: https://codereview.webrtc.org/2553283002
Cr-Commit-Position: refs/heads/master@{#15454}
Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.
TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.
BUG=None
Review-Url: https://codereview.webrtc.org/2517883002
Cr-Commit-Position: refs/heads/master@{#15453}
Reason for revert:
Deletion of transport.h broke downstream builds.
Going to reland with transport.h containing enums/etc.
Original issue's description:
> Refactoring that removes P2PTransport and DtlsTransport classes.
>
> Their base class, Transport, still exists, but it now has a more specific
> role: a helper class that applies TransportDescriptions. And is renamed
> to JsepTransport as a result.
>
> TransportController is now the entity primarily responsible for managing
> TransportChannels. It also starts storing pointers to the DTLS and ICE
> chanels separately, which will make it easier to remove
> TransportChannel/TransportChannelImpl in a subsequent CL.
>
> BUG=None
>
> Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
> Cr-Commit-Position: refs/heads/master@{#15450}
TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2553043004
Cr-Commit-Position: refs/heads/master@{#15452}
When implementing ISOLATED_OUTDIR feature in WebRTC, I found two issues,
1. pathutils and flags are not accessible in testsupport. But both of them are
useful for the feature. Pathname can help to combine path with filename, while
a flag is needed to handle command line parameter.
2. rtc::File cannot accept an rtc::Pathname, which is a little bit inconvenient.
After investigating bug webrtc:3806, flags, pathutils and urlencode are
removed from rtc_base_approved because of the including of common.h. So I
replaced common.h with checks.h, and ASSERT with RTC_DCHECK. flags,
pathutils and urlencode pairs now can be placed into rtc_base_approved to
unblock file.h to include pathutils.h.
Please kindly let me know if you have other concerns about this change.
BUG=webrtc:3806, webrtc:6732
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.chromium.mac:mac_chromium_rel_ng;master.tryserver.chromium.win:win_chromium_rel_ng;master.tryserver.chromium.android:linux_android_rel_ng
Review-Url: https://codereview.webrtc.org/2533213005
Cr-Commit-Position: refs/heads/master@{#15451}
Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.
TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.
BUG=None
Review-Url: https://codereview.webrtc.org/2517883002
Cr-Commit-Position: refs/heads/master@{#15450}
Specifically, reject any bitrate allocated for a layer not representable
by the BitrateAllocation struct.
BUG=chromium:671312
Review-Url: https://codereview.webrtc.org/2549233005
Cr-Commit-Position: refs/heads/master@{#15447}
The CL fixes adds tests that fully test the functions that manipulate the cricket::VideoFormat<->AVCaptureDeviceFormat
relation.
BUG=webrtc:6680
Review-Url: https://codereview.webrtc.org/2526813002
Cr-Commit-Position: refs/heads/master@{#15444}
I decided to make one webrtc/sdk/android/BUILD.gn for both tests and Java/jni src.
External dependencies needs to be updated after this CL.
Future work is required to clean up the Android api and move
implementation details to /webrtc/sdk/android/src.
BUG=webrtc:5882,webrtc:6804
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2547483003
Cr-Commit-Position: refs/heads/master@{#15443}
Reason for revert:
The downstream problem is now fixed, and this should be good to land again.
Original issue's description:
> Revert of APM: Change 3 UMA metrics to fewer but linearly distributed buckets (patchset #2 id:20001 of https://codereview.webrtc.org/2547593002/ )
>
> Reason for revert:
> Breaks down-stream dependencies.
>
> Original issue's description:
> > APM: Change 3 UMA metrics to fewer but linearly distributed buckets
> >
> > In this change WebRTC.Audio.ApmCaptureInputLevel{Average,Peak} are
> > changed to 64 buckets, while WebRTC.Audio.AgcLevel is changed to 50
> > buckets. All three are changed to have linear spacing between buckets.
> >
> > Also, the metrics are renamed to avoid stats conflicts because of different bucket schemes:
> > - WebRTC.Audio.AgcLevel -> WebRTC.Audio.AgcSetLevel
> > - WebRTC.Audio.ApmCaptureInputLevelAverage -> WebRTC.Audio.ApmCaptureInputLevelAverageRms
> > - WebRTC.Audio.ApmCaptureInputLevelPeakRms -> WebRTC.Audio.ApmCaptureInputLevelPeakRms
> >
> > BUG=webrtc:6622
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
> >
> > Committed: https://crrev.com/49715fe3be17d8579586d5bc954d626126d53415
> > Cr-Commit-Position: refs/heads/master@{#15418}
>
> TBR=peah@webrtc.org,rkaplow@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6622
>
> Committed: https://crrev.com/63407a9b6ae6f3fc096e01d64e46c6d21d86b517
> Cr-Commit-Position: refs/heads/master@{#15420}
TBR=peah@webrtc.org,rkaplow@chromium.org
BUG=webrtc:6622
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.webrtc.org/2551863003
Cr-Commit-Position: refs/heads/master@{#15442}
Reason for revert:
Failures on the Linux Memcheck bot
Original issue's description:
> This approach passes packetization mode to the encoder as part of
> a cricket::VideoCodec structure, rather than as part of struct VideoCodecH264 inside webrtc::VideoCodec.
>
> BUG=600254
>
> Committed: https://crrev.com/e59647b991f61cf1cf61b020356705e6c0f81257
> Cr-Commit-Position: refs/heads/master@{#15437}
TBR=hbos@webrtc.org,sprang@webrtc.org,mflodman@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=600254
Review-Url: https://codereview.webrtc.org/2558453002
Cr-Commit-Position: refs/heads/master@{#15441}
flaky, with many false results and with a huge
variance.
This CL addresses that by changing the way the
API call durations are measured, using a warmup
period and a longer interval for computing the
timing estimates.
Furthermore, this CL reduces the number of tests
to compensate for the fact that the tests now are
more expensive, as well as to reduce the number
of regressions further.
BUG=webrtc:6614,webrtc:6685,666725
Review-Url: https://codereview.webrtc.org/2549403002
Cr-Commit-Position: refs/heads/master@{#15440}
a cricket::VideoCodec structure, rather than as part of struct VideoCodecH264 inside webrtc::VideoCodec.
BUG=600254
Review-Url: https://codereview.webrtc.org/2528343002
Cr-Commit-Position: refs/heads/master@{#15437}
The Bazel build format doesn't support having separate
lists of compilation flags for C and C++; it just has a single
copts list for cc_library:
https://bazel.build/versions/master/docs/be/c-cpp.html#cc_binary.copts
This makes it hard to convert our GN targets to Bazel when there are
compiler warnings that aren't supported for C (like -Woverloaded-virtual
being added in bugs.webrtc.org/6653).
The solution for this is to move all .c files to their own targets
and remove C++-only compiler flags during conversion.
New targets:
//webrtc/common_audio:common_audio_c
//webrtc/common_audio:common_audio_neon_c
//webrtc/modules/audio_coding:g711_c
//webrtc/modules/audio_coding:g722_c
//webrtc/modules/audio_coding:ilbc_c
//webrtc/modules/audio_coding:isac_c
//webrtc/modules/audio_coding:isac_fix_c
//webrtc/modules/audio_coding:isac_test_util
//webrtc/modules/audio_coding:pcm16b_c
//webrtc/modules/audio_coding:webrtc_opusj_c
//webrtc/modules/audio_device:mac_portaudio
//webrtc/modules/audio_procssing:audio_processing_c
//webrtc/modules/audio_procssing:audio_processing_neon_c
This CL also adds a PRESUBMIT.py check that will throw an error
if targets are mixing .c and .cc files, to preven this from regressing.
BUG=webrtc:6653
NOTRY=True
Review-Url: https://codereview.webrtc.org/2550563003
Cr-Commit-Position: refs/heads/master@{#15433}
We don't have a use case for it and have no reason to
support it.
BUG=webrtc:6706
Review-Url: https://codereview.webrtc.org/2543723004
Cr-Commit-Position: refs/heads/master@{#15428}
This change enables experimentation with the clipping minimum level
parameter in the gain control.
BUG=webrtc:6622
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.webrtc.org/2543753006
Cr-Commit-Position: refs/heads/master@{#15426}
It was incorrectly using a older version of the macro, which
wasn't discovered since the code wasn't built in WebRTC until now.
I moved webrtc/base/sigslottester.h from rtc_unittests into
rtc_base_test_utils instead to make it more usable.
BUG=webrtc:6821
Review-Url: https://codereview.webrtc.org/2551813002
Cr-Commit-Position: refs/heads/master@{#15422}
The intention is to make the tests less flaky.
BUG=webrtc:6744
Review-Url: https://codereview.webrtc.org/2552713002
Cr-Commit-Position: refs/heads/master@{#15421}
