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

[Michael Niedermayer]

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

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

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20110112/8630a7ba/attachment.pgp>