Bernd

I thought this should be of interest for a lot of users here.

My question is, what is the most efficient (CPU/GPU-wise) way to play back 4 simultaneous movies WITHOUT hiccups (not PhotoJPEG, it?s DV and yes I know I know PhotoJpeg is more efficient but there is no time to convert all those movies). 

I tried ALOT and could find no REAL theoretical/practical solution what would be best. My starting patch for discussion is below (think it as 4 times).

1) Use individual qmetros for jit.gl.render and jit.qt.movie

1) Use one "Master" qmetro to bang everything (in the right? order t b b b erase)

2) Use direct connection to jit.gl.slab from jit.qt.movie

1) Use jit.qt.movie -> jit.gl.texture -> jit.gl.gridshape -> jit.gl.videoplane

To be honest I couldn?t manage this without a loss in quality of the picture.

Anyhow, here is the starting patch for discussion:

My question is, what is the most efficient (CPU/GPU-wise) way to play back 4 simultaneous movies WITHOUT hiccups (not PhotoJPEG, it?s DV and yes  I know I know PhotoJpeg is more efficient but there is no time to convert all those movies). 
I tried ALOT and could find no REAL theoretical/practical solution what would be best. My starting patch for discussion is below (think it as 4 times).

1) Use individual qmetros for jit.gl.render and jit.qt.movie
2) Use @out_name in jit.qt.movie

1) Use one "Master" qmetro to bang everything (in the right? order t b b b erase)
2) Use direct connection to jit.gl.slab from jit.qt.movie

most-efficient-way-to-use-jit-qt-movie-opengl

Did you look at the uyvy-4dv-vidplane.pat Jitter example? Here's a 

2. make sure that @highquality is enabled for all movies (can be set 

before hand inside QT Player Pro if desired)

3. make sure that @unique is enabled for all movies

4. eithger use jit.gl.slab->jit.gl.videoplane or 4 instances of 

jit.gl.videoplane with blend enable and various alpha values to blend 

between them. Make sure that you use @colormode uyvy for jit.gl.slab 

or jit.gl.videoplane (if sending directly).

On a fast dual processor G5 (2.0 Ghz or higher), you should be able 

to play 4 DV streams at 30fps. Not likely on anything less than that. 

As far as hiccups, you may not be able to avoid this when switching 

clips without multiple instances of jit.qt.movie preloaded in 

advance. As always you need to make sure you don't have too much low 

priority processing to ensure optimum framerate. There is no 

advantage to using a named output matrix.

The last suggestion to improve performance is to use 4 separate 

Here's a simple variant of your patch, if you want to use slab. I 

would *definitely* recommend batch converting to PhotoJPEG, however. 

How much time could it take? The performance benefits are noticeable.

Did you look at the uyvy-4dv-vidplane.pat Jitter example? Here's a  
summary:

1. use uyvy colormode for all movies
2. make sure that @highquality is enabled for all movies (can be set  
before hand inside QT Player Pro if desired)
3. make sure that @unique is enabled for all movies
4. eithger use jit.gl.slab->jit.gl.videoplane or 4 instances of  
jit.gl.videoplane with blend enable and various alpha values to blend  
between them. Make sure that you use @colormode uyvy for jit.gl.slab  
or jit.gl.videoplane (if sending directly).

On a fast dual processor G5 (2.0 Ghz or higher), you should be able  
to play 4 DV streams at 30fps. Not likely on anything less than that.  
As far as hiccups, you may not be able to avoid this when switching  
clips without multiple instances of jit.qt.movie preloaded in  
advance. As always you need to make sure you don't have too much low  
priority processing to ensure optimum framerate.  There is no  
advantage to using a named output matrix.

The last suggestion to improve performance is to use 4 separate  
drives, one for each media file.

Here's a simple variant of your patch, if you want to use slab. I  
would *definitely* recommend batch converting to PhotoJPEG, however.  
How much time could it take? The performance benefits are noticeable.

Thanks Joshua for your explanations and the example.

1) My basic patch led to the conclusion that I wanted to mix the 4 movies on one screen (jit.window). In fact they should go to 4 different jit.windows (screens) on different monitors.

So the question: Is there a difference when using one "Master" qmetro for all render contexts or is it not relevant to have multiple qmetros.

2) is there a performance penalty when sending jit.qt.movie?s output through a outlet of a patch to an inlet of another patch (in opposite to using @out_name).

If you are going to loop the 4 videos you might be better to preload

them in advance using loadram, If yout ram is large enought. Else the

seperate qt.movies takes up alot of bandwith to and from your HD.

If you are going to loop the 4 videos you might be better to preload
them in advance using loadram, If yout ram is large enought. Else the
seperate qt.movies takes up alot of bandwith to and from your HD.

When getting the time for a jit.qt.movie is it more efficient to trigger the gettime message with the same qmetro (i.e. every 20ms [t b gettime] compared to a gettime message that comes from another qmetro every 200ms (and probably interferes with the faster 20ms "playout" thread) ?

Naturally, executing the "gettime" function takes some time, and the 

less you send the message, the less time, overall, it will take. Why not 

use a qlim object to thin out the data from 20ms to 200ms or so, and 

trigger the gettime message that way, instead of having a 2nd qmetro?

Naturally, executing the "gettime" function takes some time, and the 
less you send the message, the less time, overall, it will take. Why not 
use a qlim object to thin out the data from 20ms to 200ms or so, and 
trigger the gettime message that way, instead of having a 2nd qmetro?

On Feb 22, 2006, at 12:05 AM, Bernd wrote:

> 1) My basic patch led to the conclusion that I wanted to mix the 4 

> movies on one screen (jit.window). In fact they should go to 4 

> different jit.windows (screens) on different monitors.

> So the question: Is there a difference when using one "Master" 

> qmetro for all render contexts or is it not relevant to have 

Note that performance slows down for multiple windows with sync 

enabled. As previously mentioned on the list, divide the monitor 

refresh rate by the number of windows with sync enabled--e.g. for 4 

windows @ 30 fps, you'll need a monitor refresh rate of 120 hz(fps). 

This is often not a possibility. If you are limited to a 60 hz(fps), 

you should not use more than two instances of jit.window with sync 

enabled (the default). You can sometimes span a window across two 

monitor outputs without problem if they are both on the same card. 

Another solution is to use a 1280x960 output and send to a quad 

splitter box, or four converters which can take a subrectangle (see 

Johnny DeKam's posts on this subject). Otherwise, you should use two 

machines to get four outputs. This is probably desirable anyways, as 

bandwidth to a second card (unless PCI-E) is poor.

As for the qmetro being global or movie specific, it should not much 

matter from a performance standpoint, however a single qmetro might 

> 2) is there a performance penalty when sending jit.qt.movie?s 

> output through a outlet of a patch to an inlet of another patch (in 

> 1) My basic patch led to the conclusion that I wanted to mix the 4  
> movies on one screen (jit.window). In fact they should go to 4  
> different jit.windows (screens) on different monitors.
>
> So the question: Is there a difference when using one "Master"  
> qmetro for all render contexts or is it not relevant to have  
> multiple qmetros.

Note that performance slows down for multiple windows with sync  
enabled. As previously mentioned on the list, divide the monitor  
refresh rate by the number of windows with sync enabled--e.g. for 4  
windows @ 30 fps, you'll need a monitor refresh rate of 120 hz(fps).  
This is often not a possibility. If you are limited to a 60 hz(fps),  
you should not use more than two instances of jit.window with sync  
enabled (the default). You can sometimes span a window across two  
monitor outputs without problem if they are both on the same card.  
Another solution is to use a 1280x960 output and send to a quad  
splitter box, or four converters which can take a subrectangle (see  
Johnny DeKam's posts on this subject). Otherwise, you should use two  
machines to get four outputs. This is probably desirable anyways, as  
bandwidth to a second card (unless PCI-E) is poor.

As for the qmetro being global or movie specific, it should not much  
matter from a performance standpoint, however a single qmetro might  
simplify your patcher logic.

> 2) is there a performance penalty when sending jit.qt.movie?s  
> output through a outlet of a patch to an inlet of another patch (in  
> opposite to using @out_name).

The dvducks.mov example movie is compressed in DV/DVCPRO - NTSC, 

Does the other DV formats (DVPRO - PAL, DVCPRO50, ...) also have the 

same advantage using the uyvy colour-mode? Is there an optimal DV 

compression? And what about frame size ... could I for instance go 

576x384 or 480x320 and get even faster results?

The dvducks.mov example movie is compressed in DV/DVCPRO - NTSC,  
720x480.

Question is:
Does the other DV formats (DVPRO - PAL, DVCPRO50, ...) also have the  
same advantage using the uyvy colour-mode? Is there an optimal DV  
compression? And what about frame size ... could I for instance go  
576x384 or 480x320 and get even faster results?

In the quest for more frames per second
~Carl Emil


Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in NTSC 

which means colors wont bleed and text will stay sharp, basically it 

looks better if you start off with an uncompressed/clean source. You 

can do a test yourself and take some uncompressed footage and encode 

Heres a pixel sampling link that explains it: 

DV-FAQ-tech.html#colorSampling - but note there are some caveats with 

Now, DV-NTSC and DV-PAL is a video standard, but DV-25, DV-50 etc are 

codecs - you can definitely play with the frame size - smaller frame 

means smaller matrix in jitter which means less data to process each 

'frame', thus higher frame rates. UYVY is a good mode to use if you 

use openGL, as it results in lower bandwidth to the video card (YUV 

chroma is half sampled, irc, compared to RGB). although slightly 

unintuitive, sometimes lowering the frame rate of your source clip 

results in faster overall processing, esp. if you do many jitter 'fx' 

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I 

You will not be saved by the Holy Ghost. You will not be saved by the 

Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in NTSC  
which means colors wont bleed and text will stay sharp, basically it  
looks better if you start off with an uncompressed/clean source. You  
can do a test yourself and take some uncompressed footage and encode  
it to different codecs.

Heres a pixel sampling link that explains it: http://www.adamwilt.com/ 
DV-FAQ-tech.html#colorSampling - but note there are some caveats with  
transcoding/generational loss, etc.

Now, DV-NTSC and DV-PAL is a video standard, but DV-25, DV-50 etc are  
codecs - you can definitely play with the frame size - smaller frame  
means smaller matrix in jitter which means less data to process each  
'frame', thus higher frame rates. UYVY is a good mode to use if you  
use openGL, as it results in lower bandwidth to the video card (YUV  
chroma is half sampled, irc, compared to RGB). although slightly  
unintuitive, sometimes lowering the frame rate of your source clip  
results in faster overall processing, esp. if you do many jitter 'fx'  
in serial.

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I  
LIVE! I LIVE! I LIVE! I LIVE!

You will not be saved by the Holy Ghost. You will not be saved by the  
God Plutonium.

> Heres a pixel sampling link that explains it: 

> www.adamwilt.com/DV-FAQ-tech.html#colorSampling

DV makes more sense now. This one helped too:

http://www.dvcollections.com/support_dvcompress.html

> You can do a test yourself and take some uncompressed footage and 

I tried that and it seems like PAL 640x480 is a bit slower than NTSC 

720x480 which makes sense according to the colour information you 

> Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in 

> NTSC which means colors wont bleed and text will stay sharp

I don't know about that, I couldn't se any notable difference in 

sharpness on text nor photo when comparing PAL and NTSC. Perhaps the 

colours in PAL are a bit more fresh, but that's it. Comparing NTSC 

720x480 and photo-jpeg in 400x300 i found that they look equally 

blurred but NTSC+UYVY is still faster and has a smaller file size. I 

saw almost no visible difference comparing NTSC 720x480 and NTSC 

640x480, but I squeezed out a couple of extra frames per second using 

Please respond if you think there is a better video format for 

> Heres a pixel sampling link that explains it: http:// 
> www.adamwilt.com/DV-FAQ-tech.html#colorSampling
DV makes more sense now. This one helped too:
http://www.dvcollections.com/support_dvcompress.html

> You can do a test yourself and take some uncompressed footage and  
> encode it to different codecs.
I tried that and it seems like PAL 640x480 is a bit slower than NTSC  
720x480 which makes sense according to the colour information you  
mentioned.

> Well, DV pal has a nicer color space imo, its 4:2:0 vs 4:1:1 in  
> NTSC which means colors wont bleed and text will stay sharp
I don't know about that, I couldn't se any notable difference in  
sharpness on text nor photo when comparing PAL and NTSC. Perhaps the  
colours in PAL are a bit more fresh, but that's it. Comparing  NTSC  
720x480 and photo-jpeg in 400x300 i found that they look equally  
blurred but NTSC+UYVY is still faster and has a smaller file size. I  
saw almost no visible difference comparing NTSC 720x480 and NTSC  
640x480, but I squeezed out a couple of extra frames per second using  
640x480.

It seems like this works best for me:
Format: NTSC (DV/DVCPRO)
Frame-size: 640x480
Frame-rate: 25
Pixel aspect: Square
Scan mode: progressive
Field dominance: none
Audio: no track!

Please respond if you think there is a better video format for  
jit.qt.movie + opengl.

how do you do when several movies have different fps ?

logically i'll think to set the metro to the highest with @unique 1.

or do you use one metro for each movie and one with the higest speed for the render ?

how do you do when several movies have different fps ?
logically i'll think to set the metro to the highest with @unique 1.
or do you use one metro for each movie and one with the higest speed for the render ?

Most efficient way to use jit.qt.movie + OpenGL