Let us begin with the conclusion – there is no such thing as an ideal codec!
Different video capture utilities have a different ways (codecs) of compressing video in real time and, of course, each utility is supplied by developers as the so called perfect / correct solution.
I’ll try to provide briefly explain what happens in the modern world of real-time capture and compress.
How can you evaluate the performance of the codec? Very simple! The compression speed, the size of output data and the compression quality (picture after decoding).
These are the three main parameters that affect the user’s choice in some way . At least it should.
Let’s proceed. Just to reiterate – I look only at the level of video compression algorithms, and nothing more.
0. The most basic method with what are sometimes confused users – recording without compression.
The data is written in the exact form it is received from the video card.
This is a huge amount of data and therefore disk space, the highest image quality and minimum CPU load.
Unfortunately, even if you have a super fast hard drive (WD Velociraptor or SSD), the huge size of the frame just gobble up all the available space very quickly.
For example, for FullHD 30fps video will fill 1920 * 1080 * 3 * 30 = 178 MB per second, or 10 GB per minute!
1. The most revered, almost god-like utility – Fraps. It simply has just a crowd of fans who answer the question “what to use to capture game video” with “fraps is the best – it is proven”.
By whom and how it was proven – I do not know. Let us analyze this.
According to the open source code of the video decoder FPS1 (from FFMPEG), Fraps has pretty a simple and fast codec that compresses with small losses and large output data size.
This codec is similar in principle to the Low compression mode used in PlayClaw.
What does this codec do (the main stages, without going into details)? Incoming RGB data (3 bytes per pixel) is converted to YUV420 color space (2 bytes per pixel). So there is a little loss of information with regard to colors – blocks of 4 pixels are coded together and the losses can be seen in places where there is a sharp contrast. For example, the red line of one pixel width on a white background – you can see blur.
In general, however, these losses are practically invisible because it is rare situation in games. Then, the transformed data is compressed using Huffman compression which is an efficient method of lossless data compression.
Compared with the method without compression, Fraps and PlayClaw give a good picture with fast compression but the file size is still large (but not huge). You can count on 1-2 GB per minute for FullHD 30fps.
2. Special paragraph is for one of the compression methods used in MSI Afterburner – RTV1 codec.
According to the author, this is a revised method of S3TC texture compression, improved and accelerated by using SSE.
Compression is really fast, but the quality of the output is not good.
3. The next stage of codecs “evolution” – MJPEG, this compression is used in MSI AB and PlayClaw. The codec is very popular in the hardware devices such as cameras and video utilities because it is pretty simple and fast.
In simple terms, MJPEG is a set of JPEG pictures. Each frame is converted to the YUV color space (different formats: yuv444, yuv420, etc), followed by mathematics (discrete cosine transform – DCT) over pixels blocks, resulting in a certain loss of image quality (can be defined), then the data is compressed using Huffman algorithm.
Despite the fact that DCT is accelerated well on modern processors, this method is still a bit slower than Low compression used in PlayClaw / Fraps, but it produces a smaller file size.
4. Moving on to the most interesting method: MPEG-1, seen in Bandicam. It is issued by the developers as a super-performance solution. MPEG-1 – is the the same as MJPEG, but with a slight improvement – the ability to encode the differences between frames.
This may in some cases give a good gain in the amount of output data (many unchanging blocks of pixels in frames), but it of course uses more CPU power.
Compared to MJPEG compression quality is unaffected.
5. The final and quintessential video compression in real time – H.264. It is usually used as an external codec (if the utility supports external codecs) – sane developers will not add this compression in the set of built-in codecs without hardware acceleration.
But why? This is because the codec is very demanding on processing power. In other words, real time encoding of FullHD 30fps video simultaneously with the game will not be much fun for the player – it will lag and decrease in-game FPS.
This compression is popular in utilities that broadcast video over network (as a standard).
To obtain acceptable FPS you must either reduce resolution or to simplify, reduce the bit rate compression.
In any case, image quality will be decreased. I will provide the evaluation in the terms of gaming experience – it is our priority.
What is the result? The choice is of course yours to make. But as I said at the beginning – there is no ideal solution and each developer selects the encoding method for encoding recordings of video games in real time to the best of their abilities and needs.
The following diagram is perfectly suited to this topic:
I would like to note that the game video capture tool PlayClaw will meet all your needs.