Motion Images Lossless Kodec ... mooooo ^^

[Marc FD]

just a demo version of the stuff i was talking about.

i optimised it better, now seems around half slower than huff is

here's a demo version, so :

- assumes input is progressive
- yv12 only
- assumes you have ISSE
- vfw is buggy and strictly minimal (i hate vfw, don't ask me more)
- it's NOT going to be backward compatible


here's a direct link : (hosted by a cool french board about video btw ^^)

http://atlas2.tgv.net/~media-video/forum2/download.php?id=166

any comments are welcome ^^

[Sirber]

What's it's features?

[Tommy Carrot]

Hmm, virtualdub says:
Couldn't find compatible format.
Possible reasons:
Codec may only support YUV.


What app should i use to try this codec?

[Marc FD]

Lossless.

compresses more than every yv12 lossless codec i know (that's about 10% less in size than a huffyuv in yv12)

EDIT : btw vfw sucks so much, you may need to feed it with YV12 directly. use avisynth to get raw YV12 streams ^^.

[Tommy Carrot]

Originally posted by Marc FD
btw vfw sucks so much, you may need to feed it with YV12 directly. use avisynth to get raw YV12 streams ^^.

I tried that, but i still cannot select it. Bad luck i guess. :)

EDIT: Wait, it works.

[Marc FD]

it says you can't ... but encodes anyway... must be some vdubmod magic ^^ (tested on vdm 1.5.4.1 build 2066)

[digitize]

Fairly nice compression gain (compared to vble), about 20MB over 1005 frames (133,025,792 bytes -> 112,990,208). This comes at the cost of speed though, hopefully optimizations will come. None the less, good job Marc ^^.

[Tommy Carrot]

I've made a short test on anime:


Huffyuv: 150,336k
VBLE : 99,934k
LOCO : 95,340k
MILK : 86,916k
FFV1 : 69,358k


Not bad! Only FFV1 could beat it, but it's twice as slow. Nice work!

Correction: Of course these results are in kilobytes, not megabytes. :)

[Sirber]

Could you add CorePNG to your comparison?

[Tommy Carrot]

Another test, part from "Shanghai knights" movie.


Huffyuv: 300,782k
VBLE : 262,086k
LOCO : 245,247k
MILK : 241,706k
FFV1 : 217,530k

[Tommy Carrot]

Originally posted by Sirber
Could you add CorePNG to your comparison?

Sorry, CorePNG takes too much time, and here it's kinda late (1am)

[Marc FD]

wow, i had never heard of ffv1. so milk is the 2nd, not the first... sorry ^^
but ffv1 seems to be binary coding based, so it's not really the same class =)

i'd like to hear about the speed. i optimised milk a lot (asmed everything), but maybe there are still some improvements who could be made ^^.

i'll improve compression after (at the tradeoff of speed), i've lots of things to do for that, like testing the full jpeg-ls specs and some tweaks :| (i wrote the current specs myself before i even knew loco & jpeg-ls existed ^^;)

so first i'll look the speed and colorspaces.

my goal is 30 fps encoding with most cpus, to make milk suitable with aquisition. decoder optimisations will follow someday (at least for the symmetric stuff ^^)

btw, i think i'll add support of the following colorspaces too : 32bits RGBA, 24 bits RGB and YUY2.

Cheers,
MarcFD

(PS : i eager to see psnr tests XD)

[iwod]

It is my wonderful teacher !!!!!
Hi Marc FD........ long time no see.....Last time you were here i thought you said you brought a PS2 and have no more time for doom9.org

Glad you are back.. ( when were you back anyway?? )

I am trying to test this against CorePNG.........
results later.......

[MfA]

About RGB, the reversible color transform from JPEG-2000 should improve compression ... the only problem is that it expands color components to 10 bits, depending on the bottlenecks that might not be a big deal though (you can do the transform on the fly and code all planes simultaneously, so memory bandwith is not an issue at least).