Lossless Video Encoder

[adammouse]

Im capturing from VHS to my hard drive via an ATI All in Wonder (UVUY) and was wondering whats the "best" encoder to use. Huffyuv doesn't seem to compress as much as Id like. are there any new or updated codecs out there?

[mod]

Hi. Try http://lags.leetcode.net/codec.html , works really good

[AVIL]

Hi,

I use arithyuv and I'm happy with it.

See:http://forum.doom9.org/showthread.php?t=98042

Good luck

[Poutnik]

I think arithyuv is intended primarily as capture codec, tune d for speed.
Lagarith is great, but intention is AFAIK as general use lossless codec,
e.g. for intermediate files. It is slower than arithyuv, which is much slower than huffyuv.
BUT AFAIK at least lagarith ( not sure about arithyuv) can support more processors,
huffyuv cannot - so speed can differ on modern PC ( not mine ).

[mg262]

Don't ask what is best, because you will get in trouble for it.
Other lossless codecs are FFV1 (comes with ffdshow), vble, loco, and (if I remember correctly) a particular mode of x264 called qp=0. If you search for these, you will find speed and compression comparisons; most of the codecs I've listed are too slow for real-time capturing, but very useful for compressing your capture after it is done.

[AVIL]

Hi again,

It's true that speak of the best think is nosense. Is better speak of suitable. Alas, this is a personal concept that anyone obtains by trial and error (or any other system of learning).

Another choice. When size matters and time is less important I use MSU lossless codec:

http://www.compression.ru/video/ls-codec/index_en.html

If you compare you can decide.

[Poutnik]

MSU is, when I tried, is excellent in compression, but very slow,
significantly slower than Lagarith or Arithyuv.
I would never recommend it for captures but very fast PC.

[mg262]

As for MSU -- be sceptical about proprietary comparisons. It's been a while since I tested these things, but IIRC I tried an old version and it was not up to FFV1. Avoid the AlparySoft one like the plague -- the 'lossless' version I tried was actually lossy.

[gaekwad2]

I think arithyuv is intended primarily as capture codec, tune d for speed.
Lagarith is great, but intention is AFAIK as general use lossless codec,
e.g. for intermediate files. It is slower than arithyuv, which is much slower than huffyuv.
BUT AFAIK at least lagarith ( not sure about arithyuv) can support more processors,
huffyuv cannot - so speed can differ on modern PC ( not mine ).
Lagarith is almost fast enough for me (roughly 1 dropped frame every 10 seconds, P4/2.6). Anyone with a faster CPU should be able to use it for capturing.

[mg262]

Lagarith is almost fast enough for me (roughly 1 dropped frame every 10 seconds, P4/2.6). Anyone with a faster CPU should be able to use it for capturing.Careful with that thought. You want to leave considerable leeway as you may get CPU usage spikes due to Windows or background processes.

[Poutnik]

.......Avoid the AlparySoft one like the plague -- the 'lossless' version I tried was actually lossy.
Are you sure you have used lossless settings of Alparysoft ?

I have tried it in the past, there are 6 lossless and 6 lossy settings,
lossy is default, I think.

It has option for capture to yv12.
Realtime lossless with prediction was probably slightly faster then Arithyuv.

I did not do any numerical confirmation of losslessness,
but did not visually realized any picture changes.....

I did not use it because it seem to me unstable,
but was claimed as beta ( maybe still is )

[mg262]

I was running a compression test on every lossless encoder I could find, and I made a point of decompressing and checking losslessness numerically. AlparySoft (alone) was definitely not lossless; I checked the settings and repeated the test to check that. It may well have been visually identical to the original, but when I use a lossless codec I want genuine losslessness.

This was some time back... it might well not be an issue now, but frankly I don't see any way of being sure without decompressing every file you try.

[Poutnik]

Ok, you have convinced me.

[Chainmax]

I found something that doesn't seem quite right in ArithYUV's readme:

* Check output: Once compressed, the frame is immediately decompressed and compared to the original frame. A breakpoint exception occurred if frames are different.

If the codec is lossless, then how could the compressed-then-decompressed frame be different from the original?


Other than that, this codec sounds great. I am currently trying to make an intermediary lossless file that will be fed to CCE, and neither FFV1 nor HuffYUV in YV12 mode with adaptive tables would give me enough headroom to use the computer, even when setting VDubMod to idle priority. I only wish it supported YV12 input and output: with only 15GB left on my HDD, it doesn't seem I'll be able to make the MPEG2 without uninstalling important stuff :(.

[mg262]

If the codec is lossless, then how could the compressed-then-decompressed frame be different from the original?Only if there's a bug. This looks like a debugging/testing-aid for the program...

[Poutnik]

I performed a small test to alparysoft lossless codec with VDub.

1) first I have encoded 250 frames of video by Helix codec ( uncompressed YV12 ) - clip A
2) Then I have encoded it by Alparysoft ( lossless, realtime, prediction, SSE,
force to YV12) - clip B ( 1/3 size to uncompresed )
3) Then I have encoded it back by Helix to uncompresses - clip C
4) clips A and C are BINARY IDENTICAL.

Note that if codec is not free registered, it puts small logo into clips...

[mg262]

Note that if codec is not free registered, it puts small logo into clips...D'oh... that could well have been the cause. I was testing all the encoders from CLI and I have no memory of whether I inspected that clip visually or not (it was over a year ago), and that means I probably didn't. Stupid oversight, but at the time it didn't occur to me to think of logos. Sorry about that!

[BilboFett]

I tried huffyuv, which is solid, but it doesn't compress very much. MSU seemed to eat up too much of my CPU. Lagarith seemed just right; compression and CPU usage. Here's a link:

http://lags.leetcode.net/codec.html