This CL robustifies the echo removal in AEC3 during the initial parts
of a call in two ways:
-By extending the period until which a headset is deemed to be used.
-By increasing the assumed echo path gain for unknown echo paths at
higher frequencies.
BUG=webrtc:7971
Review-Url: https://codereview.webrtc.org/2974883002
Cr-Commit-Position: refs/heads/master@{#18967}
Don't force requirement of media type for those packets.
BUG=webrtc:7964
Review-Url: https://codereview.webrtc.org/2973323002
Cr-Commit-Position: refs/heads/master@{#18966}
This makes more sense since logically it's a transport level feature,
not a media stream feature. Even if the implementation details forces it
to be an rtp stream detail, for the moment.
BUG=webrtc:7907
Review-Url: https://codereview.webrtc.org/2978503002
Cr-Commit-Position: refs/heads/master@{#18963}
This CL adds two changes:
-Adaptive adjustment of the echo suppression to both cover the cases
when the echo path well covers the room, and when when it does not.
-Identification of the case when the echo is too low to be audible
and adaptive handling of this case in the echo suppression.
BUG=webrtc:7519, webrtc:7956,webrtc:7957
Review-Url: https://codereview.webrtc.org/2974583004
Cr-Commit-Position: refs/heads/master@{#18962}
Defaults are consistent with these used in CallTest.
BUG=none
Review-Url: https://codereview.webrtc.org/2972423002
Cr-Commit-Position: refs/heads/master@{#18961}
It takes a bool argument, but unconditionally sets the flag to "true".
Since no comment is left to offer an explanation, I'm assuming this was
an accident.
BUG=webrtc:7716
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2974873002
Cr-Commit-Position: refs/heads/master@{#18959}
Reason for revert:
Failing chromoting tests
Original issue's description:
> Refactor timing frame logic to work with encoders with internal sources
>
> BUG=webrtc:7594,webrtc:7893
>
> Review-Url: https://codereview.webrtc.org/2968153002
> Cr-Commit-Position: refs/heads/master@{#18955}
> Committed: a7a4535a35TBR=sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7594,webrtc:7893
Review-Url: https://codereview.webrtc.org/2980533002
Cr-Commit-Position: refs/heads/master@{#18957}
PlayoutFrequency(), at least, is called ~200 times a second. The others
appear to not be in practice, but it's unclear what value they serve.
They were traces before https://chromium-review.googlesource.com/c/518133/,
which was more reasonable, as you could enable them for just audio
coding traces. But now that they are just logs, they make all VERBOSE
logging unusable.
Bug: webrtc:7959
Change-Id: I190a61c8ff4c0f047798087e80adbb41d791fc29
Reviewed-on: https://chromium-review.googlesource.com/563881
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Noah Richards <noahric@chromium.org>
Cr-Commit-Position: refs/heads/master@{#18956}
Since the keep-alive payload type is not registered in the payload type
map of FakeNetworkPipe, it will cause a DCHECK to trigger unless we're
able to destroy the call before that.
Just register it in the fake network as media type "any", it will be
discarded early on the receive side anyway.
BUG=webrt:7964
Review-Url: https://codereview.webrtc.org/2979543002
Cr-Commit-Position: refs/heads/master@{#18953}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2973183002
Cr-Commit-Position: refs/heads/master@{#18948}
Change MockRtpRtcp to NiceMock<MockRtpRtcp> throughout PacketRouterTest and PacketRouterRembTest (12 tests in total), to suppress a large number of warnings which are currently ignored.
BUG=None
Review-Url: https://codereview.webrtc.org/2977533002
Cr-Commit-Position: refs/heads/master@{#18946}
Replace the use of webrtc::VideoEncoderFactory with
cricket::WebRtcVideoEncoderFactory and remove the adapter classes
between these two factory types.
Some code changes were necessary in order to accomplish this:
* Move SimulcastEncoderAdapter from
webrtc/modules/video_coding/codecs/vp8 to webrtc/media/engine (that's
where it's used).
* Rename simulcast_unittest.h to simulcast_test_utility.h and make it
into it's own target, because it's used from both
simulcast_unittest.cc and simulcast_encoder_adapter_unittest.cc.
* Remove ownership of the encoder factory from SimulcastEncoderAdapter,
and make the necessary changes in surrounding code.
The goal with this CL is to clean up the code, and also to free up
the name webrtc::VideoEncoderFactory for future use.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/2964953002
Cr-Commit-Position: refs/heads/master@{#18945}
Reason for revert:
It breaks a downstream project.
Original issue's description:
> Change VideoTrack implementation to invoke VideoTrackSourceInterface::AddOrUpdateSink on the worker thread.
>
> Added documentation of thread expectations for video tracks and sources to the API.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2964863002
> Cr-Commit-Position: refs/heads/master@{#18938}
> Committed: f1377f7222TBR=deadbeef@webrtc.org,noahric@chromium.org,yujo@chromium.org,perkj@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=None
Review-Url: https://codereview.webrtc.org/2979493003
Cr-Commit-Position: refs/heads/master@{#18942}
First patch set uses a script attached in an issue comment:
https://bugs.chromium.org/p/webrtc/issues/detail?id=5118#c24
This discards the boilerplate prefix of WEBRTC_TRACE log strings, but it appears to be discarded anyway by all users.
Second patch set removes the header and makes small fixes to four of the log messages.
BUG=webrtc:5118
Review-Url: https://codereview.webrtc.org/2958273002
Cr-Commit-Position: refs/heads/master@{#18941}
Ensure that the ring buffer does not return a pointer into the buffer if
no data is available to read.
The ring buffer fix is not directly applicable to issue webrtc:7845, but may cause related memory errors.
BUG=webrtc:7845
Review-Url: https://codereview.webrtc.org/2971313002
Cr-Commit-Position: refs/heads/master@{#18940}
Prior to https://codereview.webrtc.org/2750783004/ Reset() intentionally
did not zero out the buffer. After that change, callers calling Reset()
and then mutable_data() were performing a wasteful zeroing.
This change adds ResetWithoutMuting() to match the old behavior and
switches the sole non-test caller of Reset() to use ResetWithoutMuting()
instead.
Prior to this change (optimized, Linux):
$ out/Default/webrtc_perf_tests --gtest_filter=NetEqPerformanceTest.Run* \
--gtest_repeat=10 | grep neteq_performance
*RESULT neteq_performance: 10_pl_10_drift= 4051 ms
*RESULT neteq_performance: 0_pl_0_drift= 1768 ms
*RESULT neteq_performance: 10_pl_10_drift= 3666 ms
*RESULT neteq_performance: 0_pl_0_drift= 1690 ms
*RESULT neteq_performance: 10_pl_10_drift= 3685 ms
*RESULT neteq_performance: 0_pl_0_drift= 1693 ms
*RESULT neteq_performance: 10_pl_10_drift= 3720 ms
*RESULT neteq_performance: 0_pl_0_drift= 1690 ms
*RESULT neteq_performance: 10_pl_10_drift= 3780 ms
*RESULT neteq_performance: 0_pl_0_drift= 1728 ms
*RESULT neteq_performance: 10_pl_10_drift= 3733 ms
*RESULT neteq_performance: 0_pl_0_drift= 1737 ms
*RESULT neteq_performance: 10_pl_10_drift= 3781 ms
*RESULT neteq_performance: 0_pl_0_drift= 1744 ms
*RESULT neteq_performance: 10_pl_10_drift= 3712 ms
*RESULT neteq_performance: 0_pl_0_drift= 1731 ms
*RESULT neteq_performance: 10_pl_10_drift= 3681 ms
*RESULT neteq_performance: 0_pl_0_drift= 1691 ms
*RESULT neteq_performance: 10_pl_10_drift= 3681 ms
*RESULT neteq_performance: 0_pl_0_drift= 1690 ms
With this change:
$ out/Default/webrtc_perf_tests --gtest_filter=NetEqPerformanceTest.Run* \
--gtest_repeat=10 | grep neteq_performance
*RESULT neteq_performance: 10_pl_10_drift= 3824 ms
*RESULT neteq_performance: 0_pl_0_drift= 1632 ms
*RESULT neteq_performance: 10_pl_10_drift= 3502 ms
*RESULT neteq_performance: 0_pl_0_drift= 1521 ms
*RESULT neteq_performance: 10_pl_10_drift= 3520 ms
*RESULT neteq_performance: 0_pl_0_drift= 1534 ms
*RESULT neteq_performance: 10_pl_10_drift= 3517 ms
*RESULT neteq_performance: 0_pl_0_drift= 1530 ms
*RESULT neteq_performance: 10_pl_10_drift= 3521 ms
*RESULT neteq_performance: 0_pl_0_drift= 1527 ms
*RESULT neteq_performance: 10_pl_10_drift= 3511 ms
*RESULT neteq_performance: 0_pl_0_drift= 1533 ms
*RESULT neteq_performance: 10_pl_10_drift= 3518 ms
*RESULT neteq_performance: 0_pl_0_drift= 1523 ms
*RESULT neteq_performance: 10_pl_10_drift= 3503 ms
*RESULT neteq_performance: 0_pl_0_drift= 1524 ms
*RESULT neteq_performance: 10_pl_10_drift= 3514 ms
*RESULT neteq_performance: 0_pl_0_drift= 1534 ms
*RESULT neteq_performance: 10_pl_10_drift= 3501 ms
*RESULT neteq_performance: 0_pl_0_drift= 1530 ms
BUG=webrtc:7343,chromium:738852,chromium:738839
Change-Id: Idcbb276ca0ed27fff95164a73f1c1fa310175ee5
Reviewed-on: https://chromium-review.googlesource.com/563021
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18939}
Added documentation of thread expectations for video tracks and sources to the API.
BUG=None
Review-Url: https://codereview.webrtc.org/2964863002
Cr-Commit-Position: refs/heads/master@{#18938}
This CL removes code that supported the now removed
downstream dependencies in the support for using an
external audio processing module.
BUG=webrtc:7939
Review-Url: https://codereview.webrtc.org/2969213002
Cr-Commit-Position: refs/heads/master@{#18929}
Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
(wrapping the VideoToolbox codec).
Some notes / things left to do:
- There are some hard-coded references to codec types that are supported by
webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
These types would need to be more codec agnostic to avoid this.
- Most interfaces are borrowed from the design document for injectable
codecs in Android. Some data in the corresponding C++ classes is discarded
when converting to the Obj-C version, since it has fewer fields. I have not
verified whether all data that we do keep is needed, or whether we might be
losing anything useful in these conversions.
- Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
Decoder wrapper classes.
- List the injected codec factory's supported codecs in the list of codecs in
AppRTCMobile.
BUG=webrtc:7924
R=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2966023002 .
Cr-Commit-Position: refs/heads/master@{#18928}
On Windows8/10, we prefer cropping desired window out from a whole screen
capture due to some reasons. The problem is Win10 has an invisible border
around the window. If we leave the border, it will expose background a bit.
This cl is about to always remove the border of desired window on Win8/10.
This will help a lot to capturing still windows during window sharing.
This cl still can't handle the background exposure issue when you move the
target window around during capturing. More investigation is needed.
BUG=chromium:737278
Review-Url: https://codereview.webrtc.org/2973853002
Cr-Commit-Position: refs/heads/master@{#18921}
In practice, this change will make AudioFrame::muted_ replicate the
explicit muted variable, passed as a pointer to NetEq::GetAudio.
BUG=webrtc:7944
Review-Url: https://codereview.webrtc.org/2965203002
Cr-Commit-Position: refs/heads/master@{#18914}
Lower then bitrate so that the delta between the highest layer of the
lower stream and lowest layer of the higher stream is not too large.
BUG=webrtc:4172
This is a reland of the following CL:
Review-Url: https://codereview.webrtc.org/2791273002
Cr-Commit-Position: refs/heads/master@{#18232}
Committed: dceb42da3e
https: //codereview.webrtc.org/2883963002
Review-Url: https://codereview.webrtc.org/2966833002
Cr-Commit-Position: refs/heads/master@{#18913}
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}
