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
We were previously using the container format of the media being
played as the mimeType generating key requests, but this is not
always correct. As an example, where a manifest contains webm streams
but specifies initialization data using cenc:pssh elements in the
manifest, the media has a webm mimeType, but the DRM initialization
data has an mp4 mimeType.
Added the property 'id' to the MediaFormat class
which serves as an identifier for the track.
DASH Representations will have the "id's" from their
Media Presentation Description mapped to the id property
in the MediaFormat class that will represent the track.
We needed this for an use case where we wanted to read the 'id'
value from the DASH representation and present it to the user
in order for the user to select the right track.
When a live stream ends, what typically happens is that the manifest
is refreshed and the refreshed version is not marked as live/dynamic.
When this happens we:
1. Don't want the duration of the track to change.
2. Still want to consider the possibility that we may have fallen behind
the live window.
3. Don't want to allow futher manifest refreshes.
This change uses the right thing in the right place.
- 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
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.
For Live SmoothStreaming, referential equality checking
isn't enough (it breaks once the manifest is updated).
Updated other instances too just for consistency.
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).
- 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.
Note: I'm fairly confident that NetworkLoadable.Parser implementations
can live without the inputEncoding being specified. But not completely
100%...
Issue: #311
Issue: #56
