linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Alexandre Courbot <acourbot@chromium.org>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	Tomasz Figa <tfiga@chromium.org>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Daniel Gomez <daniel@qtec.com>,
	Peter Griffin <peter.griffin@linaro.org>,
	Dafna Hirschfeld <dafna.hirschfeld@collabora.com>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Helen Koike <helen.koike@collabora.com>,
	Jan Schmidt <jan@centricular.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.org>,
	Michael Tretter <m.tretter@pengutronix.de>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Matthew Waters <matthew@centricular.com>
Subject: Re: [ANN] Report of Media Summit: Codecs
Date: Tue, 19 Nov 2019 15:18:19 +0100	[thread overview]
Message-ID: <b0ddcd59-cd54-67b8-af63-e7749403f868@xs4all.nl> (raw)
In-Reply-To: <311a152e-b773-76d6-a17e-86112b583179@xs4all.nl>

On 11/2/19 1:50 PM, Hans Verkuil wrote:

<snip>

> Action Items
> ------------
> 
> Hans Verkuil:
> 
> - Ask Cisco colleagues which bitrate-related parameters have to be per-frame for
>   an encoder
> - make stateful encoder infrastructure + documentation for the missing bits
> - investigate using different sizes for metadata controls in the control framework:
>   is this possible?

The problem is with compound arrays. struct v4l2_ext_control just provides a size field
for the total size and so for an array there is no way to discover the actual element
size.

That said, to my knowledge there are currently no compound arrays defined in the mainline
kernel. So one option is to take the last reserved __u32 field and split it in a
__u16 elem_size and a __u16 reserved2 field, or just use the full __u32 for the elem size
and drop the reserved2 field.

Alternatively, we prohibit compound arrays for now and postpone making any changes to
struct v4l2_ext_control until we actually need this.

As long as it is not an array, then we can safely extend these compound control structs
later. It requires some work in the control framework, but it isn't too bad.

I'm in favor of implementing this, and for now prohibiting the use of compound arrays.

It is really helpful making these codec state controls at least somewhat future-proof.

Comments?

	Hans

> 
> Michael Tretter:
> 
> - Support the new encoder stateful controls in the driver
> 
> Tomasz Figa:
> 
> - look up AMD encoder support
> 
> Boris Brezillon:
> 
> - send v3 of hantro g1 fixes
> 
> Nicolas Dufresne:
> 
> - look into multiview and sublayers support
> 
> Paul Kocialkowski:
> 
> - check metadata controls against the standards and update the docs if needed
> 
> Ezequiel Garcia and Boris Brezillon:
> 
> - add VP9 support
> 


  parent reply	other threads:[~2019-11-19 14:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-02 12:50 [ANN] Report of Media Summit: Codecs Hans Verkuil
2019-11-14 18:15 ` VP9 Stateless Support (follow up of [ANN] Report of Media Summit: Codecs) Nicolas Dufresne
2019-11-15  6:12   ` Boris Brezillon
2019-11-15 14:52   ` Recap of: " Nicolas Dufresne
2019-11-19 14:18 ` Hans Verkuil [this message]
2019-12-03  7:08   ` [ANN] Report of Media Summit: Codecs Tomasz Figa
2019-12-03  6:56 ` 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=b0ddcd59-cd54-67b8-af63-e7749403f868@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=acourbot@chromium.org \
    --cc=boris.brezillon@collabora.com \
    --cc=dafna.hirschfeld@collabora.com \
    --cc=daniel@qtec.com \
    --cc=dave.stevenson@raspberrypi.org \
    --cc=ezequiel@collabora.com \
    --cc=helen.koike@collabora.com \
    --cc=jan@centricular.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=matthew@centricular.com \
    --cc=nicolas@ndufresne.ca \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=peter.griffin@linaro.org \
    --cc=stanimir.varbanov@linaro.org \
    --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;
as well as URLs for NNTP newsgroup(s).