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 7FA49488C8 for ; Sun, 21 Jan 2024 19:02:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AC90C68CF80; Sun, 21 Jan 2024 21:02:38 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CC518680B12 for ; Sun, 21 Jan 2024 21:02:31 +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=K4bex/H6; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 73C332405F2 for ; Sun, 21 Jan 2024 20:02:31 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id TxjblVykyqaO for ; Sun, 21 Jan 2024 20:02:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1705863748; bh=JyQ2T2LcJZE2omFOMq/kVXmj1zHV5sV8teuwp1uNvmU=; h=Subject:From:To:In-Reply-To:References:Date:From; b=K4bex/H6+P86NVNVZ+CYWTY1s3tIkLKfgeJQuQVWo5CC+x9vXRyskRPxPdE/VIZl9 CtxuKF/ngMDefoZYK9i0gLdCZviWozuOxF4uyvc+62AEH3H4ZcRoeD0hDaBprQ0fuP hvhwZ4fd0csdJs2s6D/1RUb6HqWAJT04ce0DNDzxa4ZEkXqsNaDU1Xcv7jwtUPjpOF SJoCRwhaRjhZjLuwDvRuy/TnuFQUQ4IgyctBeT89iLCBIFPXcshzbz610DnwxMZ2lr IlYzFJSob1pyVYq7hBn5/32gCoIQhFjPrUZqsLD5s5G9aKhnlgA9TJ9KtaVLy20wmB usvAy0QIN2ajA== 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 CD9A92404E5 for ; Sun, 21 Jan 2024 20:02:28 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id B4FE11601B9; Sun, 21 Jan 2024 20:02:28 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <071553d8-cde6-4c48-8633-e7fcc01a6b7a@gmail.com> References: <20240120220407.64141-1-jamrial@gmail.com> <170581842075.8914.15090755160718905890@lain.khirnov.net> <170585816018.8914.1005492749396712320@lain.khirnov.net> <5cabd1bb-f454-4e5c-8950-b2217fba5231@gmail.com> <170586174894.8914.16513575461875087750@lain.khirnov.net> <071553d8-cde6-4c48-8633-e7fcc01a6b7a@gmail.com> Mail-Followup-To: FFmpeg development discussions and patches Date: Sun, 21 Jan 2024 20:02:28 +0100 Message-ID: <170586374871.8914.17185524253768248293@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 19:38:50) > On 1/21/2024 3:29 PM, Anton Khirnov wrote: > > Quoting James Almer (2024-01-21 18:47:43) > >> On 1/21/2024 2:29 PM, Anton Khirnov wrote: > >>> 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? > >> > >> 1. It needs to be usable as a Stream Group type, so a struct is > >> required. Said struct needs an allocator unless we want to have its size > >> be part of the ABI. I can remove the free function, but then the caller > >> needs to manually free any internal data. > > > > If the struct lives in lavf and is always allocated as a part of > > AVStreamGroup then you don't need a public constructor/destructor and > > can still extend the struct. > > Yes, but that would be the case if it's only meant to be allocated by > AVStreamGroup and nothing else. That is the case right now, no? If that ever changes then the constructor can be added. > > > >> 2. We need tile dimensions (Width and height) plus row and column count, > >> which give you the final size of the grid, then offsets x and y to get > >> the actual image within the grid meant for presentation. > >> 3. I want to support uniform tiles as well as variable tile dimensions, > >> hence multiple tile types. The latter currently has no use case, but > >> eventually might. I can if you prefer not include said type at first, > >> but i want to keep the union in place so it and other extensions can be > >> added. > >> 4. It's in lavu because its meant to be generic. It can also be used to > >> transport tiling and cropping information as stream and packet side > >> data, which can't depend on something defined in lavf. > > > > When would you have tiling information associated with a specific > > stream? > > Can't think of an example for tiling, but i can for cropping. If you > insist on not reusing this for non-HEIF cropping usage in mp4/matroska, > then ok, I'll move it to lavf. I still don't see why should it be a good idea to use this struct for generic container cropping. It feels very much like a hammer in search of a nail. > > > >> And what do you mean with not supporting describing arbitrary > >> partitioning? Isn't that what variable tile dimensions achieve? > > > > IIUC your tiling scheme still assumes that the partitioning is by rows > > and columns. A completely generic partitioning could be irregular. > > A new tile type that doesn't define rows and columns can be added if > needed. But the current variable tile type can support things like grids > of two rows and two columns where the second row is effectively a single > tile, simply by setting the second tile in said row as having a width of 0. The problem I see here is that every consumer of this struct then has to explicitly support every type, and adding a new type requires updating all callers. This seems unnecessary when "list of N rectangles" covers all possible partitionings. That does not mean you actually have to store it that way - the struct could be a list of N rectangles logically, while actually being represented more efficiently (in the same way a channel layout is always logically a list of channels, even though it's often represented by an uint64 rather than a malloced array). -- 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".