Cycling 74 » Topic: jitter significantly slower/worse than quicktime? http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/feed Wed, 19 Jun 2013 13:11:20 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-57817 <![CDATA[jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-57817 Wed, 29 Jun 2011 11:30:41 +0000 jsr_ hi,
i am trying to understand jitter and how it integrates quicktime.

i have a movie. relatively large: 2400×600 apple motion jpeg a 75%. i am trying to play the movie back with jitter through a tripple head to go. i am on a mac mini with a 2.4 ghz intel core 2 duo and 2gb ram.

in quicktime my movie plays back beautifully. drawing approx 26% of 1 CPU.

if i try to play back the movie in max with one of the optimized jitter patches by vade – http://abstrakt.vade.info/?p=147 – i am at about 48% CPU and the playback is stuttering, not smooth at all.

here is my code:

– Pasted Max Patch, click to expand. –

i can understand that max is not 100% as efficient as QT, but how come the result is some much worse? i feel like i must be doing something wrong? is there something i can do to boost jitters performance?

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207438 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207438 Wed, 29 Jun 2011 13:53:50 +0000 jsr_ i’ve searched around the forum and bumped in to DIPS — http://dips.dacreation.com/ — looks interesting… is there any thoughts on difference in performance? would it be an idea to switch to DIPS for QT playback?

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207439 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207439 Wed, 29 Jun 2011 14:00:53 +0000 Julien Bayle interested too.
I have no tested but I’ll follow this thread with attention.

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207440 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207440 Wed, 29 Jun 2011 14:33:57 +0000 efe A friend of mine worked as part of the DIPS dev team and it seems it has stopped for now. I am not sure it they still have those betas for max 5

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207441 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207441 Wed, 29 Jun 2011 14:34:58 +0000 efe About your first question, I am not sure myself how qt is implemented inside jitter but give it a shot to pro res, I’ve had very good experiences with it

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207442 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207442 Wed, 29 Jun 2011 15:07:51 +0000 vade I suspect you are not measuring apples to apples.

Quicktime in 10.6 for many codecs spawns a background process if the new playback engine cannot handle the codec in question. AIC forces a background process to decode.

For example, playing back a Quicktime movie (AIC, 854×480 24fps) in Quicktime looks like it takes 5% CPU on my system.

Jitter uses 24%. Amazing difference. But wait, Quicktime Player spawns a background QTKitServer process to actually decode the frames and send them to Quicktime Player (via the same method Syphon uses, actually), and so we have to take into account the actual decoding applications CPU usage, which in this case is 13%, so Quicktime summed uses around 18% CPU.

Now, Quicktime has the satisfaction of using decoupled processing, so drawing and decoding are asynchronous. Jitter, I do not think has that option, so there is blocking and waiting since things have to happen in specific order (the frame *has* to be output before display updates occur, for example).

For reference, Quartz Composer’s built in movie player uses ~ 22% CPU to play the same movie back, (when using in 32 bit mode). In 64 bit mode, it spawns a background process to do the decode (like Quicktime Player), and that uses an astounding combined ~50% CPU usage).

My custom movie player for Quartz uses a background helper process as well, but total is actually a touch more than Jitter, at 25% CPU.

Now, I cant speak for stuttering issues as I have not seen any in Jitter, but I don’t have a handy large movie to test with.

Of course, I just realized you may be on Windows. Which in that case, I have no idea what to tell you.

]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207443 <![CDATA[Re: jitter significantly slower/worse than quicktime?]]> http://cycling74.com/forums/topic/jitter-significantly-slowerworse-than-quicktime/#post-207443 Fri, 08 Jul 2011 11:33:52 +0000 jsr_ thanks for all the input!
what turned out to be my real problem / solution was fairly silly:
in the process of making my video file i had added 6 audio tracks in QTpro and then saved the file. this did not include the audio tracks in the QT movie, so when playing the clip my computer had to read from 7 different locations on my harddrive, slowing the whole thing down massively. saving the mov selfcontained made a significant improvement in playback quality, and jitter now performs fluently.
this i guess raises questions on why QT could pull off reading data from 7 different locations when jitter couldn’t, but at least for my immediate needs this solves my problems.
/j

]]>