Re: 2d animation

An easy way to do this, if you can dedicate the whole computer to just capturing the movie, is to setup a ffmpeg screencast, where you basically are capturing your screen to a movie. I've tested this, and it works pretty well. I don't know if you will be able to attain a 60 fps rate, but it's worth a try. See screencasts with ffmpeg for a step-by-step example.

UPDATE As I sat and thought about it, the screencast example uses the mkv video format, which has a very useful trait... you can just concat them together to make long videos out of short ones. So... to avoid your excessive saving of frames to disk, you could save say 10000 frames at a time, and when the counter hit 10000, you make one mkv movie segment, then discard the old frames and start another 10000. At the end, concat all the mkv's into one movie and convert it to mp4, avi, or whatever you choose.

Ideas come to me in spurts, sorry I spread my answer out over 3 posts. :-)

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Comment on Re: 2d animation

Replies are listed 'Best First'.
Re^2: 2d animation by wanna_code_perl (Friar) on Aug 15, 2011 at 23:04 UTC
Ah, yes, excellent point. I think this will work. In my early tests, the PNG frame export brought a SAS RAID 0 array to its knees, but if I partition as you suggest, I can easily save 200000 frames to a ramdisk (the render machines have 32GB). As a bonus, I pretty much get a distributed solution for free. I can chunk and distribute the (small) data file across the render farm, have each machine render 200k frames at a time and send back the small mkv, and then trivially cat the result on the master. So, it's actually a good thing you posted twice, because I can give you two richly deserved upvotes. :-)	[reply]
Re^3: 2d animation by wanna_code_perl (Friar) on Aug 20, 2011 at 09:28 UTC
Thanks again to everyone who replied. I was able to easily modify the graphing routine to output frames to a ramdisk in configurable batches. The Perlmagick-based output loop is able to output frames at about 720fps on our render machines (dual Xeons with 32GB RAM). Every 10000 frames (batch size--within reason--didn't make a significant difference), I just call a sub that runs ffmpeg, which encodes at about the same rate. Therefore typical 29.97 project encodes at about 12x realtime. Everything is still single threaded, and I haven't optimized anything yet. I will probably tinker with the old thread code and the FFmpeg library for interest's sake. But 12x is already more than good enough for our needs (1/2x would have been acceptable), so I plan to keep it simple. Even at modest bitrates, lines are sharp and artifacts are barely perceptible, if at all, to the technicians who look at these graphs/videos for a living, and do not affect the ability to interpret the data whatsoever.	[reply]


laziness, impatience, and hubris
	PerlMonks