Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3872461imm; Mon, 8 Oct 2018 10:54:05 -0700 (PDT) X-Google-Smtp-Source: ACcGV62gZtniVuQqgSnGAc6A6FjO33USuotHgr1PiXubH+qoqDWiUGWeXJuLZeY3sHpcBhn/lUpR X-Received: by 2002:a62:86c6:: with SMTP id x189-v6mr27100455pfd.252.1539021245890; Mon, 08 Oct 2018 10:54:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539021245; cv=none; d=google.com; s=arc-20160816; b=ukL0xZzf1P90DFPqOuvsz0XhOjWlE1MY0vTKIbVJ0aMH4he1mQ6Kww17h6o06yw0Fq FHb1WlFLNE+r2/6vNsbjte8GlmiIz+v3BAXcrePmThi/r8174rbxUSpaFIkg5Bt4PbHy OQf1pqiStkAjJnNCpxQUV7Sv4/k5Fwd3bj+3XbYNfFFkmVgOvCwJuPgQ1Gd/BFHUuyKG D6gxv+PN/Ubw9JCUsS6EEZpBRtXrov2lYtPpoQ1N7GT+LBxM86EFK9N7xSyqzFfCtB24 3eaGzLizH8BgbOzvjbXtYpP5THd/w02Oq0jmWdPC6uVF3faD/1N3srIeS/1UBL6QiuYm XFhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=F0To5NUumwUhMP20jr4+y0B/OTZtUzJWFV6h9Xkch9c=; b=dq6O3Zqfj6dhAQJVLMW1tsS6EJM9EZsP9KoKSE74CCq5m21ZKoAwesWej0qwKnCxGV S1cMiMgyYHEdlwj2ocdxl0sLkP4MAKDOppwBVF5cdxGp1x7emEdaRPzFHTaYATLQ513B yw4A19GLWD++SrkBb1tWmGklPfOt5lW3UjkmGRWxJhJTCV7eIZilyYim3gG8JGPH0U4H Md5OcxtHOTRUuOe7SuHerwpAKu6e5s/OaXhtC27W/2jvLFcg0RT6Djo/xwLkKqkV7Rf7 7csJZ/tv4TKkcwSuValjM6yym60axuCmXZqj9XmUjOfANL9rivNvaLO3J4xL/h+onRHp 3iXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f62-v6si9809662plf.288.2018.10.08.10.53.50; Mon, 08 Oct 2018 10:54:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726445AbeJIBGf (ORCPT + 99 others); Mon, 8 Oct 2018 21:06:35 -0400 Received: from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:49259 "EHLO lb3-smtp-cloud8.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbeJIBGf (ORCPT ); Mon, 8 Oct 2018 21:06:35 -0400 Received: from [192.168.2.10] ([212.251.195.8]) by smtp-cloud8.xs4all.net with ESMTPA id 9Zisgnxsk0ZZE9Zivg8EIq; Mon, 08 Oct 2018 19:53:42 +0200 Subject: Re: [PATCH] media: vivid: Support 480p for webcam capture To: Mauro Carvalho Chehab , Kieran Bingham Cc: Keiichi Watanabe , linux-media@vger.kernel.org, Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, tfiga@chromium.org, jcliang@chromium.org, shik@chromium.org References: <20181003070656.193854-1-keiichiw@chromium.org> <20181008140302.2239633f@coco.lan> From: Hans Verkuil Message-ID: <00b0a8af-b7a5-cb49-0684-0fd0efefa196@xs4all.nl> Date: Mon, 8 Oct 2018 19:53:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20181008140302.2239633f@coco.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAVRnZeufrN9NlqaKtWsHVobHqgseGij+kS7+NmKCuiCnp0l2xvYKk4+ccWSGOAFux0mNFxNu+6F+RCoNstbB9jd7jkd46DFhSl6k/pQgvhUa6QggwrV vWlQi3QaY/tEn0XGpsyGyikPJC2+XQpJs3LdodAForFVmHKmWLnBxuTs1R/6ENTrZ3e8Lq14jPce00Blg4E9sEX9xBAjsp3+z72tGPhr4tGIxpVRCdg5Dzmx 8O4wgT0p4r8Rf8C09txfUoB/C0lW7AWoUNLUg29HYZ0R7LNCpJqhIw0B9552rtJbixeZh5m/r+vqEgFPGA/3e57tfqGgLp09Lw3TZ6UrYm5wtHZRIzm4bRxR ZuirzISclLZqNkkiRzk8VTff8Ic90y1QuAzPL/+Bj+WiFPhnHyTVXRK0iOS1KHej1FPAUIjAKinYEhovP1kHPAPC7Lm5gPY/sGJoK75LBhtlvHVivpw= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/08/2018 07:03 PM, Mauro Carvalho Chehab wrote: > Em Wed, 3 Oct 2018 12:14:22 +0100 > Kieran Bingham escreveu: > >>> @@ -75,6 +76,8 @@ static const struct v4l2_fract webcam_intervals[VIVID_WEBCAM_IVALS] = { >>> { 1, 5 }, >>> { 1, 10 }, >>> { 1, 15 }, >>> + { 1, 15 }, >>> + { 1, 25 }, > > As the code requires that VIVID_WEBCAM_IVALS would be twice the number > of resolutions, I understand why you're doing that. > >> But won't this add duplicates of 25 and 15 FPS to all the frame sizes >> smaller than 1280,720 ? Or are they filtered out? > > However, I agree with Kieran: looking at the code, it sounds to me that > it will indeed duplicate 1/15 and 1/25 intervals. Oops, I missed this comment. Yes, you'll get duplicates which should be avoided. > > I suggest add two other intervals there, like: > 12.5 fps and 29.995 fps, e. g.: 29.995 is never used by webcams. > > static const struct v4l2_fract webcam_intervals[VIVID_WEBCAM_IVALS] = { > { 1, 1 }, > { 1, 2 }, > { 1, 4 }, > { 1, 5 }, > { 1, 10 }, > { 1, 15 }, > { 2, 50 }, > { 1, 25 }, > { 1, 30 }, > { 1, 40 }, > { 1, 50 }, > { 1001, 30000 }, > { 1, 60 }, > }; > > Provided, of course, that vivid would support producing images > at fractional rate. I didn't check. If not, then simply add > 1/20 and 1/40. vivid can do fractional rates (it does support this for the TV input), but 29.995 makes no sense for a webcam. So 1/20 and 1/40 seems the right approach. > >> Now the difficulty is adding smaller frame rates (like 1,1, 1,2) would >> effect/reduce the output rates of the larger frame sizes, so how about >> adding some high rate support (any two from 1/{60,75,90,100,120}) instead? > > Last week, I got a crash with vivid running at 30 fps, while running an > event's race code, on a i7core (there, the code was switching all video > controls while subscribing/unsubscribing events). The same code worked > with lower fps. If you have a stack trace, then let me know. > While I didn't have time to debug it yet, I suspect that it has to do > with the time spent to produce a frame on vivid. So, while it would be > nice to have high rate support, I'm not sure if this is doable. It may, > but perhaps we need to disable some possible video output formats, as some > types may consume more time to build frames. In the end that depends on the CPU and what else is running. You'll know quickly enough if the CPU isn't fast enough to support a format. Although it shouldn't crash, of course. Regards, Hans