From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D066C64EB1 for ; Fri, 7 Dec 2018 09:33:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0B1AC20989 for ; Fri, 7 Dec 2018 09:33:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="flVRg0VT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B1AC20989 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726094AbeLGJdQ (ORCPT ); Fri, 7 Dec 2018 04:33:16 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:34821 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbeLGJdO (ORCPT ); Fri, 7 Dec 2018 04:33:14 -0500 Received: by mail-wm1-f65.google.com with SMTP id c126so3801333wmh.0 for ; Fri, 07 Dec 2018 01:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eMnf6ldCLzSIFExqElBpBbrF0a80ehzcW+zL1qWkQFI=; b=flVRg0VT8rf773axgJskOt6mEUkNuIav3OWtUev+VR6+9kCUHhD3g3pj0/HTPpnT3z bBhTTWDmGD5vM9g2SvRc1ZoQfTrTf92V4niKulYBCp7xqRVQ2IH3L2zlAcpCB/Y8j/V3 AiIv7yEWETnT1S3aSofPvO3rg11PapadoELmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eMnf6ldCLzSIFExqElBpBbrF0a80ehzcW+zL1qWkQFI=; b=aucNZZgIczPmyxr4A/J93nCE7t8fdBRScOZD1T1tFMwKPBb9cVK+4JPq40NpVWKek1 kKRkCw9fbV8Jb+20vcy1u6XUR2hi2hDQImI9gw3oOgHi6YhjeL5yKvVWLqGtz8jyTYTB e4sEdUsCSM86Wo6Z2Xg5Ay1TxZL+glm9WOLDFx3te8+9Cj/SsdDw1ZSVosuBs4eFAM40 o5tLY/Pjg2RGgXN+iippgxwsOzgwJADAOcCVGelrFyx0bSjMJYfxnShorPx+BRktRemH o/3jXHrxnCQhsjMF/6VSyAMZ/2HDf91vj2vjCFG7Y/Co1BWT387ArzfbjLPmi6UJ52hp lcaw== X-Gm-Message-State: AA+aEWYtMYudM1nsUN8LAZsusM8LKRdIHsZLRnbBwfwMYjw4YM6OZwhD XutK9wdujE5NZNXPaKOMP4a+Rw== X-Google-Smtp-Source: AFSGD/V8LYViCHAWSFzE+x9aAPgqaVHDnxTvmIm+FgCPVAuapeKQs8FRRTpoXcQsMPx9wkPNtG8gNQ== X-Received: by 2002:a1c:b94b:: with SMTP id j72mr1534084wmf.11.1544175192459; Fri, 07 Dec 2018 01:33:12 -0800 (PST) Received: from [192.168.27.209] ([37.157.136.206]) by smtp.googlemail.com with ESMTPSA id z12sm3528581wrh.35.2018.12.07.01.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 01:33:11 -0800 (PST) Subject: Re: [PATCH v3] media: venus: add support for key frame To: Tomasz Figa , mgottam@codeaurora.org Cc: Stanimir Varbanov , Hans Verkuil , Mauro Carvalho Chehab , Linux Media Mailing List , Linux Kernel Mailing List , linux-arm-msm , Alexandre Courbot , vgarodia@codeaurora.org References: <1541163476-23249-1-git-send-email-mgottam@codeaurora.org> <4767b56f-420b-dc0c-0ae9-44dbf6dcd0b1@linaro.org> <6d765e0d7d6b873e087a3db823cb1b29@codeaurora.org> From: Stanimir Varbanov Message-ID: <0e0cef43-0747-295f-0eef-3e52dc538523@linaro.org> Date: Fri, 7 Dec 2018 11:33:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans, On 11/29/18 9:40 PM, Tomasz Figa wrote: > On Thu, Nov 29, 2018 at 3:10 AM wrote: >> >> >> Hi Stan, >> >> On 2018-11-29 16:01, Stanimir Varbanov wrote: >>> Hi Tomasz, >>> >>> On 11/3/18 5:01 AM, Tomasz Figa wrote: >>>> Hi Malathi, >>>> >>>> On Fri, Nov 2, 2018 at 9:58 PM Malathi Gottam >>>> wrote: >>>>> >>>>> When client requests for a keyframe, set the property >>>>> to hardware to generate the sync frame. >>>>> >>>>> Signed-off-by: Malathi Gottam >>>>> --- >>>>> drivers/media/platform/qcom/venus/venc_ctrls.c | 20 >>>>> +++++++++++++++++++- >>>>> 1 file changed, 19 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c >>>>> b/drivers/media/platform/qcom/venus/venc_ctrls.c >>>>> index 45910172..59fe7fc 100644 >>>>> --- a/drivers/media/platform/qcom/venus/venc_ctrls.c >>>>> +++ b/drivers/media/platform/qcom/venus/venc_ctrls.c >>>>> @@ -79,8 +79,10 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl) >>>>> { >>>>> struct venus_inst *inst = ctrl_to_inst(ctrl); >>>>> struct venc_controls *ctr = &inst->controls.enc; >>>>> + struct hfi_enable en = { .enable = 1 }; >>>>> u32 bframes; >>>>> int ret; >>>>> + u32 ptype; >>>>> >>>>> switch (ctrl->id) { >>>>> case V4L2_CID_MPEG_VIDEO_BITRATE_MODE: >>>>> @@ -173,6 +175,19 @@ static int venc_op_s_ctrl(struct v4l2_ctrl >>>>> *ctrl) >>>>> >>>>> ctr->num_b_frames = bframes; >>>>> break; >>>>> + case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME: >>>>> + mutex_lock(&inst->lock); >>>>> + if (inst->streamon_out && inst->streamon_cap) { >>>> >>>> We had a discussion on this in v2. I don't remember seeing any >>>> conclusion. >>>> >>>> Obviously the hardware should generate a keyframe naturally when the >>>> CAPTURE streaming starts, which is where the encoding starts, but the >>>> state of the OUTPUT queue should not affect this. >>>> >>>> The application is free to stop and start streaming on the OUTPUT >>>> queue as it goes and it shouldn't imply any side effects in the >>>> encoded bitstream (e.g. a keyframe inserted). So: >>>> - a sequence of STREAMOFF(OUTPUT), >>>> S_CTRL(V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME), STREAMON(OUTPUT) should >>>> explicitly generate a keyframe, >>> >>> I agree with you, but presently we don't follow strictly the stateful >>> encoder spec. In this spirit I think proposed patch is applicable to >>> the >>> current state of the encoder driver, and your comment should be >>> addressed in the follow-up patches where we have to re-factor a bit >>> start/stop_streaming according to the encoder documentation. >>> >>> But until then we have to get that patch. >> >> So I can see that this patch is good implementation of forcing sync >> frame >> under current encoder state. >> >> Can you please ack the same. > > Okay, assuming that when you start streaming you naturally get a > keyframe, I'm okay with this patch, since it actually fixes the > missing key frame request, so from the general encoder interface point > of view: > > Acked-by: Tomasz Figa Thanks Tomasz! Acked-by: Stanimir Varbanov -- regards, Stan