Editing Codec Roundup

[Zarxrax]

Today I decided to do some tests of editing codecs to see which ones are out on top these days. I've always been quite partial to Lagarith, but I've been having some troubles with it lately, so I decided to see how everything else stacks up.
The results of these tests are non-scientific.

My system utilizes a 2.4ghz Intel Q6600 processor (4 cores).
The video that I encoded was an unprocessed 15 minute clip from Spirited Away (NTSC DVD).
I tested the following codecs, all using yv12 mode, intra-frames only:
- Lagarith (multithreading enabled)
- FFdshow Huffyuv (median mode, adaptive huffman tables)
- FFdshow FFV1
- x264 VFW

For x264, I made 4 tests. One with the default settings. One with cabac disabled. One with cabac disabled and the QP set to 1. And one with cabac disabled and the QP set to 10.

For each codec I measured three things:
- Time to encode
- Output size
- Average CPU usage while encoding

And here are the results:

Lagarith
Time: 3:09
Size: 3.27gb
CPU usage: 65%

FFdshow huffyuv
Time: 1:50
Size: 3.49gb
CPU usage: 50%

FFdshow FFV1
Time: 8:39
Size: 2.89gb
CPU usage: 30%

x264 VFW
Time: 5:19
Size: 3.01gb
CPU usage: 95%

x264 VFW no cabac
Time: 3:29
Size: 3.39gb

x264 VFW no cabac, QP1 (not lossless)
Size: 3.67gb

x264 VFW no cabac, QP10 (not lossless)
Size: 2.33gb


Here is how each codec performed relative to one another.

Speed:
472% - 8.39 - FFV1
290% - 5:19 - X264
190% - 3:29 - X264-nocabac
172% - 3:09 - Lags
100% - 1:50 - Huff

Size:
100% - 2.33 - X264-nocabac-qp10
124% - 2.89 - FFV1
129% - 3.01 - X264
140% - 3.27 - Lags
145% - 3.39 - X264-nocabac
150% - 3.49 - Huff
156% - 3.67 - X264-nocabac-qp1


Conclusion:

FFV1 was the best compressing lossless codec in the test, but performed very slow.
X264 appears to be a great contender as an editing codec. It was almost as good as FFV1, but also much faster. If the cabac setting is disabled it almost approaches Lagarith in both speed and compression efficiency, but doesn't quite catch it.
If you are willing to forgo lossless encoding for filesize savings, using QP10 in x264 can get you a filesize savings of 30-45% over lossless x264. The big surprise here was that setting QP1 actually resulted in LARGER sizes than the lossless version.
If you want pure speed, it seems that nothing beats ffdshow's implementation of huffyuv. It's way faster than everything else, and it's compression efficiency isn't that much worse than lagarith's.

[LantisEscudo]

Is this just for creating the clips, or for actually working with them? Because for me, the performance questions aren't at the creation stage, but at the editing stage, so decode time and latency are my big issues.

I can always queue up jobs in Vdub and leave them to run overnight to create clips, but if I have to wait half a second for each frame in my editor, the codec is useless.

[Zarxrax]

All of the clips decode pretty much instantly whenever I seek to a frame. As long as a codec can decode in realtime (which all of the codecs do, on my pc) it shouldn't be a problem.

[Kariudo]

not like this should matter too much, but someone running something other than a quad core might have a little more trouble in that regard

mebbe a good idea to limit the number of cores you're using and test decoding/seeking again.
(msconfig, boot, advanced options, number of processors -> 1)
just remember to set it back to 4 after you're done testing >_>

[mirkosp]

@Lantis: I would suggest trying --tune fastdecode for x264 in case x264 speed in decoding isn't to your liking.

[Mister Hatt]

Why are you comparing lossless codecs to x264's non-lossless modes? You haven't done any testing with different IDR frame counts either. Here are the results of several lossless codecs tested roughly a week ago by myself, an x264 developer, and DeathWolf:

Code: Select all

Bored lossless encoding test
YV12 848x480@23.976, source on ramdisk, x264 is in lossless mode, destination null

Encode Test, sorted by size
===========================
Codec        FPS     Size(MB) Comment
X264         58.26   180.81   (multi threaded,default)
X264         16.98   180.81   (mono threaded,default)
X264         65.24   182.40   (multi threaded,fast)
X264         18.74   182.40   (mono threaded,fast)
X264         486.81  234.41   (multi threaded,ultrafast)
X264         155.42  234.41   (mono threaded,ultrafast)	
X264         147.47  284.27   (mono threaded,ultrafast, -I 3)
FFV1         54.90   289.07   (default, yv12 colorspace)
X264         145.77  306.96   (mono threaded,ultrafast, -I 2)
Lagarith     110.51  340.63   ()
FFHuffYV12   287.33  383.39   (default, yv12 colorspace)
X264         136.96  390.37   (mono threaded,ultrafast,all intra)
HuffYV12     615.80  443.91   ()
VBLE         261.22  458.22   ()
Null Codec   1724.4  1274.9   ()


Decode Test, sorted by speed
============================
Codec        FPS     Comment
FFV1         42.46   (default, yv12 colorspace)
VBLE         46.34   ()
Huffyv12     86.20   ()
Lagarith     88.86   (yv12 mode)
FFMS2 X264   99.78   (default)
FFMS2 X264   100.23  (fast)
FFMS2 X264   159.63  (ultrafast,all intra, much faster seeking)
FFMS2 X264   187.40  (ultrafast,-I 2, faster seeking)
FFMS2 X264   195.92  (ultrafast,-I 3, fast seeking)
FFHuffYV12   221.03  (default, yv12 colorspace)
FFMS2 X264   222.09  (ultrafast)
Null Codec   1725.8  ()

Note: please note that h264 is slow to seek:) so if you intend to browse around the stream, either fixing stuff/looking for stuff, it's not an ideal choice

If it's not immediately obvious, 'ultrafast' and so on with x264 are the presets built into it's commandline encoder. FFMS2 is the FFMpegSource 2 (svn revision 292) Avisynth plugin by Mysloik.

Also, to clarify a few things:

-I 3 means keyint. AVC seeking is only slow when you have high keyints, which by default is 250. Using 2 or 3 will make seeking MUCH faster, moreso than FFV1 on most material. FFV1 is by far the slowest codec to both encode and decode, but it has much better compression than Lagarith and most Huffman codecs. It is usually compressed worse than what x264 does, however still images compress better with FFV1 due to the nature of the codec. Additionally, filesizes will be much larger when saving as RGB and even moreso as RGBA/RGB32. If your source is YV12, you should keep it that way to make it truly lossless, and save a large amount of HDD space.

An error I noticed in Zarx's test was that he used x264vfw. Because it's VFW, it lacks some things that h264 streams normally have and that is what made his AVC encode so much larger than FFV1. Additionally, x264 speed is highly variable and a lot of the things he left enabled are only useful for lossy compression. Disabling them doesn't impact lossless, and makes it considerably faster. The 'best' way to do x264 lossless currently is with options --preset ultrafast --tune zerolatency --crf 0 -I 2, or if you want it to be smaller, -I 3 works. If you want it faster at seeking and don't mind a largish jump in filesize, using --tune fastdecode,zerolatency is a good way to go. The fastdecode tune option disables CABAC which vastly bumps filesize but does make it a lot quicker to encode and decode.

[Zarxrax]

@MisterHatt
My encodes specifically use keyints of 1. For editing, anything else is simply not acceptable. I also specifically used the VFW build, because the majority of editing software has issues with anything that is not AVI.
Regarding the testing of non-lossless settings, people are always whining about how much space lossless files take up, so I wanted to see how much the size could be reduced by using higher QPs.

[Zarxrax]

I did some more tests with FFV1, and found that setting the coding type to AC saves even more filesize for just a little slower encoding time.

FFV1 (AC coding)
Time: 9:31 (519%)
Size: 2.82gb (121%)

I also tested decoding speed of this stream, which I am quite certain would be the slowest of all the encodes. It took 12:07 to decode. Keep in mind that it is only single threaded. While it seems slow, the full clip is 15 minutes, so that means it was able to decode at approximately 30 frames per second.

[Mister Hatt]

That's because CABAC is a much more efficient entropy encoder than CAVLC. It will be much smaller with pretty much any codec but it's a lot more complicated to decode.

As far as VFW goes, it's really irrelevant as Avisynth is a VFW frameserver. FFMS2 is your friend.

[Zarxrax]

As far as VFW goes, it's really irrelevant as Avisynth is a VFW frameserver. FFMS2 is your friend.

No, it's not irrelevant. If it were irrelevant, then I would have just used Avisynth.

1. Most editing applications don't natively accept avisynth scripts (in fact I can't name a single one that does)
2. You would have to use AVFS on every clip, which can be a hassle and does add some amount of overhead. Plus it can be dangerous if you try to open your projects while the files aren't mounted properly.
3. Avisynth sucks at juggling memory for dozens of scripts at the same time