Just a quick post about this processing based project’s progress.
I have managed to get the video transport behaving itself quite well now. It supports normal playing, frame-by-frame in both directions, variable speed in both directions, and has the ability to pause or reset to the start point.
The direction issue has been partly solved. If a movie is set to play backwards, then the controls are reversed, and it sets the start point to the last frame of the movie. The main issue still to fix is the looping behaviour – it loops OK when going from the last frame through to the first, but not back the other way. This isn’t a major problem for use generally so it’s not a high priority to fix at the moment.
Accumulating variable width slices seems to work most of the time (errors pop up from time to time, so there’s still a few things to iron out). I have decided to accumulate the slices into a single PImage file which is then saved out at the end to a png format image. The image size is worked out by summing all the variable slice widths together before putting any slices into it. The image size can exceed the sketch size – I don’t know if there is some sort of implementation dependent limit to this, but I guess it may be worth looking into just in case I try to do something really huge.
The final major problem I have is the quicktime movie format. I tried h264 and it was found lacking. Some other formats just seem to produce huge files. I have had a shot at using mpeg4, but it seems to crash the applet sometimes, and is kinda slow anyway. So the search continues for a better codec to use that has good performance, reasonable file sizes, and cooperates with the quicktime java api. If I can’t find something suitable, then I’ll have to support entering the Delta X values with a low res version of the source movie, and then scale them up to grab the slices from the full resolution version. Not too hard, just more code and a different workflow.
May 23, 2007 at 5:58 pm
Have just had a quick look for some codec advice on the interweb and it looks like Sorenson 3 and Motion JPEG may be worth checking out. File size may in fact not be such an issue in terms of performance, just in terms of shifting files around between one place and another.
May 28, 2007 at 6:28 am
Well things didn’t turn out so great. Sorenson 3 and Motion JPEG both gave me some odd behaviour in the video transport for using the frame-by-frame feature. Seemed really bizarre at first, and there I was thinking it was another problem with the codecs. It may still in fact be a codec problem, but it could also be just some oddity of the movie export from iMovie.
Anyway I have figured out what is going on: the movie is checked to see how many frames are present in the entire movie. For the clip I just tested it reports 910 frames, but I found the movie actually has 219 frames. The number of frames is used to calculate a step value for doing the frame-by-frame thing, and with the incorrect and larger frame count the step value was much smaller than it should be.
When a step value is added to the current position in the movie it is truncated by conversion to an integer, which means that the step was always being pushed closer to 0 which wouldn’t allow the position to reach the next frame. That’s the gist of it, but it did behave a little more strangely than that for some reason I haven’t worked out (and don’t really need to work out I feel).
So now I need to determine where the incorrect frame count is coming from – the export process or the codecs. My bet is on the export process because I got the exact same behaviour with both codecs. Off to the video lab again I guess…