Run a script to replace occurrences of WEBRTC_TRACE logging with the new
style, on webrtc/modules/audio_device/linux/audio_device_alsa_linux.cc.
Patch set 2:
Manually fix log lines not handled by the script, remove unused header
and variable.
I would like to do this will the following files, too:
webrtc/modules/audio_device/..
.../linux/audio_device_alsa_linux.cc
.../linux/audio_device_pulse_linux.cc
.../linux/audio_mixer_manager_alsa_linux.cc
.../linux/audio_mixer_manager_pulse_linux.cc
.../linux/latebindingsymboltable_linux.cc
.../mac/audio_device_mac.cc
.../mac/audio_mixer_manager_mac.cc
.../win/audio_device_core_win.cc
BUG=webrtc:5118
Review-Url: https://codereview.webrtc.org/2978953003
Cr-Commit-Position: refs/heads/master@{#19019}
Both DXGI_OUTPUT_DESC and DISPLAY_DEVICE contain the DeviceName, which may be
able to map a DirectX screen id with the GDI screen id.
So this change exports the field from both DirectX and GDI implementations.
BUG=webrtc:7950
Review-Url: https://codereview.webrtc.org/2971393002
Cr-Commit-Position: refs/heads/master@{#19010}
The root cause is when a DxgiContext is reseted, it has not been correctly
cleared from DxgiOutputDuplicator. So during next CaptureFrame() function call,
DxgiOutputDuplicator will spread the context change to a deleted instance.
BUG=741252
Review-Url: https://codereview.webrtc.org/2975103002
Cr-Commit-Position: refs/heads/master@{#18992}
This avoids a memcopy call which may corrupt audio handling and, in rare cases, crash WebRTC with a buffer over-read.
BUG=webrtc:7845
Review-Url: https://codereview.webrtc.org/2980723002
Cr-Commit-Position: refs/heads/master@{#18984}
The check triggered in 30 / 1000 cases of running PeerConnectionIntegrationTest.CallTransferredForCaller locally, far more often than expected.
It will soon be replaced by more graceful handling.
BUG=webrtc:7845
Review-Url: https://codereview.webrtc.org/2975043002
Cr-Commit-Position: refs/heads/master@{#18983}
Instead, use a TaskQueue in the only test that required it.
BUG=none
Review-Url: https://codereview.webrtc.org/2975883002
Cr-Commit-Position: refs/heads/master@{#18969}
This CL adds detection of components in the render signal that are of
strong narrowband nature and therefore may cause problems for the AEC.
This CL also adds functionality in the echo suppressor to suppress
these signals
BUG=webrtc:7967
Review-Url: https://codereview.webrtc.org/2980493002
Cr-Commit-Position: refs/heads/master@{#18968}
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}
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}
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}
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}
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}
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}
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}
This reverts commit 2d54784d890be462a7fbf0fcfdc633bc4791982a.
Reason for revert: upstream conflicts
Original change's description:
> Reland "Adding ANA config event to debug dump."
>
> Originally review in https://chromium-review.googlesource.com/c/535554/
>
> Reverted in https://chromium-review.googlesource.com/c/539737/ due to upstreaming failure.
>
> BUG=webrtc:7854
>
> Change-Id: Ie4ad6ecfaf0f6b556dc662512d0be8ce94f8a4a8
> Reviewed-on: https://chromium-review.googlesource.com/541436
> Commit-Queue: Minyue Li <minyue@webrtc.org>
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#18865}
TBR=minyue@webrtc.org,ossu@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:7854
Change-Id: I28841ed088664d2965454dc52196f83c9d81773e
Reviewed-on: https://chromium-review.googlesource.com/559429
Commit-Queue: Minyue Li <minyue@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18904}
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}
