Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2758268pxj; Mon, 14 Jun 2021 06:35:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyIxB8mgwhjpSBuOklkD6H4FDosr+qE6FSrtPUKjTI/YcmeED43QzRZ0vptOqV6ZqvU1Qk0 X-Received: by 2002:a17:906:994d:: with SMTP id zm13mr14843346ejb.427.1623677702859; Mon, 14 Jun 2021 06:35:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623677702; cv=none; d=google.com; s=arc-20160816; b=SuWVs2POL/6I56trpbDcCScv1XtEjK8PgrurxUODYgu42Qv4do8ep+m2og9kYSxiD+ BnHQIxkks0GME5wsFvD8VnRxYt3/lP2BTFcaAJTC/YZee/GpJlshgLY9eKSYXbKeBSij dT6zZgGlG1TDz1095zxgBgmqRZ4TSwvBJmt3POLS9YppGkP1NeH2yQ/lzFgBZofFgwcF FE8Feu4gXk4ZLoO1S1tPWy0omuSQW9t1wZD6qRhExF3tkbUmddwNoSI5XbllfE1duRXW gluN3gimMR/6Z/QUBlCHLQlZtJJ2fUQpovsQGjNvNoaSCdP+qGR+Gf18oQprsOCvWdLc h0eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=cAUqeEpvWCkYWomZHT8Du/PXR9Hb0hXmraoq1aYdJeI=; b=n2RnWeSlG+2fFvOjfMGbipJKEgreId5DefaSeJkBBu288vc8lBLTO6WSHTaIl2S0LR chopKjl+su9SiZm8yoY2adpatw3sYqsadinHYDQUXtH3v7mEMOUKZDi3lAWckHXsOmTg izqqzs6qV4KluXBCtgzymofjxs+fZb1w80pDWT4lu1feHOnHxOwj7xokaxgU84KecFi+ rfQLonSghUzOr1/0VeeLjT3GmIwvJDncMbClb/Tl2Cz2cej7iImnJQKm8zeJFnk9AdBi kl/ypg3lz3WGZ263iYf3unX39+YtvsaJ888s6USmhhWAvMDby8OPJdJMvERnikRhgx8r Wi0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ndufresne-ca.20150623.gappssmtp.com header.s=20150623 header.b=pjAEL3Rk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id aq18si10866150ejc.117.2021.06.14.06.34.40; Mon, 14 Jun 2021 06:35:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ndufresne-ca.20150623.gappssmtp.com header.s=20150623 header.b=pjAEL3Rk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233767AbhFNNfg (ORCPT + 99 others); Mon, 14 Jun 2021 09:35:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233298AbhFNNfb (ORCPT ); Mon, 14 Jun 2021 09:35:31 -0400 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8151EC061574 for ; Mon, 14 Jun 2021 06:33:28 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id v6so8496876qta.9 for ; Mon, 14 Jun 2021 06:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=cAUqeEpvWCkYWomZHT8Du/PXR9Hb0hXmraoq1aYdJeI=; b=pjAEL3RklamT2ea9ks/JNUzw0Kpgv4zYuHuOL6SFc5mRQeVO99/7YT5gy5JVYZ4/Iw 3AYgtTRyl1fymKmlRu4eQBHOfx488ruY60Wjj4kvx4pVsdk6sY5WecqGPr+DTh2SniM1 7wtYNmPY26n5X7qrbIqj2ytr9thPyiS/f36pPdntQFodAYSKtWoB3OsjFCwaCLB6unXf jarKxmU45MHI5BRKbhBJKhXptH3nOlPGMx+ADeCmvHsLBAinbdSxfGZVG0ECRWHa6jMa Rbr8b9hb8uza+KYOedL9UhIQ9fBroWOPasYZ51WQgu5yp56+bnfeXN31/s6v9QMdZpoW zTRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=cAUqeEpvWCkYWomZHT8Du/PXR9Hb0hXmraoq1aYdJeI=; b=kYtn5dZDFjXlR6PDPVW+00xQG6DKciFxGdfeyXmeSs/WnRvfQrC3hNvLZewMhkYI22 GdSLWJ2F5xpnDChm98r2H6Xpky7DRMhq8Qn3q8Uq88ofUT2+P/I/Y8mT08f8+qn5OMDo +LWS2nJ2adsu6p/qXZKxK2sTk3hJLHGdwrnNk+FhB6KpuvpqmAsuRKJmeZXiej5UKFLt 4h1Fz84o/y0ylnunzPVuZMxArPhEe/hPBIqshp9Eq+UWLKkj1T5zXnXdk/PyGns380Gn jsAsUeyMxIQk3xynh4ekHGf6dYuSB/ajOJ8yjHPsW4oUFd0Ey8p00kkXuYsqpdoqJwqq ty4w== X-Gm-Message-State: AOAM5300/Bh6t2BlxF6LERmyOU3PabbqvkI4JHEJcMDb7jBknHWaeb+3 bg4fSjLFvfC5UkAgZBg7lRfIkQ== X-Received: by 2002:a05:622a:d1:: with SMTP id p17mr9570218qtw.141.1623677607558; Mon, 14 Jun 2021 06:33:27 -0700 (PDT) Received: from nicolas-tpx395.localdomain (173-246-12-168.qc.cable.ebox.net. [173.246.12.168]) by smtp.gmail.com with ESMTPSA id l6sm10217007qkk.117.2021.06.14.06.33.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 06:33:26 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2 7/8] media: hevc: Add scaling matrix control From: Nicolas Dufresne To: Ezequiel Garcia , Benjamin Gaignard , Hans Verkuil , p.zabel@pengutronix.de, mchehab@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, jernej.skrabec@siol.net, emil.l.velikov@gmail.com, andrzej.p@collabora.com, jc@kynesim.co.uk, jernej.skrabec@gmail.com Cc: kernel@pengutronix.de, linux-imx@nxp.com, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Mon, 14 Jun 2021 09:33:25 -0400 In-Reply-To: <96e63be705b04b40a943307c81ed71e8c573ef96.camel@collabora.com> References: <20210610154442.806107-1-benjamin.gaignard@collabora.com> <20210610154442.806107-8-benjamin.gaignard@collabora.com> <87a1e585-688e-7c4d-b9a9-24f42772a1a8@xs4all.nl> <96e63be705b04b40a943307c81ed71e8c573ef96.camel@collabora.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.1 (3.40.1-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le lundi 14 juin 2021 à 09:50 -0300, Ezequiel Garcia a écrit : > On Mon, 2021-06-14 at 09:43 +0200, Benjamin Gaignard wrote: > > > > Le 14/06/2021 à 09:27, Hans Verkuil a écrit : > > > On 10/06/2021 17:44, Benjamin Gaignard wrote: > > > > HEVC scaling lists are used for the scaling process for transform > > > > coefficients. > > > > V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED has to set when they are > > > > encoded in the bitstream. > > > Comparing H264 with HEVC I noticed that the corresponding flag for H264 is > > > called V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT. > > > > > > Should those names be aligned? Also, it is part of PPS for H264 and SPS in HEVC, > > > is that difference correct? > > > > In ITU specifications ("7.4.3.2.1 General sequence parameter set RBSP semantics") this flag is define like that: > > scaling_list_enabled_flag equal to 1 specifies that a scaling list is used for the scaling process for transform coefficients. > > scaling_list_enabled_flag equal to 0 specifies that scaling list is not used for the scaling process for transform coefficients. > > > > So for me the naming is correct. > > > > The bitstream is really parsed in userspace (gstreamer, ffmpeg, chromium). > Not all bitstream parameters need to be passed as-is, because the kernel > is actually a sort of low-level layer in the decoder stack. > > I think it's probably most appropriate to follow our H.264 interface > semantics, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54889c51b833d236228f983be16212fbe806bb89. > > The H.264 story goes like this: > > * Default scaling list is used for decoding, but can be modified > by a bitstream-provided scaling list. > > * The scaling list modification can be in SPS or in PPS. > > * For each frame, the SPS and PPS headers will tell if > a modified scaling list must be used for decoding, > and if it's provided in the SPS header or the PPS header. > > The userspace parser must take care of this, and pass > a scaling matrix to the kernel via V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX, > setting PPS_FLAG_SCALING_MATRIX_PRESENT. > > This flag is at the PPS control, so the scaling modification > can be applied on each frame. > > In other words, the kernel interface is simpler, it just > receives a scaling matrix and a flag telling if it must be used or not. > > We should probably clarify the documentation, so this process is more clear. > > From the HEVC spec, it seems the process should be similar. > The only difference is the SPS "scaling_list_enabled_flag" parameter, > which doesn't exist in H.264. > > Nicolas: what do you think? I believe its a fine "driver convenience". In the sense that the flag might not have been strictly needed, but may make the driver code simpler. Whenever possible, and within the spec, I'd agree to keep things as consistant as possible. From the doc, there seems to be a "default" or "flat" version of the scaling matrix in H264. I think if I had notice this before, I would have pushed forward the same semantic as the MPEG2 quantisation. In MPEG2, the quantisation control is set to it's default value in the control framework. What I like of this approach is that the control becomes always valid. Perhaps there is some differences here and there I'm not noticing though. Semantically, it would also be totally different if there is a HW fast path to the "flat" scaling matrix, in which case you need that flag to enable it. I think the fact one prepend SPS/PPS is simply to help locate the relevant part of the specification. > > Thanks, > Ezequiel >