Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2 v2] avutil: add a Tile Grid API
Date: Sun, 21 Jan 2024 19:29:08 +0100
Message-ID: <170586174894.8914.16513575461875087750@lain.khirnov.net> (raw)
In-Reply-To: <5cabd1bb-f454-4e5c-8950-b2217fba5231@gmail.com>

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.

> 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?

> 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.

-- 
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".

  reply	other threads:[~2024-01-21 18:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 22:04 James Almer
2024-01-20 22:04 ` [FFmpeg-devel] [PATCH 2/2 v2] avformat: add a Tile Grid stream group type James Almer
2024-01-21  6:27 ` [FFmpeg-devel] [PATCH 1/2 v2] avutil: add a Tile Grid API Anton Khirnov
2024-01-21 12:06   ` James Almer
2024-01-21 17:29     ` Anton Khirnov
2024-01-21 17:47       ` James Almer
2024-01-21 18:29         ` Anton Khirnov [this message]
2024-01-21 18:38           ` James Almer
2024-01-21 19:02             ` Anton Khirnov
2024-01-21 19:29               ` James Almer
2024-01-21 21:03                 ` James Almer
2024-01-22 10:38                   ` Anton Khirnov
2024-01-22 12:12                     ` James Almer
2024-01-22 10:32                 ` Anton Khirnov
2024-01-22 11:59                   ` James Almer
2024-01-25 17:13                     ` Anton Khirnov
2024-01-25 17:31                       ` James Almer
2024-01-22 12:08                   ` James Almer
2024-01-25 17:17                     ` Anton Khirnov
2024-01-25 17:26                       ` James Almer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=170586174894.8914.16513575461875087750@lain.khirnov.net \
    --to=anton@khirnov.net \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git