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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no 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 0B637C433B4 for ; Sat, 3 Apr 2021 17:18:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D467A611AF for ; Sat, 3 Apr 2021 17:18:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236906AbhDCRSJ (ORCPT ); Sat, 3 Apr 2021 13:18:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236364AbhDCRSI (ORCPT ); Sat, 3 Apr 2021 13:18:08 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 948FCC0613E6; Sat, 3 Apr 2021 10:18:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 9018F1F457AA Message-ID: <59328f10f03f9bf20ba0d1fbc2b4e7657e782c92.camel@collabora.com> Subject: Re: [PATCH v4 1/9] media: uapi: mpeg2: Rework quantization matrices semantics From: Ezequiel Garcia To: Nicolas Dufresne , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Cc: kernel@collabora.com, Jonas Karlman , Hans Verkuil , Philipp Zabel , Maxime Ripard , Paul Kocialkowski , Jernej Skrabec , Daniel Almeida Date: Sat, 03 Apr 2021 14:17:49 -0300 In-Reply-To: <6488f83a1a46c43991d239137c26c40817b3e459.camel@collabora.com> References: <20210329181329.48006-1-ezequiel@collabora.com> <20210329181329.48006-2-ezequiel@collabora.com> <6488f83a1a46c43991d239137c26c40817b3e459.camel@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nicolas, On Mon, 2021-03-29 at 16:53 -0400, Nicolas Dufresne wrote: > Le lundi 29 mars 2021 à 15:13 -0300, Ezequiel Garcia a écrit : > > As stated in the MPEG-2 specification, section 6.3.7 "Quant matrix > > extension": > > > >   Each quantisation matrix has a default set of values. When a > >   sequence_header_code is decoded all matrices shall be reset to > >   their default values. User defined matrices may be downloaded > >   and this can occur in a sequence_header() or in a > >   quant_matrix_extension(). > > > > The load_intra_quantiser_matrix syntax elements are transmitted > > in the bistream headers, signalling that a quantization matrix >                                              quantisation > > Not really a typo, just a suggestion to follow the specification spelling. I > would like to see concistant spelling the API. My rational is that you can copy > and paste the strings when searching inside the specification PDF, and you don't > mix both in the API like we do now. > Absolutely. Thanks for spotting this. > > needs to be loaded and used for pictures transmitted afterwards > > (until the matrices are reset). > > > > These "load" semantics are implemented in the V4L2 interface > > without the need of any "load" flags: passing the control > > is effectively a load. > > > > Therefore, rework the V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION >                                                         S > > > semantics to match the MPEG-2 semantics. Quantization matrices >                                                  s > > etc. > > > values are now initialized by the V4L2 control core to their > > reset default value, and applications are expected to reset > > their values as specified. > > > > The quantization control is therefore optional, and used to > > load bitstream-defined values in the quantization matrices. > > Perhaps: > > "The quantisation controls is therefore optional for decoding streams that uses > the default matrices." > > A stack that would not handle the default, would have to read the control at > least once in order to avoid overriding valid values with 0s, not sure if that > is worth mentioning ? > Hm, not entirely sure. If application calls S_EXT_CTRL with 0s, then that's what will happen. Thanks, Ezequiel