Lossless codec which exploits temporal redundancy?

[OUTPinged_]

I seem to be unable to find one.

Why these aren't common? Is lossless compression with delta so much more complex to implement? Maybe it wouldn't be that more efficient than current lossless codecs are? Any guys with videocoding theory knowledge around? ;-)

Using huffy as lossless codec is sufficient, but the amount of disk space it takes with full resolution is depressing.

[MfA]

I think noone simply has bothered to code one yet as far as open source is concerned. You are not missing that much though, the state of the art lossless spatiotemporal compressors only manage to eek out an extra 10-20% savings (at least the ones described in literature, you will find a lot of companies claiming they can do better ... but that is hard to substantiate). That is compared to state of the art lossless image compressors applied to each frame, so maybe compared to huffyuv you might be able to get a 30% savings ... but 70% of a huge file is still a huge file.

[Aktan]

Every little bit counts :D

[Malcolm]

It shouldn't be too complicated to test this.
If you apply
subtract(clip, clip.Trim(1,0))
to your video, then you should get the difference from one frame to the next (or previous). You can then encode the output of this script with huffy, and voilà there you have your temporal lossless encode!

If you do
subtract(clip.Trim(1,0), clip)
to the encoded video, then you should get your original Video back.
I hope, this is correct!

You can compare the size of the normally encoded video an the size of the video encoded like this.

bye,
Malcolm

P.S. Of course, this is only a trick. You won't be able to fast forward in your video, because you don't have 'Intra-frames' from where you can reconstruct your actual picture.

[Acaila]

Lossless codec which exploits temporal redundancy?That was my intended project for the summer holidays, so don't hold your breath, it may take a while :). Especially since I've never done it before...

Coding P frames shouldn't be too hard compared to the rest of the codec, but without motion estimation those P frames will be very inefficient. And good/fast motion estimation on the other hand IS complicated.

[OUTPinged_]

@Acaila

And good/fast motion estimation on the other hand IS complicated.

What about stealing one from xvid dudes?

[Acaila]

Always a possibility, but when I make a codec I do it because I want to learn from it. So using someone else's finished code would not be something I would be willing to do.

[mf]

Gldm's WARP lossless wavelet codec is mostly temporal. The savings he's got so far are near to DVD bitrate, but the process isn't entirely lossless. That, and he has other things on his mind at the moment, so he can't really go on with it now.

[MfA]

The funny thing about lossless coding, the last few bits come the hardest.

[morsa]

Why don't you join efforts with the other guys in this forum to make a lossless codec and start a GPL project?
May be Sourceforge or Corecodec.

[trbarry]

And good/fast motion estimation on the other hand IS complicated.

But I noticed that, at least for deinterlacing, the best bang for the buck seems to be for catching zero or very slow motion instead of trying to catch fast motion compensating from a long ways off. There is sort of a diminishing return as you search more and more.

It would be very fast to just calc from the previous unmoved macro block or pixel from the previous frame. I wonder how much that would help compression? Or is that already done in HuffYUV, etc?

- Tom

[MfA]

The easier your search gets trapped in local minima the less sense it makes to have a long search range ...

[mf]

Originally posted by MfA
The funny thing about lossless coding, the last few bits come the hardest.
Actually the problem was his transform being floating point, which can't guarantee losslessness.

[MfA]

Thats not what I mean, I just meant that whatever he has now gives no guarantuee at good performance when he tries to make it truely lossless.

Also the problem I thought was a rather questionable way of scaling coefficients rather than floating point. He pre-scaled values and used division in the averaging filter in his haar wavelet transform step, which AFAICS will result in a lot of poorly predictable under/overflow situations, just using standard pixel values and forgetting about the division and simply growing the dynamic range at each filtering step of the haar wavelet transform would have let him do lossless coding (you can not get underflow, and you know exactly how many transform steps you can do before overflow can occur ... you can switch to higher precision arithmetic if needed when you get there, but with 16 bit arithmetic you can have 8 decomposition levels so I doubt you would need to).