All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Hans Verkuil <hverkuil@xs4all.nl>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	linux-media@vger.kernel.org
Cc: Tomasz Figa <tfiga@chromium.org>
Subject: Re: [PATCH 07/10] media: coda: limit frame interval enumeration to supported frame sizes
Date: Thu, 11 Apr 2019 10:22:05 +0200	[thread overview]
Message-ID: <1554970925.6389.1.camel@pengutronix.de> (raw)
In-Reply-To: <5feecd0e-5c7b-27fe-84a0-0bffb04128df@xs4all.nl>

On Wed, 2019-04-10 at 18:24 +0200, Hans Verkuil wrote:
> On 4/10/19 6:11 PM, Nicolas Dufresne wrote:
> > Le mercredi 10 avril 2019 à 16:22 +0200, Philipp Zabel a écrit :
> > > On Wed, 2019-04-10 at 15:43 +0200, Hans Verkuil wrote:
> > > [...]
> > > > > @@ -1126,12 +1127,32 @@ static int coda_enum_frameintervals(struct file *file, void *fh,
> > > 
> > > [...]
> > > > Why support VIDIOC_ENUM_FRAMEINTERVALS at all? It makes no sense for a codec.
> > > > I'd remove it altogether.
> > 
> > It does make sense, since framerate is the only information that can be
> > used to produce a specific bitrate. If you don't enumerate the rates,
> > then you may endup with a miss-match of what userspace wants, which
> > will result in a different rate then what the user-space anticipated.
> > That being said, I expect these intervals to be really wide. Venus HW
> > uses a Q16 internally, which is precise enough that we could just
> > ignore the interval.
> 
> So the problem is that for an encoder where you desires a specific
> constant bitrate, the encoder also needs to know the framerate.
> 
> And the driver then would have to support ENUM_FRAMEINTERVALS and the
> S_PARM ioctl so userspace can set the framerate.

Ah right, that was it. Encoding works fine without ENUM_FRAMEINTERVALS,
as coda has no meaningful frame rate limitations. I had implemented
S_PARM since it is required for CBR encoding, and v4l2-compliance then
complained about ENUM_FRAMEINTERVALS missing:

  cde29ef313de ("[media] coda: Use S_PARM to set nominal framerate for h.264 encoder")
  07b6080d4e6d ("media: coda: implement ENUM_FRAMEINTERVALS")

> For decoders this would not make any sense AFAIKS, so this is encoder
> specific.

Hmm, not necesarily. I hadn't thought about that before, but if the
decoder supports frame skipping this could be used to advertise
available reductions in frame rate.

> Do I understand this correctly?
> 
> What should the default framerate be? 24 or 29.97 fps?

Driver specific? Max nominal real time capable frame rate? 30 fps?

> This should be documented in the stateful encoder spec. I never realized
> that this would be needed...
> 
> Philipp, based on this information I would say that ENUM_FRAMEINTERVALS
> can stay in the coda drivers, but for encoders only.

Ok.

regards
Philipp

  reply	other threads:[~2019-04-11  8:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 12:32 [PATCH 01/10] media: coda: set codec earlier Philipp Zabel
2019-04-08 12:32 ` [PATCH 02/10] media: coda: remove mask from decoder h.264 level control Philipp Zabel
2019-04-08 12:32 ` [PATCH 03/10] media: coda: clear error return value before picture run Philipp Zabel
2019-04-08 12:32 ` [PATCH 04/10] media: coda: add min number of buffers controls Philipp Zabel
2019-04-08 12:32 ` [PATCH 05/10] media: coda: disable encoder command on decoder and vice versa Philipp Zabel
2019-04-08 12:32 ` [PATCH 06/10] media: coda: implement encoder frame size enumeration Philipp Zabel
2019-04-08 12:32 ` [PATCH 07/10] media: coda: limit frame interval enumeration to supported frame sizes Philipp Zabel
2019-04-10 13:43   ` Hans Verkuil
2019-04-10 14:22     ` Philipp Zabel
2019-04-10 16:11       ` Nicolas Dufresne
2019-04-10 16:24         ` Hans Verkuil
2019-04-11  8:22           ` Philipp Zabel [this message]
2019-04-11 10:18             ` Hans Verkuil
2019-04-11 11:52               ` Ian Arkver
2019-04-11 12:00               ` Philipp Zabel
2019-04-11 15:53                 ` Nicolas Dufresne
2019-04-15  5:32                   ` Tomasz Figa
2019-04-08 12:32 ` [PATCH 08/10] media: coda: allow encoder to set colorimetry on the output queue Philipp Zabel
2019-04-10 13:48   ` Hans Verkuil
2019-04-10 14:23     ` Philipp Zabel
2019-04-08 12:32 ` [PATCH 09/10] media: coda: throw error on create_bufs with too small size Philipp Zabel
2019-04-08 12:32 ` [PATCH 10/10] media: coda: require all decoder command flags to be cleared Philipp Zabel
2019-04-09 16:57   ` Philipp Zabel
2019-04-10 13:53     ` Hans Verkuil

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=1554970925.6389.1.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=nicolas@ndufresne.ca \
    --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.