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

[D Richard Felker III]

On Sat, May 17, 2003 at 12:42:43AM +0200, Arpi wrote:
> Hi,
> 
> > > > Arpi, I think I figured out what I meant for point #2...
> > > 
> > > great, then re-try to explain, this is nonsence:
> > 
> > Haha, ok, sorry. :)
> > 
> > > > 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
> > > 
> > > you mean indeirect rendering? even ten the vo driver must provide a
> > > buffer struct, and it may have pointers/stride it in (will be ignored
> > > by filters but will be give back to vo driver together with export img)
> > 
> > I'm saying some drivers (not current mga_vid implementation, but
> > certainly the mga bes hardware, and probably other cards' scalers)
> > *don't* have to demand the image be at a particular location or have a
> > particular stride. Instead, they could just allocate a block of video
> > memory for the filter to use, and let the filter setup the origin and
> > stride for it, to be passed back as an export-type mpi (or some
> > similar mechanism).
> 
> ah, now i understand.
> the silly thing is that it's actually doable in g1, but not in g2 :))
> 
> i don't like the idea of exporting raw video memory, but it could be better
> to pass stride hints to vo2->get_buffer().
> 
> but actually it has no much sense, in practice.
> why? it's rare that codecs can (effectively) decode to video memory
> directly, and these codecs are designed to accept stride, for this purpose.
> the other thing which can render to slow videoram is some filters, like
> scale, expand, some postprocess/csp conversion, but they all accept stride.

The idea isn't that these filters can't accept stride. It's that they
can do their work without doing anything :))) by manipulating origins
and strides. For example, a crop filter could allocate enough video
memory with the right stride for the previous filter (e.g. scale) to
render the source image into, then 'export' that buffer back to the vo
to just display the 'cropped' part. As another thought, consider
interlaced mess. You could use 2x stride when exporting video memory
back to the vo to only show one field, or do other similar hacks.

Probably most of this can be done by other methods without too much
performance loss, tho, so maybe it's all nonsense. :)

Rich