zhilizhao (12020-07-28): > fmemopen() can work with memory on stack or on heap, although it doesn’t > support switch between the two dynamically. It’s a good to have feature like > the small string optimization in std::string, but i’m not too keen on it.
I think it is an important optimization. This kind of string operation can happen once per frame, and with low-latency codecs or devices, once per frame can be hundreds or thousand of times per second. Note that we are actively trying to prevent memory allocations that can happen once per frame, to the point of adding pools to avoid them. This optimization is both much simpler and a bit more efficient than using pools. And even for cases that are not once per frame, this is interesting: because this optimization is there, we do not have to hesitate to use this API even if we know that the string is short and a fixed buffer suffices. This is interesting because the more parts of FFmpeg use this API, the more convenient it becomes. > Please, what wonderful features are in your plan? ;) I may have exaggerated a little bit about wonderful: anything is possible with normal string buffers anyway. But AVWriter allows nice optimizations, avoiding many intermediary buffers. A few examples: If you want to send something directly to a file or the network, you can have av_avio_writer() that does that with an AVIO context. If the thing is big but constructed by parts, we avoid needing a big buffer, and serialization and writing can happen in parallel. If we have to pile string processing on top of each other, for example first serializing something and then escaping special characters in the resulting string, AVWriter can be made to do it on the fly, without an intermediate buffer in the middle. If an application works with other kinds of memory allocation, for example a Java application using StringBuffer and such, AVWriter can be made to use directly these instead of first using av_malloc() for a buffer and then converting it to what the application needs. I think that gives a good idea of what is possible. Most importantly, none of these feature makes anything more complicated in our code: using AVWriter is still as simple as I have shown earlier ( https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/266897.html ). Everything complex is in the implementation, and it not that complex. 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".
