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

Michael Niedermayer michaelni
Sat May 30 18:24:23 CEST 2009


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
it will be memcpy() somewhere

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

Avoid a single point of failure, be that a person or equipment.
-------------- 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/c43ab28a/attachment.pgp>



More information about the ffmpeg-devel mailing list