SDK / exoplayer

Libvpx: Support directly outputting YUV to SurfaceView. This is supposed to use hardware (not GPU) to convert YUV to RGB and overall use less power.

Power Comparison:

TextureView                          1080p         720p
                H264 HW              498, 496      507, 478
                VP9 RGB              1050, 1104    1185, 1152
                VP9 ANativeWindow    1070, 985     700, 674
GLSurfaceView
                VP9 YUV              1075, 1112    716, 635
SurfaceView
                H264 HW              419, 409      397, 377
                VP9 RGB              1044, 1139    654, 671
                VP9 ANativeWindow    975, 835      617, 623
                VP9 MediaCodec       683, 679      488, 476

Measures average current drawn mAH on a Nexus 6 at full brightness from time t=3 to t=95 seconds. The same clip was used for all tests. Two measurements were taken for each category.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203847744

It's no longer text specific (it's used for metadata as well, and
in theory could apply to any stream in which samples contain multiple
sub-samples)

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203767825

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203766579

Until now, the streams were released and re-enabled for each type of stream
(primary, event, embedded) in that order. That leads to problems when replacing
streams from one type to another (for example embedded to primary).

This change restructures the track selection to:
1. Release and reset all streams that need to be released or replaced.
 1(a). Including embedded orphan streams.
2. Select new streams.

Issue:#4477

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203751233

Where a device has this issue, it most likely applies to all
SOC vendor provided decoders, which are normally the only
video decoders other than the OMX.google software decoders
on the device. The fact we currently only blacklist for AVC
decoders is likely just a side effect of AVC's popularity.

I checked two devices already on the blacklist, and both
failed with other SOC vendor decoders on the device as well
(but passed if forced to use OMX.google decoders instead)

Issue: #4468

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203728285

Viewport constraints apply to adaptive content even if the
actual playback isn't adaptive (i.e. because the selector
ends up making a fixed track selection).

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203726831

- Support handling frame queries (i.e get frames at times, output to certain
sizes) from MetadataRetriever.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203489788

If there is only one track, we can assume that both boxes refer to the same track
even if the track indices don't match.

Issue:#4083

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203485872

MediaDrm.provideXResponse methods only accept the response
corresponding to the most recent MediaDrm.getXRequest call.
Previously, our code allowed the following incorrect call
sequence:

a = getKeyRequest
b = getKeyRequest
provideKeyResponse(responseFor(a));

This would occur in the edge case of a second key request
being triggered whilst the first was still in flight. The
provideKeyResponse call would then fail.

This change fixes the problem by treating responseFor(a)
as stale. Note that a slightly better fix would be to
defer calling getKeyRequest the second time until after
processing the response corresponding to the first one,
however this is significantly harder to implement, and is
probably not worth it for what should be an edge case.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203481685

Both boxes should contain the same list of track indices. However, if only one
track index in each list does not match, we can just assume that these belong
together.

Issue:#4477

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203481258

Issue: #4468

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203479944

Since this is an ongoing problem, it's reasonable that we allow
developers to toggle these workarounds without too much hassle.

Issue: #4468

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203364488

This allows to register a listener on an outer wrapping data source which
receives data transfer events from the wrapped source.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203358981

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203341457

This wires up recent changes of passing a transfer listener to the MediaSource and
allowing DataSources to accept new listeners.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203280818

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203260699

Add supports for reading duration for a TS stream by reading PCR values of the PCR PID packets at the start and at the end of the stream, calculating the difference, and converting that into stream duration.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203254626

Codec initialization may fail in creation, configuration or when start()ing the
codec. If codec initialization fails, there may be other codecs available that
could handle the same format, but currently ExoPlayer can only try to use the
first listed codec for the input format and gives up if it fails to initialize.

This change implements support for optionally falling back to alternative
decoders if initialization fails. MediaCodecSelector can now return a list of
decoders to try in priority order, and use the Format when choosing a codec.
With the default implementation, the codecs and order come from MediaCodecList,
and matches the order used internally by MediaCodec.createDecoderByType (which
implements the same kind of fallback though only to the creation step, without
configuring/starting the codec).

This feature is useful for apps that want to play several videos concurrently on
devices that have software decoders (like OMX.google.h264.decoder), as the new
behavior allows new codecs to be created when no hardware-accelerated decoders
are available.

The list of available codecs is queried when initializing the codec after a
format change that requires a new codec to be instantiated. When a decoder fails
to initialize it is removed from the list of available decoders and won't be
tried again until the next format change (or until the renderer is disabled).

Note: this change does not affect the renderer capabilities API, as when
checking format support we don't know which codec will be used.

Issue: #273

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203242285

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203141421

This ensures compatiblity of other apps depending on our public GitHub code.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203129076

This allows to iterate through the available chunks of the stream.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203105813

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203102464

This allows implementations to notify when the transfer is about to be started.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203102117

This allows all leaf data sources (i.e. ones which do not forward the requests
to other data sources) to accept multiple listeners.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203097587

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202965785

This allows to use this queue in the track selection in the future.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202954871

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202948642

This will allow to provide available information about future chunks to the
track selection.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202940994

Issue:#2395

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202926448

Issue:#4451

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202923630

Issue: #4029

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202912333

The Android Test Support Library is being renamed to AndroidX Test, with its root java namespace changing from android.support.test to androidx.test.
And code location changing from tp/android/android_test_support to tp/android/androidx_test.

More information: []

TAP global presubmit: []

BUG:
79205333

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202796842

Issue: #4321

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202660712

The new method allows to add transfer listeners (e.g. the BandwidthMeter) after
the data source has been created. To simplify the implementation for
subclasses, this change also introduces a BaseDataSource which handles
the list of listeners and the listener registration.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202649563

In the future, this allows to register the BandwidthMeter (managed by the player)
as a listener to all media transfers related to this media source.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202643946

- Extract ConstantBitrateSeeker from Mp3 package into a more general
ConstantBitrateSeekMap.
- Use this seekmap to implement seeking for AMR format.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202638183

From the spec:

If the EXT-X-INDEPENDENT-SEGMENTS tag appears in a Master
Playlist, it applies to every Media Segment in every Media
Playlist in the Master Playlist.

----

This requires propagation of attributes from the master
playlist to the media playlists. This CL only includes
independent segments, but other inheritable attributes
will be supported in following changes. Other inheritable
attributes include variable substitution definitions and
session keys.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202628422

Issue: #4460