Extract supplemental data from block additions in WebM/Matroska.
Allow storing supplemental data alongside samples in the SampleQueue and write
it as a separate field in DecoderInputBuffers.
Handle supplemental data in the VP9 extension by propagating it to the output
buffer.
Handle supplemental data for HDR10+ in MediaCodecVideoRenderer by passing it to
MediaCodec.setParameters, if supported by the component.
PiperOrigin-RevId: 264582805
I think we need to start clearing the holder as part of the
DRM rework. When we do this, it'll only be valid to read
from the holder immediately after it's been populated.
PiperOrigin-RevId: 262362725
In surface YUV output mode the width/height fields of the VpxOutputBuffer were
never populated. Fix this by adding a new method to set the width/height and
calling it from JNI like we do for GL YUV mode.
PiperOrigin-RevId: 250449734
Update configuration script to use an external build, so we can remove use of
isysroot which is broken in the latest NDK r19c. Also switch from gnustl_static
to c++_static so that ndk-build with NDK r19c succeeds.
Issue: #5922
PiperOrigin-RevId: 250287551
This is part of the public API and the underscored versions
weren't intended to be used outside the library.
Also updating the external instructions to checkout the version
of libvpx that supports this macro for this particular constant.
#codehealth
PiperOrigin-RevId: 242170926
There were some edge cases in which we'd forget to release DRM
sessions. For example if we read a format and acquired a
pendingDrmSession (in onInputFormatChanged), then immediately
read another format and overwrote pendingDrmSession, we'd
forget to release the one that's been overwritten.
This change hopefully makes release much clearer. We keep a list
of all drm sessions we're currently holding. Whenever we update
either drmSession or pendingDrmSession, we release any other
sessions that are in the list.
PiperOrigin-RevId: 228905465
Turn on flag to enable fast loop filtering. This improves
multi-threaded decode performance by starting loop filtering early
if there are free threads available to do so.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218239442
Renamed to stop collision between the ExoV1 and ExoV2 implementation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217348150
With default of value set to -1, every single dropped frame is reported because of expression: if (droppedFrames >= maxDroppedFramesToNotify) { maybeNotifyDroppedFrames(); }
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213502573
Not having this annotation may cause Kotlin implementations to fail.
Issue:#4802
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212980643
Power Comparison:
TextureView 1080p 720p
H264 HW 498, 496 507, 478
VP9 RGB 1050, 1104 1185, 1152
VP9 ANativeWindow 1070, 985 700, 674
GLSurfaceView
VP9 YUV 1075, 1112 716, 635
SurfaceView
H264 HW 419, 409 397, 377
VP9 RGB 1044, 1139 654, 671
VP9 ANativeWindow 975, 835 617, 623
VP9 MediaCodec 683, 679 488, 476
Measures average current drawn mAH on a Nexus 6 at full brightness from time t=3 to t=95 seconds. The same clip was used for all tests. Two measurements were taken for each category.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203847744
Video renderers assume that the player position is advancing linearly while in
the started state. MediaCodecVideoRenderer schedules frames for rendering in the
future in the expectation that the player position is advancing.
This assumption is not currently true when using a position from the AudioTrack:
the player position can be fixed for (in the worst case) up to about 100 ms
before it starts increasing. This leads to an effect where the first frame is
rendered then a few other frames are rendered, then there's a pause before
frames start being rendered smoothly.
Work around this issue by checking whether the position has started advancing
before scheduling frames to be rendered in the future.
It might be preferable to make the audio renderer only become ready when its
timestamp can start advancing, but this is likely to be complicated.
Issue: #3841
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190937429
Also remove logic for tracking the next output buffer in LibvpxVideoRenderer, as
this allowed many consecutive frames to be rendered that were actually late
after dropping to keyframe. It looks better to show frames at a consistent
100 ms rate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188144739
The pending exception will be thrown upon returning to Java
from native, but we should return early rather than continuing
to execute the native method to the end so as to avoid undefined
behavior. Note that the return value is irrelevant (because the
pending exception will be thrown).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184119606
Try to delay failure for as long as possible. That is, propagate
DRM session failures only after an encrypted buffer arrives or clear
sample playback without session is not allowed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183076348
Make LibvpxVideoRenderer non-final and add protected methods to match
MediaCodecVideoRenderer.
Reorganize methods to separate BaseRenderer, protected and internal methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181320714
Now this counter includes input buffers too, which are dropped as part of
skipping to keyframes for catch up.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171119930
In out libvpx extension, currently we always call vpxGetFrame and copy the data
from the native decoder to output frame. However, if the inputBuffer has
isDecoderOnly set, we can avoid populating the output buffer, but only setting
BUFFER_FLAG_DECODE_ONLY.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170318527
Using the same sampler introduced some minor horizontal scratches.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167347995
I think they're excessively sized also, but changing that
is a little more risky. And we should look at investigating
the input buffer size for all our decoder extensions,
rather than just this one.
Issue: #3120
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164234087
These changes are in part related to handling playback of mixed clear
and encrypted content, where we might want to use a secure decoder
throughout, but only have drm init data and only care about the state
of the DrmSession during playback of encrypted parts.
- requiresSecureDecoderComponent became unnecessary when we added
ExoMediaCrypto, which provides a layer in which requiresSecureDecoderComponent
can be overridden.
- Relaxed requirements for obtaining the MediaCrypto. It's helpful
to allow retrieval in the error state, since it can be used to
instantiate a decoder and play clear samples.
- Deferred throwing of errors in renderer implementations. As long as
we can get a MediaCrypto, we should init the codec. We can also
play clear samples without failing if playClearSamplesWithoutKeys is
true, regardless of the errors state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160536365
Disable libjpeg dependency when building libyuv.
Partially fixes Github Issue #2661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154179126
Fixes the following issues:
1. When a surface is set, it's expected that the renderer will
notify video size + when a frame is rendered to it. This is true
even if the surface isn't changing. Right now this is achieved
by setting renderedFirstFrame to false, but this is problematic
in the case that the surface isn't changing because (a) it will
force rendering of a subsequent frame to the output even when
paused, which is incorrect, and (b) isReady will return false
until this occurs.
2. When the surface really is changing, isReady can return false
until the first frame has been rendered into the new surface, which
will break seamless surface switching. This change allows isReady
to return true up to allowedJoiningTimeMs for this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154171111
This change also ensures that format changes are read whilst the
renderer is enabled but without a codec. This is necessary to
ensure the drm session is updated (or replaced).
Updating the format is also needed so that the up-to-date format is
used in the case that the codec is initialized later due to the
surface being set. Previously, if an ABR change occurred between
the format being read and the surface being attached, we would
instantiate the codec and then immediately have to reconfigure it
when as a result of reading the up-to-date format. For a non-adaptive
codec this resulted in the codec being immediately released and
instantiated again!
Issue: #2582
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151608096
This is the boring part of a larger change that fixes
how video renderers behave when surfaces are attached and
detached whilst they're enabled or started.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151563031
Update the filter that selects %.asm.[sS] and remove the
"remove duplicates" step in the android makefile.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150728021
This change reduces the final .so size by ~9% for armv7/arm64.
Arch : Size_before : Size_after
armeabi-v7a : 300548 : 271876
arm64-v8a : 247632 : 223056
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150648668
Fixes github issue #2339 [https://github.com/google/ExoPlayer/issues/2339]
Fixes github issue #2551 [https://github.com/google/ExoPlayer/issues/2551]
* Update the instructions to check out specific versions of libvpx and
libyuv that are known to work with our build scripts.
* Forcing a particular version of libyuv because recent versions of
libyuv are dependent on libjpeg (which isn't needed for the purpose
of this extension).
* Going forward, let's keep generate_libvpx_android_configs.sh in sync
with whatever version is specifed in the instructions in README.md
(as of now it is v1.6.1).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150208517
Pending: Convert BT2020 to DCI-P3 before render.
I'll add the same code to V2 after initial review.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148403349
I'm going to introduce an EmptySampleStream that will be used in
some cases in conjunction as part of 608/EMSG support. This change
avoids EmptySampleStream having to provide a dummy format.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148383831
- Add proguard rules for libraries/extensions into .aar files
- Add proguard rules to retain CEA608/708 decoder constructors
- Remove lots of default config from gradle files
- Remove disabling of abort on lint error
- Enable optimizations on release builds of demo app
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144350233
- Also make some of the naming more concise + misc style cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132899979
