430a9c3bfd
Reason for revert: Frame rate and freeze detection not working properly after switchCamera(). This is because the previous cameraObserver is not removed before posting a new one. Original issue's description: > VideoCapturerAndroid: Use one thread per startCapture()/stopCapture() session > > Currently, VideoCapturerAndroid sets the thread and handler in the ctor > and clears them in dispose(). This CL sets the handler in startCapture() > instead and clears it in stopCapture(). The purpose is to prepare for > sending in the SurfaceTextureHelper in startCapture() instead of letting > VideoCapturerAndroid create it in the ctor. > > All access to the handler is now synchronized by a lock, and all > Runnables are posted with a token so that they can be removed all at > once in stopCapture() to guarantee that no pending operation will be > executed after stopCapture(). > > BUG=webrtc:5519 > > Committed: https://crrev.com/9cbebee523dbd280a4f67ad414a432ed730f241f > Cr-Commit-Position: refs/heads/master@{#11939} TBR=perkj@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/1777253002 Cr-Commit-Position: refs/heads/master@{#11941}
This directory holds a Java implementation of the webrtc::PeerConnection API, as
well as the JNI glue C++ code that lets the Java implementation reuse the C++
implementation of the same API.
To build the Java API and related tests, build with OS=android in $GYP_DEFINES.
To use the Java API, start by looking at the public interface of
org.webrtc.PeerConnection{,Factory} and the org.webrtc.PeerConnectionTest.
To understand the implementation of the API, see the native code in jni/.