[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter
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
> 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