Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp5130019rwl; Tue, 11 Apr 2023 00:30:04 -0700 (PDT) X-Google-Smtp-Source: AKy350ZjXMJtN6Ezq318GbKZigx+RclZd274Mfi4UIm2Ym9NbTMUs//OVJSEm55EgKGWEaDZu5jR X-Received: by 2002:a62:5e85:0:b0:63a:65a9:10db with SMTP id s127-20020a625e85000000b0063a65a910dbmr3786252pfb.7.1681198204182; Tue, 11 Apr 2023 00:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681198204; cv=none; d=google.com; s=arc-20160816; b=KTEzO3rFioCmDThMOzzgZ5QR5GydeyEzRsAHLjgveTd6Va8Hscl3GbWvTZOzp2dl7h dnAz7yH7eZEEfmuof78fczj5mHeh66WdDyat8A8nW1cJ7gfqW5Gn5BWgV8Q+3Cs2IsOJ OBCwL7M3+ROA+r2TB5pqvTFX10jrJ63+NDefhYX1iL0ajrV4FhwbaA7uGx/BJWLZ1tID 5vA7y0S30X/wA2njlfXMzEXaZrKHiPqdfOpzou0eprGDM1nTFau2UQL0AyHmvdu1Zau+ 0TMscD22N/Phq88hHhBZXCOqtO8wvL2tz7VMKAtiyDpuBEBltLPatX95TX7xKQi50TQH qP+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=uQEExTNnaSDAflqtvZtvYcqsJmtNPx9MWT0ScJohvUw=; b=F8Tk422799j66gPwie8R5tcbBghRRsSbHoAKPJ7QRcAp3Wrq8nfhqafilSXzExKDR4 6BpG3yI6JkhESxVN7JCU8gJJiMKWTGMqoAbA/R6yLfUkiXJYNvpvM91UyyRKGyETcki+ F3C3brsiZ4FG2kRi+qOrW2dgb/uJuZ/Ucy5yRVVLOZd6fY81OIPXN0IwSG3fSCZrjF9I 3yMo5FPT+fgo5piFcjkF3qdTAhD7DGmYfZzMzjL4MbSD3f/+kS2NNB7LNbhl+xGvh+8B A6utAx7HHY+vqV+sLbZyeT/yRiocisbzFmGZ8hM/R99QblhuqTPzDxyVYjoSVqHqH+Tf Mvaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 79-20020a630252000000b005145fbb2dcasi12180758pgc.780.2023.04.11.00.29.51; Tue, 11 Apr 2023 00:30:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229886AbjDKH0z (ORCPT + 99 others); Tue, 11 Apr 2023 03:26:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbjDKH0y (ORCPT ); Tue, 11 Apr 2023 03:26:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 496128E; Tue, 11 Apr 2023 00:26:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D73EB6113B; Tue, 11 Apr 2023 07:26:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 039D7C433EF; Tue, 11 Apr 2023 07:26:49 +0000 (UTC) Message-ID: <6ee01cf1-5a8b-081f-e218-8c7da39343bc@xs4all.nl> Date: Tue, 11 Apr 2023 09:26:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v1] media: vivid: Add webcam parameter for (un)limited bandwidth Content-Language: en-US To: Max Staudt , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Ricardo Ribalda , Yunke Cao , Tomasz Figa References: <20230410063356.3894767-1-mstaudt@chromium.org> <20230410102350.382f7d02@sal.lan> <6aafad18-13a2-ef45-48a1-1f094554af31@chromium.org> From: Hans Verkuil In-Reply-To: <6aafad18-13a2-ef45-48a1-1f094554af31@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/04/2023 08:51, Max Staudt wrote: > Thank you Mauro for having a first look! > > Questions below. > > > On 4/10/23 18:23, Mauro Carvalho Chehab wrote: >> IMO, instead of a parameter that just enables/disables the bandwidth >> limit, the best would be to have a parameter specifying the bandwidth >> (with 0 meaning unlimited). >> >> If not used, vivid would initialize it to dev->webcam_bandwidth_limit, >> so a read operation will show the current limit. > Up until now, the bandwidth limit is a rather arbitrary reduction of two interval sizes per frame size. > > How would you prefer to define a limited bandwidth in this parameter? How would it affect the simulated camera, do you have a suggestion for a formula from bandwidth to frame/interval sizes offered? > > >>> +/* Default: limited webcam bandwidth */ >>> +static bool webcam_bandwidth_limit[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] = true }; >>> +module_param_array(webcam_bandwidth_limit, bool, NULL, 0444); >> >> I would also use 0666, to allow changing this on runtime. > > I guess that's possible, though it would add complexity. > > Currently we can ask for two instances, each with a different setting: > >   n_devs=2 webcam_bandwidth_limit=1,0 > > This creates /dev/video0 which is limited, and /dev/video4 which is unlimited. > > Maybe this already sufficiently covers the case you are looking for, and we can keep the complexity low? A real webcam won't suddenly offer new frame rates either... I think we either use this bandwidth option and calculate the max fps based on that (basically the bandwidth divided by (image_size + some blanking factor)), or we keep it simple and instead of going down two steps in fps we allow up to 60 fps up to 720p, then 30 fps for 1080p and 15 fps for 4k. The fps values currently used are a bit outdated w.r.t. modern webcams, so upgrading it wouldn't hurt. And this is a lot simpler than doing bandwidth calculations. Regards, Hans