An accumulation of several fixes:
1. Change to HlsExtractorWrapper is just a move + documentating
things that were already true + adding a precondition in the
configureSpliceTo method.
2. Change in HlsSampleSource.readData ensures that configureSpliceTo
and hasSamples aren't called on an extractor that isn't prepared.
3. The other change in HlsSampleSource ensures the correct "previous"
TsChunk is used. If a TsChunk fails to load and is replaced, the
previous chunk should be the one before that whose load completed
successfully.
4. Determine switchingVariantSpliced based on the actual format of the
previous chunk, so it's set correctly in the case of a TsChunk load
failure and subsequent replacement.
This fixes the case where we need to switch from one variant to
another during preparation, having loaded zero samples, because
the first chunk for that variant gave us a 404 error. In this
case the first extractor will have no samples, and there will
be a second extractor that does.
There was a mess where we were indexing into both a list of variants
and a (differently ordered and possibly of differing length) list of
formats. This sanitises everything.
1. Refine the way TtmlNode handles whitespace collapsing when constructing
the output text. Can of worms.
2. Start using SpannableStringBuilder. This will allow attaching of spans
in getText as nodes are encountered, which is how we'll be incorporating
styling information into the result.
1. Remove requirement for TrackRenderer implementations to report
current position, unless they are time sources.
2. Expose whether renderers have media to play. The immediate benefit
of this is to solve the referenced GitHub issue, and also to only
display the appropriate Audio/Video/Text buttons in the demo app
for the media being played. This is also a natural step toward
multi-track support.
Github issue: #541
- Fix bug where duration of initially disabled tracks wasn't correctly
incorporated into the overall duration reported by the player.
- Don't transition to STATE_ENDED unless the position has reached the
duration, if the duration is known. This allows for "playback" to
continue when all renderers are disabled, rather than jumping straight
to STATE_ENDED.
- contentType can be defined on an AdaptationSet.
- language can be defined either in AdaptationSet or in a contained
ContentComponent.
- The id from the AdaptationSet should come from the AdaptationSet.
to if the playlist load fails.
NB - I'm aware the casting is a bit messy, but I don't want a common
interface because I'm hopeful that TsChunk will go away at some point.
Issue: #537
* fix channel number encoding using the AUDIO_SPECIFIC_CONFIG_CHANNEL_COUNT_TABLE
* allocate the correct number of bits (4) int the CodecSpecificDataUtil struct
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.
This OMX component is listed but can't be instantiated on this device.
According to the GitHub issue, some other devices are also affected, so these
will have to be added too.
Issue: #377
They're current location is annoying, because it creates a dependency
from the dash package to the webvtt package. For apps like Play Movies
where WEBVTT isn't used, it's nice just to delete the whole package at
import time, which requires that this dependency be removed.
- 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.
