Remove onOutputFormatRequest from the VideoCapturer interface and from
all implementations of that interface. Apps should now use
VideoSource.adaptOutputFormat() instead.
BUG=webrtc:6391
Review-Url: https://codereview.webrtc.org/2373353002
Cr-Commit-Position: refs/heads/master@{#14428}
The Java VideoSource class wraps the C++ AndroidVideoTrackSource.
AndroidVideoTrackSource is the object actually owning the VideoAdapter.
We currently control the VideoAdapter through the Java VideoCapturer,
but it is more natural and direct to control it through the Java
VideoSource class. This CL adds the necessary function to do this, and
the function in VideoCapturer is deprecated.
BUG=webrtc:6391
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2350933006 .
Cr-Commit-Position: refs/heads/master@{#14332}
Camera id doesn't really exist for Camera2. Changing onCameraOpening to
take a string instead removes ugly code.
BUG=webrtc:6325
R=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2331013002
Cr-Commit-Position: refs/heads/master@{#14212}
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}
SurfaceViewRendererOnMeasureTest#testFrame1280x720 is currently flaky
because of a race. This issue was introduced here:
https://codereview.webrtc.org/2111933002/. That CL moved the function
updateFrameDimensionsAndReportEvents() from renderFrame() to
renderFrameOnRenderThread(). The OnMeasureTest currently just calls
renderFrame() with a new frame size and immediately starts testing the
measured size, which might be before renderFrameOnRenderThread() is
executed. This CL waits for the RendererEvents.onFrameResolutionChanged()
callback before starting the test to fix this race.
BUG=webrtc:6089
Review-Url: https://codereview.webrtc.org/2147463002
Cr-Commit-Position: refs/heads/master@{#13448}
This CL moves some arguments, e.g. the camera thread, from the startCapture() function to a new initialize() function. These arguments are constant during the lifetime of the VideoCapturer, and are not changed for different startCapture() calls. Setting them once allows for simplifications in the code.
This CL also fixes a bug for camera2 where pendingCameraSwitchSemaphore might not be released when switchEventsHandler is null.
In camera1, the handler lock and 'cameraThreadHandler == null' check is replaced with an atomic boolean to check if the camera is stopped.
BUG=webrtc:5519
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2122693002 .
Cr-Commit-Position: refs/heads/master@{#13404}
The plan is to use CameraEnumerator as a "factory" for camera objects in
the future. This CL prepares for that by moving Camera1 specific stuff
away from CameraEnumerationAndroid to Camera1Enumerator. Because
CameraEnumerationAndroid methods were part of public API there are
deprecated mocks for now.
When making these changes, I noticed that code duplication in
CameraVideoCapturer tests implementing TestObjectFactory could be
decreased by making TestObjectFactory an abstract class that uses
CameraEnumerator.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2071803002
Cr-Commit-Position: refs/heads/master@{#13185}
Camera1 tests are now separated from general CameraVideoCapturer tests.
Main motivation behind these changes is that Camera2 implementation can
be tested using the same tests.
CL also reduces code duplication on tests using textures.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024843002
Cr-Commit-Position: refs/heads/master@{#13130}
In org.webrtc.VideoCapturerAndroidTest#startWhileCameraIsAlreadyOpenAndCloseCamera,
use a video renderer instead of a capture observer. The video renderer
automatically returns the texture buffers, which resolves the bug.
There shouldn't be any changes to the effectiveness of the test.
BUG=webrtc:5982
Review-Url: https://codereview.webrtc.org/2042283004
Cr-Commit-Position: refs/heads/master@{#13085}
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}
This CL removes compile warnings such as:
[4520/4630] ACTION Compiling java for libjingle_peerconnection_android_unittest
androidtests/src/org/webrtc/VideoCapturerAndroidTestFixtures.java:13: warning: [deprecation] Camera in android.hardware has been deprecated
import android.hardware.Camera;
Review-Url: https://codereview.webrtc.org/2024083002
Cr-Commit-Position: refs/heads/master@{#12970}
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}
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}
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}
Reason for revert:
I was too quick to judge, this CL does not cause the problem.
Original issue's description:
> Revert of Android GlDrawer: Add frame size as argument to draw functions (patchset #2 id:20001 of https://codereview.webrtc.org/1948473002/ )
>
> Reason for revert:
> Causes errors on Google3 import.
>
> Original issue's description:
> > Android GlDrawer: Add frame size as argument to draw functions
> >
> > BUG=b/28544933
> >
> > Committed: https://crrev.com/71af75dc3ca8516017dca9de2ebe582145ecad14
> > Cr-Commit-Position: refs/heads/master@{#12623}
>
> TBR=glaznev@webrtc.org,magjed@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=b/28544933
>
> Committed: https://crrev.com/172683173dd84a72659ad494962245445eb2a353
> Cr-Commit-Position: refs/heads/master@{#12627}
TBR=glaznev@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=b/28544933
Review-Url: https://codereview.webrtc.org/1947073002
Cr-Commit-Position: refs/heads/master@{#12628}
SurfaceTextureHelper.startListening() is asynchronous and posts a Runnable to the handler thread. If stopListening() is called before that Runnable is executed, the Runnable will set the listener after stopListening() has been called. Then the next call to startListening() will fail with "SurfaceTextureHelper listener has already been set."
This CL adds a test to reproduce this bug, and a fix.
BUG=5519,b/27677772
Review URL: https://codereview.webrtc.org/1806013003
Cr-Commit-Position: refs/heads/master@{#12030}
This CL changes the interface by adding a SurfaceTextureHelper argument
to VideoCapturer.startCapture(). This removes the need for the
VideoCapturer to create the SurfaceTextureHelper itself. This also means
that it is no longer necessary to send an EGLContext to the
VideoCapturerAndroid.create() function.
The SurfaceTextureHelper is now created in AndroidVideoCapturerJni, and
the EGLContext is passed from PeerConnectionFactory in
nativeCreateVideoSource().
Another change in this CL is that the C++ SurfaceTextureHelper creates
the Java SurfaceTextureHelper instead of getting it passed as an
argument in the ctor.
BUG=webrtc:5519
Review URL: https://codereview.webrtc.org/1783793002
Cr-Commit-Position: refs/heads/master@{#11977}
and signaling the remote side to remove its remote candidate by setting the candidate priority to 0.
BUG=
Review URL: https://codereview.webrtc.org/1648813004
Cr-Commit-Position: refs/heads/master@{#11958}
This CL replaces the function SurfaceTextureHelper.setListener() that
could only be called once with the functions startListening() and
stopListening() that can be called multiple times. This is necessary
when the SurfaceTextureHelper will be passed to the VideoCapturerAndroid
in startCapture(). startListening() will be called in startCapture() and
stopListening() in stopCapture().
BUG=webrtc:5519
Review URL: https://codereview.webrtc.org/1755573002
Cr-Commit-Position: refs/heads/master@{#11855}
Currently, VideoCapturerAndroid owns a dedicated tread, and
SurfaceTextureHelper get this thread passed in the ctor. In
VideoCapturerAndroid.dispose(), ownership of the thread is passed to
SurfaceTextureHelper so that we can return directly instead of waiting
for the last frame to return.
This CL makes the SurfaceTextureHelper own the thread the whole time
instead, and VideoCapturerAndroid calls getHandler() to get it instead.
BUG=webrtc:5519
Review URL: https://codereview.webrtc.org/1738123002
Cr-Commit-Position: refs/heads/master@{#11790}
This CL factors out the interface that AndroidVideoCapturerJni is using to communicate with the Java counterpart. This interface is moved into VideoCapturer. The interface is not touched in this CL, and a follow-up CL is planned to simplify and improve it.
Another change is that the native part of VideoCapturer is created in PeerConnectionFactory.createVideoSource() instead of doing it immediately in the ctor.
BUG=webrtc:5519
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1696553003 .
Cr-Commit-Position: refs/heads/master@{#11606}
Reason for revert:
Breaks downstream compilation. Please reland in a non-breaking fashion.
Original issue's description:
> Android: Remove VideoCapturer
>
> This CL makes PeerConnectionFactory.createVideoSource() and nativeCreateVideoSource work directly with VideoCapturerAndroid instead of going via VideoCapturer. The native part is now created in nativeCreateVideoSource() instead of doing it immediately in VideoCapturerAndroid.create().
>
> BUG=webrtc:5519
> R=perkj@webrtc.org
>
> Committed: https://crrev.com/09eab315fddc3432c19d8f662f4b9360f2a58010
> Cr-Commit-Position: refs/heads/master@{#11582}
TBR=perkj@webrtc.org,magjed@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/1690073002
Cr-Commit-Position: refs/heads/master@{#11586}
Also fixing an issue with the Java PeerConnection unit test.
It wasn't correctly waiting for 10 video frames to be received.
And fixed an issue with the video engine, where generated
black frames don't get any rotation.
BUG=webrtc:5128
Review URL: https://codereview.webrtc.org/1639583003
Cr-Commit-Position: refs/heads/master@{#11583}
This CL makes PeerConnectionFactory.createVideoSource() and nativeCreateVideoSource work directly with VideoCapturerAndroid instead of going via VideoCapturer. The native part is now created in nativeCreateVideoSource() instead of doing it immediately in VideoCapturerAndroid.create().
BUG=webrtc:5519
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1684403002 .
Cr-Commit-Position: refs/heads/master@{#11582}
In addition to the code moved from talk/app/webrtc
there were some files in webrtc/api/objctests that still
had the libjingle license header.
BUG=webrtc:5418
TBR=tkchin@webrtc.org
NOTRY=True
Review URL: https://codereview.webrtc.org/1680293005
Cr-Commit-Position: refs/heads/master@{#11552}
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc
The HAVE_SCTP define was added for the peerconnection_unittests target
in api_tests.gyp.
I also checked that none of
SRTP_RELATIVE_PATH
HAVE_SRTP
HAVE_WEBRTC_VIDEO
HAVE_WEBRTC_VOICE
were used by the talk/app/webrtc code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle:
https://codereview.chromium.org/1615433002
BUG=webrtc:5418
NOPRESUBMIT=True
R=deadbeef@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1610243002 .
Cr-Commit-Position: refs/heads/master@{#11545}
