jit.qt.movie matrix output too slow (only 10 fps)
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.
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
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.
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
On Jan 30, 2006, at 10:11 AM, HZ wrote:
> 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
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)