Snow wavelet codec

[Leak]

which wavelet type is best for encoding?
Bad question (not just according to the rules) - "none size fits all".

[Terranigma]

Entropy coder backend: Snow's CABRC is identical to H.264's CABAC except that Snow's is faster. (Snow used to use CABAC, and when it switched to the current algorithm there was no change in compression ratio.)

Could CABRC be implemented in h.264 and function properly?

[akupenguin]

No. The difference is in arithmetic precision and rounding. If the encoder and decoder round differently, bad things happen.
(While it might be counterintuitive, CABRC is both higher precision and faster (not that the difference in precision matters; both are close enough to optimal). The simple explanation for why CABAC is slower is that it has to keep track of which bits the decoder isn't supposed to have computed.)

[taeuber]

Hi akupenguin,


Snow's only colorspaces are 4:2:0 and gray.


that's right for now, but the source comments the other colorspaces out. As snow isn't complete and the code contains such hints I would say it is a feature for a 1.o version.

snow.c line 3977 ff.
switch(avctx->pix_fmt){
// case PIX_FMT_YUV444P:
// case PIX_FMT_YUV422P:
case PIX_FMT_YUV420P:
case PIX_FMT_GRAY8:
// case PIX_FMT_YUV411P:
// case PIX_FMT_YUV410P:
s->colorspace_type= 0;
break;
/* case PIX_FMT_RGB32:
s->colorspace= 1;
break;*/
default:
av_log(avctx, AV_LOG_ERROR, "format not supported\n");
return -1;
}

What about you supporting snow? It's really a pity that I only can offer money as support and not able to develop myself.

You seem to know snow very well. And the missing feature of course.
Do you like to be paid for developement on snow?

Thanks
Lars

[taeuber]

Hi Liisachan,


I don't have much money, but I'd like to support the dev(s)
at least spiritually, by making a little donation like 20 EUR for now.

I think the best way ist to write a mail to the dev list that you want to support the snow developement. The motivation is not very good for that right now.

When the SoC (http://code.google.com/soc/2007/ffmpeg/about.html) has ended I try to ask the dirac programer if he would like to support ffmpeg with snow too.

He might be interested because dirac has much in common with snow.

Thank you for your support.

Lars

[Liisachan]

I think the best way ist to write a mail to the dev list that you want to support the snow developement. The motivation is not very good for that right now. So you actually asked me to make a donation, when there's no direct way to do so? I already told you that I do have will to help you out, but do not have time, like for chatting in the list. I know just sending some money is not the best way to support the project, but that's the only thing I could do for now. I have little time for testing any new codecs including x264 Dirac Theora... but that does not mean I don't like them. I'm afraid money can't buy motivation anyway (A similar thing happened for MusePack a few years ago).

[Liisachan]

but the source comments the other colorspaces out. As snow isn't complete and the code contains such hints I would say it is a feature for a 1.o version. IIRC snow is going to have the lossless mode, so it's not surprising to see RGB32 or something hidden. I don't know much about codecs so I may be wrong, but how else could it be (truly) lossless when the input is RGB24/32?

[taeuber]

Hi Liisachan,

So you actually asked me to make a donation, when there's no direct way to do so?

I mostly ask for support. Maybe I don't express this correctly. That support doesn't necessarily be money or coding skills.

I already told you that I do have will to help you out, but do not have time, like for chatting in the list.

I thought when some more people ask for a 1.0 version of snow on the list the programers might recognise others are looking forward to a stable snow codec too. The more ask for it the more motivation raises I hope.

I think the developers need to see that their codec is very welcome and waited for. Without anyone asking for it there is no virtue in developing it any further.

My english is far from good enough to express what I want to explain.

Simply: I want to support the developement in any way I'm able to. One way was to donate some (a lot of my little) money the other way is to promote snow wherever I can.
Don't take it amiss!

Regards
Lars

[Pacoup]

I'm backing taeuber's point that the more people giving out a desire for such a codec, the better the motivation will be for people developing it.

[ReinerSchweinlin]

IIRC snow is going to have the lossless mode, so it's not surprising to see RGB32 or something hidden. I don't know much about codecs so I may be wrong, but how else could it be (truly) lossless when the input is RGB24/32?Maybe I`m mistaken, it´s been a while since I took a look at snow. But AFAIR there already is a lossless mode. Losless in YUY12 is also 100% losless, of course it´s not if you have a rgb source and convert it to another colour space. since most media nowadays don´t use RGB, Support of RGB is only important for intermedia processing.

[Liisachan]

Losless in YUY12 is also 100% losless, of course it´s not if you have a rgb source and convert it to another colour space. since most media nowadays don´t use RGB, Support of RGB is only important for intermedia processing. I see. That kind of "lossless". Huffyuv also says "For RGB input you also have the option of converting to YUY2...This is not lossless, but often it doesn't matter because the same conversion is done anyway when you compress to MPEG..." and I can see the point, more or less. I typically do Src->(some filtering)->Huffyuv RGB->(retouching (involves a lot of copy-and-pasting to/from Clipboard bitmap that is RGB)/more filtering)->Another Huffyuv RGB->Compress, so I personally need RGB to RGB lossless.

Anyway, my random thought was, that snow+RGB was not surprising _because_ snow can be lossless, and I guess this "because" was inappropriate, tho the conclusion itself seems to be right... It's not like I wanted to compress something with snow using RGB. It was just a random thought.