gpvillamil

I've created a simple patch to read in a video, split it into two, and send it to two separate output contexts. (I've based it on Vade's playback optimization patches.)

The source video is 3500 x 437, encoded in Quicktime MJPEG at 75%. On a very fast computer, the patch runs at about 24fps even though the movie is encoded at 30 fps. It's a 2GB file that plays for five minutes, so I make that 7MB/s, which should not stress the hard drive (7200 RPM SATA) which I've tested at 50MB/s. Resource monitor shows disk reads averaging about 8MB/s, which seems reasonable. The CPU monitor shows a load of about 35% across both cores.

This is with a dual-core 2.8Ghz system - a quad-core 2.8Ghz system shows similar results!

So where is the bottleneck, and is there something I can do about it? At the very least, would like the 3500 x 437 file to play back at 30fps. At best, would like to play a bigger file, 6144 x 768.

I had heard that there is a problem with all QuickTime playback running in the same thread, and that there is a way around it by building a movie player using Javascript. Any info on that?

I've attached a stripped down version of my patch below:

jitter-performance-with-large-files-where-is-the-bottleneck

im going to guess the jit.siccors here is the culprit. Thats a lot of memory to be moving around very quickly. You might be better off having two different movies and uploading them individually. If you are going to have 2 windows, you can get multithreading by using two instances of Max 5 too...

im going to guess the jit.siccors here is the culprit. Thats a lot of memory to be moving around very quickly. You might be better off  having two different movies and uploading them individually. If you are going to have 2 windows, you can get multithreading by using two instances of Max 5 too...


Hey, thanks! I'm closing in on jit.scissors as the culprit.

I'm going to try jit.matrix as the splitter, or maybe try splitting in OpenGL (though I don't think a 6144 x 768 texture will be feasible).

I'm still struck by how neither the CPU nor hard drive are saturated, and yet the patch is not giving me the expected speed.

If I run two instances of Max 5 on the same system, how can I manage synchronization of the movies? Can I use the networking commands to/from localhost? Or is there a better way?

>If I run two instances of Max 5 on the same system, how can I manage synchronization of the movies? Can I use the networking commands to/from localhost? Or is >there a better way?

net.maxhole can act as send/receives between multiple instances on 1

On Sat, Dec 20, 2008 at 12:15 PM, Gian Pablo Villamil

> Hey, thanks! I'm closing in on jit.scissors as the culprit.

> I'm going to try jit.matrix as the splitter, or maybe try splitting in OpenGL (though I don't think a 6144 x 768 texture will be feasible).

> I'm still struck by how neither the CPU nor hard drive are saturated, and yet the patch is not giving me the expected speed.

> If I run two instances of Max 5 on the same system, how can I manage synchronization of the movies? Can I use the networking commands to/from localhost? Or is there a better way?

net.maxhole can act as send/receives between multiple instances on 1
or more machines (local). r

On Sat, Dec 20, 2008 at 12:15 PM, Gian Pablo Villamil
 wrote:
>
> Hey, thanks! I'm closing in on jit.scissors as the culprit.
>
> I'm going to try jit.matrix as the splitter, or maybe try splitting in OpenGL (though I don't think a 6144 x 768 texture will be feasible).
>
> I'm still struck by how neither the CPU nor hard drive are saturated, and yet the patch is not giving me the expected speed.
>
> If I run two instances of Max 5 on the same system, how can I manage synchronization of the movies? Can I use the networking commands to/from localhost? Or is there a better way?
>


Why would using jit.matrix as a splitter be remotely different than jit.scissors? The same issue comes in to play, large memory copies of huge frames every few milliseconds.

What you want to do is keep things as simple as possible.

Just split your movie before hand, and play down either two jit.qt.movies @unique 1 @colormode uyvy etc, or just have 2 copies of Max playing 1 movie each, and either way and dont fiddle with the anything till it gets to the GPU.

Max texture size on cards varies, either 2048, 4096 or 8192 for the latest cards. Honestly, doing the splitting at that rez at all is going to kill your FPS... :

Apparently jit.scissors checks the dimensions of the input matrix, but granted, that is not a heavy task.

Ended up splitting the movie when rendering, then just writing a patch that plays each half to a different output context.

One reason for managing everything as one big movie is that we wanted to apply pans/zooms/etc in realtime, but splitting the movie prevents that.

In any case, we can preview all the various moves using quarter-res (3072 x 384) files, edit them into the project, and then use the full-res patch for final playback.

Next question: how to ensure that the two halves of the movie stay in absolute lockstep? Can I just get the current frame from the left half, and force the right half to seek to it? Or should I just have a "watchdog" that checks every 10 seconds or so, and gets the movies back into sync?

Apparently jit.scissors checks the dimensions of the input matrix,  but granted, that is not a heavy task.

Next question: how to ensure that the two halves of the movie stay in absolute lockstep? Can I just get the current frame from the left half, and force the right half to seek to it? Or should I just have a "watchdog" that checks every 10 seconds or so, and gets the movies back into sync?


How about splitting the movie with jit.gl.slab @file.resample.jxs with message param srcdim?

It seemed to work for me. But maybe I am wrong..

Jitter performance with large files - where is the bottleneck?