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

[Michael Niedermayer]

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/1f772df2/attachment.pgp>