Snow wavelet codec

[Tommy Carrot]

I think Snow codec has reached the point where it should deserve an own thread here. :) If someone wouldn't know what Snow is, it's an experimental wavelet codec made by the ffmpeg developers, and despite the "experimental" label, it's probably the most mature wavelet codec out there with very good performance, far surpassing other wavelet codecs (rududu, dirac) and imho mpeg4 ASP codecs (xvid, divx etc.) too, quality-wise. As it's part of the libavcodec codec library, there are several applications with Snow support, like ffmpeg, mplayer/mencoder (http://www.aziendeassociate.it/cd.asp?dir=/mplayer) and of course ffdshow (http://www.aziendeassociate.it/cd.asp?dir=/ffdshow).

Snow has a few settings which are probably not obvious at first glance, let's see them in mencoder, here is a command line example with the more important options:

mencoder in.avi -o out.avi -ovc lavc -lavcopts vcodec=snow:vstrict=-2:vqscale=3:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel

Detailed descriptions of the various options are here (http://mplayerhq.hu/DOCS/tech/snow.txt).

Note: vqscale specifies the encoding quality, basicly it's the quantizer. If you leave it out from the command-line, snow will compress losslessly (lossless mode doesn't work with pred=0 currently!). 2-pass mode is also available, but in my experience it's far from perfect yet, it doesn't really hit the required bitrate, and it gives significantly worse quality than constant quantizer mode at comparable bitrate.

Recommended settings: I'd strongly suggest to set all cmp functions to 1 (sum of squared errors method) for minimalising the chroma (and other) artifacts. Enabling qpel is also recommended for better detail preservation. Theoretically using smaller motion partitions (:v4mv) should further improve the compression efficiency, but due to the immature state of snow, it has side effects (artifacts, less accurate ME etc), so i cannot recommend it yet.

Outside mencoder, FFdshow can also be used for encoding Snow, it's more user-friendly, but apparently not everything is right with the snow encoder implementation in it, because the output quality is inferior to mencoder (ffdshow adds a slight vibration to the video, the motions are not smooth, the finer details are jumping around... i can't explain it better, but the effect is obvious during playback. Enabling 4 mv option makes this phenomenon even worse.)

BTW, don't use Snow for archiving, experimental means that the bitstream might change during the development, so it's not guaranteed that current encodings will be decodeable with the future versions.

[virus]

Originally posted by Tommy Carrot
...but i think the next ffdshow will include it...
oh, that's good. hate 6-lines-long commandlines :)

BTW maybe your post can be split to a "snow development" thread?

[Tommy Carrot]

Originally posted by virus
BTW maybe your post can be split to a "snow development" thread?

Probably starting a new thread would've been a better idea, but oh well. :D

Anyway, here (http://www.fw.hu/carrotland/snowtest_288kbit.avi) is a test encoding, as the name says, the bitrate is 288 kbit/s, just to have some ideas what this codec is capable of. :)

Right now only mplayer can play it back, hopefully the next ffdshow build is coming soon. :D

[RadicalEd]

Best settings in my test are unanimously qpel:pred=1:mbcmp=1, but with animated and DV source. Not sure if live action DVD source would be different. CMP functions may not be accurate on my side because I don't have SSE, though encoding with them worked and did show differences.

[Tommy Carrot]

This SSE is not the refer to the instruction set, but another method for the ME. It's more accurate, but slower.

Pred=1 indeed benefits the quality, but it makes the playback so much slower that i cannot play back the video in realtime.

What is your opinion about :v4mv? IMO it increases the sharpness and the detail level at higher bitrates, so that's a good feature too.

[RadicalEd]

Ah yeah, duh, sse as in sum of squared error. I was still in the cpu mindset ~_~
My results only reflect size loss in the lossless mode, I'm in the process of testing lossy atm.

[Rrrough]

Anyway, here is a test encoding, as the name says, the bitrate is 288 kbit/s, just to have some ideas what this codec is capable of. Man, this is unbelievable !
This project seems to continue where Ogg Tarkin has left...
Are there any developers from the former Tarkin project active on SNOW ?
I also hope that'll be included with next ffdshow version.

cheers

P.S.: Wasn't the project goal of Tarkin to fit a whole movie on a zip disk ? :D

[Razorblade2000]

now THOSE are awsome results!

[Rrrough]

Pred=1 gives a nice quality boost and is still playable in realtime here, whereas lossless encoding doesn't playback in realtime (2 min 640x272 => 180 MB :eek: )
Pred=2 is really too CPU hungry for realtime playback, but quality is definetly nice !

[netchris]

Great job with introducing us to snow Tommy Carrot,
the codec is simply STATE OF THE ART!
I made some tests with a quantizer of 6 and I cant believe how great the output is.
Not sure yet but v4mv does provide a more detailed picture but introduces some artifacts like ringing around objects,and maybe stronger colour mismatches. So at this quantizer I prefer to avoid it.
I have a videoclip from a sattelite source that is very difficult to compress, and snow managed to give an excellent picture at 480 Kbps!!!!!! Previously I would have to go as high as 600kbps to get a "watchable" picture . (264 codecs are not taken in to account, I am sure it will do well with atemes codec as well).
And with one pass. Imagine it being more mature and having a two pass option!!!! It will easilly surpass all other (current) codecs!!!!

[DeepDVD]

Err... I got the Sample of the Snow-Codec and had found out the codec is also readable by VLC 0.80 ... by the way

[akupenguin]

Be careful of trying to play Snow with any stable release. It changes often, and isn't always backwards compatible, sometimes in subtle ways.

[Tommy Carrot]

Originally posted by akupenguin
Be careful of trying to play Snow with any stable release. It changes often, and isn't always backwards compatible, sometimes in subtle ways.
I'm aware of this, snow has no practical value right now, but still, i think it's a very interesting codec.

Btw, sorry guys, i was wrong, pred=1 doesn't make the decoding slower, i confused it with pred=2, and yes, it gives a nice quality boost, so it's good to have activated imo. :)

I've made some quality comparison against xvid with the following settings:
xvid - mpeg quantizer, vhq4, qpel, gmc, b-frames
snow - qpel, v4mv, all cmp function = 1, pred=1

and in every occasion snow is the clear winner, it gives more detailed image and no artifacts, so i would say snow is already better than xvid in almost every case.

[wunschkind]

hi,

it sounds good. where can we get this codec to test it?


thank you


wunschkind

[Leak]

Originally posted by DeepDVD
Err... I got the Sample of the Snow-Codec and had found out the codec is also readable by VLC 0.80 ... by the way

Well, it tries at least - for me, it freezes after 15-20 seconds and crashes a few seconds later... :(

Still, what I can see before the crash looks really promising. :)

np: Autechre - Squeller (EP7)

[gldblade]

Wow. That was by far the most impressive encode I have ever seen. Only 3 megs? Wow.

@wunschkind
At the moment the codec only exists in the mplayer/mencoder (http://celticdruid.no-ip.com/xvid/mplayer/mplayer2004.10.22.7z) package that everyone keeps linking to. Unfortunately its command-line only. It also doesn't support Avisynth files (you can encode directly from vob files though, the disadvantage is no filters). See Tommy Carrot's post for information on how to encode. In order to play the encoded video files, use mplayer movie.avi -vo directx.

[Rrrough]

@gldblade
I want to test encode using some vobs I have lying around, how would I do it?
as akupenguin's method of piping AVS to mencoder via AVS2YUV (see x264 development thread) doesn't work for me on windows (haven't tried with linux yet) I'm encoding a reasonable amount of frames with huffyuv or ffv1 and transcode the resulting avi with mencoder using snow.
If anyone knows an easier method, please let me know.

[gldblade]

@Rrrough
Haha, right after making my post I discovered that I can encode directly from vob files since apparently the package can decode mpeg2. Unfortunately there is then no resizing, cropping, and filter. Still good enough for testing purposes, although I'm open to other suggestions.

[Rrrough]

Yeah, encoding directly from VOB's would be easier with the problem of missing filters. Are you sure though that cropping and resizing doesn't work ? Gonna try...

[gldblade]

Actually I'm not familiar with mplayer/mencoder. Does it support video manipulation of any kind?

*EDIT*
It does apparently, which makes mencoder much more useful. The following page details how, along with other potentially useful information. http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-crop

[celtic_druid]

If you add the AVIS to the codec file then you can use an MakeAVIS and AVISynth as input.

crop : cropping
expand : expanding & osd
pp : postprocessing
scale : software scaling
vo : libvo wrapper
format : force output format
noformat : disallow one output format
yuy2 : fast YV12/Y422p -> YUY2 conversion
flip : flip image upside-down
rgb2bgr : fast 24/32bpp RGB<->BGR conversion
rotate : rotate
mirror : horizontal mirror
palette : 8bpp indexed (using palette) -> BGR 15/16/24/32 conversion
lavc : realtime mpeg1 encoding with libavcodec
lavcdeint : libavcodec's deinterlacing filter
dvbscale : calc Y scaling for DVB card
cropdetect : autodetect crop size
test : test pattern generator
noise : noise genenerator
yvu9 : fast YVU9->YV12 conversion
eq : soft video equalizer
eq2 : Software equalizer
halfpack : yuv planar 4:2:0 -> packed 4:2:2, half height
dint : drop interlaced frames
1bpp : 1bpp bitmap -> YUV/BGR 8/15/16/32 conversion
2xsai : 2xSai BGR bitmap 2x scaler
unsharp : unsharp mask & gaussian blur
swapuv : UV swaper
il : (de)interleave
fil : fast (de)interleaver
boxblur : box blur
sab : shape adaptive blur
smartblur : smart blur
perspective : perspective correcture
down3dright : convert stereo movie from top-bottom to left-right field
field : extract single field
denoise3d : 3D Denoiser (variable lowpass filter)
hqdn3d : High Quality 3D Denoiser
detc : de-telecine filter
telecine : telecine filter
tinterlace : temporal field interlacing
tfields : temporal field separation
ivtc : inverse telecine, take 2
ilpack : 4:2:0 planar -> 4:2:2 packed reinterlacer
dsize : reset displaysize/aspect
decimate : near-duplicate frame remover
softpulldown : mpeg2 soft 3:2 pulldown
pullup : pullup (from field sequence to frames)
filmdint : Advanced inverse telecine filer
framestep : Dump one every n / key frames
tile : Make a single image tiling x/y images
delogo : simple logo remover
hue : hue changer
spp : simple postprocess
yuvcsp : yuv colorspace converter
kerndeint : Kernel Deinterlacer
rgbtest : rgbtest
qp : QP changer
phase : phase shift fields
divtc : inverse telecine for deinterlaced video
harddup : resubmit duplicate frames for encoding
softskip : soft (post-filter) frame skipping for encoding

[DeepDVD]

@ Leak

That's strange because i don't have problems to play it at all.

I recognized that a big advantage of the codec is to handle fast-motion sequences with such a easiness i've never seen before in another codec... a disadvantage is the blocky plain parts of the picture... It's strange... other codecs have probs with too many details at a to low bitrate and encodes blocks... this encodes blocks in very easy to encode sections ;)

[Leak]

Originally posted by DeepDVD
@ Leak

That's strange because i don't have problems to play it at all.

I've used VLC 0.8.0-test2 on Windows 2000; what are you using?

np: Aphex Twin - Taking Control (Drukqs (Disc 2))

[Razorblade2000]

could some mod please split the thread?

concerning filters and mencoder: I haven't found any usefull filter that isn't included :D

[DeepDVD]

My System is Windows XP with all Bugfixes but w/o SP1 and SP2 ... and I'm using the same version of VLC as you...

[RadicalEd]

Unfortunately I'm unable to reproduce all the good reports about snow, in lossless or lossy mode. I'm not sure if the cause of this is just my source or my build of mencoder. Anyway, here's a small comparison.

Snow quant 4 (961 KB) (http://misatokatsuragi.home.comcast.net/sub_snow_q4.avi)
XviD quant 7 (931 KB) (http://misatokatsuragi.home.comcast.net/sub_xvid_q7.avi)

To me XviD looks better, especially with postprocessing.

edit: Snow also has the interesting capability to scale to ridiculously low and high bitrates: vqscale=0.01 comes to 31 MB (73,305 kbps or 72 mbps) on the above clip, while vqscale=255 is 17 KB (40 kbps). Keep in mind this is at 640x480 and 23.976 fps. This is pretty amusing (http://misatokatsuragi.home.comcast.net/sub_snow_q255.avi).
Also note that while q0.01 was 31 MB, lossless mode was only 11.

[Yong]

I think i should upgrade my computer hardware before tyring to play with this SNOW codec.:eek: Anyone here can play the SNOW videp clip smoothly?

[Tommy Carrot]

I have an athlon xp 1700+, and for 720x288 clips the CPU usage is around 85-95%, so that's the max i can play back.

@RadicalEd: your bad experience with this codec is probably related to the fact that you want to encode anime content with it. In my experience the more the detail on the image, the higher the advantage over xvid, so with many flat areas and few details probably the opposite is true, perhaps it's not really suited for cartoons.

[RadicalEd]

Originally posted by Tommy Carrot
@RadicalEd: your bad experience with this codec is probably related to the fact that you want to encode anime content with it. In my experience the more the detail on the image, the higher the advantage over xvid, so with many flat areas and few details probably the opposite is true, perhaps it's not really suited for cartoons.

Still, the lossless mode didn't perform extremely well on my DV content either. I'll test lossy mode on that tonight to see if there's a difference. Then I'll do some DVD source live action encodes just to see what happens.

[Razorblade2000]

Hmmm... can snow use the ratecontrol of libavcodec or params like vbitrate?
(Seems a bit improbable to me... but asking has never hurt anyone :D)

[Yong]

I have P4 2.4GHz, playing the SNOW video clip(CG/Animation with a lot of motion scene) 640x480 @ 100% cpu usage!!!
Below the 640x480 sholud don't have problem.
I hope Micheal can optimize this SMOWy codec before it can public release!:D

Sorry for my bad english...

[Tommy Carrot]

Michael said somewhere in the mailing list that he doesn't want to waste time with optimalization, when probably there will be substantial changes in the codec (this is why it's called experimental), so in the end most optimizations would be obsolete. When the bitstream and the used algorithms are finalized, then will he start the optimalization.

[DeepDVD]

@ Razor

I've played around a little bit with some standard commands of mencoder and got the vbitrate-command running .... but i got error by using vpass... that's sad, i would really like to see how a multipass-encode should look like and what corrections there would be with a second pass...

Uhm... the vbitrate-command is running but i get strange sizes of the encoded videofile... using 50% of the original bitrate i get a bigger file than the origin... strange :sly:

[Teegedeck]

Aha, there it is! I've been looking for news about Snow for a long time, and now it pops up in this old thread!

Edit: Hopefully this will solve our backup-problems, once DVDs use MPEG-4 AVC. :D

Perhaps splitting the thread would be a really, really good idea.

[*.mp4 guy]

This looks like an interesting codec, anyway has there been a thread split? and furthermore is there anyway i could try to use the encoder on a win xp machine?

[Razorblade2000]

yes you can :D

[Mug Funky]

a thread split is definitely a good idea, i think. it's actually really hard to find info on snow anywhere.

...commandline options for mencoder or ffmpeg would be a good place to start :)

[Tommy Carrot]

Here is the official documentation (http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html#CODEC SPECIFIC ENCODING OPTIONS (MENCODER ONLY)) of the mplayer/mencoder, it contains supposedly all command line options. The part after -lavcopts deals with the most important settings.

[Mug Funky]

already been there today. it's a no-snow (ooooh, MAN! that was an awful joke!)

[akupenguin]

Disclaimer: All the content I have ever tried to encode is anime.

I find that for lossy encoding at all sane qscales, pred=0 (9/7 wavelet) is better than both pred=1 (5/3 wavelet) and pred=2 (13/7 wavelet). For lossless, pred=1 is usually better.
And I consider Snow @ vqscale=3-4 to be medium quality, and vqscale=1.5 to be higher quality and lower bitrate than my mpeg4 rips.
I agree with the rest of your recommendations (*cmp=1 & qpel always, v4mv @ low quants).

BTW, I find that Snow lossless is only marginally better than ffv1, and sometimes even slightly worse. I would bet that ffv1 + non-motion-compensated temporal prediction would be even better compression without sacrificing speed. Dunno if I'll ever get around to implementing it, though.

[Tommy Carrot]

Originally posted by akupenguin
BTW, I find that Snow lossless is only marginally better than ffv1, and sometimes even slightly worse. I would bet that ffv1 + non-motion-compensated temporal prediction would be even better compression without sacrificing speed. Dunno if I'll ever get around to implementing it, though.
It's true that sometimes it's worse than ffv1, but there are cases where it gives _much_ better compression ratio (387,934k vs 636,034k) when the frames are very complex, but predictable from each other (e.g. most live-action movies).

[bond]

i now splitted the snow codec discussion, by simply moving all threads after 23rd October 2004 to an own thread, i hope thats ok?

[*.mp4 guy]

When reviewing some test encodes I thought I saw some faint blocking, has anyone else noticed this? Maybe it was my source, I just find it hard to believe that their would be visible bloking in a dvd, or a wavelet based codec... maybe I've just been staring at test encodes to long:D

[akupenguin]

Originally posted by *.mp4 guy
When reviewing some test encodes I thought I saw some faint blocking, has anyone else noticed this? Maybe it was my source, I just find it hard to believe that their would be visible bloking in a dvd, or a wavelet based codec...
There are plenty of DVDs with blocking artifacts. Throwing lots of bits at a codec doesn't automatically make it good, there's still room for bad filtering, bad ratecontrol, and averse reactions to noise.
Snow does not block at all, except in areas of very slight gradients where simply rounding to an 8-bit color depth introduces artifacts.

[celtic_druid]

ffdshow (http://celticdruid.no-ip.com/xvid/ffdshow/)

With SNOW support. Seems to work ok.

Alternative Download (http://s14.yousendit.com/d.aspx?id=9264A2A007E28EAA667A98AA5BE442C8)

[*.mp4 guy]

Thanks for clearing that up akupenguin it was really bothering me, and having FFdshow support Snow is great! Now i can use virtualdub for encoding and use FFdshow's psnr calculator.:)

[Teegedeck]

Originally posted by celtic_druid
ffdshow-20041026.exe (http://celticdruid.no-ip.com/xvid/misc/ffdshow-20041026.exe)

With SNOW support. Seems to work ok.
*GOSH!* Thank you.

[RadicalEd]

Originally posted by Teegedeck
*GOSH!* Thank you.

Seconded, this is pretty damn nice.

[Teegedeck]

Hm, after installing it, it won't let me configure it or decode anything and it doesn't show up in Win2K's video-codec list or in VDub.

Gonna try on WinXP lateron.

[RadicalEd]

Originally posted by Teegedeck
Hm, after installing it, it won't let me configure it or decode anything and it doesn't show up in Win2K's video-codec list or in VDub.

Gonna try on WinXP lateron.

You still need the registry fix (http://forum.doom9.org/showthread.php?s=&threadid=80256&perpage=20&pagenumber=9).

Any info on the kind of mapping for Snow's quality levels? 255 -> 0.01 is the quantization range, but the q 0 -> 100 doesn't reflect this.