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

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Leo Izen:
> 
> On 8/30/22 15:37, Nicolas George wrote:
>> Leo Izen (12022-08-30):
>>> Is there a reason this is AVWriter wr = foo() and not AVWriter *wr =
>>> foo()?
>>> Most other APIs return pointers to structs, rather than structs
>>> themselves
>>> (see: av_packet_alloc). Using a pointer would prevent us from having
>>> sizeof(AVWriter) as part of the ABI, as was done with AVPacket.
>>
>> Yes: to return a pointer, you need somewhere to store the structure. One
>> of the point of AVWriter is that you can store it on the stack to avoid
>> dynamic allocations when the string is short enough.
>>
>> Note that AVWriter is exactly two pointers. It will always be two
>> pointers, and all the objects that I intend to introduce later will
>> always be two pointers: one const pointer for the methods, one pointer
>> for the object itself.
>>
>> This design is essential to the features I promised for AVWriter and for
>> later.
>>
> 
> I don't see how you are planning on avoiding dynamic allocations by
> stack-allocating AVWriter when AVWriter itself only contains two pointers.
> 
> I also don't see how this design is essential to the features you
> promised in a way that can't be done by just not making sizeof(AVWriter)
> part of the ABI and returning pointers to a struct.
> 

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.

- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".