In Android AppRTC Demo, there was a bug where toggling disable hardware
AGC/NS would not be reflected into the summary of those settings. This
change fixes this issue.
Review-Url: https://codereview.webrtc.org/2184223003
Cr-Commit-Position: refs/heads/master@{#13551}
stack will be removed soon in a separate CL. Constraints will not be supported
in the new implementation. Apps can request a format directly and the closest
supported format will be selected.
Changes needed from the apps:
1. Use the new createVideoSource without constraints.
2. Call startCapture manually.
3. Don't call videoSource.stop/restart, use startCapture/stopCapture instead.
R=magjed@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/2127893002 .
Cr-Commit-Position: refs/heads/master@{#13504}
Add an option to use Camera2 implemantion of CameraVideoCapturer in
AppRTC Android Demo. It is enabled by default.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2077663003
Cr-Commit-Position: refs/heads/master@{#13391}
Chromium's src/build/config/android/internal_rules.gni says java lib
target names must end with _java or _javalib.
Review-Url: https://codereview.webrtc.org/2117283002
Cr-Commit-Position: refs/heads/master@{#13382}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Fix for RtcEventLog ObjC interface
>
> This moves the RtcEventLog start/stop functions to PeerConnection on the objC interface.
>
> BUG=
> R=tkchin@webrtc.org
>
> Committed: c43bf56ef1TBR=tkchin@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/2110373002
Cr-Commit-Position: refs/heads/master@{#13338}
The parameters for Logging.enableTracing() were creating the impression
that they control level and severity of one tracing system and they are
meant to be used together. In fact the "levels" parameter controlled one
tracing system (WEBRTC_TRACE), and the "severity" parameter was
responsible for a completely different one: setting the severity level
above which log messages from LOG() will be directed to the
platform-specific debug output (logcat on Android).
The method signature suggested that the "path" parameter applied to both
systems - while it was only meaningful for the WEBRTC_TRACE; LOG
messages were directed to ADB logcat no matter what the Path value was.
It is possible to redirect LOG messages to a file, but that is done
using a completely different set of APIs
- PeerConnectionFactory.startInternalTracingCapture().
I've separated these two methods to make it more clear which of the
parameters controls which system.
NOTRY=true
Review-Url: https://codereview.webrtc.org/2110853003
Cr-Commit-Position: refs/heads/master@{#13334}
not to be created in apprtc on Android.
The path separator was missing when the path for the aecdump
file was created. This CL adds that path separator.
Note that the change of the formatting of the rest of the
line was caused by "git cl format" (the clang automatic
formatting).
BUG=webrtc:5991
Review-Url: https://codereview.webrtc.org/2053263002
Cr-Commit-Position: refs/heads/master@{#13121}
Right now if an exception is thrown, it doesn't seem to be logged
anywhere. This CL makes it show a pop-up with the error message.
This should save time debugging issues.
Review-Url: https://codereview.webrtc.org/2049933004
Cr-Commit-Position: refs/heads/master@{#13120}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
This will make it much less likely for application developers to not
realize the object is reference counted.
It also fixes a bug in the Java PeerConnection binding, by allowing a
reference to be transferred in the OnRemoveStream call via std::move.
BUG=webrtc:5128
R=pthatcher@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1972793003 .
Cr-Commit-Position: refs/heads/master@{#12976}
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:
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}
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}
Earlier, strings like "aaaa" and "1111" would be interpreted as IP
addresses, which is not optimal. This CL improves the IP_PATTERN and
adds a test for it.
Review-Url: https://codereview.webrtc.org/2009493002
Cr-Commit-Position: refs/heads/master@{#12887}
For simplicity, this CL removes the need for Design Support Library.
UI is slightly changed for this to be possible. Floating Action Button
for adding favorite is removed and instead there's a button next to the
TextView.
Review-Url: https://codereview.webrtc.org/2003983002
Cr-Commit-Position: refs/heads/master@{#12861}
When local candidates are removed, signal to RTCPeerConnection
and eventually send to the remote client.
When a candidate-removal message is received, notify the native PeerConnection.
BUG=
R=tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1972483002 .
Cr-Commit-Position: refs/heads/master@{#12852}
This helps a lot on Android devices where the user threads can be scheduled with low priority when the app is in the background, causing spurious significantly delayed before a packet can be read from the socket. With this patch the timestamp is taken by the kernel when the packet actually arrives.
R=juberti@chromium.orgTBR=juberti@webrtc.org
BUG=webrtc:5773
Review URL: https://codereview.webrtc.org/1944683002 .
Cr-Commit-Position: refs/heads/master@{#12850}
LooperExecutorTest now uses Robolectric instead of being instrumentation
test. This allows the test to be run faster and easier.
Review-Url: https://codereview.webrtc.org/1989813002
Cr-Commit-Position: refs/heads/master@{#12825}
ThreadUtils.ThreadChecker in WebRTC does the same thing. No point in
having a duplicate implementation.
Review-Url: https://codereview.webrtc.org/1992813007
Cr-Commit-Position: refs/heads/master@{#12824}
LooperExecutor is only truly needed in WebSocketChannelClient because of
WebSocketClient from autobanh requiring thread to have a looper. So
LooperExecutor was left there but replaced everywhere else with built-in
singleThreadExecutor/singleThreadScheduledExecutor.
Motivation behind this change is that built-in class behaves better
under testing environment and doesn't require hacky
RobolectricLooperExecutor.
Review-Url: https://codereview.webrtc.org/1992213002
Cr-Commit-Position: refs/heads/master@{#12823}
Test is very simple but should test the basic sanity of the class.
Test is implemented as a JUnit test using Robolectric. Also
removed unused imports from TCPChannelClientTest.
Review-Url: https://codereview.webrtc.org/1989013003
Cr-Commit-Position: refs/heads/master@{#12804}
This allows connecting between clients without using external servers, which is useful to OEMs if they are working in a network without internet connection. Implementation uses custom AppRTCClient that replaces WebSocketRTCClient if roomId looks like an IP. Instead of a web socket, this class uses direct TCP connection between peers as a signaling channel.
Review-Url: https://codereview.webrtc.org/1963053002
Cr-Commit-Position: refs/heads/master@{#12789}
This allows creating tests for AppRTC Android demo that will be run on
the host machine instead of a device. These tests can mock Android APIs
through Robolectric. Because the tests are run on the host machine,
they run much faster.
BUG=webrtc:5896
NOTRY=True
Review-Url: https://codereview.webrtc.org/1985663002
Cr-Commit-Position: refs/heads/master@{#12769}
Reason for revert:
Breaks user code. Said code needs to stop using scoped_ptr!
Original issue's description:
> Remove webrtc/base/scoped_ptr.h
>
> BUG=webrtc:5520
>
> NOTRY=True
>
> Committed: https://crrev.com/65fc62e9dd8a8716db625aaef76ab92f542ecc5a
> Cr-Commit-Position: refs/heads/master@{#12684}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5520
Review-Url: https://codereview.webrtc.org/1965063003
Cr-Commit-Position: refs/heads/master@{#12686}
