Generic video capturing interface that extends tvi.webrtc.VideoCapturer.

This interface provides an extension of the WebRTC video capturing interface. Implementations of this interface or tvi.webrtc.VideoCapturer can be used when creating local video tracks. As a result, callers can leverage capturers provided by the SDK, capturers provided by WebRTC, or custom capturers.

The LocalVideoTrack API directly relates to the video capturer programming model. When a caller creates a local video track, the following methods are called in the order listed.

• isScreencast - The return value is used to create a tvi.webrtc.VideoSource.
• initialize - This method is called so the video capturer can setup to capture frames. The video capturer should retain a reference to the capturer observer and prepare to forward frames. If the video capturer wants to deliver texture frames, it should do this by rendering on the SurfaceTexture provided by {@code surfaceTextureHelper}, register itself as a listener, and forward the frames to the capturer observer. This method will be called exactly once before startCapture. The local video track retains ownership of the {@code surfaceTextureHelper}.
• startCapture - The video capturer should start capturing in a format as close as possible to {@code width x height} at {@code * framerate}. The video capturer should capture and deliver frames to the capturer observer provided in initialize on a dedicated thread.

When a caller releases a local video track, the following methods are called in the order listed.

• stopCapture - The video capturer should stop capturing frames. The SDK expects this method to block until frames have stopped being captured.
• dispose - Perform final cleanup.

Threading Recommendations

Each of these methods are called on the same thread that creates and releases a local video track which for most cases will be the main thread. As a result, video capturers should minimize the amount of work done in each callback and delegate operations on a dedicated thread. A recommended approach would be to create a capturing thread when is called and then begin capturing and delivering frames to the capturer observer on the capturing thread when startCapture is called.

Capturers should then stop capturing and join the capturer thread when } is called.