public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jernej Škrabec" <jernej.skrabec@gmail.com>
To: mchehab@kernel.org, ezequiel@vanguardiasur.com.ar,
	p.zabel@pengutronix.de, gregkh@linuxfoundation.org,
	mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org,
	jonas@kwiboo.se, nicolas@ndufresne.ca,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, kernel@collabora.com,
	knaerzche@gmail.com, jc@kynesim.co.uk,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>
Subject: Re: Re: [PATCH v3 09/14] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSET control
Date: Sat, 26 Feb 2022 18:59:18 +0100	[thread overview]
Message-ID: <1884298.PYKUYFuaPT@kista> (raw)
In-Reply-To: <4378293.LvFx2qVVIh@kista>

Hi!

Dne petek, 25. februar 2022 ob 20:30:20 CET je Jernej Škrabec napisal(a):
> Hi!
> 
> Dne petek, 25. februar 2022 ob 17:45:55 CET je Benjamin Gaignard napisal(a):
> > The number of 'entry point offset' could be very variable.
> > Rather than use a large static array define a v4l2 dynamic array
> > of integer control.
> 
> I suggest we should be more specific and say U32 (V4L2_CTRL_TYPE_U32).
> 
> > The number of entry point offsets is reported by the elems field.

I did few more tests and these are my findings:
1. dynamic array can't be set over size, specified in .dims array
2. entry point offsets are per slice, so if we make slices dynamic array, then 
entry points would become two dimensional dynamic array
3. num_entry_point_offsets must be part of slice control, because it can be 
zero, but size of array can't be
4. fortunately, not setting entry points doesn't impact decoding correctness. 
This is in line what John told me about them.

Hans, can you comment points 1-3? I might misunderstand point 1.

In short, it seems like we don't really need entry points, even if they are 
used in BSP library. In both cases, I got fluster score 119/138 (10-bit 
excluded), so we can just drop this patch, although I'm a bit uneasy not 
setting entry points...

Best regards,
Jernej

> > 
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> > ---
> >  .../userspace-api/media/v4l/ext-ctrls-codec.rst          | 9 +++++++++
> >  include/media/hevc-ctrls.h                               | 1 +
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/
> Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > index 44a268a948c0..71f7dc1c1ccd 100644
> > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> > @@ -3128,6 +3128,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
> >  
> >      \normalsize
> >  
> > +``V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS (integer)``
> 
> Here you have OFFSETS (plural) ...
> 
> > +    Specifies the i-th entry point offset in bytes and is represented by
> > +    offset_len_minus1 plus 1 bits.
> 
> You probably mean entry_point_offset_minus1? offset_len_minus1 just tells how 
> much bits need to be read for each element and it's not important for actual 
> decoding.
> 
> > +    This control is a dynamically sized array. The number of entry point
> > +    offsets is reported by the ``elems`` field.
> > +    This bitstream parameter is defined according to :ref:`hevc`.
> > +    They are described in section 7.4.7.1 "General slice segment header
> > +    semantics" of the specification.
> > +
> >  ``V4L2_CID_STATELESS_HEVC_SCALING_MATRIX (struct)``
> >      Specifies the HEVC scaling matrix parameters used for the scaling 
> process
> >      for transform coefficients.
> > diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
> > index 3016c1abb1d0..3f8a67924df3 100644
> > --- a/include/media/hevc-ctrls.h
> > +++ b/include/media/hevc-ctrls.h
> > @@ -20,6 +20,7 @@
> >  #define V4L2_CID_STATELESS_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_BASE + 
> 1012)
> >  #define V4L2_CID_STATELESS_HEVC_DECODE_MODE	(V4L2_CID_CODEC_BASE + 
> 1015)
> >  #define V4L2_CID_STATELESS_HEVC_START_CODE	(V4L2_CID_CODEC_BASE + 
1016)
> > +#define V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSET (V4L2_CID_CODEC_BASE + 
> 1017)
> 
> ... and here you have OFFSET (singlular). I suggest plural form to be used 
in 
> all places, including subject line of this commit.
> 
> Additionally, it would be nice if control is initialized, like so:
> https://github.com/jernejsk/linux-1/commit/
> f938e162cd8dd77c9f6f1b248d80144840a37bce
> 
> Best regards,
> Jernej
> 
> >  
> >  /* enum v4l2_ctrl_type type values */
> >  #define V4L2_CTRL_TYPE_HEVC_SPS 0x0120
> > -- 
> > 2.32.0
> > 
> > 
> 
> 
> 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-02-26 18:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 16:45 [PATCH v3 00/14] Move HEVC stateless controls out of staging Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 01/14] videodev2.h: add V4L2_CTRL_FLAG_DYNAMIC_ARRAY Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 02/14] v4l2-ctrls: add support for dynamically allocated arrays Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 03/14] vivid: add dynamic array test control Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 04/14] media: uapi: HEVC: Add missing fields in HEVC controls Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 05/14] media: uapi: HEVC: Rename HEVC stateless controls with STATELESS prefix Benjamin Gaignard
2022-02-25 22:19   ` Jernej Škrabec
2022-02-25 16:45 ` [PATCH v3 06/14] media: uapi: HEVC: Add document uAPI structure Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 07/14] media: uapi: HEVC: Define V4L2_CID_STATELESS_HEVC_SLICE_PARAMS as a dynamic array Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 08/14] media: uapi: Move parsed HEVC pixel format out of staging Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 09/14] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSET control Benjamin Gaignard
2022-02-25 19:30   ` Jernej Škrabec
2022-02-26 17:59     ` Jernej Škrabec [this message]
2022-02-26 18:17       ` Re: " Jernej Škrabec
2022-02-28  9:47         ` John Cox
2022-02-28 10:24           ` Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 10/14] media: uapi: Move the HEVC stateless control type out of staging Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 11/14] media: controls: Log HEVC stateless control in .std_log Benjamin Gaignard
2022-02-25 16:45 ` [PATCH v3 12/14] media: uapi: Create a dedicated header for Hantro control Benjamin Gaignard
2022-02-25 19:16   ` Jernej Škrabec
2022-02-25 16:45 ` [PATCH v3 13/14] media: uapi: HEVC: fix padding in v4l2 control structures Benjamin Gaignard
2022-02-25 19:33 ` [PATCH v3 00/14] Move HEVC stateless controls out of staging Jernej Škrabec
2022-02-26 22:25 ` Adam Ford
2022-02-28 10:13   ` Benjamin Gaignard
2022-03-03  1:23     ` Adam Ford
2022-03-03 10:13       ` Benjamin Gaignard
2022-03-04 12:59         ` Adam Ford
2022-03-04 13:03           ` Benjamin Gaignard
2022-03-04 22:46             ` Adam Ford
2022-03-07  8:49               ` Benjamin Gaignard

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=1884298.PYKUYFuaPT@kista \
    --to=jernej.skrabec@gmail.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=gregkh@linuxfoundation.org \
    --cc=jc@kynesim.co.uk \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=p.zabel@pengutronix.de \
    --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