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

Stefano Sabatini stefano.sabatini-lala
Sun May 17 13:14:22 CEST 2009

On date Monday 2009-05-11 19:17:51 +0200, Vitor Sessak encoded:
> 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);

I'm going to try this approach:
int request_frame(AVFilterLink *link, int width, int height, int left, int top);
picref *avfilter_get_video_buffer(link, int exp_w, int exp_h, int left, int top, AV_PERM_WRITE);

the additional parameters given to avfilter_get_video_buffer() (at
least left and top) seem to be necessary to correctly free the buffer.

An alternative approach would be to extend avfilter_config_links() to
take the additional parameters w, h, left, top and store them in the
link, but looks somehow more complicated.

FFmpeg = Funny and Foolish Magical Peaceful Everlasting Game

More information about the ffmpeg-devel mailing list