[FFmpeg-devel] [PATCH] libavfilter-soc: implement pad filter
Sun May 10 13:46:30 CEST 2009
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 ?
> |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,
link->src->inputs->picture->data += ctx->padleft;
link->src->inputs->picture->data += ctx->padtop * stride;
[... data[1,2,3] following the same idea ...]
[... avfilter_start_frame() and etc...]
More information about the ffmpeg-devel