Feat/migrate media3 #35
Merged
Conversation
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
Contributor
guoen21
commented
Jan 2, 2025
- Migrate media3 from 1.2.1 to 1.4.1
- Polish the failed unit tests case
- Fix the Cue.fromBundle issue
- Clean the dice stream playback logic on test player
- Polish the publish.gradle
This change was originally made in androidx/media@6f82491 It was then accidentally lost in when `Cea708Parser` was merged back into `Cea708Decoder` in androidx/media@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 androidx/media@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 androidx/media@379cb3b, which was also lost in androidx/media@25498b1. I will send a separate change to resolve this. PiperOrigin-RevId: 635796696
This change was originally made in androidx/media@379cb3b. It was then accidentally lost in when `Cea608Parser` was merged back into `Cea608Decoder` in androidx/media@25498b1. This was spotted when re-doing a similar lost change to `Cea708Decoder`, reported in androidx/media#1315. See reasoning on androidx/media@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 androidx/media@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: androidx/media#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
Merge latest androidx/media main branch
Add composition time offset parameter to TRUN box to support muxing of videos containing B-frames by FragmentedMp4Muxer. Update TRUN box version from 0 to 1 in order to manage signed composition time offset. PiperOrigin-RevId: 636426397
PiperOrigin-RevId: 636482934
Remove redundant test logic to add file size to ExportResult because the file size is already added to export result as part of an export finishing. PiperOrigin-RevId: 636499236
PiperOrigin-RevId: 636506860
Update current row value when new line is added.
None of the AndroidX libs we depend on require jetification any more. Issue: androidx/media#1362 PiperOrigin-RevId: 636544337
This helps to debug issues reported in androidx/media#1191 PiperOrigin-RevId: 636545970
This is generated in response to a deprecation warning in AS: ``` The option setting 'android.defaults.buildfeatures.buildconfig=true' is deprecated. The current default is 'false'. It will be removed in version 9.0 of the Android Gradle plugin. You can resolve this warning in Android Studio via `Refactor` > `Migrate BuildConfig to Gradle Build Files` ``` PiperOrigin-RevId: 636546985
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: androidx/media#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 (cherry picked from commit 3763e5b)
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: androidx/media#1472 PiperOrigin-RevId: 660826116 (cherry picked from commit 8b33ad5)
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: androidx/media#1516 #cherrypick PiperOrigin-RevId: 661195634 (cherry picked from commit f37f969)
Issue: androidx/media#1581 PiperOrigin-RevId: 662515428 (cherry picked from commit c48c051)
When there is an exception thrown from the `LoadTask`, the `Loader` will call `Loader.Callback.onLoadError`. Some implementations of `onLoadError` method may call `MediaPeriod.onContinueLoadingRequested`, and in the `PreloadMediaSource`, its `PreloadMediaPeriodCallback` will be triggered and then it can further call `continueLoading` if it finds needed. However the above process is currently done synchronously, which will cause problem. By calling `continueLoading`, the `Loader` is set with a `currentTask`, and when that long sync logic in `Loader.Callback.onLoadError` ends, the `Loader` will immediately retry, and then a non-null `currentTask` will cause the `IllegalStateException`. Issue: androidx/media#1568 PiperOrigin-RevId: 662550622 (cherry picked from commit cd532c5)
This method was added in API 31 (S) but it's non-functional (incorrectly, silently, returns `false`) on the Widevine plugin version (`16.0`) from R (API 30), which some devices up to at least API 34 are still using. This results in ExoPlayer incorrectly selecting an insecure decoder for L1 secure content, and subsequently calling `MediaCodec.queueInputBuffer` instead of `queueSecureInputBuffer`, which is not supported and generates the following error: > Operation not supported in this configuration: ERROR_DRM_CANNOT_HANDLE Issue: androidx/media#1603 #cherrypick PiperOrigin-RevId: 662852176 (cherry picked from commit ca455ee)
#cherrypick PiperOrigin-RevId: 663705597 (cherry picked from commit 1ffc962)
It is possible for playback to be stuck when there is failure in loading further data, while the player is required to load more due to the buffered duration being under `DefaultLoadControl.bufferForPlayback`. Therefore, we check if there is any loading error in `isLoadingPossible`, so that the player will allow the playback of the existing data rather than waiting forever for the data that can never be loaded. Issue: androidx/media#1571 PiperOrigin-RevId: 665801674 (cherry picked from commit 351593a)
PiperOrigin-RevId: 666328660 (cherry picked from commit 1994ccd)
PiperOrigin-RevId: 666347191 (cherry picked from commit 829cad6)
|
Wow!!! |
szaboa
previously approved these changes
Jan 6, 2025
hongfeih-es
approved these changes
Jan 7, 2025
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.