- Add a top level failure type (source/renderer/unexpected),
and convenience methods for retrieving the underlying cause
without needing to cast.
- Also add renderer index in the case of renderer failures.
- setIndex/getIndex is a little . . . unclean, but alternatives
involve either having the top line of the stack trace be a
non-interesting line, or loads of try/catch blocks in
ExoPlayerImplInternal.
Issue: #777
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114763073
- 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
As part of this change, Extractor.sniff may read/skip (not just peek) if it
returns true. This allows Extractors to avoid parsing the input a second time in
read.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112683272
This makes sense until we need to support seeking in the live window.
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112402026
Also apply the workaround for the secure variant of OMX.SEC.avc.dec.
Note that it's not necessary to do the same for the RK decoder in
the method below, since that workaround is targeted at SDK_INT<=17
and secure decoders only came along in 18.
Issue: #603
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112395376
After this change, AC-3 uses about 20 KB and DTS uses 49 KB.
For comparison, 'normal' PCM playbacks use by default (depending on the device
and input format) about 45 KB. For passthrough, the following buffer sizes were
used before this change:
- Nexus Player AC-3: 23 KB
- Nexus Player DTS: 25 KB
- NVIDIA Shield AC-3: 15 KB
- NVIDIA Shield DTS: 16 KB (caused underruns in some DTS-HD playbacks)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112254836
Using the provided methods by the previous refactors, it is now possible to use all of the WebVTT features already available.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112243172
The TTML 1 spec. defines an exact RGBA color tuple as #rrggbbaa
See https://www.w3.org/TR/ttml1/#style-value-color
Android's internal representation is ARGB.
The correct parsing therefore requires a bit of extra byte shuffling ...
I'm not really sure how best to document this in TrackRenderer;
it's a bit of a weird feature. For now, I've gone with the vague
approach.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112150939
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 CL exposes the cue settings parser in order to allow its usage from the MP4Webvtt extractor. Also fixes a few mistakes from the previous related CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112145806
* AudioTagPayloadReader was strangely parsing an audioSpecificConfig
itself, using the parsed values to build a new audioSpecificConfig,
then passing the newly constructed instance to be parsed by
CodecSpecificDataUtil. Unfortunately the translation was lossy ;).
* Treat Duration=0 as an unknown duration.
Issue #1137
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112143569
- I think \r and \n are handled the wrong way around?
- We only expect to encounter a BOM sequence at the start of a
file, but it feels fine to automatically discard it in all
cases for simplicity. A BOM sequence doesn't mean anything in
UTF-8. See https://en.wikipedia.org/wiki/Byte_order_mark. Note
that I think the advice not to remove it on that page relates
only to the case where the file is being edited + saved.
Issue #1136
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112143407
There are multiple issues with HlsSampleSource's use of
LoadControl that become apparent when you attempt to use
the same LoadControl for loads by another source.
* In the "limbo" state HlsSampleSource doesn't start any
new loads, but doesn't update the LoadControl to tell
it that it doesn't want to load anything either. This
can prevent another source from starting the loads that
it needs to make to complete preparation, causing
playback to become stuck.
* The LoadControl isn't updated properly when the EOS is
reached. This can cause playback to become stuck near
the end of the media.
* If HlsSampleSource is released from being in the "limbo"
state, it doesn't unregister itself with the control.
Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111942009
Given we need to do this in HlsPlaylistParser in the normal
case (i.e. not MEDIA_TAG), we may as well just be consistent
and do it everywhere.
Issue: #151
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111941335
Currently only supports a single offset to the full media timeline
(indicated by a duration of 0). This is most often used to fix the
non-zero starting presentation timestamp introduced when B-frames
are present.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111816916
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 is a no-op change for clarity only. maxWidth/maxHeight
don't mean anything for AAC/MP3, so it makes sense to pass
MediaFormat.NO_VALUE in all cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111619832
Moved the behaviors related to Cue's to the WebvttCueParser class.
This way, the parsing methods will be more easily accessible to
other classes, such as the MP4Webvtt parser. This class also has
some methods that require state to avoid repetitive avoidable
allocations. The method visibility is subject to changes in
further CLs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111616824
Targeting to all API level 19 devices using the OMX.SEC.avc.dec
decoder is probably the right thing to do. It shouldn't have
negative implications if we apply the workaround on devices that
don't really need it, except to slow down seeking slightly due
to decoder re-allocation. Given we're talking about JB, I think
the priority should be to "make sure it works".
Issue: #951
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111514406
We normally expect each frame to come in its own PES packet,
but it seems that this is not always the case. This change
uses the frame rate in the stream to increment the frame
timestamp in the case of multiple frames contained within
a single PES.
Note that since we don't expect 100s of frames in a single
PES, or anything close to that really, the rounding errors
that may accumulate due to use of a frame duration should be
fine.
Issue: #1112
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111499052
This is in preparation for removing BufferingInput,
and using peeking instead.
Also add tests for peeking with allowEndOfInput and
resetPeekPosition.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111318236
This CL adds a class responsible for managing the lifecycle
of a single Choreographer to be shared among all
VideoFrameReleaseTimeHelper instances.
Issue: #1066
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110839824
This CL is prepares the ground for refactoring the Webvtt parser,
so as to use the common parsing algorithms in both parsers. In order
to do this, the Webvtt Parser will be refactored. As a side note, many
more test cases will be added once the new subtitle features are
implemented. Some useful test cases have also been left for a following
CL, to allow an easy code review.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110466914
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
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
Fix behavior of getTimeUs when seeking after the last entry in the table of
contents. Round correctly in getPosition, clipping to the stream duration based
on the input length (if known), falling back to the stream size from the header.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=109993852
Multiple identical TTML fontStyles or fontWeights or textDecorations
on the content for a specific moment were rendered as if there's only
one decoration (span).
That's because SpannableStringBuilder.setSpan(span, start, end, flag)
found an earlier set span (the static allocated span's reference
is the same each time) and only refreshed this first span's start and
end values instead of adding a new span at its (new) different range.
This patch removes the static data members;
this makes the newly allocated span objects distinguishable.
A correct implementation is favoured over worries about memory
consumption.
