Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
Depends on https://codereview.webrtc.org/1345433002/
BUG=chromium:468375
(in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1342543004
Cr-Commit-Position: refs/heads/master@{#9954}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
This CL should not do any functional changes. It removes some redundant arguments and unnecessary error checking.
BUG=webrtc:4993
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1338943003 .
Cr-Commit-Position: refs/heads/master@{#9950}
Reason for revert:
Breaks goma (??!??!?)
Original issue's description:
> Bailing out if pc factory fails to get created.
>
> This prevents us from continuing if we fail initialization.
> The failure will happen closer to its source, rather than
> when we try to create the first peer connection.
>
> BUG=None
> R=glaznev@webrtc.org
>
> Committed: https://crrev.com/6eb75d9e67f02c256436eb96f3c77026486561a1
> Cr-Commit-Position: refs/heads/master@{#9948}
TBR=glaznev@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review URL: https://codereview.webrtc.org/1344363002
Cr-Commit-Position: refs/heads/master@{#9949}
This prevents us from continuing if we fail initialization.
The failure will happen closer to its source, rather than
when we try to create the first peer connection.
BUG=None
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1339923004 .
Cr-Commit-Position: refs/heads/master@{#9948}
Need to figure out the best way to initialize native logging system
while peer connection factory is not created yet.
R=jiayl@webrtc.org
Review URL: https://codereview.webrtc.org/1343163003 .
Cr-Commit-Position: refs/heads/master@{#9947}
Currently disposing Java peer connection object will result in auto
release of media streams and media tracks added to peer connection.
Add an option to allow application to own video track so it can be
kept after peer connection is destroyed.
R=jiayl@webrtc.org, wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1333363002 .
Cr-Commit-Position: refs/heads/master@{#9946}
I'm not super happy with the GetVoE() function added on MediaEngineInterface, but this will eventually be gone, once webrtc::Call owns the shared VoE state (or initially, maps ADM* to an implicitly created VoE).
BUG=webrtc:4690
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1269863005 .
Cr-Commit-Position: refs/heads/master@{#9939}
Add new helper class to create and synchronize access to SurfaceTextures. The plan is replace the SurfaceTexture in MediaCodecVideoDecoder in a follow-up CL and remove the SurfaceTexture.updateTexImage() call in VideoRendererGui.
BUG=webrtc:4993
R=hbos@webrtc.org
Review URL: https://codereview.webrtc.org/1342713003 .
Cr-Commit-Position: refs/heads/master@{#9938}
Future log messages should all be sent to org.webrtc.Logging as well.
BUG=
Review URL: https://codereview.webrtc.org/1338033003
Cr-Commit-Position: refs/heads/master@{#9936}
It is possible that cameraThreadHandler is null upon calling
switchCamera(). This CL adds a guard against that.
Review URL: https://codereview.webrtc.org/1325333003
Cr-Commit-Position: refs/heads/master@{#9925}
Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
BUG=chromium:468375 (in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1316363005
Cr-Commit-Position: refs/heads/master@{#9913}
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}
