[2014] Comparison of Lossless YV12 Codecs (Speed / CPU usage / Size)

[Atak_Snajpera]

CPU used : Q6600@3GHz
All read / write done on RAMDISK (2.5GB)

-------------------------------------------------------------------------------------

Uncompressed park_joy_1080p50.y4m 1474 MB

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 951 MB 158 fps (~65%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 981 MB 149 fps (~52%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 944 MB 92 fps (~65%)

x264 r2345 (--qp 0 --superfast --fastdecode) 35 fps (100%) 881 MB 50 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 52 fps (100%) 943 MB 50 fps (~95%)

-------------------------------------------------------------------------------------

Uncompressed crowd_run_1080p50.y4m 1474 MB

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 880 MB 170 fps (~64%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 934 MB 152 fps (~54%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 871 MB 95 fps (~68%)

x264 r2345 (--qp 0 --superfast --fastdecode) 33 fps (100%) 863 MB 51 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 46 fps (100%) 912 MB 51 fps (~95%)

-------------------------------------------------------------------------------------

Uncompressed ducks_take_off_1080p50.y4m 1474 MB

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 897 MB 167 fps (~64%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 889 MB 158 fps (~51%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 897 MB 93 fps (~68%)

x264 r2345 (--qp 0 --superfast --fastdecode) 29 fps (100%) 1008 MB 51 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 46 fps (100%) 1015 MB 51 fps (~95%)

-------------------------------------------------------------------------------------

Uncompressed in_to_tree_1080p50.y4m 1474 MB

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 823 MB 176 fps (~64%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 851 MB 164 fps (~53%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 811 MB 98 fps (~70%)

x264 r2345 (--qp 0 --superfast --fastdecode) 34 fps (100%) 796 MB 53 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 48 fps (100%) 835 MB 53 fps (~95%)

-------------------------------------------------------------------------------------

Uncompressed old_town_cross_1080p50.y4m 1474 MB

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 824 MB 178 fps (~65%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 846 MB 165 fps (~53%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 813 MB 98 fps (~70%)

x264 r2345 (--qp 0 --superfast --fastdecode) 33 fps (100%) 843 MB 53 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 47 fps (100%) 873 MB 53 fps (~95%)

-------------------------------------------------------------------------------------

AVERAGE VALUES

MagicYUV 0.9 (Default Settings) 44 fps (~50%) 875 MB 170 fps (~64%)

UT VIDEO 13.3.1 (ULH0 - speed) 43 fps (~46%) 900 MB 158 fps (~53%)
UT VIDEO 13.3.1 (ULH0 - compression) 43 fps (~46%) 867 MB 95 fps (~68%)

x264 r2345 (--qp 0 --superfast --fastdecode) 33 fps (100%) 878 MB 52 fps (~95%)
x264 r2345 (--qp 0 --ultrafast --fastdecode) 48 fps (100%) 916 MB 52 fps (~95%)

[Dark Shikari]

Huffyuv shouldn't be that slow. Which HuffYUV encoder are you using? Which frontend are you using?

Which encoders are you using multithreading in? I think ffvhuff now has multithreading support, so using it in Lagarith but not Huffyuv could be a little bit misleading.

How are you measuring decoding speeds? Many of these formats have multiple available decoders that aren't of equal performance. Which ones are multithreaded? Going by the low speed of FFV1, I'd have to guess you're not using multithreading there even though the encoder and decoder support it.

It would be nice to include FFV1 with a better mode (e.g. AC).

Where is the "132fps" for reading back the y4m file coming from? How are you measuring "decoding" raw video? I would think `time cat file.y4m > /dev/null" would be faster than that.

[Atak_Snajpera]

I used AVSMeter with following scripts

DirectShowSource("")

or

AviSource("")

or

RawSource("")

FFDshow was used as HuffYUV and FFv1 encoder and decoder. Encoding speed taken from virtualdub.

[Dark Shikari]

This a terribly uncontrolled setup for such an authoritative benchmark. Three different input methods, going through directshow instead of using things directly, "ffdshow" as a decoder/encoder without settings or version, an unknown mystery H.264 decoder, no information on what's multithreaded and what isn't...

At the very least, can you benchmark things directly with ffmpeg instead of going through this roundabout method? And both HuffYUV and FFV1 support multithreading, so if you're using threads in other encoders but not them, your test is kind of inaccurate.

You've also marked Lagarith as "multithreading", but I'm pretty sure that UT and x264 in your test are multithreaded too, even though you didn't mark them.

[Atak_Snajpera]

I tested both DirectShowSource and AviSource to check if decoding speed changes. In both cases decoding speed was the same.

"ffdshow" as a decoder/encoder without settings or version, an unknown mystery H.264 decoder, no information on what's multithreaded and what isn't...

latest revision was used. h.264 / HuffYuV / FFV1 was decoded by libavcodec. For h.264 number of decoding threads is 4.

You've also marked Lagarith as "multithreading", but I'm pretty sure that UT and x264 in your test are multithreaded too, even though you didn't mark them.
Lagarith has this option disabled by default. UT and x264 have mutithreading enabled by default. Besides if you get cpu usage above 25% on Quad then it clearly shows that we have multithreading enabled.

[poisondeathray]

FFDshow was used as HuffYUV and FFv1 encoder and decoder. Encoding speed taken from virtualdub.


Atak, would you mind testing some of the other HuffYUV variants?

HYMT, HYFU are VFW versions , IIRC HYMT is the fastest (huffyuv multithreaded) out of the Huffyuv bunch

[Dark Shikari]

latest revision was used. h.264 / HuffYuV / FFV1 was decoded by libavcodec. For h.264 number of decoding threads is 4.The latest libav shows the following:

FFV1: threaded encoding/decoding
Huffyuv: no threaded encoding, threaded decoding

These don't look to be enabled in your tests. Please fix this (and as mentioned, there's also an MT variant of the HuffYUV encoder, albeit not in libav/ffmpeg).

Having 30% CPU usage doesn't mean that more than one thread was used, because you're going through such a complex pipeline of source filter, avisynth, virtualdub, and so on. It's certainly not hard to spike to 30% with this kind of setup with one thread. FFV1 and HuffYUV should be able to nearly cap your CPU usage; 30% isn't that.

I'm also pretty sure I remember Lagarith getting better CPU usage than that, but I might be wrong.

[Atak_Snajpera]

does your huffyuv mt support yv12? mine supported only yuy2. also size was odd 709mb so i didn't include in test.

[poisondeathray]

does your huffyuv mt support yv12? mine supported only yuy2. also size was odd 709mb so i didn't include in test.

I think you're right, the 2 VFW versions don't support YV12

[yukkuri]

I'm sorry in English translation
[vctest] VCM benchmark for lossless codec
http://umezawa.dyndns.info/
http://umezawa.dyndns.info/archive/vctest/vctest-20101024.zip
Japanese Video codec benchmark page
http://amalabo.blog35.fc2.com/blog-entry-202.html
http://matome.naver.jp/odai/2134673384249536701

[Atak_Snajpera]

ADDED: MagicYUV 0.9 results

[Ignus2]

ADDED: MagicYUV 0.9 results

The codec setup is definitely wrong somewhere, the bigger file size than raw input should be a clear indication of that. I guess it got RGB instead of YUV.
What kind of colorspace was the source in? YUV 4:2:2 or 4:2:0?
Did you use fast recompress mode in VirtualDub? If not, did you specify in "Video->Color Space" to use "Same as decompression" for output?

Greets,
I.

[Atak_Snajpera]

Updated tests with latest UT Video and using Fast Recompress option in VirtualDub

[benwaggoner]

Updated tests with latest UT Video and using Fast Recompress option in VirtualDub
Are you using 64-bit VDub?

[Atak_Snajpera]

All tests in 32bit only

[Procrastinating]

Is there any particular reason why slower x264 presets are not used? Those with particularly powerful machines might want to archive video, for example.

[mariush]

Virtualdub 1.10.4 build 35491/release
Virtualdub 1.10.4 build 35491/release AMD64 (for Lagarith 64bit)

Options > Performance : 64MB avi output buffer, 8KB audio buffer, 256 video buffers, 1 second audio buffer
Displays panels disabled (so they won't autoenable during compression)
Video > Fast Recompress (YV12)
Audio > None

Source file : first 1800 frames from 4.Girls.YoonYoon-1080p60fpsRef5-21Mbps.mkv , saved to uncompressed YV12 in an AVI container.
Source info : YV12 1920x1080 59.94fps 1800 frames
Source size : 5,598,768,084 bytes

Both input test file and output test file on RAMDISK (11 GB) and output file preallocated (to make sure ram is allocated to the ramdisk driver)

System : FX-8320 stock (8 core @ 3.5-3.75 Ghz , 16 GB DDR3 1600)

Encoding time recorded by running Process Monitor from SysInternals Suite configured to drop all events except the ones performed by Virtualdub.exe (or VeeDub64.exe for the 64bit version).

Using the time from the moment input.avi is opened to the moment output.avi is closed.
Note: While Filemon logs the events to memory and backs to disk so it should not affect measurements, but nevertheless it is possible to skew the results a bit (a few ms of cpu time stolen from encoder/virtualdub). However, since it runs the same way for all tests, there shouldn't be any unfair advantage to any codec.


Run Time FramesPerSecond Size Percentage CPU avg CPU peak
1 5.6506 318.5502424521 5598768084 100.0000000000 30 38 direct stream copy , yv12
2 5.9721 301.4015170543 5598768084 100.0000000000
3 5.7514 312.9672775324 5598768084 100.0000000000

1 50.766 35.4568017965 4019800952 71.7979543301 15 17 Huffyuv 1.3.1
2 50.8774 35.3791663882 4019800952 71.7979543301

1 41.1791 43.7114944231 3603685440 64.3656851995 15 18 Huffyuv 2.1.1 best no multithreading
2 41.0411 43.8584735789 3603685440 64.3656851995

1 19.1763 93.8658656779 3613358068 64.5384487049 48 51 Huffyuv 2.1.1 best 8 threads
2 19.5493 92.074908053 3613358068 64.5384487049

1 20.6157 87.3120970911 4072872788 72.7458742154 47 53 Huffyuv 2.1.1 fastest 8 threads
2 20.8183 86.462266666 4072872788 72.7458742154

1 36.8121 48.8969659433 2403039988 42.9208703048 21 24 Lagarith 1.3.27 32 bit MT
2 36.7089 49.0344303425 2403039988 42.9208703048

1 12.7341 141.3527457771 3063991292 54.7261691506 49 55 utvideo yuv420 bt.709 ulh0 8cores speed
2 12.6878 141.8685666546 3063991292 54.7261691506

1 12.7533 141.1399402508 2536541484 45.3053501403 57 62 utvideo yuv420 bt.709 ulh0 8cores compression
2 13.2182 136.1758787127 2536541484 45.3053501403

1 13.7306 131.0940526998 1811453678 32.3545046128 98 99 ultrafast, fast decode, core 130 r2274bm c832fe9
2 14.4345 124.7012366206 1811453678 32.3545046128

1 25.121 71.6531985192 1614564428 28.8378515376 veryfast, fast decode,
2 25.1764 71.4955275576 1614564428 28.8378515376

1 64.5419 27.888859795 1498560106 26.7658899872 fast, fast decode
2 65.5508 27.4596191046 1498560106 26.7658899872

1 122.4173 14.7038041192 1447822218 25.8596569152 slow, fast decode

1 35.8121 50.2623414991 2403039988 42.9208703048 Lagarith 1.3.27 64 bit MT


Attached: LibreOffice spreadsheet with the results.

[Ignus2]

Virtualdub 1.10.4 build 35491/release
Virtualdub 1.10.4 build 35491/release AMD64 (for Lagarith 64bit)
...

Great test setup!
Could you try with my codec (MagicYUV see other thread) too? I would be really interested in the results!

Greets,
I.

[mariush]

64bit, default settings (dynamic, 8 threads, etc) 57% cpu usage average, peak at about 73%

start= 00.2161 , end= 09.4468 => fps = 1800 / 9.2307 = 195fps . disk space = 2.550.902.864 (45.561%)

start= 34.5664 , end= 43.4776 => fps = 1800 / 8.9112 = 201.99 fps (note: virtualdub actually showed an average of 212 fps in the status window)

32bit

start= 33.0113 , end= 44.0937 => fps = 1800 / 11.0824 = 162.41 fps, same disk space , 60-65% cpu usage, peaked at about 70%

Congrats on your codec, looks like it's fast and does multithreading quite well.

[Ignus2]

...
Congrats on your codec, looks like it's fast and does multithreading quite well.

Very good benchmark, thanks for your time!

May I have another request? If you could update the previuos post and the spreadsheet I would be really grateful!
If you do that, may I link the post and put the spreadsheet on the codec website?

Greets,
I.

[Monarc]

FFV1?

FFV1 version 3 is multithreaded (slices) and much faster than the older versions.

e.g. with ffmpeg

ffmpeg ... -vcodec ffv1 -level 3 -slices 8 (with my 8 cores)

Don't know, if there is a windows codec with version 3.

[Atak_Snajpera]

Test has been completely re-done. This time I used untouched 1080p50 (500 frames) SVT samples (https://media.xiph.org/video/derf/)

[kolak]

FFV1?

FFV1 version 3 is multithreaded (slices) and much faster than the older versions.

e.g. with ffmpeg

ffmpeg ... -vcodec ffv1 -level 3 -slices 8 (with my 8 cores)

Don't know, if there is a windows codec with version 3.

Still relatively slow.

[mariush]

Atak, those results are... weird. What's the first fps value? Seems odd to be around 44-46fps for all.

Here's my results for three of the video files Atak used ( crowd, duck and house) ... didn't do all cause I got bored.
Same test environment as my previous test (see a few posts above).
I'd like to point out that x264 was the only encoder that seemed to need a few seconds to fully.. let's say "initialize", as the first seconds would encode at 60-70fps and then it would boost in the last two seconds up to 95-130fps.

So the results are somewhat bad because the test files are too small.

And no, there's no error for huffyuv 2.1.1 best, with the crowd file.. ran the encoding several times.


Time Framerate Size Ratio Encoder File size= 1552220212 Frames= 500

14.2609 35.061 1447603092 93.26 Huffyuv 1.3.1 crowd
7.5134 66.548 1495689676 96.358 Huffyuv 2.1.1 mt8 fast
6.2064 80.562 1617897636 104.231 Huffyuv 2.1.1 mt8 best
10.0995 49.507 984100698 63.4 Lagarith 1.3.27 32bit mt
3.2843 152.239 998136136 64.304 magicyuv mt8 adaptive 32bit
3.878 128.932 1029568428 66.329 Utvideo 13.3.1 ULH0 speed
3.9705 125.929 990327976 63.801 Utvideo 13.3.1 ULH0 compression
5.1709 96.695 989846256 63.77 h264 ultra
8.7 57.471 919711724 59.251 h264 veryfast
26.2519 19.046 908506014 58.529 h264 fast
9.9269 50.368 984100698 63.4 lagarith 1.3.27 64bit mt
2.5917 192.924 998136136 64.304 magicyuv mt8 adaptive 64bit


14.217 35.169 1316500516 84.814 Huffyuv 1.3.1 ducks
6.1249 81.634 1362752996 87.794 Huffyuv 2.1.1 mt8 fast
6.2285 80.276 1554037192 100.117 Huffyuv 2.1.1 mt8 best
10.0917 49.546 936055038 60.304 Lagarith 1.3.27 32bit mt
3.35 149.254 941611464 60.662 magicyuv mt8 adaptive 32bit
3.72 134.409 932428988 60.071 Utvideo 13.3.1 ULH0 speed
3.8224 130.808 941146936 60.632 Utvideo 13.3.1 ULH0 compression
5.1152 97.748 1064398802 68.573 h264 ultra
10.891 45.909 1055065568 67.971 h264 veryfast
34.2739 14.588 1040452052 67.03 h264 fast
9.6633 51.742 936055038 60.304 lagarith 1.3.27 64bit mt
2.8298 176.691 941611464 60.662 magicyuv mt8 adaptive 64bit


14.396 34.732 1225536172 78.954 Huffyuv 1.3.1 house
5.9479 84.063 1260616940 81.214 Huffyuv 2.1.1 mt8 fast
5.9591 83.905 1333923076 85.936 Huffyuv 2.1.1 mt8 best
9.5423 52.398 847042346 54.57 Lagarith 1.3.27 32bit mt
3.2188 155.337 864478600 55.693 magicyuv mt8 adaptive 32bit
3.76 132.979 887825816 57.197 Utvideo 13.3.1 ULH0 speed
3.7914 131.877 852803152 54.941 Utvideo 13.3.1 ULH0 compression
4.9312 101.395 915623498 58.988 h264 ultra
9.6589 51.766 886252756 57.096 h264 veryfast
33.622 14.871 871831758 56.167 h264 fast
9.1764 54.488 847042346 54.57 lagarith 1.3.27 64bit mt
2.5433 196.595 864478600 55.693 magicyuv mt8 adaptive 64bit

[Atak_Snajpera]

trust me i was repeating encoding in virtualdub many times. everytime i was getting the same fps. i don't know why you think it is weird that fps are the same.