Playlisting tool in Jitter, issues with loading videos
I'm working on a playlisting tool, it takes in a txt file of videos, loads it into a coll, and loads a "current" video, and puts the "next" video on standby (for transitional effects). The main issue I've had has been with trying to bounce back and forth between which movie object is holding the "current" and the "next" video, but I think I have the logic working now. The problem I am having now is a small pause as the "next" video is loading. Could anyone give me some advice on how to clean this up and get the cleanest possible transition for this scenario? Also if anyone would like to take any of this for something of their own, feel free, hoping to contribute something back when I'm finished with things.
Reading a movie file from disk to RAM will always have a slight delay.
I think there are many strategies to avoid this.
I think the simplest way is to just have a video player for each file you wish to play. (which would be a problem if the total video size is more than your ram)
By preloading all your video files when the patch opens you avoid any delays with loading.
I'm not able run them all on ram, I want the patch to be adaptive for large sets of videos, and really the pause would be worth it to keep the long playlist. I hoped that loading it into the other buffer when it's not being used would prevent a pause, but maybe now I'll try to find ways to make it less noticeable. Is there anything that might at least minimize the pause?
Drop every gui object you don't need like jit.pwindow and float/message boxes.
if you get an ssd drive i doubt it'll skip at all.
I don't suppose an external hdd would make a small improvement? (I'll just have to give it a try later). I have no reason to really think it would, but it will be interesting comparing the speeds anyways.
hi austin.
use "asyncread" instead of "read". also, as mentioned, those pwindows are going to slow down performance dramatically. if you need that feature, add gate objects to that you can enable only when needed.
if asyncread doesn't give you enough of an improvement, using something like poly~ or the js (as demonstrated in jsmoviebank-example.maxpat) to pre-load the movies is your best option. the movie files aren't loaded into RAM, but simply read and initialized when you open your patch so that when triggering a specific movie, there is not lag.
Great, thanks again. Both of you have been a huge help in understanding Jitter. I was only using those pwindows to visualize the logic (and to try to get a better understanding of the lag). The asyncread method worked perfectly, very happy with how this is going now.
Do the reaction times for jit.movie messages relate to the size of the video? Seems like my position and rate messages are slightly delayed.
probably more related to codec. h264 will be slower when seeking compared to photo-jpeg or prores422.
if you do a lot of random seeking, it might be better to stop automatic playback (send the "stop" message), and control playback via the "frame" (or "frame_true") message.
but yes, i'm sure file size has something to do with it.
I've been using prores422, which I've read is a solid choice for decoding efficiency. Is there any variant of this that would be better? Do you know how this might also relate to changing rate of videos that are being pushed into gl? I'm sending a rate message to the jit.movie, and it either seizes up or doesn't work, unless I move very slowly or invert the number (in which case it isn't quite as responsive as I would hope). Do I need to do all time based stuff like that through the jit.movie object or is there a more appropriate way of doing that through some gl object?