[FFmpeg-devel] About avpicture_alloc (deprecate?)

Baptiste Coudurier baptiste.coudurier
Tue May 11 21:43:12 CEST 2010


On 05/05/2010 11:47 PM, Reimar D?ffinger wrote:
> On Wed, May 05, 2010 at 10:06:55PM -0700, Baptiste Coudurier wrote:
>> On 5/3/10 12:38 AM, Cyril Russo wrote:
>>>
>>> Le 02/05/2010 19:45, Reimar D?ffinger a ?crit :
>>>> On Sun, May 02, 2010 at 07:31:44PM +0200, Cyril Russo wrote:
>>>>> As soon as you use swscale, you need it.
>>>>> avcodec_alloc_frame allocate the frame structure but not the "data"
>>>>> buffer, while avpicture_alloc does.
>>>>>
>>>>> So unless you want people starting to allocate data[0] et al, by
>>>>> themselves (and doing bad thing with alignment since it's very hard
>>>>> to find out the required stride for decoder, see issue1909)
>>>> The get_buffer functions are for allocating the data, and their
>>>> documentation also explains how to get proper values _if_ you want
>>>> to implement them yourselves (which is a good idea if performance is
>>>> important).
>>> The fact is when you're using swscale, you need an allocated picture
>>> that is likely not in the same format of the decoded picture.
>>> You can't call codecContext.get_buffer as it'll allocate (or reuse, the
>>> doc doesn't say) a picture in the format expected by the codec.
>>>
>>> Let's take an example then, you want to convert YUV420P to RGB24.
>>> How do you allocate the RGB24 picture without avpicture_alloc (and make
>>> sure about the alignement requirement of swscale's algorithms) ?
>>
>> Yes, that is right, avpicture_alloc is needed and must be part of
>> the public API.
>
> That surely is a exaggeration, quite a few users will implement
> their own allocation functions anyway, but I see it is more
> convenient.

No it isn't, only a very few people will write their own, FYI I don't 
rewrite my functions.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list