linux-kernel - Re: [PATCH v2 1/4] media: uapi: hevc: Add scaling matrix control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Jan 2020 15:43:36 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Jernej Skrabec <jernej.skrabec@...l.net>, mripard@...nel.org,
        hverkuil@...all.nl, gregkh@...uxfoundation.org, wens@...e.org,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        devel@...verdev.osuosl.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/4] media: uapi: hevc: Add scaling matrix control

Hi Mauro,

On Wed 08 Jan 20, 15:11, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Dec 2019 17:04:25 +0100
> Jernej Skrabec <jernej.skrabec@...l.net> escreveu:
> 
> > HEVC has a scaling matrix concept. Add support for it.
> 
> > +struct v4l2_ctrl_hevc_scaling_matrix {
> > +	__u8	scaling_list_4x4[6][16];
> > +	__u8	scaling_list_8x8[6][64];
> > +	__u8	scaling_list_16x16[6][64];
> > +	__u8	scaling_list_32x32[2][64];
> > +	__u8	scaling_list_dc_coef_16x16[6];
> > +	__u8	scaling_list_dc_coef_32x32[2];
> > +};
> 
> I never looked at HEVC spec, but the above seems really weird.
> 
> Please correct me if I am wrong, but each of the above matrixes
> is independent, and the driver will use just one of the above on
> any specific time (for a given video output node), right?

I am not too sure about what the specification really entails, but it is my
understanding that HEVC allows simultaneous block sizes between 4x4 and 32x32
to exist within the same coding tree and slice. That suggests that it makes
sense to have specific coefficients for each case.

Note that the hardware also has distinct registers for each scaling list.

Cheers,

Paul

> If so, why would userspace be forced to update lots of matrixes, if would
> likely use just one at a given time?
> 
> IMO, the proper way would be, instead, to use an uAPI like:
> 
> /*
>  * Actually, as this is uAPI, we will use a fixed size integer type, like
>  *  unsigned int
>  */
> enum hevc_scaling_matrix_type {
> 	HEVC_SCALING_MATRIX_4x4,
> 	HEVC_SCALING_MATRIX_8x8,
> ...
> 	HEVC_SCALING_MATRIX_DC_COEF_32x32,
> };
> 
> struct v4l2_ctrl_hevc_scaling_matrix {
> 	__u32	scaling_type 		/* as defined by enum hevc_scaling_matrix_type */
> 
> 	union {
> 		__u8	scaling_list_4x4[6][16];
> 		__u8	scaling_list_8x8[6][64];
> 		__u8	scaling_list_16x16[6][64];
> 		__u8	scaling_list_32x32[2][64];
> 		__u8	scaling_list_dc_coef_16x16[6];
> 		__u8	scaling_list_dc_coef_32x32[2];
> 	};
> };
> 
> And let the core use a default for each scaling matrix, if userspace doesn't
> set it.
> 
> 
> 
> Cheers,
> Mauro

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)