SDK / exoplayer

issue:#7160
PiperOrigin-RevId: 303747338

CharSequence is used by Notification builders and allows to set Spannable text.
It's the base interface of the String class, so apps wouldn't be break after
the update.

PiperOrigin-RevId: 303731890

Issue: #6671
PiperOrigin-RevId: 303364788

Issue: #7046
PiperOrigin-RevId: 303354941

- They are always listed with their canonical names
- Considering aliases means that blacklisting a decoder can end up
  not actually blacklisting it, since it may still be accessible
  via an alias. It also means that our decoder fallback logic can
  end up falling back to a decoder that we've already tried!

PiperOrigin-RevId: 303348297

Issue: #7141
PiperOrigin-RevId: 303334072

PiperOrigin-RevId: 303316976

issue:#7122
PiperOrigin-RevId: 303154493

This is less confusing than having audio processing functionality (e.g., playback
speed adjustment) just "not work" for some pieces of media.

If this change is merged, I will update #6749 to also track making DefaultAudioSink
intelligently enable/disable float output depending on how the audio processors are
configured.

Issue: #7134
PiperOrigin-RevId: 302871568

It's incorrect to use an AudioFormat returned from AudioProcessor.configure
unless the AudioProcessor is active.

Issue: #7134
PiperOrigin-RevId: 302674132

This is a no-op for DefaultAudioSink for now, because DefaultAudioSink
currently disables processing anyway if the input uses ENCODING_PCM_FLOAT.

Issue: #7134
PiperOrigin-RevId: 302670534

Issue: #7129
PiperOrigin-RevId: 302660343

If the start time of the edit falls within a sample, start from that
sample rather than the next one. This ensures playback can start from
the correct point if the sample is a keyframe, rather than having to
start from the next one.

Issue: #7133
PiperOrigin-RevId: 302639115

Add a test for this case, and extend the existing tests to ensure the
hour is parsed when it's present.

issue:#7122
PiperOrigin-RevId: 302472213

#exo-offload

PiperOrigin-RevId: 302403507

PiperOrigin-RevId: 302345647

- Make sure logging of UnknownHostException indicates the failure reason
- Indent stack traces inside event blocks in EventLogger
- Don't log media URLs

PiperOrigin-RevId: 302007601

PiperOrigin-RevId: 301996778

Issue: #6761
PiperOrigin-RevId: 300715682

PiperOrigin-RevId: 300313753

PiperOrigin-RevId: 300330109

Requested by https://github.com/google/ExoPlayer/issues/7058.
Additionally move one of the common option in COMMON_OPTIONS.

PiperOrigin-RevId: 299862479

PiperOrigin-RevId: 299357049

PiperOrigin-RevId: 298544278

PiperOrigin-RevId: 297187116

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

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