Editing Codec Roundup

This forum is for questions and discussion of all the aspects of handling your footage. If you have questions about capturing/ripping footage, AviSynth, or compression/encoding/converting, look here.

Editing Codec Roundup

Postby Zarxrax » Tue Mar 30, 2010 5:51 pm

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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby LantisEscudo » Tue Mar 30, 2010 8:02 pm

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.
User avatar
LantisEscudo
 
Joined: 08 Mar 2001
Location: Vermont

Re: Editing Codec Roundup

Postby Zarxrax » Tue Mar 30, 2010 8:09 pm

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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby Kariudo » Tue Mar 30, 2010 11:20 pm

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 >_>
ImageImage
Image
User avatar
Kariudo
Twilight prince
 
Joined: 15 Jul 2005
Location: Los taquitos unidos
Status: 1924 bots banned and counting!

Re: Editing Codec Roundup

Postby mirkosp » Wed Mar 31, 2010 1:48 am

@Lantis: I would suggest trying --tune fastdecode for x264 in case x264 speed in decoding isn't to your liking.
Image
User avatar
mirkosp
MODkip
 
Joined: 24 Apr 2006
Location: Gallarate (VA), Italy
Status: (」・ワ・)」(⊃・ワ・)⊃

Re: Editing Codec Roundup

Postby Mister Hatt » Wed Mar 31, 2010 2:04 am

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.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: Editing Codec Roundup

Postby Zarxrax » Wed Mar 31, 2010 10:45 am

@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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby Zarxrax » Wed Mar 31, 2010 12:11 pm

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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby Mister Hatt » Thu Apr 01, 2010 1:22 am

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.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: Editing Codec Roundup

Postby Zarxrax » Thu Apr 01, 2010 10:11 am

Mister Hatt wrote: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
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby Mister Hatt » Thu Apr 01, 2010 12:32 pm

avs2avi is a really awesome tool, there is NO good reason to EVER use x264vfw. YV12 lossless codecs are an alternative if you must use avi, and I think the docu I linked gives a good example of which to use. That also kills the need for AVC I guess. Either way, don't ever use or condone x264vfw. Avisynth sucks in general at memory handling, have you seen the clusterfuck that is the avs core? I recall Myrsloik mentioning writing a Premier plugin for FFMS2 at some stage, but if an editor can use VFW, then it can use avisynth unless there is something VERY wrong with it's VFW interface.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: Editing Codec Roundup

Postby Zarxrax » Thu Apr 01, 2010 6:04 pm

Mister Hatt wrote:avs2avi is a really awesome tool, there is NO good reason to EVER use x264vfw. YV12 lossless codecs are an alternative if you must use avi, and I think the docu I linked gives a good example of which to use. That also kills the need for AVC I guess. Either way, don't ever use or condone x264vfw.

Yes, I used YV12 lossless codecs, which was the entire point of this test. And x264 happens to be a YV12 lossless codec.
BTW, Dark_Shikari approves.

<Dark_Shikari> no, x264vfw is fine
<Dark_Shikari> as long as you're not abusing it
<Dark_Shikari> for coding without b-frames, especially lossless, it should do the job fine
<Dark_Shikari> I use it myself
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

Re: Editing Codec Roundup

Postby Mister Hatt » Sat Apr 03, 2010 6:44 am

[19:40:25] <pengvado> vfw sucks, and x264vfw is no exception

my akupenguin > your D_S

I meant other YV12 lossless codecs when I wrote that post. The trouble with telling people x264vfw is ok for one thing is they go on to assume it's ok for others. That's the main reason not to use it for lossless. There are other dumb things it does but they're minor and not really important.
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you


Return to Footage Help

Who is online

Users browsing this forum: No registered users and 1 guest