linux-kernel - Re: [PATCH v2] media: uvcvideo: Implement V4L2_EVENT_FRAME

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] [day] [month] [year] [list]

Message-ID: <CANiDSCsctSyfgXxH3iroJPOE7R_9jB7todiEMBCU_5OG3EOCKQ@mail.gmail.com>
Date:   Fri, 24 Nov 2023 10:58:01 +0100
From:   Ricardo Ribalda <ribalda@...omium.org>
To:     Nicolas Dufresne <nicolas@...fresne.ca>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Esker Wong <esker@...gle.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Sakari Ailus <sakari.ailus@....fi>,
        Esker Wong <esker@...omium.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] media: uvcvideo: Implement V4L2_EVENT_FRAME_SYNC

> >
> > For bulk devices this is a maximum of 0.05 msec (32KiB/600MBps)
>
> I lack a bit of knowledge on how to scale this to different devices, with
> different speed/framesize. My only bulk device is:
>
> https://inogeni.com/product/4k2usb3/
>
> Which is USB 3.0, and have raw (NV12) resolution from 640x480 (max 60pfs) to 4K
> (max 30fps). What would the error look like with that ?

For bulk devices the maximum delay from packing multiple packets into
a urb is 0.05 msec (32KiB/600MBps)

Laurent's message <20231109000327.GE21616@...dragon.ideasonboard.com>
explains where those numbers come from :).

Regards!

>
> > For 1MiB transfer isoc devices (which is the biggest we have seen),
> > that is 1.8 msec.
> > In both cases, this is smaller than the jitter to process the event
> > itself by userspace.
> >
> > The time from V4L2_EVENT_FRAME_SYNC to DQBUF is around 30 msec.
> >
> > I do not know how much delay is considered acceptable... but if we
> > take the delay argument to the extreme, we could say that
> > V4L2_EVENT_FRAME_SYNC can never be implemented, because the event will
> > always be delayed by something.
>
> We have v4l2_event.timestamp for all events, so the jitter to process the event
> by userpace can be removed reliably already.
>
> Nicolas
>
> p.s. missed it earlier
>
> >
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> >
> >
> >
>


--
Ricardo Ribalda