alessandro.saccoia

I finished my VJ patch, but now that everything works well I am

experiencing low framerate if multiple movies and video-synths are

working at the same time. If we think at my patch as a mixer, I have 2

cannels that generate shapes etc connected to a jit.xfade, 2 channels

that play videos connected to another jit.xfade, and finally the 2

outputs of these first 2 xfades goes into a 3rd xfade. It happens that

if I am playing with all the 4 videosources switched on the framerate

drops to 6-7 fps from the original 20 (NB this happens only on my

laptop, while on my desktop that is much stronger still doesn't happen

but since I plan to add new features I could have problems also on

the desktop in the future). I am think that using jit.gl.videoplane to

enable hardware rendering would improve the performance, but I have

some doubt about how to use it in conjunction with the xfade objects.

In the videoplane help it's shown how to couple it with a jit.render,

which I read in its help has to be attached to a jit.window or

jit.pwindow to use hardware rendering. But I don't want to output

every channel to a window, I want their output to go to the

appropriate xfade. As you see I am a bit confused on how to use this

videoplane. Basically I want to move some of the CPU effort to the

GPU, and I don't know how to do it. Maybe this is possible just in the

last stage, when the last xfade is connected to jit.window. Help!

PS: the jit.fpsgui object after some processing gets transparent in

Hi list,
I finished my VJ patch, but now that everything works well I am
experiencing low framerate if multiple movies and video-synths are
working at the same time. If we think at my patch as a mixer, I have 2
cannels that generate shapes etc connected to a jit.xfade, 2 channels
that play videos connected to another jit.xfade, and finally the 2
outputs of these first 2 xfades goes into a 3rd xfade. It happens that
if I am playing with all the 4 videosources switched on the framerate
drops to 6-7 fps from the original 20 (NB this happens only on my
laptop, while on my desktop that is much stronger still doesn't happen
but since I plan to add new features I could  have problems also on
the desktop in the future). I am think that using jit.gl.videoplane to
enable hardware rendering would improve the performance, but I have
some doubt about how to use it in conjunction with the xfade objects.
In the videoplane help it's shown how to couple it with a jit.render,
which I read in its help has to be attached to a jit.window or
jit.pwindow to use hardware rendering.  But I don't want to output
every channel to a window, I want their output to go to the
appropriate xfade. As you see I am a bit confused on how to use this
videoplane. Basically I want to move some of the CPU effort to the
GPU, and I don't know how to do it. Maybe this is possible just in the
last stage, when the last xfade is connected to jit.window. Help!
Thank you
Alessandro

PS: the jit.fpsgui object after some processing gets transparent in
jitter 1.5.2 :s


jit-gl-videoplane-and-jit-xfade

shaders, shaders, shaders. xfade, although altivec-enhanced, still 

slows down the cpu. use jit.gl.slab and co.normal.jxs.

shaders, shaders, shaders.  xfade, although altivec-enhanced, still  
slows down the cpu.  use jit.gl.slab and co.normal.jxs.


Where can I find documentation about writing jxs files?

>From the docs: "Currently the high level languages GLSL and CG, as

well as ARB, and NV assembly programs are supported." which are the

differences? What would you suggest for a beginner?

And the co.normal.jxs you mentioned isn't anywhere on google. Where

I'd need a comprehensive guide on using gl stuff. :s Thanks, and

Thanks Joshua
Where can I find documentation about writing jxs files?
>From the docs: "Currently the high level languages GLSL and CG, as
well as ARB, and NV assembly programs are supported." which are the
differences? What would you suggest for a beginner?
And the co.normal.jxs you mentioned isn't anywhere on google. Where
can I find it?
I'd need a comprehensive guide on using gl stuff. :s  Thanks, and
sorry for the trivial questions,
Ale


try jitter tutorials 41-43. and search the archives for jit.gl.slab.

don't write your own. they're in c74support/jitter_shaders.

try jitter tutorials 41-43.  and search the archives for jit.gl.slab.

don't write your own.  they're in c74support/jitter_shaders.


Try running all your sources without mixing them.

I've found that as much as I optimize various things, just having multiple quicktime objects/other sources is often the real framerate killer.

I find my framerate tanks because of the following.

-High processor load Codecs in movie files. MP4/Divx/etc.

-not limiting update rates of preview windows.

-Using messages such as "gettime" on quicktime movies to update time/position.

-not optimizing message order/sending messages to too many places at the same time.

GL can be handy, but it isn't always the biggest issue.

Just for your own testing curiosity...
Try running all your sources without mixing them.

I find my framerate tanks because of the following.
-Multiple Quicktime objects.
-High processor load Codecs in movie files. MP4/Divx/etc.
-not limiting update rates of preview windows.
-Using messages such as "gettime" on quicktime movies to update time/position.
-not optimizing message order/sending messages to too many places at the same time.

GL can be handy, but it isn't always the biggest issue.


I think this is good advice! I look forward to seeing what you're up 

I think this is good advice!  I look forward to seeing what you're up  
to one of these days.

I was just making a patch with a bunch of tiny movies playing.

With 6 movies playing through separate jit.qt.movie objects, my framerate dropped to about 10 fps on a dual g5 2.3 ghz.

it seems like each instance of jit.qt.movie adds a lot of overhead.

I was triggering each object using send-recieve. I'd like to be able to run more movies if I can. Like 20 if poss.

I know there are workarounds, but is there an intrinsic issue with running multiple qt movie or Is there something I'm doing wrong here?

I was triggering each object using send-recieve. I'd like to be able to run more movies if I can. Like 20 if poss. 

try this: compressing them with photoJPEG, highest quality, 30fps. 

then look at your patch. pjpg at highest quality is lossless.

try this:  compressing them with photoJPEG, highest quality, 30fps.   
then look at your patch.  pjpg at highest quality is lossless.

do you mean that photoJPEG @highest is the same quality as raw when used to

do you mean that photoJPEG @highest is the same quality as raw when used to
export jitter output??

> I find my framerate tanks because of the following.

for clarity, however, it should be noted that if the object is not 

playing anything, it won't affect your framerate.

> -Using messages such as "gettime" on quicktime movies to update 

i can't say i've found this to be true. perhaps what was slowing 

things down was the process that the resulting "time" message output 

was directed to, for example, a graphical display widget. in this 

case, qlim or speedlim the "time" messages from jit.qt.movie's output 

(i.e., [jit.qt.movie}->[route time] -> [qlim 100] -> [widget])

i would also add that using jsui's as interactive or constantly updated 

interface elements (such as a timer display) can be a real framerate 

killer, even if fsaa is disabled on the jsui's. Pictslider or LCD 

should be used instead. This is sad-making for me, because I very much 

it also helps to use jit.change on the output of your video sources. 

in the event that you want to use a still and your patch depends on a 

constant stream of video (quite likely), you can write a bypass 

>
> I find my framerate tanks because of the following.
> -Multiple Quicktime objects.

for clarity, however, it should be noted that if the object is not 
playing anything, it won't affect your framerate.

> -Using messages such as "gettime" on quicktime movies to update 
> time/position.

i can't say i've found this to be true.  perhaps what was slowing 
things down was the process that the resulting "time" message output 
was directed to, for example, a graphical display widget.  in this 
case, qlim or speedlim the "time" messages from jit.qt.movie's output 
(i.e., [jit.qt.movie}->[route time] -> [qlim 100] -> [widget])

i would also add that using jsui's as interactive or constantly updated 
interface elements (such as a timer display) can be a real framerate 
killer, even if fsaa is disabled on the jsui's.  Pictslider or LCD 
should be used instead.  This is sad-making for me, because I very much 
like the jsui!

it also helps to use jit.change on the output of your video sources.  
in the event that you want to use a still and your patch depends on a 
constant stream of video (quite likely), you can write a bypass 
routine:

technically pjpeg @ 100% is still "lossy", but not detectable by the 

100% quality setting is logarithmically more CPU overhead to 

EG while 75% may take 3% cpu, 100% quality may take about 10-15%

imho 75% looks just as good with most material, although the 

discerning eye can tell the difference looking at a still frame, its 

technically pjpeg @ 100% is still "lossy", but not detectable by the  
naked eye

this is very important though:
100% quality setting is logarithmically more CPU overhead to  
decompress vs 75%
EG while 75% may take 3% cpu, 100% quality may take about 10-15%

imho 75% looks just as good with most material, although the  
discerning eye can tell the difference looking at a still frame, its  
very hard to tell with video.

what is deKam up to these days?
http://www.thomasdolby.com/


that's new to me. it sure is a more convenient format to archive my jitter

On 5/4/06, joshua goldberg  wrote:
>
> i believe so.

that's new to me. it sure is a more convenient format to archive my jitter
output then exporting raw ;-)

Er. So photo-jpeg quicktimes, which involve decompression, are better than uncompressed quicktimes? Surely getting rid of the decompression bit would speed things up?

At only 12x4 pixels, I I don't want to factor in compression, even lossless. These movies are under 10K bytes for 30 seconds. I'm not sure that slow retrieval times are the problem. Is Max particularly optimised for photo-jpeg?

What does seem to be the problem is multiple instances of jit.qt.movie. Whether large or small, compressed or uncompressed.

Er. So photo-jpeg quicktimes, which involve decompression, are  better than uncompressed quicktimes? Surely getting rid of the decompression bit would speed things up?

Use loadram for such small files. That will be much faster.

Use loadram for such small files.  That will be much faster.

loading to ram isn't making a difference.

Also, in principle, I want to play movies off a hard drive, not load to ram.

The hard drive I have does about 180mb per second, so access speed isn't a huge issue.

Maybe something else is at work in my patch....

Perhaps posting your patch will provide more insight into your problem.

Yes. It would help us do more than to just speculate if you could 

upload an archive (with media files, preferably) which demonstrates 

One thing to consider is if you are using metro, rather than qmetro 

to drive the process, and if you are using many instances of 

jit.pwindow to preview the movies. These all will cause additional 

low priority queue events to be processed. By default, only 10 queue 

events are processed per "tick". You can increase the number of 

events processed per tick, by changing the queuethrottle settings 

inside the performance options window. Hard to say without seeing an 

Yes. It would help us do more than to just speculate if you could  
upload an archive (with media files, preferably) which demonstrates  
your issues.

One thing to consider is if you are using metro, rather than qmetro  
to drive the process, and if you are using many instances of  
jit.pwindow to preview the movies. These all will cause additional  
low priority queue events to be processed. By default, only 10 queue  
events are processed per "tick". You can increase the number of  
events processed per tick, by changing the queuethrottle settings  
inside the performance options window. Hard to say without seeing an  
example patch.

Jit.gl.videoplane and jit.xfade