Le mardi 12 août 2025 à 14:55 +0200, Diederik de Haas a écrit :

Hi again,

On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:

quoted

On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:

quoted

This series add a HEVC backend to the Rockchip Video Decoder driver.

Patch 1 add the new HEVC backend.
Patch 2-3 add variants support to the driver.
Patch 4 add support for a rk3288 variant.
Patch 5 add a rk3328 variant to work around hw quirks.
Patch 6-7 add device tree node for rk3288.

It looks like I had a previous version of linuxtv-rkvdec-hevc-v2 branch
locally and that also had this commit:
- media: rkvdec: Keep decoder clocks gated

Is that one no longer needed/useful/etc ?

And 'chewitt' also had a commit to fix 8/10-bit selection:
https://github.com/chewitt/linux/commit/4b93b05d2ca608bc23f1d52bcc32df926d435c7c
"WIP: media: rkvdec: fix 8-bit/10-bit format selection"

I haven't tried that one (yet), but did  try an other variant with
changing the ordering in rkvdec_hevc_decoded_fmts but that didn't work
in my tests. (Can ofc be PEBKAC)

Would that be useful? I do/did have consistent problems with playing
10-bit encoded video files.

nvm about the 10-bit problem. It exists, but it's not restricted to HEVC
as it also exists with with H.264 files.

The referred patch is against some out-dated kernel. In mainline linux with
have:

	if (sps->bit_depth_luma_minus8 == 0) {
		if (sps->chroma_format_idc == 2)
			return RKVDEC_IMG_FMT_422_8BIT;
		else
			return RKVDEC_IMG_FMT_420_8BIT;
	} else if (sps->bit_depth_luma_minus8 == 2) {
		if (sps->chroma_format_idc == 2)
			return RKVDEC_IMG_FMT_422_10BIT;
		else
			return RKVDEC_IMG_FMT_420_10BIT;
	}

Which covers all cases supporte by the hardware. Chewitt seem to add a
previously missing 10bit case, and forcing downconversion from 422 to 420. A
downconversion is something to be chosen and applied by userspace, the kernel
should pick a non-destructive format by default.

Nicolas

Cheers,
  Diederik