On Thu, Jun 10, 2021 at 12:08 PM Diederick C. Niehorster
<dcni...@gmail.com> wrote:
>
> On Thu, Jun 10, 2021 at 11:39 AM Diederick C. Niehorster
> <dcni...@gmail.com> wrote:
> > 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.
>
> Ok, i have experimented with this, and hit some problems quickly.
> There are at least the following issues:
> 1. how to deal with AV_OPT_ALLOW_NULL in av_opt_get, if its guts use a
> move over to AVBPrint? leaving AVBPrint empty is not the same as a
> null, and does not signal null.
> 2. some cases forward to other functions, most importantly
> AV_OPT_TYPE_DICT, which uses av_dict_get_string. These do not play
> with AVBPrint, but just plain char** or similar. Should i use a local
> buffer in that case and then copy/print its contents into the
> AVBPrint? That seems to not improve the situation.
> This is assuming we'd want to reuse the guts of av_opt_get for this
> new function, which i think we would. Not doing so would mean a lot of
> code duplication.
>
> And there is also that this would be the only av_opt_* function
> returning output through a AVBPrint instead of plain arrays. Is that
> inconsistency in the API worth usually avoiding a dynamic allocation
> in code that'll not be used in a critical path?
I've just sent v2 of the patch set. Given what i have written above, i
have not moved the function to using AVBPrint, so i can reuse
av_opt_get internals and don't introduce inconsistency in the options
API. That said, moving it _all_ over to your better strings API
proposal[1] sounds like a pretty sweet thing to do!
I also hear you on your idea for better options. While the function i
add here allows me to format pixel_format and sample_formats correctly
because they have their own options type, I still have the issue that
another option "codec" is just printed as int, as there is no
AV_OPT_TYPE_CODEC, or otherwise information that it should be turned
into a codec name... Hope that something like your proposal will make
that a thing of the past.
Cheers,
Dee
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
