SDK / exoplayer

Issue: #6845
PiperOrigin-RevId: 288688716

Use these to migrate the last WebvttDecoderTest method to SpannedSubject

PiperOrigin-RevId: 288688620

PiperOrigin-RevId: 288667790

Issue: #4078
PiperOrigin-RevId: 288651166

Also remove most classes from the nullness blacklist

PiperOrigin-RevId: 288494712

PiperOrigin-RevId: 288476415

Suppression added in https://github.com/google/ExoPlayer/commit/6f9baffa0cc7daf8cbfd5e1f6c55a908190d2041

PiperOrigin-RevId: 288475120

These make the interesting bits of each assertion harder to follow imo.

Also remove all the assertWithMessage() calls at the same time, Olly
convinced me these are rarely useful since you can click from the stack
trace to the failing line in the IDE.

PiperOrigin-RevId: 288470704

PiperOrigin-RevId: 288468497

PiperOrigin-RevId: 288464154

As discussed with Olly, these don't add much info and are liable
to go stale.

PiperOrigin-RevId: 288463027

PiperOrigin-RevId: 288304477

PiperOrigin-RevId: 288292488

PiperOrigin-RevId: 288285953

- Simulate IO exceptions in the test using FlacBinarySearchSeeker for
  seeking in FlacExtractorTests. This makes the test slower but covers
  more test cases.

PiperOrigin-RevId: 288285057

PiperOrigin-RevId: 288280500

There's currently no rendering support for ruby text in SubtitleView
or SubtitlePainter, but this does have a visible impact with the
current implementation by stripping the ruby text from Cue.text
meaning it doesn't show up at all under the 'naive' rendering.
This is an improvement over the current behaviour of including
the ruby text in-line with the base text (no rubies is better than
wrongly rendered rubies).

PiperOrigin-RevId: 288280416

PiperOrigin-RevId: 288280332

This will be used when parsing Ruby info from WebVTT and TTML/IMSC
subtitles.

PiperOrigin-RevId: 288280181

PiperOrigin-RevId: 288274998

This typo was introduced in https://github.com/google/ExoPlayer/commit/ddb70d96ad99f07fe10f53a76ce3262fe625be70
when migrating a static method with parameter `durationUs` to an
instance method where the correct field to use was `blockDurationUs`
(but `durationUs` also exists).

The test that catches this was only added in https://github.com/google/ExoPlayer/commit/45013ece1e3fe054ff8960355a89559241eeb288 (and
therefore configured with the wrong expected output data).

issue:#6833
PiperOrigin-RevId: 288274197

Remove unused method
MediaCodecRenderer#getDequeueOutputBufferTimeoutUs().

PiperOrigin-RevId: 288005572

PiperOrigin-RevId: 287999703

It's not used. I was trying to work out how to correctly cascade my
text-combine-upright styling, but deleting the method seemed easier...

PiperOrigin-RevId: 287989480

I decided the flags bit was a bit unclear so I played around with this

It's also needed for more 'complex' assertions like colors - I didn't
want to just chuck in a fourth int parameter to create:
hasForegroundColorSpan(int start, int end, int flags, int color)

PiperOrigin-RevId: 287989424

Relying on the precedence of spans seems risky - I can't find it
defined anywhere. It might have changed in Android 6.0?
https://stackoverflow.com/q/34631851

PiperOrigin-RevId: 287989365

PiperOrigin-RevId: 287973192

Issue: #6552
PiperOrigin-RevId: 287964221

PiperOrigin-RevId: 287854701

Issue: #5789
PiperOrigin-RevId: 287828559

Issue: #6779
PiperOrigin-RevId: 287828273

Issue: #6266
PiperOrigin-RevId: 287821640

Issue: #6602
PiperOrigin-RevId: 287816831

It's unreliable for at least one IMA ADPCM file I've found.
Calculating the blockIndex to seek to using exact properties
also seems more robust.

Note this doesn't change anything for the existing PCM test,
since averageBytesPerSecond is set correctly. It does make
a difference for an upcoming IMA ADPCM test though.

PiperOrigin-RevId: 287814947

PiperOrigin-RevId: 287810018

An experiment with this algorithm didn't show positive results. We can
therefore keep the simpler default algorithm.

Startblock:
  <unknown commit> is submitted
PiperOrigin-RevId: 287807538

PiperOrigin-RevId: 287669425

Issue: #6733
PiperOrigin-RevId: 286621715

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