SDK / exoplayer

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().

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

This avoids the issue of whether it is defined behaviour to cast an
arbitrary int (or even intptr_t) value to a void* pointer. This is the
original approach used before commit 0915998a.

PiperOrigin-RevId: 295552115

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

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: 295211245

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

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: 293709205

issue:#6885
PiperOrigin-RevId: 295931197

The part about leaving the pending trim start byte count unmodified
if the processor was just configured is not correct.

PiperOrigin-RevId: 295745371

PiperOrigin-RevId: 295692163

r2.11.3

Issue: #6981
PiperOrigin-RevId: 295579872

CryptoInfo.iv length is always 16. When the actual initialization vector
is shorter, zero out the trailing bytes.

Issue: #6982
PiperOrigin-RevId: 295575845

PiperOrigin-RevId: 295540885

PiperOrigin-RevId: 295695297

PiperOrigin-RevId: 294503035

r2.11.2

PiperOrigin-RevId: 294193213

Demonstrates rendering to a GLSurfaceView while applying a GL shader.

Issue: #6920
PiperOrigin-RevId: 293551724

Issue: #6951
PiperOrigin-RevId: 294187695

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

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

Issue: #6903
PiperOrigin-RevId: 292884280

PiperOrigin-RevId: 292542298

Issue: #6938
PiperOrigin-RevId: 292415853

PiperOrigin-RevId: 292347360

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

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

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

OkHttp 3.12.7 introduced a regression, which was fixed in 3.12.8.

PiperOrigin-RevId: 291695577

Currently we only do this for the main sample URI, not for subtitles.
So pairing a web-based video file with a local subtitle file on a fresh
install just throws a 'permission denied' exception.

PiperOrigin-RevId: 290794091

PiperOrigin-RevId: 290600248

All these genres are currently causing a warning and are not added to the Metadata.Entry.

PiperOrigin-RevId: 290594810

+ force arm (over thumb) mode for 32-bit builds

-O2 improves performance ~30-40% over the default -Oz depending on the
resolution; this is similar to what is done for vp9 which uses -O3.

PiperOrigin-RevId: 290318121

PiperOrigin-RevId: 290276507

- Add additional Listener methods to DownloadManager, to inform of
  changes to whether the downloads are paused or waiting for requirements.

- Only schedule the Scheduler if we really are waiting for requirements.

- Only restart the service if we're no longer waiting for requirements,
  and if there are queued downloads that will now be restarted.
  Previously the service would be restarted whenever the requirements
  were met, regardless of whether there was any work to do.

- Restart service if it might be stopping, as well as if it's already
  stopped. Also restart service if there's a download state change to a
  state for which the service should be started, if.

Issue: #6798
PiperOrigin-RevId: 290270547

PiperOrigin-RevId: 290269098