This change replaces TrackGroup[] with TrackGroupArray. This is
to allow equality based hashCode and equals implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=115563146
The TrackSelector API will look like:
TrackSelection[] selectTrack(
TrackRenderer[] renderers, TrackGroup[] trackGroups);
In this CL:
- SampleSources return TrackGroup[], so that the result can be easily
passed to the selector.
- TrackStream gets its own file to sit alongside other Track* classes.
- A TrackSelection object is introduced to encapsulate group and track
indices.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=115251331
- 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
Duration was originally included in MediaFormat to match the
framework class, but it actually doesn't make much sense. In
many containers there's no such thing as per-stream duration,
and in any case we don't really care. Setting the duration on
each format required excessive piping.
This change moves duration into SeekMap instead, which seems
to make a lot more sense because it's at the container level,
and because being able to seek is generally couplied with
knowing how long the stream is.
This change is also a step toward merging Format and MediaFormat
into a single class (because Format doesn't have a duration),
which is coming soon.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114428500
[Step 4 - Partial, of []
- The capabilities checks previously performed in VideoFormatSelectorUtil
are now performed in MediaCodecVideoTrackRenderer. This means they'll be
useful for non-chunk use cases (e.g. when using ExtractorSampleSource).
- Added capabilities checks for audio in MediaCodecAudioTrackRenderer. We
didn't check audio capabilities previously.
- Added functionality to allow a TrackRenderer to indicate the extent of
its adaptive support.
The idea here is that a TrackSelector (to be introduced) will have access to:
(a) TrackGroups from the SampleSource that indicate whether they support
adaptive playbacks and the formats of each individual track.
(b) TrackRenderers that indicate whether they support adaptive playbacks as
well as how capable they are of rendering formats of individual tracks.
This is everything that a TrackSelector needs from the player components in
order to decide how to wire things up. Note that a TrackSelector may opt to
treat FORMAT_EXCEEDS_CAPABILITIES as FORMAT_HANDLED at its own risk, if it
thinks that it (or the user) knows better. This is a request that we've seen
from third parties for better handling cases where capabilities aren't
accurately reported by the underlying platform.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114427428
Delete SingleSampleChunkSource. I don't think it's really
useful for anything, now we have SingleSampleSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=113259289
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
When a seek is performed, renderers currently perform the
actions that they need to take in two places: Some changes
are performed in seekTo implementations. Other changes are
performed when discontinuities are read from the source.
In HLS we need to perform what is effectively a seek
originating in the source. To support this, this CL allows
discontinuities read from the source to modify the playback
position. All actions that renderers perform as a result
of a seek are moved to be performed when a discontinuity is
received.
Best way to understand CL:
- Look at SampleSource interface change and then at the
concrete implementations, to make sure they've been
changed properly.
- Look at SampleSourceTrackRenderer change.
- Look at concrete renderers. The general pattern is that
code previously performed in seekTo and READ_DISCONTINUITY
is merged into onDiscontinuity().
Note: This will be further untangled in V2.
Issue #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112720746
Seems (marginally) nicer than making one up :). I didn't
realize there was a method that didn't require a framerate
to be passed!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110456874
- 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.
- 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
When ChunkSource implementations implement multi-track for DASH and SS,
format selection will move inside of ChunkSource. If we, for example, fail
to query the decoder to determine which tracks are playable, we need an
opportunity to fail (i.e. say we're not prepared, so that maybeThrowError
is called, from which we can throw).
This may go away in the future if we remove the distinct preparation step
and treat tracks/formats as things that can change dynamically, but for now
this is what we have.
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
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.
Both FragmentedMp4Extractor and WebmExtractor now invoke seekMap() with
SeekMap.UNSEEKABLE if there isn't an index in the stream, so DASH playbacks
will end up printing this warning every 5 seconds or so. This is obviously
not desirable, so this CL just removes the warning! The alternative would
have been to print a warning if the value is anything other than UNSEEKABLE,
but it doesn't really seem worth it.
Prior to this change, there was a bug where playback would
fail with the following steps:
1. Start playback.
2. Pause playback.
3. Disable all renderers.
4. Enable at least one renderer.
5. Resume playback.
