- 30 Mar, 2020 18 commits
-
-
Issue: #6761 PiperOrigin-RevId: 300715682
andrewlewis committed -
PiperOrigin-RevId: 300313753
Oliver Woodman committed -
PiperOrigin-RevId: 300330109
Oliver Woodman committed -
Requested by https://github.com/google/ExoPlayer/issues/7058. Additionally move one of the common option in COMMON_OPTIONS. PiperOrigin-RevId: 299862479
krocard committed -
PiperOrigin-RevId: 299357049
Oliver Woodman committed -
PiperOrigin-RevId: 298544278
Oliver Woodman committed -
PiperOrigin-RevId: 297187116
Oliver Woodman committed -
The release_input_buffer callback will be called when the library is done consuming an "input buffer". The buffer passed into EnqueueFrame must be kept valid until this callback is called. If frame parallel is false, then this callback can be nullptr (in this case the buffer has to be kept valid until the next call to DequeueFrame). If frame parallel is true, this callback cannot be nullptr. PiperOrigin-RevId: 296276083
vigneshv committed -
It's not clear why we're currently outputting the format in both init() and consume() - it seems likely that this was accidentally introduced in <unknown commit> when we started outputting the format in consume() but didn't remove it from init().
Oliver Woodman committed -
1. Have frame buffer callbacks return Libgav1StatusCode instead of int. The 0 (success), -1 (failure) return value convention is less obvious. Note: The callers of frame buffer callbacks, BufferPool::OnFrameBufferSizeChanged() and YuvBuffer::Realloc(), currently return bool, so more work is needed to propagate the frame buffer callbacks' Libgav1StatusCode return value to the Decoder API. 2. Allow the FrameBufferSizeChangedCallback to be omitted if the frame buffer size information is not useful to the application. 3. Remove the old (version 1) frame buffer callback API. Remove the frame buffer callback adaptor. frame_buffer2.h is renamed frame_buffer.h. Libgav1FrameBuffer2 is renamed Libgav1FrameBuffer. GetFrameBufferCallback2 and ReleaseFrameBufferCallback2 are renamed GetFrameBufferCallback and ReleaseFrameBufferCallback. PiperOrigin-RevId: 295971183
olly committed -
Libgav1 recently added the ComputeFrameBufferInfo() and SetFrameBuffer() helper functions for writing frame buffer callbacks. Using them simplifies the Libgav1GetFrameBuffer() function. Also resurrect the AlignTo16() function. PiperOrigin-RevId: 295548330
olly committed -
fixes: gav1_jni.cc:446:25: error: cast from pointer to smaller type 'int' loses information const int buffer_id = reinterpret_cast<int>(buffer_private_data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gav1_jni.cc:730:9: error: cast from pointer to smaller type 'int' loses information reinterpret_cast<int>(decoder_buffer->buffer_private_data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ after https://github.com/google/ExoPlayer/commit/0915998add5918214fa0282a69b50a159168a6d5 PiperOrigin-RevId: 295211245olly committed -
static_cast is more appropriate than reinrerpret_cast for casting from void* to JniContext*. See Section 7.2.1 (page 173) in The C++ Programming Language, 4th Edition and https://stackoverflow.com/questions/310451/should-i-use-static-cast-or-reinterpret-cast-when-casting-a-void-to-whatever PiperOrigin-RevId: 293812940
olly committed -
The new code in Libgav1GetFrameBuffer is copied from libgav1/src/frame_buffer_callback_adaptor.cc. It may become libgav1 utility functions available to libgav1 clients in the future. The Libgav1FrameBuffer struct in the old frame buffer callback API is defined as follows: typedef struct Libgav1FrameBuffer { uint8_t* data[3]; size_t size[3]; void* private_data; } Libgav1FrameBuffer; Copy these three fields to the JniFrameBuffer class as private data members and add the RawBuffer() and Id() getter methods. The existing AlignTo16 function is replaced by the copied Align template function. PiperOrigin-RevId: 293709205olly committed -
issue:#6885 PiperOrigin-RevId: 295931197
ibaker committed -
The part about leaving the pending trim start byte count unmodified if the processor was just configured is not correct. PiperOrigin-RevId: 295745371
andrewlewis committed -
PiperOrigin-RevId: 295692163
olly committed
-
- 18 Feb, 2020 6 commits
-
-
r2.11.3
Oliver Woodman committed -
Oliver Woodman committed
-
Issue: #6981 PiperOrigin-RevId: 295579872
olly committed -
CryptoInfo.iv length is always 16. When the actual initialization vector is shorter, zero out the trailing bytes. Issue: #6982 PiperOrigin-RevId: 295575845
olly committed -
PiperOrigin-RevId: 295540885
kimvde committed -
PiperOrigin-RevId: 295695297
olly committed
-
- 13 Feb, 2020 7 commits
-
-
PiperOrigin-RevId: 294503035
olly committed -
r2.11.2
Oliver Woodman committed -
Oliver Woodman committed
-
PiperOrigin-RevId: 294193213
aquilescanta committed -
Demonstrates rendering to a GLSurfaceView while applying a GL shader. Issue: #6920 PiperOrigin-RevId: 293551724
andrewlewis committed -
Issue: #6951 PiperOrigin-RevId: 294187695
aquilescanta committed -
This check is not needed because the FLAC specification does not restrict the sample rate value and because the extension reads files with other sample rates properly. PiperOrigin-RevId: 292909391
kimvde committed
-
- 03 Feb, 2020 2 commits
-
-
This condition is trying to detect when it might be necessary to switch from a non-secure to a secure codec. This is not possible if the DRM session is unchanged, unless a different codec is required for some other reason (e.g., H264 -> H265), which is anyway handled by canKeepCodec below. PiperOrigin-RevId: 292909126
olly committed -
Issue: #6903 PiperOrigin-RevId: 292884280
olly committed
-
- 01 Feb, 2020 6 commits
-
-
PiperOrigin-RevId: 292542298
olly committed -
Issue: #6938 PiperOrigin-RevId: 292415853
bachinger committed -
PiperOrigin-RevId: 292347360
andrewlewis committed -
Passing EXT-X-KEY DrmInitData through the FragmentedMp4Extractor doesn't work for streams with key rotation, because an extractor instance is used for multiple segments, but is only passed the EXT-X-KEY DrmInitData corresponding to the first segment. This change removes passing DrmInitData through the extractor, and instead passes it via FormatAdjustingSampleQueue. This is in-line with how manifest DrmInitData is handled during DASH playbacks. Issue: #6903 PiperOrigin-RevId: 292323429
olly committed -
This is a nice-regardless improvement to SampleQueue, which will likely to used to fix the referenced issue. It makes it possible for SampleQueue subclasses to support dynamic changes to format adjustment in a non-hacky way. Issue: #6903 PiperOrigin-RevId: 292314720
olly committed -
It doesn't seem worth keeping the cap, since the device will presumably stop receiving major version updates at some point anyway. Issue: #6899 PiperOrigin-RevId: 291899439
olly committed
-
- 27 Jan, 2020 1 commit
-
-
Oliver Woodman committed
-