[FFmpeg-devel] [PATCH] lavu: header and documentation for AVWriter

[Nicolas George]

Andreas Rheinhardt (12022-08-31):
> He is not only stack-allocating AVWriter, he also intends to
> stack-allocate the actual writers like AVDynbufWriter, AVBufWriter
> (AVWriter is just a wrapper around the underlying writers). This means
> that no allocations need to be performed for AVBufWriter at all (and due
> to the inherent small-string optimization of an AVBPrint, it can also be
> avoided for AVDynbufWriter in lots of cases).
> If you return pointers to an AVWriter struct, you need to allocate this
> struct somewhere, which means that your init/av_dynbuf_writer_wrap has
> an allocation that can fail and therefore needs to be checked; and the
> struct needs to be freed lateron.

Thanks. I could have been more precise.

AVWriter itself uses a new kind of mini decentralized object system,
where all objects are a pair of pointers, first a const pointer to the
structure of primitive methods and second the structure itself, and are
passed by value. It does not require any future extension, it just works
that way.

This scheme allows to add methods on an existing structure without
altering it. So, any kind of side data, for example, can become an
object with serialize methods, or an object with ref/unref methods, etc.

The various implementations of AVWriter are also designed to be
allocated on the stack by the caller. This time, to avoid being
encumbered by sizeof(struct) for compatibility, I use a different trick:
one of the first field of the structure is its own size, set by whoever
allocated it.

Currently, the code only checks that the size is at least the original
size. If we later extend the structure, the code will have to check if
the fields it tries to access are below the reported size, and if they
are not it will have to manage without them, use a fallback value.

For writers, need for extending the structure is very unlikely. But for
the methods structures, it can happen. Methods structures defined by
earlier applications will just behave as if these methods are
unimplemented.

The ability to allocate on the stack is essential to AVWriter, since it
needs to be lightweight enough that we never have to hesitate to use it.
Of course, it can always be allocated dynamically. I wonder if I should
include functions to allocate dynamically and init av_dynbuf_writer() at
least.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220831/0f7fc100/attachment.sig>