joshua goldberg

movie playback of 1080p content is substantially lower quzlity using jit.qt.movie @window direct mode than it is using the quicktime playing in fullscreen playback mode.

machine in question: intel mac mini, 1.67 mhz, current system, current max/jit

i used the 1080p ratatouille movie trailer here: 

http://www.apple.com/trailers/disney/ratatouille/

 i used quicktime player to export it as a quicktime movie, codec MJPEG A, quality high, no fast start.

the resulting compressed movie played back seamlessly with the quicktime player, but when using the following patch, playing it back into a jit.window using @window direct, quality was stuttery and teary.

i used the 1080p ratatouille movie trailer here:  http://www.apple.com/trailers/disney/ratatouille/  i used quicktime player to export it as a quicktime movie, codec MJPEG A, quality high, no fast start.

the resulting compressed movie played back seamlessly with the quicktime player, but when using the following patch, playing it back into a jit.window using @window direct, quality was stuttery and teary.


hd-performance-with-jit-qt-movie-in-window-direct-mode

I've had the same problems with the same setup as you. In the end it seemed the best way to play back HD movies was to use Applescript to control QuickTime player from Max.

I read the video, then press 'window boobah' and without enabling the metro, the video starts playing and is being displayed properly in the window. That's intended behaviour, right?

Then, when I set the window to fullscreen or move the window to another screen, the window stops updating (but the sound continues playing). Only when I switch on the metro the window starts being updated again. And when I switch the metro off it continues being updated properly. Seems a little buggy.

Anyway, I noticed no hiccups of any kind, neither in the small window or fullscreen.

Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad Intel 2.66

> use Applescript to control QuickTime player from Max.

Compare it to straight quicktime player, there are framerate hiccups 

(whose size ad frequency vary with your performance settings and 

window update intervals), but they are there. I believe this is 

because of low priority queues needing to be serviced interrupting/ 

blocking drawing, but I am speculating about the cause. However, I 

have seen this on all systems I work with, from Octo Mac Pros with 

It is not as bad with uncompressed media, and much more noticeable 

with higher compressed video (h.264), and again I believe this is 

because decompression and drawing happen serially in the same thread 

(again, speculation), but regardless of the cause, it is there 

And it gets worse when playing that video to a GL world without 

On Aug 30, 2007, at 4:49 AM, Mattijs Kneppers wrote:

> I read the video, then press 'window boobah' and without enabling 

> the metro, the video starts playing and is being displayed properly 

> in the window. That's intended behaviour, right?

> Then, when I set the window to fullscreen or move the window to 

> another screen, the window stops updating (but the sound continues 

> playing). Only when I switch on the metro the window starts being 

> updated again. And when I switch the metro off it continues being 

> updated properly. Seems a little buggy.

> Anyway, I noticed no hiccups of any kind, neither in the small 

> Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad 

> Hard- and software for interactive audiovisual sampling

Compare it to straight quicktime player, there are framerate hiccups  
(whose size ad frequency vary with your performance settings and  
window update intervals), but they are there. I believe this is  
because of low priority queues needing to be serviced interrupting/ 
blocking drawing, but I am speculating about the cause. However, I  
have seen this on all systems I work with, from Octo Mac Pros with  
Quadro FX 4500's to Powerbooks.

It is not as bad with uncompressed media, and much more noticeable  
with higher compressed video (h.264), and again I believe this is  
because decompression and drawing happen serially in the same thread  
(again, speculation), but regardless of the cause, it is there  
regardless of codecs.

And it gets worse when playing that video to a GL world without  
direct to window, even with YUV.

>
> Joshua,
>
> I read the video, then press 'window boobah' and without enabling  
> the metro, the video starts playing and is being displayed properly  
> in the window. That's intended behaviour, right?
>
> Then, when I set the window to fullscreen or move the window to  
> another screen, the window stops updating (but the sound continues  
> playing). Only when I switch on the metro the window starts being  
> updated again. And when I switch the metro off it continues being  
> updated properly. Seems a little buggy.
>
> Anyway, I noticed no hiccups of any kind, neither in the small  
> window or fullscreen.
>
> Mattijs
>
> Max 4.6.3, Jitter 1.6.3, Mac OS 10.4.10, Quicktime 7.2.0, Quad  
> Intel 2.66
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

Quote: Kyred wrote on Thu, 30 August 2007 13:50

----------------------------------------------------

> > use Applescript to control QuickTime player from Max.

    open ("/Users/me/Documents/Video/MyVideo.mov" as POSIX file)

    set looping of document 1 to true

You can use the tap.applescript external to launch it.

Quote: Kyred wrote on Thu, 30 August 2007 13:50
----------------------------------------------------
> > use Applescript to control QuickTime player from Max.
>
> Oh ! interesting ! is it hard to do ?
----------------------------------------------------

tell application "Finder"
	open ("/Users/me/Documents/Video/MyVideo.mov" as POSIX file)
end tell

tell application "QuickTime Player"
	set looping of document 1 to true
	present document 1 scale screen
end tell

But with this method, should you want to queue more than one movie 

back to back, as separate files, dont you get the weird QT window 

pop over? Can you queue movies seamlessly back to back without 

leaving fullscreen at the end of one movie?

Curious , as I have not had the chance to try this in any capacity, 

if the above is possible, I wish I knew a few days ago! :)

I have a patch (attached to this mail) I am using for a performance, 

an incredibly paired down/simple qt/gl patch, on a quad 2.5 Ghz G5 

with 8GB of ram and NVidia Quadro FX 4500. It cues with movies with 

19 jit.qt.movies with @preroll 1, @unique 1, @colormode uyvy, @adapt 

Only one movie plays at a time, and bangs are gated and switched 

'around' all others so only one is active. All movies are stopped 

untill needed. I have one GL object, a slab, @automatic 0. I use a 

uyvy2rgba shader and a simple 'fade to color' custom shader. I have 

playback issues if the shaders are not in the pipeline as well, just 

There are no ui objects. not even an fpsgui. Main timing is triggered 

Playing DVCProHD (that is, 1280x720p@60Hz) footage with this simple 

of a patch will continuously stutter. Very visibly.

Direct to window leads to even worse performance (oddly enough). if 

I follow the direct to window noaccel route in fullscreen, I get 

consistent very low frame rates in full screen, regardless of menubar 

being visible or windows being overlayed. Playback seems somewhat 

better, but still not in any way shape or form 'right' in a windowed 

mode. Replacing 'fullscreen' with a rect message that still takes up 

the full screen still results in impressive stuttering for such a 

machine. I have this behavior on the quad and on my macbook pro.

For reference, I have benchmarked the drives (they are 90% empty) and 

there is more than sufficient disk througput.

Movies can be long, but nothing but playback at rate 1 occurs. this 

I have confirmed that Quicktime and Final Cut can play back these 

clips to the same size output (second monitor) without any visible 

Converting to UYVU seemed to somewhat improve the situation, but 

I have attached a version of the patch with cuing missing. I feel as 

though I havent gotten a straight answer from anyone about this when 

I send a patch, except the 'it works for me'. Maybe Im better at 

I know this topic is a little sore, so apologies Cycling, I really 

hope this is not seen as a nagging/get your shit together/etc sort of 

a rant, I am attaching the patch in an attempt to isolate or identify 

any strategies I (and others) can use to, in the real world, on real 

systems in real patches, get top performance with Jitter for high 

I feel i should note that, myself withstanding, other people working 

with me have noted the stuttering, but deem it somewhat acceptable 

(so we are sticking with Jitter for its flexibility and ease to 

change cues/timing etc). So it isnt "just me".

Ive also played back these files with the movie and slab help files 

with the @adapt 1 added to jit.qt.movie, and see the same stuttering 

I do not expect or want any immediate fixes for this either, im 

simply curious at this point what the response will be. Again, 

apologies for bringing /extending this sore topic. Thanks in advance.

p.s. Yes, I am aware that other codecs might free the CPU and 

scheduler to do more, but, at this point, I dont think that is much 

But with this method, should you want to queue more than one movie  
back to back, as separate files, dont you get the  weird QT window  
pop over? Can you queue movies seamlessly back to back without  
leaving fullscreen at the end of one movie?

Curious , as I have not had the chance to try this in any capacity,  
if the above is possible, I wish I knew a few days ago! :)

I have a patch (attached to this mail) I am using for a performance,  
an incredibly paired down/simple qt/gl patch, on a quad 2.5 Ghz G5  
with 8GB of ram and NVidia Quadro FX 4500. It cues with movies with  
19 jit.qt.movies with @preroll 1, @unique 1, @colormode uyvy, @adapt  
1 and @loop 0.

Only one movie plays at a time, and bangs are gated and switched  
'around' all others so only one is active. All movies are stopped  
untill needed. I have one GL object, a slab, @automatic 0. I use a  
uyvy2rgba shader and a simple 'fade to color' custom shader. I have  
playback issues if the shaders are not in the pipeline as well, just  
so you know.

There are no ui objects. not even an fpsgui. Main timing is triggered  
by a qmetro 2.

Playing DVCProHD (that is, 1280x720p@60Hz) footage with this simple  
of a patch will continuously stutter. Very visibly.

Direct to window leads to even worse performance (oddly enough).  if  
I follow the direct to window noaccel route in fullscreen, I get  
consistent very low frame rates in full screen, regardless of menubar  
being visible or windows being overlayed. Playback seems somewhat  
better, but still not in any way shape or form 'right' in a windowed  
mode. Replacing 'fullscreen' with a rect message that still takes up  
the full screen still results in impressive stuttering for such a  
machine. I have this behavior on the quad and on my macbook pro.

For reference, I have benchmarked the drives (they are 90% empty) and  
there is more than sufficient disk througput.

Movies can be long, but nothing but playback at rate 1 occurs. this  
is simply sending 'start' to the movies.

I have confirmed that Quicktime and Final Cut can play back these  
clips to the same size output (second monitor) without any visible  
framerate drops, hiccups or glitches.

Converting to UYVU seemed to somewhat improve the situation, but  
stuttering still happens.

I have attached a version of the patch with cuing missing. I feel as  
though I havent gotten a straight answer from anyone about this when  
I send a patch, except the 'it works for me'. Maybe Im better at  
seeing stuttering?

I know this topic is a little sore, so apologies Cycling, I really  
hope this is not seen as a nagging/get your shit together/etc sort of  
a rant, I am attaching the patch in an attempt to isolate or identify  
any strategies I (and others) can use to, in the real world, on real  
systems in real patches, get top performance with Jitter for high  
quality playback.

I feel i should note that, myself withstanding, other people working  
with me have noted the stuttering, but deem it somewhat acceptable  
(so we are sticking with Jitter for its flexibility and ease to  
change cues/timing etc). So it isnt "just me".

Ive also played back these files with the movie and slab help files  
with the @adapt 1 added to jit.qt.movie, and see the same stuttering  
behavior.

I do not expect or want any immediate fixes for this either, im  
simply curious at this point what the response will be. Again,  
apologies for bringing /extending this sore topic. Thanks in advance.

p.s. Yes, I am aware that other codecs might free the CPU and  
scheduler to do more, but, at this point, I dont think that is much  
the issue?

Hi vade, the attachment doesn't show up on the forum :/

Could you post the attachment via the forum or upload the patch somewhere and post the link?

Hi vade, the attachment doesn't show up on the forum :/ 

hello vade, for a playback project last year we made a basic app with 

jitter for mixing two pal quicktime files (720*576). we tried 

everything we could think of and everything that people on the list 

suggested, but it kept stuttering. the ammount of pixels we used with 

two files are roughly the same as you do with one file. if you work 

on lower resolution the stuttering will probably dissapear......;-(

we are also very interested to know what causes these playback 

problems and it would be great to know when they are scheduled to be 

hello vade, for a playback project last year we made a basic app with  
jitter for mixing two pal quicktime files (720*576). we tried  
everything we could think of and everything that people on the list  
suggested, but it kept stuttering. the ammount of pixels we used with  
two files are roughly the same as you do with one file. if you work  
on lower resolution the stuttering will probably dissapear......;-(
we are also very interested to know what causes these playback  
problems and it would be great to know when they are scheduled to be  
solved.
best lucas


Yes I'd love to comment but, without wanting to sound too bitter, 

ever since my last attempt at doing proper fullscreen pal dv mixing 

("Pmac quad 4xdv playback trouble" thread sept. 2006) and failing 

miserably I have given up all hope of doing such a thing in jitter. 

I've kept an archive of the recurring discussions surrounding this 

topic and to my knowledge no one, except maybe dekam, dunno, has 

managed to come to an agreeable result or solution (= proper 

stutterless and 'artifact-less' playback when fullscreen mixing two 

or more streams of DVPAL or higher resolution material). I've done 

some more testing since last september, mainly looking for other 

software solutions, and I've found that the problems I was 

encountering were definetely not hardware related (harddrive speeds, 

graphic cards, etc.). Software like Catalyst (

stuff with similar hardware setups. So my conclusion is that it must 

be a problem somewhere inside jitter, and I'm waiting for the next 

grand update to see if anything has changed .. In the mean time i'll 

have a look at your patch and report back. Could you possibly put 

Yes I'd love to comment but, without wanting to sound too bitter,  
ever since my last attempt at doing proper fullscreen pal dv mixing  
("Pmac quad 4xdv playback trouble" thread sept. 2006) and failing  
miserably I have given up all hope of doing such a thing in jitter.  
I've kept an archive of the recurring discussions surrounding this  
topic and to my knowledge no one, except maybe dekam, dunno, has  
managed to come to an agreeable result or solution (= proper  
stutterless and 'artifact-less' playback when fullscreen mixing two  
or more streams of DVPAL or higher resolution material). I've done  
some more testing since last september, mainly looking for other  
software solutions, and I've found that the problems I was  
encountering were definetely not hardware related (harddrive speeds,  
graphic cards, etc.). Software like Catalyst (http://www.samsc- 
pm.com/) or Pandora (http://coolux.de/) has no problems doing similar  
stuff with similar hardware setups. So my conclusion is that it must  
be a problem somewhere inside jitter, and I'm waiting for the next  
grand update to see if anything has changed .. In the mean time i'll  
have a look at your patch and report back. Could you possibly put  
some testing material online ? (.mov)

All I can say at this point is that we take these complaints 

seriously and are investigating some possible solutions. We can't 

commit to anything at this point and Max 5 is currently our biggest 

priority. Since we aren't a fixed architecture, dedicated video 

mixing application, it's not as easy for us to revisit our threading 

model as some of the examples used in comparison. I will say that the 

performance is noticeably better than many other programmable 

interactive media software environments, but there's several things 

we can do to try and make this better. Thanks for your feedback.

All I can say at this point is that we take these complaints  
seriously and are investigating some possible solutions. We can't  
commit to anything at this point and Max 5 is currently our biggest  
priority. Since we aren't a fixed architecture, dedicated video  
mixing application, it's not as easy for us to revisit our threading  
model as some of the examples used in comparison. I will say that the  
performance is noticeably better than many other programmable  
interactive media software environments, but there's several things  
we can do to try and make this better. Thanks for your feedback.

Thanks Joshua. Sorry for harping/dragging this back up. I think the 

issue is really comes down to what people can expect Jitter to do - 

and there is some confusion about that very expectation ( I myself am 

guilty). We all know Jitter was not designed explicitly for Mixing 

HD, and inherits a legacy of non video us and architecture, but there 

is no clear delineation, and it seems like users have had mixed 

I dont think anyone expects an immediate fix, nor wants it, but is 

more confused about what to realistically expect.

I am however very encouraged by your remarks and anxiously look 

forward to late next year when more 2.0 news might be available (yes 

I am speculating on that date - I know 2.0 is not even in development :)

On Sep 13, 2007, at 2:09 PM, Joshua Kit Clayton wrote:

> All I can say at this point is that we take these complaints 

> seriously and are investigating some possible solutions. We can't 

> commit to anything at this point and Max 5 is currently our biggest 

> priority. Since we aren't a fixed architecture, dedicated video 

> mixing application, it's not as easy for us to revisit our 

> threading model as some of the examples used in comparison. I will 

> say that the performance is noticeably better than many other 

> programmable interactive media software environments, but there's 

> several things we can do to try and make this better. Thanks for 

Thanks Joshua. Sorry for harping/dragging this back up. I think the  
issue is really comes down to what people can expect Jitter to do -  
and there is some confusion about that very expectation ( I myself am  
guilty). We all know Jitter was not designed explicitly for Mixing  
HD, and inherits a legacy of non video us and architecture, but there  
is no clear delineation, and it seems like users have had mixed  
signals about this very topic.

I dont think anyone expects an immediate fix, nor wants it, but is  
more confused about what to realistically expect.
I am however very encouraged by your remarks and anxiously look  
forward to late next year when more 2.0 news might be available (yes  
I am speculating on that date - I know 2.0 is not even in development :)

>
> All I can say at this point is that we take these complaints  
> seriously and are investigating some possible solutions. We can't  
> commit to anything at this point and Max 5 is currently our biggest  
> priority. Since we aren't a fixed architecture, dedicated video  
> mixing application, it's not as easy for us to revisit our  
> threading model as some of the examples used in comparison. I will  
> say that the performance is noticeably better than many other  
> programmable interactive media software environments, but there's  
> several things we can do to try and make this better. Thanks for  
> your feedback.
>
> -Joshua

But, at a risk of repeating myself, I'd like to mention that there is always the possibility of recording all necessary parameters (including movie times) of your real time performance or mixing patch and making an 'offline' render later. The render will contain no hiccups.

But, at a risk of repeating myself, I'd like to mention that there is always the possibility of recording all necessary parameters (including movie times) of your real time performance or mixing patch and making an 'offline' render later. The render will contain no hiccups.
Mattijs


Well, that kind of defeats the realtime nature of Jitter eh? I could 

On Sep 13, 2007, at 4:39 PM, Mattijs Kneppers wrote:

> But, at a risk of repeating myself, I'd like to mention that there 

> is always the possibility of recording all necessary parameters 

> (including movie times) of your real time performance or mixing 

> patch and making an 'offline' render later. The render will contain 

Well, that kind of defeats the realtime nature of Jitter eh? I could  
just use aftereffects then no?

>
> But, at a risk of repeating myself, I'd like to mention that there  
> is always the possibility of recording all necessary parameters  
> (including movie times) of your real time performance or mixing  
> patch and making an 'offline' render later. The render will contain  
> no hiccups.
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling

Hehe, 3D studio max is what I had in mind, talking about non-realtime.. ;)

But seriously, performing in low-res but realtime with jitter (thus adding some 'groove' and 'vibe' and 'feeling') and rendering back non-realtime in hi-res can be very interesting if the final product is to be used in a non-realtime production.

Of course it would be utterly ideal if Jitter had the same constant realtime playback performance as quicktime does.

Quote: vade wrote on Fri, 14 September 2007 00:11

> Well, that kind of defeats the realtime nature of Jitter eh? I could 

HD performance with jit.qt.movie in @window direct mode