This was possible previously, but now we support things
like multi-period DASH we need to do the injection in
the form of factories rather than concrete instances.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127735816
This change restores ExoPlayer to its previous behaviour.
I think we'll want a "resetPosition" boolean parameter on
setMediaSource at some point, but no need to add it right
now. Note that this would not always reset to the start
of the source. For a live playback it will reset to the
desired position (normally somewhere slightly behind the
live edge).
Issue: #1667
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127549700
In V1 we received complaints that Renderer was too locked down.
In particular, it wasn't possible to implement a Renderer that
wrapped another Renderer, since most of the methods were package
private and final (e.g. enable).
This change defines Renderer as a proper interface, removing
this limitation. A method-reordering-only change will follow
this one, to get things into a nice consistent/sane order in
each of the Renderer classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127527995
1. Rename "extensions" package to "decoder". It's used by both
text and (should be used by) metadata, so it's no longer just
for extensions.
2. Move Buffer objects move into the decoder package.
3. Rename SubtitleParser and MetadataParser to SubtitleDecoder
and MetadataDecoder respectively, since they extend Decoder.
Ditto for all subclasses.
4. Subtitle and Metadata decoders now throw their own exception
types rather than ParserException.
5. Move MediaCodec classes into a mediacodec package, with the
exception of the concrete audio and video renderers.
6. Create an audio package to hold the two audio renderer classes
plus related util classes.
7. Create a video package to hold the one video renderer class
plus related util classes.
After this change the following nice properties hold:
1. Want a video renderer? Look in the video package. Ditto for
audio, text and metadata.
2. All TrackRenderer implementations use a decoder of some kind
to decode buffers received from the source, so we have
consistent terminology there.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127326805
The BandwidthMeter should only be used by MediaSource
instances and the objects they reference, so there's
really no reason for the player to need to know about it.
This change sacrifices DebugTextViewHelper showing the
estimated bandwidth, but I think that's a price worth
paying.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127316755
It doesn't look like TrackSelectionPolicy is going to be
useful other than with DefaultTrackSelector, and it's kinda
confusing dealing with both "selector" and "policy"
terminology. This change does the following:
DefaultTrackSelector -> selector.MappingTrackSelector
DefaultTrackSelectionPolicy -> selector.DefaultTrackSelector
TrackSelectionPolicy -> [deleted]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127196326
There aren't really enough classes to justify it right
now, but if we're going to do a VideoView equivalent and
sensible player controls at some point, it's worth making
now to get classes into the correct place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127184374
- The package is renamed to avoid conflicts with v1, should any
app wish to include both v1 and v2 for a period of time. This is
similar to the approach used by some other open source projects
(e.g. okhttp).
- Copyright year is updated everywhere for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126895326
Also attempt to clear up naming a little, using "buffering" to
mean the user visible buffering state, and "loading" to mean a
source being loaded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126693592
At a high level, everything that we need to load in sync
with anything else now implements a new SequenceableLoader
class. This includes ChunkTrackStream, since multiple
demuxed tracks in DASH/SS need to be loaded in sync with
one another. At a higher level, SampleSources are also
SequenceableLoaders, which allows them to be kept in sync
by MultiSampleSource.
CompositeSequenceableLoader is able to load multiple
instances SequenceableLoaders in sync with one another,
and is used in various places where this is required.
This change also removes LoadControl registration, which
was complicated and error prone.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126632861
This is required for buffering to work properly across
playlist transitions. It's also much simpler, since
specifying the buffering policy becomes independent of
the type of media being played (i.e. the source).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126051755
ExoPlayer.EventListener.onPositionDiscontinuity is notified during seeking and
transitioning from one source to the next.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125578976
- Event listener is now at the SampleSource level, since the
individual ChunkTrackStream instances are created internally.
- Event listener receives events corresponding to loads made
at the SampleSource level (e.g. manifest fetches) in addition
to those made by the ChunkTrackStream instances.
- Added ability for FormatEvaluators to propagate arbitrary
information (as an Object) through to the listeners. This was
a request from YouTube.
- Added significantly more information to each event, for example
the DataSpec that defines the load being made is now passed, as
is timing information.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124732984
If the same instance is reset then rapidly re-enabling the
renderer after disabling it can prevent an application from
reading the final values at the time when the renderer was
disabled. Hence we now instantiate a new CodecCounters each
time. This is needed to migrate DashTest to V2.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124721106
- Parse APIC and TextInformation frames.
- In MPEG-TS, don't mind if packets contain end padding.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124079930
The allocator and buffering policy (e.g. how large the buffer
is) is moving to the top level as part of playlist support,
so it no longer makes sense to inject these parameters as
args into ExtractorSampleSource's constructor.
Instantiating the allocator and buffer size inside of the
source is temporary and only until they're moved up.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123968976
Initially only the first source index is used. In a later change,
ExoPlayerImplInternal will create SampleSources for different playlist item
indices as necessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123312595
Merge the two MediaDrmCallback classes, since they're pretty
much identical.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123220343
- Simplify setSurface by always blocking when the surface
is being cleared.
- Add analogous setVolume API.
- Support setting of playback params for extension audio
decoders. We can probably use this to add a setPlaybackRate
API to SimpleExoPlayer for API level 23 and above only,
but we'd probably want to make sure it works properly when
there's no audio track too, so some thought will be
required.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123204581
Also handle .exolist.json links. This lets you put a list of
samples somewhere (e.g. on the web). Clicking it opens the
app and displays the samples it defines.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123198928
DemoPlayer moves into core library as SimpleExoPlayer, which
implements ExoPlayer.
Issue: #383
Issue: #592
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123090184
1. Properly split out listening responsibilities so that
DemoPlayer only listens to its own components.
2. Revert StreamingDrmSessionManager UnsupportedDrmScheme
exceptions back to how they worked in V1, and inject
a DrmSessionManager rather than a MediaDrmCallback into
DemoPlayer.
This much better prepares DemoPlayer for promotion into
the core ExoPlayer library, since it removes assumptions
such as what SampleSource and DrmSessionManager impls
might be used with it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122980952
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.
