Merge latest androidx/media main branch #9
Merged
Conversation
This file contains 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
VideoSink.initialize will be added in a next CL and we want to allow flush to be called before and after initialize. PiperOrigin-RevId: 624946957
PiperOrigin-RevId: 624999257
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: #1283 PiperOrigin-RevId: 625252745
PiperOrigin-RevId: 625260110
The `DefaultDrmSessionManager` allows setting this policy. This change simply plumbs the setting up to the `DefaultDrmSessionManagerProvider`
This is to align the interface with Muxer/Muxer.java and then finally replace it. PiperOrigin-RevId: 625283725
…andler PiperOrigin-RevId: 625285300
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
PiperOrigin-RevId: 625332081
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
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
All the changes are based on existing implementations and their related tests. No new functionality is being added. PiperOrigin-RevId: 625756836
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
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
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: #1240 PiperOrigin-RevId: 626038032
PiperOrigin-RevId: 626044561
PiperOrigin-RevId: 626064956
We currently check certain properties about inputColorInfo twice: once in checkColors in the DVFP and once when creating the samplers in the defaultshaderprogam. The inputcolorinfo shouldn't change between these two components so removing the checks in the shader program to have one source of truth for inputColorInfo checks, which will make the code simpler when it comes to adding to color-related features (like the ones related to removing de-gamma-ing) PiperOrigin-RevId: 626400960
fixes #821 PiperOrigin-RevId: 626407880
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
add coverage for key use case for speed adjustments PiperOrigin-RevId: 626957912
PiperOrigin-RevId: 627002635
This is to eventually replace Transformer/Muxer.java with Muxer/Muxer.java PiperOrigin-RevId: 627027254
This is to eventually replace Transformer/Muxer.java with Muxer/Muxer.java PiperOrigin-RevId: 627043808
Update the function convertPresentationTimestampsToDurationsVu to return a list of duration in decoding order,used in the creation of STTS boxes. PiperOrigin-RevId: 627052898
PiperOrigin-RevId: 627114088
Queue image again after position reset, and reset timestamp iterator. PiperOrigin-RevId: 635049953
+additional formatting and Javadoc changes
PiperOrigin-RevId: 635459757
PiperOrigin-RevId: 635465538
PiperOrigin-RevId: 635469173
#minor-release PiperOrigin-RevId: 635469477
Gainmaps don't currently have an equals override, only reference equality is checked by Objects.equals(gainmap1, gainmap2). Create an equals method for gainmaps with the fields we care about to ensure we don't incur false positives in our equality checks. PiperOrigin-RevId: 635510451
If MediaCodec allocates passes an image buffer with a cropped region, SurfaceTexture.getTransformMatrix will cut off 2 pixels from each dimensions. The resulting videos will appear a little stretched. This patch inspects the SurfaceTexture transform matrix, and guesses what the unscaled transform matrix should be. Behind experimentalAdjustSurfaceTextureTransformationMatrix flag PiperOrigin-RevId: 635721267
Fragment shaders in OpenGL ES shader language aren't guaranteed to support highp, required to correctly represent pixel coordinates inside large images (e.g. 1920x1080). This change moves coordinate mirroring for images out of fragment shader. Fixes http://Issue: #1331 PiperOrigin-RevId: 635732208
PiperOrigin-RevId: 635737466
PiperOrigin-RevId: 635742699
PiperOrigin-RevId: 635748820
This shows ExoPlayer currently wrongly reports the duration of this sample, because it assumes every frame is 32kbps (104 bytes) due to the `PCUT` frame immediately after the `Info` frame. A follow-up change will modify `Info` frame handling to resolve this issue. This sample was crafted using a hex editor to insert the additional `PCUT` frame (the pattern of `null` and `x` is taken from the sample file in Issue: #1376, the header is modified to set the channel count to 1 to match the rest of the file), and then update the frame count and data size of the `Info` header to match. Issue: #1376 PiperOrigin-RevId: 635772837
This change was originally made in 6f82491 It was then accidentally lost in when `Cea708Parser` was merged back into `Cea708Decoder` in 51b4fa2. This is the only change made to the actual 'decoding' logic in `Cea708Parser` between it being split from `Cea708Decoder` and merged back in again, all the other changes in this period relate to the implementation of the `SubtitleParser` interface, so don't need to be preserved in `Cea708Decoder`: https://github.com/androidx/media/commits/51b4fa2cc83b60fcb313fd0e6afd2d45fe64e535/libraries/extractor/src/main/java/androidx/media3/extractor/text/cea/Cea708Parser.java `Cea608Parser` was also merged back into `Cea608Decoder` in 25498b1 and so is vulnerable to the same risk of accidental loss of changes. To be sure, I also checked the history of this file: https://github.com/androidx/media/commits/25498b151ba298ef359f245e2ed80718b4adf556/libraries/extractor/src/main/java/androidx/media3/extractor/text/cea/Cea608Parser.java The only 'decoding logic' change there is 379cb3b, which was also lost in 25498b1. I will send a separate change to resolve this. PiperOrigin-RevId: 635796696
This change was originally made in 379cb3b. It was then accidentally lost in when `Cea608Parser` was merged back into `Cea608Decoder` in 25498b1. This was spotted when re-doing a similar lost change to `Cea708Decoder`, reported in #1315. See reasoning on e2847b3 about why this is the only 'lost' CEA-608 change. PiperOrigin-RevId: 635803536
PiperOrigin-RevId: 635812838
Track information is added to the details string where relevant. PiperOrigin-RevId: 635815866
Move the parameter to the constructor instead. PiperOrigin-RevId: 636077477
This was previously only set on images because it was not ignored on other media types. This parameter was made no-op for non-images in 7b2a1b4. PiperOrigin-RevId: 636078142
…ol-branch PiperOrigin-RevId: 636095759
This allows controller apps to map these constants to suitable icons without creating a CommandButton instance first. PiperOrigin-RevId: 636096841
Fall back to using software decoder for 1920x1080 for certain devices. PiperOrigin-RevId: 636132298
`Info` header is used for CBR files, but in some cases not **every** frame in these files is the same size. This change stops using the single frame after the `Info` frame as the 'template' (and assuming all subsequent frames are the same size/bitrate), and instead derives the bitrate from fields in the `Info` header. This works for files which are 'almost' constant bitrate, like the one in Issue: #1376 where every frame is either 1044 or 1045 bytes except the one immediately after the `Info` frame which is 104 bytes (32kbps), resulting in a wildly incorrect duration calculation. PiperOrigin-RevId: 636151605
This change avoids a muxer deadlock when: 1. Sequence of items 2. First item has audio track that is shorter than video 3. Audio finishes, and muxer refuses to write more than 500ms of video consecutively. SequenceAssetLoader fails to progress to the second item. A muxer deadlock is possible when the audio of the first item finishes, audio end-of-stream is not propagated through AudioGraph, and muxer blocks video, preventing SequenceAssetLoader to move to the next item in sequence. By triggering silence generation early as soon as audio EOS is encountered, we ensure SequenceAssetLoader can progress to the next item. PiperOrigin-RevId: 636179966
This is currently set from `Mp3Extractor.synchronizedHeader` which gets overwritten every time we read a new frame. It seems safer to make this defensive copy (and there will be at most one `XingFrame` instance per-playback, so this is not prohibitively expensive). PiperOrigin-RevId: 636181038
PiperOrigin-RevId: 636205459
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 androidx/media main branch.