All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: Ricardo Ribalda <ribalda@chromium.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 09/11] media: uvcvideo: Increase the size of UVC_METADATA_BUF_SIZE
Date: Tue, 16 Mar 2021 10:45:11 +0100	[thread overview]
Message-ID: <df9feb80-6a31-478c-005c-13c12c4bf05e@xs4all.nl> (raw)
In-Reply-To: <20210315173609.1547857-10-ribalda@chromium.org>

Hi Ricardo, Laurent,

On 15/03/2021 18:36, Ricardo Ribalda wrote:
> Hans has discovered that in his test device, for the H264 format
> bytesused goes up to about 570, for YUYV it will actually go up
> to a bit over 5000 bytes, and for MJPG up to about 2706 bytes.
> 
> Credit-to: Hans Verkuil <hverkuil@xs4all.nl>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
>  drivers/media/usb/uvc/uvcvideo.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 1f17e4253673..91fc00ff311b 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -528,7 +528,7 @@ struct uvc_stats_stream {
>  	unsigned int max_sof;		/* Maximum STC.SOF value */
>  };
>  
> -#define UVC_METADATA_BUF_SIZE 1024
> +#define UVC_METADATA_BUF_SIZE 10240
>  
>  /**
>   * struct uvc_copy_op: Context structure to schedule asynchronous memcpy
> 

I've been doing some tests here, and this is tricky.

I think the core bug is in uvc_video_decode_meta():

        if (meta_buf->length - meta_buf->bytesused <
            length + sizeof(meta->ns) + sizeof(meta->sof)) {
                meta_buf->error = 1;
                return;
        }

This checks for a buffer overflow and by setting meta_buf->error to 1 it causes
the whole buffer to be discarded. But according to the V4L2_META_FMT_UVC docs here

https://hverkuil.home.xs4all.nl/spec/userspace-api/v4l/pixfmt-meta-uvc.html

it should "drop headers when the buffer is full", which suggests to me that
the 'meta_buf->error = 1;' is wrong and should be removed.

Looking at the number of headers I receive for various frame sizes and frame rates
when choosing YUYV as the pixelformat I see that the frame rate is the main input
to that: I get (very roughly) one header for every 150 microseconds. So that's
roughly 667 headers of 22 bytes for a 10 fps capture. The frame size has some
effect, but it is fairly small. This means that for slow captures (i.e. 2 fps)
you need about 75000 bytes, let's round it up to 102400.

I did tests with 1920x1080 at 5 fps for YUYV, H264 and MJPEG and saw the following:

Format		Video Size	Metadata Size

YUYV		4147200		29964
MJPG		130000		3608
H264 (P-frame)	70000		2600
H264 (I-frame)	150000		5500

The difference here is most likely due to YUYV being transmitted over time as
video lines arrive, so it is spread out over time, while H264 and MJPG are
bursty, i.e. the whole compressed frame is transferred in one go.

I think that 10240 is a good value for the metadata buffers since it is enough
for the worst-case for the compressed formats, and that if this is combined
with removing the 'meta_buf->error = 1;' it will also do its job for YUYV
even though data will be dropped, but that's better than not getting anything
at all.

Regards,

	Hans

  reply	other threads:[~2021-03-16  9:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 17:35 [PATCH v4 00/11] uvcvideo: Fix v4l2-compliance errors Ricardo Ribalda
2021-03-15 17:35 ` [PATCH v4 01/11] media: v4l2-ioctl: Fix check_ext_ctrls Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 02/11] media: uvcvideo: Set capability in s_param Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 03/11] media: uvcvideo: Return -EIO for control errors Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 04/11] media: uvcvideo: set error_idx to count on EACCESS Ricardo Ribalda
2021-03-16 11:20   ` Hans Verkuil
2021-03-15 17:36 ` [PATCH v4 05/11] media: uvcvideo: refactor __uvc_ctrl_add_mapping Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 06/11] media: uvcvideo: Add support for V4L2_CTRL_TYPE_CTRL_CLASS Ricardo Ribalda
2021-03-16  8:37   ` Hans Verkuil
2021-03-16 10:08     ` Laurent Pinchart
2021-03-16 10:12       ` Ricardo Ribalda
2021-03-16 11:04         ` Laurent Pinchart
2021-03-15 17:36 ` [PATCH v4 07/11] media: uvcvideo: Use dev->name for querycap() Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 08/11] media: uvcvideo: Set unique vdev name based in type Ricardo Ribalda
2021-03-16 10:10   ` Hans Verkuil
2021-03-15 17:36 ` [PATCH v4 09/11] media: uvcvideo: Increase the size of UVC_METADATA_BUF_SIZE Ricardo Ribalda
2021-03-16  9:45   ` Hans Verkuil [this message]
2021-03-15 17:36 ` [PATCH v4 10/11] media: uvcvideo: Return -EACCES to inactive controls Ricardo Ribalda
2021-03-15 17:36 ` [PATCH v4 11/11] uvc: use vb2 ioctl and fop helpers Ricardo Ribalda
2021-03-16 11:29   ` Hans Verkuil

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=df9feb80-6a31-478c-005c-13c12c4bf05e@xs4all.nl \
    --to=hverkuil-cisco@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ribalda@chromium.org \
    --cc=sergey.senozhatsky@gmail.com \
    /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.