Currently, when we generate the list of supported video codecs that will
be signaled in SDP, we start with the internal video codecs and then
append the external video codecs. When we create a video encoder for a
given codec, we prefer an external encoder over an internal encoder.
This CL lists the external video codecs first in SDP instead, so that we
consistently prefer external video codecs over internal.
The reason for doing this is that we will otherwise prefer an internal
SW H264 encoder over an external HW H264 encoder if the H264 profiles
differs.
BUG=chromium:688541
Review-Url: https://codereview.webrtc.org/2974383002
Cr-Commit-Position: refs/heads/master@{#19026}
This reverts commit aa41f0cfa64ece911ae2ecee83fc3190d4a42935.
Reason for revert:
Apparently, use of std::random_device() causes chromium on Linux to fail with this error:
terminating with uncaught exception of type std::__1::system_error: random_device failed to open /dev/urandom: Operation not permitted
Link to bot with failure:
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Linux%20Tester/builds/37563
Original change's description:
> API for periodically regathering ICE candidates
>
> 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}
TBR=pthatcher@webrtc.org,deadbeef@webrtc.org,steveanton@webrtc.org
No-Try: true
Bug: webrtc:7969
Change-Id: I86ef99e9f1070d3ac265398831317b68f562c614
Reviewed-on: https://chromium-review.googlesource.com/571008
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19024}
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}
If a SurfaceViewRenderer is reinitialized, the onFirstFrameRendered
callback is not fired.
Ensure that we reset the flag when the SurfaceViewRenderer is
initialized.
BUG=webrtc:7985
Review-Url: https://codereview.webrtc.org/2981793002
Cr-Commit-Position: refs/heads/master@{#19016}
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}
Check that ice_regather_interval_range is set only when continual
regathering is also set.
Bug: webrtc:7969
Change-Id: Ifcfeee744d817cf00914418d7e682f11528faf05
Reviewed-on: https://chromium-review.googlesource.com/569358
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19009}
GetSystemInfo will not return more than 32 for dwNumberOfProcessors when
called from a 32-bit process. This means that Chrome lies to me whenever
I enable logging. Calling GetNativeSystemInfo allows Chrome to return up
to 64 as the processor count. GetNativeSystemInfo even runs on WindowsXP
if that matters.
With the fix applied in a Chromium repo the logging at startup now says:
[320:196:712/335.515:INFO:cpu_info.cc(50)] Available number of cores: 48
BUG=webrtc:7981
Review-Url: https://codereview.webrtc.org/2978863002
Cr-Commit-Position: refs/heads/master@{#19008}
Currently, WebRTC is setting this config via mac_sdk_min_build_override. The old
mechanism is deprecated, but cannot be removed until chromium is updated to no
longer require mac_sdk_min_build_override.
BUG=chromium:740693
TBR=kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2979603002
Cr-Commit-Position: refs/heads/master@{#19006}
Reason for revert:
Fix the broken build file
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
>
> Reason for revert:
> Breaks bots. Build file incorrect.
>
> Original issue's description:
> > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
> >
> > Reason for revert:
> > New CL for fixing the issues
> >
> > Original issue's description:
> > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> > >
> > > 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: a0349c138d
> > >
> > > TBR=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}
> > > Committed: 1095ada7ad
> >
> > R=magjed@webrtc.org
> > TBR=tkchin@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7924
> >
> > Review-Url: https://codereview.webrtc.org/2981583002 .
> > Cr-Commit-Position: refs/heads/master@{#19002}
> > Committed: a5f1de1e65
>
> TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2979973002
> Cr-Commit-Position: refs/heads/master@{#19004}
> Committed: 81d40ee149TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,sprang@webrtc.org
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2979983002
Cr-Commit-Position: refs/heads/master@{#19005}
Reason for revert:
Breaks bots. Build file incorrect.
Original issue's description:
> Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
>
> Reason for revert:
> New CL for fixing the issues
>
> Original issue's description:
> > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> >
> > 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: a0349c138d
> >
> > TBR=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}
> > Committed: 1095ada7ad
>
> R=magjed@webrtc.org
> TBR=tkchin@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2981583002 .
> Cr-Commit-Position: refs/heads/master@{#19002}
> Committed: a5f1de1e65TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2979973002
Cr-Commit-Position: refs/heads/master@{#19004}
Reason for revert:
Break projects.
Original issue's description:
> Make the default ctor of rtc::Thread, protected.
> The goal is to force use of Thread::Create or Thread::CreateWithSocketServer.
>
> The default constructor constructs a 'default' socket server, which is usually a 'physical' socket server, but not always. Not every instance of Thread actually needs to have network support, so it's better to have this be explicit instead of unknowingly instantiate one.
>
> BUG=none
>
> Review-Url: https://codereview.webrtc.org/2981623002
> Cr-Commit-Position: refs/heads/master@{#19001}
> Committed: a8a3515997TBR=kthelgason@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=none
Review-Url: https://codereview.webrtc.org/2979963002
Cr-Commit-Position: refs/heads/master@{#19003}
Reason for revert:
New CL for fixing the issues
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
>
> 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: a0349c138d
>
> TBR=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}
> Committed: 1095ada7adR=magjed@webrtc.orgTBR=tkchin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2981583002 .
Cr-Commit-Position: refs/heads/master@{#19002}
The goal is to force use of Thread::Create or Thread::CreateWithSocketServer.
The default constructor constructs a 'default' socket server, which is usually a 'physical' socket server, but not always. Not every instance of Thread actually needs to have network support, so it's better to have this be explicit instead of unknowingly instantiate one.
BUG=none
Review-Url: https://codereview.webrtc.org/2981623002
Cr-Commit-Position: refs/heads/master@{#19001}
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}
