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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
