- 05 Sep, 2022 2 commits
-
-
* Non-standard parameter comment; prefer `/* paramName= */ arg` (see http://go/bugpattern/ParameterComment) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content. * File a bug under go/rosie-bug if there's an issue with how the CL was managed. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth Tested: Local presubmit tests passed. PiperOrigin-RevId: 472252461 (cherry picked from commit 83485bc5)
Googler committed -
No functional changes. PiperOrigin-RevId: 472245797 (cherry picked from commit fa1f09fc)
huangdarwin committed
-
- 02 Sep, 2022 3 commits
-
-
The assertion asserts against a `Period` and an `AdPlaybackState` which actually asserts against a resolved ad which is what `ExoPlayerImplInternal` does later and what gives us a `SEEK_ADJUSTMENT`. However, this assertion is not required at the moment of masking, because we are sure that the resolved seek results in a content period and never an ad period. #minor-release Issue: androidx/media#122 PiperOrigin-RevId: 471827072 (cherry picked from commit 73f86682)
bachinger committed -
shouldPassthrough's internal checks seem to be check whether we should *not* pass through, which seemed a bit like a confusing double-negative to me. shouldTranscode is slightly more clear, by instead returning true when we do want to transcode. No functional changes intended. PiperOrigin-RevId: 471753771 (cherry picked from commit 7085c2fa)
huangdarwin committed
-
- 01 Sep, 2022 2 commits
-
-
https://github.com/androidx/media/commit/3b0d2c15867b3698f130476736785d427b28b7bd made `shouldPassthrough` always return false for `enableHdrVideoEditing`: >We force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path. However, this was introduced before the `videoNeedsEncoding` setting was introduced in https://github.com/androidx/media/commit/3f615040c033a37f81b1d73605cd1f7d420b47b5. That setting should apply to HDR videos as much as SDR videos. PiperOrigin-RevId: 471569853 (cherry picked from commit bc88f8be)
Googler committed -
Replacing remaining usage of MoreExecutors.directExecutor. This allows the service to be switched to run in another process and the app still works the same as if it is running in the same process. Issue: androidx/media#100 PiperOrigin-RevId: 471547177 (cherry picked from commit 9a674543)
rohks committed
-
- 31 Aug, 2022 3 commits
-
-
* Non-standard parameter comment; prefer `/* paramName= */ arg` (see http://go/bugpattern/ParameterComment) (3 times) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content. * File a bug under go/rosie-bug if there's an issue with how the CL was managed. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth Tested: Local presubmit tests passed. PiperOrigin-RevId: 471198016 (cherry picked from commit 6d3cc01d)
Googler committed
- 30 Aug, 2022 8 commits
-
-
In particular, make it a bit more clear that "rendering" and "releasing" frames are related concepts, and how they differ from one another in conjunction with frame dropping. PiperOrigin-RevId: 471037733 (cherry picked from commit 69714e5f)
huangdarwin committed -
Separate MatrixTransformationProcessor constructors by color input and output. PiperOrigin-RevId: 471034768 (cherry picked from commit 1b648296)
huangdarwin committed -
* Non-standard parameter comment; prefer `/* paramName= */ arg` (see http://go/bugpattern/ParameterComment) (19 times) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content. * File a bug under go/rosie-bug if there's an issue with how the CL was managed. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth Tested: Local presubmit tests passed. PiperOrigin-RevId: 471022923 (cherry picked from commit b48ca6e0)
Googler committed -
PiperOrigin-RevId: 471008623 (cherry picked from commit 3ba8bb71)
huangdarwin committed -
* Non-standard parameter comment; prefer `/* paramName= */ arg` (see http://go/bugpattern/ParameterComment) This CL looks good? Just LGTM and Approve it! This CL doesn’t look good? This is what you can do: * Revert this CL, by replying "REVERT: <provide reason>" * File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content. * File a bug under go/rosie-bug if there's an issue with how the CL was managed. * Revert this CL and not get a CL that cleans up these paths in the future by replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to opt out the respective paths in your CL Robot configuration instead: go/clrobot-opt-out. This CL was generated by CL Robot - a tool that cleans up code findings (go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA. Anything wrong with the signup? File a bug at go/clrobot-bug. #codehealth Tested: Local presubmit tests passed. PiperOrigin-RevId: 470953422 (cherry picked from commit 52d32be8)
Googler committed -
This should now expect transformation to succeed. PiperOrigin-RevId: 470950411 (cherry picked from commit daf1e5e2)
andrewlewis committed
-
- 26 Aug, 2022 2 commits
-
-
PiperOrigin-RevId: 470354448 (cherry picked from commit dbe66775)
andrewlewis committed -
TL;DR: we should check if there are new frames available to queue to the ExternalTextureProcessor before actually queueing a frame. The overall flow on the external texture processor: - `SurfaceTexture.onFrameAvailable` is called on `ExtTexMgr`, and - it calls `updateTexImage()`, and sets `frame` - it calls `maybeQueueFrameToExtTexProc()` - the frame is queued to `ExtTexProc` if `frame` is set - From `ExtTexProc.queueInputFrame()`: - notifies the `frameProcessorListener` of available frame - notifies the `inputListener` of `onReadyToAcceptInputFrame` - (`ExtTexMgr` is the listener), it calls `maybeQueueFrameToExtTexProc()` again -- Parallelly -- - `ExtTexProc` calls `inputListener.onInputFrameProcessed`, when the frame is released - (`ExtTexMgr` is the listener), sets `frame` to `null` *Problem* This logic relies on `frame` to be cleared at the right time. In transformer, it's OK b/c `ExtTexProc` release the frame immediately in `queueInputFrame()` and calls `onInputFrameProcessed` which also reset `frame` But in previewing, the frame is not released for a while, up to 10 ms. In this case, `frame` will not reset in this 10 ms, and `maybeQueueFrameToExtTexProc()` is repeatedly queueing the same input frame. PiperOrigin-RevId: 470211620 (cherry picked from commit 91709831)claincly committed
-
- 25 Aug, 2022 4 commits
-
-
PiperOrigin-RevId: 469959215 (cherry picked from commit 2a05a504)
huangdarwin committed
- 24 Aug, 2022 2 commits
-
-
Use the PQ OETF and EOTF to ensure that intermediate fragment shader operations using PQ are in linear BT.2020 rather than PQ and HLG-1 BT.2020. Also, swap the OETF and EOTF in shaders, as they were used incorrectly before Manually tested by verifying transformer demo HLG and PQ videos look the same with and without this CL, including with a BitmapOverlayProcessor enabled to test flows both with one MatrixTransformationProcessor that skips HDR TFs, and with one that doesn't. PiperOrigin-RevId: 469736067 (cherry picked from commit 2ad07e88)
huangdarwin committed
- 23 Aug, 2022 3 commits
-
- 30 Sep, 2022 1 commit
-
-
PiperOrigin-RevId: 469410221 (cherry picked from commit ca41026c)
Marc Baechinger committed
-
- 22 Aug, 2022 1 commit
-
- 19 Aug, 2022 4 commits
-
- 18 Aug, 2022 3 commits
-
-
Remove the manual overwriting of Note ON events that have 0 velocity with Note OFF. JSyn handles this already. - The implementation of "running status" means that the amount of bytes read from the file differ from the size of the sample that ends up in the decoder. The decoder sample contains the applied running status (status of previous event), which the file bytes don't contain. PiperOrigin-RevId: 468537659 (cherry picked from commit 30257c76)
hmzh committed -
Adds a method to FrameProcessor.Listener to be called when an output frame is available and a method releaseOutputFrame in FrameProcessor allowing the caller to trigger release of the oldest available output frame at a given timestamp. Late frames or frames with unset release times are dropped in the FinalMatrixTransformationProcessorWrapper. More than one output frame can become available before they are released if the penultimate GlTextureProcessor is capable of producing multiple output frames. Processing continues while waiting for releaseOutputFrame to be called. Frame release tasks are prioritized over other tasks. PiperOrigin-RevId: 468473072 (cherry picked from commit a5d7fdca)
Googler committed -
Manually tested using transformer demo HLG videos. Before this CL, RGB values after the YUV to RGB conversion reached up to 1.025. After this CL, RGB values correctly clamp at 1.0. PiperOrigin-RevId: 468426092 (cherry picked from commit 244d38cf)
huangdarwin committed
-
- 17 Aug, 2022 2 commits
-
