From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Ezequiel Garcia <ezequiel@collabora.com>,
Boris Brezillon <boris.brezillon@collabora.com>,
Sasha Hauer <kernel@pengutronix.de>
Subject: Re: [PATCH] media: uapi: h264: clarify num_ref_idx_l[01]_(default_)active fields
Date: Sat, 5 Oct 2019 09:39:20 -0400 [thread overview]
Message-ID: <20191005133920.GB19943@aptenodytes> (raw)
In-Reply-To: <CAAFQd5BG5_up_Ov7GU3qcB5NCjWcnP4Da0GKWJTuRzGr-WEa4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]
Hi,
On Sat 05 Oct 19, 17:22, Tomasz Figa wrote:
> On Fri, Oct 4, 2019 at 6:12 AM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> >
> > Hi,
> >
> > On Thu 05 Sep 19, 13:42, Philipp Zabel wrote:
> > > To explain why num_ref_idx_active_override_flag is not part of the API,
> > > describe how the num_ref_idx_l[01]_active_minus1 fields and the
> > > num_ref_idx_l[01]_default_active_minus1 fields are used, depending on
> > > whether the decoder parses slice headers itself or not.
> >
> > Is there any particular reason why this is preferable to exposing the flag?
> > It feels like having the flag around sticks closer to the bitstream,
> > so it's more straightforward for everyone.
> >
> > In case there's only one set of fields exposed by the hardware (and it doesn't
> > do slice parsing itself), we could always check the flag in the driver and use
> > either the default PPS values or the slice-specific values there.
> >
> > What do you think?
>
> IMHO it would only add further logic to the drivers, because they
> would need to have a conditional block that selects default or
> per-slice value based on the flag. The goal was to be able for the
> driver to just passively write num_ref_idx_l[01]_active_minus1 (or the
> default one for slice-parsing hardware) to corresponding hardware
> registers.
Well, the Allwinner block has both set of fields and a field for the flag,
so in this case I find that it is cleaner to just copy the values and flag
rather than always setting the flag even when it's the default value used.
More generally, the two sets + flag are closer to bitstream which feels less
confusing than re-purposing these fields from the slice header to fit the
result of flag ? per-slice : per-picture.
> We're talking about kernel drivers here and for security reasons any
> logic should be reduced to the strictly necessary minimum.
I definitely agree that bitstream parsing in the kernel is to be avoided for
security reasons (among other things), but don't see the harm in considering
the flags in-driver if needed. We do it for a number of other flags already
(and strongly need to).
Cheers,
Paul
> >
> > Cheers,
> >
> > Paul
> >
> > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > ---
> > > Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> > > index bc5dd8e76567..b9834625a939 100644
> > > --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> > > +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> > > @@ -1630,10 +1630,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> > > -
> > > * - __u8
> > > - ``num_ref_idx_l0_default_active_minus1``
> > > - -
> > > + - This field is only used by decoders that parse slices themselves.
> > > * - __u8
> > > - ``num_ref_idx_l1_default_active_minus1``
> > > - -
> > > + - This field is only used by decoders that parse slices themselves.
> > > * - __u8
> > > - ``weighted_bipred_idc``
> > > -
> > > @@ -1820,10 +1820,14 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> > > -
> > > * - __u8
> > > - ``num_ref_idx_l0_active_minus1``
> > > - -
> > > + - This field is used by decoders that do not parse slices themselves.
> > > + If num_ref_idx_active_override_flag is not set, this field must be
> > > + set to the value of num_ref_idx_l0_default_active_minus1.
> > > * - __u8
> > > - ``num_ref_idx_l1_active_minus1``
> > > - -
> > > + - This field is used by decoders that do not parse slices themselves.
> > > + If num_ref_idx_active_override_flag is not set, this field must be
> > > + set to the value of num_ref_idx_l1_default_active_minus1.
> > > * - __u32
> > > - ``slice_group_change_cycle``
> > > -
> > > --
> > > 2.20.1
> > >
> >
> > --
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-05 13:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 11:42 [PATCH] media: uapi: h264: clarify num_ref_idx_l[01]_(default_)active fields Philipp Zabel
2019-09-09 12:09 ` Hans Verkuil
2019-09-09 12:27 ` Philipp Zabel
2019-09-09 12:43 ` Hans Verkuil
2019-09-09 13:36 ` Philipp Zabel
2019-09-09 14:00 ` Hans Verkuil
2019-10-03 21:12 ` Paul Kocialkowski
2019-10-05 8:22 ` Tomasz Figa
2019-10-05 13:39 ` Paul Kocialkowski [this message]
2019-10-05 13:54 ` Tomasz Figa
2019-10-05 14:12 ` Paul Kocialkowski
2019-10-05 14:21 ` Tomasz Figa
2019-10-05 15:42 ` Paul Kocialkowski
2019-10-16 13:37 ` Paul Kocialkowski
2019-10-16 15:08 ` Philipp Zabel
2019-10-25 6:24 ` Tomasz Figa
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=20191005133920.GB19943@aptenodytes \
--to=paul.kocialkowski@bootlin.com \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=tfiga@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.