[FFmpeg-soc] expand filter (alternative to pad syntax)

[Michael Niedermayer]

On Mon, May 12, 2008 at 12:59:40AM +0100, vmrsss wrote:
> On 11 May 2008, at 21:06, Michael Niedermayer wrote:
> >>> There should be no copy.
> >>> The source filter should directly draw into the larger buffer of the
> >>> destination filter.
> >>
> >> How should it be done then? Something like:
> >>
> >> static void end_frame(AVFilterLink *link)
> >> {
> >>     AVFilterLink* output = link->dst->outputs[0];
> >>
> >>     avfilter_resize_video_buffer(link->currpic, pad->w, pad->h); //  
> >> not
> >> yet existent function!
> >>
> >>     draw_borders(link->currpic);
> >>
> >>     for (i=0; i<4; i++)
> >>     link->currpic->data[i] += the quantity needed to pad top/left
> >>
> >>     avfilter_draw_slice(output, 0, pad->h);
> >>     avfilter_end_frame(output);
> >> }
> >>
> >> and avfilter_resize_video_buffer() implemented using av_realloc()?
> >
> > not possible, the buffer could be from an API like directdraw, xv, sdl
> > or even a buffer on your video card. These almost certainly do not
> > provide a function to resize. Also av_realloc() can be very slow.
> >
> > Anyway, mplayer can do it, so it can be done and actually i belived  
> > that
> > avfilter already was able to do such things but i do not know  
> > precissely
> > how ATM. So maybe that has not been completely implemented.
> 
> Looking at what mplayer does would be easy enough. It looks to me they  
> use (versions of) memcpy.

Yes as a fallback when direct rendering is not possible.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080512/74be8579/attachment.pgp>