Brecht

I have a movie, 1920x1080, 20fps, PhotoJPG, 75% quality

Playing it with quicktime, it runs smoothly at 20fps.

Running it on a Macbookpro, 2.4Gzh core 2 duo, Nvidia 8600GT, 2gb ram it plays 6fps.

the patch is simple : jit.qt.movie > jit.window...

Just a little question out of curiosity. 

Playing it with quicktime, it runs smoothly at 20fps. 

Running it on a Macbookpro, 2.4Gzh core 2 duo, Nvidia 8600GT, 2gb ram it plays 6fps. 

the patch is simple : jit.qt.movie > jit.window... 

jitter-vs-quicktime-speed-difference

Yes, I can confirm this, have the same machine. Runs at 6fps, no matter which codec (photojpeg, H264, intermediate,...)

Vlc or Quicktime plays everything as a charm...

A better test would be to send 'window [windowname]' to jit.qt.movie and use Jitter's direct-to-window mode. This avoids the decompression stage and most resembles what QT and VLC are doing.

I'm aware of all the possible optimization possibilities and tricks and workarounds. 

The problem is that I want to use the movie as a texture.

The Nvidia gpu's should be able to decode H.264 (and other codecs) with VP3 (Pure Video HD 3). Is there any option to access this and have the decoding done on the GPU instead of the CPU?

Funny thing is though that the CPU load is around 30~40% when using jit.qt.movie > jit.window... Where is the bottleneck...!?

True. 
I'm aware of all the possible optimization possibilities and tricks and workarounds. 
The problem is that I want to use the movie as a texture. 

The Nvidia gpu's should be able to decode H.264 (and other codecs) with VP3 (Pure Video HD 3). Is there any option to access this and have the decoding done on the GPU instead of the CPU? 

Funny thing is though that the CPU load is around 30~40% when using jit.qt.movie > jit.window... Where is the bottleneck...!?


You can get access to the GPU by using OpenGL objects. Do a search about vade's Jitter Optimization patches. And Apple ProRes 422 is much more efficient that PhotoJPEG. You might also want to try Apple Intermediate Codec.

- Access GPU through jit.gl objects : I'm very aware of this, but the jit.gl objects don't have anything to do with reading/decoding video, you still need jit.qt.movie for this, which basically runs on the CPU, if I'm not mistaken.

- I thoroughly know the optimization techniques. Using uyvy, slabs, and the GPU syncing technique helps to speed things up indeed, but the main bottleneck is still basically the jit.qt.movie object.

- I haven't tried the ProRes codec yet, I have to install FCP

- The final patch needs to run on winXP, which can not decode Apple Intermediate coded.

As Xerxes pointed out, he does not get notably better results with Apple Intermediate, though other posts seem to confirm your statement of it being more efficient. 

- Access GPU through jit.gl objects : I'm very aware of this, but the jit.gl objects don't have anything to do with reading/decoding video, you still need jit.qt.movie for this, which basically runs on the CPU, if I'm not mistaken. 

- The final patch needs to run on winXP, which can not decode Apple Intermediate coded. 

As Xerxes pointed out, he does not get notably better results with Apple Intermediate, though other posts seem to confirm your statement of it being more efficient. 


You're right about this, I'm sorry, I misunderstood the problem. And indeed, it's an interesting discussion. You're right about that jit.qt.movie bottleneck, it's something I've seen in my patches. Currently, I have projects with 3072 X 768 videos and even with a fast MacPro, I'm not able to run as much FPS as I'd like (around 15fps now)

That said, there's a major difference between Apple ProRes and PhotoJPEG. And H.264 is not that much better than PhotoJPEG. I'm curious about what we could do with David Rokeby's softVNS. David's objects can be very efficient. But if you need to run the patch of Windows, it won't work anyway.

As has been mentioned before on these forums, the fastest current path in jitter on both platforms is demonstrated by the following patch, which uses UYVY colormode. With this patch, I am able to play back a 1920x1080p PhotoJPEG 75% 30fps file with a sustained Jitter framerate around 60 fps. Quicktime is also able to play this file back at a sustained 30fps, so I'm not sure what's different with your setup or your file.

However, if I change the jit.qt.movie rate to 2x, jit.qt.movie chokes (framerate moves to 7fps), most likely reaching a critical threshold of cpu, cache, disk access, or related. All systems have a sweet spot beyond which framerate dramatically drops off, and for simple decompression with playback, it's usually not the raw arithmetic capabilities of the CPU which is the bottleneck these days. It's usually related memory at one tier or another. Often it pays to tweak the framerate and bitrate of your source material to tune for whatever this sweet spot is.

Finally, the cheap trick that many people use for dramatic performance increases, is to halve the resolution along the x axis (960x1080). Usually this will look close enough to full resolution, especially when source material is coming from 4:1:1 footage (or a less than awesome sensor) anyway. I would recommend you perform a high quality downsampling filter on the source footage in this case, as is exposed from Compressor, rather than QT Export's nearest neighbor sampling.

As has been mentioned before on these forums, the fastest current path in jitter on both platforms is demonstrated by the following patch, which uses UYVY colormode.  With this patch, I am able to play back a 1920x1080p PhotoJPEG 75% 30fps file with a sustained Jitter framerate around 60 fps. Quicktime is also able to play this file back at a sustained 30fps, so I'm not sure what's different with your setup or your file.

My Machine:
MBP 2.5 GHz Core 2 Duo
Nvidia 8600M GT
2GB RAM
OS X 10.5.7
QT 7.6.2
MaxMSP 5.0.7

This patch runs smoothly at the desired 20fps. I don't get it though, this is exactly what I did. (and every other combination with slabs, gpu synced to movie playback, unique 1, uyvy, etc,...)

Anyway, I will test on the machines that need to run the final application next week. Fingers crossed it'll run as smooth as this. 

Hopefully using Apple ProRes will give things an extra boost.

Anyway, I will test on the machines that need to run the final application next week. Fingers crossed it'll run as smooth as this. 
Hopefully using Apple ProRes will give things an extra boost. 

Jitter vs. Quicktime speed difference