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

[Vitor Sessak]

Stefano Sabatini wrote:
> On date Sunday 2009-05-10 15:31:37 +0200, Vitor Sessak encoded:
>> Vitor Sessak wrote:
>>> Stefano Sabatini wrote:
>>>> On date Tuesday 2009-05-05 20:49:55 +0200, Vitor Sessak encoded:
>>>>> Stefano Sabatini wrote:
>>>>>> On date Tuesday 2009-04-28 22:03:53 +0200, Stefano Sabatini encoded:
>>>> [...]
>>>>>> In order to be memcpy-less we need some API redesign, I started to
>>>>>> look at it and I'm thinking about to put in the link other fields (x,
>>>>>> y, w_exp, and h_exp).
>>>>> Why in the link and not as a parameter of request_frame() as  
>>>>> suggested  by Michael [1]?
>>>> |What effect would that have on a decoder changing the output image size?
>>>> |Also what about |- int (*request_frame)(AVFilterLink *link);
>>>> |+ int (*request_frame)(AVFilterLink *link, int width, int height, 
>>>> int left, int top);
>>>> |
>>>> |where left/top is extra memory being allocated ...
>>>>
>>>> Would that also require a corresponding change in avfilter_draw_slice():
>>>> avfilter_draw_slice(AVFilterLink *link, int left, int top);
>>> The way I see it is that the request_frame() call would just assures  
>>> that you have enough memory allocated, but picture->data[] would point  
>>> always to the picture (and thus draw_slice() would not need any  
>>> modification). A padding (with unallocated junk) filter would look like
>>>
>>> int request_frame(AVFilterLink *link, int width, int height, int left,  
>>> int top)
>>> {
>>>     avfilter_request_frame(link->src->inputs[0],
>>>                            FFMAX(width, ctx->width),
>>>                            FFMAX(height, ctx->height),
>>>                            FFMAX(left, ctx->padleft),
>>>                            FFMAX(top, ctx->padtop));
>>>
>>>     link->src->inputs[0]->picture->data[0] += ctx->padleft;
>>>     link->src->inputs[0]->picture->data[0] += ctx->padtop * stride;
>> 10l, s/+=/-=/ ...
> 
> Thanks for the reply Vitor.
> 
> So let's consider this example:
> 
> input -> pad -> output
> 
> The request_frame is called on the output pad of output, which calls
> the request_frame on the output link of pad, and so on until we get to
> the input source.
> 
> The source filter will allocate a new pic and picref, for example
> with:
> 
> AVFilterPicRef *picref = avfilter_get_video_buffer(link, AV_PERM_WRITE);
> 
> This will allocate a picture and return a picref to a picture, with
> the size specified in link, while we need to allocate a bigger
> picture to contain also the padded borders as requested by the pad
> filter.
> 
> So the problem is:
> how can we tell the avfilter_get_video_buffer() to use the parameters
> heigth, width as passed by:
> int request_frame(AVFilterLink *link, int width, int height, int left, int top)
> ?

Good point.

> A possible solution would be to store such informations in the link
> itself, for example we could negotiate the various parameters h, w,
> left, top during the configuration stage (still confused...).

Looks reasonable. Just be careful that in the configuration stage you 
should pass the _minimum_ left, top, etc. Imagine a filter chain like 
(fake broken syntax)

[in] pad=top:10,drawbox,pad=top:40

note that the input filter should allocate a buffer padded by 40 pixels, 
not 10, so the filter framework should do something in the lines of

padtop = FFMAX(input[0]->padtop, link->requested_padtop);

-Vitor