you could try @colormode uyvy on your jit.movie (simply adding that attribute to the jit.movie box is all you need to do, no other patch changes are required).

you should also try some different codecs. the avf engine has a super fast h264 hardware decoder, so that might be a good codec to try, especially if you aren't doing a lot of random seeking or reverse playback. otherwise try Prores 422.

you should also make sure your movie dimensions are no bigger than they need to be for your final output size

it might be worth trying the viddll engine, especially if you are running in 64 bit and the video clips are small enough to load into RAM. adjust the jit.movie @engine viddll @cache_size attribute to reflect the memory you have available (the value is in gigabytes).

another alternative (especially if the clips are too large to fit into memory) is exporting all the clips to the Hap codec, and using the jit.gl.hap external for playback (32 bit only).

it looks like the matrix processing for your gradient is only triggered at initialization, so that should be fine, but you may want to remove that part of the patch and see if there's optimizations to be found there.

please let us know if any of this helps.

Hi Ben and Rob,

@rob, you could confirm this , but I thought that the advantage of @viddll engine is that you could finally run hap codec in 64 bit !! :-) !!

Thanks Rob for all this - much appreciated.

So I just upgraded Max to 7.2.3 and am getting acceptable framerates now and can run the viddll engine as you suggested. I had an error before in 7.2.1 and couldn't run viddll. The decoding was definitelty the thing that was creating the bottleneck before, and the viddll engine seems to have improved things quite dramatically. Thanks for the heads up on this one.

We tried HAP but the files were just way too large, and we're going to be working with continuously recorded video files so not sure if we can encode these into HAP easily before playback in jitter. I'll give this a go in the next day or so and see if there are any improvements there. Also some useful info re gradients from Plgrm Visuals on the Jitter C74 facebook group - post to this for anyone interested is here: https://www.facebook.com/groups/961274147281218/permalink/1078440102231288/

I'll try viddll also with a loadram to see if it improves things.

Cheers!

Ben

Update - we have it working nicely with 12 x 720p videos, however our program crashes when we try to load 12 x 1080p using the viddll engine.

Our FPS for these vids is hovering pretty consistently around 19FPS - which for our purposes is acceptable.

Have attached a crash report and an error log below.

Thanks again for the help.

Ben (+ ollie)

@ben If you ever choose the hap direction. Make sure that viddll is your default video engine in preferences for it to work with hap in 64bit. not just @engine viddll in jit.movie @output_texture 1

good luck

Update: @ ben, I just looked at you patch here is what I suggest

[qmetro 60Hz] [jit.movie @drawto tw @output_texture 1 @colormode uyvy @loop 1 @engine viddll]

wow - this is fantastic, @phiol. Still getting the crash with 1080p vids but might try loading them one at a time, but doing what you suggested re the qmetro and the jit.movie setup we're sitting at 60fps running these twelve vids. Amazing - thanks!

my pleasure

here have a look @ my gpu xfade video patch . hopefully it can be of help

Change it to @engine viddll.

After looking a your patch a little, I would suggest you try to do all you gradients etc... using jit.gl.pix and try to stay on the gpu. Make sure you have absolutely no jit.pwindow. not even small ones. No UI what so ever.

phiol

PHIOL - viddll can playback Hap encoded files, but may not be as efficient as the jit.gl.hap external, especially for large dim movies.

BEN CAREY - you are possibly running out of memory. i would run your patch and monitor memory usage with something like Activity Monitor, to see if that's the cause of the crash.