New lossless video codec

[JanKafka]

Hello. I'm implementing a lossless video codec as a part of my bachelor's thesis. It uses simple 3D interframe predictor derived form 2D MED and Golomb. Rice or arithmetic coder to encode prediction errors. It can bring improvement of compression ratio in videos, where are little differencies between frames (for example - camera is static, one object is moving, background is identical). In dynamic videos, compression ratio is mostly between FFV1 and Lagarith.
For example, video Big Buck Bunny:

resolution: 1280x720 px
framrate: 24 fps
format: RGB24 uncompressed
duration: 9min 57s
size: 38 658 315 kB

After compression:

Lagarith: 10 462 689 kB
FFV1: 9 220 399 kB
my codec: 7 416 067 kB


Compression ratio could be further improved by error correction using context, like in JPEG-LS.
At this time, codec work in VfW. I will also code envelope for DirectShow and FFmpeg. Compressed data are stored in AVI container.
My question is for people, who use lossless video compression: could you benefit from this? Does your video material contain static scenes, which could be predicted interframe? I just want to know, if my work has any sense.

Thank you

[Cornucopia]

I'm glad you have got something going and all, and think that's probably a good choice for a thesis, but I have to ask: are you bringing something new to the table or are you reinventing the wheel?
Off the top of my head, I can think of ~7 lossless codecs (HuffYUV, Lagarith, UT Video, MagicYUV, MSUlossless, FFV1, QT Animation100%) already out there and I'm sure there are others. They all have good features and are often interchangeable/replaceable in a workflow even though they are not identical. They vary in compression ratio (usually between ~2:1 and ~4.5:1), but this is highly dependent upon the match of the algorithm with the specific material. They also vary in complexity ( and encode/decode speed/CPU utilization).

Ideas/questions:
How does yours compare, speedwise?
Is yours a symmetrical process (encode vs. decode time)?
Is yours easily scalable for multiple layering in NLEs?
Are you accommodating newer features (4k+, multiple sampling schemes, higher bitdepth/hdr/wide gamut, alpha channel, stereoscopic/multichannel, parametric metadata, raw, plenoptics)?
I would think that a codec that is both versatile in features and is widely supported (due to multiple platforms/architectures) would have a stronger draw; are you thinking of including QT/Macs as well? Multiple containers (incl. MKV, maybe MXF, MOV)?
Do you have a GUI or is it CLI, or API, or a mix?
Do you have an algorithm for lossless interframe that is much better size/performance-wise than just intraframe? (I have some ideas in that area) - note that interframe will likely remove the editing benefit of lossless.

Can you post links to alpha/beta versions?
Is this closed source, FOSS?...

Scott

[jagabo]

A lossless interframe codec wouldn't work for most of the stuff I deal with. When I have a YV12 video that I think will benefit from lossless interframe compression I use x264 in lossless mode. I happened to have a 1920x1080 24 fps MOV file of Big Buck Bunny so I ran a test. The source is YV12 so I used Lagarith in that mode. I downscaled the source to 1280x720 to match your source. The resulting lagarith AVI file was about 5.015 GB. Since YV12 is half as much data as RGB I suspect it indicates my 1280x720 source is substantially similar to yours. I then compressed that video with x264 in lossless mode at the veryfast preset and got a 2.170 GB file. I verified the x264 encoded video had no losses (using Subtract and Levels in an AviSynth script). It encoded at 67 fps on my quad core i5 2500K.

So x264 lossless gave a size reduction of about 54 percent vs. your codec's 29 percent. Of course, x264 benefits both from interframe encoding and motion vectors. So one would expect it to do better than an interframe encoder without (at least you didn't mention it) motion vectors.

[JanKafka]

I'm glad you have got something going and all, and think that's probably a good choice for a thesis, but I have to ask: are you bringing something new to the table or are you reinventing the wheel?

Codec is implemented according to known theory (color transform, predictors, entropy coding). However I did some experiments with 3D predictors. Existing predictors I found for example in researches on IEEE Xplore had good results in one case and worse results in another (even worse than 2D predictors). Therefore I tried to create my own version of predictor, very simple. It can switch between intraframe and interframe prediction in every pixel. Well, I'm not sure, if this is something new, but it works always at least as good as regular intraframe predictor in dynamic scenes and much better in static scenes. Of course, motion compensation could bring probably more improvement.

Codec is now implemented in VfW and supports 24 bit depth. It has GUI configuration dialog. Speed is not very good (usually a few fps slower than FFV1), but I want to do some optimization. I plan to release source code as FOSS this summer after my graduation. I think it could be good for educational purposes, if nothing else. And I would like to continue in studying. There are much more theory about compression images, for example wavelet transform.

[pandy]

I just want to know, if my work has any sense.

Thank you

Thank for info and effort.
Answer is definitely Yes if You will implement features not present in other lossless codecs - if You can beat FFV1 in terms compression and speed then it is even better.

[JanKafka]

Of course, x264 benefits both from interframe encoding and motion vectors. So one would expect it to do better than an interframe encoder without (at least you didn't mention it) motion vectors.

Yes, my codec doesn't use any motion vectors and compensation.

[JanKafka]

Hello. I have some issues with keyframes. While encoding, I create keyframe every 30 frames. In VfW I set lpdwFlags to AVIIF_KEYFRAME, or to zero, if it isn't keyframe.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd742972%28v=vs.85%29.aspx

During the decoding it is necessary to start from keyframe. MPC-HC is able to play video correctly. If I want to seek somewhere in the video, it seek to the nearest keyframe and continue decoding from there, so no problem. But Windows Media Player isn't able to seek, it crashes immediately. It can only play video from start to end. There is probably request to decode frame, which is not keyframe.

How can I fix it? Can codec refuse the request for decode frame between keyframes and ask for nearest keyframe first?
Thank you.

[Cornucopia]

This link might help: http://microsoft.public.win32.programmer.mmedia.narkive.com/rn68G9WN/aviif-keyframe-usage.

Scott

[JanKafka]

This link might help: http://microsoft.public.win32.programmer.mmedia.narkive.com/rn68G9WN/aviif-keyframe-usage.

Scott

So I have to modify structure AVICOMPRESSOPTIONS? I'm not sure, if I have access to it. Function driverproc reacts to these messages

https://msdn.microsoft.com/en-us/library/dd757704%28v=vs.85%29.aspx

and there are structures like ICCOMPRESS, BITMAPINFOHEADER etc. but no AVICOMPRESSOPTIONS.

[jagabo]

Are you maintaining a keyframe index? Are you using ODML for files larger than 4 GB?

[JanKafka]

Are you maintaining a keyframe index? Are you using ODML for files larger than 4 GB?

Probably not. Here are sources of x264 and xvid. My interface is similar. Could you please show me where these codecs do maintaining a keyframe index?

https://fossies.org/dox/xvidcore-1.3.3/codec_8c_source.html
code.openhub.net/file?fid=poUSAvny74GIFf7WmqiydkRvO0s&cid=x6WZd3gUw Tw&s=&fp=272483&projSelected=true

On line 890 in Xvid and 1738 in x264 they set *icc->lpdwFlags to AVIIF_KEYFRAME or 0. I do the same thing.

[JanKafka]

Solved. Windows Media Player was sending messages to decode keyframes, although these frames were delta frames. I put one bit to every frame to determine if this is keyframe or not.

Soon I will post link to SourceForge. Project already exists, but code documentation in english is not complete.

[JanKafka]

Hello. You can try my codec if you want.
https://sourceforge.net/projects/jklosslessvideocodec/

Codec is 32-bit VfW and I recommend to use it e.g. for recording screen via CamStudio. There can be a lot of redundancy between frames. It can beat CamStudio Lossless Codec v1.5 in compression ratio and it's faster on systems with multi core CPU (uses 8 threads).

[ezcapper]

Thank you for this codec. I had lots of fun using it on my computer.