OK, so saga of my ongoing quest for video capture under Linux: back when I first started trying to get it working, I found xvidcap, but it wouldn't capture the VO window, it would just capture a black window. According to the xvidcap website that was because xvidcap is unable to capture hardware accelerated stuff, including OpenGL. But recently Moofed mentioned that xvidcap did capture OpenGL for him, so I decided to give it another try. Now xvidcap does capture for me, but with a couple caveats: if the X server is running at 24 or 32 bit color depth, using xvidcap will not be able to capture to some formats, including on-the-fly mpeg encoding. So I switched to running my X server at 16 bit color depth, and now I can capture the video, but xvidcap (using ffmpeg) refuses to capture audio (Moofed mentioned he also had this problem). I'm at a complete loss as to why; it's supposed to capture using /dev/dsp, and I have plenty of other audio recording applications that capture off /dev/dsp just fine.

So anyway, I decided to use xvidcap to capture the video with no audio, and simultaneously run arecord to capture the audio, and then mux the video & audio together. This works to some extent, but I cannot get the audio to sync up right with the video. It starts out just fine, but very quickly gets out-of-sync.

Anyway, here's some stuff y'all might be interested in: I made a perl script (uses File::Tail) that watches errors.log so I can start & stop recording from in-game, with these aliases:
alias record_begin "echo Begin Recording; alias record_toggle record_stop"
alias record_stop "echo Stop Recording; alias record_toggle record_begin"
alias record_toggle "record_begin"
bind "R" record_toggle

You can download the perl script here: http://mandalor.homelinux.net/vendetta/xvidcap-control.pl

The perl script is hardcoded to capture 800x600, starting at the top left corner, so run Vendetta at 800x600 fullscreen (or edit the script to suit you).

Here's a video of me doing a round of BP, which shows how the audio gets out-of-sync: http://mandalor.homelinux.net/vendetta/videos/bp-1.avi AVI, 800 x 600, 25.00 fps, video:mpeg4, audio: (stereo, 48000 Hz); 165MiB

Umm. Linking to a 168MB file is probably a bad idea... Also, it's a worse idea if nothing I have here can play the file... Not even VLC!

PS: MB originally meant 1024 KB. This MiB stuff was just created because the public has no comprehension of binary numbers and thinks of MB as 1000 KB. I say screw them and let us keep the shorter abbreviation for ourselves!

Yeah, it's big, but why is that such a bad idea? I don't know why you can't play it, it's encoded in ISO MPEG-4. Either the Xvid or DivX codecs should play it fine.

Amibguity is bad. MiB removes amibiguity. Therefore MiB is good.

165 Men IN Black???

Knew it's a Sci-Fi game which seems very real, but no so real that Men In Black would be involved...

---FLASH!!! ----

What was I writing about?
Aps, yea: Fryed potatoes are real cool. I like them with ketchup...

--
Yours Larry LeBeauf (aka evil runlevel0)

MiB is a unit that specifies powers of two. Specifically, 1 MiB = 8(2^20) bits. So 1 Mib = 2^20 bits. I say stick to MB. 'tis better.

Did you switch to the OSS audio driver (instead of ALSA) before trying capturing? Maybe that's why sound doesn't work; ALSA doesn't even look at /dev/dsp.

Yeah, I thought of that, and was using OSS most of the time; and using sox's rec & audacity & other OSS recording apps I could record the audio off /dev/dsp, it was just xvidcap (using ffmpeg) that wouldn't capture the audio. Incidentally, for some reason I can't change the audio driver in the config screen while the game's running, I have to edit ~/.vendetta/config.ini while the game is not running in order to switch.

If the audio is getting out of sync, the chances are good that either A) the video framerate is wrong or B) the audio samplerate is wrong. A is far more likely... my experience with Linux encoding tools has been... frameratically challenged?
-:sigma.SB

Yeah, it's probably an issue with the framerate (although I blame the frame capturing, not the encoding). At this point I'm about ready to give up again. The grapes are probably sour, anyway.

Most sync errors I have had with recordings are due to dropped frames. With a framerate of 25/s every frame that drops produces a cumulative 40ms off-sync unless the capture software BOTH inserts empty/copied frames for the droppped ones AND does timer correction. It is not that important to get a frame every 40ms than getting exactly 45k frames in 1800 seconds.

If the off-sync is due to timing errors you might be able to correct this by changing the video frame rate to something exotic. If it is due to dropped frames (which usually are non-uniformly distributed) you probably have to do lot of cut&paste and audio time-shifting with tools like avidemux.

I played with this quite a long time ago. Long story short, even setting it to the smallest resolution it was still unable to write enough fps to keep the audio in sync. I even used a ram based fs to speed up IO, while it helped, it still wasn't enough.

So eventually I just gave up ...