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

Apr 22, 2009 at 4:13pm

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

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

#43483
Apr 22, 2009 at 5:53pm

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

#156000
Apr 22, 2009 at 6:29pm

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

#156001
Apr 22, 2009 at 6:44pm

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.

#156002
Apr 22, 2009 at 7:30pm

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

#156003
Apr 22, 2009 at 7:44pm

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

#156004
Apr 22, 2009 at 10:22pm

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?

#156005
Apr 23, 2009 at 2:35pm

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?

#156006
Apr 23, 2009 at 7:57pm

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

#156007
Apr 24, 2009 at 1:13am

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.

#156008
Apr 30, 2009 at 3:25am

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?

#156009
Apr 30, 2009 at 12:14pm

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

#156010
Apr 30, 2009 at 2:27pm

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

#156011
Apr 30, 2009 at 9:07pm

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.

#156012
May 5, 2009 at 2:26am

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

#156013
May 5, 2009 at 2:26am

Here is a typical patch I am using with poly~

Ben

#156014
May 6, 2009 at 6:08pm

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

#156015
May 8, 2009 at 9:23pm

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

#156016

You must be logged in to reply to this topic.