| commit | b3db402dc6ee1380038c64a648c07fddb8f62597 | [log] [tgz] |
|---|---|---|
| author | Trevor McGuire <[email protected]> | Mon Mar 21 20:17:56 2022 -0700 |
| committer | Trevor McGuire <[email protected]> | Wed Mar 30 15:04:17 2022 -0700 |
| tree | e7f606844154b2bce7fcefecce4d10ad7e112b5a | |
| parent | b35f453dcf0a85cafd47871df661fc0d4b7e8b52 [diff] |
Reset encoder on INACTIVE source fixes
There were a couple edge cases where the video encoder was not being
released when the VideoCapture use case was detached from the camera:
1. After a recording finished and the use case source state is
ACTIVE_NON_STREAMING, when the use case was detached and source
state changed to INACTIVE the encoder was left configured.
2. When the use case was detached while a recording was in progress,
but a new surface was generated before the last surface's
SurfaceRequest listener ran, the encoder was left configured.
These issues are addressed by ensuring the transition to the INACTIVE
state releases the encoder when there is no active Surface and ensures
when the active surface is released in an INACTIVE state, the encoder
is released.
Additionally, this ensures the video encoder will not get a premature
signal that the source is non-streaming during an INACTIVE transition.
This is accomplished by ensuring the SurfaceRequest listener is the one
to signal to the video encoder that the source is stopped.
Also adds error code to log messages that print when Finalize event is
sent.
Relnote: "Fixed an issue where the video codec wasn't released when
VideoCapture<Recorder> was unbound, causing subsequent uses of
VideoCapture<Recorder> to fail on recording with
MediaCodec.CodecException, especially on API 21-22 devices."
Bug: 215109069
Bug: 224547016
Test: VideoRecordingTest
Change-Id: Ie7f684425cc8ea826b8ebbaf426a6c852cc413d1
Jetpack is a suite of libraries, tools, and guidance to help developers write high-quality apps easier. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about.
Jetpack comprises the androidx.* package libraries, unbundled from the platform APIs. This means that it offers backward compatibility and is updated more frequently than the Android platform, making sure you always have access to the latest and greatest versions of the Jetpack components.
Our official AARs and JARs binaries are distributed through Google Maven.
You can learn more about using it from Android Jetpack landing page.
For contributions via GitHub, see the GitHub Contribution Guide.
Note: The contributions workflow via GitHub is currently experimental - only contributions to the following projects are being accepted at this time:
When contributing to Jetpack, follow the code review etiquette.
We are not currently accepting new modules.
Head over to the onboarding docs to learn more about getting set up and the development workflow!
Our continuous integration system builds all in progress (and potentially unstable) libraries as new changes are merged. You can manually download these AARs and JARs for your experimentation.
Before uploading your first contribution, you will need setup a password and agree to the contribution agreement:
Generate a HTTPS password: https://android-review.googlesource.com/new-password
Agree to the Google Contributor Licenses Agreement: https://android-review.googlesource.com/settings/new-agreement
AndroidX uses git to store all the binary Gradle dependencies. They are stored in prebuilts/androidx/internal and prebuilts/androidx/external directories in your checkout. All the dependencies in these directories are also available from google(), jcenter(), or mavenCentral(). We store copies of these dependencies to have hermetic builds. You can pull in a new dependency using our importMaven tool.