[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter

Vitor Sessak vitor1001
Fri May 22 14:31:57 CEST 2009

Stefano Sabatini wrote:
> On date Thursday 2009-05-21 23:20:51 +0200, Stefano Sabatini encoded:
>> On date Wednesday 2009-05-20 20:42:21 +0200, Vitor Sessak encoded:
> [...]
>>> I suppose you didn't test the changes to ffmpeg.c, unless you forgot to  
>>> attach the patch for vsrc_buffer.c. I imagine that here handling  
>>> avfilter_request_frame() without memcpy'ing the whole frame (as is done  
>>> in ffplay.c) would be non trivial.
> In attachment an updated patch with the missing changes to
> vsrc_buffer.c.
> Can someone suggest how would be possible to avoid the initial frame
> -> picref memcpy?

What non lavfi-patched ffmpeg.c does now is:

1- allocs a frame with the padding specified by command-line opts -padXXXX
2- decodes the frame to this buffer. Note that this buffer might need to 
be reused for ME.

what I suggest:

a) For the first frame
1- ffmpeg.c allocs a frame with no padding.
2- libavfilter request a frame with padding px,py.
3- ffmpeg.c allocs a frame with padding px, py, copies the frame to it 
and free the replaces (freeing) the old frame by the new
4- ffmpeg.c passes the new frame to the filter framework

b) For the next frame
5- ffmpeg.c decodes the frame with padding px, py
6- libavfilter request a frame with padding px2, py2
7- if (px2 > px || py2 > py) alloc another frame and memcpy the pic to 
it (and set px = px2; py = py2;). if not, just send the frame pointer to 

Note that since the frame must be preserved for ME, it is impossible to 
completely avoid memcpy() if the padding amount varies wildly between 
frames. All we can do is to avoid it if it is constant or decreasing. 
Note the user can optimize his filter chain to avoid memcpy. For 
example, this (hypothetical, libavfilter does not support changing 
width/height on the fly yet) nasty filter


can be replaced by


which will not require any memcpy'ing.


More information about the ffmpeg-devel mailing list