SDK / exoplayer

*** Original commit ***

Disable test coverage again

https://issuetracker.google.com/issues/37019591 causes local variables can't be found while debugging.

***

PiperOrigin-RevId: 280666758

Also remove the "do we really need to do this" comment for AAC.
Parsing from codec specific data is likely to be more robust, so
I think we should continue to do it for formats where we've seen
this problem.

Issue: #6648
PiperOrigin-RevId: 280575466

PiperOrigin-RevId: 280573887

Previously the renderer EOS (aka last frame rendered), was reported as soon
as the last encoded frame was queued in the codec renderer.
This leaded to EOS reported too early.

PiperOrigin-RevId: 280456277

This speeds up downloads where segments have the same URL with different
byte ranges. We limit the merged segments to 20 seconds to ensure the download
progress of demuxed streams is roughly in line with the playable media duration.

Issue:#5978
PiperOrigin-RevId: 280410761

PiperOrigin-RevId: 280176216

PiperOrigin-RevId: 280167223

Clear state for one mode when entering the other in both SimpleExoPlayer
and SimpleDecoderVideoRenderer. The latter is redundant for the case of
renderers that are used inside SimpleExoPlayer, but seems nice to have.

- Entering Surface mode means receiving a non-null Surface, SurfaceHolder
  or TextureView in SimpleExoPlayer, or a non-null Surface in
  SimpleDecoderVideoRenderer.
- Entering VideoDecoderOutputBufferRenderer means receiving a non-null
  VideoDecoderOutputBufferRenderer in SimpleExoPlayer and
  SimpleDecoderVideoRenderer.

PiperOrigin-RevId: 280155151

Also add some missing Nullable annotations.

PiperOrigin-RevId: 280150512

This aligns the method naming and Javadoc. The only remaining
inconsistency I can see is that the initial reference count for
DrmSession is 0 rather than 1. Unfortunately I think it's not
trivial to get these aligned, because DefaultDrmSessionManager
relies on being able to do something between instantiation and
the DrmSession starting to open the session. In practice this
doesn't really matter, since DrmSessions will be obtained via the
manager, which does increment thee reference count to 1 to be
consistent with how ExoMediaDrm acquisition works.

PiperOrigin-RevId: 280136574

PiperOrigin-RevId: 280106092

PiperOrigin-RevId: 280056790

Issue: #6641
PiperOrigin-RevId: 279963739

Issue:#4867
PiperOrigin-RevId: 279928345

PiperOrigin-RevId: 279928178

SSA spec allows the lines in any order, so they must all have an end time:
http://moodub.free.fr/video/ass-specs.doc

The Matroska write-up of SubRip assumes the end time is present:
https://matroska.org/technical/specs/subtitles/srt.html

This will massively simplify merging issue:#6595

PiperOrigin-RevId: 279926730

The handling of times wasn't really clear to me, hopefully this more
exhaustive documentation helps a bit.

Also assert the end timecode is the 'correct' length for the format.

PiperOrigin-RevId: 279922369

PiperOrigin-RevId: 279911378

PiperOrigin-RevId: 279899984

More information:
https://docs.google.com/document/d/16tpK6aXqN68PvTyvt4siM-m7f0NXi_8xEeitLDzr8xY/edit?usp=sharing
Tested:
    TAP --sample ran all affected tests and none failed
    http://test/OCL:279845168:BASE:279870402:1573537714395:80ca701c
PiperOrigin-RevId: 279891832

PiperOrigin-RevId: 279841132

*** Original commit ***

Add CRC-8 method in Util

***

PiperOrigin-RevId: 279733541

PiperOrigin-RevId: 279727618

Use the maximum frame size as the maximum sample size if provided.

PiperOrigin-RevId: 279722820

Issue: #6636
PiperOrigin-RevId: 279666771

To trigger receiving the broadcast it's necessary to idle() the shadow
main looper, which has to be done from the test thread. Therefore this
change removes the send broadcast action and instead sends the broadcast
from the test thread.

PiperOrigin-RevId: 279660935

Android Studio claims this escaping isn't required, but now it's removed this code crashes due to a malformed regex.

PiperOrigin-RevId: 279501823

PiperOrigin-RevId: 279286802

Note: Release notes are not final.
PiperOrigin-RevId: 279125474

PiperOrigin-RevId: 279107241

PiperOrigin-RevId: 279091742

PiperOrigin-RevId: 279088193

Assuming that a flac stream starts with bytes
['f', 'L', 'a', 'C', 0, 0, 0, 0x22] is not always correct as it could
also start with ['f', 'L', 'a', 'C', 0x80, 0, 0, 0x22]
(see https://xiph.org/flac/format.html#metadata_block_streaminfo).

PiperOrigin-RevId: 279080562

More information:
https://docs.google.com/document/d/16tpK6aXqN68PvTyvt4siM-m7f0NXi_8xEeitLDzr8xY/edit?usp=sharing

Tested:
    TAP --sample ran all affected tests and none failed
    http://test/OCL:278915274:BASE:278884711:1573074344615:a6701677
PiperOrigin-RevId: 279080514

- Add @test annotations.
- Fix seeking to ignore potential placeholders
  (see https://xiph.org/flac/format.html#metadata_block_seektable).

PiperOrigin-RevId: 279074092

More information:
https://docs.google.com/document/d/16tpK6aXqN68PvTyvt4siM-m7f0NXi_8xEeitLDzr8xY/edit?usp=sharing

Tested:
    tap_presubmit: http://test/OCL:278683723:BASE:278762656:1573036487314:924e1b0b
    Some tests failed; test failures are believed to be unrelated to this CL
PiperOrigin-RevId: 279034739

PiperOrigin-RevId: 278875587

PiperOrigin-RevId: 278867153

PiperOrigin-RevId: 278835106

PiperOrigin-RevId: 278660557