7092368982
VideoEncoderWrapper may be released and reused (Release() followed by InitEncode()). This often happens back to back when encoders are reconfigured. Because encoded frames are posted asynchronously to the encoder queue, they may be processed after the encoder associated with them has already been released. In the existing code, if a frame for the new encoder had already been received, the processing of the frame for the old encoder would clear out the record for the new encoder's frame. This is now fixed by only clearing out records that are older than the encoded frame being processed. A particularly bad symptom is when the new encoder is used for the same stream as the old one (but was reconfigured for e.g. a change in resolution). In that case, the new encoder's initial keyframe gets dropped, and all subsequent difference frames are based off the last sent frame from the old encoder. This all renders as garbage until a new keyframe is sent. Bug: webrtc:8849 Change-Id: I25094f12b38e03e158dc10ac66e92aa9ebaa5541 Reviewed-on: https://webrtc-review.googlesource.com/47549 Commit-Queue: Jonathan Yu <yujo@chromium.org> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org> Cr-Commit-Position: refs/heads/master@{#21896}
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, generate GN projects with:
--args='target_os="android"'
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/.