jit.qt.movie playback not smooth

Feb 5, 2011 at 10:48pm

jit.qt.movie playback not smooth

I have noticed that playing back a movie using jit.qt.movie seems to be choppy. For example playing a movie that’s 640×480 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?

#54822
Feb 5, 2011 at 10:57pm

There’s a thread going on which will interest you and might offer some solutions too:

http://cycling74.com/forums/topic.php?id=30899

#197413
Feb 6, 2011 at 1:27am

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.

#197414
Feb 7, 2011 at 6:08pm

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 ….

titan22

#197415
Feb 7, 2011 at 8:21pm

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

#197416
Feb 7, 2011 at 9:51pm

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.

-Joshua

#197417
Feb 9, 2011 at 7:05am

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.

#197418
Mar 10, 2011 at 8:40pm

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

#197419

You must be logged in to reply to this topic.