Jitter performance with large files – where is the bottleneck?
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’ve attached a stripped down version of my patch below:
----------begin_max5_patcher---------- 930.3ocyX1saiiBFF93To4d.ki6XYffc7bT2qiUipH1DWprgTCtMcGs26C+X GkNSZhahINppg.FG+xi+9C902ta17UxsL0bvO.+KX1reYFYlaL6Hy5GX17Z5 17JpxMw4Oy0Qq2nJa4yuu65h1ZtnhocS.1O5ZoPKn0L2c8OMbZ092frU2eGn 9g4Et4JW872gY6lrel522v7Bc976M+C949OGE++bWMKJte3MTc9SbQ4iMrbs +NgPn45.zRjsII19I17cvOc2y++s6rsll6GLMDr2LxcmV0rs5cTprJpgIJXM fFd4S5PhKT7miqUTQ4EiLxRaSJw9ILMjHSUQW4AF3g07JFHOOp88WeG0TthF Uw0rnm2p.OPa0xZplmChAOTvqU4TyjQQ.XzgIMZbLLS9bRaVAOVV8ncE01vN alSHXmkYrqAkkFdn+JufI2TQErdz+A7panB0ZYSsQkJlFfBpqe5wIrQUM7sm OcwNSYLdgitXbfo6abQg7svGB.tLPg.HdDgSc.KMNv7RkyUJYiwCOWV0VKTi m0F9PXiLTqsAY6AQGkk3kdqtE9.o3DWu3fGOshs91LbJN3QSQc96wdxmgFA6 2qSMPKBPIPHhuBHRvq.RCVY+Kj9tjSGw6CsmEvfcFLNVkBup4h8tsSWp3jfl IFEm4yD6iBhtB04zUOtkqgjaoAJUbm2aBL3Yh8durFphERO3kC2C1qkymZPr y9xuQlKjZZYYY0o.yGW8vCr5Oxdb4B8dq0OcQ0kMiz+Y.rDdoloajf812yEV FvgHA7T6e8Bdu6ixPRuN04G5PKPXnhs3KPBm5hFmrXDvUMSonkr+lWMLZQPM mPGozoyAN3kctXc0RFP+MqszK5nZ4qblI2eAciF.AOzJ3uzxreyrsHS5eYAC XqiOn1Z3fl+ueyPP+4bf+7Hy9e84UbwecZkteW6E9CVqjsM48hsKXqo9ocxr fozbgopJoXuIYiCs+rdhWTvbSX2BolWrQZBO2IjiYALXs8mO1CKtkSh1rOU3 ojF4qJMhO9BIyW5GLhz0ab3IZPurweUUiyV3DZl+DQLM88FEYaoHZ7U8nnsz gPzESlE5IkV5jIMzsozHCwuFOYR6juPSlDoguckFbPZCRlFwMn2oSi4FLYPf 6F1ME9ks3PoH+QO6a554KHijfr40b8td9yec9hv9SiKaou9Qn+zLc8HKRsqA Wuwy.N.uHtdoYPw2tYmmHsgFTc2vrKVb1ALM+FvEIvHV -----------end_max5_patcher-----------
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…
I hate the web forum software… ugh.
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
or more machines (local). r
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?
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.
Result: 6144 x 768 @ 30+ fps.
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?
How about splitting the movie with jit.gl.slab @file.resample.jxs with message param srcdim?
Is that a ‘killer’ as well?
It seemed to work for me. But maybe I am wrong..