The first has a string genre, and various other values set, generated
from `sample.mp4` with the command below [1].
The second has a numeric genre, to test `gnre` atom parsing. This
parsing is currently broken, the fix is in a follow-up change. This
file was also generated from `sample.mp4` with the command below [2].
This change also includes `CommentFrame.text` in its `toString`
representation, otherwise there's no difference between e.g. different
levels of `ITUNESADVISORY` in the extractor dump files.
Issue: androidx/media#1305
-----
[1]
```shell
$ AP_PADDING="DEFAULT_PAD=0" \
AtomicParsley sample.mp4 \
--artist "Test Artist" \
--album "Test Album" \
--tracknum 2/12 \
--disk 2/3 \
--year 2024 \
--genre "Gorpcore" \
--bpm 120 \
--compilation true \
--advisory clean \
--gapless true \
--sortOrder artist "Sorting Artist" \
--sortOrder album "Sorting Album" \
--preventOptimizing \
-o sample_with_metadata.mp4
```
[2]
```shell
$ AP_PADDING="DEFAULT_PAD=0" \
AtomicParsley sample.mp4 \
--genre "Metal" \
--preventOptimizing \
-o sample_with_numeric_genre.mp4
```
PiperOrigin-RevId: 628345458
Before this CL, the video sink was not reconfigured for the second video
in a sequence with video-image-video. For example, the stream offset
and listener were not set for the second video.
PiperOrigin-RevId: 628065991
Instead of initializing the video sink outside the renderer with an
empty format for composition preview, we initialize it in the renderer
with the input format for video.
PiperOrigin-RevId: 627313708
When playing a Composition, the color transfer of an image is incorrectly
passed down to be SMPTE170M, but it should be SRGB.
PiperOrigin-RevId: 626425396
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
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
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
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
Compared to `release`, the `reset` method doesn't release the preload manager instance. This applies to the use case that an app wants to discard all the sources but keep the preload manager active for later usage.
Also rename the `releaseSourceInternal` to `removeSourceInternal`, as the latter sounds more generic for different preload manager implementations.
PiperOrigin-RevId: 623148723
In offloaded audio playback, the `DefaultAudioSink` should use the `AudioTrack.StreamEventCallback` `onPresentationEnded` to note whether the AudioTrack has completed playing all pending data.
PiperOrigin-RevId: 622885399
Both `remove(MediaItem)` and `remove(MediaSource)` return a boolean suggesting that whether the preload manager is holding the corresponding `MediaSource` and it has been removed.
PiperOrigin-RevId: 622185427
This change makes sure the `DefaultLoadControl` would work
when passed to multiple players. It makes sure and unit tests
that the loading state of a player is maintained for each player
that is using `DefaultLoadControl`.
The targetBufferSize of the `DefaultAllocator` is increased
linearly for each player and memory is allocated in a simple
first-come-first-serve manner.
PiperOrigin-RevId: 622126523
The join mode is used for two cases: surface switching and mid-playback
enabling of video.
In both cases, we want to pretend to be ready despite not having rendered
a new "first frame". So far, we also avoided force-rendering the first
frame immediately because it causes a stuttering effect for the
mid-playback enable case. The surface switch case doesn't have this
stuttering issue as the same codec is used without interruption. Not
force-rendering the frame immediately causes the first-frame rendered
callback to arrive too early though, which may lead to cases where
apps hide shutter views too quickly.
This problem can be solved by only avoiding the force-render for the
mid-playback enabling case, but not for the surface switching case.
PiperOrigin-RevId: 622105916
Also explicitly use a synchronized list to collect cues. The previous
bare `ArrayList` was probably fine, because the `ConditionVariable`
creates a memory barrier between the main thread and the test thread,
but this seems more explicit (and any performance implications of the
synchronization don't matter for this test).
PiperOrigin-RevId: 621523824
The workaround check is now part of CTS and we should be able
to rely on the PerformancePoints values (or at least can be sure
that they cover all CDD requirements)
#minor-release
PiperOrigin-RevId: 619201331
Some media can read color info values from the bitstream
and may partially set some of the SDR default values in
Format.ColorInfo. Setting these default values for SDR can
confuse some codecs and may also prevent adaptive ABR
switches if not all ColorInfo values are set in exactly the
same way.
We can avoid any influence of HDR color info handling by
disabling setting the color info MediaFormat keys for SDR
video and also avoid codec reset at format changes if both
formats are SDR with slightly different ColorInfo settings.
To identify "SDR" ColorInfo instances, we need to do some
fuzzy matching as many of the default values are assumed to
match the SDR profile even if not set.
Issue: androidx/media#1158
PiperOrigin-RevId: 617473937
Add a new method `onUsedByPlayer(PreloadMediaSource)` for `PreloadMediaSource.PreloadControl`, which will be invoked when the player starts to use the `PreloadMediaSource`, or calling `PreloadMediaSource.preload` while the player is already using that source. `DefaultPreloadManager` will immediately preload the next source when receiving `onUsedByPlayer` event.
PiperOrigin-RevId: 616789121
Confirmed that the HLG extension displays properly on Pixel 7 Pro, API 34 and Samsung S24, API 34. On these devices, this fixes the washed out HLG preview issue on API 34, where the PQ ext had a washed out look, and where the HLG ext is supported (this bug didn't occur on API 33, only 34).
More info on manual tests done to sanity-check:
* Test cases: Transformer debug SurfaceView and ExoPlayer.setVideoEffects
* Test inputs: HLG and PQ
* Test devices: Pixel 7 Pro (API 33 & 34), Samsung Galaxy S24 (API 34)
* Added debugging: Logging colorInfo used in GlUtil.createEglSurface
No regressions were seen. HLG extension is used more in API 34, and behavior stays the same on API 33. Only human-visible change without logging is that HLG content looks better on API 34, for Samsung S24 and Pixel 7 Pro.
PiperOrigin-RevId: 616131192
