This is a preliminary step toward adding a DataSpec.Builder,
which is needed for sanity when adding DataSpec.customData.
The existing absoluteStreamPosition field is very error prone,
because anyone using a Builder to adjust the request position
will need to remember to adjust two values:
dataSpec
.buildUpon()
.setAbsoluteStreamPosition(x)
.setPosition(x)
.build();
Furthermore, the difference between position and
absoluteStreamPosition is irrelevant in nearly all cases. In
the core library, the difference is only relevant when initializing
AES encryption/decryption to write/read cache files.
Replacing absoluteStreamPosition with uriPositionOffset will
simplify the code block above to:
dataSpec
.buildUpon()
.setPosition(x)
.build();
PiperOrigin-RevId: 294485644
Passing EXT-X-KEY DrmInitData through the FragmentedMp4Extractor
doesn't work for streams with key rotation, because an extractor
instance is used for multiple segments, but is only passed the
EXT-X-KEY DrmInitData corresponding to the first segment.
This change removes passing DrmInitData through the extractor,
and instead passes it via FormatAdjustingSampleQueue. This is
in-line with how manifest DrmInitData is handled during DASH
playbacks.
Issue: #6903
PiperOrigin-RevId: 292323429
This is a nice-regardless improvement to SampleQueue, which will
likely to used to fix the referenced issue. It makes it possible
for SampleQueue subclasses to support dynamic changes to format
adjustment in a non-hacky way.
Issue: #6903
PiperOrigin-RevId: 292314720
First cl towards DefaultMediaSourceFactory (<unknown commit>) does not change the MediaSourceFactory interface except adding @Nullable anotations to setters.
PiperOrigin-RevId: 290269640
This method has two use cases:
1. Seeking. Calls are immediately preceded by a call to rewind(), and
the returned value isn't important unless it's ADVANCED_FAILED (i.e.
the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
in which case the caller wants to treat it as 0.
This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.
This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!
Issue: #6155
PiperOrigin-RevId: 290053743
As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and
init on the playback thread, matching the thread access comments.
Issue:#6321
PiperOrigin-RevId: 289167981
This offset allows to improve the calculated live offset because it
can take known client-server time offsets into account.
PiperOrigin-RevId: 285970738
Finailzed logic to update the `SampleQueue` write positions (first index) to push these into `HlsMediaChunk` when the track is initially created (from the Extractor output) and as each new chunk is queued to load (`init()` callback).
Add lots of debuging prints that can come out for the final merge.
Code is very close to a clone of `ChunkSampleStream`.
DASH implements this feature, extend the feature for HLS as well. First change just drops video samples.
For demuxed audio the audio samples will continue to play out to match the
dropped video, so need to keep indexes in all the sample queues related to a chunk and discard them all.
This is a minor change ahead of merging a full variant of
https://github.com/google/ExoPlayer/pull/6706, to make
re-buffers less likely.
Also remove variable substitution when parsing
AVERAGE-BANDWIDTH (it's not required for integer attributes)
PiperOrigin-RevId: 283554106
Calls to new Handler() without arguments are deprecated as of the latest Android
version. Replace them by a Util.createHandler call similar to the ones we
already have.
PiperOrigin-RevId: 283532891
Update it to throw if hasNext() is false, to match Java's Iterator
interface.
This also simplifies the null-checking annotations required
PiperOrigin-RevId: 277059766
@MonotonicNonNull is not useful if the variable is final, because it's only
assigned once and guaranteed to keep it's current nullability in the same
way as @MonotonicNonNull ensures it's kept non-null after checking.
This way, the workarounds can also be removed.
PiperOrigin-RevId: 275428656
Use composition instead.
This makes the null-handling more explicit & complete (previous implementation
tried to prevent null values, but didn't override all mutation methods
e.g. replace(), putIfAbsent() etc.)
PiperOrigin-RevId: 274778513
*** Original commit ***
Remove null-ness of muxedCaptionFormats list
Pre-work for removing HlsMasterPlaylist and HlsPlaylistParser from null-checking
blacklist.
***
PiperOrigin-RevId: 274591502
This method allows the player to figure out whether we still have an ongoing
load even if LoadControl.shouldContinueLoading returns false.
PiperOrigin-RevId: 272445577
This flag is currently merged into Window.isDynamic, which isn't always true
because
1. A window can be dynamic for other reasons (e.g. when the duration is still
missing).
2. A live stream can be become non-dynamic when it ends.
Issue:#2668
Issue:#5973
PiperOrigin-RevId: 271999378
