jit.qt.movie playback not smooth

    Feb 05 2011 | 10:48 pm
    I have noticed that playing back a movie using jit.qt.movie seems to be choppy. For example playing a movie that's 640x480 in resolution that's in photo-Jpeg compression, although the frame rate stays above 30, it does not play the movie at a constant speed. This is especially noticeable while the graphic is spinning such as a logo.
    You can download a sample movie here and test to see what I'm talking about (right click and save as): http://www.vjfader.com/transfer/clock_spin.mov
    Can anyone offer a solution?

    • Feb 05 2011 | 10:57 pm
      There's a thread going on which will interest you and might offer some solutions too:
    • Feb 06 2011 | 1:27 am
      sorry, I should of looked first.
      Hope this issue gets resolved soon. For most the jittery (pun) video might not be noticeable, but for professional jobs it's not acceptable.
    • Feb 07 2011 | 6:08 pm
      i totally agree with VJ Fader.
      in the past a smal job was to mix or manipulate 2-3 ntsc sized movies on one screen.
      these days a smal job is to mix or manipulate 2-3 full hd sized movies on 2-3 screens.
      this is only possible with choppy playback using 2-3 mac pros.
      it is really sad, that midsized and big jobs can not be done with this version of jitter anymore :-(
      the jit.qt.movie seems to be 10 years old ....
    • Feb 07 2011 | 8:21 pm
      While we're talking about this (on multiple threads), I thought I'd share another quick and dirty example that touches on many of the things that Vade's examples demonstrate (for reference, his excellent patches are here http://abstrakt.vade.info/?p=147 ). The main additions relate to using a single, fast qmetro (of 1ms rather than 16ms). They also include some monitors to see where the timing is off, and provide some scheduler recommendations (see schedulerlab subpatch).
      Anyway, in the meantime, these patches show how you can get pretty decent playback, before you start adding a bunch of UI objects and other issues that will cause timing issues. In such a case, it is recommended that you run your engine in a separate instance of the application and communicate to your performance patch over the network.
      I was using James' example movie file for testing: http://www.vjfader.com/transfer/clock_spin.mov
      Here are some recommendations from the patch:
      1. use a *single* 1 ms qmetro to drive all of your jit.qt.movie objects.
      2. make sure you use "@unique 1" for all jit.qt.movie objects (@adapt 1 and @colormode uyvy recommended)
      3. disable overdrive if you are only doing jitter work. high priority scheduler work typically interfere's with jitter. You may also want to set a small scheduler slop value in this case.
      4. generate as *few* low/high priority events as possible--i.e. don't use a lot of metronomes or line objects if you can avoid it.
      5. use as few dynamically updating UI elements as possible
      6. if possible, separate your video playback mechanism from your performance patch. communicate over the network with your playback engine running in two separate instances of the applciation (run your playback engine in the runtime version)
      7. if you are using other jit.gl.* objects for mixing or otherwise, drive your render drawing and swapping from a single master movie's output or following slab chain, rather than a separate metronome
    • Feb 07 2011 | 9:51 pm
      And as far as codecs go, some quick anecdotal info that may be of interest: I just ran some tests of this clock animation converted to 1080/30p in the following codecs, and tested with the jit.qt.movie-smoothtest patches:
      PhotoJPEG Apple Intermediate Codec H.264 Apple ProRes 422 Apple ProRes 422 (LT) Apple ProRes 422 (HQ) Apple ProRes 444 with Alpha
      The ProRes codec variants clearly offered the most stable timing with the lowest bandwidth (LT) to the highest bandwidth (4444) respectively. Photo JPEG and AIC didn't perform that well and H.264 was even worse. So for those of you doing HD work, I would highly recommend using the ProRes codecs if possible. With these simple patches I was able to get smooth playback with two 1080/30p sources on a latest generation MacBookPro.
      There is still a stall at the loop points when using these HD versions, which wasn't present with the SD version. This is not avoidable by using loadram, either, though slightly improved. However, QT Player exhibits the same issues trying to loop an HD movie, FWIW.
      Anyway, posting here in case of use to anyone in their attempts to get optimal HD playback.
    • Feb 09 2011 | 7:05 am
      Thanks Joshua for the example patch, and doing the codec comparison.
      Still wishing a out of the box solution, looking forward to the next generation of jit.qt.movie.
    • Mar 10 2011 | 8:40 pm
      thanks so much Joshua!
      it works perfectly with my MacBook Pro! But with the PC (Windows 7), the video is not smooth ... which codec should I use?? I tried h.264, MJPEG, PhotoJpeg etc ... but all the video playback not smooth