Video Capture Enhancements

[Baker]

There are 2 video capture schemes in different Quake engines: The "JoeQuake" one and the "DarkPlaces" one.

At least on Windows, I sought to combine the strengths of both methods and add some of my own ideas:

In FitzQuake Mark V Revision 5 (download + source | readme ) All the source code changes are marked with #ifdefs making it rather straightforward to assimilate a modification, see quakedef.h in the source code to see the marking names.

In FitzQuake Mark V:

1) If the command includes, say, "+capturedemo demo1" it will exit after demo record. This means someone could use batch files to turn a lot of demos in videos.
2) I essentially eliminated the need to specify a video codec. There are only 4 viable video codecs out in the wild (*): vp80 (Google's WebM), xvid, divx and uncompressed (no codec).

(*) Because some video codecs are too slow to encode video --- do you want it to take hours? ---- and some generate video of poor quality or other encoders like H.264 you have to pay for. Google's WebM and XVID and DIVX are free (and open source too). YouTube supports them all, obviously.

The engine attempts to use VP80. If that fails, tries XVID and then tries DIVX. All fail, it uses no codec and does an uncompressed video stream. Google's WebM/VP8 ( http://www.optimasc.com/products/vp8vfw/index.html <--- download ) makes files of slightly higher quality and much smaller file size than XVID (although XVID is a bit faster). WebM is also open source and free. cl_capturevideo_codec defaults to "AUTO" (use best one available) --- cl_capturevideo_codec "xvid" would force the xvid codec and cl_capturevideo_codec "none" would use no codec.

3) One of the most annoying aspects of video capture is wanting to know how much longer completion is going to take. Like DirectQ does with some things, I put this in the window caption (elapsed time and estimated time remaining).

4) No need to name the video file. "capturevideo toggle" autonames the video file, so merely binding "capturevideo toggle" to a key can be used to capture snippets of video. VirtualDub (free and open source) can easily be used to combine separate video files of the same codec into a single stream.

5) capturedemo aborts the playing of the demo if it couldn't create the video file for some reason. I also have capturedemo automatically NOT record the console (I have a better and funnier solution not implemented that would be even better ... do a glFinish before drawing the console, do a glReadPixels -- this is the "capture" --- and then draw the console and then swapbuffers. The video stream would never include the console of a capturedemo but you'd see the console on-screen. My reason for not implementing this yet is not having a plan to prevent the con_notify text from appearing.)

[Spike]

<devil's advocate> What about audio compression? </devil's advocate>

there are other viable video compression codecs however.
if you're chucking out 60 frames per second for 30 mins (30 mins of gametime, probably fast-forwarded as recording), then that's a lot of data getting chucked at the disk, also many (cheap) drives can't cope with the transfer rates which can result in slower recording etc. a little RLE or other fast lossless compression can reduce the data sizes quite a lot.

tbh, for defaults I'd use whatever youtube recommends (and is installed).
glReadPixels before drawing the console works fine. Just make sure you're not forcibly tripple buffered.

[qbism]

As a happy user of the JoeQuake vid tutorial, I look forward to checking this out. This in conjunction w/ 'record demo any time' should speed up video making.

[Baker]

<devil's advocate> What about audio compression? </devil's advocate>

I use the JoeQuake code and I think it uses mp3 through some Windows API.

there are other viable video compression codecs however. if you're chucking out 60 frames per second for 30 mins (30 mins of gametime, probably fast-forwarded as recording), then that's a lot of data getting chucked at the disk, also many (cheap) drives can't cope with the transfer rates which can result in slower recording etc. a little RLE or other fast lossless compression can reduce the data sizes quite a lot.

I have cl_capturevideo_fps default to 30 (this is the theory that anything too far above 26 frames per second is a waste mostly). Someone wanting to use a different video codec could do cl_capturevideo_codec "MRLE" or whatever they like. I'm not saying everything with this scheme is perfect.

Having the default codec as "auto" is better than bother the user with one more cvar and hoping someone didn't load some other engine that doesn't have that cvar, writing the config and the cvar being defaulted again.

Just make sure you're not forcibly tripple buffered.

Does that affect glReadPixels? I thought that would get read from the color buffer? :?

[revelator]

h.264 is actually opensource while divx is not. as for codecs one could use ffmpeg libraries (includes allmost all formats in one).

[Baker]

h.264 is actually opensource while divx is not. as for codecs one could use ffmpeg libraries (includes allmost all formats in one).

"On August 26, 2010 MPEG LA announced that H.264 encoded internet video that is free to end users will never be charged royalties.[10] All other royalties will remain in place such as the royalties for products that decode and encode H.264 video." -- Wikipedia

I'd interpret that as meaning playing a H.264 is free-ish (decoding) but encoding isn't (recording). DivX codec sucks, I guess I didn't know that one wasn't "open" but XVID is 4x better than DIVX (XVID produces smaller file sizes and higher quality, etc.) I included divx in the "search chain" just because it is way faster than uncompressed writing to disk.

[revelator]

might be another codec but vlc manages its own version of h.264 capable which is opensource

just noticed an opensource version of divx is actually there but is called dr divx.

[revelator]

http://www.videolan.org/developers/x264.html

this one

And dr divx was just a frontend for divx 6 which is not opensource ah well :/

[Baker]

http://www.videolan.org/developers/x264.html this one

If they are so confident it is legal, why isn't there a binary in that distribution (it is just source code to compile yourself). Do you see my point? I am not a lawyer, but I don't see how you have a GPL binary distribution of something where you didn't share the patent rights. I'm too lazy to try to read all the fine print, but a H.264 application distribution cannot be GPL nor the video codec. Then again, I could be completely and absolutely wrong.

[revelator]

there are binaries but vlc uses it internally (no codecs needed they are all plugins) just search for x264 codec for windows there are several versions.

[revelator]

32 and 64 bit codecs here https://sourceforge.net/projects/x264vfw/

and some explanation here.

http://en.wikipedia.org/wiki/X264

[revelator]

reason its legal is that the x264 codec was written from scratch to support most of what the h.264 codec could do in time it got even better than the standard though

[Baker]

reason its legal is that the x264 codec was written from scratch to support most of what the h.264 codec could do in time it got even better than the standard though

Just tried it and it appears to work well except apparently the codec wants to get some flags or some such thing that VirtualDub would tell it. Since I don't do this, I lose audio sync. Seems a lot faster than vp80. If I could easily set those flags ... well, +1 to rainy day list. The codec seems very fast.

[taniwha]

Written from scratch makes no difference when it comes to patents (which is the problem with video codecs).

[revelator]

So i guess they should have been taken to court allready since this codec has existed since 2004 xD
i bet the reason they have not is that they dont use patented algorithms (which is fubar anyway imho).
The codec uses xvid algorithms internally instead.