Lossless video codecs

[hoboX10]

I recently found this lossless video codec called MSU and it appears to be better than a lot of other lossless codecs. However, the last update was from September 2005.

I also found another lessless video codec called YULS but it's maximum video resolution is 1024 x 768.

Is there any custom builds, or better alternate lossless codecs I can use? Both are supposed to be better than CorePNG, FFV1, and Lagarith. Apparently, those two are the top 2 lossless codecs out, but MSU has problems running with VirtualDub and YULS has that resolution limit.

Also, what do you guys think of this: http://www.h265.net/

[SeeMoreDigital]

Have you taken a look at the lossless versions of MPEG-4 AVC (H.264)?

[Midzuki]

Two more codecs: Camstudio (uses GZIP compression) and LJPG.

[LoRd_MuldeR]

Try FFV1, it provides even better compression than x264 lossless in my tests

Compression of HuffYUV and lossless JPEG are significant worse than FFV1. The MSU codec is unbelievable slow, but the compression doesn't justify that speed at all!

Here are some results for the "Soccer" sample clip:

FFV1 100%, x264 105%, Lagarith 107%, LJPG 142%, HuffYUV 160%, MSU 198%

(Still wonder why x264 compresses worse than FFV1, because both use CABAC, but x264 has inter-frame prediction while FFV1 doesn't)

[MatLz]

Huffyuv.

[MiroLx]

You can also try MLC codec, at least it hasn't limit for resolution.

[SeeMoreDigital]

Originally Posted by LoRd_MuldeR

Try FFV1, it provides even better compression than x264 lossless in my tests

How about the "H.264 Lossless" encoder that comes with FFDshow?

[Dark Shikari]

Originally Posted by SeeMoreDigital

How about the "H.264 Lossless" encoder that comes with FFDshow?

That's the same thing...

[LoRd_MuldeR]

Originally Posted by Dark Shikari

That's the same thing...

Can you explain why FFV1 compresses slightly better than x264 in "lossless" mode? At least with the samples I tested (real-life footage, uncompressed YUV source).

As far as I know, FFV1 uses the CABAC entropy coder taken from the H.264 standard, but in contrast to x264 it doesn't do any inter-frame prediction or motion compensation.

So shouldn't x264 compress better in theory?

[Dark Shikari]

Originally Posted by LoRd_MuldeR

Can you explain why FFV1 compresses slightly better than x264 in "lossless" mode? At least with the samples I tested (real-life footage, uncompressed YUV source).

As far as I know, FFV1 uses the CABAC entropy coder taken from the H.264 standard, but in contrast to x264 it doesn't do any inter-frame prediction or motion compensation.

So shouldn't x264 compress better in theory?

No it shouldn't, because you're wrong.

FFV1 uses a completely different range coder than H.264, but that's not the reason; the reason FFV1 has better intra compression is because it uses median filtering and because its context model is utterly absurd (over one million contexts as compared to H.264's ~450). H.264's lossless coding is basically slapped on after-the-fact and is not very good compression-wise, at least not compared to what it could be.

On any source where inter compression is reasonably useful, x264 will beat FFV1.

[SeeMoreDigital]

Hmmm...

Using the same 50 second 720x576 MPEG-2 source, I generated lossless 720x576 encodes with x264 and FFV1. They came out at 100MB and 170MB respectively.

[LoRd_MuldeR]

Originally Posted by SeeMoreDigital

Hmmm...

Using the same 50 second 720x576 MPEG-2 source, I generated lossless 720x576 encodes with x264 and FFV1. They came out at 100MB and 170MB respectively.

Probably because you were re-encoding from a pre-compressed (lossy) source clip?

Try one of these maybe:
* http://media.xiph.org/video/derf/y4m/soccer_4cif.y4m
* http://media.xiph.org/video/derf/y4m...arkrun_ter.y4m

Originally Posted by Dark Shikari

No it shouldn't, because you're wrong. FFV1 uses a completely different range coder than H.264

Well, I don't completely understand all the details, but the FFV1 technical docs clearly say:

3.6.1 Arithmetic coding mode

Context Adaptive Binary Arithmetic Coding (CABAC)

The coder is borrowed from H.264 and the reader is referred to that for further information, it is also noted that the author doesn't know if the coder is patented, so care must be taken if FFV1 is used in countries where software patents are legal. But even if CABAC turns out to be patent free there is still some risk that other parts of FFV1 are covered by patents. By just looking at the very long list of patents which cover other relatively simple standards it is shown that the patent offices seem to pass nearly everything. In many cases the patents cover basic operations like subtraction or taking the median of 3 integers in a specific case like motion vectors.

[akupenguin]

Originally Posted by Dark Shikari

the reason FFV1 has better intra compression is because it uses median filtering and because its context model is utterly absurd (over one million contexts

173949 = (11*11*5*5*5+1)/2 symbol-contexts * 23 bit-contexts (assuming 8bit samples)

as compared to H.264's ~450).

And a bunch of those are for interlaced. So the number that counts is about 310.

Originally Posted by LoRd_MuldeR

Well, I don't completely understand all the details, but the FFV1 technical docs clearly say:

That was true when it was written 5 years ago.

[SeeMoreDigital]

Originally Posted by LoRd_MuldeR

Probably because you were re-encoding from a pre-compressed (lossy) source clip?

Just performed another test. This time I converted the 720x576 MPEG-2 source to uncompressed RGB32 (1.47GB) and used this as the source.

Same result... x264 came out at 100MB and FFV1 came out at 170MB

[LoRd_MuldeR]

Originally Posted by SeeMoreDigital

Just performed another test. This time I converted the 720x576 MPEG-2 source to uncompressed RGB32 (1.47GB) and used this as the source.

Same result... x264 came out at 100MB and FFV1 came out at 170MB

Well, maybe the kind of information/detail that would be costly (bit-wise) for x264 are already gone for good in the lossy MPEG-2 source.

Try one of the lossless/uncompessed sources I pointed to in my previous post. Going from lossy (e.g. MPEG-2) to lossless is kind of useless anyway

[Dark Shikari]

Originally Posted by akupenguin

173949 = (11*11*5*5*5+1)/2 symbol-contexts * 23 bit-contexts (assuming 8bit samples)

Ah, seems I had a bit of off-by-a-zero there. Still of course an absurd number.

[hoboX10]

Lol epic thread hijack. ^_^ Just kidding, I'm learning a little, here and there, in this conversation.

Anyway... I take it there's no custom/alternate Lossless codecs here that you wouldn't find quickly on google? ._.

[nm]

Well, there are the japanese Ut and AMV codecs.

[mark0077]

Enjoyed reading this thread but when trying to encode a 1024 x 768 60fps clip from premiere to many lossless codecs I run into trouble.

Using ffv1 in avi, the exported clip plays the first 5 seconds and then crashes.
Using lossless jpeg in avi, the exported clip initially comes up as pure grey image, then shows a streaking effect and crashes.
Using H264 losslessin avi, the exported clip plays fine the whole way through, but its suspiciously small, and shows horrible video corruption the whole way through.

I am exporting a 60fps 1024 x 768 clip which exports fine completely uncompressed (not using ffdshow encoder).

My aim is to get my clip approx 30% smaller than the uncompressed lossless version so that my hdd can keep up with the clip, 4ghz core i7 should be enough I hope to decode this on the fly.

I am using ffdshow and mpc versions released a few days ago, 3060 and 1245. h264 lossless is the only one that I can actually see some output, although its badly garbled.

The charity event I will be playing the clip at is on the 19th of Sept, hoping someone can help me out before that.

[Dark Shikari]

Originally Posted by mark0077

Using H264 losslessin avi, the exported clip plays fine the whole way through, but its suspiciously small, and shows horrible video corruption the whole way through.

Have you checked that your decoder supports H.264 lossless properly? FFDshow has only supported it since roughly this past January.

Originally Posted by mark0077

My aim is to get my clip approx 30% smaller than the uncompressed lossless version so that my hdd can keep up with the clip, 4ghz core i7 should be enough I hope to decode this on the fly.

x264 --tune fastdecode --qp 0 should compress well enough.