Forums > Jitter

Jitter vs. Quicktime speed difference

September 18, 2009 | 10:22 am

Hey there,

Just a little question out of curiosity.

I have a movie, 1920×1080, 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.window…

How is this possible?!

September 18, 2009 | 10:50 am

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…

What’s happening?

September 18, 2009 | 11:49 am

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


September 18, 2009 | 12:01 pm

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.window… Where is the bottleneck…!?

September 18, 2009 | 12:39 pm

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.

September 18, 2009 | 12:51 pm

– Access GPU through objects : I’m very aware of this, but the objects don’t have anything to do with reading/decoding video, you still need 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 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.

September 18, 2009 | 1:10 pm

You’re right about this, I’m sorry, I misunderstood the problem. And indeed, it’s an interesting discussion. You’re right about that 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.

September 18, 2009 | 5:17 pm

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
OS X 10.5.7
QT 7.6.2
MaxMSP 5.0.7

However, if I change the rate to 2x, 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 (960×1080). 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.

Hope this helps.


– Pasted Max Patch, click to expand. –
September 19, 2009 | 10:09 am

Thanks Joshua,

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.


Viewing 9 posts - 1 through 9 (of 9 total)

Forums > Jitter