Hey vegac, does the pixeltex route not scale using textures? Surely Octanes at least have enough oomph for an extra context switch and a glCopyTexSubImage2D()? I seem to recall seeing 240 MPixels/sec quoted for SSE, a PAL stream is only like 10 or something...

vegac wrote:The problem with the idea of the initial buffering is that no matter how big of a buffer you make, it will eventually run out because the slower O2's can't keep up with the codec...

Meaning: Even if you buffer 10 frames, by the time you hit frame 15 your buffer is depleted and you're lagging again - the only way to really do this would be to buffer enough to compensate for the remaining of the decode time - ...

lewis wrote:Hey vegac, does the pixeltex route not scale using textures? Surely Octanes at least have enough oomph for an extra context switch and a glCopyTexSubImage2D()? I seem to recall seeing 240 MPixels/sec quoted for SSE, a PAL stream is only like 10 or something...

I had started working on a render-to-texture approach (basically working just like the O2's dmbuffer setup, only without the dmbuffers) but was getting errors about creating a 1024x512 texture + a 1024x512 pbuffer (needed for any video with a width larger than 512 and a height larger than 256 pixels). I'm assuming it came down to lack of vram but hey, all I have is an O2 so it's hard for me to test / debug these sorts of things.

The code is (mostly) in there so some adventurous soul could search through vo_sgi.c for references to use_rendertotex

lewis wrote:Hey vegac, does the pixeltex route not scale using textures? Surely Octanes at least have enough oomph for an extra context switch and a glCopyTexSubImage2D()? I seem to recall seeing 240 MPixels/sec quoted for SSE, a PAL stream is only like 10 or something...

I had started working on a render-to-texture approach (basically working just like the O2's dmbuffer setup, only without the dmbuffers) but was getting errors about creating a 1024x512 texture + a 1024x512 pbuffer (needed for any video with a width larger than 512 and a height larger than 256 pixels).

lewis:
You know you're right, for non-O2 machines the pbuffer wouldn't need to be a power-of-two size (that only is needed for O2 to do the copy-by-reference dmbuffer stuff). That's what I get for copying/pasting code, right?

Still, I'm not in any position to test it right now as all I have is my O2, and I'm about to be out of town for a week, but someone might want to play with it?

Wow. This is really an amazing example of talent and teamwork. Congradulations all around on a very fine job. Once again, I am moved by how this place facilitates great things. Neko, if you are browsing this -- know you made this happen as much as anyone else. Thanks all!

CPU usage is always under 90%,, about 45% on each CPU (max is 200%).
The defaults are nicer to look at (e.g. blacker blacks) than the -vo sgi:pixeltex command line option, but that latter is a smidgen faster. Both are very watchable even at 1920x1200 full screen.

I'll give it a try on the UltimaVision tomorrow. Let me know what else I should try.

Lastly, I intend to take up the native Motif front-end challenge in due course. But would like for a more artistically inclined contributor to sketch out (say a RGB image) of how it should look (be shaped?). I know from my Performer lessons, that graphics context switches between motif and OpenGL can hurt performance so we'll have to watch out for that.