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
Review URL: https://codereview.webrtc.org/1378033003 .
Cr-Commit-Position: refs/heads/master@{#10203}
This CL separates the types and code paths for textures vs byte buffers in MediaCodecVideoDecoder.dequeueOutputBuffer() and MediaCodecVideoDecoder::DeliverPendingOutputs(). The purpose is to prepare for lifetime management of textures received from the SurfaceTexture.
This CL is a part of the plan in https://codereview.webrtc.org/1357923002/.
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1379383002
Cr-Commit-Position: refs/heads/master@{#10156}
This CL should not change the behaviour of the decoder. The purpose is to prepare for lifetime management of textures received from the SurfaceTexture. The main change is to only use exceptions for error signaling in MediaCodecVideoDecoder.dequeueOutputBuffer() and MediaCodecVideoDecoder.releaseOutputBuffer(), not both exceptions and error return values.
BUG=webrtc:4993
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/1383983003 .
Cr-Commit-Position: refs/heads/master@{#10148}
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}
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}
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}
- Remove an option to use MediaCodec SW decoder from Java layer.
- Better handling Java exceptions in JNI - detect exceptions
and either try to reset the codec or fallback to SW decoder.
- If any error is reported by codec try to fallback to SW
codec for VP8 or reset decoder and continue decoding for H.264.
- Add more logging for error conditions.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1178943007.
Cr-Commit-Position: refs/heads/master@{#9431}
TextureVideoFrame is currently an empty shell that only provides a convenience constructor of I420VideoFrame with a texture buffer. This CL moves that constructor, and all unittests, of TextureVideoFrame into the base class. Then it's possible to completely remove TextureVideoFrame and all its files. Also, there is no point in having I420VideoFrame virtual anymore.
R=pbos@webrtc.org, perkj@webrtc.org, stefan@webrtc.org
TBR=mflodman
Review URL: https://webrtc-codereview.appspot.com/40229004
Cr-Commit-Position: refs/heads/master@{#8629}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8629 4adac7df-926f-26a2-2b94-8c16560cd09d
- Qualcomm H.264 HW decoder on KK and older requires
a few video frames before it can generate output. Increase
maximum allowed pending frames for H.264 decoder to 30.
Plus changes in the logging to track decoder buffers
timestamps.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36319004
Cr-Commit-Position: refs/heads/master@{#8490}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8490 4adac7df-926f-26a2-2b94-8c16560cd09d
- Allow to configure MediaCodec Java wrapper to use VP8
and H.264 codec.
- Save H.264 config frames with SPS and PPS NALUs and append them to every key frame.
- Correctly handle the case when one encoded frame may generate several output NALUs.
- Add code to find H.264 start codes.
- Add a flag (non configurable yet) to use H.264 in AppRTCDemo.
- Improve MediaCodec logging.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43379004
Cr-Commit-Position: refs/heads/master@{#8465}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8465 4adac7df-926f-26a2-2b94-8c16560cd09d
