I'm unsure what caused this to start occurring, but I don't believe it's
webrtc's fault, so I'm adding a suppression for now.
BUG=webrtc:7973
TBR=kjellander@webrtc.org
NOTRY=true
Review-Url: https://codereview.webrtc.org/2977723003
Cr-Commit-Position: refs/heads/master@{#18981}
Reason for revert:
Seems to be causing new crashes, possibly because of changes to the "Destroy(false)" behavior. Will re-land after investigating these crashes more and addressing the root cause.
Original issue's description:
> Delete SignalThread class.
>
> Rewrite AsyncResolver to use PlatformThread directly, not
> SignalThread, and update includes of peerconnection client to not
> depend on signalthread.h.
>
> BUG=webrtc:6424,webrtc:7723
>
> Review-Url: https://codereview.webrtc.org/2915253002
> Cr-Commit-Position: refs/heads/master@{#18833}
> Committed: bc8feda1dbTBR=tommi@webrtc.org,kwiberg@webrtc.org,nisse@webrtc.org
NOPRESUBMIT=true
NOTRY=true
BUG=webrtc:6424,webrtc:7723
Review-Url: https://codereview.webrtc.org/2979733002
Cr-Commit-Position: refs/heads/master@{#18980}
Reason for revert:
Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
Original issue's description:
> Injectable Obj-C video codecs
>
> 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}
> Committed: a0349c138dTBR=magjed@webrtc.org,andersc@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7924
NOTRY=true
Review-Url: https://codereview.webrtc.org/2975963002
Cr-Commit-Position: refs/heads/master@{#18979}
Adds to the RTCConfiguration `ice_regather_interval_range` which, when
set, specifies the randomized delay between automatic runs of ICE
regathering. The regathering will occur on all networks and re-use the
existing ICE ufrag/password. New connections are established once the
candidates come back and WebRTC will automatically switch to the new
connection that corresponds to the currently selected connection.
Bug: webrtc:7969
Change-Id: I6bbf5439a48e285f704aed9f408631cba038c82b
Reviewed-on: https://chromium-review.googlesource.com/562505
Reviewed-by: Peter Thatcher <pthatcher@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18978}
Suppressing lint errors using comments is an undocumented feature of the
linter, and suppressing using the tools:ignore attribute should be
preferred.
Suppressing using comments becomes a problem when using the manifest
merger introduced in
6ada47bc79
as it reformats the comments slightly:
<!--suppress MissingPrefix -->
becomes
<!-- supress MissingPrefix -->
which causes the linter to disregard the suppression.
Bug: 740657
Change-Id: I8e365744d089271c390254e7c958b24b81043766
Reviewed-on: https://chromium-review.googlesource.com/566860
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Ingemar Ådahl <ingemara@opera.com>
Cr-Commit-Position: refs/heads/master@{#18971}
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}
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}
