Merge latest code from androidx media main branch#10
Merged
ybai001 merged 6068 commits intoDolbyLaboratories:dlb/dovi-supplemental-codecs/devfrom Sep 20, 2024
Merged
Merge latest code from androidx media main branch#10ybai001 merged 6068 commits intoDolbyLaboratories:dlb/dovi-supplemental-codecs/devfrom
ybai001 merged 6068 commits intoDolbyLaboratories:dlb/dovi-supplemental-codecs/devfrom
Conversation
Package-private until API is more useable. Similar to frame analyzer mode: uses ImageReader instead of an encoder, and no muxer. PiperOrigin-RevId: 658446675
The data source may behave differently, depending on the provider, so we can extend the contract test to check all available providers. PiperOrigin-RevId: 658457650
Given that `Player` interface is written in Java and is has a callback-based Listener interface, we need an adapter for the Kotlin-native world. This change introduces a suspending function `listen` that creates a coroutine, in order to capture `Player.Events`. PiperOrigin-RevId: 658478608
It will be used for Kotlin-specific functionality like extension functions on the classes from the `media3-common` module. To import it, add the following to your build.gradle file:
`implementation("androidx.media3:media3-common-ktx:1.X.Y")`
PiperOrigin-RevId: 658492256
This is needed to correctly handle files with trailing non-MP3 data (which is indicated by the length in the `Info` frame being shorter than the overall length of the file). The test file was generated by appending 150kB of `DEADBEEF` onto the end of `test-cbr-info-header.mp3`, and the test asserts that the extracted samples are identical. Issue: #1480 #cherrypick PiperOrigin-RevId: 658727595
Try to follow recommendations in https://developer.android.com/media/optimize/sharing more closely For maximum compatibility the H.264 level should be less than or equal to 4.1 PiperOrigin-RevId: 658755139
This is to share the constants with the extractor. PiperOrigin-RevId: 658755661
For now, the only extension function on the `Player` has been used in a Compose demo. It can be promoted to a proper module where in the future other extension functions will reside. Given that `Player` is in `androidx.media3.common`, the corresponding KTX library for it is `androidx.media3.common-ktx` To start using the new `suspend fun listen`, one must add `androidx.media3:media3-common-ktx` as a Gradle dependency and `import androidx.media3.common.listen` PiperOrigin-RevId: 658771029
Instead of hard-coding values in multiple files, all default values are declared in `IamfDecoder`. Additionally, the max number of frames used for output buffer initialisation is fetched from `libiamf` native functions. PiperOrigin-RevId: 658772175
This API allows users to retrieve the sample size, ensuring they can allocate sufficient buffer capacity before utilizing the `readSampleData(ByteBuffer buffer, int offset)` method to read data. PiperOrigin-RevId: 658772408
There are two ways to write editable tracks samples. 1. In the embedded edit data MP4. 2. Interleaved with primary tracks samples. Initial plan was to support only option 1 but then the decision is to support both ways. To identify between these two an additional key will be required. Option 2 is yet to be implemented in Mp4Muxer. PiperOrigin-RevId: 658791214
PiperOrigin-RevId: 658829974
#cherrypick PiperOrigin-RevId: 659504142
The integration with external libraries like Glide or Coil is currently extremely complicated. Providing the boilerplate code to handle the ImageDecoder interface and a better hook for custom image decoders in DefaultRenderersFactory allows apps to easily inject their own logic for external image loading libraries. PiperOrigin-RevId: 659508914
PiperOrigin-RevId: 659520675
PiperOrigin-RevId: 659557063
The method is not supposed to work with any input byte[] so its best to make it non static and add appropriate validations. PiperOrigin-RevId: 659906543
PiperOrigin-RevId: 660324829
Previously in MultiInputVideoGraph, each VFP would destroy the shared eglContext, such that the same eglContext object is destroyed multiple times. Adding a flag to disallow this. The alternative being we could add a flag on the VFP constructor, but I think that is too subscriptive (meaning if we later might want to add another boolean to control another GL behaviour, multiple booleans would make the class less reason-able), and would incur a lot of code changes at places. PiperOrigin-RevId: 660354367
This is a no-op change. PiperOrigin-RevId: 660370824
PiperOrigin-RevId: 660376007
PiperOrigin-RevId: 660417092
This is caused when the requested "output start time" is equal to or larger than the last event time in a `Subtitle` object. This resolves the error in Issue: #1516, but subtitles are still not renderered (probably because the timestamps aren't what we expect somewhere, but I need to investigate this part further). #cherrypick PiperOrigin-RevId: 660462720
PiperOrigin-RevId: 660491742
App users can choose arbitrary data that might not be anticipated by developers. Transformer shouldn't `checkState` based on media data or file type -- report an error for unsupported data instead. Public API change `ImageAssetLoader` needs to parse MIME type and now accepts `Context` as parameter. PiperOrigin-RevId: 660762459
Some RTSP servers may provide media descriptions for custom streams that are not supported. ExoPlayer should skip the invalid media description and continues parsing the following media descriptions. To start, ExoPlayer will still error on malformed SDP lines for media descriptions, but will now skip media descriptions with "non-parsable" formats as described by [RFC 8866 Section 5.14](https://datatracker.ietf.org/doc/html/rfc8866#section-5.14). Issue: #1472 PiperOrigin-RevId: 660826116
If the length of the `ExtractorInput` is not known then the `subtitleData` field is re-sized by 1kB each time (`SubtitleExtractor.DEFAULT_BUFFER_SIZE`), so the end of the array is often not populated. This change ensures that `length` is propagated to `SubtitleParser`, so that implementations don't try and parse the garbage/zero bytes at the end of the array. Discovered while investigating Issue: #1516 #cherrypick PiperOrigin-RevId: 661195634
This has the largest impact during operations with no encoder, such as frame extraction. Add a matching performance test. PiperOrigin-RevId: 661220044
The exiting code ensured that the timestamp is same only when it is set by the app. PiperOrigin-RevId: 661283124
This is an additional signal that legacy subtitle support needs to be explicitly enabled, and is going away at some point. PiperOrigin-RevId: 661305694
PiperOrigin-RevId: 675277275
The player supports more than 2 audio sequences PiperOrigin-RevId: 675493637
PiperOrigin-RevId: 675525508
Previously, track IDs were added to `trackIndicesPerSampleInQueuedOrder` even when the sample was not committed. This caused issues where attempts to read samples from the `SampleQueue` returned `C.RESULT_READ_NOTHING`, which led to an exception being thrown due to the assumption that samples were available to read. This fix updates the logic to track sample commits by comparing the write index before and after calling `SampleQueue.sampleMetadata`. Track indices are only added if the sample was committed, ensuring accurate sample handling and avoiding exceptions. PiperOrigin-RevId: 675526115
PiperOrigin-RevId: 675547156
The muxer might not have accepted the first sample, if it is waiting for audio track. This bug causes issue when 1. VideoSampleExporter gives first sample (timestamp = 0) to the muxer. 2. Muxer does not write it because its waiting for audio track. 3. The video pipleline has processed all the sample and they are ready to be consumed. 4. VideoSampleExporter fetches the next available sample from encoder (which is still with timestamp = 0) but it changes its timestamp to last timestamp because VideoSampleExporter thinks it has muxed the sample at timestamp zero, but in reality it hasn't. This is because the flag `hasMuxedTimestampZero` is set when queueing the input, rather than actually muxing the input. This scenario can happen when video is processed much faster than the audio. PiperOrigin-RevId: 675565603
PiperOrigin-RevId: 675678257
NotificationChannel and NotificationChannelGroup are public APIs that were added in Android O, so at this point it is okay to have them appear in API signatures. PiperOrigin-RevId: 675756005
This gives a faster/clearer failure for Issue: #1718. PiperOrigin-RevId: 675896262
After the change in a879bc2, the Sequence won't have repeated EditedMediaItems. Thus if the sequence is looping, the last EditedMediaItems in the Sequence object might not corresponds to the last item in the "logical" sequence. PiperOrigin-RevId: 675912197
The Galaxy Tab S7 FE has a device issue that causes 60fps secure H264 streams to be marked as unsupported. This CL adds a workaround for this issue by checking the CDD required support for secure H264 in addition to the current check on standard H264. If the provided performance points do not cover the CDD requirement of support 720p H264 at 60fps, then it falls back to using legacy methods for checking frame rate and resolution support. Issue: #1619 PiperOrigin-RevId: 675920968
This is to allow not setting the MediaFormat OPERATING_RATE and PRIORITY altogether. The current behvaiour, if left the value `UNSET`, it'll apply the our optimizations, but apps might want to disable this optimization. PiperOrigin-RevId: 675923909
PiperOrigin-RevId: 675933601
This is no longer needed now our `compileSdk` implies a new-enough AGP which does this out-lining automatically via R8. See also https://issuetracker.google.com/345472586#comment7 There's no plan to remove the `ApiXXX` classes, but no new ones need to be added. PiperOrigin-RevId: 675940634
PiperOrigin-RevId: 675942348
This method is documented that it may only be called in `STATE_OPENED` or `STATE_OPENED_WITH_KEYS`. It's possible for it to be called in other states (like `STATE_ERROR`) without this guard. Previously this didn't cause issues, but since 9d62845 we assume that the `sessionId` is non-null in this method, which results in an `IllegalStateException` when the documented state restriction is ignored. PiperOrigin-RevId: 675969256
PiperOrigin-RevId: 675996979
- Added logic to parse media duration from the `mdhd` box for accurate frame rate calculation. - Fallbacks to track duration from `tkhd` when `mdhd` contains invalid or missing data. - Avoids incorrect frame rate calculations in MP4 files with an edit list (`elst`) box. - Adds frame rate calculations for partially fragmented MP4 files. - Verified accuracy with tools like `mediainfo` and `ffprobe`. Issue: #1531 **Note**: The slight difference in frame rate values in dump files that aren’t MP4s with an edit list or fragmented MP4s isn’t due to differences in `tkhd` and `mdhd` duration values (which should be identical for non-edited or non-fragmented files). Rather, it’s because they are calculated using different timescales. The `mvhd` box defines a global movie timescale, which is used for the track's `tkhd` duration. Meanwhile, each track’s `mdhd` box defines its own timescale specific to its content type, which we now use for more accurate frame rate calculation. PiperOrigin-RevId: 676046744
If this doesn't work, we could make this test resilient to frame drops by only comparing the frames that weren't dropped. PiperOrigin-RevId: 676294944
PiperOrigin-RevId: 676422122
Last buffer was not flipped, so was writing the garbage data between limit and capacity, rather than the actual data between position and limit. As a result, all PCM audio dump files need updating. PiperOrigin-RevId: 676452990
When sending a custom command with `browser.sendCustomCommand` when connected to a legacy browser service, the custom command was delivered to `MediaSessionCompat.Callback.onCustomAction` instead of the service method `onCustomAction`. The difference is that the service version can return an async response with a bundle, while the session callback version doesn't have a return value. Hence, the service method was never called and it wasn't possible to send a reponse or signal an error back to the browser. The resulting `ListanableFuture` simply always immediately resolved to a success. This change overrides `ListenableFuture<SessionResult> sendCustomCommand(SessionCommand command, Bundle args)` in `MediaBrowserImplLegacy` to use the `MediaBrowserCompat` method to send instead of the `MediaControlleCompat` method that was used by the subclass `MediaControllerImplLegacy`. This involves the service callback instead of the session callback and enables `MediaBrowser` to get the actual return value from the legacy service. Issue: #1474 #cherrypick PiperOrigin-RevId: 676519314
PiperOrigin-RevId: 676581325
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge latest code from androidx media main branch