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

[Arpi]

Hi,

> Hey, Arpi. I was thinking earlier about some extra stuff libvo2 should
> support for dr. Maybe some of this is already possible, but I know
> parts aren't yet, and ideally they should be...
> 
> 1. Direct rendering of exported images. Consider the case where you
>    have a vo driver that sits on top of a graphics api, where you make
>    an api call to blit an image from an arbitrary buffer buffer to the
>    display. In this case, the vo driver should be able to pass an
>    export-type image from the last filter directly to the blit call,
>    without copying anything into its own allocated buffer first.

Hmm. it was possible (and natural) in g1, but i somehow forgot it in g2.
Ok it's not completely true...
There is 2 way to get your image to the vo driver:
1. vo driver exports its buffer
2. vo driver implements draw_slice() [which calls graphics api's blit()]

so in normal cases it is always optimal.
and i hope that there are no abnormal cases, where vo driver exports buffers
but it can accept buffers from outside too. if it can use external buffer
without extra copy, it should not export anything, but implement draw_slice().


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


A'rpi / Astral & ESP-team

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