View Full Version : AVI video textures, NeHe concept

01-03-2002, 05:04 PM
NeHe gives a way to play AVI into OpenGL textures in one of his tutorial http://nehe.gamedev.net/tutorials/lesson36.asp

glTexSubImage2D performances are somewhat disappointing, a 512*512 (re)sized AVI gives about 20fps... (the AVI uses almost no CPU).

I was wondering if the AVI routines he uses doesn't play the video on the 2D/3D card: the system sends the video to be played to the video card via DirectDraw, retrieves the result back, and resent it as a texture to the video card.
Any idea?

btw, my config is a P3-700 (FSB 100MHz), 768MB, GF2Ultra (AGP2X).

01-03-2002, 11:46 PM
You can avoid the dib routines if you use NV_rectangle so you can use textures with npot size!

The quality is better and the speed is with biger avis resolutions higher

Tom Nuydens
01-04-2002, 02:46 AM
First of all, like wedge suggested, rescaling every frame to a power-of-two resolution is just nuts. Either use NV_texture_rectangle, or glCopyTexSubImage2D() the unmodified video frame (e.g. 320x240) into a larger texture (e.g. 512x512) and update your texcoords accordingly.

Second, I noticed a bunch of ASM code in there to convert the video frames from BGR to RGB. I find it hard to believe that any cards worth caring about at the moment would not support GL_BGR_EXT properly, so get rid of the manual byte swapping and use BGR directly.

-- Tom

[This message has been edited by Tom Nuydens (edited 01-04-2002).]

01-04-2002, 05:57 AM
NV_texture_rectangle is too limited IMO, but the second option sounds nice... (although some problems with texture repeat modes may arise).

I got rid of the ASM code long ago and use GL_BGR_EXT.

Thanks for the ideas, guys!

01-04-2002, 10:24 AM
NV_texture_rectangle is too limited IMO

Limitted? It's perfect for this application. It may not allow for mipmaps, but you don't want to be computing mipmaps every frame either.

01-04-2002, 01:48 PM
And you don't need mipmaps with anisotropic filtering, so who cares? Certainly not I. Most cards that support GL_BGR_EXT should support anisotropic filtering... or am I wrong? :?

01-04-2002, 02:57 PM
I use GL_SGIS_generate_mipmap for generating the mipmaps on fly, it's very fast... almost invisible.

If you want trilinear anisotropic, you need mipmaps.

01-04-2002, 04:14 PM
And you don't need mipmaps with anisotropic filtering, so who cares? Certainly not I. Most cards that support GL_BGR_EXT should support anisotropic filtering... or am I wrong? :?

I don't know about your last point, but on your first point, yes, you do need mipmaps for consumer-level anisotropic filtering. If you had real anisotropic filtering rather than the crap that nVidia and ATI try to pass off as aniso, then you wouldn't need mipmapping.

01-05-2002, 06:44 AM
Huh? Our anisotropic filtering is most certainly real anisotropic filtering.

- Matt

01-05-2002, 07:40 AM
Korval, I agree with mcraighead...

Anisotropic can be used with mipmaps.
The goal of mipmaps is to minimize the number of required taps for the filter.

I think you say it's not a "true filtering" because it doesn't check tons of taps like "pro" 3D Applications do (eg: LightWave, 3DSMax).
But not using mipmaps in real time would be quite stupid.

01-05-2002, 10:00 AM
Actually, it should work with or without mipmaps, though I'm not sure I've ever tried without.

- Matt

01-05-2002, 11:38 AM
Originally posted by mcraighead:
Actually, it should work with or without mipmaps, though I'm not sure I've ever tried without.

- Matt

Exact... Although the OpenGL specs says the drivers may ignore the asked filtering mode when anistropy is enabled.
But I've tried every OpenGL filters with aniso 2.0 on my GF2 and everything was fine.
I know ATI drivers reverts back to bilinear aniso even when you ask for trilinear aniso, to gain some performance.

01-05-2002, 12:16 PM
Our anisotropic filtering is most certainly real anisotropic filtering.

Real anisotropic filtering requires calculating the actual area of coverage of the pixel in texel space. Real anisotropic filtering would then access all of the texels in this region and filter them based on the ammount of input those texels have on the pixel. Real anisotropic filtering doesn't use mipmaps, and will therefore look more accurate than this aniso-hack that consumer cards use.

01-05-2002, 12:19 PM
Anisotropic filtering doesn't work without MIP maps. We tried this, you have to fake it out by loading level zero and setting max LOD with a MIP map filter, which makes some sense, but wastes TRAM on most implementations. Then it just works across multiple graphics cards.

I agree anisotropic filtering on NVIDIA and ATI is certainly REAL anisotropic filtering. He probably means infinite:1 anisotropy support, but korval is wrong for other reasons. MIP mapping isn't just required for the axis of the major texture derivative, you still need to assemble the footprint from appropriately filtered MIP levels, unless you brute force the texture samples.

In other words even with say 10000000000:1 anisotropic filtering you still need to MIP map for performance/quality reasons, or you'll get aliasing along the axis of the minor texture derivative, without a combinatorally increasing texture probe count.

[This message has been edited by dorbie (edited 01-05-2002).]

01-05-2002, 04:09 PM
OK, obviously I was typing while korval was posting. His position is now clearer.


you are describing ONE way of footprint assembly. That doesn't mean that what all the graphics card companies do is not 'real' anisotropic filtering. They do use REAL anisotropic filtering.

These are quality issues but what is currently done is infact reasonably good quality, it is by no means as bad as you imply. Infact the differences may even be marginal when compared side by side. What shape for example should the projected sample be, what filter profile should it have? Key questions even for your scheme and there's no definitive answer.

Even with your system, MIP mapping would help enormously in assembling the correctly filtered footprint. As I said earlier, if you don't do this you end up with a brute force approach which makes no sense, MIP mapping would speed up your footprint assembly and wouldn't hurt quality. Some might say it's been establised in published work on the subject that an eliptical footprint approximation is good enough and that the rectilinear probe pattern while worse is certainly still anisotropic and a reasonable filter.

Here's a published paper on related work I was involved with. There are some interesting references in the bibliography if you want to bone up on the work I'm talking about, and some decent illustrations of footprint assembly with MIP map textures.

01-05-2002, 06:21 PM
Anisotropic filtering is supposed to solve all minification problems with texture mapping. Put simply, if you use true anisotropic filtering, you will not see any texture aliasing whatsoever in minified textures.

I've seen a software renderer that used anisotropic filtering that was utterly flawless at the checkerboard test (rendering a checkerboard texture and not seeing any filtering artifacts). It looked exactly like a flat, infinite checkerboard, especially along the corner diagonals of the texture.

None of the consumer-level aniso-hacks can accomplish this without turning fully gray at the far end. Turning fully gray is not the right thing to do on the corner-to-corner diagonals, but it is the mipmap thing to do. Real anisotropic filtering will get those right, even as they stretch to infinity.

01-05-2002, 08:25 PM
Anisotropic filtering is not defined as being a perfect filter, it is defined as an anisotropic filter.

Again, these are quality and performance tradeoffs to do with perfect footprint sampling. You should read the reference I offered.

I'll bet the software implementation you saw DID use MIP mapping or some equivalent, even a software implementation would not be so brain dead as to minify using brute force, it is too darned expensive and the required optimization work is well published.

It is certainly more difficult to do a perfect filter in hardware than it is in software. I don't think that discredits current hardware anisotropic texture implementations. It's anisotropic, and it's less than fair to dismiss it by calling it a hack. It is fast, it is anisotropic and it is much better than isotropic MIP mapping. It could be improved upon, but improvements would STILL need MIP maps to be fast.

MIP mapping is NOT incompatible with anisotropic filtering, it is essential for performance.

If better anisotropic filtering is what floats your boat you could take a que from our paper and improve on what's already there.