> On Jul 30, 2020, at 11:42 PM, Nicolas George <geo...@nsup.org> wrote: > > 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. >
So we can get a writer with AVIO context as backend, with custom stream filters. It do sound interesting, as long as it doesn't go too far like io in Java and C++. It's valuable to support user allocated memory, however, I'm afraid string is only a small part of the use cases. > Regards, > > -- > Nicolas George > > _______________________________________________ > 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". _______________________________________________ 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".
