The method currently modifies the input Bundle, but it's easier to
reason about it if the method is side-effect free and the places
that need to modify a Bundle do this after calling the method.
PiperOrigin-RevId: 693288031
Implemented `setLogSessionId(LogSessionId)` and `getLogSessionId()` methods.
Note: The `LogSessionId` is currently **not** forwarded to `MediaParser`, but this will be addressed once `MediaParser` can be used to configure `MediaExtractorCompat`.
PiperOrigin-RevId: 692945255
* Provide a helper Composable for remembering the state instance and launching the listening coroutine that observes the changes in the Player
* Add an example to demo-compose of using Shuffle- and Repeat- ButtonStates inside a Shuffle- and RepeatButton Composable.
* Reformat the MainActivity usage of `Shuffle` and `Repeat` buttons to form extra Player Controls and combine Prev/Play-Pause/Next with Shuffle/Repeat (Minimal controls + Extra controls = `PlayerControls`)
PiperOrigin-RevId: 692939825
The test has been moved to an instrumentation test as it relies on APIs that vary by SDK version. Robolectric’s emulation lacks sufficient realism in some cases, which impacts test accuracy. By using an instrumentation test, we ensure that the tests run in a real Android environment, providing reliable results for SDK-dependent APIs.
PiperOrigin-RevId: 692933259
Also move the `lint.xml` config which disables the `NewApi` check from
`lib-session` to the existing top-level file, and limit it to cover all
Robolectric tests by path matching.
Follow-up to 76db936d68
PiperOrigin-RevId: 692913646
This change keeps getSurfaceForCodec and hasSurfaceForCodec in sync.
Before this change when ExoPlayer is configured with setVideoEffects
and no display surface, codecs that need Set Output Surface Workaround
would not be initialized because hasSurfaceForCodec always returns false
PiperOrigin-RevId: 692900899
Restructured sample metadata management in `MediaExtractorCompat` to maintain a queue of `SampleMetadata` objects, each containing `timeUs`, `flags`, `size`, and `trackIndex`, rather than storing only track indices.
Introduced a pooling mechanism for `SampleMetadata` to reduce object allocation and improve memory efficiency. The new `SampleMetaDataQueue` centralizes metadata for easier access and management, eliminating the need to allocate a buffer or peek into the `SampleQueue` to retrieve sample metadata.
This change does not change existing behavior, it optimizes the internal structure, and existing tests already verify the relevant APIs.
PiperOrigin-RevId: 692285581
This CL adds utility methods to obtain sample-aligned timestamps from a
`SpeedProvider` to solve in a unified way the issues arising from
conversions between sample positions and microseconds.
The new utility methods will also help with the implementation of a
static method like `getDurationAfterProcessorApplied()` that will remove
the need for thread synchronization between the video and audio pipeline
for speed changing effects.
PiperOrigin-RevId: 692233318
If audio processors report a drifting position, we currently update
the media position parameters to correct this drift. However, this
means we pass in the wrong value to
audioProcessorChain.getMediaDuration, which reuqires the time since
the last flush.
To fix this problem, we can instead save the drift seperately and
apply it where needed.
PiperOrigin-RevId: 692202219
Also makes muxer shift the first video timestamp to zero, if it's not.
The trim position should respect the media timeline.
For example in a video that is 10s long (without edit list), if an edit list
adds 1_000ms to each video sample, and trimming 100ms, here's the expected:
- The video duration is 10.9s (`10s + 1s edit - 0.1s trim`)
- The first video frame time would be at 0.9s (`1s edit - 0.1s trim`)
PiperOrigin-RevId: 692187399
* Provide a helper Composable for remembering the state instance and launching the listening coroutine that observes the changes in the Player
* Add an example to demo-compose of using Previous- and Next- ButtonStates inside a Previous- and NextButton Composable.
* Reformat the MainActivity usage of `Previous`, `PlayPause`, `Next` buttons to form Minimal Player Controls
PiperOrigin-RevId: 691943147
Provide a helper Composable for remembering the state instance and launching the listening coroutine that observes the changes in the Player
Add an example to demo-compose of using PlayPauseButtonState inside a PlayPauseButton Composable.
The smart State object has been deemed a preferred solution over collecting Flows due to queuing/timing/buffering limitations. Instead, it uses the new `Player.listen` suspending extension function to catch the relevant events.
PiperOrigin-RevId: 691879975
This affects both `AnalyticsListener` and `MediaSourceEventListener`
This was introduced by d051b4b993
Also fix a missing 'load started' event for HLS media playlists (this
was also introduced by d051b4b993).
PiperOrigin-RevId: 691580183
Replaced the custom `LibraryLoader` instance with `OpusLibrary.isAvailable()` to verify the library loading. This simplifies the code by leveraging the existing library loading mechanism.
#cherrypick
PiperOrigin-RevId: 691457871
Using frames instead of bytes helps simplify the processing logic for
the component and will help with the move towards sample-based
`SpeedProvider`s. By using frames, we also abstract away the complexity
related to sample encoding.
This is a non-functional refactor.
PiperOrigin-RevId: 691444106
The overload that takes a `Format` is preferred, because it can detect
SEI NAL units in Dolby Vision tracks too.
Submitting this in a separate change so we can avoid cherry-picking it
into `1.5.0-rc01`, otherwise it would naturally be part of
27371db225.
Issue: androidx/media#1820
PiperOrigin-RevId: 691408725
Previously, `getTrackFormat()` in `MediaExtractorCompat` returned a `MediaFormat` without setting `MediaFormat.KEY_DURATION`. With this change:
- `MediaFormat.KEY_DURATION` is set based on the track's duration, if available.
- If the track duration is unset, the duration from the seek map is used as a fallback.
- When neither duration is set, `MediaFormat.KEY_DURATION` remains unset.
This ensures that `MediaFormat.KEY_DURATION` is populated when possible, enhancing duration information availability.
PiperOrigin-RevId: 691395114
This method will likely be removed in the next release, and is currently
only needed from within the `source` package.
#cherrypick
PiperOrigin-RevId: 691351449
This change ensures that the test uses `assumeTrue` to avoid failures when the `libiamf` library is not pre-built.
#cherrypick
PiperOrigin-RevId: 691333564
The logic in assumeFormatsSupported assumes that portrait videos are
always rotated before encoding but that's not the case when portrait
encoding is enabled.
PiperOrigin-RevId: 691042881
In some cases, the streamOffsetUs was passed to
VideoFrameReleaseControl.getFrameReleaseAction() but it should be the
streamStartPositionUs.
PiperOrigin-RevId: 691040172
When transitioning to the next media position parameter checkpoint
we estimate the position because the audio processor chain no longer
provides access to the actual playout duration.
The estimate using the declared speed and the last checkpoint may
have drifted over time, so we currently estimate relative to the
next checkpoint, which is closer and presumably provides a better
estimate. However, this assumes that these checkpoint are perfectly
aligned without any position jumps.
The current approach has two issues:
- The next checkpoint may include a position jump by design, e.g.
if it was set for a new item in the playlist and the duration of
the current item wasn't perfectly accurate.
- The sudden switch between two estimation methods may cause a jump
in the output position, which is visible when we add new media
position checkpoints to the queue, not when we actually reach the
playback position of the checkpoint.
We can fix both issues by taking a slightly different approach:
- Continuously monitor the estimate using the current checkpoint. If
it starts drifting, we can adjust it directly. This way the estimate
is always aligned with the actual position.
- The change above means we can safely switch to using the estimate
based on the previous checkpoint. This way we don't have to make
assumptions about the next checkpoint and any position jumps will
only happen when we actually reach this checkpoint (which is more
what a user expects to see, e.g. at a playlist item transition).
Issue: androidx/media#1698
PiperOrigin-RevId: 690979859
Removed deprecated `Transformer.PROGRESS_STATE_NO_TRANSFORMATION`, `Transformer.setListener`, and `Transformer.startTransformation` from Transformer.
PiperOrigin-RevId: 690971992
Adjusted logic to accurately calculate sizes and durations for the last valid cue point when cue timestamps are greater than the total duration.
Fixes the issue where the reported duration of the MKV file was greater than the total duration specified by the duration element. Verified this using `mkvinfo` and `mediainfo` tools.
PiperOrigin-RevId: 690961276
A player that is being released may report an error with
null `player.getPlayerError()`. Do not try to read errors
of players that are released.
PiperOrigin-RevId: 690953083
This method allows `Sonic` to statically and accurately report the
expected number of output frames for any given parameter configuration.
This change is required prework for `SpeedChangingAudioProcessor` to
implement a similar static method and allow precise, non-blocking
timestamp adjustments for the experimental speed changing effect.
PiperOrigin-RevId: 690669627
Also, fix incorrectly stretched golden file that was not detected with previous, less sensitive, average pixel error comparison.
PiperOrigin-RevId: 690643520
GLSL 3.00 mediump doesn't require enough precision near zero
to correctly represent PQ colors where the [0, 1] GL range
represents [0, 10_000] nits.
This caused `noEffects_hlg10InputAndHdr10Output_matchesGoldenFile`
to fail on some devices.
PiperOrigin-RevId: 690627069
The old code that uses MediaCodec directly has a race condition
that causes the decoder to incorrectly crop the decoded picture.
PiperOrigin-RevId: 690620868
This is prework for `Sonic` to provide a precise calculation of output
sample counts, and thus allow `SpeedChangingAudioProcessor` to replace
`getSpeedAdjustedTimeAsync()` with an accurate synchronous calculation.
This is a non functional change.
PiperOrigin-RevId: 690608520
This method is already called below in the
`else if (sps.isCompleted())` block which applies when
`hasOutputFormat == true`, but this is only ever entered if we are
parsing SPS and PPS NAL units **after** we've emitted a format, which
is only the case if
`DefaultTsPayloadReaderFactory.FLAG_DETECT_ACCESS_UNITS` is set (which
it isn't by default).
The equivalent call in `H265Reader` is already inside the
`if (!hasOutputFormat)` block, so doesn't need a similar fix.
#cherrypick
PiperOrigin-RevId: 689809529
This ensures that media button preferences with slots for BACK,
FORWARD and OVERFLOW are converted to the legacy custom layout
according to the implicit placement rules. This has to happen
when populating the MediaSessionCompat and when generating the
notification for older APIs. Sending these preferences to older
Media3 controllers can filter them down to the custom layout the
session would have used previously, but there is no need to adjust
the reservation extras because the older Media3 custom layout has
no concept of these extras.
PiperOrigin-RevId: 689761637
This is equivalent to the current logic, but also allows to easily pick
up other buttons that use the BACK, CENTRAL or FORWARD slots for the
compact view by default.
Also fix the test to actually assert the output order.
PiperOrigin-RevId: 689747844
This ensures that the slots are set according to the implicit placement
rules for the legacy custom layouts. This has to be done when receiving
custom actions from a MediaControllerCompat and for Media3 sessions
setting the custom layout field.
PiperOrigin-RevId: 689737951
These methods are marked `default` on the `AnalyticsListener` interface
with an empty implementation, so there's no need to override them just
to re-define the empty implementation.
PiperOrigin-RevId: 689416584
* Use asset without audio for independent video time progress
* Use longer item duration to avoid ExoPlayer STATE_READY workaround
(see https://github.com/google/ExoPlayer/issues/1874)
PiperOrigin-RevId: 689409427
Add `DecoderAudioRenderer.getDurationToProgressUs()` so that `ExoPlayer`, if set with `experimentalSetDynamicSchedulingEnabled()`, will dynamically schedule its main work loop to when the `DecoderAudioRenderer` can make progress.
PiperOrigin-RevId: 689377247
Mp4Muxer caches the samples and then writes them in batches.
The new API allows disabling the batching and writing sample
immediately.
PiperOrigin-RevId: 689352771
- Create `LibiamfAudioRenderer` with `DefaultRenderersFactory` in `ExoPlayerModuleProguard`.
- Remove redundant library availability check from `IamfModuleProguard`.
- Move `proguard-rules.txt` to the root folder.
- Removed unused `cryptoType` parameter from `setLibraries()` method in `IamfLibrary`.
- Added log when `LibiamfAudioRenderer` is loaded in `DefaultRenderersFactory`.
- Annotated missing classes with `@UnstableApi`.
- Check for library availability and throw exception in `IamfDecoder` constructor.
#cherrypick
PiperOrigin-RevId: 689330016
This change:
1. Updates `DataSourceContractTest` to allow multiple "not found"
resources, and to include additional info (e.g. headers) on them.
2. Updates the contract test to assert that `DataSource.getUri()`
returns the expected (non-null) value for "not found" resources
between the failed `open()` call and a subsequent `close()` call.
The `DataSource` is 'open' at this point (since it needs to be
'closed' later), so `getUri()` must return non-null.
* This change also fixes some implementations to comply with this
contract. It also renames some imprecisely named `opened`
booleans that **don't** track whether the `DataSource` is open
or not.
3. Updates the contract test assertions to enforce that
`DataSource.getResponseHeaders()` returns any headers associated
with the 'not found' resource.
4. Configures `HttpDataSourceTestEnv` to provide both 404 and "server
not found" resources, with the former having expected headers
associated with it.
PiperOrigin-RevId: 689316121
The new `media3-ui-compose` module does not have any Material library dependencies, but will rely on androidx.compose + foundation/runtime/ui and other non-theming/opinionated libraries. Surface handling is one such usecase.
PiperOrigin-RevId: 689004504
Also add a test for this to avoid missing any others in future. Also
flesh out the existing test for the deprecated builder, to assert the
return type is correctly updated.
PiperOrigin-RevId: 688948768
The duration is now correctly calculated as the maximum of all track durations, instead of being overwritten by the last track's value. This aligns with how other Extractor implementations handle durations for multiple tracks.
PiperOrigin-RevId: 688896743
`RandomParameterizedSpeedChangingAudioProcessorTest` follows the
structure of `RandomParameterizedSonicAudioProcessorTest` and will help
improve coverage and confidence in the output length of
`SpeedChangingAudioProcessor`.
This CL is prework for removing the synchronization between the video
pipeline and the audio pipeline for speed changing effects.
PiperOrigin-RevId: 688578597
Currently most of the public APIs use `fullscreen` (apart from the deprecated `PlayerControlView.OnFullScreenModeChangedListener` which will have to remain as is). This code changes mostly private variable naming.
PiperOrigin-RevId: 688559509
Frame rate change is currently notified to the release control when the
video frame processor input frame rate changes, but it should be when
the video frame processor output frame rate changes.
PiperOrigin-RevId: 688512300
If not copied, the extras Bundle can be accidentally changed by the
app if it modifies the instance passed into MediaSession. On the flip
side, the Bundle should be modifiable once created so that the session
can amend the extras if needed without crashing.
PiperOrigin-RevId: 688485963
Added start and end time details to the error message for `REASON_START_EXCEEDS_END`, helping to debug cases where the start time exceeds the end time.
PiperOrigin-RevId: 688117440
The method allows extractors to set track duration when available. The `default` implementation does nothing, allowing implementers of `TrackOutput` to override it if they need to handle track duration.
Implemented it in `FakeExtractor` to print track duration in dump files.
PiperOrigin-RevId: 688110288
Treats the media duration as unknown (`C.TIME_UNSET`) when all bytes are `-1` to prevent exceptions during playback.
Issue: androidx/media#1819
#cherrypick
PiperOrigin-RevId: 688103949
This adds the API surface for media button preferences in MediaSession
and MediaController. It closely mimics the existing custom layout
infrastructure (which it will replace eventually).
Compat logic:
- Session:
- When converting to platform custom actions, prefer to use
media button preferences if both are set.
- When connecting to an older Media3 controller, send the
media button preferences as custom layout instead.
- Controller:
- Maintain a single resolved media button preferences field.
- For Media3 controller receiving both values, prefer media
button preferences over custom layouts.
Missing functionality:
- The conversion from/to custom layout and platform custom actions
does not take the slot preferences into account yet.
PiperOrigin-RevId: 686950100
Before this change:
* With legacy subtitle decoding (at render time), load errors (e.g. HTTP
404) would result playback completely failing, while parse errors
(e.g. invalid WebVTT data) would be silently ignored, so playback
would continue without subtitles.
* With new subtitle decoding (at extraction time), both load and parse
errors would result in playback completely failing.
This change means that now neither load nor parse errors in text or
metadata tracks stop playback from continuing. Instead the error'd track
is disabled until the end of the current period.
With new subtitle decoding, both load and parse errors happen during
loading/extraction, and so are emitted to the app via
`MediaSourceEventListener.onLoadError` and
`AnalyticsListener.onLoadError`. With legacy subtitle decoding, only
load errors are emitted via these listeners and parsing errors continue
to be silently ignored.
Issue: androidx/media#1722
PiperOrigin-RevId: 686902979
These events are always reported with the primary child period ID,
because this is the same ID used in the parent `MergingMediaSource`'s
Timeline.
This ensures that e.g. loading errors from sideloaded subtitles (which
uses `MergingMediaSource`) are now reported via
`AnalyticsListener.onLoadError`.
It results in non-error events being reported from these children too,
which will result in more `onLoadStarted` and `onLoadCompleted` events
being reported (one for each child).
Issue: androidx/media#1722
PiperOrigin-RevId: 686901439
Use this for sideloaded subtitles, so preparation can still complete
despite an error from e.g. `DataSource.open`. In this case, no subtitle
tracks will be emitted.
Issue: androidx/media#1722
PiperOrigin-RevId: 686888588
This is prework for implementing
`RandomParameterizedSpeedChangingAudioProcessorTest`, which depends on
Sonic's resampling algorithm's behaviour.
This is a non-functional refactor.
PiperOrigin-RevId: 686874593
When a `SampleQueue` is prepared prior to playback, the start position may be less than the timestamp of the first sample in the queue and still be valid. This scenario can come about with specific clipping values and if all samples are sync samples. Currently, with `ClippingMediaPeriods` around `ProgressiveMediaPeriods`, if the `SampleQueue` has already been reset through the seekTo operation in `onPrepared`, then in the aforementioned scenario the seekTo operation in `handleDiscontinuity` will remove all samples and reset the loading periods unnecessarily.
The solution is that if the `ProgressiveMediaPeriod` has already handled a seekTo operation for the same position and the sample queue has not been read yet, then loading does not need to be reset.
The tests in `MergingPlaylistPlaybackTest` were specifically causing this behavior through its setup of `MergingMediaSources` around clipped `FilteringMediaSources`. Since the video content was not 'all sync samples', there would always be a discontinuity to handle and the audio content being 'all sync samples' would start with samples post start time.
These changes also remove the flakiness from the `MergingPlaylistPlaybackTest`.
PiperOrigin-RevId: 686858444
Currently every test in the library passes `null` here, which seems to
end up being passed into non-null places in the library. This change
removes the parameter and instead initializes the field to a
`DefaultAllocator` instance in the same way that `DefaultLoadControl`
creates one.
PiperOrigin-RevId: 686823273
This ensures that the buffers are correctly marked as `rendered = true`
(and therefore `renderered = false` is meaningful when it's present).
This was accidentally missed in 387153fcf2
PiperOrigin-RevId: 686474869
This allows users to extend and customize specific methods of the `TrackOutput` implementation while inheriting default behaviors for others.
PiperOrigin-RevId: 686454360
Childrens returned by the legacy service when a Media3
browser connects are cached and returned with the first
`getChildren` call in case the same `paranetid` is
requested.
In any other case the cache is immediately cleared.
#cherrypick
PiperOrigin-RevId: 686157511
Updated logic to walk forward in the timestamps array to include all frames within the valid edit duration, accounting for out-of-order frames. This ensures that no frames with timestamps less than `editMediaTime` + `editDuration` are incorrectly excluded.
Issue: androidx/media#1797
PiperOrigin-RevId: 686075680
When receiving an error from a legacy `MediaBrowserService` after
having successfully subscribed to a given `parentId`, the callback
needs to be asked to load the children again to receive an error
from the service.
Before this change such an error was dropped as a no-op by Media3
without the `MediaBrowser` giving a chance to react on such an error
being sent by the legacy service.
#cherrypick
PiperOrigin-RevId: 686052969
The `CapturingRenderersFactory` is only needed if the output is
asserted on, e.g. by using `PlaybackOutput` and
`DumpFileAsserts.assertOutput()`.
PiperOrigin-RevId: 686046545
Many of the Android TV platforms do not report accurate `SystemClock.elapsedRealtime()`
In addition this drift is not consistant accross multiple boxes, so the time offset
between any pair of boxes will vary over time.
This variance will lead to a drift in the Live Offset calculation.
Fix is simple, inValidate the NTP server query after a period of time (10 minutes)
and re-issue the call
`HlsExtractorFactory` instances are mutable, so storing one in a static
field is not safe, and can lead to state accidentally/surprisingly being
shared between different player instances.
PiperOrigin-RevId: 685701062
This ensures these values are still updated even if the delegate
`DataSource.open()` throws an exception (e.g. an HTTP 404).
PiperOrigin-RevId: 685687810
The `DefaultLoadControl` implementation of onTracksSelected only utilizes the `Renderer[]` parameter for use in stream type, of which it can collect from the `ExoTrackSelection[]` parameter.
PiperOrigin-RevId: 685677726
The `DefaultPreloadManager.Builder` is able to build the `DefaultPreloadManager` and `ExoPlayer` instances with the consistently shared configurations. Apps can:
* Simply setup the `DefaultPreloadManager` and `ExoPlayer` with all default configurations via `build()` and `buildExoPlayer()`;
* Or customize the shared configurations by the setters on `DefaultPreloadManager.Builder` and setup via `build()` and `buildExoPlayer()`;
* Or customize the player-only configurations for `ExoPlayer` via `buildExoPlayer(ExoPlayer.Builder)`.
PiperOrigin-RevId: 684852808
This CL is prework for implementing
`RandomParameterizedSpeedChangingAudioProcessorTest`, which will build
on logic present in `RandomParameterizedSonicTest`.
This is a non-functional change.
PiperOrigin-RevId: 684838017
Inconsistent rounding modes between `currentTimeUs` and
`bytesUntilNextSpeedChange` would cause `SpeedChangingAudioProcessor`
to miss calling `queueEndOfStream()` on `SonicAudioProcessor` on a speed
change, and thus the final output samples of that `SonicAudioProcessor`
"configuration" would be missed.
This change is also a partial revert of 971486f5f9, which fixed a hang
of `SpeedChangingAudioProcessor`, but introduced the dropped output
frames issue fixed in this CL (see b/372203420). To avoid reintroducing
the hang, we are now ignoring any mid-sample speed changes and will only
apply speed changes that are effective at a whole sample position.
PiperOrigin-RevId: 684824218
Removed `Android.mk` and `Application.mk`, allowing `CMake` to run directly from the build.gradle file. Users no longer need to check out `NDK` or depend on it, simplifying the usage of the Flac extension.
Also fixed a copy-pasted comment in `CMakeLists.txt` of Opus and IAMF.
PiperOrigin-RevId: 684769561
Removed `Android.mk` and `Application.mk`, allowing `CMake` to run directly from the build.gradle file. Users no longer need to check out `NDK` or depend on it, simplifying the usage of the Opus extension.
PiperOrigin-RevId: 684489927
We need to rebuild any native components of the app to prevent crashes on devices with 16 KB page support.
Tested on a device that supports 16 KB pages and runs Android 15, as well as on older Android devices.
Issue: androidx/media#1685
PiperOrigin-RevId: 684488244
Removed `Android.mk` and `Application.mk`, allowing `CMake` to run directly from the `build.gradle` file. Users no longer need to check out `NDK` or depend on it, simplifying the usage of the IAMF extension.
PiperOrigin-RevId: 684471874
The version and flags are stored in a single integer,
with the version in the higher 8 bits and the flags in
the lower 24 bits. The version should be 1 and the
flags should be 0.
Surprisingly the incorrect value was ignored by many
players and hence the bug was never caught.
With the bug, the video does not play on
`Samsung Galaxy S22 Ultra` and works well
after fixing the bug.
PiperOrigin-RevId: 684433371
Minor improvement to allow an Media3 browser to pass extras
when connecting the initial browser in `MediaControllerImplLegacy`.
Before this change an empty bundle was sent. After this change
the connection hints of the `Media3 browser is used as root hints
of the initial browser that connects when the Media3 browser is
built in `MediaBrowser.buildAsync`.
#cherrypick
PiperOrigin-RevId: 684372552
This helps avoid overflows in intermediate calculations.
Verified the value in the test using `BigInteger`:
```
jshell> BigInteger.valueOf(1L << 52).multiply(BigInteger.valueOf(90000)).divide(BigInteger.valueOf(1000000))
$3 ==> 405323966463344
```
Issue: androidx/media#1763
#cherrypick
PiperOrigin-RevId: 684028178
The implementation of these methods was updated from direct java integer
arithmetic in 885ddb167e.
In this change, `RoundingMode.FLOOR` was used to try and maintain
compatibility with java integer division. This was incorrect, because
java integer division uses `DOWN` (i.e. towards zero), rather than
`FLOOR` (i.e. towards negative infinity) semantics.
This change fixes the compatibility.
The dump file changes in this CL relate to tests that exercise edit
list behaviour. This involves manipulating negative timestamps, which
explains why they are impacted by this change.
PiperOrigin-RevId: 684013175
- Updated `DefaultTrackSelector.SpatializerWrapperV32.canBeSpatialized` to handle IAMF format.
- Modified `isAudioFormatWithinAudioChannelCountConstraints` to check for `NO_VALUE` of `channelCount` to improve readability.
Note: `DefaultTrackSelector.SpatializerWrapperV32.canBeSpatialized` is not triggered for the IAMF format due to the unset channel count (`Format.NO_VALUE`). The update ensures completeness.
#cherrypick
PiperOrigin-RevId: 684003980
Object-based audio is more efficient and flexible than channel-based audio, supporting a broader range of devices. This update makes `DefaultTrackSelector` prefer object-based audio when other factors are equal, ensuring its use whenever possible.
#cherrypick
PiperOrigin-RevId: 683990051
When calling `MediaController.getCommandButtonForMediaItem(MediaItem)`
command buttons with custom commands that are not available
shouldn't be advertised to the controller when connected to
a Media3 session.
In contrast, when connected to a legacy session, available commands
are not enforced when advertising commands. Similarly, when sending
a custom commands that is referenced by a command button for media
items, sending is permitted without the command being available.
This is required because available commands match to custom actions
in `PlaybackStateCompat` of the legacy session. Adding commands for
media items to custom action of the `PlaybackStateCompat` would
interfere with other use cases.
Issue: androidx/media#1474
#cherrypick
PiperOrigin-RevId: 683717723
This was missed in da724c8cc4
I tried to write a test for this, but got stuck crafting valid test
data. I was able to create a new fragmented MP4 file containing only a
TTML track:
```shell
$ MP4Box -add simple.ttml -frag 2000 sample_fragmented_ttml.mp4
```
Then I tried naively removing the `ftyp` and `moov` boxes with a hex
editor, but using this in `FragmentedMp4ExtractorNoSniffingTest` gave
me an `EOFException` that I didn't get to the root cause of.
Issue: androidx/media#1779
#cherrypick
PiperOrigin-RevId: 683667850
This refactors the `supportsFormat` method on the MediaCodecVideoRenderer to be a static method that can be called from external components to determine if a video format is supported by the device renderers. Since `context` is the only component that is part of the MCVR, it can easily be obtained externally and passed to the method.
This can help optimize format support decisions ahead of time of a player having been instantiated, such as removing unsupported representations from a dash manifest.
This could also be done for the MCAR but would also require passing in the AudioSink and isn't required at this time.
This change is a no-op, because
`SubtitleTranscodingExtractorOutput.seekMap` forwards directly to the
delegate implementation, but it seems clearer to always use the
wrapper.
Also remove a no-op assignment in `MatroskaExtractor`.
This is a follow-up to Issue: androidx/media#1779 where I manually checked every
implementation of `Extractor.init` for a similar mistake.
#cherrypick
PiperOrigin-RevId: 683607090
These Uris are not widely supported yet and were only meant to be
used with content Uris. Restricting this more tightly allows
controllers to use these Uris more easily as they have a stricter
guarentee on what it's needed to load these Uris. Media session
apps with different types of Uris can convert them by setting up
a ContentProvider if needed.
Issue: androidx/media#1783
PiperOrigin-RevId: 683539747
PlaybackVideoGraphWrapper will soon contain an input and an output video
sink, as the rendering of the VideoGraph output frames will be handled
by a DefaultVideoSink instance.
PiperOrigin-RevId: 683167795
This CL also fixes EOS handling to account for not-yet-copied samples in
`remainingInputToCopyFrameCount`, which would throw off the final output
sample count calculation.
For testing, we allow a tolerance of 0.000017% drift between expected
and actual number of output samples. The value was obtained from running
100 iterations of `timeStretching_returnsExpectedNumberOfSamples()` and
calculating the average delta percentage between expected and actual
number of output samples. Roughly, this means a tolerance of 40 samples
on a 90 min mono stream @48KHz.
PiperOrigin-RevId: 683133461
Just clearing the overrides only helps if a text override was
previously set. If the text is shown because of app defined track
selection parameters for language or role flags, the "none" button is
currently not working and we need to clear these flags explicitly.
PiperOrigin-RevId: 682373821
IMA always starts midrolls at index 1. So if there is no preroll ad,
the ad group index in AdPlaybackState is off by 1 all the time, and
may also lead to ArrayIndexOutOfBoundsExceptions when trying to access
the last midroll ad
Issue: androidx/media#1741
PiperOrigin-RevId: 682324368
The workaround in ExternalTextureManager.forceSignalEndOfStream
was being applied even when the decoder did output all frames, and only
the GL pipeline was slow.
This change ensures that workaround is not applied when the decoder
has already produced all output frames.
PiperOrigin-RevId: 680471587
If a codec received the EOS signal and already returned the last
output buffer, we should expect the output EOS very quickly. If
it doesn't arrive within 100ms, we can proceed to end the stream
manually without waiting any further to prevent cases where the
codec is completely stuck otherwise.
PiperOrigin-RevId: 679633116
Some devices can encode portrait 720x1080 but not landscape
1080x720. But VideoSampleExporter always prefers encoding
landscape. Have `assumeFormatsSupported` mirror sample exporter
logic more closely
PiperOrigin-RevId: 679495210
The buffered position was last updated before the beginning of
the renderer loop in doSomeWork. As the loading happens on a
background thread, it may have progressed further already
depending on how long it took to run the renderer loop.
It's slightly more correct to pass in an updated value to
shouldStartPlayback so that playback can start quicker if the
buffering is particularly fast.
PiperOrigin-RevId: 679203465
We began to use a different preload thread than the main thread in the `DefaultPreloadManagerTest`, then in the test execution, we should also ensure that the events queued on the preload looper have been executed.
Also, there is an edge case also causing flakiness. Assume that `DefaultPreloadManager` is preloading source B, then the app invalidates and triggers another sequence of preloading, say they are A, B and C. There is possibility that source B finishes preloading (started before `invalidate`) when A starting to preload, then `onPreloadSkipped` will be triggered for source B instead of `onPreloadCompleted`. However, the functional block inside of `onPreloadSkipped` is dispatched asynchronously, and by then it's possible that B starts to preload again at the consequence of A being completed, then the functional block just mentioned may think that the current source matches at B, and will advance the current preloading source to C, without informing the `Listener.onPreloadCompleted` for it. As the result, the `Listener.onPreloadCompleted` can never be triggered for B for the second sequence. To fix this, we should prevent the functional block in `onPreloadCompleted`, `onPreloadError`, `onPreloadSkipped` to be even dispatched, when the source doesn't match the current preloading one.
PiperOrigin-RevId: 679145353
The MetadataRenderer by default supports icy and vnd.dvb.ait content. Those tracks should therefore be set with the `C.TrackType` `TRACK_TYPE_METADATA` rather than `TRACK_TYPE_UNKNOWN`.
PiperOrigin-RevId: 679132680
When a Media3 controller calls play on a Media3 session, the call
is currently not routed through the platform session at all.
This means the usual exemption to start a FGS for media controller
interactions is not triggered.
We can manually ensure this exemption is given by sending a custom
platform command to the session. The Media3 session will never
receive this command as it's not a known Media3 custom command.
Sessions will see a single onConnect call with a platform controller
from the sender app though. We can prevent this on newer versions of
the code by dropping the onCommand call early.
PiperOrigin-RevId: 679115247
The max number of commands for media items of a browser or controller
can be configured with `setMaxCommandsForMediaItems(int)` on
`MediaController.Builder` and `MediaBrowser.Builder`. An app that has
only limited space for displaying commands can hint this limit to the
session.
A session can receive the value of a connected browser or controller
through `getMaxCommandsForMediaItems()` of a `ControllerInfo` that
is passed into every callback method. The session can then pick the most
sensible commands instead of making the browser app truncating the commands
rather randomly.
When a `MediaBrowser` is connected against a legacy `MediaBrowserServiceCompat`,
the max number of commands is automatically added to the root hints. Conversely,
the value passed in with the root hints to `MediaLibraryService` by a legacy
`MediaBrowserCompat`, is read into `ControllerInfo` like for a Media3 browser.
Issue: androidx/media#1474
#cherrypick
PiperOrigin-RevId: 679076506
To avoid rounding errors, set the `Rounding mode` of the `uvFromVu` and `vuFromUs` results to `HALF_UP`. This `Rounding mode` rounds numbers towards the "nearest neighbor" unless both neighbors are equidistant, in which case round up.
PiperOrigin-RevId: 679003943
See https://developer.android.com/training/cars/media#custom_browse_actions
- `MediaMetadata.supportedCommands` is converted to an array list of
strings into the extras of `MediaDescriptionCompat` with `DESCRIPTION_EXTRAS_KEY_CUSTOM_BROWSER_ACTION_ID_LIST` and vice versa.
- The set of media item command buttons of a session is passed in the
root hints to a legacy browser that connects. A Media3 browser connected
to a legacy service, gets the set of all commands after calling
`getLibraryRoot()`.
#cherrypick
PiperOrigin-RevId: 678807473
Note that unlike the legacy implementation, custom media items
commands can be used for any media items with Media3 API. This
includes `MediaItem` instances that are received from sources
different to `MediaLibraryService` methods.
Hence when connected against a Media3 session these custom commands
can be used with a `MediaController` as well as with a `MediaBrowser`.
Interoperability with `MediaBrowserServiceCompat` will
be added in a follow up CL.
Issue: androidx/media#1474
#cherrypick
PiperOrigin-RevId: 678782860
This check is also done when setting a surface on ExoPlayerImpl,
but by the time we configure the codec the surface may have become
invalid (e.g. when it is destroyed). Even though we immediately remove
a destroyed surface, we could still accidentally use it before the
removal is processed. To avoid these edge cases, we can simply not
configure the codec with an invalid surface.
PiperOrigin-RevId: 678741425
