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 D3293488ED for ; Sun, 21 Jan 2024 21:03:15 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0C27C68CACB; Sun, 21 Jan 2024 23:03:15 +0200 (EET) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E5EC268CACB for ; Sun, 21 Jan 2024 23:03:07 +0200 (EET) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-6dbd07916d0so1032799b3a.0 for ; Sun, 21 Jan 2024 13:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705870985; x=1706475785; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:autocrypt:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jnuAu48hLdY2NtgfoNoGoszrYUYCdCuWDWWYW1+4rwM=; b=fsSc8nXNjfLy1FVulIQz2thQsIGIriZBApgeAeWxq0LiknV3Q+shsrCSZdViTFqw72 b9s9SBnN8KlwY3xvRO7Wibd1Wm73xYgOQAiwU02sNSSbY/w3uNStIYdjopkjGk0153uG 1X554Wf/GU/C5ADiM7Ob4ACDhlUiyi553xBTjfhruLKxBPKENinkeUGvq9LAee158wJD SGoZLk/UwHcnw7fgrM2EP8YUpYpzejW7FhPkVJhSYWcXY9CjiUGsYOD8UKsMmH+sFkmL +dkraCqG2mQ+Rz0aRktvdZKHnRIinyDfzzoXiss0ttrPS+jy4kUg8b7DF8DtDsp2jlNO 6jnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705870985; x=1706475785; h=content-transfer-encoding:in-reply-to:autocrypt:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jnuAu48hLdY2NtgfoNoGoszrYUYCdCuWDWWYW1+4rwM=; b=nfKqL86CkR+5HFiFTWVoSydfa7NWqDCOhUnhfVuWuVNkwLycfFgaYeFzI77VXWYgxs 0zeCMRgHkPdtcf2IJQF+hlwUQIa4YFFSRK8cdFnbIegptD/6PC/H3NYBWjvKQaBnLOpk VdMqNMLlKUXeDuDDG72ob/3HJ+gFsfyXsfYCS9/d1E8PwetHk6MZ1c2qCw0xRHOmRRZf ULyH42NFgpfGkwPU30R+Oc9oM0FCkEZFIMCL8JHxIjw8+Z827YGcxJli+VOsvznhQyaM pafwVCFY5vHeUG3Idgwo3WacBnsK7uwxdSNlYY7GLsLr7QfOErBBeVmIsGZ01TBmClHv IlHQ== X-Gm-Message-State: AOJu0Ywxup1mSg6mTTwGJg01oAryu5C/C5Rx6XUXTdRyzHnVoV3Yb0Qk jH9S9NifMelK/W9eAH50tBMnKIl6NZSt60IyAKGsNClGP8rSf7mQJoc1mx/t X-Google-Smtp-Source: AGHT+IEJ0RdqFih1EkUnHDm7LSlX1iJQJ8R9/glVPYAAwddIj/QCbCS2IearYukiOsMFmCglDrixgA== X-Received: by 2002:aa7:9829:0:b0:6d9:e91c:a5bc with SMTP id q9-20020aa79829000000b006d9e91ca5bcmr3578329pfl.38.1705870985136; Sun, 21 Jan 2024 13:03:05 -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 r5-20020a056a00216500b006dbdac1595esm1348784pff.141.2024.01.21.13.03.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jan 2024 13:03:04 -0800 (PST) Message-ID: <74f11e47-060e-47d5-9329-bbeba5cbe218@gmail.com> Date: Sun, 21 Jan 2024 18:03:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: James Almer 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> <8bd854a2-b10d-479b-8a21-0e2f506db08b@gmail.com> 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: <8bd854a2-b10d-479b-8a21-0e2f506db08b@gmail.com> 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:29 PM, James Almer wrote: > 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. I could remove the types and the union altogether and leave only the array even for uniform tiles if you think that simplifies the API, but seems like a waste of memory to allocate a rows x cols array of ints just to have the same value written for every entry. _______________________________________________ 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".