- There's definitely potential for more code sharing in these
classes, but deferring for now.
- Also made no-scheme default to file://, and allowed smoothstreaming
URLs to be specified with or without the /Manifest suffix.
Before preparation, and when seeking, Mp3Extractor did not handle retrying:
- synchronizedHeader was set before the header was known to be valid, which
means that after seeing one valid frame header and then failing to read, the
synchronization would be treated as complete.
- The input buffer would keep data loaded during synchronization but on the next
call to synchronize when retrying it was not returned to the mark position to
re-parse the data.
This change fixes these issues.
- 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
When I moved the id3Reader instantiation out of the while
loop (below where it is now) it was no longer guarded by
the streamTypes.get(streamType) deduping check. This brings
back an equivalent check.
When a XING header is present but not usable (due to missing fields), CBR
seeking can be used instead. It relies on the bitrate. The bitrate from the
unusable XING header is not correct, which leads to incorrect seeking.
Also fix VBRI seeking by setting the correct offset on the frame to parse. Few
people seem to use that format, but I have found two very short truncated
samples which were falling back to the CBR case before but are using VBRI with
this change.
When a passthrough AudioTrack is replaced (due to seeking) the new one behaves
as if it is still emptying data from the old one, with its playback position
advancing until it runs out of data.
Data written while the 'old' AudioTrack was emptying would be discarded, so
avoid writing to the new AudioTrack while the old one is still emptying.
Also avoid using AudioTrack.getTimestamp with passthrough tracks, as this causes
the playback position to jump to a position that breaks audio/video
synchronization.
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
1. prepare() needs to load a TsChunk to actually prepare the source.
2. Source is prepared, but no tracks are enabled (this is why it's
an edge case - no-one is likely to be doing this!).
3. The TsChunk load completes.
We should not load additional chunks in this case.
For Live SmoothStreaming, referential equality checking
isn't enough (it breaks once the manifest is updated).
Updated other instances too just for consistency.
Play movies has an Allocator that attempts to allocate a single
huge byte[] up front to minimize the risk of GC pauses. This abstraction
will be required to keep that when updating them to the new Exo.
VP8 can be decoded by MediaCodec (since very early versions of android). Now that we want WebmExtractor to be general purpose, adding VP8 makes sense as it is a common use case.
This CL adds support for WebM files which have Cues present at the end of the file (i.e.) after Clusters. The file referenced in the bug can now be played back using the demo app. It adds a new flag to WebmExtractor which should be set to true only when being used through ExtractorSampleSource. All others (e.g. DASH) should not set it.
Reference file: http://demos.webmproject.org/exoplayer/glass_vp9_vorbis_cues_at_end.webm
I've found myself doing this a couple of times during local
debugging. It's harmless to have it public, and seems pretty
useful for debugging inside of the mp4 package.
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).
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.
Vorbis decoder in android MediaCodec [1] expects the last 4 bytes of the sample to be the number of samples in the current page. This definition holds good only for Ogg and is irrelevant for WebM. So we always set this to -1 (the decoder will ignore this value if we set it to -1). The android platform media extractor [2] does the same.
This works around an issue the audio track continues to play audio data written
after calling AudioTrack.pause(), which breaks rebuffering behavior (as video
can never catch up if audio continues to be consumed, in some circumstances).
Also don't increment the timestamp wrap count if the track is paused, to work
around an issue where the playback head position jumps back to zero after the
AudioTrack position jumps back to zero.
The OMX component needs to be configured with a format that has a
MIME type of audio/raw. Remove Ac3PassthroughAudioTrackRenderer,
which is no longer used.
The limit on the ts packet buffer can be reduced during processing
if it's discovered to have padding. Hence we need to reset it back
to the ts packet size before processing each packet.
- Keys should not expire during normal playbacks of correctly configured content.
- Attempting to refresh on expiration causes a race condition, that may result
in either failure or brief re-buffer, for the 30s license test video.
- This change provides deterministic behavior, which is to always fail.
Some servers, probably edge cache machines that exclusively serve
chunked media, don't support partial requests. Which is kind of
vaguely reasonable for that particular case. This change modifies
DefaultHttpDataSource to correctly handle this case, by manually
skipping data up to the requested position (and making sure not to
read more data than the requested length).
- Have extractors read from an ExtractorInput. Benefits of this are
(a) The ability to do a "full" read or skip of a specified number
of bytes, (b) The ability to do multiple reads in your extractor's
read method. The ExtractorInput will throw an InterruptedException
if the read has been canceled.
- Provides the extractor with the ability to query the absolute
position of the data being read in the stream. This is needed for
things like parsing a segment index in fragmented mp4, where the
position of the end of the box in the stream is required because
the index offsets are all specified relative to that position.
- Move to builder naming.
- Propagate formats to the TrackOutput instances, rather than having
them be read through the Extractor. There was actually some weird
indexing going on here before (which happened to work, but wasn't
well defined).
As per http://tools.ietf.org/html/draft-pantos-http-live-streaming-04#section-5.2,
the initializaton vector (IV) of the AES decryption algorithm should be set to:
- the IV attribute value if present,
- the sequence number otherwise.
Currently, the IV is set once and use over all next media sequences
where the IV attribute is not set. The fix is to use the provided IV if
given or use the current media sequence number.
- It's probably easiest to think of this as a standalone HLS change, which is splitting out the "loading" and "consuming" sides of HlsExtractor and a good structural change in its own right. To do this, HlsExtractorWrapper becomes a final class implementing the consuming side. HlsExtractor becomes an interface defining the loading side.
- The bigger picture is that, hopefully, HlsExtractor will become a lightweight extractor interface that can be used throughout the library. Because it doesn't need to implement the consuming side, we'll save on having to re-implement the consuming side for every extractor (we'll probably need one consuming side implementation for HLS/DASH/SmoothStreaming, and a second one for everything else, both of which will use SampleQueue). It's expected that the HlsExtractor interface will need to change to accommodate all use cases.
- The next step in unification will be to try and have FragmentedMp4Extractor implement HlsExtractor (which will need renaming). Once this is done, I'll try and move the chunk package over to use the HlsExtractor interface.
- This is a step toward hopefully converging HLS and CHUNK packages.
- Add support for encrypted samples.
- Add support for appending from a DataSource.
- 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.
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
I think this is the limit of how far we should be pushing complexity
v.s. efficiency. It's a little complicated to understand, but probably
worth it since the H264 bitstream is the majority of the data.
Issue: #278
Use of Sample objects was inefficient for several reasons:
- Lots of objects (1 per sample, obviously).
- When switching up bitrates, there was a tendency for all Sample
instances to need to expand, which effectively led to our whole
media buffer being GC'd as each Sample discarded its byte[] to
obtain a larger one.
- When a keyframe was encountered, the Sample would typically need
to expand to accommodate it. Over time, this would lead to a
gradual increase in the population of Samples that were sized to
accommodate keyframes. These Sample instances were then typically
underutilized whenever recycled to hold a non-keyframe, leading
to inefficient memory usage.
This CL introduces RollingBuffer, which tightly packs pending sample
data into a byte[]s obtained from an underlying BufferPool. Which
fixes all of the above. There is still an issue where the total
memory allocation may grow when switching up bitrate, but we can
easily fix that from this point, if we choose to restrict the buffer
based on allocation size rather than time.
Issue: #278
- Remove TsExtractor's knowledge of Sample.
- Push handling of Sample objects into SampleQueue as much
as possible. This is a precursor to replacing Sample objects
with a different type of backing memory. Ideally, the
individual readers shouldn't know how the sample data is
stored. This is true after this CL, with the except of the
TODO in H264Reader.
- Avoid double-scanning every H264 sample for NAL units, by
moving the scan for SEI units from SeiReader into H264Reader.
Issue: #278
The complexity around not enabling the video renderer before it
has a valid surface is because MediaCodecTrackRenderer supports
a "discard" mode where it pulls through and discards samples
without a decoder. This mode means that if the demo app were to
enable the renderer before supplying the surface, the renderer
could discard the first few frames prior to getting the surface,
meaning video rendering wouldn't happen until the following sync
frame.
To get a handle on complexity, I think we're better off just removing
support for this mode, which nicely decouples how the demo app
handles surfaces v.s. how it handles enabling/disabling renderers.
Reordering in the extractor isn't going to work well with the
optimizations I'm making there. This change moves sorting back
to the renderer, although keeps all of the renderer
simplifications. It's basically just moving where the sort
happens from one place to another.
I'm not really a fan of micro-optimizations, but given this method
scans through every H264 frame in the HLS case, it seems worthwhile.
The trick here is to examine the first 7 bits of the third byte
first. If they're not all 0s, then we know that we haven't found a
NAL unit, and also that we wont find one at the next two positions.
This allows the loop to increment 3 bytes at a time.
Speedup is around 60% on Art according to some ad-hoc benchmarking.
1. AdtsReader would previously copy all data through an intermediate
adtsBuffer. This change eliminates the additional copy step, and
instead copies directly into Sample objects.
2. PesReader would previously accumulate a whole packet by copying
multiple TS packets into an intermediate buffer. This change
eliminates this copy step. After the change, TS packet buffers
are propagated directly to PesPayloadReaders, which are required
to handle partial payload data correctly. The copy steps in the
extractor are simplified from:
DataSource->Ts_BitArray->Pes_BitArray->Sample->SampleHolder
To:
DataSource->Ts_BitArray->Sample->SampleHolder
Issue: #278
- TsExtractor is now based on ParsableByteArray rather than BitArray.
This makes is much clearer that, for the most part, data is byte
aligned. It will allow us to optimize TsExtractor without worrying
about arbitrary bit offsets.
- BitArray is renamed ParsableBitArray for consistency, and is now
exclusively for bit-stream level reading.
- There are some temporary methods in ParsableByteArray that should be
cleared up once the optimizations are in place.
Issue: #278
