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}
streams.
When addTrack/removeTrack is used instead of addStream/removeStream
we an end up with tracks that are not contained within any local or
remote stream.
If all track IDs are not mapped when we produce RTCRTPStreamStats
we'll hit a DCHECK.
BUG=chromium:741638
Review-Url: https://codereview.webrtc.org/2978793002
Cr-Commit-Position: refs/heads/master@{#18991}
This will eventually be a unique_ptr<RtpTransportInternal> so that we can choose to use an RtpTransport or SrtpTransport.
BUG=None
Review-Url: https://codereview.webrtc.org/2974903003
Cr-Commit-Position: refs/heads/master@{#18987}
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}
Reason for revert:
Wasn't actually the source of the memcheck issue, so relanding.
Original issue's description:
> Revert of Make "set_ignore_non_default_routes" actually use its argument. (patchset #1 id:1 of https://codereview.webrtc.org/2974873002/ )
>
> Reason for revert:
> Breaks Linux memcheck bot.
> https://bugs.chromium.org/p/webrtc/issues/detail?id=7973
>
> Original issue's description:
> > Make "set_ignore_non_default_routes" actually use its argument.
> >
> > 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}
> > Committed: 05314c3252
>
> TBR=pthatcher@webrtc.org,pthatcher@google.com,deadbeef@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7716
>
> Review-Url: https://codereview.webrtc.org/2974193002
> Cr-Commit-Position: refs/heads/master@{#18964}
> Committed: 1e50748d47TBR=pthatcher@webrtc.org,pthatcher@google.com,sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7716
Review-Url: https://codereview.webrtc.org/2979803002
Cr-Commit-Position: refs/heads/master@{#18982}
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}
Reason for revert:
Breaks Linux memcheck bot.
https://bugs.chromium.org/p/webrtc/issues/detail?id=7973
Original issue's description:
> Make "set_ignore_non_default_routes" actually use its argument.
>
> 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}
> Committed: 05314c3252TBR=pthatcher@webrtc.org,pthatcher@google.com,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7716
Review-Url: https://codereview.webrtc.org/2974193002
Cr-Commit-Position: refs/heads/master@{#18964}
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}
