I'm not sure if memory is the issue here... Try running something that monitors memory use^[1]  while running the sketch, and see if it requires loads of RAM or not, if it keeps growing, etc. How much RAM does your system have anyway?

Are you running "plain" code (a slightly modified copy/pasted example) or are you doing anything else with the video? Are you using GSVideo/GLGraphics integration or not?

... which allows for more memory to be assigned to Processing. But realise that a lot of libraries won't work in 64 bits, so if you use any other libraries this could be a problem! There is a 64 bits version of GSVideo, though.

[1] I don't know which system you are using, but on Windows I suggest Process Explorer - Microsoft's own Taskmanager on steroids.

thanks for the reply, I think you may be right about the ram usage, it seems to be hovering around 300-400MB so I should have some overhead there. I am using quite a few other libs, so 64 bit is unlikely to work in this situation, but worth looking into. I am using the glgraphics integration. 

I did a basic video example to experiment with some other methods in the gs video class. I found that I could replicate the error fairly consistently when I left out the read(); method on the GSMovie object. This made me think that maybe it was trying to put the pixels into texture that were not in the reading buffer. (maybe ??) I came across the ready() method, that was used before the .9 update to test if there were pixels to be read. When I added the read inside a conditional on the ready method, it seems to eliminate all errors I was getting before. That is until windows reverted back to it's non-transparent theme. Now I am thinking that it may be an issue with opengl in general, or my video has some bad frames in it.

 I also found that it is not necessary to have the putPixelsIntoTexture method in an if(), but just by testing if the video is ready, reading that and putting the pixels into the texture, it should work equally as well. 

here's my test code if anyone wants to try:

thanks for looking!

ak

Googling ffvideoscale gives me this:

"This element resizes video frames. By default the element will try to negotiate to the same size on the source and sinkpad so that no scaling is needed. It is therefore safe to insert this element in a pipeline to get more robust behaviour without any cost if no scaling is needed."

Are you scaling the video? If not, maybe the playback becomes more robust if you use GSPipeline instead? Yes, I know that that's the opposite of what the last sentence states. However, if it's the reget_buffer() function that fails (and it appears that's the case, for whatever reason), removing the use of it might solve the problem cure the symptom. This text suggests that using GSPipeline avoids the use of videoscale.

Note: I don't really know what I'm doing, you have been warned! :P