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

[Michael Niedermayer]

On Fri, Jun 17, 2022 at 04:57:55PM +0200, Nicolas George wrote:
> 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.

Sorry for my late reply.
I do like the AVWriter idea, i think replacing BPrint by it is a good
idea
I only now looked at your examples you posted in april last year. I may
have looked before, i dont remember but from these examples it looks
nice

Thanks


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220815/42b87158/attachment.sig>