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 16:25:30 +0200 [thread overview]
Message-ID: <eba506ce-4d63-649a-80e6-efad20125263@xs4all.nl> (raw)
In-Reply-To: <997204c7-c702-868c-9a49-52fefc9ab3d2@linaro.org>
On 6/28/19 4:23 PM, Stanimir Varbanov wrote:
> Hi Hans,
>
> On 6/28/19 4:37 PM, Hans Verkuil wrote:
>> 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?
>
> Yes.
>
>>
>> E.g. if v4l2-compliance would first set the output resolution to 320x240,
>> is the returned sizeimage value OK in that case?
>
> Yes.
>
> Here are few options to me:
> - set the correct resolution
> - set 0x0 and sizeimage at some arbitrary value (1 or 2MB). Despite if
> the bitstream is 4K it will not be enough if the bitrate is huge.
> - invent some mechanism to trigger reconfiguration on the OUTPUT queue
> as well (similar to the CAPTURE queue)
>
>>
>> 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.
>
> I cannot say for sure but that is how all downstream cases uses it i.e.
> one compressed frame per input buffer. I wonder if you fill input
> decoder buffer with many compressed frames in one input decoder buffer
> how you pass the timestamp for every packet?
>
>>
>> We really need to let userspace know about such restrictions.
>>
>> Stanimir, can you list the restrictions of the decoder for the various
>> codecs?
>
> What you mean? Restrictions like "one compressed frame per input buffer"?
>
Yes :-)
Regards,
Hans
next prev parent reply other threads:[~2019-06-28 14:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 12:59 [PATCH v2 00/11] Venus stateful Codec API 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 ` [PATCH v2 00/11] Venus stateful Codec API Hans Verkuil
2019-06-28 14:23 ` Stanimir Varbanov
2019-06-28 14:25 ` Hans Verkuil [this message]
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=eba506ce-4d63-649a-80e6-efad20125263@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;
as well as URLs for NNTP newsgroup(s).