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
