[mythtv] mythtv-vid branch needs testing

[Daniel Kristjansson]

On Fri, 2007-08-17 at 10:38 +1000, Daniel Burr wrote:
> On Thu, 2007-08-16 at 16:36 +0100, Mark Kendall wrote:
> > If you look closely at the mplayer code however (and the nvidia paper
> > the code was based on), you'll see that it only works (properly) when
> > using normal, 'power of two' textures. It will not work with
> > rectangular textures, which are the preferred choice from a quality
> > perspective and the default when available.
> 
> Can this be worked around by allocating a square texture which has a
> side length equal to the longer side of the rectangle?  The
> non-displayable parts of the square could be initialised with copies of
> the top or bottom row data (not a solid colour, else this colour would
> be used for the filtering at the top/bottom and cause odd colours),
> e.g.:
> 
> 640x480                =>  640x640
> +---------+                +---------+
> |         | <- top row     |         | <-top row repeated n times
> |         |            =>  |=========| <-original top row
> |         |                |=original|
> +---------+                |==data===|
>                            |=========|
>                            +---------+

It probably has to be a power of two texture, i.e. for 640x480 you
would use 1024x1024 textures, for 1920x1088 you would use 2048x2084
textures. There is no loss of quality but you do waste some memory.
All algorithms that work on regular power of two textures will work
with rectangular textures, you just have to remap the indexes and
scaling is not as efficient, so if the algorithm relies on multi-scale
views it may lose some efficiency.

I haven't seen the mplayer code or the nvidia paper, but I bet they
are using the built in filtered scale code for power of two textures.
You can't use OpenGL mipmap commands with rectangular textures so you
have to implement it yourself, which I believe is what Mark Kendall
is doing. His approach will take a little longer but be much more
flexible and memory efficient in the end.

-- Daniel