Re: [PATCH v3 0/6] media: qcom: iris: add support for decoding 10bit formats

[Vikash Garodia]

On 5/21/2026 12:54 PM, Neil Armstrong wrote:
> On 5/20/26 17:44, Vikash Garodia wrote:
> > On 5/18/2026 1:12 PM, Neil Armstrong wrote:
> > > On 5/13/26 19:33, Vikash Garodia wrote:
> > > > On 5/11/2026 2:50 PM, Neil Armstrong wrote:
> > > > > This adds the plumbing to support decoding HEVC, VP9 and AV1
> > > > > streams into 10bit pixel formats, linear and compressed.
> > > > >
> > > > > This has only been tested on SM8550 & SM8650 with HEVC, and was
> > > > > inspired by Venus, DRM MSM and the downstream vidc driver for the
> > > > > buffer calculations and HFI messages.
> > > > >
> > > > > I was unable to get 10bit decoding working with ffmpeg since P010
> > > > > support for v4l2 decoding is missing, but v4l2-ctl works with:
> > > > > v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC --set-fmt- 
> > > > > video=pixelformat=P010 --stream-mmap --stream-out-mmap --stream- 
> > > > > from- hdr Big_Buck_Bunny_1080_10s_30MB_main10.h265.hdr --stream-to 
> > > > > out.P010
> > > > > v4l2-ctl --verbose --set-fmt-video-out=pixelformat=HEVC --set-fmt- 
> > > > > video=pixelformat=Q10C --stream-mmap --stream-out-mmap --stream- 
> > > > > from- hdr Big_Buck_Bunny_1080_10s_30MB_main10.h265.hdr --stream-to 
> > > > > out.QC10
> > > > >
> > > > > The non-10bit decoding still works as before.
> > > > >
> > > > > With Big_Buck_Bunny_1080_10s_30MB reencoded in 10-bit profile
> > > > > and tranformed in v4l2 header format with [1]:
> > > > > ffmpeg -i Big_Buck_Bunny_1080_10s_30MB.h264 -pix_fmt yuv420p10le - 
> > > > > c:v libx265 -crf 28 -x265-params profile=main10 
> > > > > Big_Buck_Bunny_1080_10s_30MB_main10.h265
> > > > > /path/to/mkhdr.sh Big_Buck_Bunny_1080_10s_30MB_main10.h265 raw 
> > > > > Big_Buck_Bunny_1080_10s_30MB_main10.h265.hdr
> > > > >
> > > > > Fluster HEVC results on SM8650:
> > > > >
> > > > > ./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2-Gst1.0 
> > > > > - 131/147
> > > > > The failing test case:
> > > > > - Pixel Format mismatch
> > > > >   - TSUNEQBD_A_MAIN10_Technicolor_2 - Gstreamer waits NV12 but 
> > > > > decoder returns P010
> > > > > - Unsupported resolution
> > > > >   - PICSIZE_A_Bossen_1 - resolution is higher than max supported
> > > > >   - PICSIZE_B_Bossen_1 - resolution is higher than max supported
> > > > >   - WPP_D_ericsson_MAIN_2 - resolution is lower than min supported
> > > > >   - WPP_D_ericsson_MAIN10_2 - resolution is lower than min supported
> > > > > - CRC mismatch
> > > > >   - RAP_A_docomo_6
> > > > > - CRC mismatch - bitstream issue - fails with ffmpeg sw decoder as 
> > > > > well
> > > > >   - VPSSPSPPS_A_MainConcept_1
> > > >
> > > >  From earlier SOC reports, 10bit tests which were failing were
> > > > - DBLK_A_MAIN10_VIXS_4
> > > > - INITQP_B_Main10_Sony_1
> > > > - TSUNEQBD_A_MAIN10_Technicolor_2
> > > > - WP_A_MAIN10_Toshiba_3
> > > > - WP_MAIN10_B_Toshiba_3
> > > > - WPP_A_ericsson_MAIN10_2
> > > > - WPP_B_ericsson_MAIN10_2
> > > > - WPP_C_ericsson_MAIN10_2
> > > > - WPP_E_ericsson_MAIN10_2
> > > > - WPP_F_ericsson_MAIN10_2
> > > >
> > > > I was in the opinion that once we enable 10bit, these tests would 
> > > > pass. Though i do not see these in your failing tests, but the count 
> > > > of 131/147 have not improved. Could you check if these tests are 
> > > > passing and count is better than 131 pass ?
> > >
> > > Sorry there's a copy paste error I'll fix on v4, here's the fluster log:
> > >
> > >
> > > |Test|GStreamer-H.265-V4L2|
> > > |-|-|
> > > |TOTAL|141/147|
> > > |TOTAL TIME|8.600s|
> > > |-|-|
> > > ...
> > > |PICSIZE_A_Bossen_1|☠|
> > > |PICSIZE_B_Bossen_1|☠|
> > > ...
> > > |RAP_A_docomo_6|❌|
> > > ...
> > > |TSUNEQBD_A_MAIN10_Technicolor_2|☠|
> > > ...
> > > |WPP_D_ericsson_MAIN10_2|☠|
> > > |WPP_D_ericsson_MAIN_2|☠|
> > > ...
> > > |-|-|
> > > |Test|GStreamer-H.265-V4L2|
> > > |TOTAL|140/147|
> > > |TOTAL TIME|8.600s|
> > >
> > > |-|-|
> > > |Profile|GStreamer-H.265-V4L2|
> > > |MAIN|131/135|
> > > |MAIN_10|9/11|
> > > |MAIN_STILL_PICTURE|1/1|
> > >
> > > So the failing cases:
> > > - Pixel Format mismatch
> > >   - TSUNEQBD_A_MAIN10_Technicolor_2 - Gstreamer waits NV12 but 
> > > decoder returns P010
> >
> > Why would gstreamer expect NV12 for MAIN10 usecase ? Is this something 
> > to do with format negotiation ?
>
>                          # Feature: Test unequal luma and chroma bitdepth
>                          # setting. The luma bitdepth is higher than the 
> chroma
>                          # bitdepth.
>                          # Luma is 10 bit, chroma is 9 bit
>
> This particular test uses different bit depth for luma and chroma, and 
> the fw upscales all to 10bit
> while the sw decoder seems to downscale to 8bit. And it seems other HW 
> decoder does the same as iris.
>
> I think the HW decoder is right here, but this use case will probably 
> never occur in real life.

Have not seen such case either, where luma and chrome have different 
bitdepth. We can mark them as not supported by VPU

+ing Nico if he has any comments on this test.

Regards,
Vikash