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

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

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