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

[Vitor Sessak]

Michael Niedermayer wrote:
> On Sat, May 30, 2009 at 06:25:37PM +0200, Vitor Sessak wrote:
>> 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).
> 
> your example is a little silly, no filter does that and if one does yes

No filter does that yet, but I think that putting the padding parameters 
in request_frame() is silly if we do not allow it to change for 
different frames.

> it will be memcpy() somewhere

So it kind of come back to my original proposal, no?

-Vitor