avlodge

This seems to come up a bit on the forum but I haven't been able to find anything that I can make work.

I have a very simple patch. Just crossfading between two jit.qt. movie objects with dials for controlling playback speed. No effects or slabs. The clips are 640 x 480. I've tried PJPEG at 75% and Apple Pro-Res. The codec doesn't seem to matter. The clips still stutter during playback. I'm really hoping for smooth playback as almost all my clips are text animations (rolls, crawls, etc) and the stutter is super noticeable. The clips play real smooth in a standard QT player but once I try to play them in Max they stutter. Any tips to optimize my video playback great appreciated.

I'm on a Mac Book Pro, 2.66 Intel Core i7, 8gig Ram, External fast firewire 800 hard-drive, Max/MSP/Jitter 5.1.6

This seems to come up a bit on the forum but I haven't been able to find anything that I can make work.  

I have a very simple patch.  Just crossfading between two jit.qt. movie objects with dials for controlling playback speed.  No effects or slabs.  The clips are 640 x 480.  I've tried PJPEG at 75% and Apple Pro-Res.  The codec doesn't seem to matter.  The clips still stutter during playback.  I'm really hoping for smooth playback as almost all my clips are text animations (rolls, crawls, etc) and the stutter is super noticeable.  The clips play real smooth in a standard QT player but once I try to play them in Max they stutter. Any tips to optimize my video playback great appreciated.

smooth-video-playback

Might be that your pro-res is not the correct codec(there are different types). try with the 422, lq or proxy, see if any of those work properly.

Thanks. I did try all the different pro-res codecs and pjpeg as well. Doesn't make any difference. I wonder if it has something to do with the fps playback not being completely locked to the actual frame rate of the clip. Fluctuates around 29 and change and 30 and change. I'm stumped as I don't know how to get the metro to play the qt movie back at exactly 30 fps.

Thanks. I did try all the different pro-res codecs and pjpeg as well. Doesn't make any difference. I wonder if it has something to do with the fps playback not being completely locked to the actual frame rate of the clip.  Fluctuates around 29 and change and 30 and change.  I'm stumped as I don't know how to get the metro to play the qt movie back at exactly 30 fps.


I would recommend leaving them in UYVY until the image is on the GPU, and using the slab-based conversion. Also, the XFade can be replaced with a slab as well. This will provide the most efficient processing. Here is a retrofitted version of your patch that should give you a little performance boost. 

I would recommend leaving them in UYVY until the image is on the GPU, and using the slab-based conversion.  Also, the XFade can be replaced with a slab as well.  This will provide the most efficient processing.  Here is a retrofitted version of your patch that should give you a little performance boost.  


Thanks Ben! That helped a bit. However the playback of the clips still stutters and is most noticeable on text roll/crawl animations. Do you think I'll gain some performance by stopping and clearing the qt movie that is not active in the mixer? Or do you think it is better to just let the clip play until I load another one? Is it just not possible to play QT movies at 640 x 480 smoothly in Jitter?

Thanks Ben! That helped a bit.  However the playback of the clips still stutters and is most noticeable on text roll/crawl animations.  Do you think I'll gain some performance by stopping and clearing the qt movie that is not active in the mixer?  Or do you think it is better to just let the clip play until I load another one?  Is it just not possible to play QT movies at 640 x 480 smoothly in Jitter?

It could be that the data rate is too large..even in photojpeg..this sounds like more of a disk speed issue than a processing problem..I've definitely played two 640x480's simultaneously while doing a million other processes and never had a noticeable stutter.

Open your clips in quicktime and go to 'window' and select movie inspector..it should tell you your data rate for that clip...if its much over 20mb/s its probably overkill and could be bottle-necking your disk..pro res codecs would definitely be a high data rate codec

it would be really great, if someone could write

the quicktime play engine from openframeworks could

be a good start. (there is no stuttering)

for cycling it seem to be ok as it is .....

the problem is the ji.qt.movie object.
it always stutters !
independent from codec or hardware ..

it would be really great, if someone could write
an external which solve this issue.
the quicktime play engine from openframeworks could
be a good start. (there is no stuttering)

for cycling it seem to be ok as it is .....
its a pity ...

Yes, the clips are over 20mb/s. But I don't understand how that is a disc issue if they play fine in the Apple QT player or with the VLC player. But I will try a codec that is less than 20 mb/s to see if that solves the problem. However, I'm also afraid they won't look good anymore if I do that.

Yes, the clips are over 20mb/s.  But I don't understand how that is a disc issue if they play fine in the Apple QT player or with the VLC player.  But I will try a codec that is less than 20 mb/s to see if that solves the problem. However, I'm also afraid they won't look good anymore if I do that.

They play fine one a time or both at the same time in QT? I have the exact same machine you have (8gb ram), play things off of a 7200rpm FW800 drive, two at a time and I sit pretty steadily at 30fps..and I'm sometimes running 10 slab effects and jumping around within the videos.

My photojpegs are around 17mb/s in terms of data rate..although fw800 claims 800mbits/s as it's throughput, it is much lower than you think according to this article: 

http://en.wikipedia.org/wiki/List_of_device_bit_rates

FW800 can at best get around 98mb/s, so if you're running two videos that add up to be more than that..chances are you'll have some stuttering...dropping the quality just a bit to 50% or so really won't look too bad

My photojpegs are around 17mb/s in terms of data rate..although fw800 claims 800mbits/s as it's throughput, it is much lower than you think according to this article: http://en.wikipedia.org/wiki/List_of_device_bit_rates

FW800 can at best get around 98mb/s, so if you're running two videos that add up to be more than that..chances are you'll have some stuttering...dropping the quality just a bit to 50% or so really won't look too bad


I tried photojpeg at around 17mb/s and the playback stutter is just as bad as with the prores clips (maybe even worse). Weird. And I'm not even playing two clips at the same time. After a 2 second xfade I stop and clear the non-active qt player. It seems to me to have something specifically to do with Jitter and/or perhaps my patch (with edits from Andrew Benson) still isn't as optimized as it could be. There has been some mention that softVNS plays video better than the jit.qt.player but I really can't afford it at the moment.

I tried photojpeg at around 17mb/s and the playback stutter is just as bad as with the prores clips (maybe even worse).  Weird.  And I'm not even playing two clips at the same time.  After a 2 second xfade I stop and clear the non-active qt player.  It seems to me to have something specifically to do with Jitter and/or perhaps my patch (with edits from Andrew Benson) still isn't as optimized as it could be. There has been some mention that softVNS plays video better than the jit.qt.player but I really can't afford it at the moment. 

Is Overdrive on? At what point in the playback does stuttering occur? Is something else happening at the same time (like reading a new movie in, for example)? Sometimes a small stall will occur at the loop-point of a video as the hard-drive has to seek to the beginning of the file. This can be alleviated to some extent by using "loadram" messages to load the beginning and end of the clip into RAM.

Is Overdrive on? At what point in the playback does stuttering occur?  Is something else happening at the same time (like reading a new movie in, for example)?  Sometimes a small stall will occur at the loop-point of a video as the hard-drive has to seek to the beginning of the file.  This can be alleviated to some extent by using "loadram" messages to load the beginning and end of the clip into RAM.


I'm not sure what Overdrive is except in audio circuits so I'm not sure If I am using it or not. It just happens throughout the length of the clip. The clips are fairly long, anywhere from 1 to 3 minutes each. But I do not have any effects other than the cross fade and I am not looping anything. With the xfade each clip comes on really smooth. I haven't had much problem there. The stutter really comes and goes but more often than not it is there. It is just especially noticeable on the text roll animations. Do you think the problem is the clip length?

I'm not sure what Overdrive is except in audio circuits so I'm not sure If I am using it or not.  It just happens throughout the length of the clip.  The clips are fairly long, anywhere from 1 to 3 minutes each.  But I do not have any effects other than the cross fade and I am not looping anything.  With the xfade each clip comes on really smooth.  I haven't had much problem there. The stutter really comes and goes but more often than not it is there.  It is just especially noticeable on the text roll animations.  Do you think the problem is the clip length?  

Overdrive is an option in the 'options' menu..it ensures timing related things run as accurately as possible, but its usually more important for audio related tasks I think...but I'm sure andrew knows best.

It's definitely not the clip length. I use 10-12minute 640x480 clips with no problem.

How about starting over completely from scratch..just to make sure its not another element in your patch. Do those video files 'stutter' when you try them in say..the qt.movie help file with no other patches open, or the jit.xfade help file?

What kind of fps are you getting? Is it a sudden fps drop that looks like a 'stutter'? I might need a little more info on what the stutter looks like...im just really confused since we have the exact same setup and I don't have that problem..what about upgrading to 5.1.7?

Overdrive is an option in the 'options' menu..it ensures timing related things run as accurately as possible, but its usually more important for audio related tasks I think...but I'm sure andrew knows best. 

What kind of fps are you getting? Is it a sudden fps drop that looks like a 'stutter'? I might need a little more info on what the stutter looks like...im just really confused since we have the exact same setup and I don't have that problem..what about upgrading to 5.1.7?


the 'quicktime play engine' is just a wrapper around the quicktime framework.

I tried your suggestions, opening a file in the jit.qt.movie help file with no other patches open, and I can see the stutter. It's really only noticeable on my text roll animations. The fps I'm getting is right around 33 plus some variable amount after the decimal point. I'm wondering if it is the variable frame rate causing the stutter on the text rolls. They were animated to play smoothly at 29.97 (SMPTE time code speed). So I wonder if the non-standard fps is the problem. Is there anyway in Jitter to force a .mov file to play at 29.97? Or will it do this automatically at the default Rate of 1.? Just confused about the fps in Jitter. If the clip is playing at 33.2534 fps does that mean that it is playing faster than 29.97? Will the clip actually be shorter in terms of how much time it takes to play?

Maybe I'm just over thinking all of this and not in the smartest way. The jit.qt.movie object is simple to use in some ways but takes so many messages and has so many attributes that I find it hard to fully understand it.

I tried your suggestions, opening a file in the jit.qt.movie help file with no other patches open, and I can see the stutter.  It's really only noticeable on my text roll animations.  The fps I'm getting is right around 33 plus some variable amount after the decimal point.  I'm wondering if it is the variable frame rate causing the stutter on the text rolls.  They were animated to play smoothly at 29.97 (SMPTE time code speed). So I wonder if the non-standard fps is the problem. Is there anyway in Jitter to force a .mov file to play at 29.97? Or will it do this automatically at the default Rate of 1.?  Just confused about the fps in Jitter.  If the clip is playing at 33.2534 fps does that mean that it is playing faster than 29.97?  Will the clip actually be shorter in terms of how much time it takes to play?

Maybe I'm just over thinking all of this and not in the smartest way.  The jit.qt.movie object is simple to use in some ways but takes so many messages and has so many attributes that I find it hard to fully understand it.

It is sort of confusing, agreed! jit.qt.movie does not "guarantee' a frame rate: the speed it reads the file from disc is independent from the speed it outputs frames. The speed jit.qt.movie outputs frames is NOT related to the frame rate of the video file: it is only the result of how many bangs per second it receives.

If you set the metro that bangs the jit.wt.movie to "100" you will get around 10 frames per second output. This is true if your video FILE has a frame rate of 29.97, or 24, or 15...or even if your file is a still image, like a .jpg, instead of a .mov.

Frames per second of the file is NOT EQUAL to the frames per second that jit.qt.movie outputs. It is entirely independent.

Each bang received is a request to output a frame. If it has a new frame available, it will out put it. If it doesn't, it will output the same frame again. (This is the reason you may see an output frame rate that is higher than the frame rate of your file -- you mention seeing 33.25 from a 29.97 file.)

If you want to "guarantee" an output rate, your best bet is to type "@unique 1" on the jit.qt.movie, and set the metro faster that your intended output frame rate (say, 20ms for 29.97fps). This insures that no duplicates will be output, and that there will almost definitely be a request for every new available frame from disc.

In MSP, it's possible to guarantee timing: when MSP is ON, audio signals flow down the yellow-and-black patch cords at 44.1k samples per second, GUARANTEED. In Jitter, there are no guarantees. Video is heavy work, and there is no way to insure that other Max activities (effects, etc) won't bog down the processor, or that system activities won't cause the disc to spin etc.

It is sort of confusing, agreed! jit.qt.movie does not "guarantee' a frame rate: the speed it reads the file from disc is independent from the speed it outputs frames. The speed jit.qt.movie outputs frames is NOT related to the frame rate of the video file: it is only the result of how many bangs per second it receives. 

the quicktime framework in jitter is not good.

open some fotojpeg movies (640x480, 30fps or bigger)inside

on a modern machine all the movies will play fluently.

play the same movies with openframeworks (and mix them)

try the same with max/jitter using all tricks

so it seems to be a problem of the jit.qt.movie object.

perhaps it is a bit outdated or overloaded with functions....

perhaps it would be a good idea to let the object as it is

and deliver a new one, which has not so many functions but

has its focus on playing movies fluently.

i think many jitter people would love to use this object.

for us it is a core functionality to play movies :-)

the c code to realize the object is opensource.

@ efe
all i want to say is, that the use of
the quicktime framework in jitter is not good.

you can make some simple tests on a mac:
open some fotojpeg movies (640x480, 30fps or bigger)inside
the quicktimeplayer and start them all.

or:
play the same movies with openframeworks (and mix them)
they will all play fluently
http://www.openframeworks.cc/

try the same with max/jitter using all tricks
(vades patch, opengl ....)
it will always stutter !

so it seems to be a problem of the jit.qt.movie object.
perhaps it is a bit outdated or overloaded with functions....

perhaps it would be a good idea to let the object as it is
and deliver a new one, which has not so many functions but
has its focus on playing movies fluently.

i think many jitter people would love to use this object.
for us it is a core functionality to play movies :-)

the c code to realize the object is opensource.
http://www.openframeworks.cc/

It is actually c++(you have similar wrappers in other toolkits like Cinder), but i do agree that the qt objects in jitter can be slightly inefficient when playing high resolution files. I am not sure if the stuttering is only related with the object itself or with the update of the Max graphic interface or something else. When compiled, Jitter objects need to be exposed to the patcher, maybe a bottleneck there?.

I agree with the previous two posts: C74 should make it a priority to test and improve performance of jit.qt.movie. It is not what it should be.

I understand that there are complex interactions between objects in Max/Jitter, threading issues, etc. But like they say, the first step to getting better is admitting there's a problem. ;-)

I agree with the previous two posts: C74 should make it a priority to test and improve performance of jit.qt.movie. It is not what it should be.
I understand that there are complex interactions between objects in Max/Jitter, threading issues, etc. But like they say, the first step to getting better is admitting there's a problem. ;-)


With Syphon would it be possible to route a fluently-playing movie from Open Frameworks (for instance) into Jitter for processing?

so we could make a proof of concept for C74.

is it possible to "stream" multiple textures via Syphon ?

then we could make a kind of moviebank program in Open Frameworks, which

or we have to create one Open Frameworks application for each quicktime.

its a pity, that i am totally busy till april.

is it possible to "stream" multiple textures via Syphon ?
then we could make a kind of moviebank program in Open Frameworks, which
delivers smooth texture streams.

or we have to create one Open Frameworks application for each quicktime.
(with a settings.xml)
its a pity, that i am totally busy till april.
but i  will definitly check this out !

just in case did you activate highquality ? jit.qt.movie @highquality 1

Hello,
just in case did you activate highquality ? jit.qt.movie @highquality 1
Cheers
Hubert


@Kurt FWIW, we've admitted this limitation for all the reasons you point out in various forum threads over the years. It's not an easy solution for us to revisit the way QT interacts with Max without doing things like separating it into a separate process which introduces *many* other issues. However, we are investigating improvements for Max 6.

For example, here's some I've commented on over the years in this area:

https://cycling74.com/forums/jitter-video-playback-amatuer-or-professional-grade

https://cycling74.com/forums/hd-performance-with-jit-qt-movie-in-window-direct-mode

https://cycling74.com/forums/quicktime-playback-optimization-some-example-patches

@jeanette_h + efe, for reasons, such as Kurt outlines, it's not exactly a fair comparison with open frameworks, or cinder, where you are building a custom lightweight application. When you make something in these apps, you are not at the same time building a scheduler, low priority queue, a complete editing and patcher environment with competing with user events, and high priority events in the same way.

Sure, if one simply uses QT to play a movie to a window through CoreVideo, you get smooth playback. However, when you decouple the data from QT itself as jitter does it makes some of the timestamp synchronization and other issues with smoothness more difficult to preserve. Also note that CoreVideo (necessary for the time-stamping and synchronization to get smooth playback) and QTKit isn't present on windows, that we maintain a cross platform code base and are integrating it into a complex, existing thread ecosystem of a large scale general purpose application. These make it a much more significant problem, and we balance this problem with other development priorities. Max/MSP/Jitter is not a dedicated video program, and cannot be fairly compared as such. It is a dynamic visual programming environment which has video capabilities as one of it's many competing features.

I would say that a third party app which streams data from an out of process player is a great idea. I think it would be useful to a great number of people. Already, you can do this with QuartzComposer and jit.gl.syphon.

In the meantime, we'll also investigate various improvements (note that in those threads the "next major version of Jitter" is actually Max 6).

Thank you for your feedback and understanding.

For example, here's some I've commented on over the years in this area:
https://cycling74.com/forums/jitter-video-playback-amatuer-or-professional-grade
https://cycling74.com/forums/hd-performance-with-jit-qt-movie-in-window-direct-mode
https://cycling74.com/forums/quicktime-playback-optimization-some-example-patches

@Joshua Kit Clayton : When would Max 6 be released?

Just thought I'd chip in to say 2 things. First is while I don't have access to ProRes, I find that the best codec to use is Apple Intermediate Codec. Although I'm sure this is irrelevant to the issue after reading the thread.

Secondly, whilst this talk of using qc/ofx and syphon to make a smooth stream sounds a great idea, I consistantly keep thinking it would be great to have a max object that was based upon mplayer. The main benefit of this would be the increased format support on Windows, but I always found that for single threaded CPU based decoding (my opinion has changed a bit since all this GPU based VDADecoder stuff came into quicktime), it is by far the fastest decoder.

Would there be a way of making an object that played mplayer directly to a named jitter texture (lets say ignoring if it's being banged or not), that then could simply be read by using a jit.gl.texture object? Would that kind of thing fix the problem?

Just some random ideas I've been having that I thought I might share! Sorry if it's a little off topic.

Quicktime codecs such as Pro Res and AIC (and many others) are multithreaded for the decompression sessions behind the scenes. So while Jitter may use one (or a few?) threads, Quicktime is managing its own decompression threads for the selected movie. This is not to say Quicktime is great (getting intimate with it makes me understand how amazingly not great it is as a *modern* sensible API), but I think part of the issue right now is just how Max/ Jitter work (push vs pull rendering for one), the timestaping issue JKC mentions, etc.

DigitalFX, even if you sent a texture directly to GL, or output a jit_gl_texture from an output port on this jit.mplayer object, you will still need to drive the main GL context rendering and have the scheduler, etc issues that are inherit to Max.

Quicktime codecs such as Pro Res and AIC (and many others) are multithreaded for the decompression sessions behind the scenes. So while Jitter may use one (or a few?) threads, Quicktime is managing its own decompression threads for the selected movie. This is not to say Quicktime is great (getting intimate with it makes me understand how amazingly not great it is as a *modern* sensible API), but I think part of the issue right now is just how Max/ Jitter work (push vs pull rendering for one), the timestaping issue JKC mentions, etc. 

DigitalFX, even if you sent a texture directly to GL, or output a jit_gl_texture from an output port on this jit.mplayer object, you will still need to drive the main GL context rendering and have the scheduler, etc issues that are inherit to Max.


Yup that makes sense! But then that also means the idea of using ofx/QC and syphon would be no different right?

on the contrary, i am completely aware of the pros and cons of using jitter as a creative tool. Looking forward for Max6.

Hey Joshua:
on the contrary, i am completely aware of the pros and cons of using jitter as a creative tool. Looking forward for Max6.


Joshua, thanks++ for the info and comments! Max 5 is a thing of beauty -- looking forward to the even greater beauties of Max 6.

Firewire 800 is just short of 800 Mbit/s Which works out to 98 MB/s - thats MegaBytes Not MegaBits = big difference Original Firewire was ~ 100 Mbit/

@Laserpilot
Please check your stats before posting
Firewire 800 is just short of 800 Mbit/s Which works out to 98 MB/s - thats MegaBytes Not MegaBits = big difference Original Firewire was ~ 100 Mbit/
Cheers
MM


DigitalFX, no, because the scheduler timing would not hinder the secondary background application that is doing the decoding, and timestamps are dealt with in this secondary playback app, ensuring that the texture is properly up to date (Core Video and Quicktime visual contexts also handle buffering the textures to ensure things are there as fast as possible). As long as you can reasonably get 60Hz for display, it should be ok.

I think, what actually would be amazingly helpful for jitter (and this is something I had pondered for a while), is something along the lines of a "DisplayLink" driven metro.

Core Video display link is a separate sort of timer and callback that is driven by the refresh rate of your display, and calls your rendering functions so they finish *just in time* for the screen refresh to draw. No faster, so its light on the CPU. It keeps a running average of how long your rendering takes, and then times the rendering function to happen before the display updates, then sleeps the appropriate amount of time.

Being able to drive a metro or qmetro like that so its 60Hz (qmetro 16.666666666667) but somehow smart enough to bang to sync with the display might make a decent amount of difference?

No idea if something like that is feasible, or maybe if Jitter already does it unknowingly, but it could not hurt? (or.. could it?)

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 

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

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

I was using James' example movie file for testing:
http://www.vjfader.com/transfer/clock_spin.mov

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


And for this thread's pertinence, here's an adapted version of the originally posted patch (including Andrew Benson's GPU optimizations)

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.

PhotoJPEG
Apple Intermediate Codec
H.264
Apple ProRes 422
Apple ProRes 422 (LT)
Apple ProRes 422 (HQ)
Apple ProRes 444 with Alpha

@Joshua, could you please make a sticky out of the two posts above?

This is an incredibly useful and informative thread.

I second that jonathanb.
This is an incredibly useful and informative thread.


also a very important setting for better movie playback on multiple gpus is:

cut 1 pixel of the left side of your jit.window (using the rect message)

i have 30% better framerates playing movies on my system.

this is a bug, which exists till snow leopard came out.

since 1,5 years ther is no bugfix from cycling74 :-(

also a very important setting for better movie playback on multiple gpus is:
cut 1 pixel of the left side of your jit.window (using the rect message)

i have 30% better framerates playing movies on my system.
mac pro 4,1, mac os 10.6.4

this is a bug, which exists till snow leopard came out.
since 1,5 years ther is no bugfix from cycling74 :-(

I thought I'd throw in my $0.02 wrt codecs and smooth video playback. I too have found apple prores to be quiet good for HD playback. But here are some interesting (?) observations (all of which are kind of expected, but sharing nonetheless):

1. Baseline: patch loads, takes ~7% of the CPU (as is usually the case). no video processing yet.

2. turn on rendering (but no files loaded into jit.qt.movie yet): no change in CPU

3. load one 720p movie (apple ProRes 4444), CPU jumps to 26%. autostart = 0, no bang reaching the jit.qt.movie object.

4. send a "start" message, CPU to 50%. Still no bang reaching jit.qt.movie. Shark reports that 44% of Max's resources is in dealing with the apple ProRes codec.

5. start the image chain (i.e. allow the bang to pass thru the jit.qt.movie), 67%.

(consistently throughout I'm getting 60fps, which is great, and smooth playback)

Now for my particular project, I'm actually loading 4 HD streams & compositing into 3840 x 720 window (three tiled background movies, one foreground with an alpha channel that moves across the entire window).

7. 4 HD movies reading from the hard drive, ~135%. Still 60fps. Shark reports that 85% of max's resources is dealing with decoding pro res.

8. If I load everything into RAM, my disk activity drops to 0, but CPU is around 200%. Still 60fps.

9. Repeat step 7 with photo jpeg (med) HD files (ignoring the fact that I can't have an alpha channel on the foreground image), CPU @ 70%, 60fps. However vs. ProRes, photo jpeg adds quite a few artifacts that show up quite easily in the content I'm using.

One thing I did notice was that you have to send a "stop" message to jit.qt.movie objects even when you stop the bangs to the jit.qt.movie objects if your goal is to recoup some CPU cycles for other tasks (otherwise stays above 100%, mostly for pro res decoding).

I also notice I get a lot of crashes after loading the HD files into RAM. I suspect it's Max running out of memory, however the usual "memoryheap" issues don't show up in the crash log. Using an SSD drive takes care of the need to load into RAM.

Anyway, may or may not be useful...just thought I'd share.

BTW: this is on a recent MBP, 10.6.5, Max 5.1.7.

I thought I'd throw in my $0.02 wrt codecs and smooth video playback. I too have found apple prores to be quiet good for HD playback. But here are some interesting (?) observations (all of which are kind of expected, but sharing nonetheless):
1. Baseline: patch loads, takes ~7% of the CPU (as is usually the case). no video processing yet.
2. turn on rendering (but no files loaded into jit.qt.movie yet): no change in CPU
3. load one 720p movie (apple ProRes 4444), CPU jumps to 26%. autostart = 0, no bang reaching the jit.qt.movie object.
4. send a "start" message, CPU to 50%. Still no bang reaching jit.qt.movie. Shark reports that 44% of Max's resources is in dealing with the apple ProRes codec.
5. start the image chain (i.e. allow the bang to pass thru the jit.qt.movie), 67%.
6. load the movie into RAM, CPU = 90%
(consistently throughout I'm getting 60fps, which is great, and smooth playback)

One thing I did notice was that you have to send a "stop" message to  jit.qt.movie objects even when you stop the bangs to the jit.qt.movie objects if your goal is to recoup some CPU cycles for other tasks (otherwise stays above 100%, mostly for pro res decoding).

Quicktime movies task when not being banged (the file is still being read, and decoded if you told it to play, etc), so even if you stop the metro, you need to give an explicit stop method to jit.qt.movie, less you want disk access and CPU to be used in the background with no real visible indication.

Good to know! I don't think I would have ever noticed it had I not switched to a more CPU-intesive codec!

I learned that pretty quickly on older machines it was hard not to notice even on 320x240 back in the day, when we played visuals uphill (both ways). You youngen's with your 12 cores and gigahertz.... complaining about the lack of smooth playback.

But honestly, I don't recall if that was ever mentioned in the documentation. It certainly is ... not intuitive compared to other matrix based objects that only process when banged. Something good to know, especially if you juggle between generative and playback, ensuring you get the full CPU and thus FPS when not actively using your jit.qt.movies.

I learned that pretty quickly on older machines it was hard not to notice even on 320x240 back in the day, when we played visuals uphill (both ways). You youngen's with your 12 cores and gigahertz.... complaining about the lack of smooth playback. 

Similarly related to that vade, do you know the answer to this post I made a few months ago? 

https://cycling74.com/forums/jit-qt-movie-startstop-vs-rate-0

Similarly related to that vade, do you know the answer to this post I made a few months ago? https://cycling74.com/forums/jit-qt-movie-startstop-vs-rate-0


Thanks for posting the patch with optimizations. However, for some reason I can't seem to get your patch to output video. Am I doing something wrong or is their a bug in the patch?

Thanks for posting the patch with optimizations.  However, for some reason I can't seem to get your patch to output video.  Am I doing something wrong or is their a bug in the patch?

If I change the attribute in the jit.gl.videoplane object from @automatic 0 to @automatic 1 than the patch works. Is there a benefit to setting that attribute to @automatic 0? And if so what is the benefit and how can I get the patch to output video to the jit.window with the setting at @automatic 0?

If I change the attribute in the jit.gl.videoplane object from @automatic 0 to @automatic 1 than the patch works.  Is there a benefit to setting that attribute to @automatic 0?  And if so what is the benefit and how can I get the patch to output video to the jit.window with the setting at @automatic 0?

Your fix for this was appropriate. Oversight on my part. Sorry for the confusion.

The patch (including Andrew Benson's GPU optimizations) still produces an error for me, even after making the @automatic 1 changes recommended by avlodge.

When I click the center button which triggers the fade to the second video instance, once it reaches 100 and completes the fade the video stops playing, unless I send a bang from the left-most button, which isn't clear to me b/c I believe this controls rate for the first video instance.

The patch (including Andrew Benson's GPU optimizations) still produces an error for me, even after making the @automatic 1 changes recommended by avlodge. 

is it because the rendering context changes to something other than 'tristan' when you press the middle button which initiates the crossfade ?

Smooth Video Playback