Looking for a suitable lossy video codec to quickly record video in-game.

Started by
7 comments, last by Beosar 9 years, 7 months ago
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!
Advertisement
I gather that FFMPEG may be a suitable choice. Take a look at: http://blog.mmacklin.com/2013/06/11/real-time-video-capture-with-ffmpeg/
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
I've been using the intel performance primitives, encoding into MPEG4 (not h264 as that was slower) in realtime. but nowadays I'd go for the intel media SDK https://software.intel.com/en-us/vcsource/tools/media-sdk-clients
it's also cross platform, utilizes the dedicated intel hardware if available (so it's essentially 'free' on most PCs) and it's quite simple to use.

Maybe a lossless codec makes more sense. You can record in a lossless codec and encode it with the x264 encoder after recording. A standard HDD (7200 rpm) should be fast enough to record at 1080p, 30 fps with lossless compression.

Using a lossy codec for recording needs much CPU power and files are bigger than with x264, so upload takes much longer depending on the upload speed. In Germany, average upload speed is about 1 MBit/s (or maybe more, but many people still have 16/1 MBit/s internet connections), so uploading a 30 minutes 1080p video takes about 2 hours. And this is for x264. When using a lossy codec when recording, the file is about 2 times the size of the x264 video, so upload would take 4 hours.

Maybe you should let the user choose which of these options he wants to use depending on his internet speed and CPU power.

let's validate your claim:

http://www.tomshardware.com/charts/hdd-charts-2013/-06-Write-Throughput-Minimum-h2benchw-3.16,2905.html

best HDD makes 114MB/s

standard HDD makes around 60MB/s

1080p in RGB is 6075KB

@30Hz it's ~178MB/s

I'm afraid it's not working out even on the fastest HDD.

also, that's 10GB/minute and some people record hours of gameplay and you cannot really be sure there is 600gb of free HDD space just to spill it with uncompressed frames, realtime encoding might really make sense.

Intel hardware encoding was mentioned above - nVidia and AMD also have hardware encoders in modern GPUs.
I'm not sure if anyone has made a nice API that abstracts all if these bits of hardware (and a SW fallback) though... That would be a helpful library if it exists :)

let's validate your claim:
http://www.tomshardware.com/charts/hdd-charts-2013/-06-Write-Throughput-Minimum-h2benchw-3.16,2905.html
best HDD makes 114MB/s
standard HDD makes around 60MB/s
1080p in RGB is 6075KB
@30Hz it's ~178MB/s

I'm afraid it's not working out even on the fastest HDD.

also, that's 10GB/minute and some people record hours of gameplay and you cannot really be sure there is 600gb of free HDD space just to spill it with uncompressed frames, realtime encoding might really make sense.

I said lossless COMPRESSION. RGB is not compressed. I recommend to use a codec which allows lossless compression. I use the Dxtory Codec for recording gameplay videos (with up to 300 MB/s in 4K with 4:2:0 chroma subsampling (which is also used by YouTube), so it would be 75 MB/s or less in 1080p (depending on the game you record)), but it's not open source (it comes with Dxtory, a software to record gameplay videos). Maybe you could find an open source codec for your game or write your own. It's difficult to achieve this compression with low CPU usage, but it's not impossible. (I am able to play and record AC4 and Watch_Dogs in 4K, so the cpu usage is not really high. I don't think this would be possible with lossy compression without getting a video full of compression artifacts.)

In general you could say that the lower the cpu usage of a compression algorithm, the bigger the filesize of the output video. It took me up to 12 hours per 1h video to compress my videos with x264 in 4K (3 hours in 1080p) even with a i7-3930K processor. The results are amazing (very good quality and "little" filesize (between 7 and 40 GB per hour in 4K)). You have to find the best trade-off between filesize and duration of encoding (or let the user decide).

Be aware of the fact that most people who want to record more than just a few videos will use an external tool like Fraps or Dxtory or nVidia's ShadowPlay instead of your ingame tool.

Implementing a good recording and encoding algorithm is not trivial, otherwise there would not be so many recording programs which are not really good if you want a high quality video. NEVER use a fixed bitrate. It would result in either too high bitrate in some scenes (good quality but also much too big files) or too low bitrate (little filesize but also really bad quality). Use quality-based compression. Some things like rotating the camera in a game require a very high bitrate because you can hardly compress a scene if everything is moving. You will see an image full of compression artifacts in these scenes if using a fixed bitrate (or set the bitrate to 40000 kBit/s for 1080p and get a video with good quality which is really big (some of my 4K videos have less than 40 MBit/s average bitrate)).

Now you know what you should be aware of when implementing a recording function in your game. I hope I did not forget something...
sorry, I've apparently skipped that tiny word ;)
and 4:2:0 YCbCr is a compression already:P

but what exactly is the point of creating an lossless stream? his request were:
-small amount of data that is shared from within the app on-line
-fast (lossy compression tends to be faster than lossless at reasonable file sizes)
To get the smallest file size, you have to use x264 (see http://compression.ru/video/codec_comparison/h264_2012/figures/results.png) which is too slow for realtime encoding in 1080p. Uploading a 30 minute 1080p video would take up to many hours depending on the internet connection speed of the user. Even if you could achieve 200% of the x264 file size, it would be often faster to encode it with x264 after recording. Let's say the video's file size would be 2 GB if encoded with x264. You record it lossy, so it is 4 GB. Let's assume the user lives in a country with low internet speed (e.g. Germany) and has 1 MBit/s upload speed, so uploading would take 8 hours. It would be faster to encode 30 minutes of lossless video with x264 and upload it (about 2h encoding, 4h uploading).

Recording in a lossless codec would be better in this case.

Also do uploading in a separate process, so the user could leave the game and the upload would not be aborted.

This topic is closed to new replies.

Advertisement