maybe you can preload not all the entire files but just the beginning, let say 1 second or less like in he VPS example.

you can try reading int the quicktime movies at initialization. not preloading, or loadram-ing, but simply reading in a single time.

you can also try creating a separate java-thread to load the movies, as described here: https://cycling74.com/forums/multi-output-poly-for-movies

David,

You're asking a really good question here. I hope it gets some attention, or at least a response, from the developers. This is the reason that I have never used Max for realtime performance.

I do live video improvisation. At any point in the performance, I need the capability of loading several short quicktime loops into a patch from a large database of loops on hard disk.

I have never been able to do this in Max without the interruptions you describe. I've upgraded computers several times, moved from slower hard disks to faster ones, and eventually installed the fastest ssd's available, and still no luck. As you did, I spent a lot of time trying to find the file size and codec. Again, no luck.

Some of the VJ software in current use has the same issues. I see some problems at times with Resolume, VDMX and Modul8, but their performance is much better than Max6.

I hope someone knows a good solution for this. It's a serious limitation that doesn't appear to have a good workaround. It if could be solved by Cycling74, Max would have a real advantage over many other video app's. Right now, it does not measure up well at all.

Best regards, Michael

Hello Robert, Thanks for the tips. I tryed both, but they are definitly not working. Also tested: jit.qt.movie inside a ~poly As newdendrite, I tryed different hardware, codecs ....

From my standpoint this is a bug in asyncread, which is known since years and affects many users.

It would be great, if the dev team of c74 find a solution to avoid this interruptions while load.

An other thing is, that we always have hickups while playing a movies with jit.qt.movie.

Perhaps it is a good idea to develop a new movie object, which has less functionality but a stable, optimized loading and playing.

Just my 2 cents, kugelschreiber

Robert,

Thanks for the ideas. Unfortuantely, they do not work for me, either, because I need to load directly from a ssd while other files are playing. There are simply too many possible files to read them all in at initialization.

An optimized movie player would be a great idea and a real contribution to users working with video. If the use of a separate java thread actually works, this would be a good candidate for a Max6 object from the developers? I am not able to get the java code in the original thread to compile, though.

Best regards, Michael

hi guys, this has been discussed many times on the forums. see joshua's replies in this thread: https://cycling74.com/forums/smooth-video-playback

hello robert,

joshua's thread addresses the hickup isssue. (or call it bug)

joshua wrote in this thread: "However, we are investigating improvements for Max 6"

it was 1 year ago !! no improvments in max6. very sad or all, who want to play movies with jitter. (even smal ones)

this thread is about the interruption of a movie, while loading another movie.

still unsolved problem .... perhaps someone has a working workaround ;-)

it would be great to get a roadmap, when the dev team is working on this issues.

@newdendrite: the java-thread loading recommended by robert is definitly NOT working on mac (max5 or max6)

kugelschreiber

Hi all, So...looks like I'm not alone! I knew that, actually...just was hoping others have had more success or workarounds in Max 6 land since it had been a bit since the last post on this issue. I often use Max for presentations for industrials (i.e. dog and pony shows for other companies during conventions and the like). For these we usually have one of two hd video playing in the background, then are loading on the fly a ton of png files, each often with their own "animation" (scaling, position, alpha, jit.anim, shader effects, etc. etc.). Each time I load a new image, not only does the background image stop for a moment, but all other video effects stop, too, while the image loads (e.g. if I'm moving an image in from off screen while loading another image its movement will stop while the other image loads, then continue). Obviously I've set-up the show to minimize these issues, preloading images where I can (unfortunately each show has hundreds of images, so pre-loading everything but the movies into RAM isn't an option since Max will quickly run out memory...64-bit anybody?). What frustrates me is that I don't see these hiccups in software like watchout using the same machine (which has to be the mspaint of video control software...don't make me use watchout!).

I guess the question I have is where we think the issue lies? Is it quicktime? And what might be the workaround (a non-quicktime object)?

Thanks, David

Now that I've had a few more moments to follow all the links mentioned above I see that there really isn't an easy solution to this (not that I expected there to be, but was still holding out for something that might work better). It does seem to be quicktime, and building another engine to replace quicktime doesn't appear to be in the cards at the moment. Certainly other options to explore outside Max while still maintaining control within Max...still would be nice to have everything under one roof.

Can anyone from cycling74 comment on the possibility of a 64-bit version of max in the not-too-terribly-distant future? This would at least allow us to pre-load more files. Another option would be to create several different apps that do nothing but preload images, but that would only work on the Mac via syphon in order to get everything back into a single rendering context.

Definitely presents some challenges!

Cheers, David

Its no real solution but if you want to load more into ram, use a ram disk.

hello cycling74 team, i am planning a big project, which will happen in the end of the year. for me it is very important to play and load full hd movies fluenty.

is it possible to give me some information, if you are working on these bugs. or will the jit.qt.movie object will be as it is in this period ?

cheers, dupecom

Have any of you tried the VIZZIE PLAYR object? Loading movies into it seems to cause a shorter interruption, although a visible delay is still present. Unfortunately, using multiple PLAYR objects is not a solution. That would place many small moving images in patch, and these would slow system performance, too.

This suggests to me that there may be ways for the developers to address the problem, though. If they can reduce the interruption time with a new object, perhaps they can eliminate it.

Best regards, Michael

A workaround might be to load the video's in another application (VJ software, quartz composer, ofx,...) and use syphon to send it to jitter. Might introduce new performance issues but it's worth a try.

Hi all,

I also tryed VIZZIE PLAYR, same here 1 second hickup while loading clips. But i found a workaround for the loading issue. If you copy all movies into one single quicktime file and jump in this file to avoid using the asyncread method every time, you load a new clip. Thie can be done automatically with applescript.

But this is very cumbersome ... And it does not solve the hickups while playback.

The cycling74 team has not answered, so i count it as a: No, we do not see a problem here, we will not fix these bugs.

This is sad. I personally love patching with max. But cycling74 team chases me to other patforms ....

I will do my project in openframeworks. No stuttering while load and playback !

cheers, dupecom

I have this issue too. I am very disappointed with Max Msp. It is not good for real-time application. I spent a lot of experimentation without success. The only good usage of Max Msp is to control a render engine that is made in different framework such as openframeworks. However it's not efficient to use two different things so I am thinking also to quit using Max Msp too.

Has anyone ever tried building the video players as separate standalone applications and sending commands to read files from another patch? Would that somehow compartmentalize the video buffering?

I did yesterday after posting my opinion. I gave a try. I made an two channel videoplayer engine in openframeworks with a crossfade function. The crossfade is shader based. I controlled the changing of video clips and crossfade via OSC protocol from Max4Live. I tested two approach:

1.When changing video clips the previous is unloaded from memory and the new one is loaded into memory Behavior: I got the same problem as in Max Msp, a noticeable interrupt while loading.

2. I loaded all video clips into memory when starting the application Behavior: Interrupt is less visible when two HD movie is played, but if only one movie is play no interrupt as well.(See the bellow related explanation)

Another behavior that I identified that in openframeworks when you play two HD videos at same time the video playback isn't smooth, a small flickers occur randomly. But when I play only one video the playback is smooth. Furthermore when both HD video is played The fps rate is 30-37fps. When only one than it is ~50fps.

In overall it is better performance but I guess there are other bottlenecks too. In my case could be a HDD since i don't have SSD or too high PhotoJpeg compression but I don"t have any useful clue at this moment. I hope this benchmark might be useful.

Regards Attila

I made a progress. I replaced the PhotoJpeg codec with Hap codec and in openframeworks used ofxHapPlayer. All interruption gone and fps increased to 58 fps when playing two HD video at same time. Hap codec decompress video files on GPU unit leaving CPU free for other things. For converting videos to Hap codec I use MPEG StreamClip application (Hap codec need to be installed first).

More info on : http://vdmx.vidvox.net/blog/hap https://github.com/bangnoise/ofxHapPlayer

Regards Attila

Hi all,

I did some testings with the new increadible avf videoengine. Well done C74 ! But it seems, that we still have the problem that all videos are stooping while we read another file ...

I think this is a "show stopper" for many of us. I thougt i could realize my recent project with max instead of openframeworks ....

But it seems, that we have to wait for max 8 :-(

yonfell

hi yonfell. this is something we will continue to investigate making better, now that the avf framework is in place.

jit.gl.hap is really great, thanks.

Is there already a solution for the hanging while loading a new video? The same happens with two hap playbacks, if I reload the first, the second playback hangs shortly.

An improvement would be so fantastic!