lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d4632b2-916a-4eda-ad08-44af68461dc8@oss.qualcomm.com>
Date: Tue, 27 Jan 2026 16:56:34 +0530
From: Vikash Garodia <vikash.garodia@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
        Abhinav Kumar <abhinav.kumar@...ux.dev>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Saravana Kannan <saravanak@...nel.org>, Joerg Roedel <joro@...tes.org>,
        Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
        Stefan Schmidt <stefan.schmidt@...aro.org>,
        Hans Verkuil <hverkuil@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Vishnu Reddy <busanna.reddy@....qualcomm.com>,
        Hans Verkuil <hverkuil+cisco@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux.dev, Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Charan Teja Kalla <charan.kalla@....qualcomm.com>,
        Vijayanand Jitta <vijayanand.jitta@....qualcomm.com>
Subject: Re: [PATCH 0/7] media: iris: add support for kaanapali platform


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ