MSU Lossless Codecs Comparison released

[DmitriyV2]

Last update in this month, I think:

MSU Lossless Codecs Comparison released!
http://compression.ru/video/codec_comparison/lossless_codecs_en.html

* Number of test sequences: 9
* Number of color spaces considered: 3
* Number of codecs tested: 15

Main results:

http://compression.ru/images/codec_comparison/gr_avgb_rgb.gif http://compression.ru/images/codec_comparison/gr_avgb_yuy2.gif http://compression.ru/images/codec_comparison/gr_avgb_yv12.gif

Detailed info:
http://compression.ru/video/codec_comparison/lossless_codecs_en.html

Enjoy! :)

[Tommy Carrot]

Snow
Couldn’t be tested. We would appreciate very much a functioning Windows version of
this codec.Snow is broken in the recent ffdshow builds, while it worked flawlessly a few months ago. Try this build (http://www.aziendeassociate.it/./cd//ffdshow/ffdshow-20050105.exe), hopefully it's old enough to work. :)

[DmitriyV2]

Snow is broken in the recent ffdshow builds, while it worked flawlessly a few months ago. Try this build (http://www.aziendeassociate.it/./cd//ffdshow/ffdshow-20050105.exe), hopefully it's old enough to work. :)
Thanks! We will add it to next comparison!

[Atamido]

Assuming you still have the original clips, why not add it to this comparison?

[DmitriyV2]

We use standard and new sequences as well and prefer standard sequences.

[TEB]

FYI:

Hi. Im eagerly looking at the dev of the lossless codecs nowadays. Did a test the other day.

http://forum.doom9.org/showthread.php?s=&threadid=90031

best regards teb

[akupenguin]

A few days ago (AFAIK not yet in CD's builds), ffdshow gained support for adaptive huffman tables in huffyuv. In my experience (I've been using it for a while in mencoder), this puts it near Lagarith's compression ratio in both YUY2 and YV12 without sacrificing any speed. (Using median prediction, of course.)

[TEB]

aku: Can u give me a pointer to where i can read about the changes in the ffdshow lossless codecs? Ive tried to read the cvs changes, but its hard to see if anything is happening that will benefit the lossless codecs themselves.
Whats the diff between the new ffhuffman and ffv1 these days? why have 2 lossless codecs that have the same goal?

[Tommy Carrot]

I think ffvhuff (or something like that) is faster (almost as fast as the original huffyuv, but with higher compression ratio), so you can use it for capturing even on slower computers, while ffv1 is more efficient.

BTW, ffv1 seems to losing ground against the latest motion-compensated lossless codecs (msu, snow), but if it could exploit the temporal similarities, like CorePNG (simply store the difference if it's more compressable than the actual frame), that would improve the efficiency on most material (especially on cartoons), and the speed penalty wouldn't be too big.

[akupenguin]

Originally posted by TEB
aku: Can u give me a pointer to where i can read about the changes in the ffdshow lossless codecs? Ive tried to read the cvs changes, but its hard to see if anything is happening that will benefit the lossless codecs themselves. They aren't documented anywhere, not even in the MPlayer manpage (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html) where such things usually are.

Whats the diff between the new ffhuffman and ffv1 these days? why have 2 lossless codecs that have the same goal? Internally: ffv1 uses arithmetic coding, and even in vlc mode it uses a context to select vlc table. ffvhuff uses the same vlc table for a whole frame.
Goals: ffv1 tries for good compression at the cost of speed, while ffvhuff tries to compress as well as possible while still being fast enough for realtime capture or the like.
I see that your test puts (old) ffhuffyuv and ffv1-vlc at the same speed. How did you measure speeds, and what format did you encode from? On my computer, ffvhuff encoding is about 3x faster than ffv1-vlc.

if it could exploit the temporal similarities, like CorePNG (simply store the difference if it's more compressable than the actual frame), that would improve the efficiency on most material (especially on cartoons), and the speed penalty wouldn't be too big. I have played with that, but never spent the time to make it really work. But I don't think CorePNG's whole-frame approach is the right way to go: better would be block-based or sample-based switching, even if we don't use motion compensation.

[DmitriyV2]

Originally posted by TEB
FYI: Hi. Im eagerly looking at the dev of the lossless codecs nowadays. Did a test the other day.
Thanks for link TEB!

[TEB]

Aku: It was basically a RGB24 avi file run through vdub with a different source and a different targetdrive.. I measured the speed just with the internal timer in vdub.. no idea how accurate it is but it gives a pretty good indication of the speed. U can check more of the info on my thread. Its definatly not io-bound. The cpu was maxed during the tests..
teb