All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Nicolas Dufresne <nicolas@ndufresne.ca>,
	Michael Tretter <m.tretter@pengutronix.de>,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org
Cc: kernel@pengutronix.de, robh+dt@kernel.org, mchehab@kernel.org,
	tfiga@chromium.org
Subject: Re: [PATCH v2 2/3] [media] allegro: add Allegro DVT video IP core driver
Date: Wed, 30 Jan 2019 08:47:20 +0100	[thread overview]
Message-ID: <f983efdb-4ac1-d2e2-4be3-421d337f94ef@xs4all.nl> (raw)
In-Reply-To: <9e29f43951bf25708060bc25f4d1e94756970ee2.camel@ndufresne.ca>

On 1/30/19 4:41 AM, Nicolas Dufresne wrote:
> Hi Hans,
> 
> Le mercredi 23 janvier 2019 à 11:44 +0100, Hans Verkuil a écrit :
>>> +     if (*nplanes != 0) {
>>> +             if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
>>> +                     if (*nplanes != 1 ||
>>> +                         sizes[0] < channel->sizeimage_encoded)
>>> +                             return -EINVAL;
>>
>> Question relating to calculating sizeimage_encoded: is that guaranteed to be
>> the largest buffer size that is needed to compress a frame? What if it is
>> not large enough after all? Does the encoder protect against that?
>>
>> I have a patch pending that allows an encoder to spread the compressed
>> output over multiple buffers:
>>
>> https://patchwork.linuxtv.org/patch/53536/
>>
>> I wonder if this encoder would be able to use it.
> 
> Userspace around most existing codecs expect well framed capture buffer
> from the encoder. Spreading out the buffer will just break this
> expectation.
> 
> This is specially needed for VP8/VP9 as these format are not meant to
> be streamed that way.

Good to know, thank you.

> I believe a proper solution to that would be to hang the decoding
> process and send an event (similar to resolution changes) to tell user
> space that capture buffers need to be re-allocated.

That's indeed an alternative. I wait for further feedback from Tomasz
on this.

I do want to add that allowing it to be spread over multiple buffers
also means more optimal use of memory. I.e. the buffers for the compressed
data no longer need to be sized for the worst-case size.

Regards,

	Hans

  reply	other threads:[~2019-01-30  7:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 13:37 [PATCH v2 0/3] Add ZynqMP VCU/Allegro DVT H.264 encoder driver Michael Tretter
2019-01-18 13:37 ` [PATCH v2 1/3] media: dt-bindings: media: document allegro-dvt bindings Michael Tretter
2019-01-21 10:59   ` Philipp Zabel
2019-01-21 16:17     ` Nicolas Dufresne
2019-01-21 16:30       ` Philipp Zabel
2019-01-21 17:42       ` Michael Tretter
2019-01-21 17:13   ` Rob Herring
2019-01-22 13:38     ` Michael Tretter
2019-01-18 13:37 ` [PATCH v2 2/3] [media] allegro: add Allegro DVT video IP core driver Michael Tretter
2019-01-23 10:44   ` Hans Verkuil
2019-01-23 14:17     ` Michael Tretter
2019-01-30  3:46       ` Nicolas Dufresne
2019-01-30  3:54         ` Tomasz Figa
2019-01-30  9:22         ` Michael Tretter
2019-01-30  3:41     ` Nicolas Dufresne
2019-01-30  7:47       ` Hans Verkuil [this message]
2019-01-30 15:19         ` Nicolas Dufresne
2019-01-30 16:14           ` Michael Tretter
2019-01-18 13:37 ` [PATCH v2 3/3] [media] allegro: add SPS/PPS nal unit writer Michael Tretter
2019-01-18 14:11 ` [PATCH v2 0/3] Add ZynqMP VCU/Allegro DVT H.264 encoder driver Hans Verkuil
2019-01-21 10:42   ` Michael Tretter
2019-01-23 10:48     ` 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=f983efdb-4ac1-d2e2-4be3-421d337f94ef@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-media@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=robh+dt@kernel.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 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.