gavspav

Anyone know of avoiding the behaviour exhibited in the patch below.

Importing a movie into a matrixset or even clearing it causes jitter output to stutter.

The effect is far more noticeable than reading a new movie into the qt.movie object.

I've been using this in M4L and it causes audio dropout - see this thread:

https://cycling74.com/forums/any-way-to-clear-jit-matrixset-without-audio-glitching

But even in Max Jitter output is affected.

There is no asyncread/preload that I know of with jit.matrixset.

Anyone got any suggested workarounds? I am thinking either :

load the quicktime movie and feed it into the matrix frame by frame (this seems a bit clumsy)

use the mxj matrixlist somehow to achieve this in a low priority thread (no java experience but willing to have a crack!)

Anyone know of avoiding the behaviour exhibited in the patch below.
Importing a movie into a matrixset or even clearing it causes jitter output to stutter.
The effect is far more noticeable than reading a new movie into the qt.movie object.

I've been using this in M4L and it causes audio dropout - see this thread:
https://cycling74.com/forums/any-way-to-clear-jit-matrixset-without-audio-glitching

But even in Max Jitter output is affected.
There is no asyncread/preload that I know of with jit.matrixset.

jitter-output-stuttering-when-clearingimporting-into-jit-matrixset

I found the same problem and tried the solution of loading the quicktime movies (very short < 200 frames)via 'read' or 'asyncread' and then 'framedump' do load it into the matrixset. Max Jitter stutters TWO TIMES! Once during opening the file then again when framedump starts. Unusable! Didn't try with audio. Now I'm using quicktime movie to directly feed the rest of my chain... however not a real solution.

Low priority thread would be fine... but how?

I found the same problem and tried the solution of loading the quicktime movies (very short < 200 frames)via 'read' or 'asyncread' and then 'framedump' do load it into the matrixset. Max Jitter stutters TWO TIMES! Once during opening the file then again when framedump starts. Unusable! Didn't try with audio. Now I'm using quicktime movie to  directly feed the rest of my chain... however not a real solution.

Low priority thread would be fine... but how?


I contacted support and they acknowledged the problem, lodged a feature request (for low priority importing) and sent me a patch similar to your solution (below).

It's not perfect but its better than what I had before.

re the low priority thread thing. I found this thread with a quicktime player in an mxj object.

I thought maybe I could do the same for jit.matrixset adapting the mxj matrixlist example.

I had a bit of a go at it, got confused and then sidetracked!

I contacted support and they acknowledged the problem, lodged a feature request (for low priority importing) and sent me a patch similar to your solution (below).
It's not perfect but its better than what I had before.

re the low priority thread thing. I found this thread with a quicktime player in an mxj object.
I thought maybe I could do the same for jit.matrixset adapting the mxj matrixlist example.
I had a bit of a go at it, got confused and then sidetracked!
Sure it could work though.


Yes, this patch runs rather smoothly. But it has nearly nothing to do with a real world situation. My patch, a video installation, is rather saturating CPU (windows 7, i7 cpu) though most of the video stuff is done in OpenGL. Many Quicktime operations introduce noticable stutter. Also during record. I'm recording in background from a matrixset frame by frame at a very low speed (had to slow down to 2 frames x second!).

So real background threads would be THE solution!

Today I posted a first test session to Vimeo:

Today I posted a first test session to Vimeo:
http://vimeo.com/36076000

Well it did improve things in my (also demanding) real world situation but it isn't ideal for a few reasons.

I never linked to thread with the java movie player:

https://cycling74.com/forums/multi-output-poly-for-movies

Have you tried optimizing the video, codecs, image format etc. Using a ram disk perhaps?

I never linked to thread with the java movie player:
https://cycling74.com/forums/multi-output-poly-for-movies

YES!!! Just in this moment I got a first result. Never tried Java under Max before... a steep learning curve... however I got it running with my patch for a few tries... and a lot of MAX crashes!!! it doesn't work anymore now... Surprisingly nothing changes, stuttering still orcurred as before! Who knows in which way the threads are assigned, or if the MAX event is delayed and so its scheduler???

Maybe I'll go a bit deeper in it but now it's time for dinner!

YES!!! Just in this moment I got a first result. Never tried Java under Max before... a steep learning curve... however I got it running with my patch for a few tries... and a lot of MAX crashes!!!  it doesn't work anymore now...  Surprisingly nothing changes, stuttering still orcurred as before! Who knows in which way the threads are assigned, or if the MAX event is delayed and so its scheduler???

Maybe I'll go a bit deeper in it but now it's time for dinner!


I also tried playing my video clips from another top level patch. Same result! Now, as many other movies show much much less stutter than mine, I changed codec to the super simple 'jpeg'.

Bingo! The encoding with qt.record isn't heavy anymore and the stutter in play is lot shorter (nearly invisible). I suspect with the old format the decoder had to go thru the whole file to collect all the information needed. Seems he does this synchronous! So it takes a while.

For my current app this is the final move.

Jitter output stuttering when clearing/importing into jit.matrixset