[FFmpeg-devel] [PATCH] Explicit avcodec_decode_video2 documentation about picture allocation
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...
More information about the ffmpeg-devel