[MPlayer-G2-dev] extra dr types (oh no not more!! :)

[D Richard Felker III]

On Thu, May 15, 2003 at 12:08:25PM +0200, Arpi wrote:
> > 2. Dirty stride arithmetic tricks... :)) If the vo's buffer is an
> >    overlay in video memory, chances are good that you can customize
> >    the source width, source height, origin, and stride independent of
> >    the actual pixel layout in video memory. Is there some way we could
> >    let the filter chain take advantage of this? For example, the crop
> >    filter could let DR go right through it, allocating a buffer the
> >    size of the source image in video memory, but then only configuring
> >    the desired part of it to be visible. Another potential use is
> >    using stride arithmetic for deinterlacing, i.e. writing the whole
> >    interlaced picture to video memory, but selecting only one field to
> >    be visible at a time.
> 
> vo2 api is capable (RESIZE_SRC), but as you said it's not eays to implement
> cleanly. maybe the best way is implementing these as options to vf_vo2
> filter. or maybe we could drive this control through the filter layer, so
> filters like fields or crop could query if RESIZE_SRC is available and use
> that instead of copy. (like the DRAW_OSD, VIDEO_EQ or SCALE controls in g1)

Arpi, I think I figured out what I meant for point #2...

What I'd like to see is a way whereby the filter chain can get a
pointer to an area in video memory from the vo driver, then give it
back to the vo driver as an *export* image, i.e. specifying its own
pointer somewhere inside video memory and stride. Naturally this would
only work for very flexible vo drivers, but it would be nice and
powerful and clean! Of course, the vo could tell the filter the
minimum power of 2 that would have to divide stride, and likewise how
aligned the origin offset would have to be...

Rich