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

[Arpi]

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.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu