[FFmpeg-devel] AVWriter again (was: v2 1/2] avformat/url: check double dot is not to parent directory)

[Zhao Zhili]

> On Jul 30, 2020, at 11:42 PM, Nicolas George <george at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".