(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 <geo...@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 _______________________________________________ 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".