This layer takes in a simplified "options" struct and the current local description,
and generates a new offer/answer. Previously the options struct assumed there would
only be one media description per media type (audio/video), but it now supports
N number of audio/video descriptions.
The |add_legacy_stream| options is removed from the mediasession.cc/.h
in this CL.
The next step is to add the ability for PeerConnection/WebRtcSession to create
"options" to represent multiple RtpTransceivers, and apply the Unified Plan
descriptions correctly. Right now, only Plan B descriptions will be
generated in unit tests.
BUG=chromium:465349
Review-Url: https://codereview.webrtc.org/2991693002
Cr-Original-Commit-Position: refs/heads/master@{#19343}
Committed: a77e6bbd30
Review-Url: https://codereview.webrtc.org/2991693002
Cr-Commit-Position: refs/heads/master@{#19394}
Reason for revert:
BUG=webrtc:8108: breaks Clang build.
Original issue's description:
> Adding support for Unified Plan offer/answer negotiation to the mediasession layer.
>
> This layer takes in a simplified "options" struct and the current local description,
> and generates a new offer/answer. Previously the options struct assumed there would
> only be one media description per media type (audio/video), but it now supports
> N number of audio/video descriptions.
>
> The |add_legacy_stream| options is removed from the mediasession.cc/.h
> in this CL.
>
> The next step is to add the ability for PeerConnection/WebRtcSession to create
> "options" to represent multiple RtpTransceivers, and apply the Unified Plan
> descriptions correctly. Right now, only Plan B descriptions will be
> generated in unit tests.
>
> BUG=chromium:465349
>
> Review-Url: https://codereview.webrtc.org/2991693002
> Cr-Commit-Position: refs/heads/master@{#19343}
> Committed: a77e6bbd30TBR=deadbeef@webrtc.org,zhihuang@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:465349
Review-Url: https://codereview.webrtc.org/3001083002
Cr-Commit-Position: refs/heads/master@{#19384}
Reason for revert:
It breaks a downstream project.
Original issue's description:
> Trace the stats report as JSON instead of each stat separately.
>
> Trace the whole report as a string instead of each field on it's own. And test that the traces collected are valid.
>
> R=tommi@webrtc.org, hbos@webrtc.org
> BUG=chromium:653087
>
> Review-Url: https://codereview.webrtc.org/2986453002
> Cr-Commit-Position: refs/heads/master@{#19341}
> Committed: 80c65780e6TBR=hbos@webrtc.org,tommi@webrtc.org,ehmaldonado@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:653087
Review-Url: https://codereview.webrtc.org/3001683002
Cr-Commit-Position: refs/heads/master@{#19344}
This layer takes in a simplified "options" struct and the current local description,
and generates a new offer/answer. Previously the options struct assumed there would
only be one media description per media type (audio/video), but it now supports
N number of audio/video descriptions.
The |add_legacy_stream| options is removed from the mediasession.cc/.h
in this CL.
The next step is to add the ability for PeerConnection/WebRtcSession to create
"options" to represent multiple RtpTransceivers, and apply the Unified Plan
descriptions correctly. Right now, only Plan B descriptions will be
generated in unit tests.
BUG=chromium:465349
Review-Url: https://codereview.webrtc.org/2991693002
Cr-Commit-Position: refs/heads/master@{#19343}
That way, the debug printout will tell us which of x and y that was false.
BUG=none
Review-Url: https://codereview.webrtc.org/2988153003
Cr-Commit-Position: refs/heads/master@{#19297}
[This CL is work in progress.]
Wire up the rtp keep-alive in webrtc::Call::Config using new
SetRtpTransportParameters() method on RtpTransportInterface.
BUG=webrtc:7907
Review-Url: https://codereview.webrtc.org/2981513002
Cr-Commit-Position: refs/heads/master@{#19287}
Follow up to https://codereview.webrtc.org/2989243002/.
It turns out that "b=AS:-1" was being used to mean "no bandwidth limit",
even though just omitting "b=AS" completely will do that. So we should
treat this as a soft error for now, and give applications time to
transition to doing the standard thing.
BUG=chromium:675361
Review-Url: https://codereview.webrtc.org/2995463002
Cr-Commit-Position: refs/heads/master@{#19244}
It doesn't make sense to have a negative RTP session bandwidth; RFC3550
doesn't define any meaning for this. So just treat it as invalid SDP.
BUG=chromium:675361
Review-Url: https://codereview.webrtc.org/2989243002
Cr-Commit-Position: refs/heads/master@{#19221}
Added documentation of thread expectations for video tracks and sources to the API.
Originally landed as patchset #2 id:20001 of https://codereview.webrtc.org/2964863002/.
Patchset 1 is the originall cl.
Patschet 2 is modified so that VideoTrackInterface::AddSink and RemoveSink have a default implementation.
BUG=none
Review-Url: https://codereview.webrtc.org/2989113002
Cr-Commit-Position: refs/heads/master@{#19195}
This allows an application to easily override the default limit
(currently 5).
Also adding a test that covers more of the
PeerConnection<->PortAllocator interaction.
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2985653003
Cr-Commit-Position: refs/heads/master@{#19160}
There is an inconsistency in behavior of PeerConnection.
When I remove track from PeerConnection observer->OnRenegotiationNeeded is called, however if I remove track from MediaStream then there is no notification to renegotiate.
This patch adds missing OnRenegotiationNeeded calls.
BUG=webrtc:7966
Review-Url: https://codereview.webrtc.org/2977493002
Cr-Commit-Position: refs/heads/master@{#19125}
SrtpTransport currently just delegates everything to RtpTransport.
Also makes BaseChannel::rtp_transport_ an RtpTransportInternal and constructs an SrtpTransport if srtp is required.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/2981013002
Cr-Commit-Position: refs/heads/master@{#19095}
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/2976293002
Cr-Commit-Position: refs/heads/master@{#19094}
This reverts commit 26d5e2e2809558148dc1e977ec1bc8318a2047bc.
Reverted originally because it dependend on a CL which was reverted. That CL has been reinstated in: https://chromium-review.googlesource.com/#/c/572070/
Bug: webrtc:7969
Change-Id: I404c3a42ad447312d981646dca0aa4cf0ec3134e
Reviewed-on: https://chromium-review.googlesource.com/572403
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19034}
Use rtc::SystemTimeNanos() instead of std::random_device() for PRNG seed
to avoid crashing when /dev/urandom is unavailable.
This reverts commit 3beb20720db349f651c2c04970c45b1b171c025c.
Bug: webrtc:7969
Change-Id: I5ed58a789939ee4caa99ac3abf9cab18e3e19c69
Reviewed-on: https://chromium-review.googlesource.com/572070
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19033}
This is a partial re-land. The change doesn't make the default Thread ctor protected anymore but it does mark it as deprecated and updates all use of it in WebRTC.
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/2977953002
Cr-Commit-Position: refs/heads/master@{#19031}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
This CL finalizes the support for allowing an external
audio processing module to be used in a peerconnection.
BUG=webrtc:7775
Review-Url: https://codereview.webrtc.org/2965703002
Cr-Commit-Position: refs/heads/master@{#18864}
Can be enabled by setting "enable_encrypted_rtp_header_extensions" in
"crypto_options" of "PeerConnectionFactoryInterface::Options" and will
only be used if both peers support it.
BUG=webrtc:3411
Review-Url: https://codereview.webrtc.org/2761143002
Cr-Commit-Position: refs/heads/master@{#18842}
[This CL is a rebase of an original CL by solenberg@:
https://codereview.webrtc.org/2948763002/ which in turn was a
rebase of an original CL by peah@:
https://chromium-review.googlesource.com/c/527032/]
Allow an external audio processing module to be used in WebRTC
This CL adds support for optionally using an externally created audio
processing module in a peerconnection. The ownership is shared
between the peerconnection and the external creator of the module.
As part of this the internal ownership of the audio processing module
is moved from VoiceEngine to WebRtcVoiceEngine.
BUG=webrtc:7775
Review-Url: https://codereview.webrtc.org/2961723004
Cr-Commit-Position: refs/heads/master@{#18837}
Was only working when the nonstandard "renomination" extension to ICE
is enabled, which chromium doesn't use.
BUG=chromium:734094
Review-Url: https://codereview.webrtc.org/2957303002
Cr-Commit-Position: refs/heads/master@{#18814}
