Qualcomm kaanapali platform have a newer generation of video IP iris4. 
The hardware have evolved mostly with respect to higher number of power 
domains as well as multiple clock sources.

The series extends support for multiple iommu-map entries for the same 
input id. Considering iris as a client driver, it adds the handling for 
multiple stream ids from VPU via iommu-map.

This series is depend on the below series:
Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/

Following are the compliance and functional validation reports.

v4l2-compliance report for decoder including streaming tests:

v4l2-compliance 1.33.0-5441, 64 bits, 64-bit time_t
v4l2-compliance SHA: 4310f15610f4 2026-01-18 22:09:17

Compliance test for iris_driver device /dev/video0:

Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Decoder
        Bus info         : platform:2000000.video-codec
        Driver version   : 6.19.0
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateful Decoder

Required ioctls:
        test VIDIOC_QUERYCAP: OK
        test invalid ioctls: OK

Allow for multiple opens:
        test second /dev/video0 open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK
        test for unlimited opens: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
        test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
        test VIDIOC_QUERYCTRL: OK
        test VIDIOC_G/S_CTRL: OK
        test VIDIOC_G/S/TRY_EXT_CTRLS: OK
        test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
        test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
        Standard Controls: 12 Private Controls: 0

Format ioctls:
        test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
        test VIDIOC_G/S_PARM: OK (Not Supported)
        test VIDIOC_G_FBUF: OK (Not Supported)
        test VIDIOC_G_FMT: OK
        test VIDIOC_TRY_FMT: OK
        test VIDIOC_S_FMT: OK
        test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
        test Cropping: OK
        test Composing: OK
        test Scaling: OK (Not Supported)

Codec ioctls:
        test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
        test VIDIOC_G_ENC_INDEX: OK (Not Supported)
        test VIDIOC_(TRY_)DECODER_CMD: OK

Buffer ioctls:
        test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
        test CREATE_BUFS maximum buffers: OK
        test VIDIOC_REMOVE_BUFS: OK
        test VIDIOC_EXPBUF: OK
        test Requests: OK (Not Supported)
        test blocking wait: OK

Test input 0:

Streaming ioctls:
        test read/write: OK (Not Supported)
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (select, REQBUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (epoll, REQBUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (select, CREATE_BUFS): OK
the input file is smaller than 7077888 bytes
        Video Capture Multiplanar: Captured 465 buffers
        test MMAP (epoll, CREATE_BUFS): OK
        test USERPTR (select): OK (Not Supported)
        test DMABUF: Cannot test, specify --expbuf-device

Total for iris_driver device /dev/video0: 54, Succeeded: 54, Failed: 0, 
Warnings: 0

v4l2-compliance report for encoder including streaming tests:

v4l2-compliance 1.33.0-5441, 64 bits, 64-bit time_t
v4l2-compliance SHA: 4310f15610f4 2026-01-18 22:09:17

Compliance test for iris_driver device /dev/video1:

Driver Info:
        Driver name      : iris_driver
        Card type        : Iris Encoder
        Bus info         : platform:2000000.video-codec
        Driver version   : 6.19.0
        Capabilities     : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
        Detected Stateful Encoder

Required ioctls:
        test VIDIOC_QUERYCAP: OK
        test invalid ioctls: OK

Allow for multiple opens:
        test second /dev/video1 open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK
        test for unlimited opens: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
        test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
        test VIDIOC_QUERYCTRL: OK
        test VIDIOC_G/S_CTRL: OK
        test VIDIOC_G/S/TRY_EXT_CTRLS: OK
        test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
        test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
        Standard Controls: 38 Private Controls: 0

Format ioctls:
        test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
        test VIDIOC_G/S_PARM: OK
        test VIDIOC_G_FBUF: OK (Not Supported)
        test VIDIOC_G_FMT: OK
        test VIDIOC_TRY_FMT: OK
        test VIDIOC_S_FMT: OK
        test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
        test Cropping: OK
        test Composing: OK (Not Supported)
        test Scaling: OK (Not Supported)

Codec ioctls:
        test VIDIOC_(TRY_)ENCODER_CMD: OK
        test VIDIOC_G_ENC_INDEX: OK (Not Supported)
        test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
        test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
        test CREATE_BUFS maximum buffers: OK
        test VIDIOC_REMOVE_BUFS: OK
        test VIDIOC_EXPBUF: OK
        test Requests: OK (Not Supported)
        test blocking wait: OK

Test input 0:

Streaming ioctls:
        test read/write: OK (Not Supported)
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (select, REQBUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (epoll, REQBUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (select, CREATE_BUFS): OK
        Video Capture Multiplanar: Captured 61 buffers
        test MMAP (epoll, CREATE_BUFS): OK
        test USERPTR (select): OK (Not Supported)
        test DMABUF: Cannot test, specify --expbuf-device

Total for iris_driver device /dev/video1: 54, Succeeded: 54, Failed: 0, 
Warnings: 0

gstreamer test:
Decoders validated with below commands, codec specific:
gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
video/x-raw,format=I420 ! filesink location=<output_file.yuv>

Encoders validated with below commands:
gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
capture-io-mode=4 output-io-mode=4 ! filesink sync=true
location=<output_file.h264>

gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
capture-io-mode=4 output-io-mode=4 ! filesink sync=true
location=<output_file.hevc>

ffmpeg test:
Decoders validated with below commands:
ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0
output_file.yuv -y
ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0
output_file.yuv -y

v4l2-ctl test
Decoders validated with below commands:
v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=<input_file.h264> --stream-to=<output_file.yuv>

v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from=input_file.bit --stream-to=<output_file.yuv>

v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90
--set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
--stream-from-hdr=input_file.hdr  --stream-mmap
--stream-to=<output_file.yuv>

Encoders validated with below commands:
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d
/dev/video1
v4l2-ctl --verbose
--set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
--set-selection-output
target=crop,top=0,left=0,width=<width>,height=<height>
--set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap
--stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d
/dev/video1

Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Charan Teja Kalla (2):
      of: factor out of_map_id() code
      of/iommu: add multi-map support

Vikash Garodia (5):
      media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding
      media: iris: Switch to hardware mode after firmware boot
      media: iris: add context bank devices using iommu-map
      media: iris: add helper to select context bank device
      media: iris: Add platform data for kaanapali

 .../bindings/media/qcom,kaanapali-iris.yaml        | 234 +++++++++++++++++++++
 drivers/iommu/of_iommu.c                           |  36 +++-
 drivers/media/platform/qcom/iris/iris_buffer.c     |   7 +-
 drivers/media/platform/qcom/iris/iris_buffer.h     |   2 +
 drivers/media/platform/qcom/iris/iris_core.c       |   4 +
 drivers/media/platform/qcom/iris/iris_hfi_common.c |   4 +
 drivers/media/platform/qcom/iris/iris_hfi_queue.c  |  16 +-
 .../platform/qcom/iris/iris_platform_common.h      |  30 +++
 .../media/platform/qcom/iris/iris_platform_gen2.c  |  90 ++++++++
 .../platform/qcom/iris/iris_platform_kaanapali.h   |  80 +++++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  59 +++++-
 drivers/media/platform/qcom/iris/iris_resources.c  |  93 ++++++++
 drivers/media/platform/qcom/iris/iris_resources.h  |   3 +
 drivers/media/platform/qcom/iris/iris_vidc.c       |   4 +-
 drivers/media/platform/qcom/iris/iris_vpu2.c       |   1 +
 drivers/media/platform/qcom/iris/iris_vpu3x.c      |   9 +-
 drivers/media/platform/qcom/iris/iris_vpu4x.c      |  24 ++-
 drivers/media/platform/qcom/iris/iris_vpu_common.c |  16 +-
 drivers/media/platform/qcom/iris/iris_vpu_common.h |   3 +
 drivers/of/base.c                                  |  69 ++++--
 include/linux/of.h                                 |   6 +
 21 files changed, 726 insertions(+), 64 deletions(-)
---
base-commit: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
change-id: 20260126-kaanapali-iris-29fd184e2fe4
prerequisite-message-id: <20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com>
prerequisite-patch-id: 1d896ff4a958ebd06066dbf705c4c45cf73b6041
prerequisite-patch-id: 44414df7d8342ca19c0518ac087f08f98546c3ff
prerequisite-patch-id: 0f45ca6f67948e03a89274c144660a55b3ff8fb1

Best regards,
-- 
Vikash Garodia <vikash.garodia@oss.qualcomm.com>

On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> Qualcomm kaanapali platform have a newer generation of video IP iris4. 
> The hardware have evolved mostly with respect to higher number of power 
> domains as well as multiple clock sources.
> 
> The series extends support for multiple iommu-map entries for the same 
> input id. Considering iris as a client driver, it adds the handling for 
> multiple stream ids from VPU via iommu-map.
> 
> This series is depend on the below series:
> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> 
> Following are the compliance and functional validation reports.

Please validate with fluster too. Having a "knowingly good" command line
is not a validation. It can't be reproduced by anybody else.

> gstreamer test:
> Decoders validated with below commands, codec specific:
> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
> video/x-raw,format=I420 ! filesink location=<output_file.yuv>

Neither of these commands specify, what exactly was validated. They
specify that you've validated _some_ videos. It's impossible to even
reproduce your results, because you don't specify which files you've
used.

> 
> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> Encoders validated with below commands:
> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> location=<output_file.h264>

At least these should use test sinks in order to be reproducible.

> 
> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h265enc
> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> location=<output_file.hevc>
> 
> ffmpeg test:
> Decoders validated with below commands:
> ffmpeg -vcodec h264_v4l2m2m -i <input_file.h264> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> ffmpeg -vcodec hevc_v4l2m2m -i <input_file.hevc> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> ffmpeg -vcodec vp9_v4l2m2m -i <input_file.webm> -pix_fmt nv12 -vsync 0
> output_file.yuv -y
> 
> v4l2-ctl test
> Decoders validated with below commands:
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=H264
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from=<input_file.h264> --stream-to=<output_file.yuv>
> 
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from=input_file.bit --stream-to=<output_file.yuv>
> 
> v4l2-ctl --verbose --set-fmt-video-out=pixelformat=VP90
> --set-fmt-video=pixelformat=NV12 --stream-mmap --stream-out-mmap
> --stream-from-hdr=input_file.hdr  --stream-mmap
> --stream-to=<output_file.yuv>
> 
> Encoders validated with below commands:
> v4l2-ctl --verbose
> --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
> --set-selection-output
> target=crop,top=0,left=0,width=<width>,height=<height>
> --set-fmt-video=pixelformat=H264 --stream-mmap --stream-out-mmap
> --stream-from=<input_file.yuv> --stream-to=<output_file.h264> -d
> /dev/video1
> v4l2-ctl --verbose
> --set-fmt-video-out=width=<width>,height=<height>,pixelformat=NV12
> --set-selection-output
> target=crop,top=0,left=0,width=<width>,height=<height>
> --set-fmt-video=pixelformat=HEVC --stream-mmap --stream-out-mmap
> --stream-from=<input_file.yuv> --stream-to=<output_file.hevc> -d
> /dev/video1

-- 
With best wishes
Dmitry

On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
>> Qualcomm kaanapali platform have a newer generation of video IP iris4.
>> The hardware have evolved mostly with respect to higher number of power
>> domains as well as multiple clock sources.
>>
>> The series extends support for multiple iommu-map entries for the same
>> input id. Considering iris as a client driver, it adds the handling for
>> multiple stream ids from VPU via iommu-map.
>>
>> This series is depend on the below series:
>> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
>>
>> Following are the compliance and functional validation reports.
> 
> Please validate with fluster too. Having a "knowingly good" command line
> is not a validation. It can't be reproduced by anybody else.
> 

Below is the fluster result on kaanapali (will add in cover letter in 
next revision)

H264:
77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
- 52 test vectors failed due to interlaced clips - not supported
- 3 test vectors failed due to unsupported bitstream.
- 2 test vectors failed because SP_SLICE type - not supported by the
   hardware.
- 1 test vector failed due to unsupported profile

H265:
  129/147 testcases passed while testing JCT-VC-HEVC_V1 with
  GStreamer-H.265-V4L2-Gst1.0.
  The failing test case:
  - 10 testcases failed due to unsupported 10 bit format.
  - 4 testcase failed due to unsupported resolution
  - 2 testcase failed due to CRC mismatch
  - 2 test fails due to session error (under debug)
    - PICSIZE_C_Bossen_1
    - WPP_E_ericsson_MAIN_2

VP9:
235/305 testcases passed while testing VP9-TEST-VECTORS with
  GStreamer-VP9-V4L2-Gst1.0.
  The failing test case:
  - 64 testcases failed due to unsupported resolution
  - 2 testcases failed due to unsupported format
  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
  - 2 testcase failed due to unsupported resolution after sequence change
  - 1 testcase failed due to unsupported stream

>> gstreamer test:
>> Decoders validated with below commands, codec specific:
>> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
>> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> 
> Neither of these commands specify, what exactly was validated. They
> specify that you've validated _some_ videos. It's impossible to even
> reproduce your results, because you don't specify which files you've
> used.
> 

commands are shared indicating the pipeline used for validation for 
different codec plugins. These are some basic encode and decode 
commands, and shared for reference for anyone to pick input test files 
of their own.

>>
>> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
>> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>
>> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
>> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>
>> Encoders validated with below commands:
>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>> location=<output_file.h264>
> 
> At least these should use test sinks in order to be reproducible.

it is using filesink in the pipeline to generate the encoded bitstream

Regards,
Vikash

On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> 
> On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> > > Qualcomm kaanapali platform have a newer generation of video IP iris4.
> > > The hardware have evolved mostly with respect to higher number of power
> > > domains as well as multiple clock sources.
> > > 
> > > The series extends support for multiple iommu-map entries for the same
> > > input id. Considering iris as a client driver, it adds the handling for
> > > multiple stream ids from VPU via iommu-map.
> > > 
> > > This series is depend on the below series:
> > > Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> > > 
> > > Following are the compliance and functional validation reports.
> > 
> > Please validate with fluster too. Having a "knowingly good" command line
> > is not a validation. It can't be reproduced by anybody else.
> > 
> 
> Below is the fluster result on kaanapali (will add in cover letter in next
> revision)

Nice, thanks!

> 
> H264:
> 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.

What about the extension testsuites? Even if they are not supported,
they should not crash or cause the timeouts.

> - 52 test vectors failed due to interlaced clips - not supported

Yet or completely? Does "failed" mean "returned an error" or something
else?

> - 3 test vectors failed due to unsupported bitstream.
> - 2 test vectors failed because SP_SLICE type - not supported by the
>   hardware.
> - 1 test vector failed due to unsupported profile
> 
> H265:
>  129/147 testcases passed while testing JCT-VC-HEVC_V1 with
>  GStreamer-H.265-V4L2-Gst1.0.
>  The failing test case:
>  - 10 testcases failed due to unsupported 10 bit format.

MAIN10? I was actually surprised, Venus driver supported them for the
Iris2 hardware. Is it somethething to be fixed in future?

>  - 4 testcase failed due to unsupported resolution

Can it be fixed?

>  - 2 testcase failed due to CRC mismatch

Which means an error in the testsuite or somewhere on our side?

>  - 2 test fails due to session error (under debug)
>    - PICSIZE_C_Bossen_1
>    - WPP_E_ericsson_MAIN_2
> 
> VP9:
> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>  GStreamer-VP9-V4L2-Gst1.0.
>  The failing test case:
>  - 64 testcases failed due to unsupported resolution

Can it be fixed?

>  - 2 testcases failed due to unsupported format

Hmm?

>  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)

Could you please raise an issue against fluster?

>  - 2 testcase failed due to unsupported resolution after sequence change

Can it be fixed?

>  - 1 testcase failed due to unsupported stream

?

> 
> > > gstreamer test:
> > > Decoders validated with below commands, codec specific:
> > > gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
> > > parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > 
> > Neither of these commands specify, what exactly was validated. They
> > specify that you've validated _some_ videos. It's impossible to even
> > reproduce your results, because you don't specify which files you've
> > used.
> > 
> 
> commands are shared indicating the pipeline used for validation for
> different codec plugins. These are some basic encode and decode commands,
> and shared for reference for anyone to pick input test files of their own.

Thanks, but it would also be helpful if you stated, which filesets were
used for validation. There are enough public filesets for testing video
decoders.

> 
> > > 
> > > gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> > > parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > 
> > > gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> > > parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > 
> > > Encoders validated with below commands:
> > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> > > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> > > capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> > > location=<output_file.h264>
> > 
> > At least these should use test sinks in order to be reproducible.
> 
> it is using filesink in the pipeline to generate the encoded bitstream

I should have been more explicit: test sinks to generate the image.

-- 
With best wishes
Dmitry

On 1/27/2026 5:22 PM, Dmitry Baryshkov wrote:
> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
>>
>> On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
>>>> Qualcomm kaanapali platform have a newer generation of video IP iris4.
>>>> The hardware have evolved mostly with respect to higher number of power
>>>> domains as well as multiple clock sources.
>>>>
>>>> The series extends support for multiple iommu-map entries for the same
>>>> input id. Considering iris as a client driver, it adds the handling for
>>>> multiple stream ids from VPU via iommu-map.
>>>>
>>>> This series is depend on the below series:
>>>> Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
>>>>
>>>> Following are the compliance and functional validation reports.
>>>
>>> Please validate with fluster too. Having a "knowingly good" command line
>>> is not a validation. It can't be reproduced by anybody else.
>>>
>>
>> Below is the fluster result on kaanapali (will add in cover letter in next
>> revision)
> 
> Nice, thanks!
> 
>>
>> H264:
>> 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
> 
> What about the extension testsuites? Even if they are not supported,
> they should not crash or cause the timeouts.
> 
>> - 52 test vectors failed due to interlaced clips - not supported
> 
> Yet or completely? Does "failed" mean "returned an error" or something
> else?

completely. Driver returns error on firmware detecting the content as 
interlace.

> 
>> - 3 test vectors failed due to unsupported bitstream.
>> - 2 test vectors failed because SP_SLICE type - not supported by the
>>    hardware.
>> - 1 test vector failed due to unsupported profile
>>
>> H265:
>>   129/147 testcases passed while testing JCT-VC-HEVC_V1 with
>>   GStreamer-H.265-V4L2-Gst1.0.
>>   The failing test case:
>>   - 10 testcases failed due to unsupported 10 bit format.
> 
> MAIN10? I was actually surprised, Venus driver supported them for the
> Iris2 hardware. Is it somethething to be fixed in future?

10bit would be added in iris. We are catching up with all the codecs, 
10bit should be next from decoder side.

> 
>>   - 4 testcase failed due to unsupported resolution
> 
> Can it be fixed?
> 
>>   - 2 testcase failed due to CRC mismatch
> 
> Which means an error in the testsuite or somewhere on our side?
> 
>>   - 2 test fails due to session error (under debug)
>>     - PICSIZE_C_Bossen_1
>>     - WPP_E_ericsson_MAIN_2
>>
>> VP9:
>> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>>   GStreamer-VP9-V4L2-Gst1.0.
>>   The failing test case:
>>   - 64 testcases failed due to unsupported resolution
> 
> Can it be fixed?
> 
>>   - 2 testcases failed due to unsupported format
> 
> Hmm?
> 
>>   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> 
> Could you please raise an issue against fluster?
> 
>>   - 2 testcase failed due to unsupported resolution after sequence change
> 
> Can it be fixed?
> 
>>   - 1 testcase failed due to unsupported stream
> 
> ?
> 
>>
>>>> gstreamer test:
>>>> Decoders validated with below commands, codec specific:
>>>> gst-launch-1.0 multifilesrc location=<input_file.h264> stop-index=0 !
>>>> parsebin ! v4l2h264dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>
>>> Neither of these commands specify, what exactly was validated. They
>>> specify that you've validated _some_ videos. It's impossible to even
>>> reproduce your results, because you don't specify which files you've
>>> used.
>>>
>>
>> commands are shared indicating the pipeline used for validation for
>> different codec plugins. These are some basic encode and decode commands,
>> and shared for reference for anyone to pick input test files of their own.
> 
> Thanks, but it would also be helpful if you stated, which filesets were
> used for validation. There are enough public filesets for testing video
> decoders.

Ack, will add that info in the cover letter in next revision.

>>
>>>>
>>>> gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
>>>> parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
>>>> parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
>>>> video/x-raw,format=I420 ! filesink location=<output_file.yuv>
>>>>
>>>> Encoders validated with below commands:
>>>> gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
>>>> format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
>>>> capture-io-mode=4 output-io-mode=4 ! filesink sync=true
>>>> location=<output_file.h264>
>>>
>>> At least these should use test sinks in order to be reproducible.
>>
>> it is using filesink in the pipeline to generate the encoded bitstream
> 
> I should have been more explicit: test sinks to generate the image.
> 

If you could suggest a gst pipeline for it, i can give it a try.

Regards,
Vikash

On Tue, Jan 27, 2026 at 09:41:01PM +0530, Vikash Garodia wrote:
> 
> On 1/27/2026 5:22 PM, Dmitry Baryshkov wrote:
> > On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> > > 
> > > On 1/26/2026 7:08 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 26, 2026 at 05:55:43PM +0530, Vikash Garodia wrote:
> > > > > Qualcomm kaanapali platform have a newer generation of video IP iris4.
> > > > > The hardware have evolved mostly with respect to higher number of power
> > > > > domains as well as multiple clock sources.
> > > > > 
> > > > > The series extends support for multiple iommu-map entries for the same
> > > > > input id. Considering iris as a client driver, it adds the handling for
> > > > > multiple stream ids from VPU via iommu-map.
> > > > > 
> > > > > This series is depend on the below series:
> > > > > Link: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
> > > > > 
> > > > > Following are the compliance and functional validation reports.
> > > > 
> > > > Please validate with fluster too. Having a "knowingly good" command line
> > > > is not a validation. It can't be reproduced by anybody else.
> > > > 
> > > 
> > > Below is the fluster result on kaanapali (will add in cover letter in next
> > > revision)
> > 
> > Nice, thanks!
> > 
> > > 
> > > H264:
> > > 77/135 while testing JVT-AVC_V1 with GStreamer-H.264-V4L2-Gst1.0.JVT-AVC_V1.
> > 
> > What about the extension testsuites? Even if they are not supported,
> > they should not crash or cause the timeouts.
> > 
> > > - 52 test vectors failed due to interlaced clips - not supported
> > 
> > Yet or completely? Does "failed" mean "returned an error" or something
> > else?
> 
> completely. Driver returns error on firmware detecting the content as
> interlace.

Ok. I was more worried about timeouts or other kinds of failures.

> 
> > 
> > > - 3 test vectors failed due to unsupported bitstream.
> > > - 2 test vectors failed because SP_SLICE type - not supported by the
> > >    hardware.
> > > - 1 test vector failed due to unsupported profile
> > > 
> > > H265:
> > >   129/147 testcases passed while testing JCT-VC-HEVC_V1 with
> > >   GStreamer-H.265-V4L2-Gst1.0.
> > >   The failing test case:
> > >   - 10 testcases failed due to unsupported 10 bit format.
> > 
> > MAIN10? I was actually surprised, Venus driver supported them for the
> > Iris2 hardware. Is it somethething to be fixed in future?
> 
> 10bit would be added in iris. We are catching up with all the codecs, 10bit
> should be next from decoder side.

Thanks!

> > > > > gst-launch-1.0 multifilesrc location=<input_file.hevc> stop-index=0 !
> > > > > parsebin ! v4l2h265dec ! video/x-raw ! videoconvert dither=none !
> > > > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > > > 
> > > > > gst-launch-1.0 filesrc location=<input_file.webm> stop-index=0 !
> > > > > parsebin ! vp9dec ! video/x-raw ! videoconvert dither=none !
> > > > > video/x-raw,format=I420 ! filesink location=<output_file.yuv>
> > > > > 
> > > > > Encoders validated with below commands:
> > > > > gst-launch-1.0 -v filesrc location=<input_file.yuv> ! rawvideoparse
> > > > > format=nv12 width=<width> height=<height> framerate=30/1 ! v4l2h264enc
> > > > > capture-io-mode=4 output-io-mode=4 ! filesink sync=true
> > > > > location=<output_file.h264>
> > > > 
> > > > At least these should use test sinks in order to be reproducible.
> > > 
> > > it is using filesink in the pipeline to generate the encoded bitstream
> > 
> > I should have been more explicit: test sinks to generate the image.
> > 
> 
> If you could suggest a gst pipeline for it, i can give it a try.

gst-launch-1.0 -v videotestsrc pattern=smpte '!' video/x-raw,width=1280,height=720 '!' xvimagesink

There are other patterns supported too:
https://gstreamer.freedesktop.org/documentation/videotestsrc/index.html?gi-language=c#GstVideoTestSrcMotionType

-- 
With best wishes
Dmitry

Hi,

Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> 

[..]

> 
> >  - 4 testcase failed due to unsupported resolution
> 
> Can it be fixed?

Its nicer if you name the failing tests vectors. I can guess this is
PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
level impose a limit on bandwidth, not on resolution. These files are either
very large and small height or the opposite. One of these is just 4K in portrait
mode (that is more concerning). Though, there is a V4L2 limitation for this
aspect, since we advertise the resolutions by range. Most hardware is designed
to support 4096x4096, in that casse that's what you should expose as limits.

Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
this case there is not much you can do, you have to find the right trade of. But
since you expose LEVELs, I think its fine to overshoot a little. Both
constraints should ensure it works with valid streams.

> 
> >  - 2 testcase failed due to CRC mismatch

These are clear example of "no one can guess".

> 
> Which means an error in the testsuite or somewhere on our side?

The testsuite fully pass if you run using Franhofer reference decoder. This is
logical since the MD5 has been generated with it.

> 
> >  - 2 test fails due to session error (under debug)
> >    - PICSIZE_C_Bossen_1

Hmm, see, I have no idea which fourth one could fail due to resolution, and that
forth one is likely a bug on your side.

> >    - WPP_E_ericsson_MAIN_2
> > 
> > VP9:
> > 235/305 testcases passed while testing VP9-TEST-VECTORS with
> >  GStreamer-VP9-V4L2-Gst1.0.
> >  The failing test case:
> >  - 64 testcases failed due to unsupported resolution
> 
> Can it be fixed?

Check if you aren't mixing up constraints between display, coded and allocated
resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
not care at all, or use it to allow optimistic pre-allocation. But check that
the low resolution constraints is not coming from the OUTPUT queue software.

VP9 coded resolution, it always at least 64x64.

> 
> >  - 2 testcases failed due to unsupported format
> 
> Hmm?

Clarify please, I suppose these are YUV444 (aka professional profiles).

> 
> >  - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> 
> Could you please raise an issue against fluster?

Check your setup, it fully pass with reference here. The MD5 has been generated
using the reference.

  ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS

It also fully pass with the GStreamer wrapper, though it had been fixed in
recent GStreamer versions (I'm testing with 1.26.10).

> 
> >  - 2 testcase failed due to unsupported resolution after sequence change
> 
> Can it be fixed?

This one can't be fixed without adding an extension to the V4L2 Stateful Decoder
spec, like we did for the stateless decoder spec. In order to handle inter-frame
resolution changes (a resolution change on a non-keyframe), you have to notify
userspace with the new resolution, give it a way to read back this solution,
have CREATE_BUFS() support to allow allocating for that new resolution without
going through streamoff (to avoid looking reference data), and finally, a way to
remove buffers that are now too small (or too big if userspace wants to reduce
the amount of RAM used) through the new DELETE_BUFS ioctl. You also have to
track in your driver the reference buffer resolution/stride.

This is non-trivial with the existing stateful state-machine. You have to make
sure userspace won't be confused between normal DRC and inter-frame DRC (dynamic
resolution changes).


[...]

regards,
Nicolas

On 1/27/2026 8:40 PM, Nicolas Dufresne wrote:
> Hi,
> 
> Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
>> On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
>>
> 
> [..]
> 
>>
>>>   - 4 testcase failed due to unsupported resolution
>>
>> Can it be fixed?
> 
> Its nicer if you name the failing tests vectors. I can guess this is
> PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
> level impose a limit on bandwidth, not on resolution. These files are either
> very large and small height or the opposite. One of these is just 4K in portrait
> mode (that is more concerning). Though, there is a V4L2 limitation for this
> aspect, since we advertise the resolutions by range. Most hardware is designed
> to support 4096x4096, in that casse that's what you should expose as limits.
> 
> Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
> this case there is not much you can do, you have to find the right trade of. But
> since you expose LEVELs, I think its fine to overshoot a little. Both
> constraints should ensure it works with valid streams.

I can list the failing test vectors for failing tests. In this case, its
PICSIZE_A_Bossen_1
PICSIZE_B_Bossen_1
WPP_D_ericsson_MAIN10_2
WPP_D_ericsson_MAIN_2

I have not explicitly gone through individual failures this time on 
kaanapali, as last time when these were analyzed for earlier platform 
(SM8550), the failed due to resolution lower than 96x96, which VPU does 
not support for kaanapali as well.

Do you think if fluster can query the supported frame sizes and 
accordingly, mark the ones testing outside that range as pass, if 
graceful error ?

>>
>>>   - 2 testcase failed due to CRC mismatch
> 
> These are clear example of "no one can guess".
> 

RAP_A_docomo_6
VPSSPSPPS_A_MainConcept_1

For "RAP.." test vector, it was discussed earlier [1] and the frames 
marked as VB2_BUF_STATE_ERROR should be dropped. GST is currently 
displaying the NULL content leading to CRC mismatch. Let me know if this 
can be taken up as a GST bug.

[1] 
https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/

>>
>> Which means an error in the testsuite or somewhere on our side?
> 
> The testsuite fully pass if you run using Franhofer reference decoder. This is
> logical since the MD5 has been generated with it.

Since the reference decoder in this is not generating buffers with zero 
filled data, its not complaining. In VPU case, even though buffers are 
of zero filled data, marking them as error, should get dropped, instead 
of considering it as a valid frame.

> 
>>
>>>   - 2 test fails due to session error (under debug)
>>>     - PICSIZE_C_Bossen_1
> 
> Hmm, see, I have no idea which fourth one could fail due to resolution, and that
> forth one is likely a bug on your side.
> 

This could pass on sm8550 and fails on kaanapali. This should be 
debugged from driver side.

>>>     - WPP_E_ericsson_MAIN_2
>>>
>>> VP9:
>>> 235/305 testcases passed while testing VP9-TEST-VECTORS with
>>>   GStreamer-VP9-V4L2-Gst1.0.
>>>   The failing test case:
>>>   - 64 testcases failed due to unsupported resolution
>>
>> Can it be fixed?
> 
> Check if you aren't mixing up constraints between display, coded and allocated
> resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
> not care at all, or use it to allow optimistic pre-allocation. But check that
> the low resolution constraints is not coming from the OUTPUT queue software.
> 
> VP9 coded resolution, it always at least 64x64.
> 
The failed list is same as the one published during sm8550 [1]. I see 
most of the test vectors are <= 64x64 and going as low as 08x08. Here as 
well if we can have a query for supported frame size, it should handle 
these cases.

[1] 
https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
>>
>>>   - 2 testcases failed due to unsupported format
>>
>> Hmm?
> 
> Clarify please, I suppose these are YUV444 (aka professional profiles).

vp91-2-04-yuv422.webm
vp91-2-04-yuv444.webm

> 
>>
>>>   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
>>
>> Could you please raise an issue against fluster?
> 
> Check your setup, it fully pass with reference here. The MD5 has been generated
> using the reference.
> 
>    ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS
> 
> It also fully pass with the GStreamer wrapper, though it had been fixed in
> recent GStreamer versions (I'm testing with 1.26.10).
> 

I would let Dikshita comment on this. I am unable to find that 
discussion where it was failing in her setup with reference decoder as well.

>>
>>>   - 2 testcase failed due to unsupported resolution after sequence change
>>
>> Can it be fixed?
> 
> This one can't be fixed without adding an extension to the V4L2 Stateful Decoder
> spec, like we did for the stateless decoder spec. In order to handle inter-frame
> resolution changes (a resolution change on a non-keyframe), you have to notify
> userspace with the new resolution, give it a way to read back this solution,
> have CREATE_BUFS() support to allow allocating for that new resolution without
> going through streamoff (to avoid looking reference data), and finally, a way to
> remove buffers that are now too small (or too big if userspace wants to reduce
> the amount of RAM used) through the new DELETE_BUFS ioctl. You also have to
> track in your driver the reference buffer resolution/stride.
> 
> This is non-trivial with the existing stateful state-machine. You have to make
> sure userspace won't be confused between normal DRC and inter-frame DRC (dynamic
> resolution changes).
> 
> 
> [...]
> 
> regards,
> Nicolas

Regards,
Vikash

Hi,

Le mardi 27 janvier 2026 à 21:29 +0530, Vikash Garodia a écrit :
> 
> On 1/27/2026 8:40 PM, Nicolas Dufresne wrote:
> > Hi,
> > 
> > Le mardi 27 janvier 2026 à 13:52 +0200, Dmitry Baryshkov a écrit :
> > > On Tue, Jan 27, 2026 at 04:56:34PM +0530, Vikash Garodia wrote:
> > > 
> > 
> > [..]
> > 
> > > 
> > > >   - 4 testcase failed due to unsupported resolution
> > > 
> > > Can it be fixed?
> > 
> > Its nicer if you name the failing tests vectors. I can guess this is
> > PICSIZE_{A,B,C,D}_Bossen_1 by experience, but not everyone will guess. HEVC
> > level impose a limit on bandwidth, not on resolution. These files are either
> > very large and small height or the opposite. One of these is just 4K in portrait
> > mode (that is more concerning). Though, there is a V4L2 limitation for this
> > aspect, since we advertise the resolutions by range. Most hardware is designed
> > to support 4096x4096, in that casse that's what you should expose as limits.
> > 
> > Though, some hardware do have dynamic sizing capabilities (like RKVDEC HEVC), in
> > this case there is not much you can do, you have to find the right trade of. But
> > since you expose LEVELs, I think its fine to overshoot a little. Both
> > constraints should ensure it works with valid streams.
> 
> I can list the failing test vectors for failing tests. In this case, its
> PICSIZE_A_Bossen_1
> PICSIZE_B_Bossen_1
> WPP_D_ericsson_MAIN10_2
> WPP_D_ericsson_MAIN_2
> 
> I have not explicitly gone through individual failures this time on 
> kaanapali, as last time when these were analyzed for earlier platform 
> (SM8550), the failed due to resolution lower than 96x96, which VPU does 
> not support for kaanapali as well.
> 
> Do you think if fluster can query the supported frame sizes and 
> accordingly, mark the ones testing outside that range as pass, if 
> graceful error ?

No, the conformance streams are the same for all decoder regardless of the
subset of the spec the hardware designers decided have implemented. The error
type could possibly be enhanced, but at the moment we have:

- Success: MD5 matches
- Fail: MD5 does not match (corrupted/truncated outcome)
- Error: When the operation did not complete.

Once you have manually investigated all the case, and you want to setup your CI
(which I strongly recommend you to do). You can pass -sv / --skipvectors
parameter to `run` command to remove the expected fail from your run.

Another thing we get to notice, is that integrator very commonly assume that a
96x96 limits imply that all the resolution, display, coded and allocated must be
at least that big. Which most of the time is not what the HW designers intended.

> 
> > > 
> > > >   - 2 testcase failed due to CRC mismatch
> > 
> > These are clear example of "no one can guess".
> > 
> 
> RAP_A_docomo_6

When I read the description for this one it looks like something normally handle
in the control software (which is in your firmware for this type of hardware).
You should report to your firmware team. When a GOP starts on a CRA followed by
RASL, the control software need to skip over the RASL. This can either be done
by skipping over the decoding, or letting the decoder run but marking as non-
output. The second is what the GStreamer stateless decoders implementation do,
but we notice that on older driver, it may cause errors or hangs, so we will
stop doing that in the future. For reference, you can download the zip (link in
fluster/test_suites/h.265/JCT-VC-HEVC_V1.json), ITU conformances usually come
with a description.

https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/HEVC_v1/RAP_A_docomo_6.zip
RAP_A_docomo_6: (RAP_A_docomo_6.bit)
Frame rate: 30 fps
Picture size: 832x480 
Spec version: HM10.1

(Category: RAP; Sub-category: Bitstream starting with a CRA picture followed by
RASL pictures that cannot be decoded)

The purpose of the stream is to exercise the decoding of a conforming bitstream
where the CRA is the first picture in the bitstream and is followed by 7 RASL
pictures that are not decodable. There are two subsequent CRA pictures with RASL
pictures, following the first CRA picture in this bitstream. These subsequent
RASL pictures should be decodable since the associated CRA is not the first CRA
picture in the bitstream.

Note: In actual decoders, any RASL pictures associated with a CRA picture at the
beginning of the bitstream or any RASL pictures associated with a BLA picture
may be ignored (removed from the bitstream and discarded), as they are not
specified for output and have no effect on the decoding process of any other
pictures that are specified for output.

The MD5 of the yuv file in output order decoded using the HM10.1-dev-3420 is
included in RAP_A_docomo_6.md5.


> VPSSPSPPS_A_MainConcept_1

This one depends on software cropping happening after the decoder. This is not
implemented in v4l2 stateful decoder, so a GStreamer bug. Unaligned crop regions
that cannot be cropped by offset and stride stricks are generally not supported,
but we opted for a proper cropper in the stateless plugin in order to support
conformance testing. Patched welcome, but not an issue with this driver.

> 
> For "RAP.." test vector, it was discussed earlier [1] and the frames 
> marked as VB2_BUF_STATE_ERROR should be dropped. GST is currently 
> displaying the NULL content leading to CRC mismatch. Let me know if this 
> can be taken up as a GST bug.

Well, as discussed earlier, GStreamer drops the ERROR frame if their payload
size it reset to 0. Otherwise its treated as partially corrupted frame, and
pushed. This aligns with how the v4l2 buffer error state is documented.

> 
> [1] 
> https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
> 
> > > 
> > > Which means an error in the testsuite or somewhere on our side?
> > 
> > The testsuite fully pass if you run using Franhofer reference decoder. This is
> > logical since the MD5 has been generated with it.
> 
> Since the reference decoder in this is not generating buffers with zero 
> filled data, its not complaining. In VPU case, even though buffers are 
> of zero filled data, marking them as error, should get dropped, instead 
> of considering it as a valid frame.

See comment below, you have some debugging to do here. I think other dev in your
group have kept ignoring the problem.

> 
> > 
> > > 
> > > >   - 2 test fails due to session error (under debug)
> > > >     - PICSIZE_C_Bossen_1
> > 
> > Hmm, see, I have no idea which fourth one could fail due to resolution, and that
> > forth one is likely a bug on your side.
> > 
> 
> This could pass on sm8550 and fails on kaanapali. This should be 
> debugged from driver side.
> 
> > > >     - WPP_E_ericsson_MAIN_2
> > > > 
> > > > VP9:
> > > > 235/305 testcases passed while testing VP9-TEST-VECTORS with
> > > >   GStreamer-VP9-V4L2-Gst1.0.
> > > >   The failing test case:
> > > >   - 64 testcases failed due to unsupported resolution
> > > 
> > > Can it be fixed?
> > 
> > Check if you aren't mixing up constraints between display, coded and allocated
> > resolutions. On most hardware, all 3 can differ. The OUTPUT queue should either
> > not care at all, or use it to allow optimistic pre-allocation. But check that
> > the low resolution constraints is not coming from the OUTPUT queue software.
> > 
> > VP9 coded resolution, it always at least 64x64.
> > 
> The failed list is same as the one published during sm8550 [1]. I see 
> most of the test vectors are <= 64x64 and going as low as 08x08. Here as 
> well if we can have a query for supported frame size, it should handle 
> these cases.
> 
> [1] 
> https://lore.kernel.org/linux-media/20250408-iris-dec-hevc-vp9-v1-0-acd258778bd6@quicinc.com/
> > > 
> > > >   - 2 testcases failed due to unsupported format
> > > 
> > > Hmm?
> > 
> > Clarify please, I suppose these are YUV444 (aka professional profiles).
> 
> vp91-2-04-yuv422.webm
> vp91-2-04-yuv444.webm
> 
> > 
> > > 
> > > >   - 1 testcase failed with CRC mismatch (fails with ref decoder as well)
> > > 
> > > Could you please raise an issue against fluster?
> > 
> > Check your setup, it fully pass with reference here. The MD5 has been generated
> > using the reference.
> > 
> >    ./fluster.py run -d libvpx-VP9 -ts  VP9-TEST-VECTORS
> > 
> > It also fully pass with the GStreamer wrapper, though it had been fixed in
> > recent GStreamer versions (I'm testing with 1.26.10).
> > 
> 
> I would let Dikshita comment on this. I am unable to find that 
> discussion where it was failing in her setup with reference decoder as well.

Looking forward some improvement over generation of hardware, not regression.

regards,
Nicolas