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

[Vitor Sessak]

Michael Niedermayer wrote:
> On Sat, May 30, 2009 at 06:37:55PM +0200, Vitor Sessak wrote:
>> 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.
> 
> what you where speaking of, was to have a buffer preserve its content and
> where in memory it is while changing its size, this IS silly
> creating a new buffer is a seperate matter

I didn't said anything about changing or not where in the memory the 
buffer is, just changing its size.

>>> it will be memcpy() somewhere
>> So it kind of come back to my original proposal, no?
> 
> what was your original proposal?
> the last ive seen was non functional aka "allocate each frame based on
> the size of the previous frame" and memcpy if they differ

I agree it is ugly (I don't know what you mean here by non functional). 
What do you propose? Your previous proposal choke for the case of frames 
that differs in padding and a codec that need the previous frame as output.

-Vitor