See the documentation of buildTracks for the gory details.
Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112149293
This is equivalent to DashTrackSelector and SmoothStreamingTrackSelector.
This is a step toward allowing HlsChunkSource to expose multiple tracks,
which is a requirement for supporting WebVtt.
This change also enables WebVtt extractor instantiation.
Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111698833
This allows the same adjusters to be used by multiple
HlsChunkSource instances. This is necessary because
WebVTT chunks will be loaded by a second chunk source
to the one loading audio/video. In both cases the same
timestamp adjustments will need to be applied.
Each source may transition from one discontinuity sequence
to the next at a slightly different time, so it's necessary
to maintain a separate adjuster for each sequence.
An adjuster can only be initialized correctly using audio/video
and not WebVTT, because the start time in a WebVTT file in
HLS doesn't necessarily correspond to the chunk start time,
which means the timestamp offset calculated by the adjuster
could end up being incorrect. Hence sources providing WebVTT
chunks will set isMasterSource to false. Lovely, right :(?
Issue: #151
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111693126
This gives DefaultSmoothStreamingTrackSelector feature parity
with DefaultDashTrackSelector. Note that the code duplication
across these classes will go away eventually, when we rework
track selection as described in Github Issue #1121.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111688784
This allows implementation and injection of custom MediaCodecSelector
instances. By injecting a custom selector, it's possible for applications
to exert more control over which decoder(s) they instantiate. For example,
applications can force use of a software decoder.
GitHub Issue #938
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110369810
Overrided the dispatchKeyEvent of MediaController to allow FFWD and RWD through
remote control keys.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=108989028
* Add additional Widevine samples.
* Improve error messaging in demo app around decoders.
* Display toasts for playback errors related to missing insecure
decoders, missing secure decoders, decoder instantiation failure
and decoder query failure.
* Remove checks from SampleChooserActivity, since the above largely
covers off this problem.
API 23 requires the permissions to be granted at runtime.
This CL submits a solution for EXTERNAL_STORAGE, since it
is the only dangerous privilege required so far.
Context:
- Currently, playback is significantly more juddery with it disabled,
particularly on AndroidTV.
- We should be able to do the "best" job of this internally, so injection
doesn't buy anything useful. If someone has a better implementation for
adjusting the frame release, they should improve the core library.
- With this change, you can select from the individual video formats in
the demo app, as well as the regular "auto" (adaptive) track.
- DashRendererBuilder no longer needs to create MultiTrackChunkSource
instances for the multiple tracks to be exposed.
- It's not possible to determine a period's duration just from the
corresponding Period element in a DASH manifest. It's necessary
to look at the start time of the next period (or the duration of the
manifest for the last period) to determine how long a period is. We
don't currently do this in the parser, and hence set duration incorrectly.
We also set period start times incorrectly because we don't set it to
equal to sum of the durations of prior periods in the case where it's
not explicitly defined.
- We're currently propagating these (incorrect) values all over the place
through data-structures that we build when parsing the Period element.
- This CL removes this redundancy, storing only the start time of each
period in Period elements, and not propagating it elsewhere. It's then
used when required in DashChunkSource.
