CPU usage and looping issues using viddll with jit.movie

David Flaherty's icon

I'm using the viddll engine in order to trigger jit.movie video playback with very low latency. Loading a video into ram with the "loadram" message does indeed allow me to trigger the video very quickly, but it also causes a spike in CPU usage, getting as high as 100-200% after loading just a single 4.2 MB 720p video. I have a patcher with several jit.movie instances that use jit.movie's @moviefile attribute to load video files and it reaches over 800% CPU when using viddll—and that's without any videos actually playing!

In addition, in spite of following Rob Ramirez's advice on viddll best practices (https://cycling74.com/forums/jit-movie~-will-not-loop-video-smoothly-at-end-of-video#reply-5d8a294a816dc95cca0babd0, except transcoding to HAP, which I was hoping wouldn't be necessary), I can't manage to get smooth looping working with viddll.

Am I missing some basic configuration step of some kind? Running 9.0.8 on an M4 Max MBP with plenty of memory.

Max Patch
Copy patch and select New From Clipboard in Max.
Rob Ramirez's icon

I imagine the spike with nothing playing is the loadram process loading the frames. Yes the frame cacheing in viddll is a CPU and RAM heavy operation, so 800 % cpu for loading frames from a few m4v format high decoding cost codec sounds as expected. If you need to manage that load you can sequence the movies loadram operation to happen one after the other (using the loadram notification out the dump out). It will happen in a background thread.

But otherwise the most important aspect of realtime move file manipulation is using a realtime codec. You either pay the cost ahead of time with the offline transcoding, or in realtime with the frame loading.