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 CC96748894 for ; Sun, 21 Jan 2024 17:47:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9DC4568D054; Sun, 21 Jan 2024 19:47:47 +0200 (EET) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2E28768CEC8 for ; Sun, 21 Jan 2024 19:47:41 +0200 (EET) Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-6de83f5a004so1714005a34.1 for ; Sun, 21 Jan 2024 09:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705859259; x=1706464059; 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=G9fAvgt21cpnKxUglWAuCWX5UbjPorb7LAsV6L+OoTw=; b=kzni2ukXNOF84cMl/CSAboywlbxCRyultwzJi08PDqn4FZSD7hF9Piz2RtejsUf1W1 4O+XXktUHS7Jvf74iUrZnUY3PSTrc18Tcx/6auCC8QoF6c18zUjeh+86Uf4dnznAtjOD snec3y8MhtiyFSoiMA3fQLUxsPal9uuE+Dlyoo3kEgi6+C/dvL2h5v2sj3pIoDQurADW awrdAcD8fzZKP9QS7I1MMtiCCyf1r9bD8ilkdmM7fQtsbgKNOFL//6NcaQa+AJ8lz0IH UZAO61xAwA6Q3ygmoRjnQXtNlwzv8XKZPYuOqm60MvaG8mFavIiCQCQuFoHKaY7t+569 rRlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705859259; x=1706464059; 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=G9fAvgt21cpnKxUglWAuCWX5UbjPorb7LAsV6L+OoTw=; b=W2hfcLOMCKvXRfpmFaiqCTGSrG3T8LQL9C05rsQbc1JeN/OcfQ2sEPHm8UhUtpuaiF O7mBNToyRmpwrM/3Wlpmvng7XUYpHKgpBcSiTT9cOPWhcEi+BSSu+qyp9HISPg94Whoy 9EKSf9qP9xU4r8QdRV6K+tD8eOkFyYV3ENXIz5b3xOi+4YOCwKYjN9xcxECNoqG2UNsX AXRBjXE4LaAAqlZcw/4HTckqlaJdB/JCkTMiWqXe3zX5Uzq55ReGK9CRklYqji/EpGC8 TBT4wEU5Vu4+A1/8/FwWiX5/HDTWbJlNIRahUlX0eDw+FQH9mnraT41SrDQscGuLzPwX Y79Q== X-Gm-Message-State: AOJu0YzuFFRuHOeqhSHEanhnENKMCGVKQs4/hp0MJl7aw0maTgQD5AKZ ZlbDVVaf2DivP0f8bI/biHqEQ40ze24Zc53ueRkNnFOl7Ej/lt5VqShC9/Xi X-Google-Smtp-Source: AGHT+IEOXfIQceLIVIjnjK62CZ6HOZix919kvxKSq16n9qdCDvS0izZTFe7IrcVyw6h2xTfh7t4+GQ== X-Received: by 2002:a9d:74d7:0:b0:6e0:c8ab:9b71 with SMTP id a23-20020a9d74d7000000b006e0c8ab9b71mr3527652otl.50.1705859258550; Sun, 21 Jan 2024 09:47:38 -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 l18-20020a62be12000000b006db3149eacasm8230456pff.104.2024.01.21.09.47.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jan 2024 09:47:38 -0800 (PST) Message-ID: <5cabd1bb-f454-4e5c-8950-b2217fba5231@gmail.com> Date: Sun, 21 Jan 2024 14:47:43 -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> 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: <170585816018.8914.1005492749396712320@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 2:29 PM, Anton Khirnov wrote: > 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? 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. 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. And what do you mean with not supporting describing arbitrary partitioning? Isn't that what variable tile dimensions achieve? _______________________________________________ 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".