SDK / exoplayer

PiperOrigin-RevId: 294621946

This is a no-op change and just moves some duplicated logic into the
base class.

PiperOrigin-RevId: 294615218

PiperOrigin-RevId: 294614958

PiperOrigin-RevId: 294613898

- Removes empty <p> tag in javadoc
- Removes incorrect parameter name warnings for var args.

PiperOrigin-RevId: 294555651

Issue: #2863
PiperOrigin-RevId: 294531127

Keeping (Uri) and (Uri, position, length) to avoid needing
Builder for the trivial case.

PiperOrigin-RevId: 294530226

PiperOrigin-RevId: 294520836

PiperOrigin-RevId: 294518763

PiperOrigin-RevId: 294503035

Language is already applicable to image formats as well.
It can also apply to video formats. For example when the
video contains burnt in subtitles. Also, some animation
studios produce multiple variants of animations, in which
text within the scene itself (e.g., a signpost) is
replaced to be language specific.

PiperOrigin-RevId: 294500227

- Replace tests specific to HTTP request headers with tests that
  more generally test constructor correctness.
- Add test specifically around the constructor that infers the
  HTTP method from postBody, since that's a non-trivial bit of
  constructor logic.

Note: In general, I'm not sure this type of test (i.e., testing a
bit of trivial copying through a constructor) is worth the cost
of writing and maintaining them. That said, checking the new
uriPositionOffset is calculated correctly is non-trivial, as is
the HTTP method inference, so keeping them for now.
PiperOrigin-RevId: 294488684

This is a preliminary step toward adding a DataSpec.Builder,
which is needed for sanity when adding DataSpec.customData.

The existing absoluteStreamPosition field is very error prone,
because anyone using a Builder to adjust the request position
will need to remember to adjust two values:

dataSpec
    .buildUpon()
    .setAbsoluteStreamPosition(x)
    .setPosition(x)
    .build();

Furthermore, the difference between position and
absoluteStreamPosition is irrelevant in nearly all cases. In
the core library, the difference is only relevant when initializing
AES encryption/decryption to write/read cache files.

Replacing absoluteStreamPosition with uriPositionOffset will
simplify the code block above to:

dataSpec
    .buildUpon()
    .setPosition(x)
    .build();

PiperOrigin-RevId: 294485644

PiperOrigin-RevId: 294465827

PiperOrigin-RevId: 294441610

Replace Thread with thread on documentation.

PiperOrigin-RevId: 294401357

Add support for asynchronous input buffer queueing in the
MultiLockAsyncMediaCodecAdapter.

PiperOrigin-RevId: 294397811

 - Add method to scale scrubber handle of DefaultTimeBar

PiperOrigin-RevId: 294366734

PiperOrigin-RevId: 294241169

PiperOrigin-RevId: 294239472

Currently, the subset of audio tracks for adaptation is selected
purely based on the size of the subset in the track group, completely
ignoring the previously selected best individual track.

This change ignores all tracks with a different configuration than the
previously selected best track.

PiperOrigin-RevId: 294231806

PiperOrigin-RevId: 294222083

The DedicatedThreadAsyncMediaCodecAdapter supports enqueueing
input buffers in a background Thread.

PiperOrigin-RevId: 294202744

PiperOrigin-RevId: 294193213

Issue: #6951
PiperOrigin-RevId: 294187695

PiperOrigin-RevId: 294184891

PiperOrigin-RevId: 294183213

PiperOrigin-RevId: 294182858

MediaCodecInputBufferEnqueuer wraps MediaCodec queue operations.

PiperOrigin-RevId: 294182717

PiperOrigin-RevId: 294181886

PiperOrigin-RevId: 294179427

PiperOrigin-RevId: 294074348

This allows the file to be created automatically when
FakeExtractorOutput#WRITE_DUMP is true.

PiperOrigin-RevId: 293834547

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

PiperOrigin-RevId: 293781786

PiperOrigin-RevId: 293780365

PiperOrigin-RevId: 293774012

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

PiperOrigin-RevId: 293612280

PiperOrigin-RevId: 293608745