Not sure what is GSVideo, but the -pre5 suffix of the library file suggests it is still a beta version. You should submit a bug report to GSVideo team instead.

Maybe more details could help. Does the error occur when you run movie playback, camera capture, etc.? If you have a minimal sketch that reproduces the error, then post it and I will take a look at it.

Also, note that I have been releasing some "test" versions of gsvideo which solved some issues in pre5. Download the latest one from here.

In any case, if the problem persists, please enter a bug report in the tracker.

Here's the code which crashes with gsvideo-0.6-pre5.

It's got briefed from detecting differences code between frames, so it contains some unneeded codes, but I tried to make it intentionally crash....

So the following code works fine with gsvideo-0.4.5-win, but causes crash with gsvideo-0.6-pre5.

It doesn't always crash, but crashes about once in 5 tries or something like that.

One thing is gsvideo-0.4.5-win gives the following warning in red letters, but it seems work fine.
(java.exe:3812): GLib-GObject-CRITICAL **: file ..\..\gobject\gobject.c: line 1642: assertion `G_IS_OBJECT (object)' failed(java.exe:3812): GLib-GObject-CRITICAL **: file ..\..\gobject\gobject.c: line 1742: assertion `G_IS_OBJECT (object)' failed

My memory setting for Processing 1.1 is 1512 MB.

import codeanticode.gsvideo.*;
import processing.opengl.*;

GSCapture cam;
PImage oldCam,tDiffImg,diffImg;

int vWidth=320;
int vHeight=240;
int vPixels=vWidth*vHeight;
int lastCapture=0;
int captureInterval=100;

void setup() {
  size(vWidth,vHeight,OPENGL);

  cam=new GSCapture(this,vWidth,vHeight,GSCapture.list()[0]);
  oldCam=createImage(vWidth,vHeight,ARGB);
  tDiffImg=createImage(vWidth,vHeight,ARGB);
  diffImg=createImage(vWidth,vHeight,ARGB);
  cam.loadPixels();
  oldCam.loadPixels();
  tDiffImg.loadPixels();
  diffImg.loadPixels();

  fill(255);
  smooth();
  noCursor();
  frameRate(1000);
  int temp=millis();
  while (millis()<temp+2000) {
    captureVideo();
  }
}

void draw() {
  captureVideo();
  background(0);
  set(0,0,diffImg);
}

void captureVideo() {
  int diff,diffCount;

  if (millis()>lastCapture+captureInterval) {
    if (cam.available()) {
      arrayCopy(cam.pixels,oldCam.pixels);
      cam.read();
      lastCapture=millis();

      for (int i=0;i<vPixels;i++) {
        tDiffImg.pixels[i]=color(0);
        if (brightness(cam.pixels[i])>200) {
          tDiffImg.pixels[i]=color(255);
        }
      }
      tDiffImg.updatePixels();  

      arrayCopy(tDiffImg.pixels,diffImg.pixels);
      diffImg.updatePixels();  
    }
  }
}

Oh, and I will post about this at GSVideo tracker page from now on.

Thanks.

I just tried out your code on Linux, and works fine. So it is probably a mac-specific issue. I'll test on a mac machine soon.

I didn't see an open ticket on the bug tracker, so I'll just post this here. It should get better visibility for other having this problem as well.

This is not a Mac-specific problem. I have experienced it while testing on two machines running XP, one running Win7x64, and one running OS X. The problem seems to be related to "dropped frames" of GSCapture. By this I mean, if many frames have filled the buffer before the next GSCapture.read() is called, it results in a crash. The error message is always the same, but I'll attach it to the end of the post anyway.

Here is some sample code to demonstrate the problem. It can, and will happen on the example sketches provided with the library, but I have modified one of the examples to speed things up a little. This is simply the brightness tracking example, except instead of calling GSCapture.read() every frame, it is called every 10 frames instead.

1. /**
2.  * Brightness Tracking
3.  * by Golan Levin.
4.  *
5.  * GSVideo version by Andres Colubri. 
6.  *
7.  * Tracks the brightest pixel in a live video signal.
8.  */
9. import codeanticode.gsvideo.*;
10. GSCapture video;
11. void setup() {
12.   size(640, 480); // Change size to 320 x 240 if too slow at 640 x 480
13.   // Uses the default video input, see the reference if this causes an error
14.   video = new GSCapture(this, width, height, 30);
15.   noStroke();
16.   smooth();
17. }
18. void draw() {
19.   if (video.available() && ((frameCount % 10) == 0)){
20.     video.read();
21.     image(video, 0, 0, width, height); // Draw the webcam video onto the screen
22.     int brightestX = 0; // X-coordinate of the brightest video pixel
23.     int brightestY = 0; // Y-coordinate of the brightest video pixel
24.     float brightestValue = 0; // Brightness of the brightest video pixel
25.     // Search for the brightest pixel: For each row of pixels in the video image and
26.     // for each pixel in the yth row, compute each pixel's index in the video
27.     video.loadPixels();
28.     int index = 0;
29.     for (int y = 0; y < video.height; y++) {
30.       for (int x = 0; x < video.width; x++) {
31.         // Get the color stored in the pixel
32.         int pixelValue = video.pixels[index];
33.         // Determine the brightness of the pixel
34.         float pixelBrightness = brightness(pixelValue);
35.         // If that value is brighter than any previous, then store the
36.         // brightness of that pixel, as well as its (x,y) location
37.         if (pixelBrightness > brightestValue) {
38.           brightestValue = pixelBrightness;
39.           brightestY = y;
40.           brightestX = x;
41.         }
42.         index++;
43.       }
44.     }
45.     // Draw a large, yellow circle at the brightest pixel
46.     fill(255, 204, 0, 128);
47.     ellipse(brightestX, brightestY, 200, 200);
48.   }
49. }

This will crash within a few seconds on any system I have tried. Here is the error message for posterity:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c342eee, pid=4168, tid=2288
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode windows-x86 )
# Problematic frame:
# C  [msvcr71.dll+0x2eee]
#
# An error report file with more information is saved as:
# C:\SOME_PATH\hs_err_pid4168.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

I appreciate all your hard work on GSVideo, and I will provide any useful information possible to get this bug solved quickly. Thanks!

Thanks for posting the code. I added a ticket in the sourceforge tracker about this issue.

I'll just tried on Mac, and was working fine at least for some minutes without crashing.

I'll test in more detail soon, now I'm pretty busy with preparing new a release of GSVideo with OSX support and OpenGL stuff.

Hi Guys,
anything new about this?
I'm facing the same problem. It is Win7 x64, JRE 6.0_20-b02, GSVideo 0.7. <-- notice version
I tested with the GettingStartedCaptureWin Example - provided with the library, i only modified the resolutions. It seems that the error occurs when the camera-own driver tries to auto-whitebalance and do some lighting corrections. There is a sec when the picture freezes. After this the picture returns - with the correct lighting and whitebalance, or the error occurs.
It also seems to make a difference whether you close the sketch by stopping it via the processing "stop"-button, or killing it by just closing the window where the camera-image is shown.

Sounds to me that this is most likely a problem with the underlying gstreamer plugin that handles camera capture.

Since you are running windows7 on Mac hardware, you have some alternatives to setup video capture. The GSCapture class uses by default a source plugin called dshowvideosrc, but you can use ksvideosrc instead. I don't know if this solves the problem, but it is worth a try.

You can use ksvidesrc by setting a capture pipeline directly:

pipe = new GSPipeline(this, "ksvideosrc device-index=0 ! decodebin2 ! ffmpegcolorspace ! video/x-raw-rgb, bpp=32, depth=24");

or by telling GSCapture to explicitly use ksvideosrc:

pipe = new GSPipeline(this, "ksvideosrc", cameras[0]);

Just to be clear, there are 3 different people reporting this problem so far. Only one was using Win7 on Mac hardware. For instance, I was using it on two various PCs and also XP on PC hardware. Not that "PC hardware" and "Mac hardware" are any different these days...

Ok, I aggregated these reports in this entry in the bug tracker of GSVideo. I'll update as I find possible solutions, workarounds, etc.

For postofficebuddy and waterbass: I reproduced the crash with Processing 1.1, GSVideo 0.7, Windows Vista 32bits (I don't have a Win7 machine at this time to test). The reason for the error is that you are not calling the GSCapture.read() method at every frame. I understand that reading the video pixels at a certain interval greater than one might result in some performance improvement (but not much though, since gstreamer will keep pushing frames continuously regardless if read() is called or not). I'll try to implement the use of read() in this non-continuous fashion so there is no crash, but it won't be immediate (more like for a 0.8 release of the lib). For the time being I recommend separating the pixel processing (which can be done at the desired interval) from the pixel reading (which needs to be done every time a new video frame is available).

For Eyecandy: I suspect some low level issue with the interaction between the camera driver, direct show and gstreamer, and not something I can solve from gsvideo. Maybe this error goes away if you can disable the white autobalance of the camera?

I've just tested on Windows 7 x64, but with a working processing 1.2.1 x86 (built-in java) and gsvideo test version 20110203 that this problem still reliably occurs. In my case, after anything from a few seconds to a minute of successful video capturing, I get the feared problematic frame msvcr71.dll+0x2eee problem and the processing applet dies an ungraceful death:

Andres, I hope that you see this post at some stage:

Ok everyone, I've fixed the bug. It turned out to be a multi-threading problem, OPENGL vs P3D just made it happen faster as OPENGL is slower blitting webcam images to the screen.

this is great, thanks!