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
Review-Url: https://codereview.webrtc.org/2548333002
Cr-Commit-Position: refs/heads/master@{#15420}
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
Review-Url: https://codereview.webrtc.org/2547593002
Cr-Commit-Position: refs/heads/master@{#15418}
This push decision if Marker bit should be set into packetizers fixing
issue where returned last_packet flag was ambiguous for some VP9 packets.
Added test for VP9 where last_packet != marker_bit
BUG=webrtc:6723
Review-Url: https://codereview.webrtc.org/2522553002
Cr-Commit-Position: refs/heads/master@{#15415}
This CL is in preparation to move the AudioFrame into webrtc/api. The
AudioFrame is a POD type used for representing 10ms of audio. It
appears as a parameter and return value of interfaces being migrated
to webrtc/api, in particular AudioMixer.
Here, methods operator+=, operator>>=, Mute are
moved into a new target webrtc/audio/utility/audio_frame_operations,
and dependencies are changed to use
the new versions. The old AudioFrame methods are marked deprecated.
The audio frame utilities in webrtc/modules/utility:audio_frame_operations
are also moved to the new location.
TBR=kjellander@webrtc.org
BUG=webrtc:6548
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2424173003
Cr-Commit-Position: refs/heads/master@{#15413}
Change the second parameter type to a const reference of vector so that
the vector will not be copied.
BUG=none
Review-Url: https://codereview.webrtc.org/2551603003
Cr-Commit-Position: refs/heads/master@{#15396}
https://codereview.webrtc.org/2504023002 broke exponential probing.
After that change ProbeController stops exponential probes prematurely:
it goes to kProbingComplete state if SetEstimatedBitrate() is called
with bitrate lower than min_bitrate_to_probe_further_bps_, which always
happens with the first pair of probes. As result it wasn't sending
repeated probes as it should. This change fixes that issue by moving
probe expieration logic to ProbeContoller::Process(). This also ensures
that the controller goes to kProbingComplete state as soon as probing
timeout expired, without waiting for the next SetEstimatedBitrate()
call.
BUG=669421
Review-Url: https://codereview.webrtc.org/2546613003
Cr-Commit-Position: refs/heads/master@{#15392}
Error resilience is currently always enabled for VP9 which reduces quality.
BUG=webrtc:6783
Review-Url: https://codereview.webrtc.org/2532053002
Cr-Commit-Position: refs/heads/master@{#15390}
Before this the BWE was allowed to operate freely up to 100 kbps. This isn't a good idea for audio BWE.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2542083003
Cr-Commit-Position: refs/heads/master@{#15389}
This tool takes list of video file names as input and calculates freezing metrics score for the video files without having reference to original video by comparing the PSNR and SSIM values of current and previous frame.
BUG=webrtc:6759
Review-Url: https://codereview.webrtc.org/2515253004
Cr-Commit-Position: refs/heads/master@{#15386}
This is in preparation for https://codereview.webrtc.org/2517173004/,
which needs some updates of downstream dependencies. This cl adds the
target to api/BUILD.gn, creates the directory api/video, and a single
harmless include file there.
BUG=webrtc:5880
Review-Url: https://codereview.webrtc.org/2546723003
Cr-Commit-Position: refs/heads/master@{#15385}
The tool is no longer needed and will be removed in Chromium.
BUG=chromium:670470
Review-Url: https://codereview.webrtc.org/2548763002
Cr-Commit-Position: refs/heads/master@{#15384}
It is not safe to call vpx_codec_destroy if vpx_codec_dec_init failed,
because the |decoder_| memory will be uninitialized. See the bug for
more info.
BUG=chromium:663293
Review-Url: https://codereview.webrtc.org/2541163007
Cr-Commit-Position: refs/heads/master@{#15381}
The packet size was only used to control how often to output DTMF
packets. However, it likely did not work as intended, since that
interval was only set during initialization. No changes to the packet
size, like what AudioEncoder::Num10MsFramesInNextPacket could
indicate, were picked up. The value was instead taken from an entry in
ACMCodecDB.
Since it was not-fully-functional, its exact value didn't seem to
matter and it was getting in the way of making it possible to supply
an external audio encoder factory, I've decided to remove it
altogether. The DTMF code now uses an interval of 50 ms regardless,
which is a value recommended by the RFC.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2545753002
Cr-Commit-Position: refs/heads/master@{#15380}
QualityScaler may scale down the resolution, so our tests shouldn't
expect the input resolution to exactly match the resolution received on
the other side. Instead, we now just check that the aspect ratio
matches.
BUG=webrtc:5907
Review-Url: https://codereview.webrtc.org/2547673002
Cr-Commit-Position: refs/heads/master@{#15373}
This isn't a performance test, so it may be running in a slow
environment, and shouldn't be subject to strict timeouts.
BUG=webrtc:6801
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2539183005
Cr-Commit-Position: refs/heads/master@{#15370}
We still DCHECK for RTP, but not RTCP. RTCP packets can be sent before
offer/answer negotiation is complete, due to this bug:
https://bugs.chromium.org/p/webrtc/issues/detail?id=6809
This bug can only occur if the RTCP mux policy is "require", which is
why we started hitting it recently (the default in unit tests was
recently changed to "require").
BUG=webrtc:6776
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2542233002
Cr-Commit-Position: refs/heads/master@{#15369}
This change adds HistogramFactoryGetCountsLinear and
RTC_HISTOGRAM_COUNTS_LINEAR. Note that the default implementation of
HistogramFactoryGetCounts in metrics_default.cc also provides a
linearly spaced histogram, while the Chrome UMA implementation
provides exponentially spaced buckets.
BUG=none
Review-Url: https://codereview.webrtc.org/2548463002
Cr-Commit-Position: refs/heads/master@{#15367}
AdaptiveVideoSource is used in testing/simulations of the bandwidth estimator.
Nada's reaction to delay depends on the current bitrate and the configured max rate in a non-intuituve way. Increase the starting bitrate to compensate for the increased max bitrate. This is only used in unit tests.
BUG=webrtc:6807
# Presubmit warns about a lint error in bwe.h that's unrelated to my change. Fixing it is beyond the scope of this CL.
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/2542843003
Cr-Commit-Position: refs/heads/master@{#15364}
When starting from 720p this is necessary to achieve acceptable
quality at low bitrates.
BUG=webrtc:6495
Review-Url: https://codereview.webrtc.org/2538913003
Cr-Commit-Position: refs/heads/master@{#15356}
These tests have been a little flaky on the bots.
Hopefully increasing the timeout by 200% will help.
BUG=webrtc:6799
Review-Url: https://codereview.webrtc.org/2541743006
Cr-Commit-Position: refs/heads/master@{#15355}
This CL makes a method available on the AVFoundationVideoCapturer
that adapts the output format of captured video to the specified
width and height.
BUG=webrtc:6753
Review-Url: https://codereview.webrtc.org/2528493004
Cr-Commit-Position: refs/heads/master@{#15351}
The goal with this CL is to move implementation details out from the
webrtc root (webrtc/video_decoder.h) to simplify the dependency graph.
Another goal is to streamline the creation of VideoDecoders in
webrtcvideoengine2.cc; it will now have two factories of the same
WebRtcVideoDecoderFactory type, one internal and one external.
Specifically, this CL:
* Removes webrtc::VideoDecoder::DecoderType and use webrtc::VideoCodecType
instead.
* Removes 'static VideoDecoder* Create(DecoderType codec_type)' and
moves the create function to the internal decoder factory instead.
* Removes video_decoder.cc. webrtc::VideoDecoder is now just an
interface without any static functions.
BUG=webrtc:6743
Review-Url: https://codereview.webrtc.org/2521203002
Cr-Commit-Position: refs/heads/master@{#15350}
This change makes the Java classes and constructors for
SurfaceTextureHelper and I420Frame public. This allows applications to
use the WebRTC CameraVideoCapturer to obtain raw frames, and to render
frames on the WebRTC VideoRenderer without having to pass them through a
VideoTrack - such as when using Quartc.
BUG=None.
Review-Url: https://codereview.webrtc.org/2544563002
Cr-Commit-Position: refs/heads/master@{#15344}
This is to assess the performance penalty of the (current)
lack of integration with FlexFEC and BWE.
This CL also enables send-side BWE for the following tests:
- foreman_cif_net_delay_0_0_plr_0_VP9
- foreman_cif_net_delay_0_0_plr_0_H264
- foreman_cif_delay_50_0_plr_5_VP9
- foreman_cif_delay_50_0_plr_5_H264
- foreman_cif_delay_50_0_plr_5_H264_flexfec
- foreman_cif_delay_50_0_plr_5_H264_ulpfec
Perf alerts on these tests are therefore expected.
R=stefan@webrtc.org
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2534203004
Cr-Commit-Position: refs/heads/master@{#15339}
It is unused since cl https://codereview.webrtc.org/2386573002.
The new denoiser implementation and its tests are kept for now. This
code is also unused, but there are some plans to take this code into
use in the not too distant future.
BUG=None
Review-Url: https://codereview.webrtc.org/2496153002
Cr-Commit-Position: refs/heads/master@{#15338}
We already have an implementation in h264_common. We should have
as few of these as possible as they are subtly hard to get right
and it creates work to maintain N implementations.
BUG=webrtc:6546
Review-Url: https://codereview.webrtc.org/2538133002
Cr-Commit-Position: refs/heads/master@{#15336}
