For LL-HLS, the non-primary playlists originally keep reloading even after the primary playlist has been changed to another one. The reason being this is to check if the hinted(#EXT-X-PRELOAD-HINT) resource has been published or removed. If removed, the loading of it should be canceled, per the suggestion in the HLS spec:
"A Client SHOULD cancel a request for a hinted resource if it is not present in a subsequent Playlist update, such as in an EXT-X-PRELOAD-HINT tag or as part of another tag such as EXT-X-PART. The client SHOULD ignore the results of such requests."
However, keeping the non-primary playlists reloading is not optimal. As a solution, we trigger the playlist reloading only when there is a preload chunk loading instead of every time after we have processed the playlist. Compared to the original implementation, this will save the requests of reloading non-primary playlist after we have taken action upon the preload chunk being published or removed.
Issue: androidx/media#1240
PiperOrigin-RevId: 626038032
This is the preparation to import the media1 classes as
private copies into media3.
- Reword Javadoc to use @code instead of @link to media1 types. This
avoids accidentally linking to the future internal types.
- Use fully qualified names for the converter methods to and from
MediaSessionCompat.Token to ensure they keep the publicly available
type.
- Add new public variable that is directly referenced from our code
instead of referring the the media1 equivalent.
- Clean up tests that are using media1 types to make assertions on
media3 fields and vice versa (mostly when using LegacyConversions
in the test method). This also makes the tests more DAMP than DRY.
(also moved LegacyConversionsTest to a unit test as it doesn't test
cross-process communication)
PiperOrigin-RevId: 626000082
Before this CL, if all the video (resp. audio) samples were fed before
the audio (resp. video) output format was reported, the
SequenceAssetLoader was incorrectly reporting a MediaItem change with a
null format.
PiperOrigin-RevId: 625978268
For audio with more than 12 channels, no channel mask was determined, which
meant that the code to check spatializability would throw because of creating
an invalid audio format.
Return early if the channel mask was invalid instead (and assume spatialization
isn't possible).
PiperOrigin-RevId: 625618683
Transformer's input shouldn't be constrained to the number of playable audio channels on the current device because the media may be edited (to mix channels for example) or encoded for playback on another device (a server for example).
PiperOrigin-RevId: 625604243
The raw audio decoder's output audio format is stereo when the number of input
channels is (for example) 10 channels. Add a temporary workaround that uses the
input channel count for raw audio. This code should be removed in future when
we bypass the decoder entirely for raw audio.
Tested manually on a WAVE file with 18 audio channels.
PiperOrigin-RevId: 625307624
This change also switches from media3's `Log` class (marked with
`@UnstableApi`) to `android.util.Log` which is what we would expect
apps to use.
Issue: androidx/media#1283
PiperOrigin-RevId: 625252745
Before this CL, currentInputBufferBeingOutput was set to null without
adding the buffer to the queue of available buffers, which was making
this buffer unusable. After multiple seeks, playback was stuck because
the AudioGraphInput had no input buffer left.
PiperOrigin-RevId: 624943271
Before this CL, the FrameMetadataListener was set in
onReadyToInitializeCodec while it had already been set when handling
message MSG_SET_VIDEO_FRAME_METADATA_LISTENER.
PiperOrigin-RevId: 624940824
Some seek operations are currently filtered in the base classes if
the target index is not explicitly specified and the implicitly
assumed operation doesn't have an obvious target index. (Example:
calling seekToNext() at the last item in a playlist)
This is too opinionated because the actual player implementation
using this base class may be able to handle this seek request (e.g.
by adding new items on the fly or using other logic to select
the most suitable next item).
This can be solved by forwarding all seek requests to the respective
handler methods even if they are a presumed no-op. Also clarify the
Javadoc that the provided index is just an assumption if it wasn't
provided explicitly in the method call.
PiperOrigin-RevId: 624887116
Add a new string command line optional argument to allow the playback
to run in loop. This would help to use the app in the automated video
tests. The change does not enable the option view for switching the loop
mode in the UI as providing an extra argument implies force, not
optional, loop playback. The extra option is provided with "repeat_mode"
key and one of the possible modes can be specified: NONE|ONE|ALL. The
available options correspond to the Player API to ensure compability.
Before this CL, the offset was set:
- in onPositionReset for composition preview
- in onReadyToInitializeCodec for ExoPlayer
The code flow is easier to reason about if the path for both use cases
is as shared as possible.
PiperOrigin-RevId: 624870150
After this CL, Transformer will throw if the clipping start and end
positions are the same because MediaMuxer doesn't support writing a
file with no samples. This should work once we default to the in-app
muxer.
Issue: androidx/media#1242
PiperOrigin-RevId: 624861950
The previous syntax doesn't seem to work. I assume I tested it when I
wrote 2eafa570e9,
so maybe it's stopped working since? Or maybe I'm wrong and it never
worked. This syntax was originally proposed in Issue: google/ExoPlayer#6339 and
seems to work today.
PiperOrigin-RevId: 624161848
This was always intended as a debug API only, but its inclusion in media3.common and public visibility has led to partners sometimes experimenting with this API and complaining when it doesn't work as expected.
PiperOrigin-RevId: 624158798
A live window with changing duration can't be properly
displayed in a media notification. The duration constantly
changes and creates a nervous jumping seekbar that is not
really useful.
This change sets the duration for live streams to `C.TIME_UNSET`
when publishing the player state to the platform session. This
way no duration is sent to the platform session which prevents
media controls from drawing a seekbar.
Issue: androidx/media#1256
PiperOrigin-RevId: 624112541
This removes the TODOs without updating the links, because the
DAC-hosted images are not co-located with the hosted javadoc (unlike
when these images were referenced on exoplayer.dev before 10342507f7),
and therefore we would need to include the full path anyway, at which
point it seems clearer and more robust to keep using a fully-qualified
URL with the domain too.
PiperOrigin-RevId: 623452217
When delegating EMSG samples in `HlsSampleStreamWrapper`,
the offset passed into `sampleMetadata(..)` of the delegate
`TrackOutput` must be zero because it is called immediately
after `sampleData(..)` is called.
The condition to trigger this issue is that more than one
metadata samples are pending in `pendingMetadataSampleInfos`
of `FragmentedMp4Extractor` which produces non-zero offsets.
Issue: androidx/media#1002
Issue: androidx/media#1203
PiperOrigin-RevId: 623210835
