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