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


    Jan 30 2006 | 1:58 am
    Hi,
    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

    • Jan 30 2006 | 5:56 pm
      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.
      -Joshua
    • Jan 30 2006 | 6:11 pm
      Hi Joshua,
      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
    • Jan 30 2006 | 6:32 pm
      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. > 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)
      -Joshua