[FFmpeg-devel] [PATCH 25/35] avutil/opt: add av_opt_to_string

[Diederick C. Niehorster]

(NB: I have reorganized your reply a bit to make it for me to respond to)

On Wed, Jun 9, 2021 at 1:54 PM Nicolas George <george at nsup.org> wrote:
>
> The critical part is the API of the new public function, because this we
> cannot fix later.
>
> Unfortunately, to get a good API, you will not be able to reuse the
> implementation of av_opt_get() as it is. Therefore, you will probably
> need two changes: (1) change the implementation of av_opt_get() and (2)
> add the new function.
>
> Whether this should be done in one or two patches depends on the
> specifics, on the amount of code in each change and how much they cover
> each other.
>
> In the meantime, as I suggested, I think using AVBPrint is the best
> option:
>
> void av_num_opt_bprint(AVBPrint *bp, AVOptionType type, double val);

Ok, see if i understand this correctly. To use AVBPrint in this new
API (which when reading up on it, seems like a good idea since it does
something similar to C++'s std::string's small string optimization,
and many string here will be very short, so no dynamic allocations), i
would need to change the guts of av_opt_get() that i would like to
reuse to take an AVBPrint. That would be pretty similar to the current
uint8_t buf[128] currently used in the function, but remove the
arbitrary (if rarely hit) size limit.

What is the size of the internal buffer of AVBPrint?

So in av_opt_get(), I'd do something like this:
AVBPrint buf;
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
// 1. call internal print function, with &buf
// ...
// 2. provide output to caller
if (!av_bprint_is_complete(&buf))
{
    av_bprint_finalize(&buf,NULL);
    return AVERROR(ENOMEM);
}
ret = av_bprint_finalize(&buf,out_val);
return ret<0 ? ret : 0;

I'll experiment with that.

>
> I have long-term projects of rewriting the options system, with each
> type (channel layouts, pixel formats, color ranges, etc.) coming with a
> descriptor for printing and parsing it, and a de-centralized way of
> adding new types. Unfortunately, first I need to convince people here
> that we need a better strings API

That sounds nice. Lets keep things here as they are then. Have you
laid out your plans somewhere i can read about them?

Cheers,
Dee