Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
Date: Tue, 23 Apr 2024 17:24:03 -0300
Message-ID: <927b5c94-c765-4852-a502-4369b4a624c6@gmail.com> (raw)
In-Reply-To: <20240423111552.GI6420@pb2>

On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
>> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
>>> Quoting Andrew Sayers (2024-04-23 11:51:00)
>>>> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
>>>>>> lavu/opt: Clarify that AVOptions is not indended for general use
>>>>>
>>>>> They _are_ intended for general use though.
>>>>
>>>> In that case I'm confused...
>>>>
>>>> Let's say I make a desktop app to transcode videos.  Obviously I would use
>>>> AVOptions to display configuration options for different encoders.  And it's
>>>> possible to create AVOptions objects for my UI.  But how strongly is that use
>>>> case recommended?
>>>>
>>>> To provide a particularly difficult example - let's say I want to let the user
>>>> choose between interface themes, and I want to show both some text and a
>>>> picture of the theme.  AVOption doesn't include a "text + picture" option,
>>>> so how would I extend it to meet my needs?
>>>
>>> If they fit your use case, then use them, otherwise don't - that's true
>>> for pretty much all APIs we provide.
>>
>> Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> 
> If FFmpeg which is a multimedia tool in no place needs or wants to store
> pictures through its option API in a way not curently supported.
> I would say thats not going to qualify as "general use" outside specialized
> software thats already dealing with a lot of pictures
> 
> still you certainly can handle binary data (like a bitmap picture) through
> AVOption
> 
> thx

Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which 
is currently the only field not covered by an AVOption (And thus not 
currently configurable from the CLI). How could it be supported? Binary 
type doesn't work because it expects a pointer + size field and 
allocates the former.
_______________________________________________
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".

  parent reply	other threads:[~2024-04-23 20:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22  8:49 [FFmpeg-devel] [PATCH] " Andrew Sayers
2024-04-22 11:00 ` Stefano Sabatini
2024-04-22 12:09   ` [FFmpeg-devel] [PATCH v2] " Andrew Sayers
2024-04-22 12:56     ` Stefano Sabatini
2024-04-23  9:21     ` Anton Khirnov
2024-04-23  9:51       ` Andrew Sayers
2024-04-23 10:04         ` Anton Khirnov
2024-04-23 10:10           ` Andrew Sayers
2024-04-23 11:15             ` Michael Niedermayer
2024-04-23 11:18               ` Michael Niedermayer
2024-04-23 11:54                 ` Andrew Sayers
2024-04-23 17:08                   ` Michael Niedermayer
2024-04-24  7:30                     ` [FFmpeg-devel] [PATCH v3] lavu/opt: Clarify the scope of AVOptions Andrew Sayers
2024-04-30 23:33                       ` Michael Niedermayer
2024-04-23 17:28                   ` [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use Vittorio Giovara
2024-04-23 18:52                     ` Andrew Sayers
2024-04-23 20:16                       ` Andrew Sayers
2024-04-23 20:27                 ` Stefano Sabatini
2024-04-23 20:24               ` James Almer [this message]
2024-04-23 20:53                 ` Michael Niedermayer
2024-04-23 21:23                   ` James Almer
2024-04-23 21:48                     ` Michael Niedermayer

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=927b5c94-c765-4852-a502-4369b4a624c6@gmail.com \
    --to=jamrial@gmail.com \
    --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