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

Michael Niedermayer michaelni
Fri May 29 00:12:03 CEST 2009


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 or which part do i
misunderstand?

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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- 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/20090529/84c5f8f8/attachment.pgp>



More information about the ffmpeg-devel mailing list