Forums > Jitter

Performance problems running 3 720×480 jit.qt.movie at fullscreen simultaneously


Ben Miller
Apr 22 2009 | 4:13 pm

I am running into performance issues running three, fullscreen 720×480 jit.qt.movies simultaneously.

The movies are fairly small H264 compressed files (150mb tops) and if I try to run them at 320×240 they look pretty terrible.

I was wondering if there is anyway I can offload some of the work to the GPU or if there are any other optimization methods I should use to make these files run at full quality/speed.

hardware:
Windows XP 32-bit
Intel Core Duo 3.16 GHZ
2.50 Gb Ram
Nvidia Geforce 6200
Nvidia Geforce 8600 GT

Cheers,
Ben


MIB
Apr 22 2009 | 5:53 pm

If you don’t know this already, check out this blog by Vade about jitter optimization. It also comes with handy example patches.

http://abstrakt.vade.info/?p=147


MJ
Apr 22 2009 | 6:29 pm

did you tried to change codec

in max i always use quicktime photo-jpeg at 75%
but thats on osx….

i had bad fps with h264 before


Ben Miller
Apr 22 2009 | 6:44 pm

MIB: great link to some good information on optimizing Jitter for videos. However, when I downloaded the zipped patches and extracted them, they are all recognized as basic FILE types. I tried changing the extension to .maxpat and .pat but Max didnt load them corretly…

MJ: I have tried to use different codecs but H264 gives me the smallest file size. Of course, this makes reading the files more computationally intensive and I bet that is where I am getting stuck.

I have read elsewhere that PhotoJPG at 70-80% is recommended. I will try to run three of them simultaneously later and see if it improves performance.


MIB
Apr 22 2009 | 7:30 pm

works for me. here it is again, re-zipped.


Ben Miller
Apr 22 2009 | 7:44 pm

MIB: Couldnt get anything to work until I tried loading the Max files as text from within max and then loading that through the clipboard. Thanks though!

Although I will be unable to test whether or not using the photo-JPEG codec will improve performance until later tonight, I noticed that my PC does not seem to be overly taxed in regards to the CPU or RAM by running these fullscreen videos.

When running the patch, The CPU usage only gets up to around 60% and the commit charges are always a fraction of the total amount of physical memory I have available.

Does anyone know if this additional information points to a "likely" problem area in regards to the patch, hardware setup, or video compression? Is Max limited to only consume 60% of cpu usage or something weird?

Cheers,
Ben


MJ
Apr 22 2009 | 10:22 pm

in your patch you have a "metro 20" for every movie

better just have one metro and send that to all movies
and when you’re done with a movie make sure he doesn’t receive the metro.

why 20 ? if you’re movies run at 25fps then use a metrospeed of 40
(1000/25=40) no need for faster metrospeeds.

also try using qmetro instead of metro

and did you turned on the overdrive?


Ben Miller
Apr 23 2009 | 2:35 pm

MJ: thanks for your help.

I consolidated all of the metros in my patch into one metro source. I also made the jit.windows I am using smaller (320 x240) and compressed all of my files using Photo Jpeg at around 80%.

I do not have overdrive turned on. When I turned it on, I think the video ran even more sluggishly.

The attribute that seems to change the performance of the patch the most is the size of each individual jit.qt.movie.

Video looks terrible at 320×240 but runs well whereas video looks great at 720×480 but does not stay in synch with the audio (which is a separate file). It looks like I can probably use some bizarre size like 500×480 and it seems to look OK and run well.

Does this performance speak to a specific problem I am missing? Is there anyway I could further optimize the patch and get things running well at 720×480? Would spatially repositioning the elements in the patch help at all?


MJ
Apr 23 2009 | 7:57 pm

you can also try to use less jit.qt.movies
you need just 3 one for each output

did you looked at the "Jitter Movie Optimization Methods.zip" ?

in there you’ll see that it goes faster if you put the video as atexture on a jit.gl.videoplane


Ben Miller
Apr 24 2009 | 1:13 am

I am looking into using some of the techniques described in the Jitter Movie Optimization.zip tonight.

I am intrigued about the idea of only using three jit.qt.movies but I dont know how I would pre-load any data using that method.


Ben Miller
Apr 30 2009 | 3:25 am

I have noticed that as I play through the 15 different videos during any given performance, the ram being used by the computer continues to rise.

Each video seems to use a certain amount of RAM and this RAM memory is never freed up, even after the video is stopped.

Is there anyway I can play a video and then when I stop it, free the ram that it used?


MJ
Apr 30 2009 | 12:14 pm

thats why you should maybe use less jit.qt.movies
if you ‘stop’ the movie it will stay in that jit.qt.movie

send a ‘dispose’ message to the jit.qt.movies after a certain movie is done


Ben Miller
Apr 30 2009 | 2:27 pm

MJ: Thanks for your reply. Right after I posted this message I saw that I could send a dispose message to the quicktime movies and have started to implement that. Hopefully this will help.

I noticed in the Jitter Movie Optimization files that the author had made GPU examples that work with multiple channels. I was wondering if the workflow to creating a slab + videoplane solution to work with multiple different movie files was easy. I dont really care about multiple channels as much as I care about being able to easily load, play, and stop multiple videos one after another.

Can I run many different videos through one videoplane or do I need a separate one for each video?

Does anyone have any tips on how to make this or patches that demonstrate this type of setup?

Cheers,
Ben


Rob Ramirez
Apr 30 2009 | 9:07 pm

the most common answer to the question of how to load multiple quicktime movies, is to make use of the poly~ object to handle several instances of a qt.movie player patch.

searching the forum for something like "poly movie" should give good results.


Ben Miller
May 05 2009 | 2:26 am

robtherich: Thanks for your input. I looked through the forums and implemented a very basic form of poly~ to instance the various jit.qt.movies I was creating.

Everything has been working great so far.

However, just tonight (the first night of the performance, tomorrow is the second and final night) the CPU usage jumped to 33% and above (which shouldnt matter anyway since we are running a quad-dual core, vista 64 bit machine) and we actually had Max crash due to the graphics driver crashing.

We have never seen this before and we unpleasantly surprised to say the least.

I wonder if it has something to do with memory management. The system seems to have gotten slower every time we have run the program, irregardless of the fact we shut down/restart all the time.

Is there some type of memory management I need to do when I am using poly~?

Any help would be greatly appreciated. Our final performance is tomorrow night…

Ben


Ben Miller
May 05 2009 | 2:26 am

Here is a typical patch I am using with poly~

Ben


Rob Ramirez
May 06 2009 | 6:08 pm

your poly~ patch has unnecessary inputs and outputs, but i doubt that’s your problem. possibly it has to do with how you are managing your qt.movie’s (ie, making sure you send proper stop messages when they are no longer needed to play).

other than that, you could try the vade optimizations (search the forum to find these).


Ben Miller
May 08 2009 | 9:23 pm

robtherich, and everyone else that helped with this patch:

Thanks for the suggestions and help with this patch.

The final performance went off well after we re-installed Max and made sure the graphics card was as cool as possible. I think the error was due to overheating but I am not sure.

Regardless, we got through four full performances without any software issues.

Everyone was a huge help to me and my teammates in creating interactive theatre. Thank you once again.

Cheers,
Ben

Viewing 18 posts - 1 through 18 (of 18 total)
Forums > Jitter