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 E09F4488D6 for ; Sun, 21 Jan 2024 19:30:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9877568CF59; Sun, 21 Jan 2024 21:30:02 +0200 (EET) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 51FB068AF3B for ; Sun, 21 Jan 2024 21:29:56 +0200 (EET) Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6da9c834646so2492642b3a.3 for ; Sun, 21 Jan 2024 11:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705865393; x=1706470193; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NrYxa4uTfMWeMlxQWxVxtxkgt/JW8Ae4cumqQMWWE6Y=; b=WYTbSr6i/LvSVxUdtGuT/Y33RODMIOOr+G7t6WKsUZwlQnn/dpz0q7bpi2PO/zUYWi oZLdG21k6XQdyPAcmqal51lHxd1LkQRXciO1TEQL1KzcTGTvvCdVOWOunz2FAsk0JZJZ JbAK6MrBR0zcEj8S7i0dwUFHUvoBr1MaGDRftMnc6wfVxOCxomAIWHYhy/C+TedZQ2LF a5Z6tI2ctI+wbj6lt2suf918XeAVa1z6BYf0uVIAHL0JlFBqLg1O94m/8VK65ibXljAh M9TnjjeqBKPj3NvJ2BZrsBrrg0J/LL+pTo6ztPgcFqeykuVPEJ53PKLACobw4z7TBq9/ RNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705865393; x=1706470193; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NrYxa4uTfMWeMlxQWxVxtxkgt/JW8Ae4cumqQMWWE6Y=; b=ngDxNX6xrJf6xpu332LSBrjTyQRmSvi/YkOA/PBr/Vi40f7KAlLa423yyCYWIKF+CY Z/GSAGUiesWdJ5trVHOyL9bDoH763jcISjJya1/4/Ht7ha3O8YhCg7f1F0wX8PYiUxGr rA8uth7hWeMtmXIJDZ5eU1wA04+eB7kUVW2RfXkbC0O5sRXwgZ29LK62ckNSbSYJju7F lB7QwjwB8BLuBg2jUgQkmLCX4g0J7ArVS8GaDXXTR1sg4t0cDsTjUgHqZqpBRzMZ+4n2 M1rq6RVGXpa3dknmMZdRzQlyU3orDrBzkBI27Vq9IUD/aZVO7wj/rIL9cKac809oSraT wbRw== X-Gm-Message-State: AOJu0YzZ28SzYz3+k8oYjvMB4cdxAGJRst74MNcMjOdLImu98a6ovtWp SFGq91sFbEkI/ImSi6dlt1HpQFvmBK0jThXkO2UAUKR9Nijt2NCIDmJOFPpG X-Google-Smtp-Source: AGHT+IEUf7cVGOvYJbdrbAz9INuLofCQvvz9jhl7oTqcrOw5H12kPwVgrv6qNvzxUfkmgyvWK78wzA== X-Received: by 2002:a05:6a00:3c8e:b0:6db:db8a:93e7 with SMTP id lm14-20020a056a003c8e00b006dbdb8a93e7mr1955625pfb.64.1705865393076; Sun, 21 Jan 2024 11:29:53 -0800 (PST) Received: from [192.168.0.18] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id b7-20020aa78107000000b006dbd9501028sm1419015pfi.92.2024.01.21.11.29.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jan 2024 11:29:52 -0800 (PST) Message-ID: <8bd854a2-b10d-479b-8a21-0e2f506db08b@gmail.com> Date: Sun, 21 Jan 2024 16:29:58 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org 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> <170586374871.8914.17185524253768248293@lain.khirnov.net> From: James Almer Autocrypt: addr=jamrial@gmail.com; keydata= xsBNBFjZtqABCADLW+vdEoZaJZDsIO6geYFTOcn1unsEHefj9zn+3oTHlDFFzO47mzHsSfbK 9JE2xpOJEVnC8FAF5Sayi/pVwV+mtQUV3n5dgVeVBYF9GUQwOGFCpK8X54RRqhkgknbunOEE 0CtgAJgmpFmmmHgq02GvEspx1h/rh4apqwQR6QX4Favb+x9+i9ytVpwVcBX94vo2toyP7h/K BWfadQmb8ltgE1kshfg+SQs/H5bTV5Z1DuEASf02ZL/1qYB/sdTgWPLv9XMUHHsRFmMY8TMx wJSkP+Af3AiYQPJYz1B1D4tt98T/NoiVdin10zATakPjV8hXaobuRmxgakkUASXudydDABEB AAHNH0phbWVzIEFsbWVyIDxqYW1yaWFsQGdtYWlsLmNvbT7CwJIEEwEIADwCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAFiEEd1EujP2UoWlX5pp6FGMBrXN2WeAFAmJoLUUCGQEACgkQ FGMBrXN2WeAFVQf9GtGhniRs1PzNUOgJktCnv6j4BbLieaIPYPEFXKDHOgjqQE2zVMYXnoXl Jam928ii902a8OY06r9ywn/R8ApD1/3NY/v64O71CY9scz5XyH2au8wIZ6HwFy3/f7sqjdGD uctY8Qs7rjT7NkoC5lmgMu2v2k03dGtM9AAf5AK5gU+H0EUw7vmKKiXzUqt5kvBuf4CEwXvH AQT1SMJ52rIlDWB7FQFyZeUbOAK2IgY/KNedfK6nsgd/eQVnlofPd2XoddE7kP6iys7jJefw DD3g3rZyDTq7in5dyk5glaNpWZpbHGBs+9SCYLnfQ8XvWqPFOD+gj0plamKANgOvavKTxM7A TQRY2bagAQgA69YtILj8kYxmqPr/M8+MXT7wVoOWVW9lvSmPquCELaDy/NIS7D06VC5EuE/6 JlJXZMTn37NLlyWhzwOgXuXw5w2tyoQQBuvqGiXJijuXwXH7HKdzrc6rpYtAqt5w05hzNrFS KrS0izG64VpWrfproy3BsL+8TBm9brLhhNPynVRqVukbbGzlATTzNQGZ14TTi2/dL6DkMQnM qn4jX9UEe4GdGQBP50bUJSSmeiIkyNLWA+znuN2PZEz930ZwNrF9GtDVw7mzcmpCZ7spldE2 tutbpy9D1bIqxyqBrYDSezyzL2adR1qgHyOTMCHg2AYNkrIQHrSyJxKTpZ1/hqOp8wARAQAB wsBfBBgBAgAJBQJY2bagAhsMAAoJEBRjAa1zdlnghekH/0Yb0iYJ74oID2f/Fj+AJKS2ekQF P2xOr8lpGzgp/+yWUvPtqbX0A33anBJdYwxaAC0NataX3tfZ+oJkzXqfmqhIHMPYHdZesJA2 Bk9hU/33mDl5s5U66/z0uelWzwKVHoQ2O6or4+qF3HJFSJLCe9uvWJ3zXf9F342Ftj73sfx+ 3xkw/IXsN1RqbYqDlzpoEQ99SIEfY/8Jjwnd3sIPfqkuyeaYfe6GJDqKawdCEP1oRRlbXEAp TJgYz8r3nPhGv9cdHNDCk44ISbsqVuxIEnLqi4fTPZaGupiQhT+srl268TTAp2TQW7+6Ce/b NPQorMquzS/LZoyALpmsYi/miMc= In-Reply-To: <170586374871.8914.17185524253768248293@lain.khirnov.net> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 1/21/2024 4:02 PM, Anton Khirnov wrote: > 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. Because once we support container cropping, we will be defining a stream/packet side data type that will contain a subset of the fields from this struct. If we reuse this struct, we can export a clap box as an AVTileGrid (Or i can rename it to AVImageGrid, and tile to subrectangle) either as the stream group tile grid specific parameters if HEIF, or as stream side data otherwise. > >>> >>>> 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. Well, the variable type supports a list of N rectangles where each rectangle has arbitrary dimensions, and you can do things like having three tiles/rectangles that together still form a rectangle, while defining row and column count. So i don't personally see the need for a new type to begin with. > > 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). > _______________________________________________ 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".