[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <472aac3c-9d3e-4892-8d6c-665fa6793464@mailbox.org>
Date: Thu, 4 Sep 2025 17:32:43 +0200
From: Marek Vasut <marek.vasut@...lbox.org>
To: Nicolas Dufresne <nicolas@...fresne.ca>,
Nas Chung <nas.chung@...psnmedia.com>, mchehab@...nel.org,
hverkuil@...all.nl, sebastian.fricke@...labora.com, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org
Cc: linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-imx@....com,
jackson.lee@...psnmedia.com, lafley.kim@...psnmedia.com
Subject: Re: [PATCH v2 0/8] Add support for Wave6 video codec driver
On 9/4/25 3:25 PM, Nicolas Dufresne wrote:
> Hi,
>
> Le mercredi 03 septembre 2025 à 23:47 +0200, Marek Vasut a écrit :
>> On 4/22/25 11:31 AM, Nas Chung wrote:
>>> This patch series introduces support for the Chips&Media Wave6 video
>>> codec IP, a completely different hardware architecture compared to Wave5.
>>>
>>> The wave6 driver is a M2M stateful encoder/decoder driver.
>>> It supports various video formats, including H.264 and H.265,
>>> for both encoding and decoding.
>>> While other versions of the Wave6 IP may support VP9 decoding and
>>> AV1 decoding and encoding those formats are not implemented or validated
>>> in this driver at this time.
>>>
>>> On NXP i.MX SoCs, the Wave6 IP functionality is split between two regions:
>>> VPU Control region, Manages shared resources such as firmware memory.
>>> VPU Core region, Provides encoding and decoding capabilities.
>>> The VPU core cannot operate independently without the VPU control region.
>>>
>>> This driver has been tested with GStreamer on:
>>> - NXP i.MX95 board
>>> - pre-silicon FPGA environment
>>>
>>> Test results for decoder fluster:
>>> - JVT-AVC_V1, Ran 77/135 tests successfully in 35.519 secs
>>> - JVT-FR-EXT, Ran 25/69 tests successfully in 17.725 secs
>>> - JCT-VC-HEVC_V1, Ran 132/147 tests successfully in 81.549 secs
>>> - All failures are due to unsupported hardware features:
>>> -- 10bit, Resolutions higher than 4K, FMO, MBAFF
>>> -- Extended profile, Field encoding and High422 sreams.
>>>
>>> Test results for v4l2-compliance:
>>> v4l2-compliance 1.29.0-5359, 64 bits, 64-bit time_t
>>> v4l2-compliance SHA: 2a91a869eb8a 2025-04-12 11:35:53
>>>
>>> Compliance test for wave6-dec device /dev/video0:
>>> fail: ../utils/v4l2-compliance/v4l2-test-controls.cpp(1180): !have_source_change || !have_eos
>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>>> Total for wave6-dec device /dev/video0: 48, Succeeded: 47, Failed: 1, Warnings: 0
>>>
>>> Compliance test for wave6-enc device /dev/video1:
>>> fail: ../utils/v4l2-compliance/v4l2-test-controls.cpp(1169): node->codec_mask & STATEFUL_ENCODER
>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>>> Total for wave6-enc device /dev/video1: 48, Succeeded: 47, Failed: 1, Warnings: 0
>>>
>>> Note: the failures are all related with the eos event.
>>
>> For what its worth, the whole series:
>>
>> Tested-by: Marek Vasut <marek.vasut@...lbox.org> # NXP i.MX95 rev. A0
>
> Do you mind sharing what tests you have done ? Are you confirming the same
> fluster and compliance results, have you done more ? Since this is largely
> inspired on Wave5, I'd like to see people testing real-world playback, with
> seeks, dynamic resolution changes, data lost. On Wave5, latest performance
> patches leads to crash or hangs.
I did not use fluster this time, I used h264 decode of 1920x1080 60 FPS
stream. The pipeline was very basic, something along the lines of:
gst-launch-1.0 -v filesrc location=/test.mp4 ! qtdemux ! h264parse !
v4l2h264dec ! fpsdisplaysink text-overlay=false video-sink=waylandsink
Powered by blists - more mailing lists