SDK / exoplayer

[Problem]
CC1 is shown even when CC2-3-4 is selected

[Solution]
 * use incoming channel and frame information
 * Misc Codes need to handle use Frame information
 * Add checks everywhere

[Test]
* Live channels and already existing test should not show any difference
in behavior when CC1 is selected.
* Live channels might have CC2-CC3-CC4
* Sarnoff test content has specific test cases for channel support

Reported in https://github.com/google/ExoPlayer/issues/3860
For failing examples see the github link above.

[Problem]
We drop matching control codes even if they are not received on
consecutive frames.

The specification says
"(4) If the first transmission of a control code pair passes parity,
it is acted upon within one video frame. If the NEXT frame contains
a perfect repeat of the same pair, the redundant code is ignored."

Keyword is the NEXT. The frames must arrive immediately after
each other.

See https://www.law.cornell.edu/cfr/text/47/79.101

[Solution]
Set an additional flag when any data is processed. Control code
duplication checks should be limited only for the first control
byte pairs processed after any control code.

[Test]
Sarnoff tests have equivalent CEA708 and CEA608 Streams.

PiperOrigin-RevId: 228341073

PiperOrigin-RevId: 228324452

PiperOrigin-RevId: 228309236

This is the initialization part of mitigating issue #4253. The
remaining work is on the writing side, and is simply a case of
having startFile return File instances that are sharded into
sub-directories. We still need to decide what scheme we want
to use for doing that.

Issue: #4253
PiperOrigin-RevId: 228306327

PiperOrigin-RevId: 228296962

Calls to File.length() can be O(N) where N is the number of files
in the containing folder. This is believed to be true for at least
FAT32. Repeated calls for the same file tend to be faster,
presumably due to caching in the file system, however are still
surprisingly expensive. Hence minimizing the number of calls is
preferable.

Issue: #4253
PiperOrigin-RevId: 228179921

Issue:#5313
PiperOrigin-RevId: 228155222

Issue:#5320
PiperOrigin-RevId: 228142567

They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.

PiperOrigin-RevId: 227871157

We currently either use the app thread returned by the player or the thread
the commands are called on depending on whether the media source is already
prepared or not.

This change lets the application decide which callback thread to use. As a
side effect, we also don't longer need access the player instance passed to
MediaSource.prepare.

PiperOrigin-RevId: 227871111

These are part of published IMA SDK 3.10.2.

PiperOrigin-RevId: 227861713

Also configure the FFmpeg context to ignore errors as far as possible (this
appears to have an effect only for certain decoders).

Issue: #5293
PiperOrigin-RevId: 227851397

PiperOrigin-RevId: 227822937

PiperOrigin-RevId: 227813461

Also support preparation without a player, in line with PlayerView.

PiperOrigin-RevId: 227735260

If a negative value is read, sniffing should just fail.

PiperOrigin-RevId: 227689568

PiperOrigin-RevId: 227682600

PiperOrigin-RevId: 227682159

The top level requirement only tried to ensure that the entire timeline only
has one period. This is already asserted by ImaAdsLoader. AdsMediaSource
itself works fine as long as the wrapped timeline has one period only. This
is now asserted instead.

PiperOrigin-RevId: 227682141

Passing the player through MediaSource.prepare is only needed for the AdsLoader
and complicates other usages of MediaSource. Providing the player directly to
the AdsLoader is also in line with the usage pattern of PlayerView and other
components.

Also rename methods to start/stop to better reflect their usage.

PiperOrigin-RevId: 227682112

Issue:#5312
PiperOrigin-RevId: 227673949

PiperOrigin-RevId: 227668426

Made DownloadState top level class.
Replaced action field DownloadAction fields.
Added removing, removed and restarting states.
Renamed started state to downloading.

PiperOrigin-RevId: 227664735

ExoPlayer methods must not be called from any thread besides the specified
app thread. Therefore we shouldn't use them here. Using a regular Handler
instead is fully equivalent.

Issue:#5240
PiperOrigin-RevId: 227650489

PiperOrigin-RevId: 227646358

- Increase the default cache file size to 5MB
- Recommended a minimum cache file size of 2MB to discourage
  applications from specifying values small enough such that
  unreasonably large numbers of cache files are generated
- Allow maxCacheFileSize=C.LENGTH_UNSET, equivalent to setting it
  to MAX_VALUE. This is just for API consistency with other APIs
  we have that accept LENGTH_UNSET

Issue: #4253
PiperOrigin-RevId: 227524233

PiperOrigin-RevId: 227520168

Issue: #4114
PiperOrigin-RevId: 227516509

CacheEvictor.onStartFile currently receives a length, which is the
maximum size of the content that might be written. The LRU cache
evictor will make sure there's sufficient space for the specified
size. If the actual size of the content is unknown, CacheDataSink
passes maxCacheFileSize.

The current behavior isn't ideal. It seems valid for a developer to
specify maxCacheFileSize=Long.MAX_VALUE if they don't want any
file fragmentation in the cache. However if they then attempt to
cache something with unknown length, LRU cache will try and make
room for content of length Long.MAX_VALUE, and end up evicting the
entire cache to do so.

This change alters the logic so a length is only passed if the
actual size of the content is known. In other cases C.LENGTH_UNSET
is now passed. The LRU evictor will not evict until after the file
is committed. Note a custom LRU evictor could still opt to evict to
ensure some application specified amount of space, if that's the
desired behavior.

PiperOrigin-RevId: 227509525

PiperOrigin-RevId: 227500707

See also https://github.com/Matroska-Org/matroska-specification/issues/269.

PiperOrigin-RevId: 226758584

This also applies when seeking or transitioning to unprepared media, which
isn't clear from the current documentation.

Issue:#5267
PiperOrigin-RevId: 226486685

PiperOrigin-RevId: 226460891

PiperOrigin-RevId: 226459209

PiperOrigin-RevId: 226356810

PiperOrigin-RevId: 226356758

This includes NoSampleRenderers.

PiperOrigin-RevId: 226323693

Issue: #5145
PiperOrigin-RevId: 226297129