jit.movie~ will not loop video smoothly at end of video
Using jit.movie~, I'm having issue with video not looping smoothly, at end of each loop there's a slight but noticeable pause, for example playing MP4 h264 videos. This happens on both Mac and PC, playing PJPEG MOV codec videos seems to loop fine, however today a lot of videos are compressed into H264.
use the loadram messages to load 1 second from the start and end of the file, and make sure your cache_size attribute is adjusted as needed. These messages can be triggered automatically on file read.
Thanks for the example here, will test this out.
Technically jit.movie~ should work the same as jit.movie without this work around, no?
depends on your default video engine. on mac jit.movie defaults to avf engine, and jit.movie~ is only supported by viddll.
but even if they're both using viddll, jit.movie~ is doing processing that jit.movie is not, so hard to say they would behave exactly the same. additionally, seamless looping with viddll depends on many factors (codec, files size, texture output, cpu usage, gpu, etc) but in most cases will behave much more reliably with the cache_size increased and looppoints cached.
Hello Rob
thanks for this patch. So to understand it right. QT engine is not supporting output_texture?
I had the same problem: Couldn't get a seamless loop from viddl engine.
Your patch works but there is one thing that bothers me:
when i change between several videos or retrigger the video it jumps briefly to the last frame before starting from frame 0. how can i change this behaviour?
thx so much
qt engine should not be used unless there is a very specific reason.
can you block the output (e.g. with a gate) until it is finished loading the frames? you could use the loadram notification to trigger a counter to count a couple frames before opening up the gate.
thx for the quick reply!
i am sorry i am not fully understanding your answer.
i cant figure out how to implement this. i think for retriggering the clip when it is already in the ram i could make it work. but if there is a new clip coming in it would happen again.
i would love to trigger a lot of clips smoothly for live vjing according to a beat without hiccups.
so that means out of the box the viddl engine is not able to loop smoothly?
if you use an optimum realtime codec (hap, prores, etc) and keep the file sizes reasonable and are running a machine with adequate resources there is no reason either video engine can't loop smoothly.
there is no such thing as out of the box with Max, hence the blank patch, so tweaking for your scenario is part of the process.
i've attached a patch that can be used as a starting point for a 2 channel video switcher for dynamically reading and manipulating video files with Jitter using viddll engine loadram.
The trick I alluded to above is implemented here, a mechanism to gate the output a certain number of frames to workaround any file glitches you are encountering . The patch demonstrates loading the entire video file into cache, and then randomly outputting frames at a high fps. I can execute this process on my machine using the stock h264 1080p files (a poor codec choice for any type of dynamic playback manipulation), at a steady 60fps with no glitches when switching files. These particular files are small enough to entirely fit in the 3GBs of ram allocated for each channel's player.
One thing to note since playback is entirely controlled by the random object and frame message, the jit.movie object never starts playback. For looping you'd likely want to trigger start and stop messages in addition to the looppoints. Your situation needs may be entirely different, so this is merely demonstrating a technique to try.
but as always when dealing with realtime video, codec is the biggest factor (after ensuing texture output and gpu processing is enabled).
Hello Rob
thank you so much for your answer. i really appreciate the help.
i studied it for the last hours and fiddling with different behaviour of loadram vs loadram -1 vs loadram 1.
I am using a prores codec on all my videos btw which i thought should be a good choice. also i am using a ssd drive.
Unfortunately using a two channel video playback where i would delay the switching when the other video is load into ram doesnt work for me.
I am using a sql database which i build over years now based on this tutorial by Andrew Benson: https://cycling74.com/tutorials/data-collection-building-databases-using-sqlite
So i want to trigger and switch the videos (the list is around 5000) from the database and i want them to loop if possible without any delay. So i would love the provided expample to work without hiccups only for one channel and as tight as possible.
I am aware there is no such thing as "Out of the box" i am just sometimes a bit confused. When i switched the engines from qt to the one which is supposed to be better: viddl simple things, which i took for granted, dont work any more (seamless video looping). And i would really want to use the opportunities texture based processing is offering. And it is sometimes frustrating to figure out these simple things which i took for granted takes way more patching time than i expected .
So here are my observations:
Loadram-1 is responsible that the video starts at a different frame. I guess it starts one second before the end maybe? The message is also responsible for making a seamless video loop1 on the other hand.
Loadram 1 doesnt to start at a different frame and works fine. But doesnt help for seamless looping.
Loadram works fine if videos are not too long(too big). If it exceeds a certain size (e.g 4 seconds in my case with a prores codec) it causes a short loading pause when switching videos
What the difference is between using asyncread/read was not obvious to me. i guess it is something ram related. To understand correctly: loadram only fills up the ram from the selected video and frees the ram again when another one is selected?
So for now after spending two afternoons i could not find any satisfying solution yet:(
If anyone has a solution how to use loadram-1 without a glitchy starting frame i would be happy to be taught!
thanks
After wrapping my head around it for a little more time i came up with the following solution: it is a combination of the two patches rob provided. I am using the second video player only for the start part and then disposing its content after 300ms and stoping it. that way i hope to achieve better performance than 2 video player playing at the same time
updated with correct patcher
Hi Linden, I'm dealing with this issue, too. Unfortunately, the patcher in your last post is incomplete. I would like to have a look at your solution. Could you please send the patch again?
ah sorry
here it is:
interested if it works for you.
let me know
Thanks, Linden. That works for me! Great.