This mail is about a project I have to make FFmpeg's API and infrastructure more convenient. For a common introduction, see this thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
int av_foo_to_string(char *buf, size_t buf_size, AVFoo *foo); int av_bar_to_string(char *buf, AVBar *bar); /**< buf should be at least 42 */ int av_qux_to_string(char **buf, AVQux *qux); /**< av_freep() buf after */ This is annoyingly inconsistent. To make the API more pleasant, a consistent way of returning strings and byte buffers is needed. Unfortunately, only the method with dynamic allocation is generic enough to serve everywhere, but it is also the most expensive and annoying to use. Fact: we have frame and buffer pools. It means we consider that dynamic allocations that happen at least once per frame are worth optimizing, even at the cost of non-trivial code. The AVWriter API is a more elegant and generic version of the AVBPrint API. By default, it works with a buffer on stack but switches to dynamic allocation as soon as needed, with many extra features. The benefits I promise from this: - Factored error handling, with only a single test at the end. - Unified string return API, with the efficiency of static buffers when possible and the power of dynamic allocation when necessary. - The ability to use for byte buffers as well. - On-the-fly filtering, for example escaping or changing the character encoding, without intermediate buffers. - The ability to directly plug with the string objects used by other libraries or languages. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
