I'm running Mavericks on an older Macbook Pro (Core2 Duo 2.4GHz) and your patch seems fine in MAX 6.1.6 running in 32 bit mode. I'm using the "old" grabber though. I wonder if that's related? Look in the "MAX 6.1.6 Released" thread for info about the new QTKit grabber and how to switch back to the old one to avoid possible image corruption: https://cycling74.com/forums/max-6-1-6-released/

Thank you for pointing me towards this info about the new QTKit -- definitely useful information to know in the future.

But I think you may have mistaken my issue -- I'm having no issue with the grabber, it's when you switch from jit.qt.grab to jit.qt.movie that the bleeding feedback artifact appears (which is part of the reason why it's so strange to me, I don't understand why there should be any major difference between the webcam output and a .mov). If you look in the patch marked hsflow_0rty@xVideoSwitch it allows you to switch from the grabber to the movie file, in this case I'm using the standard dishes.mov file but i've tried a variety of different videos of various resolutions and codecs, and they all produce the same result. If you try running the patch with a movie file, does everything run smoothly for you?

My apologies. I mis-read the post!

I get totally normal behavior with the movie or the webcam on my system (Mavericks 10.9.1, older "Santa Rosa" MacBook Pro, MAX 6.1.6 in 32-bit mode).

Hopefully somebody can reproduce the problem.

Thanks for the help! -- I've figured out a solution to the problem, hopefully somebody can help shed some light on the reason for this behavior so I can understand the underlying issue in future problems -- I still don't understand why this problem occurred for me only when moving to OSX 10.9, or why a movie vs. the grabber makes a difference.

Also I've simplified the patch to exclude all of Andrew's shaders, to show that this is a general problem with slab feedback, meaning it could potentially negatively affect a lot of Jitter users work.

So when I set the glreadback from the fbo (frame buffer object) to rtt (read to texture), everything runs as it should, the way it did before I upgraded to OSX 10.9. if I switch to fbo, then the feedback artifact appears again. but for some reason it still only happens with movie files and not with the webcam.

ZLP, in your preferences is your default GL Readback set to fbo or rtt?

I've also tested the patch in Max 5 on OSX 10.9, and without switching to rtt everything runs as it should. but, just like in max6 when I switch the readback to fbo the artifact appears. does anyone know if max5 is set to rtt by default?

Here is a patch that allows you switch between the readback settings to illustrate the problem.

I'm sorry, I made a mistake -- the problem doesn't persist without Andrew's shaders. So it does seem like problem with optical flow shaders and OS X 10.9

example here:

For what it's worth, my prefs are set to FBO and it works fine here. (My GPU is NVIDIA GeForce 8600M GT 256 MB)

Hi ZLP, Just wondering whether you ever got to the bottom of this one I've had a similar problem with the optical flow shaders, this time on a new Mac Pro. Works fine on my Macbook Pro under the same OS.

Cheers

Tom

Tom W. I'm not the original poster. I couldn't reproduce the problem on my machine. Good luck.