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

Atak_Snajpera · 25th August 2012, 13:41

Code:

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 · 25th August 2012, 13:44

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 · 25th August 2012, 13:54

I used AVSMeter with following scripts

Code:

DirectShowSource("")

or

Code:

AviSource("")

or

Code:

RawSource("")

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

Dark Shikari · 25th August 2012, 14:03

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 · 25th August 2012, 14:06

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

Quote:

"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.

Quote:

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 · 25th August 2012, 17:41

Quote:

Originally Posted by Atak_Snajpera

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 · 25th August 2012, 19:12

Quote:

Originally Posted by Atak_Snajpera

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 · 25th August 2012, 19:21

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

poisondeathray · 25th August 2012, 20:04

Quote:

Originally Posted by Atak_Snajpera

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 · 7th September 2012, 15:26

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 · 13th February 2014, 18:22

ADDED: MagicYUV 0.9 results

Ignus2 · 13th February 2014, 21:47

Quote:

Originally Posted by Atak_Snajpera

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 · 14th February 2014, 15:12

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

benwaggoner · 14th February 2014, 18:22

Quote:

Originally Posted by Atak_Snajpera

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

Are you using 64-bit VDub?

Atak_Snajpera · 14th February 2014, 19:07

All tests in 32bit only

Procrastinating · 15th February 2014, 05:18

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 · 15th February 2014, 09:48

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.

Code:

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 · 15th February 2014, 10:45

Quote:

Originally Posted by mariush

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 · 15th February 2014, 11:16

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 · 15th February 2014, 13:09

Quote:

Originally Posted by mariush

...
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.

25th August 2012, 13:44	#2 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	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. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10 Last edited by Dark Shikari; 25th August 2012 at 13:50.

25th August 2012, 13:54	#3 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,815	I used AVSMeter with following scripts Code: DirectShowSource("") or Code: AviSource("") or Code: RawSource("") FFDshow was used as HuffYUV and FFv1 encoder and decoder. Encoding speed taken from virtualdub. __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 25th August 2012 at 13:57.

25th August 2012, 14:03	#4 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	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. __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10 Last edited by Dark Shikari; 25th August 2012 at 14:07.

25th August 2012, 19:21	#8 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,815	does your huffyuv mt support yv12? mine supported only yuy2. also size was odd 709mb so i didn't include in test. __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 25th August 2012 at 19:24.

13th February 2014, 18:22	#11 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,815	ADDED: MagicYUV 0.9 results __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper Last edited by Atak_Snajpera; 13th February 2014 at 18:41.

7th September 2012, 15:26	#10 \| Link
yukkuri Registered User Join Date: Sep 2012 Posts: 1	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

14th February 2014, 15:12	#13 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,815	Updated tests with latest UT Video and using Fast Recompress option in VirtualDub __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper

14th February 2014, 19:07	#15 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,815	All tests in 32bit only __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper

15th February 2014, 05:18	#16 \| Link
Procrastinating Registered User Join Date: Aug 2013 Posts: 71	Is there any particular reason why slower x264 presets are not used? Those with particularly powerful machines might want to archive video, for example.

15th February 2014, 11:16	#19 \| Link
mariush Registered User Join Date: Dec 2008 Posts: 589	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.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode