Comparison of Lossless RGB Encoders

[jmac698]

Comparison of Lossless RGB Encoders
Final size only, avi container


Test of Lossless RGB Codecs

Size % Method
8,329,686,444 100.0% RGB24
3,534,123,063 42.4% zip [3]
3,362,925,852 40.4% huffyuv-best [4a]
2,708,965,860 32.5% UT-speed [1a]
2,441,065,124 29.3% UT-size [1b]
2,236,022,300 26.8% lagarith [5]
2,193,969,458 26.3% x264 lossless-fastdecode [6b]
1,938,767,482 23.3% x264 lossless [6a]
1,916,658,798 23.0% mlc-fast [7b]
1,882,066,820 22.6% ffv1-vlc-lrg [2a]
1,728,169,870 20.7% ffv1-ac-lrg [2b]
1,704,483,252 20.5% mlc-max [7a]

[1] UT Video Codec 10.2.4, x86, RGB
[a] Optimize for decoding speed (Predict Left) checked
Assume interlace video not checked
[b] Optimize for compression ratio (Predict median) checked
Assume interlace video not checked

[2] ffdshow tryouts rev3996, x86, RGB32
[a] Coder type: VLC, Context Model: Large, Keyframes distance: 10
[b] Coder type: AC, Context Model: Large, Keyframes distance: 10

[3] 7-Zip, x86, 9.20, preset zip ultra, method deflate (this took a very long time)

[4] HuffyUV, 2.1.1, x86, RGB
[a] Predict gradient (best)
*The result was reduced to YUY2, so it's not lossless. I'm still investigating whether this codec can do RGB.

[5] Lagarith, 1.3.27, x86, RGB, multithread checked
*There are ancedotal reports that this is an atypical result compared to Huffyuv. It's usually better.

[6] x264vfw 33968, virtualdub hack checked
[a] tune: animation, bitrate: lossless, keep original colorspace: checked, quality: very slow
Mediainfo reports: AVC High 4:4:4 Predictive@L5.1, CABAC, Ref16, 347Mbps
[b] tune: none, bitrate: lossless, keep original colorspace: checked, quality: very slow, fast decode checked

[7] MLC 1.1
[a] Compression (predefined): Maximum compression
Only keyframes: not checked
Motion Estimation: checked, Slow
Mode: Maximize compression
Use multithreading: checked

[b] Compression (predefined): Fastest


Source: cgi, rgb24, 1080p, 30fps, 1339 frames, 45s
The video is colorful, with simple texture details, and consists of 3d swooping and flying to watch various aspects of an imaginary, cartoonish assembly line.

[Atak_Snajpera]

add lagarith and plain huffyuv

[jmac698]

ok, updated

[Dark Shikari]

Add x264, and maybe 7zip with a large dictionary (like 256MB+, if your RAM can handle it) on Ultra?

[Atak_Snajpera]

once we have all results we should also compare decoding speed but you would need ssd to avoid bottleneck

[Leeloo Minaï]

once we have all results we should also compare decoding speed but you would need ssd to avoid bottleneck

Or better : a RAM disk.

[jmac698]

Ok, but it's not looking good...

[jmac698]

well it's done, that took an hour!! on my pathetic machine.. for 44 seconds. I don't think you'd want me to benchmark this machine, though it would show some kind of relative difference. The rest except zip took 10 minutes.

As for 7z, my biggest dictionary size available is 64mb, and it's compressing around 50% right now.
PPMd with 512MB dictionary size seems to be about the same in a short run. The compression started dropping like a rock once it got past 512MB compressed. My guess is it'd be comparable to zip.

[smok3]

thanks, how would a "ffv1-ac-lrg [2b]" ffmpeg command line looks like?

[Groucho2004]

PPMd with 512MB dictionary size seems to be about the same in a short run. The compression started dropping like a rock once it got past 512MB compressed. My guess is it'd be comparable to zip.

PPMd is very good for text compression. I doubt that it's good for this purpose. You should try "normal" lzma or lzma2:
-t7z -m0=lzma -mx=7

Winrar might also be worth a try but it's not free.

[jmac698]

I tried lzma2 in 7z, results were comparable to zip, it was starting at around 50%.
All the methods (bzip2, lzma2, ppmd) are about the same here.

[Firebird]

Try x264 without --tune animation and with --tune fastdecode please.

[jmac698]

Hmm..
ffmpeg -i infile.avi -vcodec ffv1 -pix_fmt rgb24 out.avi
Something like that

-fastcode is gonna end up just bigger than lagarith.

[detmek]

--fastdecode disables CABAC so it will increase file size. Why --tune animation? None of tune animation settings are used for lossless. No deblock, no bframes, no psy, ref is already 16...

[jmac698]

I have next to no experience in x264, don't have much use for it.

Not much call for it?? Why, it's the single most popular cheese in the world!

[akupenguin]

How can huffyuv possibly beat ffv1-vlc? Huffyuv is strictly worse in every way: Nonadaptive huffman tables, no context model, gradient rather than median, ...

[Sparktank]

There is a more updated version of UTV than the one you used.
Ut Video Codec Suite 11.1.1 (http://www.videohelp.com/tools/Ut-Video-Codec-Suite)

Version history:
Version 11.1.1
Bug fixes
(Windows) Size (number of bytes) of frame may not be set correctly when encoding and decoding.

Version 11.1.0
Performance Improvements
(Mac) Add assembly language version of colorspace conversion routine from RGB to ULY2.
Common: Speed up decoding a little.
Common: Speed up encoding on x64 about 10%
Others
(Mac) encoded size becomes a little smaller by omitting unnecessary media sample flags.

Version 11.0.0
New features
Add QuickTime encoder components for Mac OS X. Encoding from RGB24/ARGB32 are supported. ULY2 is not very fast.
Bug fixes
ULY2: QuickTime decoder may output corrupted data in case of certain width of video and output buffer.

Version 10.2.4
Others
(Windows) Installer now displays "before-install" notice.
(Mac) Report more apropreate codec name to QuickTime.


I did a quick test on several lossless codec compressions a couple months ago.
Didn't do a complete test or logging, but generally found the results to be the same, as far as compression goes.
Speed for each compression... have not paid attention to.
Also didn't do any -tuning or controlled settings for x264 or other codecs.

Found UtVC to be quite pleasing and still prefer it to this day for most of my lossless work.

[MiroLx]

You can also try MLC if speed is not important. Version 1.2 is available.

[jmac698]

MLC is not looking good at all
--
Well, it just might redeem itself in the end.

That took me 90 minutes, x264 took 60 minutes, and the zips took 3 hours, so it's the slowest codec.

[MiroLx]

MLC is not looking good at all
--
Well, it just might redeem itself in the end.

That took me 90 minutes, x264 took 60 minutes, and the zips took 3 hours, so it's the slowest codec.

OK. May I ask which setting you used, since codec speed is very different in different modes (not so much compression ratio). Highest compression mode is very slow. Also disabling Motion Estimation can speed up compression...

[K.i.N.G]

Why encode in 32bit RGB?

Also add 24bit RGB pls, which is what most ppl will/should use (except those who think more bits is always better).
32bit is only if you have an alpha channel.

*edit: hm, it appears you cant choose 24bit in some, and thus are 'forced' to use 32bit, which is a bit strange imho.
Is 4:4:4 lossless?

[jmac698]

Lossless doesn't refer to a colorspace, but if you converted to 4:4:4 which is a YUV colorspace, there would be a loss from 8-bit RGB.

Depending on the algorithm, perhaps 32bit is a natural word-size. It's usually faster to deal with this size in code then breaking it down.

Impressive, MLC fast only took 3:26, and the compression is pretty good, Probably the high motion search is what slowed down my first test.

Possibly you were confused by references to 32bit, I changed that to x86. (Still, some codecs have colorspace restrictions)

All settings are listed at the bottom.

[AVIL]

Hi jmac698,

Can you test two codecs more?

YULS:http://www.yuvsoft.com/2d-technologies/lossless-video-codec/

Download: http://www.yuvsoft.com/downloads/download/lossless-codec/YUVsoft-ls-codec.zip

YLC:http://spring-fragrance.mints.ne.jp/aviutl/

PS: I don't understand japanese, but is possible that ylc makes internal conversion RGB<->YUY2. Then it can't compress losslessly RGB native videos

Download: http://spring-fragrance.mints.ne.jp/aviutl/ylc.zip

Thanks in advance

[lulalala]

I am really amazed by lagarith. I thought it has no P-frame. Yet it is merely below x264. How can that be?

[Dark Shikari]

Lagarith is basically like HuffYUV except using an arithmetic coder instead of a range coder (a constant set of probabilities specified in each frame header).

I wouldn't trust the results in this thread, since Lagarith losing to HuffYUV should probably not happen.

[jmac698]

Hi,
I understand your skepticism; I can offer one explanation. I have found that some codecs would not let me select 24bit rgb in the colorspace, so if they are really compressing 32bit, then it's not a fair comparison. However, if there's no other selection, then that's really all that can be done.

I still have the files; perhaps I can arrange for you to test it yourself?

[poisondeathray]

But lagarith can do RGB or RGBA, that doesn't explain the results unless you inadvertently used RGBA

ffv1 can do RGB if you use ffmpeg - is that the one you're referring to? ffv1 through ffdshow ?

[Dark Shikari]

RGBA probably won't use significantly more bits than RGB if the video is actually RGB -- the alpha channel will just be empty and cost very few bits.

[jmac698]

Of course that's a reasonable speculation. I could redo the tests then and see what happens. It might even be a typo error.

[smok3]

ut, huff, fv1, x264 can all be in ffmpeg, perhaps an interesting script that would measure speed/compression ratio/video md5ness is something to work on?

p.s. perhaps this https://gist.github.com/3291078 could be a start.

[jmac698]

There can be no doubt about huffyuv:

General
Complete name : F:\lossless compression test\factory-huff-best.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.72 GiB
Duration : 44s 633ms
Overall bit rate : 331 Mbps
Writing library : VirtualDub build 34703/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 44s 633ms
Bit rate : 331 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 5.322
Stream size : 1.72 GiB (100%)

[jmac698]

There's no doubt: I have two short clips, where huffyuv is better than lagarith:

General
Complete name : F:\lossless compression test\huffyuv.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 5.05 MiB
Duration : 100ms
Overall bit rate : 423 Mbps
Writing library : VirtualDub build 34703/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 100ms
Bit rate : 423 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 6.796
Stream size : 5.04 MiB (100%)


and

General
Complete name : F:\lossless compression test\lag.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 6.78 MiB
Duration : 100ms
Overall bit rate : 568 Mbps
Writing library : VirtualDub build 34703/release

Video
ID : 0
Format : Lagarith
Codec ID : LAGS
Duration : 100ms
Bit rate : 568 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 9.127
Stream size : 6.77 MiB (100%)

[poisondeathray]

These results are unexpected. Did you verify the colorspace (e.g. in ffmpeg) ? As mediainfo isn't necessarily reliable in these things. Was it "real" RGB material ?

Could it be something peculiar about your sample ? Maybe it was too small ?I've tested RGB in the past, and Huffyuv never beats Lagarith (not even close) .

I just did a quick RGB test as well

FFV1 332MB (AC, large, 10)
HYFU 507MB
HYMT 507MB
LAGS 383MB

[Dark Shikari]

"There's no doubt"? Have you tried, for example, hashing the decoded output to ensure it's identical? Certainly doubt could persist at least until that's confirmed.

Furthermore, does this video have duplicate frames? If you're encoding with two different programs, one might be using AVI null frames and the other not, for example.

[jmac698]

You can see in the mediainfo output that the writing application was the same. I tested the output visually with subtract or some such thing. I'll update the test results to indicate that it's believed to be an atypical result.

Anyhow, test yourself:

huffyuv.avi (5.05MB)
http://www.sendspace.com/file/u1j4de

lag.avi (6.78MB)
http://www.sendspace.com/file/esucz1

[poisondeathray]

You can see in the mediainfo output that the writing application was the same. I tested the output visually with subtract or some such thing. I'll update the test results to indicate that it's believed to be an atypical result.

Anyhow, test yourself:

huffyuv.avi (5.05MB)
http://www.sendspace.com/file/u1j4de

lag.avi (6.78MB)
http://www.sendspace.com/file/esucz1


your huffyuv sample is YUY2, your lag sample is RGB24 , confirmed by ffmpeg, and avisynth info() using AVISource - although info() reports lag is RGB32

[Dark Shikari]

That HuffYUV video is in YUV 4:2:2, not RGB. It's not surprising that it's smaller; it's also not lossless.

[jmac698]

YULS and YLC:
YLC says it's restricted to 1024xs768, and YULS is YUY2. They can't be tested for lossless RGB. They would belong in a separate test of YUV codecs.
Anyhow, YULS estimated 2.1GB, but that's not comparable.

[jmac698]

Thanks for investigating that; does huffyuv support RGB at all?
I also need to double-check my comparison technique; I agree that only a hash would be reliable, but all I know for that is to decompress to a common codec and hash that. It there a program which can let me do a decoding hash on the fly?
What tool can you use to see what the native decompression format is? It seems possible that any codec could lie and try to do a color conversion.

[poisondeathray]

Thanks for investigating that; does huffyuv support RGB at all?


Yes it does

For comparing - I usually check with ffmpeg and double check with an amplified difference subtract script in avisynth . If there is even a minute difference it will be visible right away on the 1st frame

[Dark Shikari]

Thanks for investigating that; does huffyuv support RGB at all?
I also need to double-check my comparison technique; I agree that only a hash would be reliable, but all I know for that is to decompress to a common codec and hash that. It there a program which can let me do a decoding hash on the fly?
Maybe something like:

ffmpeg -i input -f rawvideo -pix_fmt rgb24 - | md5sum

[IanB]

Thanks for investigating that; does huffyuv support RGB at all?
...
It seems possible that any codec could lie and try to do a color conversion.
Huffyuv is fully configurable. When fed with RGB data the RGB compression methods are 1. Predict left/No decorr. (fastest), 2. Predict left, 3. Predict gradient (best) and 4. <- Convert to YUY2, which defers to the configured YUY2 compression method.

There is also the "Always suggest RGB format for output" option which will force conversion from a YUY2 compression to an RGB output.

Looks like your test had "<- Convert to YUY2" configured.
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv-config.png

[jmac698]

I don't know how I managed to do that; I did it twice and it's a simple procedure. Anyhow, I ran it again and got this:

General
Complete name : F:\lossless compression test\huffyuv2.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 3.13 GiB
Duration : 44s 633ms
Overall bit rate : 603 Mbps
Writing library : VirtualDub build 34807/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 44s 633ms
Bit rate : 603 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 9.689
Stream size : 3.13 GiB (100%)


It's now one of the worst. Could leaving virtualdub at full processing affect this? The default is best, you would have to go out of your way to select YUY2. I can't imagine what happened.

[Dark Shikari]

Huffyuv should be one of the worst; it is nearly the fastest and simplest possible lossless video format.