jit.movie~ jump to somewhere not working
I am trying to jump to various points in an relatively long (i.e., 17 minute) video file which I am playing back using jit.movie~.
I have tried with "jump," "jump_true," "frame," "frame_true" and "time_secs" but the result is always the same: playback stops and starts again from the beginning (usually with lots of glitches).
Interestingly, with DAC turned off, it works as it should (but this is no use to me!). I thought that the large size of the video file might be causing this, so created a very low-res version which is only 360Mb, but the problem did not got away.
Not sure if I need to load this file to ram for this to work? Hopefully not, as the hi-res file is huge.
Any ideas?
I did a quick test on my computer (MacOS + Max8.2.1) and "jump" message works fine for me. Can you post your patch and add some info about OS and Max version you are using?
I am using Max 8.2.1. My computer is a little old and is running OS10.12.6.
Ok, your patch will be really useful if we want to track the problem, but, anyway, here is a simplest possible construction I can imagine and "it works on my machine":
Here is the relevant part of the patch:
There are a few other objects in the mix, as I am using the time_secs output to run a visual time-code.
I should add that this works fine for me with short video files, as in the one in Yaniki's example.... the problem only crops up with longer videos.
In Yaniki's patch, I encounter the exact same problem if I load a long video file.
I just tested jumping around a bunch of long-ish movie files with no issues, so it's most likely a codec issue. what codec and container format is your file? Feel free to send me link to the file and i'll try and reproduce, email in my profile
I have tried with ProRes 422 and ProRes 422 Proxy @ 1920x1080 (both in .mov format ) as well as with H.264 @ 1280x720 (.m4v).
I suppose that the problem could simply be that my computer is a little too old to handle this. But the fact that I can jump to any point in the video when DAC is off, even when using the file with the largest size (i.e., 6.2Gb) , makes me think otherwise.
@Rob Ramirez: am uploading an example file now, will send you the link when it is done.
Alternatively, you can try to use jit.movie (instead of jit.movie ~) and synchronize the video playback with the soundtrack loaded into buffer~.
@Yaniki: I was doing this originally, but the slight drift between the playback of long video and audio files led to occasional jumps in whichever was synchronised to the other... hence my choice to play back audio with jit.movie~.
hi Paul, I took a look at your file and it seemed all good to me. I also had no problems playing it with audio enabled and randomly jumping around. However with files this large you absolutely should be using @output_texture 1 if you want decent performance. You probably also want to increase @cache_size to give the decoder a larger buffer to work with. You may also want to ensure that your audio driver sample rate matches the sample rate in the file.
My guess is that when both audio is enabled and matrix processing is enabled, the cpu drain on your machine is too much to keep things running as expected. hopefully if you can offload the image processing to the GPU (via output_texture 1) and keep it on the GPU (i.e. don't use any matrix objects further down the chain) then your CPU will be able to handle the audio load and keep things running smoothly.
try playing back with this simple patch and see if things improve:
Thanks very much for all this, Rob. It seems that my computer simply isn't up to the task, if it worked okay for you. Even with a straight-forward setup as in the patch you posted, I had the same problem. Hmm, time to buy a new machine.
With regards to the jit.movie~ attributes, I was planning on setting a 2Gb cache once everything else was up and running in the patch. As for output_texture 1, that is problematic, as there will be a point at which I need to cross-fade from this video to another which is manipulated in real-time. As I understand it, with output_texture set to 1, this is impossible, no?
crossfading textures is of course possible! simply use a [ jit.gl.pix @gen xfade ] instead of jit.xfade. You will really get no better efficiency improvements than switching from textures to matrices.
https://cycling74.com/tutorials/best-practices-in-jitter-part-1
https://cycling74.com/articles/jitter-shaders-or-gen-patcher-equivalents-for-common-jitter-objects
Thanks Rob!