BlackLotus

I need to extract a movie into 8 substreams to display it on a 8-projector wall. Because the projectors have overlap regions, I cannot use the "scissors" to generate 8 substreams, but need to cut out each region per pixel and the scale it to fullscreen.

This already works fine. The problem is, that the output of jit.qt.movie is very slow. The video stream is taken from a DVD with 720 x 405 pixels with 25 fps in size. If I put the video stream directly from jit.qt.movie to a window (with hardware acceleration), by using a named context and using @noaccel 1 , the video runs very smooth (just like playing it in Quicktime).

If I take the matrix output of jit.qt.movie instead, I only get nearly 10 fps. It doesnt matter if I immediately move this matrix into a jit.window, or move it into a jit.gl.videoplane and use jit.gl.render to show it. The problem is that the jit.qt.movie is already delivering the frames in a too slow rate. Regarding cpu-power, there

hopefully someone can help me on this.
I need to extract a movie into 8 substreams to display it on a 8-projector wall. Because the projectors have overlap regions, I cannot use the "scissors" to generate 8 substreams, but need to cut out each region per pixel and the scale it to fullscreen.

If I take the matrix output of jit.qt.movie instead, I only get nearly 10 fps. It doesnt matter if I immediately move this matrix into a jit.window, or move it into a jit.gl.videoplane and use jit.gl.render to show it. The problem is that the jit.qt.movie is already delivering the frames in a too slow rate. Regarding cpu-power, there


jit-qt-movie-matrix-output-too-slow-only-10-fps

Please (always) provide us with a simple example patch that clearly 

illustrates what you're doing, and most likely we can provide you 

One thing which comes to mind is that you might be limited by the VBL 

synchronization. When using multiple windows, the sync attribute 

should be disabled for maximum frame rate, as it otherwise waits for 

the next VBL for each window. So for a 60Hz refresh rate it would be 

60Hz for one window, 30Hz for two, 20Hz for three, ..., and 6Hz for 

10 windows. We might be able to avoid this in future versions, but it 

Another thing which comes to mind is that you may be sending the 

entire video data 8 times to 4 different graphics cards, completely 

saturating the bus. There have been a variety of suggestions posted 

on this list for splitting a single stream in external hardware 

rather than using multiple graphics cards.

Please (always) provide us with a simple example patch that clearly  
illustrates what you're doing, and most likely we can provide you  
specific optimization tips if possible.

One thing which comes to mind is that you might be limited by the VBL  
synchronization. When using multiple windows, the sync attribute  
should be disabled for maximum frame rate, as it otherwise waits for  
the next VBL for each window. So for a 60Hz refresh rate it would be  
60Hz for one window, 30Hz for two, 20Hz for three, ..., and 6Hz for  
10 windows. We might be able to avoid this in future versions, but it  
is otherwise a current limitation.

Another thing which comes to mind is that you may be sending the  
entire video data 8 times to 4 different graphics cards, completely  
saturating the bus. There have been a variety of suggestions posted  
on this list for splitting a single stream in external hardware  
rather than using multiple graphics cards.

thanks for the quick response. I could give you an easy example,

I just right now modified the 01jPlayAMovie.pat-patch from the

Jitter-tutorial. Not much changes : just movie size has been set to

720 x 405, and jitter window accordingly to 720 x 405, nothing else.

http://www.billiger-online.de/01jPlayAMovie_modified.pat

If you now play a video, you will get only about 15 frames. Can clearly

be seen in fast scenes. The source file is an mpeg2-file (direct rip from

a DVD, no changes, just rename a VOB-file for that). I

thanks for the quick response.  I could give you an easy example,
I just right now modified the 01jPlayAMovie.pat-patch from the
Jitter-tutorial. Not much changes : just movie size has been set to
720 x 405, and jitter window accordingly to 720 x 405, nothing else.
http://www.billiger-online.de/01jPlayAMovie_modified.pat

If you now play a video, you will get only about 15 frames. Can clearly
be seen in fast scenes. The source file is an mpeg2-file (direct rip from
a DVD, no changes, just rename a VOB-file for that). I


> thanks for the quick response. I could give you an easy example,

> I just right now modified the 01jPlayAMovie.pat-patch from the

> Jitter-tutorial. Not much changes : just movie size has been set to

> 720 x 405, and jitter window accordingly to 720 x 405, nothing else.

Unfortunately this link is sending binary data as text. Could you 

either post in the message as a text file, or place on a web server 

Without seeing your patch, here's a few suggestions given additional 

1. PhotoJPEG typically gives better performance than MPEG. Temporally 

compressed video typically is more computation intensive.

2. If the movie crops are static, then you would benefit from 

cropping the movie for each computer and playing back at the cropped 

size (i.e. don't introduce realtime computation that isn't necessary)

3. You might benefit from using UYVY colormode (see colorspace 

4. Rather than using srcdim/dstdim, you can also use texture 

coordinates to accomplish cropping on the graphics card (though again 

if this is going to be static, you may do better to crop as a smaller 

matrix and then send to the graphics card via jit.window)

> thanks for the quick response.  I could give you an easy example,
> I just right now modified the 01jPlayAMovie.pat-patch from the
> Jitter-tutorial. Not much changes : just movie size has been set to
> 720 x 405, and jitter window accordingly to 720 x 405, nothing else.
> http://www.billiger-online.de/01jPlayAMovie_modified.pat

Unfortunately this link is sending binary data as text. Could you  
either post in the message as a text file, or place on a web server  
as an archive (.zip or .sit)

Without seeing your patch, here's a few suggestions given additional  
information you've provided:

1. PhotoJPEG typically gives better performance than MPEG. Temporally  
compressed video typically is more computation intensive.

2. If the movie crops are static, then you would benefit from  
cropping the movie for each computer and playing back at the cropped  
size (i.e. don't introduce realtime computation that isn't necessary)

3. You might benefit from using UYVY colormode (see colorspace  
tutorial in JItter manual)

4. Rather than using srcdim/dstdim, you can also use texture  
coordinates to accomplish cropping on the graphics card (though again  
if this is going to be static, you may do better to crop as a smaller  
matrix and then send to the graphics card via jit.window)

jit.qt.movie matrix output too slow (only 10 fps)