Linux Media Controller development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox