jit.movie~ stops playback when changing loop points
Hi,
I encountered a weird bug and I'm not sure if the problem is in my code or in the way jitter deals with looping.
The idea is to make a "video stutter" effect by changing the loopend and loopstart points when pressing a toggle. The stutter effect works nicely but what happens is that when I toggle the effect off the video playback stops after a few seconds; the playbar shows that jit.movie is still going through the frames, but the pwindow is frozen.
I tried with various .mov and .mp4 files and the issue appears with both formats. One thing I did notice is that the bug doesn't happen with short videos under 3 seconds. Does jitter have issues dealing with long videos?
I'm attaching the patch - read the dozer.mov file to see how the stutter effect should work and then try to load a longer length .mov or .mp4 file to see the bug in action.
try increasing your @cache_size value (check out the jit.movie help file, in the VIDDLL tab, for info on this attribute).
also, you will have better performance if you replace the pwindow with a jit.world, and enable output_texture on the movie~ object
Hi Rob, thank you for the reply!
Your suggestions lead me down the rabbit hole of different engines, codecs and GPU vs CPU video processing. Before I go any further I just want to let you know that I am using OS X, since that might have some relevance.
First of all, I tried the VIDDLL suggestion (my default engine before was AVF). While increasing the cache size does help for loading frames into RAM it does not help with playback on the first run of the movie file - I assume the movie has to play through all the frames first in order to store them and then you can manipulate the loop points as much as you want. In order to deal with that I looked into the "loadram" message. This fixes the freezing of the playback since the movie is stored inside RAM but it takes a lot of time for the process to finish. This is an issue since the patch I am building needs to load different movie clips in real time (I want the video to trigger with the press of a MIDI key).
I came across some forum posts about a "preroll" option but I can't seem to find it in any documentation. Is there something along those lines available in Max 7? Obviously I don't understand how it worked but I'm assuming it loaded a couple of frames ahead of playback in order to account for errors such as mine?
I also experimented with using different codecs and following your suggestions somewhere on this forum tried both h264 and ProRes 422 and found no difference in terms of my issue. I did however find that using short videos still helps - I exported different lengths of the same movie with same export settings and found that the error tends to stop occurring at the length of 6 seconds.
Finally - I used the jit.world suggestion and while I hope that it did indeed increase my performance, it didn't help with the issue of a freezing video.
Thanks for your help!
I think I know what the problem is. jit.movie~ needs audio enabled and something connected to its audio outlets in order to read through the file, otherwise the audio buffers get jammed up and output stops. give that a try and let me know if that fixes things.
Hi Rob,
thank you for the suggestion. I tried out both using jit.movie instead of jit.movie~ and connecting the audio outlets from jit.movie~ to an ezdac~ object; none of them solved my issue.
I'm attaching the current patch that I've made with all of your recent suggestions. Can you tell me if it works for you? Even if you use video clips longer than 6 seconds? If needed I can also send you the exact video clips that I am using in case that could be the issue.
Thanks for helping me through this!
ah ok, I see the stall now, takes a few seconds to kick in. I'll ticket this as a bug, thanks for persisting.
in the meantime, you might be able to patch a work around of sorts. if you enable @unique 1 on the movie object, and then use the output to trigger a delay set to some threshold value (~60 maybe) and use this to a trigger a frame message with the current frame as an argument. this way whenever a stall happens, the frame message will be triggered and hopefully kickstart playback.
Hi Rob,
I don't think I understand what you're suggesting. If I enable @unique on my jit.movie~ object I can now monitor when the stall happens by observing a button connected to the matrix(out). That is great but I don't understand how the delay object plays into that.
As far as I understand I need to be able to detect the lack of bangs coming out of matrix(out) and when that happens trigger a frame message with the current frame as the argument. The only thing the delay message does, is it constantly sends out a frame message with a delay, causing the movie object to stutter.
Could you elaborate on your idea further, I'm sure I'm missing something obvious.
yeah that's basically it. the delay won't fire as long as it receives bangs at a rate faster than it's delay time. so as soon as the file stalls, the delay will fire the bang:
Thanks Rob, the workaround works!