hi
Hmm, I am not sure about that memory bug. Quicktime spawns at least one thread of it's own, and it is possible, that we would need to be careful there somehow, but how exactly I am not sure.
The large movie thing, yes, that was the reason why I myself abandoned FM myself and went for pure java. Currently I think the movie data gets copied twice. It is possible to reduce out one of these by rendering directly to processing, but I think there would still be another copy. Still, it might help you. In theory it should work if you give a true as third argument to the constructor. But your processing stage needs to be the same size as the movie. And probably you have little chance of drawing anything else in that mode. You could also try with different renderers for processing. Try opengl for example, that might speed things up. Also different renderers might have different speeds on different platforms.
After all, qt for java is in a bad state. It doesn't seem to receive much love from apple (much like java in general). Even when I ditched processing I had to do experimentation to find a way to get it going. There are at least 3 sane ways to render the movie in java, and each works best on different platforms
.
Indeed, vlc or ffmpeg could help. I would go for the former, as it encompasses ffmpeg, and there is a java vlc on videolan.org, loking official. I might have a look at it
.
Oh, and in theory there is a jump function. Did you try it?
Pages: 