- 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.
It was possible for a codec input buffer to be filled with two frames' worth of
data, if seekTo was called after populating a buffer, if waitingForKeys was true
and seeking did not trigger a flush. This caused the CryptoInfo to be configured
as if the input buffer contained a large amount of reconfiguration data as
cleartext.
Move resetting waitingForKeys to flushCodec, so that we don't try to read the
next sample from the source until the first one has been consumed or discarded.
Also remove uriIsFullStream. It's not doing anything particularly
useful, so I think it makes sense to remove it from the public API;
it's unlikely anyone is using it.
Issue: #329
For fields encoded using UTF-16 or UTF-16BE charsets when looking for
termination character we have to look for two zero consecutive bytes.
Otherwise, as many characters encoded with UTF-16 or UTF-16BE has one
of their 2 bytes set with the value zero, we will be truncating text
fields.
- Added support for ID3 frames of types GEOB and PRIV.
- GEOB type is commonly used by dynamic ads provider to include in the
stream information about the ads to be played.
- PRIV type is commonly used for time synchronization (example:
synchronizing playback of a live stream and its webvtt captions) and
also by analytics companies to include tracking information in the
stream.
- Added a sample stream from Apple that contains ID3 metadata.
Note: I'm fairly confident that NetworkLoadable.Parser implementations
can live without the inputEncoding being specified. But not completely
100%...
Issue: #311
Issue: #56
The return value here assumed that the time being searched for
was beyond the start time of the last segment. This fix also
handles the case where the time is prior to the start of the
first segment.
Clear stale blacklist in getChunkOperation before getting next variant.
This ensures:
1.- Player resilience to failures, always trying to look for a working
playlist that allows player to non stop playback.
2.- High quality blacklisted playlists can be reused in case they go up
after a failure. Player always trying to provide the best user
experience.
Added an expiration time field to playlists blacklisted to allow
Exoplayer to continue playback when playlists that failed were
recovered from a bad state.
In live environments, some times occur that primary encoder stop
working for a while. In that cases, HLS failover mechanism in the
player should detect the situation and “switch” to playlists served by
the backup encoder (in case a backup encoder exists). This was well
managed before these changes.
However, and to ensure a playback experience that can recover itself
from temporary issues, we cannot blacklist a playlist forever. When
streaming live events using HLS, it is quite typical that the player
needs to switch from primary to backup playlists, and from backup to
primary ones, from time to time to have playback working when temporary
issues in the network/encoder are happening. Most of the issues are
recoverable, so what I have implemented is a mechanism that makes
blacklisted playlist to be available again after a while (60 seconds).
Evaluation of this algorithm should happen just when something fails.
If player is working with a backup playlist, it shouldn’t switch to the
primary one at least something fail.
Support is provided for the following schemes:
urn:mpeg:dash:utc:direct:2012
urn:mpeg:dash:utc:http-iso:2014
urn:mpeg:dash:utc:http-xsdate:2012
urn:mpeg:dash:utc:http-xsdate:2014
- Data needs to be unescaped before it's passed to SeiReader.
- SeiReader should loop over potentially multiple child messages.
- I also changed the sample passed to the EIA-608 renderer so that
it's the entire sei message payload. The first 8 bytes are
unnecessary, but it seems nicer conceptually to do it this way.
Issue: #295
Previous regular expression for extracting codec information was wrong,
given a line that defines a variant it added information from “CODEC=“
text to the end of the line (including also information about
RESOLUTION or alternate rendition groups as part of the CODEC field).
This is not causing a functional problem (at least known by me)
although is making codecs field storing information that is not related
with the codec.
Some extractor implementations underneath MediaExtractor require a seekTo
call after tracks are selected to ensure samples are read from the correct
position. De-duplicating logic was preventing this from happening in some
cases, causing issues like:
https://github.com/google/ExoPlayer/issues/301
Note that seeking all tracks a side effect of track selection sucks if
you already have one or more tracks selected, because it introduces
discontinuities to the already selected tracks. However, in general, it
*is* necessary to specify the position for the track being selected,
because the underlying extractor doesn't have enough information to know
where to start reading from. It can't determine this based on the read
positions of the already selected tracks, because the samples in these
tracks might be very sparse with respect to time.
I think a more optimal fix would be to change the SampleExtractor
interface to receive the current position as an argument to selectTrack.
For our own extractors, we'd seek the newly selected track to that
position, whilst the already enabled tracks would be left in their
current positions (if possible). For FrameworkSampleExtractor we'd
still have no choice but to call seekTo on the extractor to seek all
of the tracks. This solution ends up being more complex though, because:
- The SampleExtractor then needs a way of telling DefaultSampleSource
which tracks were actually seeked, so that the pendingDiscontinuities
flags can be set correctly.
- It's a weird API that requires the "current playback position to seek
only the track being enabled"
So it may not be worth it! I think this fix is definitely good for now,
in any case.
Issue: #301
- This change:
1. Extracts HlsExtractor interface from TsExtractor.
2. Adds AdtsExtractor for AAC/ADTS streams, which turned out to be
really easy.
Selection of the ADTS extractor relies on seeing the .aac extension.
This is at least guaranteed not to break anything that works already
(since no-one is going to be using .aac as the extension for something
that's not elementary AAC/ADTS).
Issue: #209
