Re: [FFmpeg-devel] The case for a good string API

[Nicolas George <george@nsup.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]

Stefano Sabatini (12022-06-17):
> I was thinking about mempool (and no, I don't think it's really
> neeeded for this use case).
> 
> I still had to read the implementation, now I think I got what this is
> about.

You have touched the main difference between AVWriter and BPrint.

BPrint is a specific implementation, it works the way it works and
return the string as a pointer and a length field. If you are not happy
with it, you must take it anyway.

AVWriter is a layer of abstraction. A very thin, very lightweight layer.
Very ffmpeg.

You can make an AVWriter out of anything, as long as it is something
where writing to it text makes sense. You just need to write a few
low-level callbacks to write bits of string, and benefit from the
high-level features of AVWriter.

There is already an AVWriter that will let you have a static-or-dynamic
buffer allocated with av_realloc(). In fact it is a BPrint inside of it,
because no need to duplicate the code.

There is already an AVWriter that will use a buffer you already have.
There is already an AVWriter that will write the text to the logs
without storing it.

If you are writing an application that is partially in Rust, you can
make an AVWriter that will store the text in a Rust String object. Same
goes with Perl, Java, whatever language.

If you are writing a GUI application, you can make an AVWriter that will
store the text directly in a text widget.

You can make an AVWriter that will change the character encoding of the
text, or compress it, or encrypt it, and write the result to another
AVWriter.

Your imagination is the limit. But if you only want good old C strings,
you do not need to know any of that, just use one of the built-in
AVWriter as shown in the documentation and you are good to go.

I have to confess, I am rather proud of the ideas I have had to make an
abstraction layer that is lightweight, nimble and future-proof at the
same time. Eventually, I would like to go further in that direction, for
example with side data types describing themselves how they can be
serialized / duplicated / referenced. But later.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".