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

[Wangao Wang <wangao.wang@oss.qualcomm.com>]

On 2026/5/29 21:25, Neil Armstrong wrote:
> On 5/29/26 12:33, Wangao Wang wrote:
>>
>>
>> On 2026/5/29 17:55, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 5/29/26 10:21, Wangao Wang wrote:
>>>>
>>>>
>>>> On 2026/5/28 21:26, Neil Armstrong wrote:
>>>>> Hi Wangao,
>>>>>
>>>>> On 5/27/26 06:15, Wangao Wang wrote:
>>>>>> I tested the v4 patch using the gst command you provided earlier. 
>>>>>> The decoded output still has the previous plane misalignment 
>>>>>> issue, but all frames are decoded successfully. When viewing the 
>>>>>> raw data with an image player at 1920x1080 resolution, the first 
>>>>>> frame looks correct but subsequent frames appear shifted. If 
>>>>>> viewed at 1920x1088 resolution, there are artifacts at the bottom 
>>>>>> of each frame. I've attached the images.
>>>>>>
>>>>>> Also, have you tested the 720p case? I can't get it to run on my end.
>>>>>
>>>>> Thanks for the report but I don't have access to the Purwa platform 
>>>>> you use,
>>>>> I've run test with multiple resolutions with display using P010
>>>>> and QC10, and ran fluster aswell and all passed on SM8550 and SM8650.
>>>>>
>>>>> I'll test it on the Hamoa T14S I have which should be the closest 
>>>>> to purwa,
>>>>> but it uses the same driver setup as SM8550 so I expected it to 
>>>>> work the same.
>>>>>
>>>>> Could you indicate which iris firmware you're using ?
>>>>>
>>>>> Could you try passing the fluster h265 main10 test suite with 
>>>>> gstreamer ?
>>>>>
>>>>> fluster download -c h.265
>>>>> fluster run -d GStreamer-H.265-V4L2 -ts JCT-VC-HEVC_V1 -q -s -j1
>>>>>
>>>>> The picture you send looks like there's a mismatch with the kernel
>>>>> and firmware setup of planes offsets.
>>>>> Could you check if there's a Purwa specific firmware property
>>>>> to set for 10bit decoding ?
>>>>>
>>>>> Neil
>>>>>
>>>>>>
>>>>
>>>> Hi Neil,
>>>>
>>>> I also tested on hamoa, and it has the same issue as purwa. The 
>>>> firmware used on purwa is vpu30_p1_s7.mbn.
>>>>
>>>> This is the result of fluster:
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WP_MAIN10_B_Toshiba_3 
>>>>       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_A_ericsson_MAIN10_2       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_A_ericsson_MAIN_2 
>>>>       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_B_ericsson_MAIN10_2       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_B_ericsson_MAIN_2 
>>>>       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_C_ericsson_MAIN10_2       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_C_ericsson_MAIN_2 
>>>>       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_D_ericsson_MAIN10_2       ... Error
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_D_ericsson_MAIN_2 
>>>>       ... Error
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_E_ericsson_MAIN10_2       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_E_ericsson_MAIN_2 
>>>>       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) 
>>>> WPP_F_ericsson_MAIN10_2       ... Success
>>>> [JCT-VC-HEVC_V1] (GStreamer-H.265-V4L2-Gst1.0) WPP_F_ericsson_MAIN_2 
>>>>       ... Success
>>>>
>>>
>>> Ok so this works fine, so I'm really wondering if your main10 HEVC is 
>>> not properly encoded.
>>>
>>> Could you try playing a well know HEVC main10 files ?
>>>
>>> For example I just tried the 1080p and 4k 10bit files on Hamoa + 
>>> fluster and it just worked as expected:
>>> https://larmoire.org/jellyfish/
>>> https://larmoire.org/jellyfish/media/jellyfish-10-mbps-hd-hevc-10bit.mkv
>>> https://larmoire.org/jellyfish/media/jellyfish-120-mbps-4k-uhd- 
>>> hevc-10bit.mkv
>>>
>>> Neil
>>
>> Could you provide the test commands? I tried both files and the 
>> results from gst still show anomalies, but the results from 
>> iris_test_app are normal. I'm wondering if there are any additional 
>> settings needed on the client side.
>>
>> Here are my test commands:
>> gst-launch-1.0 -v -m filesrc location=jellyfish-10-mbps-hd- 
>> hevc-10bit.mkv ! matroskademux ! h265parse ! v4l2h265dec ! filesink 
>> location=1080P_out.yuv
>> gst-launch-1.0 -v -m filesrc location=jellyfish-120-mbps-4k-uhd- 
>> hevc-10bit.mkv ! matroskademux ! h265parse ! v4l2h265dec ! filesink 
>> location=4K_out.yuv
>>
> 
> If I run those exact commands, I can correctly visualize the files with:
> gst-launch-1.0 -v -m filesrc location=1080P_out.yuv ! rawvideoparse 
> format=p010-10le width=1920 height=1080 frame-size=6266880 ! waylandsink
> gst-launch-1.0 -v -m filesrc location=4K_out.yuv ! rawvideoparse 
> format=p010-10le width=3840 height=2160 frame-size=25067520 ! waylandsink
> 
> I have to use the decoder full aligned buffer size because gst just 
> dumps the whole v4l2 buffer into filesink and frames are not tighly 
> packed together.
> 
> If you want to output tighly packed frames, this worked for me:
> gst-launch-1.0 -v -m filesrc location=jellyfish-10-mbps-hd- 
> hevc-10bit.mkv ! matroskademux ! h265parse ! v4l2h265dec ! rawvideoparse 
> format=p010-10le width=1920 height=1080 frame-size=6266880 ! filesink 
> location=1080P_out.yuv
> gst-launch-1.0 -v -m filesrc location=jellyfish-120-mbps-4k-uhd- 
> hevc-10bit.mkv.1 ! matroskademux ! h265parse ! v4l2h265dec ! 
> rawvideoparse format=p010-10le width=3840 height=2160 frame- 
> size=25067520 ! filesink location=4K_out.yuv
> 
> There's probably a better way I don't know, but in any case gstreamer 
> will only use the "frame-size" portion of each frame and process it.
> 
> For example, you can convert it nv12 and dump to file, it will then dump 
> only the nv12 data:
> gst-launch-1.0 -v -m filesrc location=jellyfish-10-mbps-hd- 
> hevc-10bit.mkv ! matroskademux ! h265parse ! v4l2h265dec ! 
> videoconvert ! video/x-raw, format=NV12 ! filesink location=1080P_out.yuv
> gst-launch-1.0 -v -m filesrc location=1080P_out.yuv ! rawvideoparse 
> format=nv12 width=1920 height=1080 ! waylandsink
> 
> If the plane offset/alignment was wrong, the convert frames would be 
> wrong and playback would also be wrong.
> 
> Neil

Thanks. Using the commands you provided, the output file no longer has 
the previous issues.

-- 
Best Regards,
Wangao