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

[Vitor Sessak]

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
>>>>> 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?
> 
> 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).

-Vitor