jit.movie looping issues
Hi,
I'm new to Jitter but not Max and I'm struggling with a jit.movie issue. I've been asked to make a patch that grabs and loops portions of video. I had (perhaps naively!) assumed this would be fairly similar to how it works in the audio realm but I'm running into difficulties. Patch is below, but I'll try and explain what I'm doing. Essentially, I want to trigger a loop that will be current time + x milliseconds, and upon release, continue where the video left off. At the moment I can kind of achieve what I want, but when I release the loop, the video seems to intermittently stop a few seconds later, though if I poll it with 'gettime' it still shows that it's playing, just not updating in either jit.world or jit.window. What am I doing wrong?! Any help greatly appreciated!
Note - I'm using the viddll engine as I read elsewhere it can be more reliable when doing this sort of thing, but the looping issue occurs with avf too.
Thanks,
Robin
I should also add I've tried a different approach where looping is always on, and I set the loop time to be the small loop when required, then set it to loop until the end when the mini loop is turned off. Behaviour is the same
use jit.world and jit.movie @output_texture 1 to improve overall performance, which should in turn improve looping performance.
use codecs that keyframe every frame (e.g. hap, prores).
Thanks Rob. jit.world and jit.movie @output_texture 1 definitely improve the smoothness but I'm still having the same issue where sometimes the video stops a few seconds after the looping ends. It doesn't always do it, and I seem to be able to 'free' it by triggering another random loop. I'm at a bit of a loss to be honest. You think that this is a codec related issue?
Try to use "@cache_size 1." argument in your jit.movie object. It will cache 1GB of your file for smoother playback. You can increase the value depending on your system, patch and files. I think you need to use the viddll engine for this to work.
The is also the more agressive loadram technic (see the [p loadram] under the "VIDDLL specific" tab of the jit.movie helper patch).
I have very smooth looping videos (playing backward or forward) by using a 3GB cache size (my system has 16GB of RAM) and videos encoded in MJPEG (you can use ffmpeg or more easily Mpeg Streamclip from Squared 5 for this).
EDIT: From my understanding, using loadram messages is for a more "precise" use of your defined cache_size as it gives you the ability to cache the desired parts of your file (for instance the last second and the first one for a smoother looping).
About my case: I have two jit.movie playing video files (720p encoded in MJPEG, between 100MB and 300MB each for 1minute of movie) both with a cache_size of 3GB, and this way I got rid of any stutter while looping.
Also mind that a 100MB movie file does not mean 100MB of used cache. It's actually way more as from my understanding the software will cache "ready-to-use" uncompressed frames).
Thanks for the reply but smoothness or stuttering isn't the problem I'm having
Oh sorry I read your first post too fast...
Unfortunately your patch seems to not work with Max 7 I have (gettime_ms and getmilliseconds are not recognized by jit.movie).
But yes the codec can be an issue. I think the player can be kind of lost if your loop points are not on a keyframe. Maybe if you cache the whole movie in RAM it can work better. Or use a proper codec.
Thanks, I'll give it a try
I've tried loading the movie into memory - same issue. If I loop a small portion, then tell the movie to stop looping the small portion and instead loop from the current position to the end, it freezes after a couple of seconds. Do you think HAP could solve this? Second question - what's the easiest way to encode a video as HAP?
Thanks
Lovely, thank you
No difference with HAP :(
I'll be spending some time with the viddll engine over the next few weeks, and will try and reproduce the issues and see if any improvements can be made
Hi Martin,
Thanks for this. It works really well except if I try and use the video I was using for the previous patch, which eats up all my RAM and crashes Max. That's really useful though as it definitely suggests that the issue is related to memory/the video I'm using.
Robin
Hi Rob,
Just FYI, the same issue occurs with AVF. I've managed to get around it by using the time message to jump to a point repeatedly rather than setting loop points though.