Stefano Sabatini (12022-06-15): > Hi, and sorry for the long delay (I'll comment soon about the AVWriter > API).
Thanks. I was starting to despair that somebody else gives a damn about it. > Before jumping to the discussion, probably it's good to think a bit > about the bprint.h API and its limitations (the ones which come to mind > are: no errors in case of truncation, and possible inefficiency due to > the realloc). So while it covers the case for small strings (and it's > not that bad IMO from the API point of view), probably it's underkill > for data serialization. > > Do you have more in mind about its limitations? The limitations of BPrint were one of the motivations to start working on this. But I am not sure what you are referring to exactly. BPrint already has a means to test for truncation in case of memory allocation failure. I tried to make it a little harder to forget with dynamic AVWriter, but it is a fine line between harder to forget and annoying to use. Regarding realloc(), I am even more confused: we cannot avoid a dynamic allocation if the string is larger than the initial buffer. But AVWriter goes a step further in that direction: if you want to write to a file or to the network, it can do so on the fly, without using a dynamic buffer. > Also, is the new API supposed to be a replacement for AVBprint or is > it supposed to live in parallel with it (to serve different purposes)? Eventually, I would like to have all useful features of BPrint in the dynamic buffer AVWriter and deprecate BPrint, since that was written in part to learn and do BPrint better. 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".