[FFmpeg-devel] [WORK IN PROGRESS] Efficient string and JSON writing API

[Nicolas George]

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