Message-ID: <63ca375440c4ff2f55ea0aa4e19458f775552d88.camel@ndufresne.ca>
Date: Tue, 27 Jan 2026 11:58:49 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Vikash Garodia <vikash.garodia@....qualcomm.com>, 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

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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists