1. 30 Aug, 2022 8 commits
    • Effect: Add some FrameProcessor javadoc. · 958df4e0
      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
    • HDR: Use factory for MatrixTransformationProcessor. · 6c51aa94
      Separate MatrixTransformationProcessor constructors by color input and output.
      
      PiperOrigin-RevId: 471034768
      (cherry picked from commit 1b648296)
      huangdarwin committed
    • Fix 19 ErrorProneStyle findings: · 09d613b9
      * 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
    • Add static Grayscale and Inverted RGB Filter. · fb43ce20
      PiperOrigin-RevId: 471017440
      (cherry picked from commit 85950423)
      leonwind committed
    • Update first frame instructions. · 2490a787
      PiperOrigin-RevId: 471008623
      (cherry picked from commit 3ba8bb71)
      huangdarwin committed
    • Remove media3-only line from exoplayer2 `build.gradle` file · 30e55ad7
      #minor-release
      
      PiperOrigin-RevId: 470999044
      (cherry picked from commit 932f0d22)
      ibaker committed
    • Fix 1 ErrorProneStyle finding: · e49cde80
      * 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
    • Update color info mismatch test · 19fad593
      This should now expect transformation to succeed.
      
      PiperOrigin-RevId: 470950411
      (cherry picked from commit daf1e5e2)
      andrewlewis committed
  2. 26 Aug, 2022 2 commits
    • Log instead of throwing for transfer mismatch · f3adc5a5
      PiperOrigin-RevId: 470354448
      (cherry picked from commit dbe66775)
      andrewlewis committed
    • Fix ExternalTextureManager: repeated queueing input frame in preview · 7fc1e4a6
      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
  3. 25 Aug, 2022 4 commits
  4. 24 Aug, 2022 2 commits
    • Fix missing id error · 6b5a9e80
      PiperOrigin-RevId: 469750922
      (cherry picked from commit 84577949)
      rohks committed
    • HDR: Add PQ support. · 7e7f07f8
      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
  5. 23 Aug, 2022 3 commits
  6. 30 Sep, 2022 1 commit
  7. 22 Aug, 2022 1 commit
  8. 19 Aug, 2022 4 commits
  9. 18 Aug, 2022 3 commits
    • Fix the command sample size given to trackOutput. · d7523d03
      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
    • Allow frame release to be controlled outside FrameProcessor. · 166838ae
      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
    • HDR: Clamp YUV to RGB conversion. · 068a9d10
      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
  10. 17 Aug, 2022 3 commits
  11. 16 Aug, 2022 3 commits
  12. 15 Aug, 2022 5 commits
    • Allow high-priority tasks to be executed before other tasks. · f6dde782
      This is needed as a pre-requisite for allowing MCVR to control
      FrameProcessor frame release for previewing.
      
      Submitting a high-priority task is conceptually different from
      posting at the front of a single queue of tasks, as the high-priority
      tasks are executed in FIFO order among themselves. This will ensure
      that frame release tasks submitted in close succession are executed
      in the order they are submitted but before any lower priority tasks.
      
      PiperOrigin-RevId: 467675137
      (cherry picked from commit 59be7322)
      Googler committed
    • Increase max sample size for HEVC. · 56ed1e11
      Increase the estimated max sample size for HEVC by 2x, and set a minimum
      size of 2MB. The 2MB will be applied for resolutions up to 1080p, after
      which the new calculation takes effect. This is in par with the
      platform's HEVC software decoder.
      
      PiperOrigin-RevId: 467641494
      (cherry picked from commit b83b16eb)
      christosts committed
    • Update CMake version for AV1 extension · f6a71d3a
      The specified CMake version doesn't work with the latest
      Android Studio releases. Updating to a more recent version
      fixes the problem.
      
      Issue: google/ExoPlayer#9933
      PiperOrigin-RevId: 467634063
      (cherry picked from commit 9e1d4f6f)
      tonihei committed
    • Add initial version of SimpleBasePlayer · b6002a35
      This base class will simplify the implementation of custom
      Player classes. The current version only supports
      available commands and playWhenReady handling.
      
      PiperOrigin-RevId: 467618021
      (cherry picked from commit 43ede97d)
      tonihei committed
    • Increase pixel difference threshold · a2815141
      PiperOrigin-RevId: 467610621
      (cherry picked from commit 73d606ac)
      andrewlewis committed
  13. 12 Aug, 2022 1 commit
    • MediaNotificationManager: handle playback ended · 19cc87c0
      When the player finishes playback and reaches the STATE_ENDED,
      the notification remains visible with a pause button and the
      service is kept in the foreground. This is a bug.
      
      With this change, when the player reaches the STATE_ENDED, the
      service is stopped from the foreground and a notification is shown
      with a play button. If the play icon is tapped, the player will restart
      playback of the last played item. Playing the last played item again
      is the existing behavior when play/pause commands are received from
      the legacy MediaSession (e.g. BT headset buttons).
      
      #minor-release
      
      Issue: google/ExoPlayer#112
      PiperOrigin-RevId: 467231509
      (cherry picked from commit 7a7e1eb2)
      christosts committed