From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 2237E477C3 for ; Sun, 21 Jan 2024 17:29:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BAD2A68CF01; Sun, 21 Jan 2024 19:29:28 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9296F68CCC1 for ; Sun, 21 Jan 2024 19:29:21 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=qHg13yVN; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 4116D2405F2 for ; Sun, 21 Jan 2024 18:29:21 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id nprzAT2xAWLb for ; Sun, 21 Jan 2024 18:29:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1705858160; bh=NKQCpt4HuBd4FokhKvn9xzMW4wonQsz1wq29nVDQIZc=; h=Subject:From:To:In-Reply-To:References:Date:From; b=qHg13yVNhxsIg19/EbiuytOEWnr16sU1U21mgjiQOTsWxZiET2EQJRAOBFFa1dIoK NNuewr/w20bCLt+MgT3axEg/1X90NL0eO3z2psxrnMfYEIKchWiWqbJeajvLuYlhdG F0+7mcu1HiGsrBLwvpkIAfFDNvl40a+GSPzxGj1NH/HxR6kz7VyiQ2XyhmtOPNvOp8 sSZrRW2DGjgGnEsSWmTEbXmWq9aICuCDnb4J2JD+42E9lnOKot4Ygd5yRhJILuGyIJ CPs2/DgVAAjOp/mdLnZr1QdzxoBG9QYu1ypLuX2Hp+Tg2DseLqTKApRseUGKl/oe30 gZsFXgUH1CEwQ== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 531FB2404E5 for ; Sun, 21 Jan 2024 18:29:20 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 33C1D1601B9; Sun, 21 Jan 2024 18:29:20 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20240120220407.64141-1-jamrial@gmail.com> <170581842075.8914.15090755160718905890@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Sun, 21 Jan 2024 18:29:20 +0100 Message-ID: <170585816018.8914.1005492749396712320@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2 v2] avutil: add a Tile Grid API X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting James Almer (2024-01-21 13:06:28) > On 1/21/2024 3:27 AM, Anton Khirnov wrote: > > Quoting James Almer (2024-01-20 23:04:06) > >> This includes a struct and helpers. It will be used to support container level > >> cropping and tiled image formats, but should be generic enough for general > >> usage. > >> > >> Signed-off-by: James Almer > >> --- > >> Extended to include fields used for cropping. Should make the struct reusable > >> even for non tiled images, e.g. setting both rows and tiles to 1, in which case > >> tile width and height would become analogous to coded_{witdh,height}. > > > > But why? What does cropping have to do with tiling? What advantage is > > there to handling them in one struct? > > The struct does not need to be used for non tiled image scenarios, but > could if we decide we don't want to add another struct that would only > contain a subset of the fields present here. > > As to why said fields here present here, HEIF may use a clap box to > define cropping for the final image, not for the tiles. This needs to be > propagated, and the previous version of this API, which only defined > cropping from right and bottom edges if output dimensions were smaller > than the grid (standard case for tiled heif with no clap box), was not > enough. Hence this change. > > I can rename this struct to Image Grid or something else, which might > make it feel less awkward if we decide to reuse it. We still need to > propagate container cropping from clap boxes and from Matroska elements > after all. Honestly this whole new API strikes me as massively overthinking it. All you should need to describe an arbitrary partition of an image into sub-rectangles is an array of (x, y, width, height). Instead you're proposing a new public header, struct, three functions, multiple "tile types", and if I'm not mistaken it still cannot describe an arbitrary partitioning. Plus it's in libavutil for some reason, even though libavformat seems to be the only intended user. Is all this complexity really warranted? -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".