[FFmpeg-devel] [PATCH] Explicit avcodec_decode_video2 documentation about picture allocation

Cyril Russo stage.nexvision
Sun May 2 15:20:47 CEST 2010

> I didn't claim it to be obvious, however being only output parameter
> (the whole AVFrame) means the function will not read from it - with
> that promise there's no way it could know it is allocated.
I'm not sure the code does what you're saying. Since I haven't checked 
all video decoders, I will consider to be the case.
Anyway, it's not consistent with the rest of the api, for example with 
avcodec_decode_audio where "samples" is not allocated by the function, 
but marked as output too.

>>    * @param avctx the codec context
>>    * @param[out] picture The AVFrame in which the decoded video frame will be stored.
>> + *                     The function allocate the frame (don't call avpicture_alloc beforehand).
> "allocates", and "do not".


> But I think it would be more consistent with e.g. the struct documentation to write
> "Initialized and allocated by libavcodec" (or something better if you can think of anything).

I'm a bit confused between the mix in AVFrame and AVPicture in the API, 
with the example code converting from the former to the later everywhere.
Adding "Initialized and allocated by libavcodec" to AVFrame struct 
documentation wouldn't improve this, IMHO, since even if you allocate 
with avpicture_alloc, it *does* initialize and allocate by libavcodec.

If you don't mind confirming this, I can add "similar" documentation to 
avcodec_decode_audio / subtitle, stating that the output buffer should 
be allocated beforehand for those.

> There is also the option of slightly changing the API so it must be zeroed and then
> checking the pointer being NULL, but I am unsure that is a good idea.

In an ideal world, all decode functions should act the same so the user 
doesn't have to guess the behaviour once she did it once.

Thanks for answering.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: allocationHelp.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100502/8ac2eda9/attachment.asc>

More information about the ffmpeg-devel mailing list