mollyim/webrtc
1
0
Fork 0
mirror of https://github.com/mollyim/webrtc.git synced 2025-05-17 15:47:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
29021 commits 2 branches 92 tags 416 MiB
Commit graph

5 commits

Author SHA1 Message Date
Mirko Bonadei
317a1f09ed Use std::make_unique instead of absl::make_unique. 
WebRTC is now using C++14 so there is no need to use the Abseil version
of std::make_unique.

This CL has been created with the following steps:

git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt
git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt
git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt

diff --new-line-format="" --unchanged-line-format="" \
  /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \
  uniq > /tmp/only_make_unique.txt
diff --new-line-format="" --unchanged-line-format="" \
  /tmp/only_make_unique.txt /tmp/memory.txt | \
  xargs grep -l "absl/memory" > /tmp/add-memory.txt

git grep -l "\babsl::make_unique\b" | \
  xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g"

git checkout PRESUBMIT.py abseil-in-webrtc.md

cat /tmp/add-memory.txt | \
  xargs sed -i \
  's/#include "absl\/memory\/memory.h"/#include <memory>/g'
git cl format
# Manual fix order of the new inserted #include <memory>

cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \
  xargs sed -i '/#include "absl\/memory\/memory.h"/d'

git ls-files | grep BUILD.gn | \
  xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d'

python tools_webrtc/gn_check_autofix.py \
  -m tryserver.webrtc -b linux_rel

# Repead the gn_check_autofix step for other platforms

git ls-files | grep BUILD.gn | \
  xargs sed -i 's/absl\/memory:memory/absl\/memory/g'
git cl format

Bug: webrtc:10945
Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29209}
 2019-09-17 15:47:29 +00:00
Bjorn A Mellem
c85ebbe766 Reland: Implement true negotiation for DatagramTransport with fallback to RTP. 
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport.  If the answerer supports datagram transport, it will
parse this line and create a datagram transport.  It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).

If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport.  If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.

Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto.  Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP.  This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.

Negotiation consists of four parts:
 1. DatagramTransport exposes transport parameters for both client and server
 perspectives.  The client just echoes what it received from the server (modulo
 any fields it might not have understood).

 2. SDP adds a x-opaque line for opaque transport parameters.  Identical to
 x-mt, but this is specific to datagram transport and goes in each m= section,
 and appears in the answer as well as the offer.
  - This is propagated to Jsep as part of the TransportDescription.
  - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
    media_session.cc, webrtc_sdp.cc

 3. JsepTransport/Controller:
  - Exposes opaque parameters for each mid (m= section).  On offerer, this means
    pre-allocating a datagram transport and getting its parameters.  On the
    answerer, this means echoing the offerer's parameters.
  - Uses a composite RTP transport to receive from either default RTP or
    datagram transport until both offer and answer arrive.
  - If a provisional answer arrives, sets the composite to send on the
    provisionally selected transport.
  - Once both offer and answer are set, deletes the unneeded transports and
    keeps whichever transport is selected.

 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.

Bug: webrtc:9719
Change-Id: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28198}
 2019-06-07 20:14:36 +00:00
Bjorn Mellem
7e8de0bf2d Revert "Implement true negotiation for DatagramTransport with fallback to RTP." 
This reverts commit 71c6482baf.

Reason for revert: Lands too much at once and breaks downstream tests that need to implement new interfaces first.

Original change's description:
> Implement true negotiation for DatagramTransport with fallback to RTP.
> 
> In short, the caller places a x-opaque line in SDP for each m= section that
> uses datagram transport.  If the answerer supports datagram transport, it will
> parse this line and create a datagram transport.  It will then echo the x-opaque
> line into the answer (to indicate that it accepted use of datagram transport).
> 
> If the offer and answer contain exactly the same x-opaque line, both peers will
> use datagram transport.  If the x-opaque line is omitted from the answer (or is
> different in the answer) they will fall back to RTP.
> 
> Note that a different x-opaque line in the answer means the answerer did not
> understand something in the negotiation proto.  Since WebRTC cannot know what
> was misunderstood, or whether it's still possible to use the datagram transport,
> it must fall back to RTP.  This may change in the future, possibly by passing
> the answer to the datagram transport, but it's good enough for now.
> 
> Negotiation consists of four parts:
>  1. DatagramTransport exposes transport parameters for both client and server
>  perspectives.  The client just echoes what it received from the server (modulo
>  any fields it might not have understood).
> 
>  2. SDP adds a x-opaque line for opaque transport parameters.  Identical to
>  x-mt, but this is specific to datagram transport and goes in each m= section,
>  and appears in the answer as well as the offer.
>   - This is propagated to Jsep as part of the TransportDescription.
>   - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
>     media_session.cc, webrtc_sdp.cc
> 
>  3. JsepTransport/Controller:
>   - Exposes opaque parameters for each mid (m= section).  On offerer, this means
>     pre-allocating a datagram transport and getting its parameters.  On the
>     answerer, this means echoing the offerer's parameters.
>   - Uses a composite RTP transport to receive from either default RTP or
>     datagram transport until both offer and answer arrive.
>   - If a provisional answer arrives, sets the composite to send on the
>     provisionally selected transport.
>   - Once both offer and answer are set, deletes the unneeded transports and
>     keeps whichever transport is selected.
> 
>  4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
> 
> Bug: webrtc:9719
> Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28182}

TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org

Change-Id: I0d502c4a6d27516c35ed85154f3fa5869f88b3b7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140822
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28188}
 2019-06-07 06:17:50 +00:00
Bjorn A Mellem
71c6482baf Implement true negotiation for DatagramTransport with fallback to RTP. 
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport.  If the answerer supports datagram transport, it will
parse this line and create a datagram transport.  It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).

If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport.  If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.

Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto.  Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP.  This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.

Negotiation consists of four parts:
 1. DatagramTransport exposes transport parameters for both client and server
 perspectives.  The client just echoes what it received from the server (modulo
 any fields it might not have understood).

 2. SDP adds a x-opaque line for opaque transport parameters.  Identical to
 x-mt, but this is specific to datagram transport and goes in each m= section,
 and appears in the answer as well as the offer.
  - This is propagated to Jsep as part of the TransportDescription.
  - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
    media_session.cc, webrtc_sdp.cc

 3. JsepTransport/Controller:
  - Exposes opaque parameters for each mid (m= section).  On offerer, this means
    pre-allocating a datagram transport and getting its parameters.  On the
    answerer, this means echoing the offerer's parameters.
  - Uses a composite RTP transport to receive from either default RTP or
    datagram transport until both offer and answer arrive.
  - If a provisional answer arrives, sets the composite to send on the
    provisionally selected transport.
  - Once both offer and answer are set, deletes the unneeded transports and
    keeps whichever transport is selected.

 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.

Bug: webrtc:9719
Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28182}
 2019-06-07 01:09:04 +00:00
Bjorn A Mellem
44bd71cc44 Create a composite implementation of RtpTransportInternal. 
This will be used to multiplex multiple transports during SDP
negotiation.  When the offerer watns to support multiple RTP transports,
it will combine them into a singla CompositeRtpTransport.

CompositeRtpTransport can receive from any of the offered transports
while waiting for an answer to arrive.

The choice of which transport is used to send must be driven by the SDP
answer.  If a provisional answer arrives, the composite can be set to
send using the chosen transport, while maintaining other transports in
case the peer changes its mind.  When the final answer arrives, the
composite will be deleted and replaced with the chosen transport.

Bug: webrtc:9719
Change-Id: Ib8cea77ef202f37086723bfa2c71e2aa5995a912
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/138281
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28093}
 2019-05-28 23:18:49 +00:00