| 88518a22c62ccb7989a0e10d43bea1a63cdfcd09 |
|
18-Dec-2015 |
perkj <perkj@webrtc.org> |
Use NV21 instead of YUV12 and clean up.
BUG=webrtc:5375
Review URL: https://codereview.webrtc.org/1530843002
Cr-Commit-Position: refs/heads/master@{#11079}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 71f5a9a37750d6ccea110028e3154ee90334ba6d |
|
11-Dec-2015 |
Per <perkj@chromium.org> |
This cl change VideoCaptureAndroid to handle CVO the same way when capturing to texture as when using ordinary byte buffers.
Ie, rotation is applied in C++ in the VideoFrameFactory is apply_rotation_ is set. If not, rotation is sent in RTP.
BUG=webrtc:4993
R=nisse@chromium.org
Review URL: https://codereview.webrtc.org/1493913007 .
Cr-Commit-Position: refs/heads/master@{#10986}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| c490e01bd1bd4a0d754ed5f746b95ac03136346f |
|
10-Dec-2015 |
nisse <nisse@webrtc.org> |
Implement NativeToI420Buffer in C++, calling java SurfaceTextureHelper, new method .textureToYUV, to
do the conversion using an opengl fragment shader.
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1460703002
Cr-Commit-Position: refs/heads/master@{#10972}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 488e75f11b840dfbe636a9ea9bbc18252e7c59f0 |
|
19-Nov-2015 |
Per <perkj@chromium.org> |
Patchset 1 yet again relands without modification https://codereview.webrtc.org/1422963003/
It do the following:
The SurfaceTexture.updateTexImage() calls are moved from the video renderers into MediaCodecVideoDecoder, and the destructor of the texture frames will signal MediaCodecVideoDecoder that the frame has returned. This CL also removes the SurfaceTexture from the native handle and only exposes the texture matrix instead, because only the video source should access the SurfaceTexture.
It moves the responsibility of calculating the decode time to Java.
Patchset2 Refactor MediaCodecVideoDecoder to drop frames if a texture is not released.
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1440343002 .
Cr-Commit-Position: refs/heads/master@{#10706}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| c01c25434ba92f6ea32cdfdcde77ec8278182851 |
|
13-Nov-2015 |
Per <perkj@chromium.org> |
Revert of Android MediaCodecVideoDecoder: Manage lifetime of texture frames (patchset #12 id:320001 of https://codereview.webrtc.org/1422963003/ )
Reason for revert:
Causes fallback to SW decoder if a renderer is put in the background.
Original issue's description:
> Patchset 1 is a pure
> revert of "Revert of "Android MediaCodecVideoDecoder: Manage lifetime of texture frames" https://codereview.webrtc.org/1378033003/
>
> Following patchsets move the responsibility of calculating the decode time to Java.
>
> TESTED= Apprtc loopback using H264 and VP8 on N5, N6, N7, S5
>
> Committed: https://crrev.com/9cb8982e64f08d3d630bf7c3d2bcc78c10db88e2
> Cr-Commit-Position: refs/heads/master@{#10597}
TBR=magjed@webrtc.org,glaznev@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
Review URL: https://codereview.webrtc.org/1441363002 .
Cr-Commit-Position: refs/heads/master@{#10637}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 9cb8982e64f08d3d630bf7c3d2bcc78c10db88e2 |
|
11-Nov-2015 |
perkj <perkj@webrtc.org> |
Patchset 1 is a pure
revert of "Revert of "Android MediaCodecVideoDecoder: Manage lifetime of texture frames" https://codereview.webrtc.org/1378033003/
Following patchsets move the responsibility of calculating the decode time to Java.
TESTED= Apprtc loopback using H264 and VP8 on N5, N6, N7, S5
Review URL: https://codereview.webrtc.org/1422963003
Cr-Commit-Position: refs/heads/master@{#10597}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 30a5b5e9fb574016ced1a45ae43921c1a01860a0 |
|
20-Oct-2015 |
olka <olka@webrtc.org> |
passing |buffer| by reference in AndroidVideoCapturer::OnIncomingFrame
BUG=webrtc:5062
Review URL: https://codereview.webrtc.org/1414703002
Cr-Commit-Position: refs/heads/master@{#10342}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 543b6ca30a43eeb069c699291460ce6bacc7959d |
|
15-Oct-2015 |
magjed <magjed@webrtc.org> |
Revert of "Android MediaCodecVideoDecoder: Manage lifetime of texture frames" https://codereview.webrtc.org/1378033003/
The code that depends on the reverted CL is disabled but not removed. NativeHandleImpl is reverted to the previous implementation, and the new implementation is renamed to NativeTextureHandleImpl. Texture capture can not be used anymore, because it will crash in peerconnection_jni.cc.
Reason for revert:
Increased HW decoder latency and crashes related to that. Also suspected cause of video tearing.
Original issue's description:
> This CL should be the last one in a series to finally
> unblock camera texture capture.
>
> The SurfaceTexture.updateTexImage() calls are moved from
> the video renderers into MediaCodecVideoDecoder, and the
> destructor of the texture frames will signal
> MediaCodecVideoDecoder that the frame has returned. This
> CL also removes the SurfaceTexture from the native handle
> and only exposes the texture matrix instead, because only
> the video source should access the SurfaceTexture.
>
> BUG=webrtc:4993
> R=glaznev@webrtc.org, perkj@webrtc.org
>
> Committed: https://crrev.com/91b348c7029d843e06868ed12b728a809c53176c
> Cr-Commit-Position: refs/heads/master@{#10203}
TBR=glaznev
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1394103005
Cr-Commit-Position: refs/heads/master@{#10288}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 52a30e31f13f6bd28b22f85613f6fd9d25086be2 |
|
12-Oct-2015 |
magjed <magjed@webrtc.org> |
Reland of Android: Put common native VideoFrameBuffer implementation in androidvideocapturer_jni (patchset #1 id:1 of https://codereview.webrtc.org/1389283003/ )
Reason for revert:
Nothing wrong with the original CL, the bug was in rtc::Bind(), which is fixed now (https://codereview.webrtc.org/1403683004/).
Original issue's description:
> Revert of Android: Put common native VideoFrameBuffer implementation in androidvideocapturer_jni (patchset #1 id:1 of https://codereview.webrtc.org/1391403004/ )
>
> Reason for revert:
> Crashes on AppRTCDemo disconnect
>
> Original issue's description:
> > Android: Put common native VideoFrameBuffer implementation in native_handle_impl.cc
> >
> > BUG=webrtc:4993
> > R=perkj@webrtc.org
> >
> > Committed: https://crrev.com/60472216da0644b49ed5f9fa51c51d4874afafa7
> > Cr-Commit-Position: refs/heads/master@{#10248}
>
> TBR=perkj@webrtc.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:4993
>
> Committed: https://crrev.com/962c26bfd6c3eb3cf7402daaab89404ae38dd534
> Cr-Commit-Position: refs/heads/master@{#10249}
TBR=perkj@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1397373002
Cr-Commit-Position: refs/heads/master@{#10254}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 962c26bfd6c3eb3cf7402daaab89404ae38dd534 |
|
12-Oct-2015 |
magjed <magjed@webrtc.org> |
Revert of Android: Put common native VideoFrameBuffer implementation in androidvideocapturer_jni (patchset #1 id:1 of https://codereview.webrtc.org/1391403004/ )
Reason for revert:
Crashes on AppRTCDemo disconnect
Original issue's description:
> Android: Put common native VideoFrameBuffer implementation in native_handle_impl.cc
>
> BUG=webrtc:4993
> R=perkj@webrtc.org
>
> Committed: https://crrev.com/60472216da0644b49ed5f9fa51c51d4874afafa7
> Cr-Commit-Position: refs/heads/master@{#10248}
TBR=perkj@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1389283003
Cr-Commit-Position: refs/heads/master@{#10249}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 60472216da0644b49ed5f9fa51c51d4874afafa7 |
|
12-Oct-2015 |
Magnus Jedvert <magjed@webrtc.org> |
Android: Put common native VideoFrameBuffer implementation in native_handle_impl.cc
BUG=webrtc:4993
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1391403004 .
Cr-Commit-Position: refs/heads/master@{#10248}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| ac30642461c4f94916741106e3ba3f3b7b670a47 |
|
08-Oct-2015 |
perkj <perkj@webrtc.org> |
Native changes for VideoCapturerAndroid surface texture support
These are the necessary changes in C++ related to the video capturer necessary to capture to a surface texture.
It does not handle scaling / cropping yet though.
BUG=
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1395673003 .
Cr-Commit-Position: refs/heads/master@{#10218}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 3d06eca5e3310ea068625a9c95d492a16854f421 |
|
08-Oct-2015 |
perkj <perkj@webrtc.org> |
Add support to Capture to a texture instead of memory.
This adds support for capturing to a texture in the Java part of VideoCapturerAndroid.
After this cl, the C++ also needs modification.
https://codereview.webrtc.org/1375953002/ contains the idea and have a working version where textures can be rendered in local preview.
BUG=webrtc:4993
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1383413002 .
Cr-Commit-Position: refs/heads/master@{#10213}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 0c4e06b4c6107a1b94f764e279e4fb4161e905b0 |
|
07-Oct-2015 |
Peter Boström <pbos@webrtc.org> |
Use suffixed {uint,int}{8,16,32,64}_t types.
Removes the use of uint8, etc. in favor of uint8_t.
BUG=webrtc:5024
R=henrik.lundin@webrtc.org, henrikg@webrtc.org, perkj@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1362503003 .
Cr-Commit-Position: refs/heads/master@{#10196}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| e0bce240652bcf4031ae61985938e968469d3f53 |
|
05-Oct-2015 |
perkj <perkj@webrtc.org> |
VideoCapturerAndroid: Add custom nativeCreateVideoCapturer()
This CL shouldn't make any functional changes. It adds a new VideoCapturerAndroid.nativeCreateVideoCapturer() instead of always using VideoCapturer.nativeCreateVideoCapturer(). The purpose is to simplify androidvideocapturer_jni and VideoCapturerAndroid.create(). This way, it is possible to use the ctor instead of VideoCapturerAndroid.init() to initialize variables, and they can be made final etc.
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1360173002 .
Cr-Commit-Position: refs/heads/master@{#10171}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| b5815c801362c98d99668924a8d3ba763ec36a04 |
|
29-Sep-2015 |
magjed <magjed@webrtc.org> |
Revert of Android VideoCapturer: Send ByteBuffer instead of byte[] (patchset #1 id:1 of https://codereview.webrtc.org/1372813002/ )
Reason for revert:
The top row in the video stream from the camera is messed up. The byte[] pointer is not the same as GetDirectBufferAddress() apparently.
Original issue's description:
> Android VideoCapturer: Send ByteBuffer instead of byte[]
>
> The purpose with this CL is to replace GetByteArrayElements() and ReleaseByteArrayElements() with GetDirectBufferAddress().
>
> R=hbos@webrtc.org
>
> Committed: https://crrev.com/cb3649b40b3fd6d5bbb0a92003b717e46ce90924
> Cr-Commit-Position: refs/heads/master@{#10091}
TBR=hbos@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1377783002
Cr-Commit-Position: refs/heads/master@{#10103}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| cb3649b40b3fd6d5bbb0a92003b717e46ce90924 |
|
28-Sep-2015 |
Magnus Jedvert <magjed@webrtc.org> |
Android VideoCapturer: Send ByteBuffer instead of byte[]
The purpose with this CL is to replace GetByteArrayElements() and ReleaseByteArrayElements() with GetDirectBufferAddress().
R=hbos@webrtc.org
Review URL: https://codereview.webrtc.org/1372813002 .
Cr-Commit-Position: refs/heads/master@{#10091}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| f706c8ae914da976f16205ff13d15b1a28ead8fd |
|
23-Sep-2015 |
Magnus Jedvert <magjed@webrtc.org> |
VideoCapturerAndroid: Fix threading issues
This CL makes the following changes:
* Instead of creating a new thread per startCapture()/stopCapture() cycle, VideoCapturerAndroid has a single thread that is initialized in the constructor and kept during the lifetime of the instance. This is more convenient because then it is always possible to post runnables without if-checks. This way, a lot of synchronize statements can be removed. Also, when the camera thread is preserved after stopCapture() it is possible to post late returnBuffer() calls to the correct thread.
* FramePool now enforces single thread use and returnBuffer() calls are posted to the camera thread. This is important because the camera should only be used from one thread, and we call camera.addCallbackBuffer() in returnBuffer().
* switchCamera() no longer returns false on failure, but instead signals the result via the callback.
* Update the test testCaptureAndAsyncRender() - it's not a valid use case to have outstanding frames when calling PeerConnectionFactory.dispose(). Instead, the renderer implementations should have release() functions that block until all frames are returned. The release() functions need to be called in the correct order with PeerConnectionFactory.dispose() last.
BUG=webrtc:4909
R=hbos@webrtc.org, perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1350863002 .
Cr-Commit-Position: refs/heads/master@{#10025}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 91d6edef35e7275879c30ce16ecb8b6dc73c6e4a |
|
17-Sep-2015 |
henrikg <henrikg@webrtc.org> |
Add RTC_ prefix to (D)CHECKs and related macros.
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.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| c464f504dcb40ad40b5258875493f12783bd5fda |
|
25-Aug-2015 |
Magnus Jedvert <magjed@webrtc.org> |
AndroidVideoCapturerJni: Fix threading issues
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}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| b69ab79338bff71ea411b82f3dd59508617a11d5 |
|
22-Jul-2015 |
magjed <magjed@webrtc.org> |
VideoCapturerAndroid: Add function to change capture format while camera is running
Review URL: https://codereview.webrtc.org/1178703009
Cr-Commit-Position: refs/heads/master@{#9608}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 2b679250fbd50b3c8d9ac266a42fbc8a1bd84167 |
|
15-Jun-2015 |
Åsa Persson <asapersson@webrtc.org> |
VideoCapturerAndroid: Add possibility to request a new resolution from the video adapter.
BUG=
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1178643006.
Cr-Commit-Position: refs/heads/master@{#9434}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 2f5be9ad630dfe499a3e2fc64c6178143acddb84 |
|
19-May-2015 |
Alex Glaznev <glaznev@google.com> |
Improve Android camera error handling.
- Set Camera.ErrorCallback callback when opening camera to
receive camera server error notifications.
- Allow user to provide interface for handling camera errors
happening on camera thread.
- Run camera observer on camera thread and monitor camera fps
and amount of callback buffers, print statistics and report error
if camera stops generating frames.
- Query camera formats starting from front camera instead of back
camera to detect camera failures as fast as possible.
- Change all DCHECK to CHECK in androidvideocapturer.cc to detect
camera error on release builds.
- Plus adding some extra logging.
R=hbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52519004
Cr-Commit-Position: refs/heads/master@{#9221}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| c4905fb72a01d5fe5788cc33d847c31b039468e3 |
|
21-Apr-2015 |
Alex Glaznev <glaznev@google.com> |
Fix race condition in Android camera JNI code.
AndroidVideoCapturerJni dtor is called on signaling thread
and may destroy JNI global refs while processing late camera
frame arrival in ReturnBuffer_w() in worker thread.
Fix this by waiting for all function invoked on worker thread
to complete in camera JNI dtor.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49099004
Cr-Commit-Position: refs/heads/master@{#9037}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 8c054154daa17676ad32ca6554025b7a09670410 |
|
20-Apr-2015 |
Alex Glaznev <glaznev@google.com> |
Add extra logging for Android camera JNI layer.
Plus enabled checks for release version.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46939004
Cr-Commit-Position: refs/heads/master@{#9034}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 49a862ec4cba4060f9897ceb24b215d316bc0544 |
|
07-Apr-2015 |
Per <perkj@chromium.org> |
Return pending buffers to Java VideoCapturerAndroid if camera is stopping
BUG=4510
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45009005
Cr-Commit-Position: refs/heads/master@{#8935}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 3354419a2d53c3bfee8077cfbb0d86022b03e94a |
|
02-Apr-2015 |
Per <perkj@chromium.org> |
Zero copy AndroidVideeCapturer.
This cl uses the YV12 buffers from Java without a copy if no rotation is needed. Buffers are returned to the camera when the encoder and renderers no longer needs them.
This add a new frame type WrappedI420Buffer based in that allows for wrapping existing memory buffers and getting a notification when it is no longer used.
AndroidVideoCapturer::FrameFactory::CreateAliasedFrame wraps frame received from Java. For each wrapped frame a new reference to AndroidVideoCapturerDelegate is held to ensure that the delegate can not be destroyed until all frames have been returned.
Some overlap exist in webrtcvideoframe.cc and webrtcvideengine.cc with https://webrtc-codereview.appspot.com/47399004/ that is expected to be landed before this cl.
BUG=1128
R=glaznev@webrtc.org, magjed@webrtc.org
TBR=mflodman@webrtc.org // For changes in webrtc/common_video/video_frame_buffer
Review URL: https://webrtc-codereview.appspot.com/49459004
Cr-Commit-Position: refs/heads/master@{#8923}
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 41d8fda12dbd1f47a4eea7e5b9995bff07bad2d8 |
|
27-Feb-2015 |
perkj@webrtc.org <perkj@webrtc.org> |
VideoCapturerAndroid allocates direct buffers so that the frame buffers can be used in C++ without a copy. However byte[] array = ByteBuffer.array() seems to point to the beginning of the underlaying buffer and that is what the camera fills. But it turns out that ByteBuffer.arrayOffset() returns an offset and it seems like the pointer returned by jni->GetDirectBufferAddress(j_frame). This cl reverts back to pass the byte[] to c++ and use jni->GetByteArrayElements to get the address of the buffer.
R=glaznev@webrtc.org, magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35349004
Cr-Commit-Position: refs/heads/master@{#8535}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8535 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 112f127170193bf022565b112b03827c025168b6 |
|
25-Feb-2015 |
perkj@webrtc.org <perkj@webrtc.org> |
Refactor how VideoCapturerAndroid delivers frames and is stopped.
With this cl, video buffers are now allocated using direct buffers.
These buffers are guaranteed to live as long as the capturer is running.
We can now post frames in c++ from the Java thread to the c++ worker thread and let c++ post the buffers back when it has finished
processing them.
This cl also reverts back to make Stop asynchronouse so that it is guaranteed that the c++ worker thread is not used and no frames are delivered to VideoCapturerAndroid after Stop completes.
BUG=4318
TESTED= On a N5, N6, N9 and Samsung device.
R=glaznev@webrtc.org, magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43369004
Cr-Commit-Position: refs/heads/master@{#8493}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8493 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 3db042e2f09f1df7d8b5d40f30766f780848ecd9 |
|
19-Feb-2015 |
perkj@webrtc.org <perkj@webrtc.org> |
Stop AndroidVideoCapturer asynchronously.
The purpose is to avoid a deadlock between the C++ thread calling Stop and the Java thread that provides video frames.
BUG=4318
R=glaznev@webrtc.org, magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35249004
Cr-Commit-Position: refs/heads/master@{#8425}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8425 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|
| 96e4db9bea49cf096044c89c94778bff525362ba |
|
13-Feb-2015 |
perkj@webrtc.org <perkj@webrtc.org> |
Split peerconnection_jni.cc into separate files.
For now:
java_helpers - JNI convenience functions etc. Can in theory be moved to libjingle / webrtc general one day.
classreferenceholder - app/webrtc specific Java class loader.
androidvideocapturer_jni - the jni part of the video capturer I added.
peerconnection_jni - all the rest.
This also move all jni specifics into ns webrtc_jni to avoid naming collision.
R=glaznev@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38099004
Cr-Commit-Position: refs/heads/master@{#8363}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8363 4adac7df-926f-26a2-2b94-8c16560cd09d
/external/webrtc/talk/app/webrtc/java/jni/androidvideocapturer_jni.cc
|