This is in line with the new C++ VideoCodecFactory interface.
Bug: webrtc:7925
Change-Id: Ice51cab61b6498fef1b0483ce1bd4835ef550231
Reviewed-on: https://webrtc-review.googlesource.com/88368
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23966}
Since the legacy video codecs seem to be around for some time more, we
need to make them injectable and provide a migration path for clients
that still use them so that we can clean up PeerConnectionFactory.
This CL moves the creation of EglContexts into the legacy codec
factories. Clients can then migrate to setEGLContext() instead of using
setVideoHwAccelerationOptions().
Bug: webrtc:9502
Change-Id: I608607b32db73ce3df7704a061e66d9d53946af5
Reviewed-on: https://webrtc-review.googlesource.com/87941
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23934}
All usage of these functions should be migrated to use
android.opengl.Matrix instead.
Bug: webrtc:9487
Change-Id: I023761b31cae7e7af9b537928b849657baa5bb8b
Reviewed-on: https://webrtc-review.googlesource.com/87263
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23853}
This is a reland of 21219a0e43446701810236fb9fdd59be072c12df
The default implementation of OnLogMessage(msg, sev, tag) discarded
the tag, resulting in FileRotatingLogSink not receiving tags.
Since the revert the default implementation of
OnLogMessage(msg, sev, tag) has been updated to add the tag to the log
message. A more efficient implementation of it has also been added for
FileRotatingLogSink.
Unit tests are added for the default implementation and for Loggable
injection.
Original change's description:
> Reland "Injectable logging"
>
> Any injected loggable or NativeLogger would be deleted if PCFactory
> was reinitialized without calling setInjectableLogger. Now native
> logging is not implemented as a Loggable, so it will remain active
> unless a Loggable is injected.
>
> This is a reland of 59216ec4a4151b1ba5478c8f2b5c9f01f4683d7f
>
> Original change's description:
> > Injectable logging
> >
> > Allows passing a Loggable to PCFactory.initializationOptions, which
> > is then injected to Logging.java and logging.h. Future log messages
> > in both Java and native will then be passed to this Loggable.
> >
> > Bug: webrtc:9225
> > Change-Id: I2ff693380639448301a78a93dc11d3a0106f0967
> > Reviewed-on: https://webrtc-review.googlesource.com/73243
> > Commit-Queue: Paulina Hensman <phensman@webrtc.org>
> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
> > Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#23241}
>
> Bug: webrtc:9225
> Change-Id: I2fe3fbc8c323814284bb62e43fe1870bdab581ee
> TBR: kwiberg
> Reviewed-on: https://webrtc-review.googlesource.com/77140
> Commit-Queue: Paulina Hensman <phensman@webrtc.org>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23310}
Bug: webrtc:9225
Change-Id: I67a5728fe772f0bedc9509713ed8b8ffdc31af81
TBR: kwiberg
Reviewed-on: https://webrtc-review.googlesource.com/80860
Commit-Queue: Paulina Hensman <phensman@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23711}
Also adds api in PCF for specifying which library to load.
This is in preparation for a CL adding a native function
to be used only in tests.
Bug: webrtc:9225
Change-Id: I72eff272350404729424176758bfa81f7da81836
Reviewed-on: https://webrtc-review.googlesource.com/84125
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23663}
There is no need to hold on to the render thread after the OES texture
buffer has been created. toI420() is handled by the thread in the
SurfaceTextureHelper.
Bug: webrtc:9391
Change-Id: Ide081bc083db72bb991f1deba74d3cecf3e1fee6
Reviewed-on: https://webrtc-review.googlesource.com/84121
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23652}
This CL adds tests that are primarily targeting
VideoFrame.Buffer.toI420() and cropAndScale(), but includes the whole
chain for YuvConverter, GlRectDrawer, and VideoFrameDrawer.
It also includes a couple of fixes to bugs that were exposed by the new
tests.
Bug: webrtc:9186, webrtc:9391
Change-Id: I5eb62979a8fd8def28c3cb2e82dcede57c42216f
Reviewed-on: https://webrtc-review.googlesource.com/83163
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23611}
In particular:
* Trying to remove a VideoSink that was not attached should be a no-op.
* Trying to remove a null VideoSink should be a no-op.
* Adding the same VideoSink multiple times should a no-op, and should
not create duplicate native VideoSinks.
* Trying to add a null VideoSink should throw an exception in the Java
layer instead of crashing in native code.
This CL also adds tests that verify these behaviors.
Bug: webrtc:9403
Change-Id: I928b7bb7f683634e287d7fec9e26f4179f73c150
Reviewed-on: https://webrtc-review.googlesource.com/83322
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23602}
The proper closing procedure is:
1. Alice resets outgoing stream.
2. Bob receives incoming stream reset, resets his outgoing stream.
3. Alice receives incoming stream reset; channel closed!
4. Bob receives acknowledgement of reset; channel closed!
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.7
However, up until now we've been sending both an incoming and outgoing reset
from the side initiating the closing procedure, and doing nothing on the remote
side.
This means that if you call "Close" and the remote endpoint is using an old
version of WebRTC, the channel's state will be stuck at "closing" since the
remote endpoint won't send a reset. Which is already what happens when Firefox
is talking to Chrome.
This CL also fixes an issue where the DataChannel's state prematurely went to
"closed" before the closing procedure was complete. Which could result in a
new DataChannel attempting to re-use the ID and failing.
TBR=magjed@webrtc.org
Bug: chromium:449934, webrtc:4453
Change-Id: Ic1ba813e46538c6c65868961aae6a9780d68a5e2
Reviewed-on: https://webrtc-review.googlesource.com/79061
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23478}
This CL adds the field but does not implement any functionality using it.
Bug: webrtc:9341
Change-Id: I533fc7f8bc1e40207aa16b834e0d7daa60709614
Reviewed-on: https://webrtc-review.googlesource.com/78741
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23466}
Before this CL, there would be an out-of-bounds write in the ByteBuffer
copying when a decoded frame had height != sliceHeight.
Bug: webrtc:9194
Change-Id: Ibb80e5555e8f00d9e1fd4cb8a73f5e4ccd5a0b81
Tested: 640x360 loopback with eglContext == null in AppRTCMobile on Pixel.
Reviewed-on: https://webrtc-review.googlesource.com/74120
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23184}
Let the test expect calls to onRenegotiationNeeded(), as introduced by
https://codereview.webrtc.org/2977493002.
Bug: webrtc:7761
Change-Id: If8e3c484236f6599cc225a0398bbbc9cf6c356a5
Reviewed-on: https://webrtc-review.googlesource.com/48364
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23165}
This is a reland of 3e0dee26603cdc3a2653c225398f55dd8ca0d8c1
Original change's description:
> Android: Remove deprecated PeerConnectionFactory ctors
>
> This CL removes deprecated PeerConnectionFactory ctors as well as some
> deprecated comments and functions left from the
> PeerConnectionFactory.initialize work.
>
> Bug: webrtc:9158
> Change-Id: I757f85b52cbfdbe15bf2570c394202b898892550
> Reviewed-on: https://webrtc-review.googlesource.com/70400
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23085}
TBR=sakal
Bug: webrtc:9158
Change-Id: Idb3628be85cc3268a7a4cf6990af5ed2f406ab07
Reviewed-on: https://webrtc-review.googlesource.com/74400
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23114}
This CL removes deprecated PeerConnectionFactory ctors as well as some
deprecated comments and functions left from the
PeerConnectionFactory.initialize work.
Bug: webrtc:9158
Change-Id: I757f85b52cbfdbe15bf2570c394202b898892550
Reviewed-on: https://webrtc-review.googlesource.com/70400
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23085}
The VPN adapter type is not effectively supported in WebRTC Android for
1) the network monitor may not obtain the VPN adapter type from the OS,
e.g. via NetworkInfo.getType, 2) and VPN adapter type is replaced
by the adapter type of an underlying network by the network monitor in
the current implementation. Specifically, WebRTC Android would
previously classify VPNs as either type ADAPTER_TYPE_UNKNOWN, or the
type of the currently active network (which we assume the VPN is
using).
In this CL, VPNs are classified as ADAPTER_TYPE_VPN whenever possible,
and the underlying network type, if available from the VPN, is
separately stored and used to prioritize ICE candidates in network path
selection.
This allows ADAPTER_TYPE_VPN to be used in networkIgnoreMask to ignore
VPNs when gathering ICE candidates.
Bug: webrtc:9168
Change-Id: I9513c76a114ba967437b699e71223a4a2f13f34a
Reviewed-on: https://webrtc-review.googlesource.com/70960
Commit-Queue: Qingsi Wang <qingsi@google.com>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23061}
There was an attempt to add MediaRecording functionality to the camera
classes, but it was never finished and never worked properly. This CL
removes the code for it. In the future, if offline video recording is
needed we should add it as a VideoSink instead of inside the camera
classes.
Bug: webrtc:9144
Change-Id: I74b70d4b128aa212d84e70da01e5e19133c5af24
Reviewed-on: https://webrtc-review.googlesource.com/69642
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23050}
This CL removes internal support for anything else than Android frames
that are wrapped Java VideoFrames. This allows for a big internal
cleanup and we can remove the internal class AndroidTextureBuffer and
all logic related to that. Also, the C++ AndroidVideoTrackSource no
longer needs to hold on to a C++ SurfaceTextureHelper and we can
remove all JNI code related to SurfaceTextureHelper. Also, when these
methods are removed, it's possible to let VideoSource implement the
CapturerObserver interface directly and there is no longer any need for
AndroidVideoTrackSourceObserver. Clients can then initialize
VideoCapturers themselves outside the PeerConnectionFactory, and a new
method is added in the PeerConnectionFactory to allow clients to create
standalone VideoSources that can be connected to a VideoCapturer outside
the factory.
Bug: webrtc:9181
Change-Id: Ie292ea9214f382d44dce9120725c62602a646ed8
Reviewed-on: https://webrtc-review.googlesource.com/71666
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23004}
This CL updates the WebRTC code to stop using the old VideoRenderer and
VideoRenderer.I420Frame classes and instead use the new VideoSink and
VideoFrame classes.
This CL is the first step and the old classes are still left in the code
for now to keep backwards compatibility.
Bug: webrtc:9181
Change-Id: Ib0caa18cbaa2758b7859e850ddcaba003cfb06d6
Reviewed-on: https://webrtc-review.googlesource.com/71662
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22989}
Currently this warnings prevernt chromium roll into webrtc, because we
consider them as errors. So to unblock roll all warning are suppressed.
All places are documented into bug and will be fixed later.
TBR=henrika@webrtc.org
Bug: webrtc:9175
Change-Id: I0bf5a4b65eb49308e28f71a92d42b5fad6a99b74
Reviewed-on: https://webrtc-review.googlesource.com/71420
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22956}
This ensures memory is released timely and avoids problems with garbage
collection.
Native buffers don't support array operation, so FileVideoCapturer had
to be update to use FileChannel to write ByteBuffers directly.
Bug: None
Change-Id: I3f63d2adc159e9f39f0c68dd0bd6b1747686584e
Reviewed-on: https://webrtc-review.googlesource.com/55262
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22118}
In practice, this is safe since WebRTC doesn't access the buffer after the
callback returns. This avoids unnecessary memory allocations causing out of
memory errors.
Bug: b/72675429
Change-Id: I2ed0224f40b7e1fa67c7aba625b99211f9c1e0a3
Reviewed-on: https://webrtc-review.googlesource.com/49162
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21932}
This removes the DefaultAudioProcessingFactory, PostProcessingFactory and DefaultAudioProcessingFactoryTest classes and leaves the interface AudioProcessingFactory without any default implementation (as the default APM is already created by the PeerConnectionFactory JNI).
Bug: webrtc:8701
Change-Id: I259108afbc5b24cab5161485f45af4236f775c18
Reviewed-on: https://webrtc-review.googlesource.com/37220
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21577}
C++ API allows passing all configuration through RTCConfiguration
object. This adds all values previously passed through PC constraints
to Java RTCConfiguration object and deprecates API that takes PC
contraints.
Using the deprecated API overrides the values in RTCConfigration
object.
Bug: webrtc:8663, webrtc:8662
Change-Id: I128432c3caba74403513fb1347ff58830c643885
Reviewed-on: https://webrtc-review.googlesource.com/33460
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#21357}
This is similar to https://webrtc-review.googlesource.com/c/src/+/3620
for iOS.
Using the new WebRtcMediaEngineFactory::Create API, the built-in
software video codecs are no longer appended to the injected codecs.
To be able to use the software codecs, they are exposed as Java
classes through SoftwareVideoEncoderFactory etc.
There is also a new DefaultVideoEncoderFactory used by AppRTCMobile.
This factory tries to use hardware implementations where available,
but falls back to using the injected software codecs.
The HardwareVideoEncoderFactory is temporarily also falling back on
the software codecs in its default configuration in order to
maintain backwards compatibility.
Bug: webrtc:7925
Change-Id: I3e8c5ed492ccd160aca968986ad217d7978a951c
Reviewed-on: https://webrtc-review.googlesource.com/17480
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Anders Carlsson <andersc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20647}
In https://chromium-review.googlesource.com/c/chromium/src/+/750645
Chromium started to use an ErrorProne plugin to discourage synchronized
public methods (an encourage the usage of synchronized blocks).
In order to unblock the Chromium Roll we can suppress these warnings
and decide if we want to align with Chromium on this check or ask
them to make it optional.
More details in the bug.
TBR=magjed@webrtc.org
Bug: webrtc:8491
Change-Id: Ie77a324e54aab44a4f59853959549f1d21f884a0
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/20060
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20569}
Previously input buffers would be filled incorrectly for sparsely
packed buffers where stride is not equal to the plane width.
Bug: webrtc:8478
Change-Id: I080fa3c354a27982bb996be8c1e41b103384e4bc
Reviewed-on: https://webrtc-review.googlesource.com/17321
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20550}
This is done in preparation to make all javac warnings into errors for
WebRTC targets.
Bug: webrtc:6597
Change-Id: I402043157bd75943adf0de52111e5a1bb179c6d1
Reviewed-on: https://webrtc-review.googlesource.com/15104
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20450}
This allows injection of a user-defined post processing module from
the Android layer.
Bug: webrtc:8163
Change-Id: If3a6b4726c34c5f82d186b8cf95373c283cbd3f6
Reviewed-on: https://webrtc-review.googlesource.com/7610
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20367}
In order to enable errorprone [1] we have to fix this finding.
third_party/errorprone has been recently enabled in Chromium and in
order to unblock the Chromium Roll we have to fix these errors.
[1] - https://cs.chromium.org/chromium/src/third_party/errorprone/
Bug: webrtc:8390
Change-Id: Ic737def5ae2a8c6ad1216d9b485af59987fe511c
Tbr: magjed@webrtc.org
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/9161
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20273}
This will handle the scenario where, for example, the initial
offer/answer only negotiates audio, and video is added later (to the
same stream). Previously, there was absolutely no way to get a handle to
the new track without hacking the SDP. Now, the stream will be updated
after setRemoteDescription finishes.
Bug: webrtc:5677
Change-Id: Iea31bb7744da6b82afdaf44c8f74d721298a9474
Reviewed-on: https://webrtc-review.googlesource.com/6261
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20228}
This renames I420BufferImpl to JavaI420Buffer and moves it as part of
the API.
Bug: webrtc:7749
Change-Id: I70726f248ba4601b4922996712bdfdafbfa4a1e1
Reviewed-on: https://webrtc-review.googlesource.com/5381
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20145}
