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

[Vitor Sessak]

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
>>> 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 
>> libavfilter
> 
> 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?

> or which part do i misunderstand?

Hmm... If one implements something like

     AVFilterPicRef *(*get_video_buffer)(AVFilterLink *link, int perms, 
int padleft, int padright, int padtop, int padbottom);

I don't see why also passing the padding parameters to request_frame() 
is necessary. So your suggestion is just to instead of changing the 
logic of request_frame(), change only get_video_buffer()? It might work...

-Vitor