I'm working on integrating a video recording functionality inside of a game, so that game footage can be automatically encoded to video and shared online from within the game. Currently I've integrated the libtheora codec, but it is too slow to be really functional(it can encode about 4 Full HD frames per second).

So now I'm looking for a faster video codec that should ideally also have the following requirements:

  • Output file shouldn't be too big (duration of video can go up to 30 minutes and needs to be shareable on-line).
  • The codec should ideally work for Windows Mac and Linux.
  • Has a license that is usable in a commercial game, so probably not GPL.

paid options are also possible, I have a small budget available.

Do any of you have a suggestion for an appropriate codec for my specific application? Thanks!


There is a rule in compression, quality, size and speed, pick two of three. Video compression is an incredibly complex process that requires a lot of resources on either the CPU, GPU or both. You can get around that one of two ways, you can either reduce the level of compression (with lossless being the fullest extreme) or you can reduce the quality (making larger approximations means the video has more artifacts, but is simpler to compress).

Unfortunately, in the case of video games, this problem is compounded as the game itself requires the same resources that the video encoding requires. This means that your best (and really only) option for high quality, high compression encoding of video games is to move the processing off the resources that the game is using.

Most simply, this generally means using specialized real time encoding hardware that is optimized for making real time, high quality streams. Such hardware is unfortunately not particularly cheap and generally runs around $100 on the low end to over $1000 on the high end, with $200 to $500 being around the point at which it becomes "professional" hardware, depending on the features of the device. Unfortunately, this solution doesn't help your scenario at all other than suggesting that you may want to include support for some of the most popular real time encoders to be used with your game natively.

You can also try doing it by capturing uncompressed on one system and streaming that data over a really fast network connection to another computer and have that computer do the encoding. This can be a bit cheaper if you already have a second powerful computer and a fast (gigabit or higher) network, but if you have to build a computer for it, the real time encoder is a better option as it is cheaper than a dedicated PC for the job and will do a better job anyway. You might consider building your own client that could simplify this process for users.

One thing you can do is use the encoder support built in to some more recent graphics cards. Some cards have started including their own consumer level encoding support for doing things like streaming. If you tap in to this functionality, you would be able to make pretty good quality encodes on the fly.

Overall, your best bet though, is probably to capture to a lossless or near-lossless quality file and then encode it after the fact. You can include an encoder of your choice and batch things up to run during free cycles that the game isn't making use of. After compression finishes, you can get rid of the full size file.

I'd also suggest at looking at some of the codec options used by software like FRAPS to determine what might work well for that high quality, high speed codec that would make the files a bit smaller, but always keep in mind that the more compression you do, the more it will impact the performance of your game.


x264 would be a good option, its an extremely fast and efficient h264 encoder, probably the best on the market and its open source. I has several good presets/profiles f.e. the ultrafast profile which can encode FullHD with several 100FPS on a modern multi core cpu. I made good experiences with it regarding capturing real time rendering applications.

Its available as an either standalone encoder or through FFmpeg.

x264 is under the GPL but can be licensed under a commercial license. YouTube is using it aswell. http://x264licensing.com/


You really only have one option. h.264. It is the only codec that can fulfill you needs here. And its the only codec that can play on mobile. You will have to pay licensing to MPEL LA, and probably to the software vendor (most likely core codec). You can also encode using some OS/Video card features (NVENC for example), and possibly save the software costs.

  • There are far more options than just h.264 that will play on mobile. Webm and any number of other formats also play well on mobile. h.264 is simply not the only option, nor is it necessarily the best one, particularly if they can do a transcode after capture.
    – AJ Henderson
    Sep 22 '14 at 19:02
  • On IOS any other codec will be in software, so to decode you are using high CPU and hence battery. Sure you can do it, but I would not recommended it.
    – SlimSCSI
    Sep 22 '14 at 19:05
  • that's still a far cry different from being "the only codec that can play on mobile".
    – AJ Henderson
    Sep 22 '14 at 19:07
  • Its a difference between practical and possible. I assumed he wanted to make a product with good user experience. But you are correct, I should have clarified.
    – SlimSCSI
    Sep 22 '14 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.