SDK / exoplayer

Where media segments are specified using byte ranges, it makes
sense that a server might return 416 (which we don't consider
for blacklisting) if the segment is unavailable, rather than
the 404 (which we do consider for blacklisting) that we expect
when media segments are only specified using a URL.

Issue: #6775
PiperOrigin-RevId: 286620698

PiperOrigin-RevId: 286586865

PiperOrigin-RevId: 286585978

Issue:#6776

Issue: #6774
PiperOrigin-RevId: 286576383

The Download constructor considers it invalid to have a failure
reason if the download isn't in the failed state. Unfortunately,
calling DefaultDownloadIndex.removeAllDownloads when there's a
failed download will change the state without clearing the reason.
If the downloads are then read back from the DefaultDownloadIndex
we end up violating the Download constructor assertion.

This change clears the failed reason for any existing rows in the
invalid state, and also fixes the root cause that allows invalid
rows to enter the table in the first place.

Issue: #6785
PiperOrigin-RevId: 286576242

Issue: #6774
PiperOrigin-RevId: 286575797

Merge of https://github.com/google/ExoPlayer/pull/6793

PiperOrigin-RevId: 286556008

Without this @Nullable, potential subclasses can't  override the
method to return null if they don't want to use the renderer as a
media clock.

Issue:#6792
PiperOrigin-RevId: 286545736

PiperOrigin-RevId: 286368964

This seems to work with R8 but interact badly with ProGuard.

issue:#6771
PiperOrigin-RevId: 286215262

PiperOrigin-RevId: 286201458

PiperOrigin-RevId: 286156361

R8 does constant folding, so we need to keep buildRawResourceUri
to ensure that resources passed to it are kept.

PiperOrigin-RevId: 286153875

These annotations are compile-only - so we don't mind they're not
accessible at runtime.

PiperOrigin-RevId: 285993063

Issue: #6773
PiperOrigin-RevId: 285990377

PiperOrigin-RevId: 285449865

This indicates the extractor has output a Format with a specified
maxInputSize that's too small. Failing in FakeTrackOutput ensures
this doesn't happen during Extractor tests.

PiperOrigin-RevId: 285776069

Manual rollback of https://github.com/google/ExoPlayer/commit/b3f485d7d9c08e39574b72a949166ee4834c3b24

It's technically possible to output a seekable SeekMap with unknown duration. This can occur if the media defines seek points but doesn't define either the overall duration or the duration of the media from the last seek point to the end.

PiperOrigin-RevId: 285769121

In MatroskaExtractor, if the last cue time exceeds the duration
specified in the header, then we end up generating a negative
duration chunk as the last item in the SeekMap. We should probably
not do this, so drop it instead.

Note: Matroska does have a CueDuration element, but it's not used
in the one problematic file I've found.
PiperOrigin-RevId: 285738418

PiperOrigin-RevId: 285422885

This has been broken since
https://github.com/google/ExoPlayer/commit/c3d6be3afdd7c0ca68dba15e443bc64aa3f61073
and broken for ICY (where I noticed the problem) since
https://github.com/google/ExoPlayer/commit/5695bae9d8fde5e156fd38fa552e266c5611c71f.
ICY symptom is that we see no repeated metadata, because the
Icy-MetaData:1 header doesn't make it to the server so we never get back
icy-metaint.

PiperOrigin-RevId: 285379234

The presentationTimeOffsetMs may be C.TIME_UNSET for VOD content
and shouldn't be used in calculations for the windowStartTime.

PiperOrigin-RevId: 285363095

Issue: #6685
PiperOrigin-RevId: 284736041

r2.11.0

Change FakeAdaptiveMediaPeriod back to this style for consistency.

PiperOrigin-RevId: 284967667

Remove all generic arrays from this class.

FakeAdaptiveMediaPeriod.java:171: warning: [rawtypes] found raw type: ChunkSampleStream
    return new ChunkSampleStream[length];
               ^
  missing type arguments for generic class ChunkSampleStream<T>
  where T is a type-variable:
    T extends ChunkSource declared in class ChunkSampleStream

PiperOrigin-RevId: 284761750

Keyframe was rendered rather than skipped when performing
an exact seek to a non-zero position close to the start of
the stream.

PiperOrigin-RevId: 284798460

PiperOrigin-RevId: 284792946

Issue: #6621
PiperOrigin-RevId: 284743414

Caveats:

- Block additional data is ignored if the block is laced
  and contains multiple samples. Note that this is not
  a loss of functionality (SimpleBlock cannot have block
  additional data, and lacing was previously completely
  unsupported for Block)

- Subrip and ASS samples are dropped if they're in laced
  blocks with multiple samples (I don't think this is
  valid anyway)

Issue: #3026
PiperOrigin-RevId: 284545197

This change constrains the use of sample state member variables to
writeSampleData, finishWriteSampleData and resetWriteSampleData.
Using them elsewhere gets increasingly confusing when considering
features like lacing in full blocks. For example sampleBytesWritten
cannot be used when calling commitSampleToOutput in this case
because we need to write the sample data for multiple samples
before we commit any of them.

Issue: #3026
PiperOrigin-RevId: 284541942

PiperOrigin-RevId: 284509437

For AOSP TV devices that might not pass manual verification.

PiperOrigin-RevId: 284154763

- Remove "lacing" from member variables. They're used even if
  there is no lacing (and the fact that lacing is the way of
  getting multiple samples into a block isn't important).

Issue: #3026
PiperOrigin-RevId: 284152447

- Change sampleHasReferenceBlock to a block reading variable, which is
  what it is (the distinction didn't matter previously, but will do so
  when we add lacing support in full blocks because there wont be a 1:1
  relationship any more.
- Move sampleRead to be a reading state variable.
- Stop abbreviating "additional"

Issue: #3026
PiperOrigin-RevId: 284000937

An I/O error could occur while handling the start of an mdta box, in
which case retrying would cause another ContainerAtom to be added. Fix
this by skipping the mdta header before updating container atoms.

PiperOrigin-RevId: 284000715