[FFmpeg-devel] [RFC] Unified string / stream API
Nicolas George
george at nsup.org
Thu Dec 31 15:34:39 EET 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201231/2b42f410/attachment.sig>
More information about the ffmpeg-devel
mailing list