From: Hans Verkuil <hverkuil@xs4all.nl>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>,
linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Vikash Garodia <vgarodia@codeaurora.org>,
Tomasz Figa <tfiga@chromium.org>,
Alexandre Courbot <acourbot@chromium.org>
Subject: Re: [PATCH v2 00/11] Venus stateful Codec API
Date: Fri, 28 Jun 2019 15:37:11 +0200 [thread overview]
Message-ID: <9c3399a8-4fc6-3117-10ee-3395cee034da@xs4all.nl> (raw)
In-Reply-To: <20190628130002.24293-1-stanimir.varbanov@linaro.org>
On 6/28/19 2:59 PM, Stanimir Varbanov wrote:
> Hello,
>
> Here is v2 of the Venus transition to stateful codec API
> compliance. The v2 can be found at [1].
>
> Changes since v1:
> * codec_state is now enum
> * dropped IS_OUT and IS_CAP macros and use vb2_start_streaming_called()
> * corrected g_fmt and reconfig logic
> * s/vdec_dst_buffers_done/vdec_cancel_dst_buffers
> * use v4l2_m2m_ioctl_try_decoder_cmd M2M helper
> * various fixes to make v4l2-compliance pass the streaming test
>
> To test the streaming with --stream-from-hdr v4l2-compliance option I have
> to make the following hack (it is needed because the size of decoder input
> buffers (OUTPUT queue) is not enough for the h264 bitstream, i.e the driver
> default resolution is 64x64 but the h264 stream is 320x240):
>
> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> index c71dcf65b721..dc0fcf20d3e4 100644
> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> @@ -1294,6 +1294,11 @@ int testMmap(struct node *node, unsigned frame_count, enum poll_mode pollmode)
> fmt.s_sizeimage(fmt.g_sizeimage(p) * 2, p);
> }
> fail_on_test(q.create_bufs(node, 1, &fmt));
> +
> + for (unsigned p = 0; p < fmt.g_num_planes(); p++)
> + fmt.s_sizeimage(fmt.g_sizeimage(p) * 2, p);
> + node->s_fmt(fmt);
> +
> fail_on_test(q.reqbufs(node, 2));
> }
> if (v4l_type_is_output(type))
Does the venus driver set sizeimage based on the given output resolution?
E.g. if v4l2-compliance would first set the output resolution to 320x240,
is the returned sizeimage value OK in that case?
And this also means that the venus driver requires each buffer to have
a single compressed frame, right? I.e. it can't be spread over multiple
OUTPUT buffers.
We really need to let userspace know about such restrictions.
Stanimir, can you list the restrictions of the decoder for the various
codecs?
Regards,
Hans
next prev parent reply other threads:[~2019-06-28 13:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 12:59 Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 01/11] venus: venc: amend buffer size for bitstream plane Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 02/11] venus: helpers: export few helper functions Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 03/11] venus: hfi: add type argument to hfi flush function Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 04/11] venus: hfi: export few HFI functions Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 05/11] venus: hfi: return an error if session_init is already called Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 06/11] venus: helpers: add three more helper functions Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 07/11] venus: vdec_ctrls: get real minimum buffers for capture Stanimir Varbanov
2019-06-28 12:59 ` [PATCH v2 08/11] venus: vdec: allow bigger sizeimage set by clients Stanimir Varbanov
2019-06-28 13:00 ` [PATCH v2 09/11] venus: make decoder compliant with stateful codec API Stanimir Varbanov
2019-06-28 13:00 ` [PATCH v2 10/11] venus: helpers: handle correctly vbuf field Stanimir Varbanov
2019-06-28 13:00 ` [PATCH v2 11/11] venus: dec: populate properly timestamps and flags for capture buffers Stanimir Varbanov
2019-06-28 13:37 ` Hans Verkuil [this message]
2019-06-28 14:23 ` [PATCH v2 00/11] Venus stateful Codec API Stanimir Varbanov
2019-06-28 14:25 ` Hans Verkuil
2019-06-28 14:31 ` Nicolas Dufresne
2019-06-28 14:32 ` Nicolas Dufresne
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=9c3399a8-4fc6-3117-10ee-3395cee034da@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=acourbot@chromium.org \
--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
all inboxes | Powered by JetHome®