[MPlayer-dev-eng] MPlayer OpenGL patch

[Sven Goethel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 15 October 2001 12:42, Arpi wrote:
> > > GL_BRG888 doesn't worked me, neither DRI or Utah-GLX (G400/G550)
> >
> > thats pretty interesting ...
> >
> > opengl 1.2 _must_ support this
>
> yes but is every implementation fully 1.2 conformant?
>
> maybe you should query if it's supported (setting up bgr texture gives an
> error or ok)

well, i test if gl 1.2 is avaiable and give a printout,
but i do not make a gl 1.2 conformance test ;-)

[ may be you should co dri ? cause it runs well on my r128+dri]

>
> > i _have_ tested this on my r128 dri machine (direct & indirect
> > rendering), and nvidia-glx machine - it works best for me.
>
> of course, if it's supported it should be faster than software rgb->bgr
>

> > so i am asking about hardware yuv2rgb ...
> > 	- mmx

the latest version i have send uses mmx !

> > 	- opengl ? (never ever heard about yuv opengl support)
>
> i heard about it somewhere (dri list), maybe it's in 2.0 or soem
> nonstandard extension. at least g400 can do that, it's used by windows
> driver on the second head (yuv overlay is only at first head - second head
> can display yuv and they use texturing engine for scaling)
>
> i also remember seeing somewhere in sgi spechs - highend sgi machines can
> do that... (for video effects/editing)

since it is _no_ std. thing (gl 1.3 specs ?), it is not interesting ..

>
> > may be i have some rtfm stupid config errors, but i get this :
> > 	Cannot init MMX colorspace transform
> > 	No accelerated colorspace conversion found
> > ??
>
> only 16 and 32bpp is mmx-accelerated.
> 24bpp is hard to handle with 64-bit mmx registers...
>

ok - thanxs - i did it allready

it is very inconvinience to being forced to use 32 bit,
than just to use 24 bit.

or should i just skip the colors and use 16 bit ? ;-),
i guess not ..

> > > what about OSD support?
> > > using GL alphablending to render subtitles over the image?
> >
> > yes and no ;-)
> >
> > i have added OSD support, just using the exisiting "writing direct to
> > texture/image" functions - it works for me.
>
> now it works. in libvo2 we will update osd partially, only when it changed.
> it will also allow osd outside the image. so it would be very usefull using
> opengl blending for that.

yes .. then we need images incl. it's (rel.) position to do this.

>
> > because of the bigger diff i just send the complete vo_gl2.c as a bzip2
> > attachment.
>
> ok.
>
> btw i can give you CVS write access. send me login/pass in private.

ok

>
> > CHANGES:
> > 	speed:
> > 		- using opengl BGR, instead of manual component flipping,
> > 		  must work with opengl >= 1.2
> > 		- alignment tweaks
> > 		- texture internal format tweaks
> > 		- update only the dirty-area of the texture
> >
> > 	feature:
> > 		- bilinear filtering on/off (key: 'b')
> > 		- antialiasing on/off (key: 'a') (useless ?)
> > 		- OSD support
> > 		- fullscreen support
>
> ok, i'll commit this
>

but please use the latest one _with_ mmx support
and the little bgr/rgb fix.

> A'rpi / Astral & ESP-team

sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7ywfVHdOA30NoFAARAsfGAJ91Pcq4JjjF2QLPND/GlIYsWk4n3gCeOwF5
p77e5g8dTNW4EQdQMhqY/7w=
=9A1k
-----END PGP SIGNATURE-----