This CL adds the following interfaces:
* RtpTransportController
* RtpTransport
* RtpSender
* RtpReceiver
They're implemented on top of the "BaseChannel" object, which is normally used
in a PeerConnection, and roughly corresponds to an SDP "m=" section. As a result
of this, there are several limitations:
* You can only have one of each type of sender and receiver (audio/video) on top
of the same transport controller.
* The sender/receiver with the same media type must use the same RTP transport.
* You can't change the transport after creating the sender or receiver.
* Some of the parameters aren't supported.
Later, these "adapter" objects will be gradually replaced by real objects that don't
have these limitations, as "BaseChannel", "MediaChannel" and related code is
restructured. In this CL, we essentially have:
ORTC adapter objects -> BaseChannel -> Media engine
PeerConnection -> BaseChannel -> Media engine
And later we hope to have simply:
PeerConnection -> "Real" ORTC objects -> Media engine
See the linked bug for more context.
BUG=webrtc:7013
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2675173003
Cr-Commit-Position: refs/heads/master@{#16842}
"bundle_transport_name" is no longer relevant here, and
"rtcp_mux_required" is implied by whether or not an RTCP transport is
passed in.
BUG=None
Review-Url: https://codereview.webrtc.org/2689503002
Cr-Commit-Position: refs/heads/master@{#16551}
This helps show where ownership is transfered between objects.
Specifically, this CL wraps cricket::VideoCapturer, MediaEngineInterface
and DataEngineInterface in unique_ptr.
BUG=None
TBR=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2685093002
Cr-Commit-Position: refs/heads/master@{#16548}
DtlsTransportChannelWrapper is renamed to be DtlsTransport which inherits from
DtlsTransportInternal. There will be no concept of "channel" in p2p level.
Both P2PTransportChannel and DtlsTransport don't depend on TransportChannel
and TransportChannelImpl any more and they are removed in this CL.
BUG=none
Review-Url: https://codereview.webrtc.org/2606123002
Cr-Commit-Position: refs/heads/master@{#16173}
Reason for revert:
Failed the memory check.
May need to fix the memory leak.
Original issue's description:
> make the DtlsTransportWrapper inherit form DtlsTransportInternal
>
> BUG=none
>
> Review-Url: https://codereview.webrtc.org/2606123002
> Cr-Commit-Position: refs/heads/master@{#16160}
> Committed: 5aed06c8d3TBR=deadbeef@webrtc.org,pthatcher@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/2639203004
Cr-Commit-Position: refs/heads/master@{#16162}
Previously, BaseChannel supported a "no RTCP" mode, which wasn't
being used any more and is being deleted.
Also, "RTCP mux required" previously worked by calling "ActivateRtcpMux"
after construction. Now it works by explicitly passing a
"require_rtcp_mux" parameter into the constructor.
BUG=None
Review-Url: https://codereview.webrtc.org/2622613004
Cr-Commit-Position: refs/heads/master@{#16045}
The BaseChannel can set the transport directly without depending on
TransportController.
When initializing the network of the BaseChannel, the ChannelManager will
create TransportChannels with the TransportController.
When enabling bundling, WebRtcSession will get or create TransportChannels
with the TransportController.
When a TransportChannel of the BaseChannel needs to be destroyed, it will
fire a signal to notify the WebRtcSession.
BUG=none.
Review-Url: https://codereview.webrtc.org/2614263002
Cr-Commit-Position: refs/heads/master@{#16043}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Original-Commit-Position: refs/heads/master@{#15906}
Committed: 67b3bbe639
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15973}
Reason for revert:
Hitting DCHECK in chromium's WebrtcTransportTest.TerminateDataChannel and WebrtcTransportTest.DataStreamLate. Will investigate and reland.
Original issue's description:
> Separating SCTP code from BaseChannel/MediaChannel.
>
> The BaseChannel code is geared around RTP; the presence of media engines,
> send and receive streams, SRTP, SDP directional attribute negotiation, etc.
> It doesn't make sense to use it for SCTP as well. This separation should make
> future work both on BaseChannel and the SCTP code paths easier.
>
> SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
> directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
> doesn't get confused with webrtc::DataChannel any more.
>
> Beyond just moving code around, some consequences of this CL:
> - We'll now stop using the worker thread for SCTP. Packets will be
> processed right on the network thread instead.
> - The SDP directional attribute is ignored, as it's supposed to be.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2564333002
> Cr-Commit-Position: refs/heads/master@{#15906}
> Committed: 67b3bbe639TBR=pthatcher@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/2614813003
Cr-Commit-Position: refs/heads/master@{#15908}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15906}
"Crypto required" is a property of the PeerConnection of construction
time; it has nothing to do with SDP. So I'm moving it out of
MediaContentDescription and putting it in the BaseChannel constructor
instead. This is more intuitive, and provides the added assurance that
"secure_required_" can't be flipped from "true" to "false".
BUG=None
Review-Url: https://codereview.webrtc.org/2537343003
Cr-Commit-Position: refs/heads/master@{#15579}
Reason for revert:
This CL probably broke Chromium FYI.
Original issue's description:
> Stop caching supported codecs in WebRtcVideoEngine2
>
> We currently cache the result of GetSupportedCodecs in a member variable
> |video_codecs_| in WebRtcVideoEngine2. This means we need to keep
> |video_codecs_| and the result of GetSupportedCodecs in sync, which is
> error prone. It's simpler to just call GetSupportedCodecs when we need
> it, and we actually end up making fewer calls, so it's faster as well.
> This CL also returns all std::vectors by-value instead of by-ref. Move
> semantic together with in-place filtering of codecs actually end up with
> fewer copies, and it's also simpler to not return references.
>
> BUG=webrtc:6337
>
> Committed: https://crrev.com/9f71ec5a3e3175751f4475b126cfda89767363f2
> Cr-Commit-Position: refs/heads/master@{#15007}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2489173004
Cr-Commit-Position: refs/heads/master@{#15014}
We currently cache the result of GetSupportedCodecs in a member variable
|video_codecs_| in WebRtcVideoEngine2. This means we need to keep
|video_codecs_| and the result of GetSupportedCodecs in sync, which is
error prone. It's simpler to just call GetSupportedCodecs when we need
it, and we actually end up making fewer calls, so it's faster as well.
This CL also returns all std::vectors by-value instead of by-ref. Move
semantic together with in-place filtering of codecs actually end up with
fewer copies, and it's also simpler to not return references.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2492473002
Cr-Commit-Position: refs/heads/master@{#15007}
GCM cipher suites are optional (disabled by default) and can be enabled
through "PeerConnectionFactoryInterface::Options".
If compiled with Chromium (i.e. "ENABLE_EXTERNAL_AUTH" is defined), no
GCM ciphers can be used yet (see https://crbug.com/628400).
BUG=webrtc:5222, 628400
Review-Url: https://codereview.webrtc.org/1528843005
Cr-Commit-Position: refs/heads/master@{#13635}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Move RtcEventLog object from inside VoiceEngine to Call.
>
> In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
> The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
>
> BUG=webrtc:4741,webrtc:5603,chromium:609749
> R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
>
> Committed: https://crrev.com/1895526c6130e3d0e9b154f95079b8eda7567016
> Cr-Commit-Position: refs/heads/master@{#13321}
TBR=solenberg@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741,webrtc:5603,chromium:609749
Review-Url: https://codereview.webrtc.org/2111813002
Cr-Commit-Position: refs/heads/master@{#13340}
In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
BUG=webrtc:4741,webrtc:5603,chromium:609749
R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1748403002 .
Cr-Commit-Position: refs/heads/master@{#13321}
Added the plumbing necessary to get two different lists of codecs from
WebRtcVoiceEngine up to MediaSessionDescriptionFactory.
This should be the last step in this set of CLs. Once
https://codereview.webrtc.org/1991233004/ has landed, it's possible to
implement the ReceiveCodecs getter with the info from the
AudioDecoderFactory. The factory needs to be updated to actually
produce the correct list, as well.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2013053002
Cr-Commit-Position: refs/heads/master@{#13131}
With this change, when max-bundle and rtcp-mux are both enabled, we no
longer create and destroy a temporary transport channel when a media
channel gets added. Instead, the media channel uses the correct bundled
transport channel from the start.
This fixes a bug where adding a media type would cause the ICE state to
briefly become Disconnected and then immediately recover. The temporary
channel was created in a non-writable state, which caused the
TransportController to declare the ICE state to be Disconnected (as not
all transport channels were writable). Right after creation, the
temporary channel was then destroyed and the ICE state went back to the
correct one.
BUG=webrtc:5856
Review-Url: https://codereview.webrtc.org/1972493002
Cr-Commit-Position: refs/heads/master@{#12781}
The caller can set a negative or zero file size to avoid using a limit.
BUG=
Review-Url: https://codereview.webrtc.org/1974453002
Cr-Commit-Position: refs/heads/master@{#12730}
BaseChannel do calls to transport_channel on network_thread,
while keep calls to media_engine on worker_thread.
It still works when network_thread == worker_thread.
BUG=webrtc:5645
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1903393004 .
Cr-Commit-Position: refs/heads/master@{#12690}
I readded virtual bool Pause(bool paused) for now with a dummy implementation since Chrome remoting override this method.
Original cl description:
Removed unused cricket::VideoCapturer methods:
void UpdateAspectRatio(int ratio_w, int ratio_h);
void ClearAspectRatio();
bool Pause(bool paused);
Restart(const VideoFormat& capture_format);
MuteToBlackThenPause(bool muted);
IsMuted() const
set_square_pixel_aspect_ratio
bool square_pixel_aspect_ratio()
This cl also remove the use of messages and posting of state change.
Further more - a thread checker is added to make sure methods are called on only one thread. Construction can happen on a separate thred.
It does not add restrictions on what thread frames are delivered on though.
There is more features in VideoCapturer::Onframe related to screen share in ARGB that probably can be cleaned up in a follow up cl.
BUG=webrtc:5426
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1744153002 .
Cr-Commit-Position: refs/heads/master@{#11809}
Reason for revert:
Breaks remoting::protocol::WebrtcVideoCapturerAdapter::Pause'
See https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20Builder/builds/3689/steps/compile/logs/stdio
Original issue's description:
> Removed unused cricket::VideoCapturer methods:
>
> void UpdateAspectRatio(int ratio_w, int ratio_h);
> void ClearAspectRatio();
> ool Pause(bool paused);
> Restart(const VideoFormat& capture_format);
> MuteToBlackThenPause(bool muted);
> IsMuted() const
> set_square_pixel_aspect_ratio
> bool square_pixel_aspect_ratio()
>
> This cl also remove the use of messages and posting of state change.
> Further more - a thread checker is added to make sure methods are called on only one thread. Construction can happen on a separate thred.
> It does not add restrictions on what thread frames are delivered on though.
>
> There is more features in VideoCapturer::Onframe related to screen share in ARGB that probably can be cleaned up in a follow up cl.
>
> BUG=webrtc:5426
>
> Committed: https://crrev.com/e9c0cdff2dad2553b6ff6820c0c7429cb2854861
> Cr-Commit-Position: refs/heads/master@{#11773}
TBR=magjed@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1740963002
Cr-Commit-Position: refs/heads/master@{#11777}
void UpdateAspectRatio(int ratio_w, int ratio_h);
void ClearAspectRatio();
ool Pause(bool paused);
Restart(const VideoFormat& capture_format);
MuteToBlackThenPause(bool muted);
IsMuted() const
set_square_pixel_aspect_ratio
bool square_pixel_aspect_ratio()
This cl also remove the use of messages and posting of state change.
Further more - a thread checker is added to make sure methods are called on only one thread. Construction can happen on a separate thred.
It does not add restrictions on what thread frames are delivered on though.
There is more features in VideoCapturer::Onframe related to screen share in ARGB that probably can be cleaned up in a follow up cl.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1733673002
Cr-Commit-Position: refs/heads/master@{#11773}
