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

[Vitor Sessak]

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/+=/-=/ ...

-Vitor