Skip to content
Snippets Groups Projects
Select Git revision
  • master
  • rk3288-encoder-wip default
  • v1p-20210224
3 results
Search by author
  • Any Author
  • Nicolas Dufresne Nicolas Dufresne nicolas
1 author
  1. Jun 02, 2020
  3. May 22, 2020
  5. May 21, 2020
  7. Dec 26, 2019
  9. Dec 23, 2019
  11. Dec 17, 2019
  13. Dec 12, 2019
  15. Aug 20, 2019
  17. Aug 19, 2019
  19. May 28, 2019
  21. May 18, 2018
    • 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
  23. Mar 07, 2018
  25. Jul 20, 2017
  27. Sep 07, 2016
  29. Sep 05, 2016
  31. Aug 22, 2016
  33. May 25, 2016
  35. Aug 04, 2015
  37. Jun 19, 2015
  39. Jun 18, 2015
  41. May 12, 2015
    • 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
  43. Mar 27, 2015
  45. Feb 28, 2015
    • 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
  47. Jan 13, 2015
  49. Jan 09, 2015
  51. Dec 19, 2014
  53. Dec 15, 2014