On Tue Aug 12, 2025 at 3:27 PM CEST, Nicolas Dufresne wrote:
> Le mardi 12 août 2025 à 14:55 +0200, Diederik de Haas a écrit :
>> On Tue Aug 12, 2025 at 2:11 PM CEST, Diederik de Haas wrote:
>> > On Sun Aug 10, 2025 at 11:24 PM CEST, Jonas Karlman wrote:
>> > > 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;
> 	}

That's indeed the code for H.264.

> 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.

It's based on the 6.16 mainline kernel, but that patch is a 'fix' on a
not (yet) accepted patch he added on top of that for HEVC. So it not
working for me on H.264 must be from somewhere else in the/my stack.

Sorry for the noise.