SDK / exoplayer

Currently the renderer is only ready when the input stream has more data to
read. Actual renderers, however, are also ready as long as their output buffer
contains some audio/video samples to play, roughly corresponding to the fact
that the playback time hasn't reached the timestamp of the last buffered
sample. Added a isready flag to FakeRenderer to simulate this behaviour.

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

This is possible to do without passing the player instance to
custom action providers through their constructors, given we
no longer have a MuteActionProvider. Passing the player through
the constructors generalizes better to such cases, however, so
feels like the right thing to do.

It's also possible to use generics and keep passing the player
instance via the CustomActionProvider methods, but this adds
some unnecessary complexity.

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

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

Extensions can perform additional actions whenever data is read (e.g. sleeping
to simulate bandwidth restrictions).

Additionally, the factory class can also be overwritten and allows to set the
FakeDataSet later in case it is not available right away.

Moreover, this class now also uses a transfer listener similar to all real data sources.

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

The position returned by getContentPosition() could be C.TIME_END_OF_SOURCE.
Fix the content position stored in MediaPeriodInfos for postroll ads to be the
duration of the containing period.

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

framework.

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

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

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

Note: Wont work quite yet; we need to actually do a
release for the instructions to become effective.

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

The value is automatically set at creation and allows simpler access to the
faked data position within the source.

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

This class defines the data of an adaptive media source. It currently has
chunks of equal length and size corresponding to the declared average bitrate
of the Formats.

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

We currently read at most 5 packets at a time from the
extractor input. Whether this is inefficient depends on
how efficiently the underlying DataSource handles lots
of small reads. It seems likely, however, that DataSource
implementations will in general more efficiently handle
fewer larger reads, and in the case of this extractor
it's trivial to do this.

Notes:
- The change appears to make little difference in my
  testing with DefaultHttpDataSource, although analysis
  in #3040 suggests that it does help.
- This change shouldn't have any negative implications
  (i.e. at worst it should be neutral wrt performance). In
  particular it should not make buffering any more likely,
  because the underlying DataSource should return fewer
  bytes than are being requested in the case that it
  cannot fully satisfy the requested amount.

Issue: #3040

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

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

If seek is called for a non-seekable period, when the period is prepared the
start position will be updated from the seek position to zero. Because the
start position is part of the renderer offset for the first loaded period
holder, after the update the renderer offset start position and the new start
position would no longer cancel out, leading to the player position being
negative.

The first period holder's renderer offset is the fixed base offset (60 seconds)
plus its start position, but the start position is always subtracted. Avoid
subtracting the start position for the first period holder so that when it
changes there is no need to update the renderer offset.

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

This enables adaptive media test cases using TrackGroups with multiple
Formats.

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

This allows to create extensions of FakeDataSet and also simplifies the
FakeDataSource class.

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

Also move to using an array to hold the SampleQueues,
as we've moved to doing in ExtractorMediaPeriod.

Issue: #551

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

drmInitData can be null in DASH if all of the init data is
specified at the manifest level instead. I took a look at
injecting the manifest format into the extractors, so that
we can actually copy the scheme type into it, but that's
at least non-trivial enough to delay for a subsequent CL.

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

We'd normally expect playback controls to be hidden during
ad playback, although if they are visible for whatever reason,
it makes sense to set the position to the current content
position now that we have it.

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

We want to experiment with a direct executor to avoid thread hops between the
network thread and the response handling thread. This change is needed to do
so.

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

Note: this temporarily exposes a bug where seeking a non-seekable source leads
to the player position being negative before playback starts.

Issue: #2655

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

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

On an old version of okhttp, opening connection clears the thread interrupt flag silently. This is a workaround
to reduce the effect of the bug.

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

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

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

"Default (none)" is sometimes just wrong, since the track
selector may attempt to select a track even if it exceeds
the renderer's capabilities. Just "Default", as it used to
be, was more accurate.

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

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

Apply the same learnings as in ParsableBitArray.

Issue: #3040

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

ParsableBitArray.readBit in particular was doing an excessive
amount of work. The new implementation is ~20% faster on desktop.

Issue: #3040

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

Really low hanging fruit optimization for TS extraction.

ParsableBitArray is quite expensive. In particular readBits
contains at least 2 if blocks and a for loop, and was being
called 5 times per 188 byte packet (4 times via readBit). A
separate change will follow that optimizes readBit, but for
this particular case there's no real value to using a
ParsableBitArray anyway; use of ParsableBitArray IMO only
really becomes useful when you need to parse a bitstream more
than 4 bytes long, or where parsing the bitstream requires
some control flow (if/for) to parse.

There are probably other places where we're using
ParsableBitArray over-zealously. I'll roll that into a
tracking bug for looking in more detail at all extractors.

Issue: #3040

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

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

This CL also makes DefaultTrackSelector take it into account when RendererCapabilities
sets it to unsupported.

A following CL could add a DefaultTrackSelector parameter to force DRM "known support" for specific track types.

Issue:#1661
Issue:#1989
Issue:#2089

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

Let's do it this way for now. Note there's an implicit
assumption in here that non-AV tracks consist of only
key-frames, but I think we'll not encounter any issues
in the real world as a result, we already make this
assumption in ChunkSampleStream, and actually tagging
every queue with this information explicitly is a very
painful amount of plumbing.

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

adsLoader.contentComplete was called twice which led to postrolls not seeing
the STARTED event.

Also make the onPositionDiscontinuity handler easier to follow by renaming
variables, and remove the adGroupIndex field.

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

This metric is measured once every second.

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

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

Ads don't have their own periods any more, so show ad group markers even if the
time bar is not multi-window.

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

This includes a metric logger class which logs events and generates metrics, and some changes to the Perfgate benchmark config to add the metrics. So far, only rebuffer counts, rebuffer time and startup time are measured, together with auxiliary values of total playback time used for testing and number of playback failures.

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

Issue: #3033

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

Once background and resuming is supported, the ads loader will be kept when the
player is destroyed and recreated. Move the state relating to the structure of
ads and what ads have been loaded/played out of the media source and into the
loader so the information is not lost when the source is released, in
preparation for supporting background and resuming.

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