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

[Michael Niedermayer]

On Sat, May 30, 2009 at 09:31:06PM +0200, Vitor Sessak wrote:
> 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.

then i missunderstand the underlined part above

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

i mean its non functional because it does not know the buffer size it just
guesses and then reallocates the buffer, that could involve closing and
opening a window or changing the video mode if its buffers from the vo


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

sorry, i do not know what you talk about, you will have to explain the
problem you hint at more verbosely

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090530/458cd0e5/attachment.pgp>