Bigger changes will be coming, but this gets DRM back
up and working again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122719062
- Don't report errors to listeners if playback will immediately
fail. Doing so is redundant, since such errors are immediately
reported through ExoPlayer's listener as a result of playback
failure. We were also reporting these errors inconsistently
across renderers.
- Reduce code duplication through EventDispatcher classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122519976
Allows the user to provide their own criteria for selecting one of the available tracks
without having to reimplement the track assignment logic, i.e. linking type x tracks with
type x renderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122422087
1. Merge HlsOutput and HlsSampleSource -> HlsTrackStreamWrapper.
2. Rename HlsSource -> HlsSampleSource2. This will be renamed to
HlsSampleSource in a subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122415970
Mechanical step to create a new HlsSource in the library.
Note that naming is now confusing. This will be fixed in
the next CL, when:
HlsSource -> HlsSampleSource
HlsSampleSource+HlsOutput -> HlsOutput
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122054800
Support for opus content in ogg container.
TODO: Sample duration and seeking.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121940392
Dash/SS SampleSources now instantiate ChunkSource and
ChunkSampleSource (renamed to ChunkTrackStream) instances
on demand as tracks are enabled. The TrackGroups exposed
by the DASH/SS SampleSources are now constructed at the
top level.
Note that this change resolves the TODOs at the top of the
ChunkSource classes, allowing multiple adaptation sets of
the same type.
Next steps will include:
- Bring back UTC timing element support for DASH, which
will be an extra request during preparation in the DASH
SampleSource.
- Simplification of manifest fetching to use a Loader directly
in the two top level SampleSource classes. ManifestFetcher
should eventually go away once HLS no longer needs it.
- Eventually, some consolidation between DASH/SS. There's a
lot of common code there now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121001777
This is a mechanical change. The two new SampleSource classes
are forked from MultiSampleSource, with the logic that previously
was in the demo app's SourceBuilder methods copied into the
corresponding constructors. Subsequent steps will:
1. Pull the initial manifest processing from DashChunkSource and
SmoothStreamingChunkSource into the new SampleSource classes.
2. Remove the construction of ChunkSampleSource instances from
the constructors, instead instantiating children only as needed
when tracks are enabled.
3. Simplify ChunkSampleSource down into a ChunkTrackStream object.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121001021
The construction currently in SourceBuilder will be
moving inside of the core lib, so it can't refer to
DemoPlayer constants.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=120822759
- RollingSampleBuffer -> DefaultTrackOutput
- TsChunk -> HlsMediaChunk
- Established hls.playlist package for HLS playlist things
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=120325049
- Rename preparePlayer to initializePlayer, to reflect the fact that the
preparing state is gone. Replace playerNeedsPrepare with playerNeedsSource.
- playWhenReady is now always true in calls to initializePlayer.
- Handle the intent just before setting the source.
- Use URIs consistently instead of Strings to avoid reparsing.
- onShown becomes initializePlayer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=120125576
prepare(SampleSource) is renamed to setSource(SampleSource). The player
immediately transitions to STATE_BUFFERING when the source is set, at which
point doSomeWork is called.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119838825
This is in preparation for the player knowing about the live
window, at which point only correct playback positions will be
passed into ChunkSource implementations. Note that both
implementations bound the chunk index within range in case of,
for example, off-by-one errors caused by very recent manifest
updates.
This will temporarily cause live playbacks to always start at
the beginning of the current live window (we'll be trying to
play from t=0, which will be adjusted to the start of the live
window as a result of the bounding).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119733559
Both of these features are being promoted to first class
citizens in V2 (multi-period support will be handled via
playlists, seeking-in-window will be handled by exposing
the window/timeline from the player and via the normal
seek API). For now, it's much easier to continue the
refactoring process with the features removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=119518675
Step 6 of the refactor involves moving the logic that's
currently in the SourceBuilder classes in the demo app
into new SampleSource classes in the library. These classes
will construct video/audio/text pipelines on-demand (i.e.
when tracks are enabled) rather than constructing them all
up front as is currently the case in the SourceBuilder
classes. Hence we need a way to instantiate DataSource
instances (i.e. a DataSourceFactory ;)).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118722180
In V2 we'll at some point start using DataSource factories
for creating DataSource instances. If there are two DataSource
interfaces this gets unnecessarily awkward.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118470751
* Do not stop playback onPause but onStop in N and greater.
* Fix back navigation after app has been put to background.
* Make VIEW intent work when PlaybackActitivty is already launched.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=118022964
When showing a track selection for a renderer, the override
variable could end up being retained from some previous call
to show a track selection for some other renderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117557994
Notes:
- The way this works is that every time the player needs to
select some tracks it invokes the TrackSelector. When a
track selection is actually activated (i.e. "hits the
screen") it gets passed back to the TrackSelector, which
allows it to expose the current tracks through an API that
it may choose to define. Since playlist support doesn't exist
yet, it's currently the case that the pass-back always occurs
immediately.
- A TrackSelector can invalidate its previous selections if its
selection criteria changes. This will force the player to invoke
it again to make a new selection. If the new selection is the
same as the previous one for a renderer then the player handles
this efficiently (i.e. turns it into a no-op).
- DefaultTrackSelector supports disabling/enabling of renderers.
Separately, it supports overrides to select specific formats.
Since formats may change (playlists/periods), overrides are
specific to not only the renderer but also the set of formats
that are available to it. If the formats available to a renderer
change then the override will no longer apply. If the same set
of formats become available at some point later, it will apply
once more. This will nicely handle cases like ad-insertion where
the ads have different formats, but all segments of main content
use the same set of formats.
- In general, in multi-period or playlist cases, the preferred
way of selecting formats will be via constraints (e.g. "don't play
HD", "prefer higher quality audio") rather than explicit format
selections. The ability to set various constraints on
DefaultTrackSelector is future work.
Note about the demo app:
- I've removed the verbose log toggle. I doubt anyone has
ever used it! I've also removed the background audio option.
Without using a service it can't be considered a reference
implementation, so it's probably best to leave developers to
figure this one out. Finally, listening to AudioCapabilities
has also gone. This will be replaced by having the player
detect and handle the capabilities change internally in a
future CL. This will work by allowing a renderer to invalidate
the track selections when its capabilities change, much like
how a selector is able to invalidate the track selections in
this CL.
- It's now possible to enable ABR with an arbitrary subset of
tracks.
- Unsupported tracks are shown grayed out in the UI. I'm not
showing tracks that aren't associated to any renderer, but we
could optionally add that later.
- Every time the tracks change, there's logcat output showing
all of the tracks and which ones are enabled. Unassociated
tracks are displayed in this output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117122202
- Format can represent both container and sample formats.
If a container contains a single track (as is true in
DASH and SmoothStreaming) then the container Format can
also contain sufficient information about the samples
to allow for track selection. This avoids the Format to
MediaFormat conversions that we were previously doing in
ChunkSource implementations.
- One important result of this change is that adaptive
format evaluation and static format selection now use the
same format objects, which is a whole lot less confusing
for someone who wants to implement both initial selection
and subsequent adaptation logic. It's not in the V2 doc,
but it may well make sense if the TrackSelector not only
selects the tracks to enable for an adaptive playback, but
also injects a FormatEvaluator when enabling them that will
control the subsequent adaptive selections. That would make
it so that all format selection logic originates from the
same place.
- As part of this change, the adaptiveX variables are removed
from the format object; they don't really correspond to a
single format. This also saves on having to inject the max
video dimensions through a bunch of classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114546777
This change removes the need for SourceBuilders to load their
manifests before building their sources. This is done by pushing
initial manifest loads into the ChunkSource classes. This simplifies
the SourceBuilders a lot, and also DemoPlayer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=113259259
Notes:
1. The logic in ExoPlayerImplInternal is very temporary, until we
have proper TrackSelector implementations. Ignore the fact that
it's crazy and has loads of nesting.
2. This change removes all capabilities checking. TrackRenderer
implementations will be updated to perform these checks in a
subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=113151233
GitHub note - Apologies for the cryptic change descriptions,
they relate to a design doc that's not externally visible.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=113043764
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.
- Video track is always marked as adaptive, the resolution is
stripped out (since it's otherwise just set to whatever the
resolution of the first selected variant is), and the max
dimensions are set.
Issue #514
- Migrate demo app to use new APIs.
- Add multi-track support for ExtractorSampleSource case.
- Add multi-track support for SmoothStreaming use case.
The final step is to add support back for the DASH use case and
delete MultiTrackChunkSource. This is blocked on multi-period support
landing, in order to prevent a horrendous merge conflict. We also
need to update HLS to expose sensible track information.
Issue: #514
multi-track support upstream to the ChunkSource interface.
This change does not yet make use of the newly exposed APIs. This
will come in a subsequent CL.
Issue #514.
- Parse all attributes that may exist in either the AdaptationSet or
in the child Representation elements at both levels.
- Correctly infer TYPE_TEXT for Representation elements whose mimeType
is application/mp4 and whose codecs attribute indicates a known text
codec type.
Issue: #689
Remove MPEG TS stream filtering based on AudioCapabilities.
Pass AudioCapabilities to MediaCodecAudioTrackRenderer so it can choose between
passthrough/raw and decoding for AC-3 tracks.
Everything I've seen that uses ExoPlayer sets it to true, and
setting it to false is poorly supported / likely to result in
bad initial A/V sync after each seek.
If the manifest server response arrived after the player was released, the
renderer builder would set up renderers for a released player, causing an
exception to the thrown in the DASH case.
Also fix Issue #657
- ExtractorSampleSource takes an array of extractors to test for suitability.
- Extractors now implement a sniff() method that returns whether they can
extract samples in the input stream's format.
- Switch demo app samples to use format detection.
Issue: #438
The SubtitleLayout is now properly aligned with the surface.
This means the subtitles remain on top of the video in portrait
mode, rather than being huge and below it.
