1. 02 Jun, 2020 1 commit
  2. 22 May, 2020 4 commits
  3. 21 May, 2020 4 commits
  4. 26 Dec, 2019 1 commit
  5. 23 Dec, 2019 1 commit
  6. 17 Dec, 2019 1 commit
  7. 12 Dec, 2019 2 commits
  8. 20 Aug, 2019 1 commit
  9. 19 Aug, 2019 1 commit
  10. 28 May, 2019 1 commit
  11. 18 May, 2018 1 commit
    • Chih-Yu Huang's avatar
      Rockchip: Store cropped size in v4l plugin. · 5e603425
      Chih-Yu Huang authored
      When setting the format of OUTPUT queue, the rockchip driver may
      increase the height 16 to align the buffer. For example, when setting
      QCIF(176x144) size, the driver will adjust to 176x160. However, the
      driver doesn't accept the cropped size with larger than 16 (1 MB).
      That means, we cannot use crop to set the correct resolution.
      
      This CL stores the cropped size at the plugin, and uses it as the
      resolution of the encoded video. Regardless there are some restriction
      about the cropped size at the driver, the plugin allow any cropped
      size.
      
      BUG=b:79551489
      TEST=pass VEA unittest with QCIF video.
      TEST=pass testEncodeDecodeVideoFromBufferToBufferQCIF CTS
      
      Change-Id: Iabfb80aa7c5bff357e91661bd3ede581b5aef83a
      Reviewed-on: https://chromium-review.googlesource.com/1061035
      
      
      Commit-Ready: Chih-Yu Huang <akahuang@chromium.org>
      Tested-by: default avatarChih-Yu Huang <akahuang@chromium.org>
      Reviewed-by: default avatarTomasz Figa <tfiga@chromium.org>
      5e603425
  12. 07 Mar, 2018 2 commits
  13. 20 Jul, 2017 1 commit
  14. 07 Sep, 2016 2 commits
  15. 05 Sep, 2016 2 commits
  16. 22 Aug, 2016 1 commit
  17. 25 May, 2016 1 commit
  18. 04 Aug, 2015 1 commit
  19. 19 Jun, 2015 1 commit
  20. 18 Jun, 2015 2 commits
  21. 12 May, 2015 1 commit
    • Tomasz Figa's avatar
      Rockchip: Force first 3x3 array of macroblocks of frame to be intra blocks · 819d3d20
      Tomasz Figa authored
      When running decoding in parallel with encoding (i.e. one frame of decoding,
      one frame of encoding, etc.), due to hardware issue, encoder block does not
      properly reinitialize some internal SRAM, which is shared with decoder block
      and resulting encoded frame might be corrupted.
      
      According to Rockchip engineers, to work around the issue, a large enough
      block of macroblocks need to be encoded as intra block in every frame to
      make that area of SRAM be reinitialized by other part of encoder block.
      
      This patch makes the plugin always force first 3x3 block of macroblocks to
      be encoded as intra blocks to prevent encoding corruption.
      
      BUG=chrome-os-partner:36844
      TEST=AppRTC loopback in current tab with Lorax trailer playing in another
      
      Change-Id: I43b7c7d3ec037842ba8dd8e57c9e76b43e46926a
      Reviewed-on: https://chromium-review.googlesource.com/270301
      
      Tested-by: default avatarTomasz Figa <tfiga@chromium.org>
      Reviewed-by: default avatarPawel Osciak <posciak@chromium.org>
      Commit-Queue: Tomasz Figa <tfiga@chromium.org>
      819d3d20
  22. 27 Mar, 2015 1 commit
  23. 28 Feb, 2015 3 commits
    • Tomasz Figa's avatar
      Rockchip: Do not reset rate control if no parameters changed · f6e383a6
      Tomasz Figa authored
      Current code always resets rate control algorithm whenever
      rk_vp8_encoder_setconfig() is called. However the function can be also
      used to request a keyframe. In addition, it might be possible to call
      this function with the same parameters as already set, which would cause
      rate control to be reset unnecessarily.
      
      To fix the problem, this patch modifies the code to perform the reset only
      if bit rate or frame rate actually changed. To achieve this the internal
      API is slightly modified to avoid accessing private parameters
      (outRateDenom, outRateNum and encStatus of internal vp8Instance_s struct)
      from external code (e.g. rk_vpu8_encoder_setconfig()) and explicitly convey
      the dependence of VP8EncSetRateCtrl() on these private parameters,
      which are now explicitly given to this function.
      
      BUG=chrome-os-partner:37204
      TEST=video_encode_accelerator_unittest (after 4fc28962e2da8b3f278b952c55fefe10487db952);apprtc
      
      Change-Id: Iff4787f6ac55a0324e63b80d272dfd04aadd084c
      Reviewed-on: https://chromium-review.googlesource.com/253252
      
      Reviewed-by: default avatarWu-cheng Li <wuchengli@chromium.org>
      Commit-Queue: Tomasz Figa <tfiga@chromium.org>
      Tested-by: default avatarTomasz Figa <tfiga@chromium.org>
      f6e383a6
    • Tomasz Figa's avatar
      Rockchip: Zero the params struct after deferred setting · aed2ed96
      Tomasz Figa authored
      rk_vepu_update_parameter() expects all parameters that do not change to
      be zero, so after we apply them in
      qbuf_if_pending_buffer_exists_locked(), we need to memset the struct to
      zero, just as ioctl_s_ext_ctrls_locked() already does if setting is not
      deferred by pending buffer. Otherwise, a keyframe might be requested by
      the way of other parameter change request.
      
      BUG=chrome-os-partner:37203
      TEST=video_encode_accelerator_unittest (after 4fc28962e2d);apprtc
      
      Change-Id: I1f3a6551b2c5faedbb789506c4b84e021ef68792
      Reviewed-on: https://chromium-review.googlesource.com/253251
      
      Reviewed-by: default avatarWu-cheng Li <wuchengli@chromium.org>
      Commit-Queue: Tomasz Figa <tfiga@chromium.org>
      Tested-by: default avatarTomasz Figa <tfiga@chromium.org>
      aed2ed96
    • Tomasz Figa's avatar
      Rockchip: Implement keyframe requests correctly · f37b1cb1
      Tomasz Figa authored
      Currently, when rk_vepu_update_param() is called with keyframe request
      the codingType field in EncoderParameters structure is set to intra
      frame. However, every frame, frame counter is evaluated and this field
      is overwritten with frame type determined automatically, which results
      in ignoring keyframe requests.
      
      To fix this, store keyframe request flag in a separate field and then
      use it as additional factor for code determining frame type for next
      frame.
      
      BUG=chrome-os-partner:37203
      TEST=video_encode_accelerator_unittest (after 4fc28962e2da8b3f278b952c55fefe10487db952); apprtc
      
      Change-Id: I8acd8c5bfa6aded4b2139082b26b773828fc0dc8
      Reviewed-on: https://chromium-review.googlesource.com/251970
      
      Reviewed-by: default avatarWu-cheng Li <wuchengli@chromium.org>
      Commit-Queue: Tomasz Figa <tfiga@chromium.org>
      Tested-by: default avatarTomasz Figa <tfiga@chromium.org>
      f37b1cb1
  24. 13 Jan, 2015 1 commit
  25. 09 Jan, 2015 1 commit
  26. 19 Dec, 2014 1 commit
  27. 15 Dec, 2014 1 commit