Bug 882 : sketches that use the video library sometimes hang when used with other libraries (serial or opengl)
Last modified: 2010-06-05 03:57



Assigned To:

Attachment Type Created Size Actions
Sample code demonstrate seperate-thread Capture text/plain 2009-06-12 14:54 735 bytes

Description:   Opened: 2008-08-18 19:35
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

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

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

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

void captureEvent(Capture video1) {
Works in 0135 and in 0144, but not 0146 or 0147. Didn't try 0145.
Additional Comment #1 From fry 2008-08-27 19:37
Do any sketches that use OpenGL work on your system?
Additional Comment #2 From brmoon 2008-08-27 20:54
> 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()".
Additional Comment #3 From fry 2008-08-30 05:46
managed to get this to reproduce, so i'll be looking into it shortly.
related to bug #829.
Additional Comment #4 From brmoon 2008-09-24 17:01
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).
Additional Comment #5 From fry 2008-09-25 14:21
ah, thanks for letting me know. closing the bug now.
Additional Comment #6 From fry 2008-09-29 18:22
*** Bug 934 has been marked as a duplicate of this bug. ***
Additional Comment #7 From fry 2008-09-30 07:20
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.
Additional Comment #8 From fry 2008-10-19 04:40
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.
Additional Comment #9 From thomas-schnitzel 2008-10-25 08:02
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.
Additional Comment #10 From pat 2008-10-30 22:33
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.
Additional Comment #11 From fry 2008-11-03 07:08
interesting, that's a helpful data point, thanks.
Additional Comment #12 From vollstock 2008-11-20 00:58
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:
to the extension folder of my JRE:

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


Hope that helps. Thank you for your great work!!
Additional Comment #13 From fry 2008-11-20 07:22
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.
Additional Comment #14 From fry 2008-11-23 07:31
*** Bug 1042 has been marked as a duplicate of this bug. ***
Additional Comment #15 From fry 2008-11-24 17:20
*** Bug 1055 has been marked as a duplicate of this bug. ***
Additional Comment #16 From fry 2008-11-24 17:25
The workaround for this bug is to place this code inside setup(), and
*before* size():

try {
} catch (quicktime.QTException qte) {

In all other situations, you should never place code before the size()
method inside setup(), but desperate times call for desperate measures.
Additional Comment #17 From CongoZombie 2008-11-30 16:35
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)
Additional Comment #18 From fry 2009-01-06 04:21
*** Bug 1113 has been marked as a duplicate of this bug. ***
Additional Comment #19 From fry 2009-02-26 03:13
*** Bug 1181 has been marked as a duplicate of this bug. ***
Additional Comment #20 From rsodre 2009-05-20 18:18
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);
Additional Comment #21 From chemicalpilate 2009-06-12 14:54
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.
Additional Comment #22 From tega 2010-01-11 05:29
If you add in the following code after you call size() in setup() it also
seems to fix the problem.

Additional Comment #23 From fry 2010-06-05 02:57
*** Bug 1233 has been marked as a duplicate of this bug. ***
Additional Comment #24 From fry 2010-06-05 03:57
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.