rbedgar@stanford.edu

I am playing a quicktime video not by using the default playback, but by using the "jump" command to jump from one frame number to another. I'm jumping around in the movie, not just playing it linearly...ideally delivering one frame at a time, at a frame rate of about 30 fps.

This actually works fine with one Quicktime movie, but I've got two jit.qt.movie(s) playing in parallel, and once I engage the second jit.qt.movie the frame rate slows WAY down to a few frames per second. I'm trying to substantially speed up the playback when both movies are playing.

I've based my patches on the well-known examples provided by Vade.

I've tried putting the separate quicktime video source files on separate hard drives, but that doesn't seem to help.

Anyone have any suggestions for how I might speed this up? I'm using the Apple Motion JPEG A codec, and have a set horizontal and vertical size (so making it smaller isn't an answer for me).

It seems intuitive that loading portions of the files into RAM could help, provided I managed that the range of the jumps stayed within the portion of the file that is loaded. I would then manage unloading and loading additional portions of the file into RAM as I changed the ranges of the jumps. Does this make sense to anyone who knows how the jump command affects the hard disk seeking by jit.qt.movie?

I've tried putting the separate quicktime video source files on separate hard drives, but that doesn't seem to help. 

Anyone have any suggestions for how I might speed this up? I'm using the Apple Motion JPEG A codec, and have a set horizontal and vertical size (so making it smaller isn't an answer for me). 

speeding-up-jump-for-jit-qt-movie

Actually using "frame" not "jump", and not "frame_true".

You could try merging both vids into one file and doing something like the following (add Vade's optimizations). This should avoid the slowing framerate, but it may not work for you if audio is involved.

I tried a variation on this, and it DID speed it up, probably enough for me to work with it. I'll try to smooth it out a bit over the next few days, but it does seem to provide the speed I need. Thanks very much.

OK...interesting.
I tried a variation on this, and it DID speed it up, probably enough for me to work with it. I'll try to smooth it out a bit over the next few days, but it does seem to provide the speed I need. Thanks very much.

I'm having the exact same problem and it's been driving me nuts trying to troubleshoot, and not making progress:

Using "jump" based on analysis of audio, to pick frames from a video file. This works GREAT until I want to have Jitter load a different video file.

Then I get amazingly sluggish performance, Jitter errors like "could not allocate matrix" and my ol' friend the spinning beach ball.

Do I have to "unload" the old movie somehow, before I can put in another one? It almost seems like the two movies are fighting. They're both the same format/approximate length.

Sorry for the incredible length of the pasted-in patch below. I've got a bit going on there. If it's impenetrable I can make a straightforward, "troubleshooting version".

As for putting these into a single movie, I'd like to avoid that-- this should ultimately be something people can drag their own clips onto.

Using "jump" based on analysis of audio, to pick frames from a video file. This works GREAT until I want to have Jitter load a different video file. 

Hmm...when I tried to load your patch (I'm using MAX 5 on a Windows computer) I received this error:

value expected in array, possible extra comma or missing "]": line=1188, char=44, text='..."hidden": 0 "midpoints": [321.5, 116.0,.'

It might be that creating a stripped-down version would be a good idea. Of course, this message might give you a hint also.

In my own code, I'm using "frame" and not "jump"...jump moves to a frame a specific distance from your start frame, and I'm moving to a specific frame number. I'm "jumping" around in the file continuously, and it moves at about 30 fps when I'm only doing this with one area of the file. However, I'm trying to make this work using two "jump" start frames and jumping targets at once, and that is slowing it way down to a few frames per second. But nothing as slow as you're reporting.

I should say that I can also load new video clips into this program, but with no new problems. I'm doing this using a standard drop-down menu, browsing to the new file and loading it., which automatically replaces the previous file without a glitch. It may slow down for a moment, but no spinning ball.

Hi,
Hmm...when I tried to load your patch (I'm using MAX 5 on a Windows computer) I received this error:
value expected in array, possible extra comma or missing "]": line=1188, char=44, text='..."hidden": 0 "midpoints": [321.5, 116.0,.'

It might be that creating a stripped-down version would be a good idea. Of course, this message might give you  a hint also.

might want to load all the movies at initialization time, by placing all your qt.movie stuff in one abstraction, and turning that abstraction into a poly~ object.

plenty of examples of how to do that can be found by searching "poly~ movie" or something similar.

I solved my problem. It turned out not to be an inherent speed problem...I was triggering both slab "frame" jumps with the same trigger...and (duh) getting approximatley half the speed I needed...along with some sloppy playback. I finally figured out that I could alternate the triggers before sending them to the two subroutines, and low and behold...the playback is smoothed and fast.

Life is good.
Thanks for everyone's help!

Yes! Sending two QuickTime movies into a single instance of jit.qt.movie is BAD NEWS. Sorted it out... the other really important thing is to stop sending bang messages to whichever one you're not using.

This turned out to be a bit of a puzzle-- lots of bangs going all over in this patch-- but it's lead to cleaner organization overall.

Haven't yet figured out the poly~ object, but boy: be careful if you google "poly movie" to include "cycling74".

Great! Thanks for all the help, rbedgar & robtherich.

Yes! Sending two QuickTime movies into a single instance of jit.qt.movie is BAD NEWS. Sorted it out... the other really important thing is to stop sending bang messages to whichever one you're not using. 

Haven't yet figured out the poly~ object, but boy: be careful if you google "poly movie" to include "cycling74". 

Great! Thanks for all the help, rbedgar & robtherich.


Speeding up jump for jit.qt.movie