public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-media@vger.kernel.org, Tomasz Figa <tfiga@chromium.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	kernel@pengutronix.de
Subject: Re: [PATCH] media: uapi: h264: clarify num_ref_idx_l[01]_(default_)active fields
Date: Thu, 3 Oct 2019 17:12:47 -0400	[thread overview]
Message-ID: <20191003211247.GC3927@aptenodytes> (raw)
In-Reply-To: <20190905114210.9232-1-p.zabel@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

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?

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

  parent reply	other threads:[~2019-10-03 21:12 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 [this message]
2019-10-05  8:22   ` Tomasz Figa
2019-10-05 13:39     ` Paul Kocialkowski
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=20191003211247.GC3927@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox