There is a dependency chain from Chromium windows main_dll to Opus
which should never exist. We used to rely on rtc_static_library
to break this chain. So this CL replaced some rtc_source_set
with rtc_static_library.
libvpx fix (https://chromium-review.googlesource.com/c/544107/) for
ios-simulator linking issue is landed and this CL can be sumbitted once the new
Chromium is rolled into WebRTC.
BUG=chromium:734631
Review-Url: https://codereview.webrtc.org/2947273002
Cr-Commit-Position: refs/heads/master@{#18709}
Reason for revert:
Relanding the orginal CL. The breakage would be a flakey build.
Original issue's description:
> Revert of Try to fix the binary size increase issue on Chromium. (patchset #1 id:1 of https://codereview.webrtc.org/2945233002/ )
>
> Reason for revert:
> The Android 32 (more config) bot is broken.
>
> Original issue's description:
> > Try to fix the binary size increase issue on Chromium.
> >
> > The target common_video used to depend on rtc_media_base which introduces
> > the dependency on p2p. This probably causes the binary size increase on Win
> > Chromium. Some chromium targets like src/media/gpu:gpu depends on common_video directly.
> >
> > BUG=chromium:734631
> >
> > Review-Url: https://codereview.webrtc.org/2945233002
> > Cr-Commit-Position: refs/heads/master@{#18693}
> > Committed: 9ed1609737
>
> TBR=kjellander@webrtc.org,deadbeef@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:734631
>
> Review-Url: https://codereview.webrtc.org/2949953003
> Cr-Commit-Position: refs/heads/master@{#18694}
> Committed: c2e208a924TBR=kjellander@webrtc.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:734631
Review-Url: https://codereview.webrtc.org/2949883003
Cr-Commit-Position: refs/heads/master@{#18695}
Reason for revert:
The Android 32 (more config) bot is broken.
Original issue's description:
> Try to fix the binary size increase issue on Chromium.
>
> The target common_video used to depend on rtc_media_base which introduces
> the dependency on p2p. This probably causes the binary size increase on Win
> Chromium. Some chromium targets like src/media/gpu:gpu depends on common_video directly.
>
> BUG=chromium:734631
>
> Review-Url: https://codereview.webrtc.org/2945233002
> Cr-Commit-Position: refs/heads/master@{#18693}
> Committed: 9ed1609737TBR=kjellander@webrtc.org,deadbeef@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:734631
Review-Url: https://codereview.webrtc.org/2949953003
Cr-Commit-Position: refs/heads/master@{#18694}
The target common_video used to depend on rtc_media_base which introduces
the dependency on p2p. This probably causes the binary size increase on Win
Chromium. Some chromium targets like src/media/gpu:gpu depends on common_video directly.
BUG=chromium:734631
Review-Url: https://codereview.webrtc.org/2945233002
Cr-Commit-Position: refs/heads/master@{#18693}
In this case it wasn't an issue, because only one result would be found
by remove_if, but might as well fix it just in case.
BUG=None
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2945723002
Cr-Commit-Position: refs/heads/master@{#18641}
This CL makes the WebRTC more modular and allows the users to build
WebRTC without audio and video(DataChannel only).
The BUILD files in call/, logging/, media/ and pc/ are modified to
support modular WebRTC.
The dependencies on Call and RtcEventLog are removed from the
PeerConnection. Instead of being created internally, they would be
passed in by the PeerConnectionFactory.
Add the CreateModularPeerConnectionFactory function which allow the
users to create a PeerConnectionFactory with the modules they need.
If the users want to build WebRTC without audio and video, they can
pass in null pointers for modules they don't need. (MediaEngine,
VideoEncoderFactory etc.)
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2854123003
Cr-Commit-Position: refs/heads/master@{#18617}
This eliminates a thread hop in PeerConnectionFactory initialization,
and will allow some code to be simplified.
BUG=None
Review-Url: https://codereview.webrtc.org/2934103002
Cr-Commit-Position: refs/heads/master@{#18613}
PeerConnection::SetBitrate calls PeerConnectionFactory::worker_thread
from multiple threads, so it was triggering the DCHECK. However, the
worker thread never changes after construction, so worker_thread should
be safe to call from multiple threads.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2923953004
Cr-Commit-Position: refs/heads/master@{#18576}
WebRtcVideoChannel and and WebRtcVideoEngine seem to have been removed, and only WebRtcVideoChannel2 and WebRtcVideoEngine2 remain, which removes the need for the "2" postfix.
BUG=None
Review-Url: https://codereview.webrtc.org/2932073002
Cr-Commit-Position: refs/heads/master@{#18531}
Reason for revert:
Broken downstream project.
Original issue's description:
> Adds PeerConnectionInterface::UpdateCallBitrate to give clients more control of the bandwidth estimator. PeerConnection implements this method by passing a BitrateConfigMask to its associated Call, which is combined with the existing BitrateConfig and passed on to the SendSideCongestionController as necessary. The existing BitrateConfig generally comes from the x-google-{min,start,max}-bitrate params in the SDP.
>
> BUG=webrtc:7395
>
> Review-Url: https://codereview.webrtc.org/2888303005
> Cr-Commit-Position: refs/heads/master@{#18417}
> Committed: 9641c13327TBR=deadbeef@webrtc.org,stefan@webrtc.org,kwiberg@webrtc.org,solenberg@webrtc.org,holmer@google.com,zstein@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7395
Review-Url: https://codereview.webrtc.org/2914413002
Cr-Commit-Position: refs/heads/master@{#18420}
Reason for revert:
Broken downstream projects
Original issue's description:
> Wire up BWE stats through WebrtcSession so that they are filled in both for audio and video calls.
>
> Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
>
> BUG=webrtc:5079
> R=deadbeef@webrtc.org, hbos@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2863123002 .
> Cr-Commit-Position: refs/heads/master@{#18384}
> Committed: e80f4c91d0TBR=hbos@webrtc.org,deadbeef@webrtc.org,holmer@google.com,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2916793003
Cr-Commit-Position: refs/heads/master@{#18386}
Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
BUG=webrtc:5079
R=deadbeef@webrtc.org, hbos@webrtc.org
Review-Url: https://codereview.webrtc.org/2863123002 .
Cr-Commit-Position: refs/heads/master@{#18384}
The change is now compatible with the old JVM::Initialize API. The
context is passed to the ContextUtils class when calling its deprecated
signature.
BUG=webrtc:7665
NOTRY=True # Only comment changes since the last patchset.
Review-Url: https://codereview.webrtc.org/2903253004
Cr-Commit-Position: refs/heads/master@{#18268}
This CL doesn't yet offer these protos; it just accepts them if they're
seen in a remote offer. It also doesn't verify that the ICE candidate
protocol matches the m= section protocol (UDP vs. TCP), since we don't
do this elsewhere and don't really have a reason to care.
This CL also adds an integration test that receives a spec-compliant
SCTP offer and attempts to send data bidirectionally.
BUG=webrtc:7706
Review-Url: https://codereview.webrtc.org/2902213002
Cr-Commit-Position: refs/heads/master@{#18265}
The media related stats wasn't working for unsignaled stream because there
is no mapping between the receiver_info and unsignaled tracks.
This CL fixes the issue by adding some special logic to the TrackMediaInfoMap
which would create the mapping.
BUG=b/37836881
BUG=webrtc:7685
TBR=deadbeef@webrtc.org
Review-Url: https://codereview.webrtc.org/2883943003
Cr-Commit-Position: refs/heads/master@{#18217}
Add the include to the files where it is actually used instead.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2869863003
Cr-Commit-Position: refs/heads/master@{#18176}
The only thing the physical socket server was used for was
"Wait"/"WakeUp", but it could be replaced by a simple rtc::Event.
So, removing this dependency makes things less confusing; the fact that
VirtualSocketServer takes a PhysicalSocketServer may lead someone to
think it uses real sockets internally, when it doesn't.
BUG=None
Review-Url: https://codereview.webrtc.org/2883313003
Cr-Commit-Position: refs/heads/master@{#18172}
For every failing test, the solution was either to do a "has IPv4" check
before the test is run, or avoid depending on real network interfaces
altogether.
This specifically fixes rtc_unittests, peerconnection_unittests, and
webrtc_nonparallel_tests.
BUG=None
Review-Url: https://codereview.webrtc.org/2881973002
Cr-Commit-Position: refs/heads/master@{#18155}
Instead, make the pointer to the associated socket server a
construction time const, and delete its lock.
Introduces a helper class AutoSocketServerThread for code
(mainly tests) which need a socket server associated with
the current thread.
BUG=webrtc:7501
Review-Url: https://codereview.webrtc.org/2828223002
Cr-Commit-Position: refs/heads/master@{#18047}
The test attempted to call InsertDtmf before verifying that the DTLS
handshake was complete. Unlike a data channel, the DTMF sender doesn't
do any buffering, so this isn't reliable.
BUG=webrtc:7547
NOTRY=True
Review-Url: https://codereview.webrtc.org/2855573004
Cr-Commit-Position: refs/heads/master@{#18041}
The test contained an invalid IPv6 address. It should have ":" instead of "::" as separation.
BUG=webrtc:7565
Review-Url: https://codereview.webrtc.org/2868453002
Cr-Commit-Position: refs/heads/master@{#18035}
Plumbed AudioEncoderFactory up into CreatePeerConnectionFactory.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2799033006
Cr-Commit-Position: refs/heads/master@{#17977}
Specifically, the tests that only use data channels shouldn't need any
audio codec support; by using an audio decoder factory that supports
no codecs, we ensure that this is the case.
For completeness, I tried doing the same to the two tests that
actually use audio and video; as expected, they fail, with messages
like this:
[000:032] (webrtcsession.cc:334): Failed to set remote sdp: Session
error code: ERROR_CONTENT. Session error description: Failed to set
local audio description recv parameters..
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2848563002
Cr-Commit-Position: refs/heads/master@{#17907}
I disabled the check on "video_tests" because it pulls
"//webrtc/media/rtc_unittest_main" as a dependency and it defines
the _main (that is already defined by "//webrtc/test:test_main").
I will file a bug to solve this in another CL.
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2832063003
Cr-Commit-Position: refs/heads/master@{#17859}
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
The test isn't complete, since "track_id" ends up unset. But it's
better than having no test at all.
BUG=None
Review-Url: https://codereview.webrtc.org/2827643003
Cr-Commit-Position: refs/heads/master@{#17753}
The example that brought up this issue was:
1. Do offer/answer exchange.
2. Later, remove the audio/video stream.
3. Add back a new stream, that contains only the audio track.
4. Do new offer/answer.
The new offer didn't have the new stream ID, but code elsewhere was
expecting one. As a result, the send stream is never hooked up to the
audio track, and audio packets aren't sent.
BUG=chromium:611708
Review-Url: https://codereview.webrtc.org/2810733003
Cr-Commit-Position: refs/heads/master@{#17709}
The "initialize audio/video" parameters are no longer needed, but
at the same time were required to be true, causing a lot of confusion.
This CL removes them, but leaves the old method signature around,
marked "deprecated".
BUG=webrtc:3416
TBR=solenberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2800353002
Cr-Commit-Position: refs/heads/master@{#17626}
