Hi. This patch series is not for review, it is for reference, because I am stashing it before working on something else. The prospect of the uphill battle that would be needed to convince some people here that we need this discouraged me a little, I must say.
It is the work in progress for a set of APIs to handle string and serialization with the accent on convenience, efficiency and nimbleness. It is all that was good about BPrint, but even better. For now, it implements strings plus JSON serialization. Once it works, it can be easily extended to XML serialization based on the same principles, and that is something several part of our code base would benefit from. It is convenient because it factors error checking as much as possible. It is also convenient because it is efficient and nimble: we could use it everywhere without bothering to wonder if in a particular case something else would be better. It is efficient because it avoids unnecessary allocations. That makes it usable even when it happens once per frame or more. But it does so without adding arbitrary limits, like using a fixed-size buffer would. It is nimble because it can directly plug into other APIs and ways of handling strings. It can use Perl strings, Java strings, GUI text buffers, etc., all directly without the need for extra buffers. It can also plug directly to files or network, again without intermediate buffers. All this has some cost, of course. It costs code to implement it. Just like memory pools with efficient locking. Efficiency is worth it. It also costs about three minutes to learn how to use it. But the convenience makes it well worth it. To achieve all this, I had to use unusual programming techniques. I had to invent ways of doing things. I think this is the FFmpeg way. If you had not invented better programming techniques, we never would have got the fastest VP9 decoder and so on. I am sad that the project is progressively turning into a risk-advert collection of wrappers for existing libraries instead of continuing its tradition of inventing new and better ways of doing things. I am not good at shaving a few cycles in a tight loop, so optimizing codecs is not my scene, but infrastructure is also necessary for the project. If I have my way about this overhaul of string APIs, at some point we will be able to use FFmpeg types directly in printf-like format strings. But that is for later. For now, feel free to comment or ask for details. I would be happy to learn that you find all this interesting. But I will start working on event loop for libavformat and libavdevice. [PATCH 1/7] lavu: add macros to help making future-proof structures. [PATCH 2/7] lavu: new AVWriter API. [PATCH 3/7] lavu/writer: add test. [PATCH 4/7] lavf/dump: use a writer. [PATCH 5/7] WIP: add an intro to AVWriter [PATCH 6/7] lavu: add a JSON writer API. [PATCH 7/7] lavu: add JSON writer test. 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".
