Skip to content
Snippets Groups Projects
  1. Jun 12, 2023
  2. Aug 31, 2022
  3. Jul 27, 2022
  4. Jul 15, 2022
  5. Jul 08, 2022
  6. Jun 20, 2022
    • Benjamin Gaignard's avatar
      media: hantro: Be more accurate on pixel formats step_width constraints · 135ad96c
      Benjamin Gaignard authored
      
      On Hantro G2 decoder on IMX8MQ strides requirements aren't the same
      for NV12_4L4 and NV12 pixel formats. The first one use a 4 bytes padding
      while the last one needs 16 bytes.
      To be sure to provide the correct stride in all cases we need:
      - to relax the constraints on codec formats so set step_width to 4
      - use capture queue format and not the output queue format when applying
        the pixel format constraints.
      - put the correct step_width constraints on each pixel format.
      
      Move HEVC SPS validation in hantro_hevc.c to be able to perform it
      when setting sps control and when starting to decode the bitstream.
      Add a new test in HEVC SPS validation function to check if resolution
      is still matching the hardware constraints.
      
      With this SAODBLK_A_MainConcept_4 and SAODBLK_B_MainConcept_4 conformance
      tests files are correctly decoded with both NV12 and NV12_4L4 pixel
      formats. These two files have a resolution of 1016x760.
      
      Add defines for the various used resolutions.
      For other variants than Hantro G2 on IMX8M keep the same step_width to
      avoid regressions.
      
      Fluster HEVC test score is now 128/147 vs 126/147 with the both pixel
      formats as decoder output.
      Fluster VP9 test score stay at 147/303.
      
      [hverkuil: fix trivial checkpatch warnings]
      
      Signed-off-by: default avatarBenjamin Gaignard <benjamin.gaignard@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      135ad96c
  7. May 17, 2022
  8. May 13, 2022
  9. Apr 24, 2022
  10. Mar 07, 2022
  11. Jan 28, 2022
  12. Dec 16, 2021
  13. Dec 14, 2021
    • Benjamin Gaignard's avatar
      media: hantro: Fix G2/HEVC negotiated pixelformat · 4c1aaf09
      Benjamin Gaignard authored
      G2/HEVC is broken because driver capture queue pixelformat ioctl G_FMT
      returns VT12 while G2/HEVC always generate NV12 frames:
      
      video1: VIDIOC_S_FMT: type=vid-out-mplane, width=2560, height=1600, format=S265 little-endian (0x35363253), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
      plane 0: bytesperline=0 sizeimage=6144000
      video1: VIDIOC_S_EXT_CTRLS: which=0x0, count=1, error_idx=0, request_fd=0, name=HEVC Sequence Parameter Set, id/size=0x990cf0/32
      video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
      plane 0: bytesperline=2560 sizeimage=6144000
      video1: VIDIOC_ENUM_FMT: index=0, type=vid-cap-mplane, flags=0x0, pixelformat=NV12 little-endian (0x3231564e), mbus_code=0x0000, description='Y/CbCr 4:2:0'
      video1: VIDIOC_ENUM_FMT: error -22: index=1, type=vid-cap-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
      video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
      
      Use the postprocessor functions introduced by Hantro G2/VP9 codec series
      to fix the issue and remove duplicated buffer management.
      This allow Hantro G2/HEVC to produce NV12_4L4 and NV12.
      
      Fluster scores are 77/147 for HEVC and 129/303 for VP9 (no regression).
      
      Beauty, Jockey and ShakeNDry bitstreams from UVG (http://ultravideo.fi/
      
      )
      set have also been tested.
      
      Fixes: 53a3e710 ("media: hantro: Simplify postprocessor")
      Signed-off-by: default avatarBenjamin Gaignard <benjamin.gaignard@collabora.com>
      Reviewed-by: default avatarEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      4c1aaf09
  14. Nov 30, 2021
    • Chen-Yu Tsai's avatar
      media: hantro: Hook up RK3399 JPEG encoder output · 230d683a
      Chen-Yu Tsai authored
      
      The JPEG encoder found in the Hantro H1 encoder block only produces a
      raw entropy-encoded scan. The driver is responsible for building a JPEG
      compliant bitstream and placing the entropy-encoded scan in it. Right
      now the driver uses a bounce buffer for the hardware to output the raw
      scan to.
      
      In commit e765dba1 ("hantro: Move hantro_enc_buf_finish to JPEG
      codec_ops.done"), the code that copies the raw scan from the bounce
      buffer to the capture buffer was moved, but was only hooked up for the
      Hantro H1 (then RK3288) variant. The RK3399 variant was broken,
      producing a JPEG bitstream without the scan, and the capture buffer's
      .bytesused field unset.
      
      Fix this by duplicating the code that is executed when the JPEG encoder
      finishes encoding a frame. As the encoded length is read back from
      hardware, and the variants having different register layouts, the
      code is duplicated rather than shared.
      
      Fixes: e765dba1 ("hantro: Move hantro_enc_buf_finish to JPEG codec_ops.done")
      Signed-off-by: default avatarChen-Yu Tsai <wenst@chromium.org>
      Tested-by: default avatarNicolas Dufresne <nicolas.dufresne@collabora.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      230d683a
  15. Nov 22, 2021
  16. Sep 30, 2021
  17. Jul 22, 2021
  18. Jun 17, 2021
  19. Jun 08, 2021
  20. May 23, 2021
Loading