linux-kernel - Re: [PATCH v2 00/11] Venus stateful Codec API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9c3399a8-4fc6-3117-10ee-3395cee034da@xs4all.nl>
Date:   Fri, 28 Jun 2019 15:37:11 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        linux-media@...r.kernel.org
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        Vikash Garodia <vgarodia@...eaurora.org>,
        Tomasz Figa <tfiga@...omium.org>,
        Alexandre Courbot <acourbot@...omium.org>
Subject: Re: [PATCH v2 00/11] Venus stateful Codec API

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