I've been adding AVI capture to the RMQ engine. This is something I've resisted for a long time as it's quite OS-dependent and there are some things about implementations of it which I've studied that I'm not happy about, in particular the fact that it tends to stick it's tentacles into lots of other places in the engine too.
However it is a useful feature for demoing new RMQ stuff in the RMQ engine itself, so it's a valid thing to have.
The eventual compromise we found was to just dump a stream of images (and a wave file) into a subdirectory, which you can then process into a video yourself. It's not ideal, but going further would require messing around with codecs, which brings us right back into OS-dependent land. This way we get to stay nice and platform-neutral.
So I'm really rolling my own in other words, and - I must say - it's quite a bit of fun. There are various problems to be resolved with this, and discovering them (as well as discovering solutions to them) is perking up my interest in other areas. It's been a while since I've written any code to deal with WAV files, for example.
One of the biggest problems, that's going to remain a problem, is that disk I/O is a serious bottleneck here. This has bearings on how fast you can run your capture, what resolution you run it at, what formats you use, etc. I'm currently leaning towards running at 20-25 FPS and defaulting to 320x240 resolution, which seems to give a good enough balance. The image format of choice is TGA; this does make disk I/O slightly more of a problem, but the tradeoff is that it's very light on the CPU - switching to a compressed format would most likely just swap one bottleneck for another.
Another problem was synchronising audio with video correctly, but that was easily resolved by adding another maxfps upper bound if we're currently capturing and just letting the image capture happen every frame instead of on a timer.
So all in all it's done and working nicely; no sample videos for you (they're not going to be any different to those you'll find anywhere on YouTube) but a nice clean and simple piece of work. There are a few things to tidy up with it, but overall I'm happy.
By the way, I don't see this as being a feature for DirectQ, and my recommendation there is to use FRAPS if you want to capture video. This option was floated for RMQ, but the fact that FRAPS is Windows-only ruled it out. With DirectQ being a Direct3D engine (and therefore Windows-only too) it's a non-issue.
Tuesday, February 1, 2011
AVI Capture (...Of Sorts...)
Posted by
mhquake
at
5:44 PM
Subscribe to:
Post Comments (Atom)
2 comments:
I see two main ways to use avi capture in quake; one is to record live interactions with menus or even short gameplay demonstrations. The other is to convert existing longer-form demos into a movie format.
For the latter, it seems like the ideal way to do this would be to link it in with the demo playback code, so you can guarantee the framerate (i.e. the playback would slow down if capture is slower than realtime, maybe even speed up past realtime if your cpu/drive is fast enough.) Not sure how this would work with sound mixing though; that's something i've never had to deal with.
If cpu is fast and disk is slow, you could try a format with fast and cheap compression to balance it better. Not sure how fast jpeg is, for example.
> record live interactions with menus
I never actually thought of that. It's a great idea for tutorials for newbies. "This is how you connect to a server", etc.
Nice one, have a beer on me! :)
Post a Comment