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.
1. Remove requirement for TrackRenderer implementations to report
current position, unless they are time sources.
2. Expose whether renderers have media to play. The immediate benefit
of this is to solve the referenced GitHub issue, and also to only
display the appropriate Audio/Video/Text buttons in the demo app
for the media being played. This is also a natural step toward
multi-track support.
Github issue: #541
This makes it so that it's no longer necessary to specify the number
of downstream renderers to HlsSampleSource, FrameworkSampleSource and
ExtractorSampleSource, by forcing the downstream renderers to register
with the SampleSource instances in their constructors. This eliminates
a common source of subtle client bugs where the passed value is incorrect.
- There's definitely potential for more code sharing in these
classes, but deferring for now.
- Also made no-scheme default to file://, and allowed smoothstreaming
URLs to be specified with or without the /Manifest suffix.
This also fixes a technical mistake where HlsChunkSource is fed
seekPositionUs=-1 when obtaining the first chunk. This is wrong,
but the usage of this variable within HlsChunkSource enforces that
the seek must stay within bounds, so we get away with it.
Issue: #385
The spurious transitions were caused by calling pushTrackSelection
in onRenderers after changing the renderer building state to BUILT
and before calling player.prepare. pushTrackSelection can cause the
ExoPlayer to generate state changes, since it can call setPlayWhenReady.
This change transitions the renderer building state later, so that
when this happens getPlaybackState correctly masks the state and
returns STATE_PREPARING.
Play movies has an Allocator that attempts to allocate a single
huge byte[] up front to minimize the risk of GC pauses. This abstraction
will be required to keep that when updating them to the new Exo.
Using a file:// URL for loading an HLS stream (for testing) would fail due to
casting the connection to an HttpURLConnection in DefaultHttpDataSource.
This change makes UriDataSource an interface for objects that are DataSources
with URIs. That allows for reading manifests for HLS using just a UriDataSource
rather than an HttpDataSource (URLs in the playlist are relative to the data
source's URL so the getUri method is needed).
The OMX component needs to be configured with a format that has a
MIME type of audio/raw. Remove Ac3PassthroughAudioTrackRenderer,
which is no longer used.
- Keys should not expire during normal playbacks of correctly configured content.
- Attempting to refresh on expiration causes a race condition, that may result
in either failure or brief re-buffer, for the 30s license test video.
- This change provides deterministic behavior, which is to always fail.
- Added support for ID3 frames of types GEOB and PRIV.
- GEOB type is commonly used by dynamic ads provider to include in the
stream information about the ads to be played.
- PRIV type is commonly used for time synchronization (example:
synchronizing playback of a live stream and its webvtt captions) and
also by analytics companies to include tracking information in the
stream.
- Added a sample stream from Apple that contains ID3 metadata.
Note: I'm fairly confident that NetworkLoadable.Parser implementations
can live without the inputEncoding being specified. But not completely
100%...
Issue: #311
Issue: #56
Support is provided for the following schemes:
urn:mpeg:dash:utc:direct:2012
urn:mpeg:dash:utc:http-iso:2014
urn:mpeg:dash:utc:http-xsdate:2012
urn:mpeg:dash:utc:http-xsdate:2014
- This change:
1. Extracts HlsExtractor interface from TsExtractor.
2. Adds AdtsExtractor for AAC/ADTS streams, which turned out to be
really easy.
Selection of the ADTS extractor relies on seeing the .aac extension.
This is at least guaranteed not to break anything that works already
(since no-one is going to be using .aac as the extension for something
that's not elementary AAC/ADTS).
Issue: #209
The complexity around not enabling the video renderer before it
has a valid surface is because MediaCodecTrackRenderer supports
a "discard" mode where it pulls through and discards samples
without a decoder. This mode means that if the demo app were to
enable the renderer before supplying the surface, the renderer
could discard the first few frames prior to getting the surface,
meaning video rendering wouldn't happen until the following sync
frame.
To get a handle on complexity, I think we're better off just removing
support for this mode, which nicely decouples how the demo app
handles surfaces v.s. how it handles enabling/disabling renderers.
- Remove simple variant. Maintaining both simple + full is
unnecessary effort.
- Remove need to specify content id in Sample definition,
except where it's actually required (for DRM requests in
the Widevine GTS samples)
SampleExtractor will initially only be implemented by FrameworkSampleExtractor
which delegates to a MediaExtractor, but eventually it will also be implemented
by additional extractors.
The sample extractor can be used as a source of samples via DefaultSampleSource.
