ExoPlayer's traditional HLS preparation works by loading a chunk from each track
group, and then tries to use the sample information plus the master playlist
information to generate the preparation's resulting TrackGroups.
There are 3 possible scenarios:
- Supported case: Each variant has a single codec string per track type. We can
assign each track the codec string which matches the loaded sample's type.
- Supported case: Each variant has more than one codec string, but each track
group has a single track. This is the case when different languages use
different codecs. In this case, we can assign whichever codec matches the
loaded sample's mime type.
- Unsupported case: Each variant has more than one codec string, and track
groups contain more than one track. We are not able to safely map tracks to
codec strings because that would require loading a chunk from each track
(which would considerably delay preparation).
Broken in:
4783c329cc
PiperOrigin-RevId: 343072201
This only has a couple of simple tests for now. We'll add more tests
after we've written some concrete sub-class tests for various
DataSource implementations.
I've included a concrete FileDataSourceContractTest as a demonstration.
PiperOrigin-RevId: 342851187
This ensures the buffer is not full when the `DefaultLoadControl` determines
whether we should continue loading and thus prevents a false warning about
not having enough memory left.
PiperOrigin-RevId: 342616623
This requires the parent of the background to draw and have padding large enough to support the size of the ripple.
The bottom buttons must remained bordered as the space around them is constrained.
PiperOrigin-RevId: 342162231
Add experimental method to synchronize MediaCodec interactions
with asynchronous queueing. When the feature is enabled, interactions
such as MediaCodec.setOutputSurface() triggered by the
MediaCodecRenderer will wait until all input buffers pending queueing
are first submitted to the MediaCodec.
PiperOrigin-RevId: 341423837
To check what is safely possible we keep track of the live offset
corresponding to the buffered duration and only deecrease the
target offset to a safe margin from the buffered duration.
Also, while still possible (i.e. while the actual offset is larger
than the safe margin), we increase the target offset to the safe
margin to avoid rebuffers to start with.
Issue: #4904
PiperOrigin-RevId: 341396492
Add more MediaCodec methods to MediaCodedAdapter so that renderers
interact with the MediaCodec through the MediaCodecAdapter.
PiperOrigin-RevId: 341023452
- This change removes the last piece of logic that could cause deferred
codec release (i.e., where the decision to release was made in
processEndOfStream rather than in onInputFormatChanged.
- After this change, whether the codec will be released as a result of
a format change is always established in onInputFormatChanged.
PiperOrigin-RevId: 341012403
This fixes a case where updateCodecOperatingRate would configure
the decoder to be drained and then released, only for
onInputFormatChanged to override the drain action with something
else.
We've not seen any reports of this issue, which suggests that either
it's OK to not release the decoder in such cases, or that the
case doesn't happen very often. I suspect that it's both, but let's
restore the intended behaviour for now.
PiperOrigin-RevId: 340909132
This information is already available in the MappingTrackSelector,
but not currently forwarded to the TrackSelection.Factory.
This makes it more complicated (or impossible) to depend on period
or manifest information in the track selection (for example to only
select tracks which are cached for the current format).
PiperOrigin-RevId: 340605886
In a later change, the AdPlaybackState will include the playing adsId (set by
the AdsLoader) and the ads loader will use this to determine what ad
information is associated with the playing/next periods, to allow loading ads
in playlists.
Apps can continue to pass just a URI for an ad tag with their MediaItem, in
which case the associated playlist will request that ad tag just and the same
state will be used for all occurrences of the ad tag.
This change has breaking changes to the AdsLoader interface and removes
deprecated ways of passing the ad tag, as it's very likely to go into a major
release anyway and not needing to handle the deprecated cases simplifies
ImaAdsLoader.
Issue: #3750
PiperOrigin-RevId: 340438580
1. Move logic to decide to re-initialize the codec rather than using
MediaCodec.setMediaDrmSession if (a) PlayReady is in use, and (b)
the new session is still provisioning. This would previously have
happened asynchronously after an input format change, after the
decoder has subsequently been flushed. After this change the logic
executes synchronously when the input format changes. This helps
with the ref'd bug, since we want to propagate reasons for codec
re-initialization through inputFormatChanged events.
2. Whilst moving the logic for re-initialization if PlayReady is
being used, I fixed a bug that would occur when switching from
[PlayReady --> non-PlayReady]. Re-use doesn't work in this case.
The old logic only checked for the [Something --> PlayReady] case.
3. Remove pointless codec flush if updating the DRM session having
not queued anything to the codec.
PiperOrigin-RevId: 340299790
- I don't think the session recovering later would work, because
the codec will be configured not to use it.
- I'm not sure session recovery makes sense in general, and our
implementations do not do this. Document it as a terminal state
for now.
PiperOrigin-RevId: 340204194
This avoids confusion that currently exists between "operating rate"
and "codec operating rate", which are different. It also tightens the
requirement of the value being passed to be more than a "hint". It's
already being used as more than a hint for setting the Surface frame
rate.
PiperOrigin-RevId: 340201829
Some content types always provide the license URL in the media.
The PlayReady example in the demo app doesn't provide a default
license URL for this reason, as an example.
#minor-release
PiperOrigin-RevId: 340125784
This change will be followed up by:
- Changes adding APIs to enable the use of MediaParser in each of the supported
media sources.
- Changes removing TODOs related to the change of the stable SDK to API 30.
PiperOrigin-RevId: 339556777
In order to ensure we can update the values for new manifests but still use
the user provided override, we need to save the original and the updated MediaItem
seperately.
And in order to incorporate the existing logic for the min/max supported live
offset, which we already use to correct the target offset, also move both places
together so that all the adjustment happens in one place.
Logical adjustments to the previous min/max supported live offset:
- Use the user-provided MediaItem values if set
- Use the newly parsed ServiceDescription values if available.
- Limit the minimum to 0 if the current time is in the window and we can
assume to have low-latency stream.
- Add minBufferTime from the manifest to ensure we don't reduce the live
offset below this value.
Issue: #4904
PiperOrigin-RevId: 339452816
Logic for determining if (and how) decoders can be adapted is
currently split between renderers and MediaCodecInfo. This change
centralizes the majority of the logic in MediaCodecInfo.
This change also fixes a bug in MediaCodecAudioRenderer when computing
max values for the codec. Previously, max values would not be increased
to account for potential adaptation to another stream in the case that
the codec needs to be flushed for the adaptation to occur.
PiperOrigin-RevId: 339133416
Refactor the AsynchronousMediaCoderAdapter and move the callback thread
out of the adapter so that implementation of async callback and and
async queueing are consistent design-wise.
PiperOrigin-RevId: 338637837
