- 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.
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.
ChunkSampleSource had a null check solely for the VTT case,
where DashChunkSource wasn't setting a MediaFormat on VTT
chunks. It's trivial to do so, and is more consistent, so I've
done that and removed the null check. Also done some small
tidying.
- Make HlsPlaylistParser treat non-positive dimensions as unknown.
- Make HlsPlaylistParser parse floating point resolutions, because
technically that's how they're spec'd.
- Make VideoFormatSelectorUtil treat non-position dimensions as unknown.
Issue: #461
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
For Live SmoothStreaming, referential equality checking
isn't enough (it breaks once the manifest is updated).
Updated other instances too just for consistency.
On retrying loading a chunk, the state of the extractor was reset due to a call
to seek(). Prevent this call by only calling init() if no bytes were loaded.
Also make the DefaultExtractorInput use the loading position not the original
stream position so that its getPosition() method returns offsets relative to
the start of the stream, which fixes a bug where the chunk index offsets would
be relative to the wrong position if there was a retry while loading the chunk.
- The fmp4 extractor was reading from sampleEncryptionData even
for not-encrypted samples, which I'm pretty sure isn't right.
Fixed this. For all encrypted content I've seen, this change
will be a no-op because isEncrypted is always true if there's
an encryptionBox present.
- Made webm extractor only set cryptoInfo if isEncrypted is true.
- Align variable naming in the two extractors, for clarity.
- Rather than returning a map, return a DrmInitData object,
with mapped and non-mapped implementations.
- Include a suitable mimeType to pass to the MediaDrm. Previously
we were incorrectly passing the mimeType of the samples,
where-as MediaDrm expects the container mimeType. Note that
it doesn't matter whether the mimeType starts with "video" or
"audio", hence using video mimeTypes everywhere.
