jit.qt.movie performance? - again...


    May 27 2006 | 7:19 pm
    Hi all.
    I know that this topic has been up and down the list a couple of hundred times. Nevertheless, I couldn't find the right answers yet...
    I am trying to get the best performance for playing back simultaneously four different Quicktime movies at a time. The patch should be able to re-size and re-position each video file individually right before it starts playing.
    All of my quicktimes are compressed to PhotoJPEG@75%, size 768x576. (Btw: I am dealing with hundreds of video files, so it is not possible to load the files into RAM;)
    I tried - unsuccessfully - different methods of getting the four video streams - with a decent 25 fps - onto the screen: using gl.gl.render and four videoplanes --> too slow (~ 11fps); using named matrices (like in the Jitter Tutorial 16) --> the same; using jit.qt.movie connected to jit.window --> slightly better performance (~15fps), and switching colormode to uyvy gives me another slight improvement, but still not good enough.
    Using the jit.qt.movie direct-to-window function and four different jit.windows seems to work best so far. If the size of the jit.window is the same (or even larger!) than the size of the video file (768x576), all four videos are running at their full frame rate. But if I reduce the size of a jit.window (which I unfortunately have to do sometimes), the frame rate drops drastically (CPU...)
    Am I right that it in this case has to do with some sort of interpolation (or going back to calculating a matrix instead of 'not-bothering' in direct mode?)??
    Is there a way to get around this? (e.g. if I run four files simultaneously in Quicktime, they play smoothly even when I change their size...)
    I am using Jitter 1.5.2, on a G5 dual 2.0, 1.5GB RAM, RAID0, NVIDIA GeForce6800GT
    Thanks for your help!
    Cheers, Holger

    • May 27 2006 | 8:40 pm
      having some patches to look at would be beneficial, so we can see if there are any bugs, or further optimizations to make.
      v a d e //
      www.vade.info abstrakt.vade.info
    • May 27 2006 | 9:45 pm
      On May 27, 2006, at 12:19 PM, Holger Stenschke wrote:
      > I tried - unsuccessfully - different methods of getting the four > video streams - with a decent 25 fps - onto the screen: > using gl.gl.render and four videoplanes --> too slow (~ 11fps); > using named matrices (like in the Jitter Tutorial 16) --> the same; > using jit.qt.movie connected to jit.window --> slightly better > performance (~15fps), > and switching colormode to uyvy gives me another slight > improvement, but still not good enough.
      If you're using four windows, all with the default @sync, it would explain the 15fps figure above. Every window with @sync diminishes the framerate by an integer factor of the video devices frequency. For four outputs @30fps, I would recommend using projectors/monitors which support a native frequency of 120hz, or where possible use two dual-monitor spanning windows with a frequency of 60hz.
      In UYVY mode, I'm able to easily playback 4 DV or photo JPEG files with a single window at full resolution and 30fps or higher, on a G5 with similar specifications you mention, using jitter-examples/video/ uyvy/uyvy-4dv-vidplane.pat. ARGB mode will be markedly slower.
      As for the direct to window problems with downsampling. Everything is out of our hands when this option is on, and QT may be using their expensive, but high quality downsampling function.
      Hope this helps.
      -Joshua
    • May 27 2006 | 10:52 pm
      Hi Joshua, would you be so kind as to explain why multiple windows result fps drop like that - Id love to know a bit more why this is under the hood. Is this jitter specific?
      ie: if I have 4 movies all 30 fps on 4 windows on the same screen, why do I need to have a 120Hz output device, shouldnt I force all my windows to draw at the same time, ie: supply the same sync signal to them? This is common in professional video devices to have a separate external sync 'input', to force drawing to occur simultaneously.
      I assumed that the @sync attribute was only for vertical blanking for GL, so that the video would be drawn in sync with the display device. Why does having multiple windows effect the FPS that drastically?
      v a d e //
      www.vade.info abstrakt.vade.info
    • May 27 2006 | 11:11 pm
      On May 27, 2006, at 3:52 PM, vade wrote:
      > Hi Joshua, would you be so kind as to explain why multiple windows > result fps drop like that - Id love to know a bit more why this is > under the hood. Is this jitter specific? >
      VBL sync. Discussed on the list before (search archives). Each one waits for the VBL sync to swap rather than all swapping simultaneously. It may be possible to address this issue in a future version, but this is the way it works now.
      > ie: if I have 4 movies all 30 fps on 4 windows on the same screen, > why do I need to have a 120Hz output device, shouldnt I force all > my windows to draw at the same time, ie: supply the same sync > signal to them? This is common in professional video devices to > have a separate external sync 'input', to force drawing to occur > simultaneously.
      This would be useful for each device to swap at the same time to prevent "tearing" across mulitple displays, but not within one display.
      > I assumed that the @sync attribute was only for vertical blanking > for GL, so that the video would be drawn in sync with the display > device. Why does having multiple windows effect the FPS that > drastically?
      jit.window also draws with opengl.
      -Joshua
    • May 27 2006 | 11:51 pm
      Thanks, that clears it up 100% for me.
      v a d e //
      www.vade.info abstrakt.vade.info
    • May 30 2006 | 3:16 pm
      Thanks for all your help!
      I found out that the main problem of the performance decrease was the AVID-compression (photo-JPEG 75%) of the videofiles. I still could not figure out which setting caused the problem... I will post it in case I will ever find it...
      Anyway DV-PAL works pretty well now.
      Thanks again. Holger
    • May 30 2006 | 3:34 pm
      Holger Stenschke wrote: > Thanks for all your help! > > I found out that the main problem of the performance decrease was the AVID-compression (photo-JPEG 75%) of the videofiles. I still could not figure out which setting caused the problem... I will post it in case I will ever find it... > I had the same problem with AVID photoJPEG A as well. I re-encoded in QT 7.0 pro in medium quality (MJPEG) and with four videos running at 720x480 I get a respectable 20 FPS using the 4-dv-videoplane method running 4 jit.xfades and jit.slides. > Anyway DV-PAL works pretty well now. > Can you encode into dv-pal through Avid xpress pro hd? > Thanks again. > Holger >
    • May 30 2006 | 5:03 pm
      AVID compression is not a QuickTime standard. It is built for the Avid system and not really made to be used outside of it. In general, it�s best to stay away from codecs based on turnkey systems of any sort. Ken ken@kennethfeinstein.com www.kennethfeinstein.com
    • Sep 01 2014 | 6:15 pm
      Hey folks,
      I am playing back video in Max using qt.movie and am finding that the CPU performance is pretty bad. Playing back a 1280x720 clip keeps the CPU at 55%-60%. Is this normal? I would think that this should not be a big deal, I am running things on a pretty fast machine...
      Model Name: MacBook Pro Processor Name: Intel Core i7 Processor Speed: 2.5 GHz Total Number of Cores: 4 Memory: 8 GB Graphics: AMD Radeon HD 6770M
      I have pasted my test patch below. Any ideas why it is hogging so much CPU power?
    • Sep 01 2014 | 6:56 pm
      what is the codec/length/resolution of the movie ?
    • Sep 01 2014 | 7:05 pm
      Res: 1280 × 720 Codec: Apple ProRes 422 (HQ), Timecode Duration: 00:22
    • Sep 01 2014 | 7:48 pm
      try photojpeg.
      if i run a 22 sec prores 442 movie i get 59% a photojpeg does the same for 35%
      you are aware that 59% cpu on your system is actually ±15% of the total power of your system (=400%) (maybe it even less because of multithreading stuff)
    • Sep 02 2014 | 9:15 am
      you are aware that there is the gpu-route that many claims to be faster ...
      and there is the jit.gl.hap chain that moves in opengl too.