From: Hans Verkuil <hverkuil@xs4all.nl>
To: "Jernej Škrabec" <jernej.skrabec@siol.net>,
"Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>
Cc: mripard@kernel.org, gregkh@linuxfoundation.org, wens@csie.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/4] media: uapi: hevc: Add scaling matrix control
Date: Thu, 9 Jan 2020 16:19:30 +0100 [thread overview]
Message-ID: <16682efd-763a-8cb1-c5ee-b48ee6063c6b@xs4all.nl> (raw)
In-Reply-To: <3030664.44csPzL39Z@jernej-laptop>
On 1/9/20 4:17 PM, Jernej Škrabec wrote:
> Hi!
>
> Dne sreda, 08. januar 2020 ob 15:43:36 CET je Paul Kocialkowski napisal(a):
>> 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@siol.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.
>
> Specs ITU-T REC. H.265 (06/2019), chapter 7.3.4 shows that multiple different
> matrices can be present at the same time. If they are not, default values
> should be used instead. But in general, more than one can be needed at the
> same time.
>
> Only real question is if default values should be also provided by userspace
> or by kernel. Since place has to be reserved for all different scaling lists
> anyway, we won't save any space by providing default values in kernel. Cedrus
> VPU has only bit switch for using default values for all matrices at the same
> time or all custom.
>
> Note that this control contains slightly processed data. Frame has stored
> these matrices in form of deltas. But because this is the only driver that use
> this structure I have no idea what is the most proper form of this data (raw
> values or deltas). That's why this will stay in staging using private headers
> until we figure this out.
This definitely needs to be documented! Otherwise this will be forgotten.
Regards,
Hans
>
> Best regards,
> Jernej
>
>>
>> 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
>
>
>
>
next prev parent reply other threads:[~2020-01-09 15:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 16:04 [PATCH v2 0/4] media: cedrus: hevc: Add support for scaling matrix and multi-slice frames Jernej Skrabec
2019-12-13 16:04 ` [PATCH v2 1/4] media: uapi: hevc: Add scaling matrix control Jernej Skrabec
2020-01-08 14:11 ` Mauro Carvalho Chehab
2020-01-08 14:43 ` Paul Kocialkowski
2020-01-09 15:17 ` Jernej Škrabec
2020-01-09 15:19 ` Hans Verkuil [this message]
2019-12-13 16:04 ` [PATCH v2 2/4] media: cedrus: hevc: Add support for scaling matrix Jernej Skrabec
2020-01-07 15:01 ` Hans Verkuil
2020-01-07 17:10 ` Jernej Škrabec
2020-01-08 7:48 ` Hans Verkuil
2020-01-08 14:46 ` Hans Verkuil
2020-01-16 19:49 ` Jernej Škrabec
2019-12-13 16:04 ` [PATCH v2 3/4] media: uapi: hevc: Add segment address field Jernej Skrabec
2020-01-08 14:31 ` Mauro Carvalho Chehab
2020-01-09 14:46 ` Jernej Škrabec
2019-12-13 16:04 ` [PATCH v2 4/4] media: cedrus: hevc: Add support for multiple slices Jernej Skrabec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16682efd-763a-8cb1-c5ee-b48ee6063c6b@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jernej.skrabec@siol.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=mripard@kernel.org \
--cc=paul.kocialkowski@bootlin.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).