GSVideo 0.9 released   24 comments

GSVideo 0.9 is a significant release of this library because it introduces a new methodology to feed video frames directly into GLTexture objects from the GLGraphics library, which often results in a reduction of CPU usage of around 50%. The latest version of GLGraphics, 0.99, is required for this optimization to work.

This new mechanism in GSVideo basically consists in setting a GLTexture object as the “pixel destination” for a GSVideo class. All the media-handling classes in GSVideo – GSMovie, GSPlayer, GSCapture and GSPipeline –  incorporate this mechanism. The usage is quite simple, the setPixelDest(tex) method is called right after creating the GSVideo object, with tex being the GLTexture object to use as destination. Then, in the draw() method, tex.putPixelsIntoTexture() should be called in order to update the OpenGL texture with a new video frame, if available:

void setup() {
  ...
  movie = new GSMovie(this, "movie.avi");
  tex = new GLTexture(this);
  movie.setPixelDest(tex);
  movie.loop();
}

void draw() {
  if (tex.putPixelsIntoTexture()) {
    image(tex, 0, 0, width, height);
  }
}

The new examples illustrating the use of this GSVideo-GLGraphics interoperability mode are grouped in the GLGraphics category. The image below shows the CPU usage when first running the original Movie/Loop example (the first plateau at around %50), followed by running the equivalent GLGraphics/Movie example  (the second plateau at around %25), which uses the GSVideo-GLGraphics interop. mode. The initial bump in both cases is due to the reading the video file from disk.

GLGraphics-GSVideo

This performance improvement is consistent across different platforms (Linux, Windows, OSX) and applies to movie playback, camera capture, and arbitrary video pipelines. It should be noted that when enabling this method, the GSVideo object cannot be used to do any drawing, since it doesn’t contain valid image data as the video frames are transfered over to GLGraphics even before updating the pixels array.

GSVideo 0.9 includes a few additional minor improvements, which are detailed in the release notes.

Advertisements

24 responses to “GSVideo 0.9 released

Subscribe to comments with RSS.

  1. Hi,
    first of all, thanks for your great library!
    I just installed your new version and it doesn’t work anymore.
    This is the error I’m getting when trying to run the GettingStartedCapture example:

    #
    ** (java.exe:3884): CRITICAL **: file ..\..\gobject\gtype.c: line 2315: assertion `g_type_parent (interface_type) == G_TYPE_INTERFACE’ failed
    # A fatal error has been detected by the Java Runtime Environment:
    #
    # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x774143f9, pid=3884, tid=7720
    #
    # JRE version: 6.0_24-b07
    # Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode windows-x86 )
    # Problematic frame:
    # C [msvcrt.dll+0x143f9]
    #
    # An error report file with more information is saved as:
    # C:\Users\Powder\AppData\Local\Temp\\hs_err_pid3884.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.
    #

    Any help?

    Greetings, Tim

  2. Hi,

    I have a problem running the GettingStartedCapture example on Win7 32bit:

    #
    ** (java.exe:3884): CRITICAL **: file ..\..\gobject\gtype.c: line 2315: assertion `g_type_parent (interface_type) == G_TYPE_INTERFACE’ failed
    # A fatal error has been detected by the Java Runtime Environment:
    #
    # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x774143f9, pid=3884, tid=7720
    #
    # JRE version: 6.0_24-b07
    # Java VM: Java HotSpot(TM) Client VM (19.1-b02 mixed mode windows-x86 )
    # Problematic frame:
    # C [msvcrt.dll+0x143f9]
    #
    # An error report file with more information is saved as:
    # C:\Users\Powder\AppData\Local\Temp\\hs_err_pid3884.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.
    #

    Any help?

    Greetings, Tim

    • The only 32 bits versions of windows I have available for testing right now are Vista and XP. In both cases, I didn’t observe this crash.

      My impression, after reading reports of similar glib crash on other applications (like this one for gimp: http://www.gimpusers.com/forums/gimp-developer/5334-gimp-2-3-1-crash), is that is due to a library incompatibility. Do you have any other copy of the glib libraries (libglib-2.0-0.dll, libgmodule-2.0-0.dll, libgio-2.0-0.dll, etc) installed in your system? Are you using by any chance the gstreamer-winbuilds from the ossbuild project?

  3. i got this error on my ubuntu :
    Exception in thread “Animation Thread” java.lang.ClassCastException: processing.core.PGraphicsJava2D cannot be cast to processing.opengl.PGraphicsOpenGL
    at codeanticode.glgraphics.GLTexture.(Unknown Source)

  4. i make it on java

    import codeanticode.glgraphics.GLConstants;
    import codeanticode.gsvideo.GSCapture;
    import processing.core.PApplet;

    public class Presence extends PApplet{
    int numPixels;
    int[] backgroundPixels;
    GSCapture video;

    public void setup() {
    size(320, 240, GLConstants.GLGRAPHICS);
    video = new GSCapture(this, width, height);
    }
    public void draw() {
    if (video.available()) {
    video.read();
    video.loadPixels();
    video.updatePixels();
    image(video,0,0);
    }
    }
    public static void main(String[] args) {
    PApplet.main(new String[] {“Presence” });
    }
    }

    and here below the error message
    GSVideo version: 0.9
    Exception in thread “Animation Thread” java.lang.ClassCastException: processing.core.PGraphicsJava2D cannot be cast to processing.opengl.PGraphicsOpenGL
    at codeanticode.glgraphics.GLTexture.(Unknown Source)
    at liatpilem.setup(liatpilem.java:13)
    at processing.core.PApplet.handleDraw(Unknown Source)
    at processing.core.PApplet.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:662)

  5. stable release version 0195

    • Better use 1.5.1 (is the latest stable).

      • hmm still problem, as you said, it’s not about GSVideo, I think it’s about my VGA card, by the way thanks a lot for this. rgds

      • Yes, could be problem with the OpenGL drivers… I haven’t seen this crash before.

        You can still use GSVideo without GLGraphics, selecting the P2D or P3D renderers in size(). These renderers doesn’t require OpenGL.

        Of course, in this way you cannot use the GSVideo-GLGraphics integration mode, which gives you more performance.

  6. Hello,
    I came across your library from a post on blprnt.com (http://blog.blprnt.com/blog/blprnt/processing-tip-rendering-large-amounts-of-text-fast). That looks very promising.

    I’m trying to use the library for processing sketches that are loaded via the java based KetchupAddict application I’m developing (http://ketchupaddict.com), so the sketches are loaded from the application.

    I’m unfortunately getting a similar java error to Tim’s error above.
    As soon as I close the sketch, the entire application closes (this doesn’t happen with other skethes) and the following java error report is saved:
    http://pastebin.com/Rcs1xnCz

    This doesn’t happen when using the Processing IDE though.

    Any idea where this could be coming from ?
    Do I need to do any thing special before disposing the PApplet ?

    Thank you for your library and any help you may provide.

    • Hello Oussama,

      One problem when you run the sketch from the KetchupAddict application could be that the OpenGL resource release mechanism in GLGraphics gets called when the PApplet thread of the sketch is no longer current. Because the OpenGL resources are created in the PApplet thread, trying to access them from another thread would generate errors, as OpenGL is not thread safe.

      Not 100% sure, but it is a possibility. One workaround could be to explicitly call the GLState.deleteAllGLResources() method while you are still inside the sketch. In this way, all the OpenGL resources are properly disposed while the sketch’s thread is still current. Let me know if it works.

      BTW, the KetchupAddict projects looks fantastic!

      Andres

      • Hi Andres,

        Thank you for your answer.

        I’ve tried to do a call to GLState.deleteAllGLResources() before disposing the sketch, but the error persists.

        I’ve also tried removing everything in the sketch’s draw method, leaving only the bare minimum (sketch code available at http://pastebin.com/MFzhmrku), but the error still occurs and the entire app exits.

        This seems to only happen when using GLConstants.GLGRAPHICS in the size call; this doesn’t happen when using OPENGL.

        Note: I’ve tried this on both Windows and Ubuntu with similar results.

        Best,

        Oussama

      • Does the minimal sketch crash with the same error you pasted originally?

      • Yes, here’s the new report: http://pastebin.com/8ujePXZ1

      • Hi Oussama, I think the only way for me to find the problem is to run the sketches inside your framework, otherwise I can only guess. Let me know if is there any way to do that. You can contact me directly at andres AT interfaze.info

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: