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

[Arpi]

Hi,

> > > > > 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

you should do crop before scale/blit/etc. this is the main point!

> 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. :)

imho we should avoid this kind of hacks in g2, at least for now.
i can't see a good enough reason to implement it, and it would be a
hack actually. btw if you really want it, it is doable then easily,
just create a new flag in vfcap.h, for example VFCAP_MESS_WITH_POINTERS
or sth :) and set in vo drivers supporting it.
Then you can check it in vf_crop and change the pointers freely after
get_image. Vo drivers supporting this mess should check (and update the
hw) buffer->planes/stride in their frame_done().
but i still no see advantages of it.

btw, about interlacing.
i'm thinking of interlacing support in vf layer, and so in codecs/vo too.
it would mean a 'field' parameter in mpi, 0=frame 1=top 2=bottom field.
if both vo, codec and filters inbetween supports fields, then codec could
decode per field and pass fields to vo, without 'interlacing them together'.

btw 2, i'm thinking about a bigger change of the codec/vfilter layer,
by dropping away mpi->type (MP_IMGTYPE_*) 'buffering templates' and
introduce get_buffer/release_buffer style (already used in libavcodec).
but i'm not sure if it's a really good idea...


A'rpi / Astral & ESP-team

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