The sample program http://processing.org/learning/libraries/gettingstartedcapture.html runs
and captures the video, but my code grown from this example doesn't.

Difference is that I'm using OPENGL mode.

test code to replicate problem:
---------------------------------
import processing.opengl.*;
import processing.video.*;
Capture video1;
int vidWidth = 32;
int vidHeight = 24;

void setup() {
// in default renderer capture works
// size(200,200);
// in OPENGL the new Capture or Capture.list() stops the program without an error
size(200,200,OPENGL);

println("about to Capture.list()");
String[] devices = Capture.list();
println(devices);

println("about to create video capture");
video1 = new Capture(this, vidWidth, vidHeight, 15);
println("don't see this message in OPENGL mode");
}

void draw() {
background(0);
image(video1,0,0,width, height);
}

void captureEvent(Capture video1) {
video1.read();
}
-----------------
Works in 0135 and in 0144, but not 0146 or 0147. Didn't try 0145.

Do any sketches that use OpenGL work on your system?

> Do any sketches that use OpenGL work on your system?
Tried out the demos in 0147 Beta:
Esfera, ExtrusionGL, FullScreenApp, Geometry, LightsGL, Matrix, SpaceJunk, TexturedSphere,
Yellowtail - all work
If I modify 'Framingham' to use OPENGL by adding import processing.opengl.*; and replace
P3D with OPENGL it just gives a gray window, no errors. The default version works.

So it seems to be something with processing.video and processing.opengl.

Checked in 0148 and it is still a problem.
But is intermittent - if I keep re-running the test app I submitted it sometimes works.
(about 3 in 30 so far in 0147 (but none in the first 15 tries))
( 1 in 35 in 0148, but it is in 0148 that it seemed to be working more frequently, so I went
back and retested 0147.)

The Capture.list() isn't returning - all I see on the failed runs is "about to Capture.list()".

managed to get this to reproduce, so i'll be looking into it shortly.
related to bug #829.

Java update 2 for OS X 10.5 from Apple today fixes this problem for me in 0148 and 0147. http://support.apple.com/kb/HT2733
(it doesn't fix the slow file menu problem).

ah, thanks for letting me know. closing the bug now.

*** Bug 934 has been marked as a duplicate of this bug. ***

k, found a fix for this for 0149. still not sure what's going on, so it may
just be a hack, but at least it's working again.

Have to re-introduce the bug for 0152 because the fix has broken lots of
other code. Will have to just track down why QTJava is behaving like this.

For anyone interested in the technical side of the problem,
QTSession.open() causes a hang when run from our animation thread. It seems
to only want to run from an application's main() method or even the EDT. I
can't find anything in the QTJava documentation that explains this.

Just stumbled onto this bug too and wondering which is the latest version of processing which
works with the video capture and openGL on OSX. I went down to 0135 which works, but don't
know where to find the other past releases to test.

While I was playing around trying to capture while in OPENGL mode, I found
out that if you call Capture.list() before calling size(x,y,OPENGL), the
sketch works.

Currently using 148.

interesting, that's a helpful data point, thanks.

I don't really now if that belongs here but maybe you'll find it helpful.

My patch worked perfectly on my computer (Mac) but hung on any other Mac that i have tried.
It always froze on this line:

capture = new Capture(parent, captureWidth, captureHeight, FPS);

A friend with a PC (Vista) could run the patch.

Then I found out that the difference between my Mac and all the others was, that I copied all
the OPENGL libraries delivered with processing in this folder:
Processing/Contents/Resouces/Java/libraries/opengl/library/
to the extension folder of my JRE:
/Liibrary/Java/Extensions/

I did this some weeks ago while playing around with an OPENGL patch in Eclipse.

After copying all the libraries to the system folder on another mac as well, it suddenly was
working.

:-)

Hope that helps. Thank you for your great work!!

That's odd, though it probably has to do with the order in which libraries
are loaded causing a problem. Keep in mind that this will break Processing
whenever we update JOGL to a newer version, so keep an eye on revisions.txt
otherwise you'll run into some nasty headaches.

*** Bug 1042 has been marked as a duplicate of this bug. ***

*** Bug 1055 has been marked as a duplicate of this bug. ***

The workaround for this bug is to place this code inside setup(), and
*before* size():

try {
quicktime.QTSession.open();
} catch (quicktime.QTException qte) {
qte.printStackTrace();
}

In all other situations, you should never place code before the size()
method inside setup(), but desperate times call for desperate measures.

Thanks, I was having the same problem, but the code that you posted (fry)
seems to stop it. I should add that without the "fix", the OpenGL +
processing.video sketches seem to work fine in Present mode, just not
regular windowed run mode. (I'm using OS X 10.5.5)

*** Bug 1113 has been marked as a duplicate of this bug. ***

*** Bug 1181 has been marked as a duplicate of this bug. ***

Hey, Comment #16 saved my life! Or at least the last 2 days of my life...
With me, the patch does not work with simple movie playback. Looks like an
OpenGL+QT issue.

It is easy to reproduce this error by adding the following to the QT
Pixelate example:

import processing.opengl.*;
...
size(640, 480, OPENGL);

edit]
Sample code demonstrate seperate-thread Capture

One way to get around this problem is to do all your Capture use in a child
thread and render the captured data to a global PGraphics object that you can
then use in the OpenGL thread without any trouble. My ugly (but working) hack
at this is pasted below.

If you add in the following code after you call size() in setup() it also
seems to fix the problem.

hint(ENABLE_OPENGL_4X_SMOOTH);

*** Bug 1233 has been marked as a duplicate of this bug. ***

closing this bug, because we'll be replacing the current video library with
another sometime later this summer. as such, i won't be doing any more bug
fixes on the current video library. in the meantime, we recommend using
gsvideo, opencv, or one of the other video libraries that are available.