[FFmpeg-cvslog] r26315 - trunk/libavfilter/vf_pad.c

Baptiste Coudurier baptiste.coudurier
Wed Jan 12 02:01:00 CET 2011


On 01/11/2011 04:45 PM, Michael Niedermayer wrote:
> On Tue, Jan 11, 2011 at 04:35:14PM -0800, Baptiste Coudurier wrote:
>> On 01/11/2011 03:53 PM, michael wrote:
>>> Author: michael
>>> Date: Wed Jan 12 00:53:24 2011
>>> New Revision: 26315
>>>
>>> Log:
>>> Fix design of the pad filter.
>>> Previously the pad filter just drawed borders in the surrounding of the input
>>> without checking if this area was allocated or writeable. Now we check and
>>> allocate a new buffer if the input is unsuitable.
>>
>> How so ? pad filter get_buffer should ensure that the buffer is
>> correctly allocated.
>
> yes, but nothing gurantees that what is input into start_frame/draw_slice
> is what get_buffer returned

Humm I have a bad feeling about this. I think it should be better 
guaranteed given how many filters handle the buffers currently.

> An example to show this problem
>
>                  /->pad=1000:100
> decoder ->  split
>                  \->pad=100:1000
>
> the decoder can here only get frames allocated from one of the 2 pad filters
> the second pad filter will get frames that have been allocated by the other

Yes, but in this case direct rendering is not possible for the one of 
the filters, so I don't see why this is a problem.

> There are also simpler cases where its convenient not to return the data in
> the next filters provided buffer.
> Examples are for example when the data alraedy is somewhere else like a
> AVPacket from a raw demuxer or from a decoder like our mpeg2 decoder that can
> provide slices by reusing a 16pixel high buffer to improve cache useage

Assuming direct rendering, the decoder will write slices in the user 
supplied buffer using get_buffer, so I don't see why this is a problem.

For the raw demuxer case, it might be an issue, but in this case I think 
the buffer should be marked as unwrittable and libavfilter should copy 
it into the pad filter supplied buffer.

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



More information about the ffmpeg-cvslog mailing list