ac3Bitrate is set only after the first buffer is handled, which meant that
getting the playback position would cause a divide by zero before then.
When playing back AC-3 content, the ac3Bitrate will always be set after the
first buffer is handled, so return a 0 position if it is not set.
- Adds support for dash manifests that define SegmentTemplate
but no SegmentTimeline.
- Assumes that the device clock is correct when calculating which
segments to load. The final step here is to use the Utc timing
element in the DASH manifest to obtain an accurate client clock.
- Doesn't yet enforce that the client shouldn't load segments that
are in the future or behind the live window.
This fixes the referenced issue, except that the MPD parser
needs to actually parse out UUID and binary data for schemes
that we wish to support. Alternatively, it's easy to applications
to do this themselves by extending the parser and overriding
the parseContentProtection and buildContentProtection methods.
Github Issue: #119
It's cleaner to not inject data into the extractor only
so that it can be read out as though it were parsed from
the stream. This is also an incremental step towards
fixing Github issue #119.
Note: This adds support for the majority of DASH live streams,
however we do not yet correctly support live streams that rely
on UtcTimingElements in their manifests.
Issue: #52
Plus start to properly document the SmoothStreaming package.
Note that where the documentation is a little vague, this is
because the original SmoothStreaming documentation is equally
vague!
- Split sample pools for video/audio/misc, since the typical
required sample sizes are very different (and so it becomes
inefficient to use a sample sized for video to hold audio).
- Add TODO for further improvements.
Issue: #174
The timestamp scaling in SegmentBase.getSegmentTimeUs was
overflowing for some streams. Apply a similar trick to that
applied in the SmoothStreaming case to fix it.
- Move all three buffering constants to a single class (the
chunk source).
- Increase the target buffer to 40s for increased robustness
against temporary network blips.
- Make values configurable via the chunk source constructor.
- Treat captions as a text track for HLS. This allows them to
be enabled/disabled through the demo app UI.
Issue: #165
- Add options to switch abruptly at segment boundaries. Third
parties who guarantee keyframes at the start of segments will
want this, because it makes switching more efficient and hence
rebuffering less likely.
- Switch quality faster when performing a splicing switch (when
we detect that we need to switch variant, we now immediately
request the same segment as we did last time for the new variant,
rather than requesting one more segment for the old variant
before doing this.
1. Correctly replace the AES data source if IV changes.
2. Check the largest timestamp for being equal to MIN_VALUE, and
handle this case properly.
3. Clean up AES data source a little.
Issue: #162
The actual fix here is to not call discardExtractors in HlsSampleSource
whilst the loading thread that's pushing data into it is still running.
It's required to wait for that thread to have exited before doing this.
Issue: #159
Looking up a long in a HashSet<Long> auto boxes the long and leaves
it for the GC. As decodeOnly is relatively infrequent it's much
better to do a simple linear search in a List<Long>. That way
we can avoid boxing every incoming time stamp value. In the general
case this will be linear searching in an empty list, a very fast
operation.
Signed-off-by: Jonas Larsson <jonas@hallerud.se>
AudioTrack contains the portions of MediaCodecAudioTrackRenderer that handle the
platform AudioTrack instance, including synchronization (playback position
smoothing), non-blocking writes and releasing.
This refactoring should not affect the behavior of audio playback, and is in
preparation for adding an Ac3PassthroughAudioTrackRenderer that will use the
AudioTrack.
Passing uncropped dimensions to certain decoders will make them
output frames without proper cropping set.
Signed-off-by: Jonas Larsson <jonas@hallerud.se>
- Add a readBit method to BitsArray for reading a boolean flag.
- Make things accessed from inner classes package visibility to avoid
the compiler generating thunk methods.
- The HlsSampleSource now owns the extractor. TsChunk is more or less dumb.
The previous model was weird, because you'd end up "reading" samples from
TsChunk objects that were actually parsed from the previous chunk (due to
the way the extractor was shared and maintained internal queues).
- Split out consuming and reading in the extractor.
- Make it so we consume 5s ahead. This is a window we allow for uneven
interleaving, whilst preventing huge read-ahead (e.g. in the case of sparse
ID3 samples).
- Avoid flushing the extractor for a discontinuity until it has been fully
drained of previously parsed samples. This avoids skipping media shortly
before discontinuities.
- Also made start-up faster by avoiding double-loading the first segment.
Issue: #3
The key change here is that nextLoadPositionUs is set to -1
if we're not loading but don't have a next chunk ready to
load. This ensures that "missing chunks" in one stream don't
prevent chunks in another stream from loading. This occurs
in SmoothStreaming with TTML subtitles, where the chunks are
sparse.
Propagate elapsedRealtimeUs to the video renderer. This allows
the renderer to calculate and adjust for the elapsed time since
the start of the current rendering loop. Typically this is <2ms,
but there situations where it can go higher (normally when the
video renderer ends up processing more than 1 output buffer in
a single loop).
Also made variable naming more consistent throughout the package.
- Move parsing onto a background thread. This is analogous
to how frame decoding is pushed to MediaCodec, and should
prevent possible jank when new subtitle samples are parsed.
This is more important for out-of-band subtitles, which can
take a second or two to parse fully.
- Add Useful DataSpec method.
- Use native frame release timing in video renderer for
smoother video playback.
- Avoid unnecessary memory copy steps in audio renderer.
- Use non-blocking AudioTrack API.
Previously we'd end up blocking forever in this case, which
is the worst thing we could do :). We could either throw an
exception or just print a warning. Printing a warning is more
in line with what other methods do (Handler prints a "sending
message to dead thread" warning).
This allows ManifestFetcher to both execute the initial
manifest load and be plugged into an ExoPlayer ChunkSource,
where it can be used for repeated manfiest refreshes during
live playback.
