Reason for revert:
Speculative revert.
Linux memcheck bot started failing a lot at the time of this cl. Doesn't look related at first glance, but we don't have another lead yet.
Original issue's description:
> Fix BitrateProber to match the requested bitrate more precisely
>
> Previously BirateProber was calculating delay between probes based on
> the size of the previous probe. Because of that the actual sent bitrate
> can deviate greatly from the target value. With this change it uses
> total number of bytes in the cluster to estimate delay before each
> probe.
>
> BUG=webrtc:6952
>
> Review-Url: https://codereview.webrtc.org/2613543003
> Cr-Commit-Position: refs/heads/master@{#15971}
> Committed: 599c5011e7TBR=philipel@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6952
Review-Url: https://codereview.webrtc.org/2626473004
Cr-Commit-Position: refs/heads/master@{#15979}
Because Voice Engine was the only user.
(We have tried to land this many times before. I'm hoping that this
time all external dependencies on these files will really be gone.)
BUG=none
Review-Url: https://codereview.webrtc.org/2622493002
Cr-Commit-Position: refs/heads/master@{#15978}
The intention of SetConfiguration is that it modifies the configuration,
while keeping the constraints passed into CreatePeerConnection. Right
now that's now happening. See bug for more explanation.
BUG=webrtc:6942
Review-Url: https://codereview.webrtc.org/2603653002
Cr-Commit-Position: refs/heads/master@{#15974}
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}
Previously BirateProber was calculating delay between probes based on
the size of the previous probe. Because of that the actual sent bitrate
can deviate greatly from the target value. With this change it uses
total number of bytes in the cluster to estimate delay before each
probe.
BUG=webrtc:6952
Review-Url: https://codereview.webrtc.org/2613543003
Cr-Commit-Position: refs/heads/master@{#15971}
webrtcvideoengine2.cc uses a field for parameters_, and doesn't empty
out the current state in functions like SetCodec. In the case of
internal_source, SetCodec only set it for external encoders, which
means that in a switch from an internal-source external encoder to an
internal encoder, the internal_source bit would stay set.
(It's plausible that there are other places that are also unsafe and we
just don't notice because codec switches are uncommon in most usage)
In combination with https://codereview.webrtc.org/2574183002/,
generic_encoder.cc now creates 1x1 uninitialized frames as fake frames
for internal_source keyframe requests. The vp8 software encoder doesn't
deal correctly with frames of resolutions that don't match the
configured resolution (besides a DCHECK) and no longer throws these
away (they used to be 0x0 frames), so this results in the VP8
encoder creating a keyframe of the configured send codec size by reading
random memory off the end of the fake I420 frame. This could either
cause crashes or encoding junk data, depending on where the allocation
was.
BUG=webrtc:6957
Review-Url: https://codereview.webrtc.org/2617003003
Cr-Commit-Position: refs/heads/master@{#15969}
Refactor "OPT_SSLTCP" renaming it to "OPT_TLS_FAKE", making it clear
that it's not actually some kind of SSL over TCP. Also making it clear
that it's mutually exclusive with OPT_TLS. Maintaining deprecated
backwards compatible support for "OPT_SSLTCP".
Add "OPT_TLS_INSECURE" that implements the new certificate-check
disabled TLS mode, which is also mutually exclusive with the other
TLS options.
PortAllocator: Add a new TLS policy enum TlsCertPolicy which defines
the new insecure mode and added it as a RelayCredentials member.
TurnPort: Add new TLS policy member with appropriate getter and setter
to avoid constructor bloat. Initialize it from the RelayCredentials
after the TurnPort is created.
Expose the new feature in the PeerConnection API via
IceServer.tls_certificate_policy as well as via the Android JNI
PeerConnection API.
For security reasons we ensure that:
1) The policy is always explicitly initialized to secure.
2) API users have to explicitly integrate with the feature to
use it, and will otherwise get no change in behavior.
3) The feature is not immediately exposed in non-native
contexts. For example, disabling of certificate validation
is not implemented via URI parsing since this would
immediately allow it to be used from a web page.
This is a second attempt of https://codereview.webrtc.org/2557803002/
which was rolled back in https://codereview.webrtc.org/2590153002/
BUG=webrtc:6840
Review-Url: https://codereview.webrtc.org/2594623002
Cr-Commit-Position: refs/heads/master@{#15967}
Left shifting negative integers is undefined behavior, and should be prevented. This CL fixes one such instance in the NetEq Expand function.
BUG=chromium:677106
Review-Url: https://codereview.webrtc.org/2616363003
Cr-Commit-Position: refs/heads/master@{#15966}
When apply_rotation() returns true, rotation and captured width/heigh are not set correctly.
BUG=webrtc:6925
Review-Url: https://codereview.webrtc.org/2611113003
Cr-Commit-Position: refs/heads/master@{#15963}
Removing the DCHECK due to (sometimes) failing voe_auto_test.
Long-term, this DCHECK should be readded. Before that can happen,
the SSRC in the RTPSender should be made immutable.
TESTED=No failures when running third_party/gtest-parallel/gtest-parallel --repeat=5000 --gtest_filter="VolumeTest.ManualInputMutingMutesMicrophone" out/Debug/voe_auto_test.
BUG=webrtc:6887
Review-Url: https://codereview.webrtc.org/2610873002
Cr-Commit-Position: refs/heads/master@{#15962}
Also, move owner file from webrtc/sdk to webrtc/sdk/objc since we now
also have webrtc/sdk/android directory.
BUG=None
TBR=tkchin
NOTRY=True
Review-Url: https://codereview.webrtc.org/2589233002
Cr-Commit-Position: refs/heads/master@{#15961}
Reason for revert:
Skipping the build of the target "//webrtc/modules/audio_device:audio_device_java" when building webrtc with chromium.
This was causing a failure because in that case it is not possible to refer to the script used by the template "android_shared_srcjar" with an absolute path (which seems to be necessary since the script attribute of action is relative to the invocation target and not to the template declaration).
Original issue's description:
> Revert of Fixing package-boundary violation with srjar_deps (patchset #5 id:80001 of https://codereview.webrtc.org/2610823002/ )
>
> Reason for revert:
> This CL is breaking a chromium.webrtc.fyi: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder/builds/226
>
> I am trying to reproduce the issue on my local machine and I will try to re-land the CL later.
>
> Original issue's description:
> > Fixing package-boundary violation with srjar_deps
> >
> > Without the usage of the srcjar_deps attribute we were not able to
> > include .java files from other packages without violating the package
> > boundary contraint.
> >
> > As an example, in this CL the target "libjingle_peerconnection_java" was
> > directly including .java files from another packages in its "java_files"
> > attribute.
> >
> > Using srcjar_deps we are able to declare the dependency of the target
> > avoiding to create hidden dependencies in the codebase.
> >
> > This is not fixing the webrtc:6356 bug directly but it is a first step to
> > include ThreadUtils classes in libjingle_peerconnection_client_java.jar
> > again.
> >
> > It seems also to be related to the chromium:648244 bug. This can be solved
> > if we can find a way to perform srcjar generation in the android_library
> > target without changing the semantic of the target.
> >
> > BUG=webrtc:6356
> >
> > Review-Url: https://codereview.webrtc.org/2610823002
> > Cr-Commit-Position: refs/heads/master@{#15914}
> > Committed: 10a76592a7
>
> TBR=kjellander@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6356
>
> Review-Url: https://codereview.webrtc.org/2617533005
> Cr-Commit-Position: refs/heads/master@{#15915}
> Committed: eb731ed09eTBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2612953004
Cr-Commit-Position: refs/heads/master@{#15958}
Last references to the old code were fixed in Chromium with
https://codereview.chromium.org/2616873002/ and
https://codereview.chromium.org/2617363002/
Original issue's description:
> Revert of Remove webrtc/libjingle/{xmllite,xmpp} (patchset #1 id:1 of https://codereview.webrtc.org/2617443003/ )
>
> Reason for revert:
> Breaks Chromium FYI bots.
>
> tommi, please let me land this (I forgot to run them).
>
> Original issue's description:
> > Remove webrtc/libjingle/{xmllite,xmpp} as it's dead code.
> >
> > These sources have now been imported into Chromium's
> > src/third_party/libjingle_xmpp.
> >
> > BUG=webrtc:5539
> > NOTRY=True
> >
> > Review-Url: https://codereview.webrtc.org/2617443003
> > Cr-Commit-Position: refs/heads/master@{#15910}
> > Committed: 1670b1fe6b
>
> TBR=tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5539
>
> Review-Url: https://codereview.webrtc.org/2618633003
> Cr-Commit-Position: refs/heads/master@{#15911}
> Committed: 60ef117be4TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5539
Review-Url: https://codereview.webrtc.org/2618693002
Cr-Commit-Position: refs/heads/master@{#15954}
With this, RtpSender and RtpReceiver will always return an SSRC if one
is available. Also, attempts to change the SSRC with SetParameters will
fail, rather than silently doing nothing.
BUG=webrtc:6888
Review-Url: https://codereview.webrtc.org/2567333004
Cr-Commit-Position: refs/heads/master@{#15939}
The src/remoting/protocol/channel_socket_adapter_unittest.cc will use this class
instead of creating its own MockTransportChannel which subclasses the TransportChannel.
This will make it easier to switch the base class of P2PTransportChannel from
TransportChannel to IceTransportInternal.
BUG=webrtc:6951
Review-Url: https://codereview.webrtc.org/2610663003
Cr-Commit-Position: refs/heads/master@{#15922}
Reason for revert:
This CL is breaking a chromium.webrtc.fyi: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder/builds/226
I am trying to reproduce the issue on my local machine and I will try to re-land the CL later.
Original issue's description:
> Fixing package-boundary violation with srjar_deps
>
> Without the usage of the srcjar_deps attribute we were not able to
> include .java files from other packages without violating the package
> boundary contraint.
>
> As an example, in this CL the target "libjingle_peerconnection_java" was
> directly including .java files from another packages in its "java_files"
> attribute.
>
> Using srcjar_deps we are able to declare the dependency of the target
> avoiding to create hidden dependencies in the codebase.
>
> This is not fixing the webrtc:6356 bug directly but it is a first step to
> include ThreadUtils classes in libjingle_peerconnection_client_java.jar
> again.
>
> It seems also to be related to the chromium:648244 bug. This can be solved
> if we can find a way to perform srcjar generation in the android_library
> target without changing the semantic of the target.
>
> BUG=webrtc:6356
>
> Review-Url: https://codereview.webrtc.org/2610823002
> Cr-Commit-Position: refs/heads/master@{#15914}
> Committed: 10a76592a7TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2617533005
Cr-Commit-Position: refs/heads/master@{#15915}
Without the usage of the srcjar_deps attribute we were not able to
include .java files from other packages without violating the package
boundary contraint.
As an example, in this CL the target "libjingle_peerconnection_java" was
directly including .java files from another packages in its "java_files"
attribute.
Using srcjar_deps we are able to declare the dependency of the target
avoiding to create hidden dependencies in the codebase.
This is not fixing the webrtc:6356 bug directly but it is a first step to
include ThreadUtils classes in libjingle_peerconnection_client_java.jar
again.
It seems also to be related to the chromium:648244 bug. This can be solved
if we can find a way to perform srcjar generation in the android_library
target without changing the semantic of the target.
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2610823002
Cr-Commit-Position: refs/heads/master@{#15914}
Reason for revert:
Breaks Chromium FYI bots.
tommi, please let me land this (I forgot to run them).
Original issue's description:
> Remove webrtc/libjingle/{xmllite,xmpp} as it's dead code.
>
> These sources have now been imported into Chromium's
> src/third_party/libjingle_xmpp.
>
> BUG=webrtc:5539
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2617443003
> Cr-Commit-Position: refs/heads/master@{#15910}
> Committed: 1670b1fe6bTBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5539
Review-Url: https://codereview.webrtc.org/2618633003
Cr-Commit-Position: refs/heads/master@{#15911}
These sources have now been imported into Chromium's
src/third_party/libjingle_xmpp.
BUG=webrtc:5539
NOTRY=True
Review-Url: https://codereview.webrtc.org/2617443003
Cr-Commit-Position: refs/heads/master@{#15910}
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}
Instead of having to specify a bitrate and how many packets to use,
the BitrateProber will now use the bitrate to calculate how many
bytes it will use to probe that bitrate instead.
For now, |kMinProbeDurationMs| is set to 15 ms which means that probing
at 1900 kbps will result in 1900/8*0.015 = 3.5 kB used. Since we can
expect packets to be smaller at the beginning of a stream (500 to 700
bytes) this will result in 7 to 5 packets sent for that bitrate, and
should work very similar to how the current initial probing works.
A minimum of 5 packets are always sent.
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2609113003
Cr-Commit-Position: refs/heads/master@{#15899}
This will make it easier for some downstream projects to control whether
or not to set ENABLE_EXTERNAL_AUTH, via the GN variable.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2608673002
Cr-Commit-Position: refs/heads/master@{#15894}
This use of a=bundle-only is unspecified, but not disallowed, so it
should simply result in the attribute being ignored, not a parse
failure.
Note that older versions of Firefox may generate SDP with a=bundle-only
and a nonzero port, so this also fixes an interop issue. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1325991
BUG=webrtc:4674
Review-Url: https://codereview.webrtc.org/2609863003
Cr-Commit-Position: refs/heads/master@{#15890}
DtlsTransportInternal is an internal interface that does DTLS.
The DtlsTransportChannel will inherit from this class instead of the
TransportChannelImpl so that the ICE-related methods can be separated.
Once the DtlsTransportChannl inherits from this class. It would be
renamed as DtlsTransport.
BUG=none
Review-Url: https://codereview.webrtc.org/2597053002
Cr-Commit-Position: refs/heads/master@{#15888}
Reason for reland:
Added disabling of the BlockProcessor DEATH tests due to false alarms on the trybots.
These errors cannot be reproduced locally and they occur only in the DEATH test code,
which means that the memory leaks do not occur under normal conditions.
Original issue's description:
> Reason for revert:
> Memcheck buildbot detected memory leaks in the death tests. The code looks fine
> to me, but please investigate what causes the error and reland.
> > Original issue's description:
> > Added first layer of the echo canceller 3 functionality.
> >
> > This CL adds the first layer of the echo canceller 3.
> > All of the code is as it should, apart from
> > block_processor.* which only contains placeholder
> > functionality. (Upcoming CLs will add proper
> > functionality into those files.)
> >
> >
> >
> > BUG=webrtc:6018
> >
> > Review-Url: https://codereview.webrtc.org/2584493002
> > Cr-Commit-Position: refs/heads/master@{#15861}
> > Committed:
> 38fd1758e9
>
> TBR=ivoc@webrtc.org,aleloi@webrtc.org,henrik.lundin@webrtc.org,peah@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6018
BUG=webrtc:6018
TBR=ivoc@webrtc.org,aleloi@webrtc.org,henrik.lundin@webrtc.org
Review-Url: https://codereview.webrtc.org/2608233002
Cr-Commit-Position: refs/heads/master@{#15884}
- add some unit tests
- change SampleCounter members from int to int64_t
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/2577073002
Cr-Commit-Position: refs/heads/master@{#15882}
Reason for revert:
Memcheck buildbot detected memory leaks in the death tests. The code looks fine to me, but please investigate what causes the error and reland.
Original issue's description:
> Added first layer of the echo canceller 3 functionality.
>
> This CL adds the first layer of the echo canceller 3.
> All of the code is as it should, apart from
> block_processor.* which only contains placeholder
> functionality. (Upcoming CLs will add proper
> functionality into those files.)
>
>
>
> BUG=webrtc:6018
>
> Review-Url: https://codereview.webrtc.org/2584493002
> Cr-Commit-Position: refs/heads/master@{#15861}
> Committed: 38fd1758e9TBR=ivoc@webrtc.org,aleloi@webrtc.org,henrik.lundin@webrtc.org,peah@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6018
Review-Url: https://codereview.webrtc.org/2603293002
Cr-Commit-Position: refs/heads/master@{#15877}
Reason for revert:
Doing a reland where systeminfo.cc includes basictypes.h so that CPU_X86 etc. are defined when they are checked/used.
Original issue's description:
> Revert of Replace basictypes.h with stdint.h for int_t types. (patchset #1 id:1 of https://codereview.webrtc.org/2604043002/ )
>
> Reason for revert:
> Very likely cause of Chromium import bot breakage (unused function '__cpuid'), TBD why.
>
> Original issue's description:
> > Replace basictypes.h with stdint.h for int_t types.
> >
> > Removes basictypes.h for types that only makes use of it for fixed-size-int
> > typedefs and replaces it with stdint.h.
> >
> > BUG=webrtc:6853
> > R=tommi@webrtc.org
> >
> > Review-Url: https://codereview.webrtc.org/2604043002
> > Cr-Commit-Position: refs/heads/master@{#15867}
> > Committed: 7fd1a75300
>
> TBR=tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6853
>
> Review-Url: https://codereview.webrtc.org/2603203003
> Cr-Commit-Position: refs/heads/master@{#15869}
> Committed: 7eb0e23bcf
BUG=webrtc:6853
TBR=tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2609783002
Cr-Commit-Position: refs/heads/master@{#15873}
