- 11 Sep, 2022 1 commit
-
- 09 Sep, 2022 4 commits
-
-
https://github.com/google/ExoPlayer/commit/eb6c1183b69d319a610d79ef57028f62e74a7614
*** Original commit *** Handle int instead of byte in SSIM. The value of pixels are converted to integers at the point of use, move this logic to the initialisation step. This is a prerequisite step for testing SSIM calculation, which will lead on to some SSIM improvements being verifiable. Tested manually and SSIM values match for the same video before and after this change. *** PiperOrigin-RevId: 473259446 (cherry picked from commit 8f9c9d0f)
samrobinson committed -
The value of pixels are converted to integers at the point of use, move this logic to the initialisation step. This is a prerequisite step for testing SSIM calculation, which will lead on to some SSIM improvements being verifiable. Tested manually and SSIM values match for the same video before and after this change. PiperOrigin-RevId: 473231779 (cherry picked from commit eb6c1183)
samrobinson committed -
PiperOrigin-RevId: 473212543 (cherry picked from commit 41963fce)
huangdarwin committed
- 08 Sep, 2022 3 commits
-
-
Test that HDR editing succeeds on devices supporting HDR editing, tone maps on devices supporting tone mapping, and throws exceptions on all other devices. Also, only restrict HDR editing and tone mapping support to API 31+ only when transcoding, not for all transformations. PiperOrigin-RevId: 472958965 (cherry picked from commit 8ee21216)
huangdarwin committed
- 07 Sep, 2022 3 commits
-
-
If the back buffer is using too much memory, there is a risk playback could get stuck because LoadControl refuses to load further data. This eventually results in a stuck-buffering playback error. We can detect this case, clear the back buffer and then ask the LoadControl again to avoid failing playback in such a case. PiperOrigin-RevId: 472679797 (cherry picked from commit 125646e4)
tonihei committed
- 06 Sep, 2022 3 commits
-
-
The stream offset is used to calculate the presentation time of a metadata object when reading and later when playing, to calculate the current presentation time to decide whether to send the metadata to the output. Accordingly, the presentation time of a pending metadata that has been calculated with a given offset needs to be recalculated when the stream offset changes. #minor-release PiperOrigin-RevId: 472499943 (cherry picked from commit 5a122377)
bachinger committed
- 19 Oct, 2022 2 commits
-
-
PiperOrigin-RevId: 472488921 (cherry picked from commit 92cfa746)
Marc Baechinger committed -
PiperOrigin-RevId: 472475124 (cherry picked from commit 9c56b2c4)
Marc Baechinger committed
-
- 06 Sep, 2022 3 commits
-
- 05 Sep, 2022 4 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: 472254253 (cherry picked from commit 83966478)
Googler 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: 472252461 (cherry picked from commit dfdcf76d)
Googler committed -
No functional changes. PiperOrigin-RevId: 472245797 (cherry picked from commit 8e14611d)
huangdarwin committed
- 02 Sep, 2022 2 commits
-
-
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 1a4cd549)
huangdarwin committed
- 01 Sep, 2022 1 commit
-
-
https://github.com/google/ExoPlayer/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/google/ExoPlayer/commit/3f615040c033a37f81b1d73605cd1f7d420b47b5. That setting should apply to HDR videos as much as SDR videos. PiperOrigin-RevId: 471569853 (cherry picked from commit 94713a8f)
Googler committed
-
- 31 Aug, 2022 2 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 bac7d697)
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 e6a1936b)
huangdarwin committed -
Separate MatrixTransformationProcessor constructors by color input and output. PiperOrigin-RevId: 471034768 (cherry picked from commit a8e814ab)
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 674b3d45)
Googler committed -
PiperOrigin-RevId: 471008623 (cherry picked from commit cb60f506)
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 f26e5d4c)
Googler committed -
This should now expect transformation to succeed. PiperOrigin-RevId: 470950411 (cherry picked from commit 1023254d)
andrewlewis committed
-
- 26 Aug, 2022 2 commits
-
-
PiperOrigin-RevId: 470354448 (cherry picked from commit f1a3a40e)
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 a8c54dd3)claincly committed
-
- 25 Aug, 2022 2 commits
-
