On our machines (XEON, Linux, 64-bit) we can't mplay full HD sequences in real-time. The biggest we can get is about 75% (using -z) before playback drags to a crawl. It's not a frame loading issue – even after all frames are loaded into memory, playback is still slow, so I'm guessing it's some kind of memory bandwidth issue.

64-bit RV (another image player) also suffers from the same slowness. However, 32-bit FrameCycler plays back in real-time at full-res (!).

We don't have any trouble playing HD quicktimes with mplayer, either. Otherwise I would suspect hardware configuration.

I've tried various combinations in “Video Card Options…”. Through one particular setting I was able to get real-time playback of a single channel, but not RGB.

The video card is pretty beefy, Quadro FX 4400 (NV45GL) with 171.06.01 drivers.

Has anyone else had a similar issue? If so, how did you resolve it?

thanks,
-Mark

have you tried switching to full screen mode?

(CTRL+F I think…)

G

Does mplay -8 -C make a difference?

You can try this env variable:
setenv HOUDINI_OGL_ENABLE_TEXTURE_SEQUENCES 1
It is not on by default because of compatibility issues with older drivers (it could cause Xserver reboots, but your 171 driver is much more recent than that).

Ugh. I just tried this and it makes a huge difference in speed.

Since the 71.74 drivers are extremely old I'd almost be inclined to say this should be on by default. No?

Double-ugh…yeah, just tried it here and it's a huge difference, much faster. I understand the support issues that this can cause having it on by default and users trying out Houdini with old drivers getting a bad first impression, but this strikes me as something so important perhaps there could be a driver version query and use it automatically if the driver > <some version>?

Cheers,

J.C.

It should probably be made an video display option if possible.

There's also an issue with memory usage that needs to be addressed before it can become mainstream. OpenGL textures reside in main memory as well as on the GPU, so MPlay needs to avoid caching the image along with the texture. When using a single texture and piping data through it the way it currently operates, this isn't a big deal. But with a 1:1 texture-to-image setup, it would become very bloated for large sequences.

Because MPlay also needs to be able to read from the images as well (inspection, saving), it unfortunately isn't just a simple change.

edward
Does mplay -8 -C make a difference?

Yes, that definitely made it faster.

twod
You can try this env variable:
setenv HOUDINI_OGL_ENABLE_TEXTURE_SEQUENCES 1
It is not on by default because of compatibility issues with older drivers (it could cause Xserver reboots, but your 171 driver is much more recent than that).

Whoah. Now it plays crazy fast, even without forcing 8-bit loading.

twod
There's also an issue with memory usage that needs to be addressed before it can become mainstream.

It's definitely noticeable – memory gets chewed up a lot faster.

We're going to just use the -8 toggle here for now.

On to the next problem! So, we're also seeing redraw artifacts about halfway down. I seem to recall iplay had a “Double Buffer” option. Is this on by default? Could the redraw problem be due to my LCD screen? Anyone else see this?

cheers

On to the next problem! So, we're also seeing redraw artifacts about halfway down. I seem to recall iplay had a “Double Buffer” option. Is this on by default? Could the redraw problem be due to my LCD screen? Anyone else see this?

Run mplay double buffered with mplay -b d and see if that helps (turning on double buffering interactively is currently rather broken). If not, in the video driver, try “Force to VSync”. That isn't very recommended, though, as it can seriously slow things down.

Ummm….

what happened to the rest of this thread?

good question

related to: http://forums.odforce.net/index.php?showtopic=9294&view=findpost&p=61259 [forums.odforce.net] ?

very odd.. glad I grabbed that envvar before it got lost.. just reposting it just in case:

HOUDINI_OGL_ENABLE_TEXTURE_SEQUENCES 1

In case this thread doesn't get resurrected…

The magic env var is fast, but uses up memory twice as fast.

The -8 (force 8-bit) solution is good enough for us – not as fast as texture sequence, but fast enough to playback at 25 fps realtime.

I hope mplay -8 does the right thing with a 2.2 gamma so that it doesn't lose precision though