Forums > Jitter

Is Jitter Quicktime Playback Inherently Flawed?

April 17, 2007 | 5:27 am

This is follow up to my recent 7-channel video problem post. In trying to figure out how to fix my problem I went back and tested about every Jitter/Quicktime patch I could possibly think of on multiple computers and my conclusion is that jitter does not play back quicktime as perfectly as quicktime player/pro. I don’t think I’m crazy, because I had someone else test it out on multiple computers in their studio and we both had same problem. For a test file we had a single animation of a 3D ball moving very slowly across the screen. In Quicktime Pro, it always played perfectly. In Jitter it inevitably hickuped at least once (meaning a quick stutter or imperfect motion), no matter what the OS or version of QT or Max/Jitter. How can this be? Are my friend and I both crazy? Oh yeah, the video was 640×480. I tried both photo-jpeg and h.264 on g4 g5 and mac pro. Can someone else please try this? You might need a high quality, slow moving, and very clean image to see it. I’m very interested in what others have to say. Thanks, Aaron


April 17, 2007 | 6:28 am

On 17 avr. 07, at 07:27, Aaron Miller wrote:

> This is follow up to my recent 7-channel video problem post. In
> trying to figure out how to fix my problem I went back and tested
> about every Jitter/Quicktime patch I could possibly think of on
> multiple computers and my conclusion is that jitter does not play
> back quicktime as perfectly as quicktime player/pro. I don’t think
> I’m crazy, because I had someone else test it out on multiple
> computers in their studio and we both had same problem. For a test
> file we had a single animation of a 3D ball moving very slowly
> across the screen. In Quicktime Pro, it always played perfectly.
> In Jitter it inevitably hickuped at least once (meaning a quick
> stutter or imperfect motion), no matter what the OS or version of
> QT or Max/Jitter. How can this be? Are my friend and I both
> crazy? Oh yeah, the video was 640×480. I tried both photo-jpeg
> and h.264 on g4 g5 and mac pro. Can someone else please try this?
> You might need a high quality, slow moving, and very clean image to
> see it. !
> I’m very interested in what others have to say. Thanks, Aaron

Did you use the jit.qt.movie’s "direct to window" mode? Note however
that H264 is highly not recommended for realtime purpose, stay with
Photo-JPEG.

Cheers,
ej


April 17, 2007 | 7:23 am

how are you timing your playback?


April 17, 2007 | 7:26 am

and render it at 50-60% quality

On 17-apr-2007, at 8:28, Emmanuel Jourdan wrote:

> stay with Photo-JPEG


April 17, 2007 | 9:25 am

Hi Aron,
Is your material rendered in PAL? try using NTSC. I complained several
times that Jitter dislikes Pal Material, framerate as well as PAL size.
Let me know if that helps. John.

Aaron Miller schrieb:
> This is follow up to my recent 7-channel video problem post. In trying to figure out how to fix my problem I went back and tested about every Jitter/Quicktime patch I could possibly think of on multiple computers and my conclusion is that jitter does not play back quicktime as perfectly as quicktime player/pro. I don’t think I’m crazy, because I had someone else test it out on multiple computers in their studio and we both had same problem. For a test file we had a single animation of a 3D ball moving very slowly across the screen. In Quicktime Pro, it always played perfectly. In Jitter it inevitably hickuped at least once (meaning a quick stutter or imperfect motion), no matter what the OS or version of QT or Max/Jitter. How can this be? Are my friend and I both crazy? Oh yeah, the video was 640×480. I tried both photo-jpeg and h.264 on g4 g5 and mac pro. Can someone else please try this? You might need a high quality, slow moving, and very clean image to see it.
!
> I’m very interested in what others have to say. Thanks, Aaron
>


April 17, 2007 | 1:32 pm

? why on earth does jitter dislike PAL ?

Also, as per discussions earler in the thread, Jitters QT playback
happens within one thread within the Max scheduler. Performance can
be increased by writing a java external that has multithreaded QT
decompression, not a trivial task, but there is nothing different
about the how things are compressed, just how many simultaneous
threads are active to do QT decoding.

This is the performance difference you are seeing.

as was mentioned, try multiple instances of Max and communicate via
OSC for timing. This will work.

On Apr 17, 2007, at 5:25 AM, John Dekron wrote:

> Hi Aron,
> Is your material rendered in PAL? try using NTSC. I complained
> several times that Jitter dislikes Pal Material, framerate as well
> as PAL size. Let me know if that helps. John.
>
> Aaron Miller schrieb:
>> This is follow up to my recent 7-channel video problem post. In
>> trying to figure out how to fix my problem I went back and tested
>> about every Jitter/Quicktime patch I could possibly think of on
>> multiple computers and my conclusion is that jitter does not play
>> back quicktime as perfectly as quicktime player/pro. I don’t
>> think I’m crazy, because I had someone else test it out on
>> multiple computers in their studio and we both had same problem.
>> For a test file we had a single animation of a 3D ball moving very
>> slowly across the screen. In Quicktime Pro, it always played
>> perfectly. In Jitter it inevitably hickuped at least once
>> (meaning a quick stutter or imperfect motion), no matter what the
>> OS or version of QT or Max/Jitter. How can this be? Are my
>> friend and I both crazy? Oh yeah, the video was 640×480. I tried
>> both photo-jpeg and h.264 on g4 g5 and mac pro. Can someone else
>> please try this? You might need a high quality, slow moving, and
>> very clean image to see it.
> !
>> I’m very interested in what others have to say. Thanks, Aaron
>

v a d e //

http://www.vade.info
abstrakt.vade.info


April 17, 2007 | 2:18 pm

In answer to the questions:

1. I used both photo-jpeg and h.264 with the same results. I was only playing one movie forward at normal rate so h.264 should be fine.

2. No, stupidly, I didn’t try direct to window. I did try it now and it is flawless. I guess I forgot about direct to window because it seems problematic if you are doing multi-channel (as in multi-graphics card output) because it does’t take advantage of the gpu like videoplane does. Right???

3.I tested my timing with metro-qball, metro, and qmetro. All failed the test (except direct to window).

4. Yes, yes, my photo-jped material was rendered at 50%. But I don’t think compression is the isssue. These tests were with just one movie playing but at normal speed!

5. No, my material was not pal. 640×480 photo-jped or h.264 from a 640×480 NTSC source.

6.vade, I hear what your saying, but I’m taking about playing just one movie. I’ll all tests (except direct to window) playback was clearly not perfect. Do I have to write a java external to make one movie play back without hickuping on a Mac Pro!

Anyway, direct to window is beautiful, but what do you (vade, others) suggest I do for multi-channel, multi-graphics card work. Multiple instances of max each doing direct to window? This will be much slower than videoplane, right? Or is there a way to make videoplane as smooth as direct to window??? Many many thanks. This forum is great.

-Aaron


April 17, 2007 | 2:23 pm

You mean by just copy-cloning the Max app and launching several
copies simultaneously?
Mmmm … seems to work indeed.

more infos on the "Jitter Dislikes Pal Material" issue would be
welcome for us 25fps-europeans…

>
>as was mentioned, try multiple instances of Max and communicate via
>OSC for timing. This will work.
>


>3f. Univers KOI8-R
@www.n3krozoft.com
@www.x-xx—x.info
@www.blutgift.de
!"
!"
!"
!"#$%&’()*+,-./
0123456789:;< =>?
@ABCDEFGHIJKLMNO
PQRSTUVWXYZ[]^_


April 17, 2007 | 2:30 pm

I actually have to tend to agree that even playing one movie (even
ntsc) ~can~ drop frames, not play perfectly smooth, even with proper
codecs and such. for most content cases and situations we take it as
an acceptable tradeoff. (BUT msp doesn’t ‘drop samples’ – as long as
the buffers are setup properly, why should quicktime!?) i think It
is related to the ‘inherent’ nature of the jitter low priority
scheduler model – it would be wonderful if there was some upgrade to
the kernel that accounted for this with quicktime playback in
particular.

If there is indeed a programatic way to eliminate the problem please
please c74 provide an example. last night i fell asleep wondering if
it might be possible to make a ‘cpuclock’ qt movie engine, (based on
recipe#31) such that playback is driven from this seemingly smoother
timing source. (even if one needs to forego ‘playing’ the movie in
lieu of driving frames sequentially thus losing embedded audio)

-deK


April 17, 2007 | 2:33 pm

actually – directtowindow does use opengl, just not within jitter.
it is making use of quicktimes embedded use of video card
acceleration, it is virtually identical to using QuickTime player, so
go ahead and do multiple directtowindows :)

for me unfortunately, I am using shaders extensively, so its not an
option, so my query still stands

-deKam

> 2. No, stupidly, I didn’t try direct to window. I did try it now
> and it is flawless. I guess I forgot about direct to window
> because it seems problematic if you are doing multi-channel (as in
> multi-graphics card output) because it does’t take advantage of the
> gpu like videoplane does. Right???
>
> Anyway, direct to window is beautiful, but what do you (vade,
> others) suggest I do for multi-channel, multi-graphics card work.
> Multiple instances of max each doing direct to window? This will
> be much slower than videoplane, right? Or is there a way to make
> videoplane as smooth as direct to window??? Many many thanks.
> This forum is great.
>
>


April 17, 2007 | 2:49 pm

jit.qt.movie autodefers to low priority, but certainly jit.matrixset doesn’t?

Mattijs

Quote: Johnny deKam wrote on Tue, 17 April 2007 16:30
—————————————————-
> I actually have to tend to agree that even playing one movie (even
> ntsc) ~can~ drop frames, not play perfectly smooth, even with proper
> codecs and such. for most content cases and situations we take it as
> an acceptable tradeoff. (BUT msp doesn’t ‘drop samples’ – as long as
> the buffers are setup properly, why should quicktime!?) i think It
> is related to the ‘inherent’ nature of the jitter low priority
> scheduler model – it would be wonderful if there was some upgrade to
> the kernel that accounted for this with quicktime playback in
> particular.
>
> If there is indeed a programatic way to eliminate the problem please
> please c74 provide an example. last night i fell asleep wondering if
> it might be possible to make a ‘cpuclock’ qt movie engine, (based on
> recipe#31) such that playback is driven from this seemingly smoother
> timing source. (even if one needs to forego ‘playing’ the movie in
> lieu of driving frames sequentially thus losing embedded audio)
>
> -deK
>
>
>
>
>
—————————————————-


April 17, 2007 | 3:53 pm

>
> jit.qt.movie autodefers to low priority, but certainly
> jit.matrixset doesn’t?

I’m not so certain… the manuals only say low priority is automatic
for things ‘like drawing to the screen’
Joshua’s in-depth article is also very vague about this. (although
still a quite useful article)
I’ve always assumed if your end destination is a display in jitter,
it IS low priority – why else the qmetros?

http://cycling74.com/story/2005/5/2/133649/9742

Anyway, even if it is high priority, are you suggesting I load my 30
minute HD QT movie into jit.matrixset?
// just let me know as soon as Macs have a Terrabyte RAM option ; )

-deK


April 17, 2007 | 6:58 pm

good news, some answers maybe?…

direct to window with multiple max apps running is working really well. here is the setup:

1 mac pro 2.6ghz
newest qt and max
4x nvidia cards/8 monitors
7 apps running 7 videos on 7 monitors (one monitor for controls)
using direct to window
videos are 30 fps h.264 best quality 640 480
each app is using 12 threads, 25mb mem, 27% cpu usage (this is on one processor right?)
overall user cpu usage is only 45-50%
i haven’t tried running photo-jpeg on this setup yet, but i think these cards are optimized for h.264. if i’m playing them normal speed, shouldn’t they run faster than photo-jpeg?

anyway, thanks to all for the help.

-aaron


April 17, 2007 | 7:11 pm

I dont believe OS X offloads any quicktime decoding to the GPU at all.

what do you mean run faster?

On Apr 17, 2007, at 2:58 PM, Aaron Miller wrote:

>
> good news, some answers maybe?…
>
> direct to window with multiple max apps running is working really
> well. here is the setup:
>
> 1 mac pro 2.6ghz
> newest qt and max
> 4x nvidia cards/8 monitors
> 7 apps running 7 videos on 7 monitors (one monitor for controls)
> using direct to window
> videos are 30 fps h.264 best quality 640 480
> each app is using 12 threads, 25mb mem, 27% cpu usage (this is on
> one processor right?)
> overall user cpu usage is only 45-50%
> i haven’t tried running photo-jpeg on this setup yet, but i think
> these cards are optimized for h.264. if i’m playing them normal
> speed, shouldn’t they run faster than photo-jpeg?
>
>
> anyway, thanks to all for the help.
>
> -aaron

v a d e //

http://www.vade.info
abstrakt.vade.info


April 17, 2007 | 7:31 pm

> 7 apps running 7 videos on 7 monitors (one monitor for controls)
> using direct to window
> each app is using 12 threads, 25mb mem, 27% cpu usage (this is on
> one processor right?)

you probably wouldn’t notice any difference between running 4 apps vs
7, since you only have 4 processors.
on a new octo-core you would though. you’re getting ‘overall’ 50%’
because its 27% x2 since your effectively running 2 apps per
processor – make sense?

btw – instead of activity monitor you might enjoy a little app called
‘menu meters’ that gives you a bar graph of cpu usage for each
processor in the menubar.

> i haven’t tried running photo-jpeg on this setup yet, but i think
> these cards are optimized for h.264. if i’m playing them normal
> speed, shouldn’t they run faster than photo-jpeg?

highly unlikely the cards do anything for h.264 decompression, at
best, there might be some hardware colorspace conversion
recognized. h.264 is NOT ‘faster’ (read more efficient) in terms of
CPU usage. but if all you are doing is playback, and it works, and
you think it looks good, *its all about the end result* (so why
bother transcoding?)

-deK


April 17, 2007 | 8:07 pm

by faster i mean less cpu intensive. but i think you both are right. i looked around on the nvidia site and everything about h.264 is PC only (of course) this is what the site said:

NVIDIA PureVideo technology is the combination of a dedicated video processing core and software that delivers ultra-smooth, high-definition H.264, WMV, and MPEG-2 movies with minimal CPU utilization and low power consumption. And the high-precision subpixel processing enables videos to be scaled to any size, so that even small videos look like they were recorded in high-resolution.

H.264, WMV, and MPEG-2 Hardware Acceleration
NVIDIA PureVideo provides ultra-smooth playback of H.264, WMV and MPEG-2 HD and SD videos with minimal CPU usage.

deK, that’s what i figured about the cpu % being processor specific. and right 4-programs, i don’t know what i was thinking there…


April 17, 2007 | 8:16 pm

Quote: Johnny deKam wrote on Tue, 17 April 2007 17:53
—————————————————-
> >
> > jit.qt.movie autodefers to low priority, but certainly
> > jit.matrixset doesn’t?
>
> I’m not so certain… the manuals only say low priority is automatic
> for things ‘like drawing to the screen’
> Joshua’s in-depth article is also very vague about this. (although
> still a quite useful article)
> I’ve always assumed if your end destination is a display in jitter,
> it IS low priority – why else the qmetros?
>
> http://cycling74.com/story/2005/5/2/133649/9742
>
> Anyway, even if it is high priority, are you suggesting I load my 30
> minute HD QT movie into jit.matrixset?

I don’t think it’s a very strange idea that to handle your frames with timecritical priority may require having the data available in uncompressed form in ram..

> // just let me know as soon as Macs have a Terrabyte RAM option ; )

It shouldn’t take very much longer ;)

Mattijs

>
> -deK
>
>
>
—————————————————-


April 18, 2007 | 9:28 am

>
> more infos on the "Jitter Dislikes Pal Material" issue would be welcome
> for us 25fps-europeans…
>
It is just my experience that
-quicktime movies with NTSC framerate seem to run smoother than 25fps
encoded material
-when using PAL size (768*576) and you play it in quarter size (384*288)
it looks quite pixelated. But when you play it 320*240 it looks much
better although it is not devided by an integer and smaller.

John


April 18, 2007 | 9:37 am

Quote: John Dekron wrote on Wed, 18 April 2007 11:28
—————————————————-
>
> >
> > more infos on the "Jitter Dislikes Pal Material" issue would be welcome
> > for us 25fps-europeans…
> >
> It is just my experience that
> -quicktime movies with NTSC framerate seem to run smoother than 25fps
> encoded material
> -when using PAL size (768*576) and you play it in quarter size (384*288)
> it looks quite pixelated. But when you play it 320*240 it looks much
> better although it is not devided by an integer and smaller.

This could have everything to do with the @adapt 1 property of jit.qt.movie.

Mattijs

>
> John
>
—————————————————-


April 18, 2007 | 9:42 am

I am glad that you can confirm my findings although I would love to be
proven wrong. I do not want to step on somebodies toes, but there are
realtime video applications that can handle this.

-but be assured that is no reason to abandon Max because everything else
is sooo much better in Maxland.

John.

dekam schrieb:
> I actually have to tend to agree that even playing one movie (even ntsc)
> ~can~ drop frames, not play perfectly smooth, even with proper codecs
> and such. for most content cases and situations we take it as an
> acceptable tradeoff. (BUT msp doesn’t ‘drop samples’ – as long as the
> buffers are setup properly, why should quicktime!?) i think It is
> related to the ‘inherent’ nature of the jitter low priority scheduler
> model – it would be wonderful if there was some upgrade to the kernel
> that accounted for this with quicktime playback in particular.
>
> If there is indeed a programatic way to eliminate the problem please
> please c74 provide an example. last night i fell asleep wondering if it
> might be possible to make a ‘cpuclock’ qt movie engine, (based on
> recipe#31) such that playback is driven from this seemingly smoother
> timing source. (even if one needs to forego ‘playing’ the movie in lieu
> of driving frames sequentially thus losing embedded audio)
>
> -deK
>
>
>
>
>


April 18, 2007 | 10:45 am

If there is indeed a programatic way to eliminate the problem please
> please c74 provide an example. last night i fell asleep wondering if it
> might be possible to make a ‘cpuclock’ qt movie engine, (based on
> recipe#31) such that playback is driven from this seemingly smoother
> timing source.

If this was possible, it would be wonderful. Having PAL playback problems here too.

Throws up the possibility of using ‘getclock’ in qt to get the clock of a video output card. This would mean that (theoretically) Jitter could output frames to the card when it was ready to accept them, giving smooth playback (but no GPU functionality).
Or am I getting all mixed up?


April 18, 2007 | 11:01 am

No, it hasn`t. I tried all permutations I could think of.

John.

Mattijs Kneppers schrieb:
> Quote: John Dekron wrote on Wed, 18 April 2007 11:28
> —————————————————-
>>> more infos on the "Jitter Dislikes Pal Material" issue would be welcome
>>> for us 25fps-europeans…
>>>
>> It is just my experience that
>> -quicktime movies with NTSC framerate seem to run smoother than 25fps
>> encoded material
>> -when using PAL size (768*576) and you play it in quarter size (384*288)
>> it looks quite pixelated. But when you play it 320*240 it looks much
>> better although it is not devided by an integer and smaller.
>
> This could have everything to do with the @adapt 1 property of jit.qt.movie.
>
> Mattijs
>
>
>> John
>>
> —————————————————-
>
>
> –
> SmadSteck – http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>


Viewing 22 posts - 1 through 22 (of 22 total)