[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter
Sat May 30 18:25:37 CEST 2009
Michael Niedermayer wrote:
> On Sat, May 30, 2009 at 03:44:00PM +0200, Vitor Sessak wrote:
>> Michael Niedermayer wrote:
>>> On Fri, May 22, 2009 at 02:31:57PM +0200, Vitor Sessak wrote:
>>>> 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
>>>> 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
>>> 1 - the decoder which is pretty much a filter with no input requests
>>> from the next filter a buffer.
>>> 1b- the next filter can pass this request up until to the video output
>>> device in principle or return a buffer. If this request passes a
>>> "pad" filter it is modified accordingly.
>>> 2 - the decoder decodes into this frame.
>>> Which part of that are you not understanding
>> I probably was missing that there is no decoder that need not only to
>> preserve, but to output to the same data pointers of the last frame. Can
>> you confirm that you can decode the first frame in a buffer and the second
>> frame in a different buffer for every codec?
> no i cant confirm that, the filter framework must support that as well
> but i cant see in how far that would be a problem.
If you have:
Frame 1: Size: 200x200, requested padding 1,1,1,1 -> buffer size:202x202
Frame 2: Size: 200x200, requested padding 8,8,8,8 -> buffer size:216x216
To decode the second frame, you need a buffer of size 216x216, but with
the previous picture data inside. The only way I see to do this is to
alloc a new buffer and memcpy the previous picture to it (unless, of
course, you could predict already in the first frame you'd need a
216x216 buffer, but it shouldn't be possible in general).
More information about the ffmpeg-devel