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}
The reason we want to use EGL14 is to be able to use EGLExt.eglPresentationTimeANDROID when writing textures to MediaEncoder.
BUG=webrtc:4993
TBR=glaznew@webrtc.org
Review URL: https://codereview.webrtc.org/1461083002
Cr-Commit-Position: refs/heads/master@{#10864}
This cl make it possible for the hw video encoder to downscale a texture image before encoding. The purpose is to allow downscaling if the quality is too bad at the current resolution.
BUG=webrtc:4993
R=magjed@webrtc.org, pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1470043002 .
Cr-Commit-Position: refs/heads/master@{#10804}
This makes it clearer this code not meant to be used as an API.
I could not find any use of this in downstream code.
BUG=webrtc:5095
TESTED=git cl try -c --bot=android_compile_rel --bot=linux_compile_rel --bot=win_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
R=stefan@webrtc.orgTBR=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1440873005 .
Cr-Commit-Position: refs/heads/master@{#10699}
Not fully tested yet. Verified in test loopback application
with fake VP9 codec factory.
Assume that encoder generates bitstream in non flexible mode with
one temporal and one spatial layers.
R=magjed@webrtc.org
Review URL: https://codereview.webrtc.org/1451953002 .
Cr-Commit-Position: refs/heads/master@{#10695}
This reverts commit 12f680214e28dc5f0a13ac8afc0d1445f89e67e6.
Original cl in https://codereview.webrtc.org/1396073003/
Prepare MediaCodecVideoEncoder for surface textures.
This refactors MediaVideoEncoder to prepare for adding support to encode from textures. The C++ layer does not have any functional changes.
- Moves ResetEncoder to always work on the codec thread
- Adds use of ThreadChecker.
- Change Java MediaEncoder.Init to return true or false and introduce method getInputBuffers.
- Add simple unit test for Java MediaCodecVideoEncoder.
The pure revert of the revert is in patchset 1.
Patchset 2, moves getting the input buffer to before storing pending timestamps etc to fix b/24984012.
BUG=webrtc:4993 b/24984012
Review URL: https://codereview.webrtc.org/1406203002
Cr-Commit-Position: refs/heads/master@{#10622}
This reverts commit 90754174d98d6b71fd4aaed897bd54980f7e59c4.
Revert "Fix use of scaler in MediaCodecVideoEncoder"
This reverts commit ec93628e75fdb81f23635b39b5f3da846bcefd21.
R=magjed@webrtc.orgTBR=glaznev@webrtc.org
BUG=webrtc:4993 b/24984012
Review URL: https://codereview.webrtc.org/1407263002 .
Cr-Commit-Position: refs/heads/master@{#10300}
This make small refactorings to MediaVideoEncoder to prepare for adding support to encode from textures. The C++ layer does not have any functional changes.
- Moves ResetEncoder to always work on the codec thread
- Adds use of ThreadChecker.
- Change Java MediaEncoder.Init to return true or false and introduce method getInputBuffers.
- Add simple unit test for Java MediaCodecVideoEncoder.
BUG=webrtc:4993
Review URL: https://codereview.webrtc.org/1396073003
Cr-Commit-Position: refs/heads/master@{#10250}
Android hardware H.264 seems to keep a steady high-QP flow instead of
dropping frames, so framedrops aren't sufficient to detect a bad state
where downscaling would be beneficial.
BUG=webrtc:4968
R=magjed@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1364253002 .
Cr-Commit-Position: refs/heads/master@{#10078}
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}
- 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
