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):
Can anyone offer a solution?
Feb 5, 2011 at 10:57pm
There’s a thread going on which will interest you and might offer some solutions too:
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.
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
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 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:
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 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:
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 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.
Mar 10, 2011 at 8:40pm
thanks so much Joshua!
it works perfectly with my MacBook Pro!
You must be logged in to reply to this topic.