From: mgottam@codeaurora.org
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Tomasz Figa <tfiga@chromium.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Alexandre Courbot <acourbot@chromium.org>,
vgarodia@codeaurora.org
Subject: Re: [PATCH] media: venus: amend buffer size for bitstream plane
Date: Tue, 13 Nov 2018 12:58:02 +0530 [thread overview]
Message-ID: <38dfc098517b3ddb5d96195f2e27429d@codeaurora.org> (raw)
In-Reply-To: <8fe1d205-c5e7-01a0-9569-d3268911cddd@linaro.org>
On 2018-11-12 18:04, Stanimir Varbanov wrote:
> Hi Tomasz,
>
> On 10/23/2018 05:50 AM, Tomasz Figa wrote:
>> Hi Malathi,
>>
>> On Tue, Oct 9, 2018 at 4:58 PM Malathi Gottam <mgottam@codeaurora.org>
>> wrote:
>>>
>>> For lower resolutions, incase of encoder, the compressed
>>> frame size is more than half of the corresponding input
>>> YUV. Keep the size as same as YUV considering worst case.
>>>
>>> Signed-off-by: Malathi Gottam <mgottam@codeaurora.org>
>>> ---
>>> drivers/media/platform/qcom/venus/helpers.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/qcom/venus/helpers.c
>>> b/drivers/media/platform/qcom/venus/helpers.c
>>> index 2679adb..05c5423 100644
>>> --- a/drivers/media/platform/qcom/venus/helpers.c
>>> +++ b/drivers/media/platform/qcom/venus/helpers.c
>>> @@ -649,7 +649,7 @@ u32 venus_helper_get_framesz(u32 v4l2_fmt, u32
>>> width, u32 height)
>>> }
>>>
>>> if (compressed) {
>>> - sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 /
>>> 2;
>>> + sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2;
>>> return ALIGN(sz, SZ_4K);
>>> }
>>
>> Note that the driver should not enforce one particular buffer size for
>> bitstream buffers unless it's a workaround for broken firmware or
>> hardware. The userspace should be able to select the desired size.
>
> Good point! Yes, we have to extend set_fmt to allow bigger sizeimage
> for
> the compressed buffers (not only for encoder).
So Stan you meant to say that we should allow s_fmt to accept client
specified size?
If so should we set the inst->input_buf_size here in venc_s_fmt?
@@ -333,10 +333,10 @@static const struct venus_format *
venc_try_fmt_common(struct venus_inst *inst, struct v4l2_format *f)
pixmp->num_planes = fmt->num_planes;
pixmp->flags = 0;
-
- pfmt[0].sizeimage = venus_helper_get_framesz(pixmp->pixelformat,
- pixmp->width,
- pixmp->height);
+ if (!pfmt[0].sizeimage)
+ pfmt[0].sizeimage =
venus_helper_get_framesz(pixmp->pixelformat,
+
pixmp->width,
+
pixmp->height);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
pfmt[0].bytesperline = ALIGN(pixmp->width, 128);
@@ -387,6 +387,7 @@ static int venc_s_fmt(struct file *file, void *fh,
struct v4l2_format *f)
venc_try_fmt_common(inst, &format);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ inst->input_buf_size = pixmp->plane_fmt[0].sizeimage;
inst->out_width = format.fmt.pix_mp.width;
inst->out_height = format.fmt.pix_mp.height;
Similar implementation is already handled in case of decoder.
Then in queue setup, we can compare this against calculated size to
obtain final buffer size
@@ -899,7 +900,8 @@ static int venc_queue_setup(struct vb2_queue *q,
sizes[0] =
venus_helper_get_framesz(inst->fmt_out->pixfmt,
inst->width,
inst->height);
- inst->input_buf_size = sizes[0];
+ if(inst->input_buf_size < sizes[0])
+ inst->input_buf_size = sizes[0];
break;
I hope this meets are requirements.
next prev parent reply other threads:[~2018-11-13 7:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 7:52 [PATCH] media: venus: amend buffer size for bitstream plane Malathi Gottam
2018-10-22 6:12 ` Alexandre Courbot
2018-10-23 2:50 ` Tomasz Figa
2018-11-12 12:34 ` Stanimir Varbanov
2018-11-13 7:28 ` mgottam [this message]
2018-11-13 8:12 ` Stanimir Varbanov
2018-11-13 9:13 ` Tomasz Figa
2018-11-13 10:46 ` Stanimir Varbanov
2018-11-14 3:51 ` Tomasz Figa
2018-11-16 4:34 ` mgottam
2018-11-16 6:02 ` Tomasz Figa
2018-11-12 12:28 ` Stanimir Varbanov
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=38dfc098517b3ddb5d96195f2e27429d@codeaurora.org \
--to=mgottam@codeaurora.org \
--cc=acourbot@chromium.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=stanimir.varbanov@linaro.org \
--cc=tfiga@chromium.org \
--cc=vgarodia@codeaurora.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.