Enumerating using android.hardware.camera2 is 10x faster than enumerating using android.hardware.camera, but they don't list exactly the same formats. android.hardware.camera2 support higher resolutions for some cameras, and also different framerates.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1321893003 .
Cr-Commit-Position: refs/heads/master@{#9861}
The purpose with this CL is to remove some code bloat. A subtle change is that GL_TEXTURE_MIN_FILTER in MediaCodecVideoDecoder is changed from GL_NEAREST to GL_LINEAR. This may lead to slightly worse performance when the decoded video is rendered minified, but with better visual quality. After reading https://crbug.com/351458 and the fix https://codereview.chromium.org/713603002 I think this is the right choice.
BUG=webrtc:4742
R=hbos@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1303373005 .
Cr-Commit-Position: refs/heads/master@{#9845}
of decoder factory class.
- Add new Peer connection factory method to initialize shared
EGL context.
This provides an option to use single peer connection factory
in the application and create peer connections from the same
factory and reinitialize shared EGL context for video
decoding HW acceleration.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1304063011 .
Cr-Commit-Position: refs/heads/master@{#9838}
Enumerating camera capabilities in the deprecated android.hardware.Camera interface is really slow because of the need to open and release the camera. By making getSupportedFormats() an interface, we allow apps the opportunity to inject their own implementation, such as storing the supported formats offline in the device's internal storage. It will also be possible to add an implementation of getSupportedFormats() using the new android.hardware.Camera2 interface in a follow-up CL.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1321903002 .
Cr-Commit-Position: refs/heads/master@{#9819}
This CL makes the Java render interface asynchronous by requiring every call to renderFrame() to be followed by an explicit renderFrameDone() call. In JNI, this is implemented with cricket::VideoFrame::Copy() before calling renderFrame(), and a corresponding call to delete in renderFrameDone(). This CL is primarily done to prepare for a new renderer implementation.
BUG=webrtc:4742, webrtc:4909
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1313563002 .
Cr-Commit-Position: refs/heads/master@{#9814}
This is handled by Android itself and may result in GL errors
when trying to release shaders when Activity is destroyed.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1322703004 .
Cr-Commit-Position: refs/heads/master@{#9811}
webrtc::VideoSource resolves the kMaxFrameRate constraint by capping the desired framerate to kMaxFrameRate. That framerate is then passed into cricket::VideoCapturer::GetBestCaptureFormat(). The default implementation will choose a format from the supported formats list. Instead, we should override this function in AndroidVideoCapturer to give VideoCapturerAndroid.java the opportunity to choose a suitable framerate range.
BUG=webrtc:4938
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1308953004 .
Cr-Commit-Position: refs/heads/master@{#9805}
Why the replacements? Mainly two reasons:
1) RTCCertificate owns the identity and as long as things are referencing the identity there should be a scoped_refptr reference to the RTCCertificate. Handing out raw pointers is less memory safe.
2) With the latest RFC, an RTCCertificate should be sufficient for specifying a crypto cert and the code should be updated to use RTCCertificate instead of SSLIdentity directly.
This replace work is split up into multiple CLs. In this CL...
- WebRtcSessionDescriptionFactory is updated to use RTCCertificate over SSLIdentity.
- WebRtcSessionDescriptionFactory::SignalCertificateReady is connected to WebRtcSession::OnCertificateReady and WebRtcSession is updated to use RTCCertificate.
- The cricket::Transport and related classes are updated to use RTCCertificate. These are called from WebRtcSession::OnCertificateReady.
BUG=webrtc:4927
R=tommi@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1312643004 .
Cr-Commit-Position: refs/heads/master@{#9794}
The primary fix in this CL is to remove the dangling |thread_| pointer in AndroidVideoCapturerJni. That thread is not safe to use after Stop() has been called. Even after Stop() has been called, we must still be able to return late frames to Java in order to not leak them, so that path has been made thread safe instead. To make sure that we always return frames, the Java frame should be wrapped in a scoped_refptr as quickly as possible, so this CL moves the wrapping from AndroidVideoCapturer to AndroidVideoCapturerJni. This also removes the need for the interface function AndroidVideoCapturerDelegate::ReturnBuffer().
Some other minor changes are:
* Remove |valid_global_refs_| and all logic related to that. Now that rtc::Bind() captures method objects as scoped_refptr, the destructor of AndroidVideoCapturerJni will not be called before all frames are returned.
* Remove global ref |j_frame_observer_|. No need for this, we don’t call it and it is kept alive with standard Java memory management.
* Add helper function ShallowCenterCrop() for VideoFrameBuffers. This functionality already exists in the constructor of WrappedI420Buffer, but it’s more convenient to have it as a separate function.
BUG=webrtc:4742,webrtc:4909
R=glaznev@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1307973002 .
Cr-Commit-Position: refs/heads/master@{#9784}
This CL allows you to, having generated one or more RTCCertificates, supply them to RTCConfiguration for CreatePeerConnection use. This means an SSLIdentity does not have to be generated with a DtlsIdentityStore[Interface/Impl] as part of the CreatePeerConnection steps because the certificate contains all the necessary information.
To create an RTCCertificate you have to do the identity generation yourself though. But you could reuse the same RTCCertificate for multiple connections.
BUG=webrtc:4927
R=tommi@webrtc.org, torbjorng@webrtc.org
Review URL: https://codereview.webrtc.org/1288033009 .
Cr-Commit-Position: refs/heads/master@{#9774}
Migrated from https://codereview.webrtc.org/1275703006/ which causes test failures for android. On android, loopback interface was used as local interface to generate candidates. Add a test case to make sure this won't be broken in the future.
Also observed some failures under content_browsertests in chromium.fyi bot but can't repro locally. Might just be temporary test issue.
BUG=webrtc:4517
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1299333003 .
Cr-Commit-Position: refs/heads/master@{#9746}
The IceEndpointType has the format of <local_endpoint>_<remote_endpoint>. It is recorded on the BestConnection when we have the first OnTransportCompleted signaled.
BUG=webrtc:4918
R=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1277263002 .
Cr-Commit-Position: refs/heads/master@{#9737}
This reverts commit 0a2955f227666efd87b2a303a69c083ef801c528.
Revert "In the past, P2PPortAllocator.enable_multiple_routes is the indicator whether we should bind to the any address. It's easy to translate that into a port allocator flag in P2PPortAllocator's ctor. Going forward, we have to depend on an asynchronous permission check to determine whether gathering local address is allowed or not, hence the current way of passing it through constructor approach won't work any more. The asynchronous check will trigger SignalNetowrksChanged so we could only check that inside DoAllocate."
This reverts commit ba9ab4cd8d2e8fbc068dc36b5e6f6331d7deeccf.
TBR=pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1288843003 .
Cr-Commit-Position: refs/heads/master@{#9729}
Add events to Android VideoRendererGui implementation to
optionally report first rendered frame and video frame
dimension changes.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1292293002 .
Cr-Commit-Position: refs/heads/master@{#9715}
There is currently no way to dispose VideoRendererGui or VideoRendererGui.YuvImageRenderer. This CL adds functions to do so.
BUG=webrtc:4892
Review URL: https://codereview.webrtc.org/1273803002
Cr-Commit-Position: refs/heads/master@{#9710}
This will prevent it from blocking network input when it falls behind,
which is happening when running with ThreadSanitizer.
BUG=webrtc:4663
Review URL: https://codereview.webrtc.org/1236023010
Cr-Commit-Position: refs/heads/master@{#9707}