VoEBase is plumbed to optionally take an AudioDecoderFactory, or create
a builtin factory if none is provided.
Retained the CreateChannel interfaces in Channel and ChannelManager
and added variants for injecting an AudioDecoderFactory. The
"old-style" variants call CreateBuiltinAudioDecoderFactory to get a
factory to use.
(Just realized this means each channel uses a separate factory with the
old-style calls. Probably ok.)
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1993783002
Cr-Commit-Position: refs/heads/master@{#12961}
This is a reland of https://codereview.webrtc.org/1847013002/
with the following changes:
* _USE_32BIT_TIME_T is no longer set: it was removed from Chromium
in https://codereview.chromium.org/1862443003/.
Setting it in target_defaults was likely the reason to
remoting_unittests failing in the previous attempt to land this.
* Added define for FreeBSD platform.
* Added corresponding GN changes.
Copy the defines from the target_defaults section of Chromium's
src/third_party/libjingle.gyp into our webrtc/build/common.gypi
in order to ensure the same defines are used for the Chromium build
when removing the source listings in src/third_party/libjingle.gyp.
With this CL landed, it should be possible to replace them with
dependencies on:
* webrtc/api/api.gyp:libjingle_peerconnections
* webrtc/media/media.gyp:rtc_media
* webrtc/pc/pc.gyp:rtc_pc
* webrtc/pp2/p2p.gyp:rtc_p2p
* webrtc/libjingle/xmpp/xmpp.gyp:rtc_xmpp
Not ported (Windows specific):
* Precompiled headers (build/win_precompile.gypi):
since it only seems to offer a compile speedup. Will be landed
for all of WebRTC in separate CL.
BUG=webrtc:4256
NOTRY=True
Review-Url: https://codereview.webrtc.org/1924663003
Cr-Commit-Position: refs/heads/master@{#12959}
This will hopefully resolve a crash that might occur if it thinks H264 is
supported when in fact it isn't.
BUG=chromium:615513
Review-Url: https://codereview.webrtc.org/2018273002
Cr-Commit-Position: refs/heads/master@{#12958}
Reason for revert:
Updated signature to work with other JNI versions. We would need to compile it differently in order to catch failures like this in WebRTC in the future.
Original issue's description:
> Revert of Android: Add FramerateRange class (patchset #2 id:60001 of https://codereview.webrtc.org/2010763003/ )
>
> Reason for revert:
> Breaks downstream Android tests:
> java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
>
> We should have a similar test in WebRTC so we can catch such errors pre-commit.
>
> Original issue's description:
> > Android: Add FramerateRange class
> >
> > The Camera1 and Camera2 API use different framerate range types. Camera1
> > uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> > unfortunately only available on Lollipop and later, so this CL adds a
> > similar FramerateRange class in CaptureFormat.
> >
> > The purpose with this CL is to have a common framerate range type that can
> > be reused from both Camera1 and Camera2 in helper functions such as
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange().
> >
> > BUG=webrtc:5519
> > R=sakal@webrtc.org
> >
> > Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> > Cr-Commit-Position: refs/heads/master@{#12942}
>
> TBR=sakal@webrtc.org,magjed@webrtc.org
> NOTRY=True
> BUG=webrtc:5519
>
> Committed: https://crrev.com/bd5621f065fd25e0a77307f10dc9ddaf76e7945f
> Cr-Commit-Position: refs/heads/master@{#12956}
TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2019333002
Cr-Commit-Position: refs/heads/master@{#12957}
Reason for revert:
Breaks downstream Android tests:
java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
We should have a similar test in WebRTC so we can catch such errors pre-commit.
Original issue's description:
> Android: Add FramerateRange class
>
> The Camera1 and Camera2 API use different framerate range types. Camera1
> uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> unfortunately only available on Lollipop and later, so this CL adds a
> similar FramerateRange class in CaptureFormat.
>
> The purpose with this CL is to have a common framerate range type that can
> be reused from both Camera1 and Camera2 in helper functions such as
> CameraEnumerationAndroid.getClosestSupportedFramerateRange().
>
> BUG=webrtc:5519
> R=sakal@webrtc.org
>
> Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> Cr-Commit-Position: refs/heads/master@{#12942}
TBR=sakal@webrtc.org,magjed@webrtc.org
NOTRY=True
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024573002
Cr-Commit-Position: refs/heads/master@{#12956}
Reason for revert:
Reland. It was a false alarm.
Original issue's description:
> Revert of Change ProcessThread's task type to be the one from TaskQueue. (patchset #3 id:80001 of https://codereview.webrtc.org/2016043003/ )
>
> Reason for revert:
> Downstream issues
>
> Original issue's description:
> > Change ProcessThread's task type to be the one from TaskQueue.
> > ProcessThread will eventually be replaced by TaskQueue, so this is the first little step.
> >
> > BUG=
> > R=magjed@webrtc.org
> >
> > Committed: https://crrev.com/400a276c8a0b299190ff17a81edd8780a26d63d3
> > Cr-Commit-Position: refs/heads/master@{#12952}
>
> TBR=magjed@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=
>
> Committed: https://crrev.com/641455176a1241dea6dda7071ba4162f41a0b5fc
> Cr-Commit-Position: refs/heads/master@{#12953}
TBR=magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2017333002
Cr-Commit-Position: refs/heads/master@{#12954}
Reason for revert:
Downstream issues
Original issue's description:
> Change ProcessThread's task type to be the one from TaskQueue.
> ProcessThread will eventually be replaced by TaskQueue, so this is the first little step.
>
> BUG=
> R=magjed@webrtc.org
>
> Committed: https://crrev.com/400a276c8a0b299190ff17a81edd8780a26d63d3
> Cr-Commit-Position: refs/heads/master@{#12952}
TBR=magjed@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.webrtc.org/2020783003
Cr-Commit-Position: refs/heads/master@{#12953}
When this test was updated to use separate worker/signaling threads,
the virtual socket server wasn't moved over to the worker thread. So it
was set on the signaling thread and wasn't being used.
Review-Url: https://codereview.webrtc.org/2015763002
Cr-Commit-Position: refs/heads/master@{#12951}
This will be useful for any tests that test objects with time-dependent
behavior. It will allow such tests to be written in such a way that their
outcome is more repeatable (less flaky), and will also allow such tests
to finish quicker. For example, a test for STUN timeout doesn't need to
wait the full timeout interval in real time; it can simply advance the
simulated clock.
BUG=webrtc:4925
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1895933003 .
Cr-Commit-Position: refs/heads/master@{#12950}
I think the code that only allowed one role conflict was a workaround
for our old implementation (TransportChannelProxy, etc.). Not necessary
now, with TransportController.
BUG=webrtc:5470
Review-Url: https://codereview.webrtc.org/2004463003
Cr-Commit-Position: refs/heads/master@{#12949}
Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken Chromium FYI bots.
Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
>
> The store was used in WebRtcSessionDescriptionFactory to generate certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
>
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
> The generator is fully parameterized and does not generate RSA-1024 unless you
> ask for it (which makes sense not to do beforehand since ECDSA is now default).
> The store was not fully parameterized (known filed bug).
>
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
> Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
>
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
>
> Committed: 400781a209TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2020633002
Cr-Commit-Position: refs/heads/master@{#12948}
The store was used in WebRtcSessionDescriptionFactory to generate certificates,
now a generator is used instead (new API). PeerConnection[Factory][Interface],
and WebRtcSession are updated to pass generators all the way down to the
WebRtcSessionDescriptionFactory instead of stores.
The webrtc implementation of a generator, RTCCertificateGenerator, is used as
the default generator (peerconnectionfactory.cc:189) instead of the webrtc
implementation of a store, DtlsIdentityStoreImpl.
The generator is fully parameterized and does not generate RSA-1024 unless you
ask for it (which makes sense not to do beforehand since ECDSA is now default).
The store was not fully parameterized (known filed bug).
The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
updated to take a generator instead of a store. But as to not break Chromium,
the old function signature taking a store is kept. It is implemented to invoke
the generator version by wrapping the store in an
RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
new function signature we can remove the old CreatePeerConnection.
Due to having multiple CreatePeerConnection signatures, some calling places
are updated to resolve the ambiguity introduced.
BUG=webrtc:5707, webrtc:5708
R=phoglund@webrtc.org, tommi@webrtc.orgTBR=tkchin@webrc.org
Review URL: https://codereview.webrtc.org/2013523002 .
Cr-Commit-Position: refs/heads/master@{#12947}
This CL makes the ctor public and externally usable by changing the
camera id argument from an int to a String.
The main purpose with this change is to get rid of the
CameraEnumerationAndroid.setEnumerator() hack. If an external app wants
to have a custom format enumeration, they can just override
getSupportedFormats() instead.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2012193003
Cr-Commit-Position: refs/heads/master@{#12945}
Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2013363002 .
Cr-Commit-Position: refs/heads/master@{#12943}
The Camera1 and Camera2 API use different framerate range types. Camera1
uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
unfortunately only available on Lollipop and later, so this CL adds a
similar FramerateRange class in CaptureFormat.
The purpose with this CL is to have a common framerate range type that can
be reused from both Camera1 and Camera2 in helper functions such as
CameraEnumerationAndroid.getClosestSupportedFramerateRange().
BUG=webrtc:5519
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2010763003 .
Cr-Commit-Position: refs/heads/master@{#12942}
This makes it clearer that the C++ SurfaceTextureHelper owns its associated java object it.
In addition, arrange so that the SurfaceTextureHelper.stopListening
method (in java) can be called from any thread.
BUG=
Review-Url: https://codereview.webrtc.org/1988043002
Cr-Commit-Position: refs/heads/master@{#12941}
They don't really belong in PeerConnection because the state at that
level can change when a transport channel is removed. That makes almost
any state transition possible.
The asserts are now in P2PTransportChannel (the equivalent to
IceTransport in the spec). Currently it has a reduced set of states,
that don't even take into account writability, but I plan to change
that soon.
BUG=webrtc:4757
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2005573002 .
Cr-Commit-Position: refs/heads/master@{#12937}
The test doesn't really care about the order; the fact that it relied
on a specific order was just an implementation detail.
However, this made the test flaky since race conditions sometimes
determine the order. It also made it frustrating to add new tests.
BUG=webrtc:5930
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2006263004 .
Cr-Commit-Position: refs/heads/master@{#12936}
Due to the experiment in chromium relying on KT_DEFAULT = KT_RSA (bug:
crbug.com/611698) a conditional was introduced. Now that the experiment is
ending and the experiment flag has been removed we can make KT_DEFAULT=KT_ECDSA
unconditionally.
BUG=chromium:611698
Review-Url: https://codereview.webrtc.org/2009533003
Cr-Commit-Position: refs/heads/master@{#12935}
The local endpoint was given 4 seconds to converge but the remote
endpoint was only given 1 second. Now they both collectively
have 4 seconds.
Also fixed the ExpectCandidate2 method (used for verbose failure
logging) and removed a bunch of dead code.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2018703002 .
Cr-Commit-Position: refs/heads/master@{#12934}
Adding a some checks and switching out a few assert for RTC_[D]CHECK.
These changes are around use of AudioFrame.data_ to help us catch issues earlier since assert() is left out in release builds, including builds with DCHECK enabled. I've also added a few full-on CHECKs to avoid reading past buffer boundaries or continuing on in a failed state.
TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Committed: https://crrev.com/60c4e0ae8f124f08372645a95042f4a1246d7aa3
Cr-Commit-Position: refs/heads/master@{#12925}
Committed: https://crrev.com/5771beb265129082d31736259b7dc6ca037cff4d
Cr-Commit-Position: refs/heads/master@{#12926}
Review URL: https://codereview.webrtc.org/2014973002 .
Cr-Commit-Position: refs/heads/master@{#12927}
Adding a some checks and switching out a few assert for RTC_[D]CHECK.
These changes are around use of AudioFrame.data_ to help us catch issues earlier since assert() is left out in release builds, including builds with DCHECK enabled. I've also added a few full-on CHECKs to avoid reading past buffer boundaries or continuing on in a failed state.
TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Committed: https://crrev.com/60c4e0ae8f124f08372645a95042f4a1246d7aa3
Cr-Commit-Position: refs/heads/master@{#12925}
Review URL: https://codereview.webrtc.org/2014973002 .
Cr-Commit-Position: refs/heads/master@{#12926}
Adding a some checks and switching out a few assert for RTC_[D]CHECK.
These changes are around use of AudioFrame.data_ to help us catch issues earlier since assert() is left out in release builds, including builds with DCHECK enabled. I've also added a few full-on CHECKs to avoid reading past buffer boundaries or continuing on in a failed state.
TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/2014973002 .
Cr-Commit-Position: refs/heads/master@{#12925}
Currently there are two structs that are identical and track extension details:
webrtc::RtpExtension
cricket::RtpHeaderExtension
The use of the structs is mixed in the code to track the extensions being
supported. This results in duplicate definition of
the URI constants and there is code to convert between the two structs.
Clean up to use a single RtpHeader throughout the codebase. The actual location
of RtpHeader may change in future (perhaps to be located in api/). Additionally,
this CL renames some of the constants to clarify Uri and Id use.
BUG= webrtc:5895
Review-Url: https://codereview.webrtc.org/1984983002
Cr-Commit-Position: refs/heads/master@{#12924}
This affects the webrtc::VideoFrameBuffer and cricket::VideoFrame
classes.
To make this work, VideoFrameFactory is changed to use an
I420BufferPool rather than a plain VideoFrame to cache allocated
frames.
The I420BufferPool is reorganized to return an I420Buffer,
rather than a proxy object.
BUG=webrtc:5921, webrtc:5682
Review-Url: https://codereview.webrtc.org/2009193002
Cr-Commit-Position: refs/heads/master@{#12919}
A regression happened in https://codereview.webrtc.org/2006723002,
causing neteq_rtpplay not to work. The problem was that when the main
code was moved inside of the webrtc::test namespace, it was no longer
visible to the linker. Meanwhile, the dependency on test_support_main
rather than test_support caused the executable to be a gtest.
In this fix, the gyp dependencies are corrected, and a main method is
added outside of the namespaces.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2018473002
Cr-Commit-Position: refs/heads/master@{#12918}
If deleting files fails, wait a sec and retry. This can help in case
and antivirus software or similar has locked the file, preventing it
from being deleted.
BUG=webrtc:5898
Review-Url: https://codereview.webrtc.org/2014823002
Cr-Commit-Position: refs/heads/master@{#12917}
Also remove the unnecessary code in VideoCapturerAndroid.dispose() and
only log instead.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2007863005
Cr-Commit-Position: refs/heads/master@{#12913}
