Problems with occasional freezing of videos
I'm working on a rebuild of my video synth, partially to resolve these exact bugs. Attached is my playback tool. It juggles through videos in a playlist in a way that allows me to transition to the second buffer, where the first buffer has a new video loaded in the background. This really helps me get smoother transitions, but for some reason I have occasional freezing problems. I'm not pausing or stopping the video anywhere, it's just simply that at times the video is loaded but doesn't begin. Does anyone have some advice on how to combat these sorts of bugs? (Or do you possibly see a glaring problem in my patch?)
Thanks!
the problems are the two jit.pwindows receiving the jit.movie texture output, which causes a texture readback in order to display the video. search for "GL Texture Output" in the reference browser for more information.
you need to create a unique gl.render / pwindow context with sharing enabled, for each preview window you want. see my first reply here for an example: https://cycling74.com/forums/best-video-codec-video-engine-on-windows-10-moving-from-max-6-to-max-7/
Thanks Rob. Still can't seem to get it, I have made sure that the two jit.movie texture outputs are being sent to their own videoplanes, each named differently (m1 and m2), and then I created to jit.gl.render objects for m1 and m2. The jit.pwindows have 'shared' enabled, and are named m1 and m2. Displays, but almost immediately ran back into the freeze bug.
Also, the two jit.pwindow objects are purely for testing and I am absolutely willing to set those aside. The problem is that it is happening with or without those windows.
the problem with stalling frames might be that you are not waiting for the "read" notification (which indicates that the file is ready for playback) before banging frames out of the movie object.
i would do it slightly differently, with logic to control a switch based on whichever movie is currently loaded:
I like your solution. I need to be able to use my xfade, but I'll be keeping that around for situations that I don't. I am still having a problem getting your jit.movie dumpout (bang upon read) part to work. It seems like automatic 1 is just not working, I can't tell if I'm just missing something to properly bind it to jit.world? Since it's enabled and "drawto" is set for mainout (same as jit.world) I thought it would work...
Just as an update, here is where the patch is now:
you also need to send the "start" and "stop" messages to the jit.movie objects. start and stop control the internal frame reader/decoder, automatic (or banging the object) controls the jit_matrix output.
I am using start after automatic is set to 1, but it's still giving me (rare) freezes. Seems like it's happening less, but there must be a reason for this in the logic of my patch right? I know that I will get some occasional pauses during load, which I can live with, but freezes are much harder to work around. Could it have something to do with not sending "stop"? I figured that I could get away with it because "start" was being sent.