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: <8abf9651-5ce1-7b73-6d14-04f42081a743@chromium.org>
Date:   Tue, 11 Apr 2023 20:34:29 +0900
From:   Max Staudt <mstaudt@...omium.org>
To:     Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Ricardo Ribalda <ribalda@...omium.org>,
        Yunke Cao <yunkec@...omium.org>,
        Tomasz Figa <tfiga@...omium.org>
Subject: Re: [PATCH v1] media: vivid: Add webcam parameter for (un)limited
 bandwidth

On 4/11/23 16:45, Hans Verkuil wrote:
>> Do I understand you correctly, are you suggesting to simply update the FPS limits to a new fixed schema, and not have an option at all?
> 
> Correct.
> 
> The ideal solution is indeed proper bandwidth calculations, since this would
> be a proper emulation of actual webcam hardware. If you have time and are
> interested in doing the work, then that would be great, of course.

My patch suggestion is motivated by a test which expects higher FPS 
rates at large frame sizes than vivid currently provides.

If I have a choice, then let's keep this patch simple ;)


> But if you just want to increase the fps limits to be more in line with
> modern webcams, then that's much quicker and should be fine.
> 
> It might also be interesting to perhaps allow for 120 fps for the low
> resolutions (below 720p).

Coincidentally, this would solve the problem we have at hand, but only 
until someone wants to see even higher frame rates, and then we'd 
revisit today's thread. Hence the idea for a parameter to simply unlock 
all rates, depending on whether a test needs a vivid webcam with low or 
high "performance".


My rationale behind the module parameter is twofold:

1. To allow for higher FPS without touching the kernel code again.
2. To stay backward compatible to previous behaviour of vivid. Changing 
the FPS formula would break this.


Actually I have a new idea: How about renaming my suggestion to 
"webcam_limit_enable" - this way, we can keep the current design with 
the boolean value: Not setting this value would default to "enabled" - 
i.e. vivid behaves as before. Disabling the limit unlocks all FPS at all 
sizes.

And later, should the need for a more precise simulation arise, we can 
add a second parameter "webcam_limit_value".

I've removed the "bandwidth" word from the new suggestions, so if a 
numeric limit is introduced, it can be anything, even an arbitrary 
number like the current "remove 2 FPS rates per size".


Please let me know what you think.

Max

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ