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

Stefano Sabatini stefano.sabatini-lala
Sun May 10 23:35:02 CEST 2009

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

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

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)

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...).

FFmpeg = Funny Fiendish Magnificient Portentous Embarassing Guru

More information about the ffmpeg-devel mailing list