For sync-sample-only formats, we have an optimization to drop all buffers with less than the start time when writing them to the queue. For the same formats, if we set a new start time (=seek), we only seek to the buffer at or before the start time. This means the first sample in the queue is different depending on whether we seek to a start time or set a start time and then write samples. This is inconsistent and effectively means the first sample depends on a race condition between the Loader thread (writing samples) and the playback thread (attempting an initial seek in the already loaded samples). The effect of this inconsistency is that we have to decode one sample we don't need (and could have skipped) and that some tests become flaky if the test setup runs into the mentioned race condition. The fix is to change the SampleQueue seek method to also seek to a sample at or after the specified time, to align the behavior to the case where we write the same samples to an empty queue. The change also clarifies the Javadoc of MimeTypes.allSamplesAreSyncSamples to note that this should really only return true if the samples have no "duration" that matters. Otherwise, we could reasonably return true for most subtitle formats although it would break subtitle display because we'd remove samples that start before the seek time. PiperOrigin-RevId: 547189941 |
||
|---|---|---|
| .github/ISSUE_TEMPLATE | ||
| .idea | ||
| demos | ||
| gradle/wrapper | ||
| libraries | ||
| .gitignore | ||
| api.txt | ||
| build.gradle | ||
| common_library_config.gradle | ||
| constants.gradle | ||
| CONTRIBUTING.md | ||
| core_settings.gradle | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| LICENSE | ||
| lint.xml | ||
| missing_aar_type_workaround.gradle | ||
| publish.gradle | ||
| README.md | ||
| RELEASENOTES.md | ||
| SECURITY.md | ||
| settings.gradle | ||
AndroidX Media
AndroidX Media is a collection of libraries for implementing media use cases on Android, including local playback (via ExoPlayer) and media sessions.
Documentation
- The developer guide provides a wealth of information.
- The class reference documents the classes and methods.
- The release notes document the major changes in each release.
- Follow our developer blog to keep up to date with the latest developments!
Migration for existing ExoPlayer and MediaSession projects
You'll find a migration guide for existing ExoPlayer and MediaSession users on developer.android.com.
API stability
AndroidX Media releases provide API stability guarantees, ensuring that the API surface remains backwards compatible for the most commonly used APIs. APIs intended for more advanced use cases are marked as unstable. To use an unstable method or class without lint warnings, you’ll need to add the OptIn annotation before using it. For more information see the UnstableApi documentation.
Using the libraries
You can get the libraries from the Google Maven repository. It's also possible to clone this GitHub repository and depend on the modules locally.
From the Google Maven repository
1. Add module dependencies
The easiest way to get started using AndroidX Media is to add gradle
dependencies on the libraries you need in the build.gradle file of your app
module.
For example, to depend on ExoPlayer with DASH playback support and UI components you can add dependencies on the modules like this:
implementation 'androidx.media3:media3-exoplayer:1.X.X'
implementation 'androidx.media3:media3-exoplayer-dash:1.X.X'
implementation 'androidx.media3:media3-ui:1.X.X'
where 1.X.X is your preferred version. All modules must be the same version.
Please see the AndroidX Media3 developer.android.com page for more information, including a full list of library modules.
This repository includes some modules that depend on external libraries that need to be built manually, and are not available from the Maven repository. Please see the individual READMEs under the libraries directory for more details.
2. Turn on Java 8 support
If not enabled already, you also need to turn on Java 8 support in all
build.gradle files depending on AndroidX Media, by adding the following to the
android section:
compileOptions {
targetCompatibility JavaVersion.VERSION_1_8
}
3. Enable multidex
If your Gradle minSdkVersion is 20 or lower, you should
enable multidex in order
to prevent build errors.
Locally
Cloning the repository and depending on the modules locally is required when
using some libraries. It's also a suitable approach if you want to make local
changes, or if you want to use the main branch.
First, clone the repository into a local directory:
git clone https://github.com/androidx/media.git
cd media
Next, add the following to your project's settings.gradle file, replacing
path/to/media with the path to your local copy:
gradle.ext.androidxMediaModulePrefix = 'media-'
apply from: file("path/to/media/core_settings.gradle")
You should now see the AndroidX Media modules appear as part of your project. You can depend on them as you would on any other local module, for example:
implementation project(':media-lib-exoplayer')
implementation project(':media-lib-exoplayer-dash')
implementation project(':media-lib-ui')
Developing AndroidX Media
Project branches
Development work happens on the main branch. Pull requests should normally be
made to this branch.
The release branch holds the most recent stable release.
Using Android Studio
To develop AndroidX Media using Android Studio, simply open the project in the root directory of this repository.