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.

[Rrrough]

ffdshow-20041026.exe
With SNOW support. Seems to work ok.
YAY, point'n'click-encoding !!!
Plus playback with MPC.
Works fine here. (Win XP)
Thank you very much ! :)

[Teegedeck]

Works fine on WinXP! Surprisingly very acceptable speed, great quality (well, if you take the compression ratio into accout), bloody good compression. I'm quite taken.

[hellfred]

Michael has updated the snow.c (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/snow.c?cvsroot=FFMpeg&sortby=date) file in libavcodec.
CABAC -> range coder

Celtic_druid, does your ffdshow build already incorporate this update?

Hellfred

[DAvenger]

Impressive quality!

[hellfred]

Hy Celtic_Druid
Does your ffdshow compile need special instructions sets like SSE2 to work? I can not get your ffdshow-20041026.exe working on my System ( PIII Win98). When viewing the details at the end of installation process I can see "Can't open E:\Rechner\ffdshow\ffdshow.ax" and trying to register it manually will earn me some BlueScreensOfDeath only.
On the other hand, installing ffdshow-20041012.exe works like a charm, and shows up in VDubMod, too.

Hellfred

[celtic_druid]

http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/ffmpeg/libavcodec/snow.c?rev=1.7&view=log
Last update four weeks ago. If you want the latest, then I would stick with ffmpeg or mencoder.

Should work fine on a PIII, perhaps it is a win98 issue?

[Tommy Carrot]

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.
Thanks man!

[hellfred]

Originally posted by celtic_druid
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/ffmpeg/libavcodec/snow.c?rev=1.7&view=log
Last update four weeks ago. If you want the latest, then I would stick with ffmpeg or mencoder.

Should work fine on a PIII, perhaps it is a win98 issue?
I do not think so. Up to now i had no porblems with your builds of ffd_x264.dll and any ffdshow build from sourceforge or Andy. I have uninstalled your ffdshow build and reinstalled v20041012. Now all works fine again.
As I still can use self-compiled mplayer to watch snow encoded clips, there is no real problem. Thanks for your reply and affords to compile ffdshow for us, nevertheless. I will give your compile another try on the second system that i can access (P4@3.06GHz running WinXP). Hopefully it will work there, and I can compare the results of mencoder and ffdshow encoded video clops - and decoder performance, too.

EDIT: About snow.c. If you follow the link, you will see that I am referring to the cvs repository of ffmpeg project directly, that is hosted on some mplayer server

[708145]

ffdshow 20041026 does not install correctly here :confused:
registered filter manually -> vidc is set correctly.

Whatever you did right with previous installers: Please do it again!

bis besser,
Tobias

[Teegedeck]

For the moment I'd like to take a little back of what I said on Snow; XviD holds itself well but I cannot test any more because all of a sudden Snow makes VDub exit all the time.

Edit: I've made at least some samples with Snow before 'it gave up on me'. Among them I managed to produce one at quality=95 which happens to be just 1.8% smaller than a transparent XviD clip of the same sample. The Snow sample looks a teensy bit unsharp in comparison. This is pretty much the same phenomenon that I encountered when testing Ateme's H.264 codec. Both codecs seem to concentrate on more extreme levels of compression and don't offer any improvement in the 'transparent' department - yet. (SSE and QPel used)

[Sagittaire]

With ffdshow and SNOW use:

- SAD, SADT ... but NOT RD
- chroma motion for ME and subpixel but NOT for Macroblock
- QPel

[celtic_druid]

About the installer, I just used the NSIS script provided. Fixed it now though simple matter of replacing $INSTDIR with $SHORTINSTDIR for the vidc and acm keys. Possible that I broke something else in there though, like uninstalling.

I know which snow.c you were refering to, what I was trying to point out that I compiled with cvs ffdshow soure which is 4 weeks old for snow. It isn't like mplayer where you just add the latest libavcodec so you can't just drag snow.c over, at least I don't think it is that simple.

I will update the installer, however before I do that I think there may have been a problem with some/one of my ICL op flags as audio decoding causes a crash here and it doesn't with an unoptimised MSVC (1/3 the size) build.

[Tommy Carrot]

Originally posted by Teegedeck
For the moment I'd like to take a little back of what I said on Snow; XviD holds itself well but I cannot test any more because all of a sudden Snow makes VDub exit all the time.

Edit: I've made at least some samples with Snow before 'it gave up on me'. Among them I managed to produce one at quality=95 which happens to be just 1.8% smaller than a transparent XviD clip of the same sample. The Snow sample looks a teensy bit unsharp in comparison. This is pretty much the same phenomenon that I encountered when testing Ateme's H.264 codec. Both codecs seem to concentrate on more extreme levels of compression and don't offer any improvement in the 'transparent' department - yet. (SSE and QPel used)

You should try to enable 4mv, in my experience it can improve the sharpness and the detail-level. Also it seems that we can't change the wavelet function in ffdshow, it uses the default (9/7), while 5/3 wavelet usually gives sharper image imo.

Slightly offtopic, but i also noticed that the quantizer slider of the x264 has finally got the correct range [0-51]. Thx Milan.

[Teegedeck]

Originally posted by Tommy Carrot
You should try to enable 4mv,
I did.

Edit: But perhaps I'm just being very subjective and prefer the 'look' that I have grown accustomed to. I hope that I will get Snow working again and can continue an earnest comparison sometime soon.

[hellfred]

Originally posted by celtic_druid
I know which snow.c you were refering to, what I was trying to point out that I compiled with cvs ffdshow soure which is 4 weeks old for snow. It isn't like mplayer where you just add the latest libavcodec so you can't just drag snow.c over, at least I don't think it is that simple.
OK, got that. As improvements are added to libavcode quite often, being alble to use unchanged libavcodec from ffmpeg would be great for those wanting to compile it themselfes. But that is not me. I am busy with compiling X264 and mplayer/mencoder.
By the way, i have no problems with your builds on the P4 system mentioned in my last post. I even have to report that ffdshow keeps sync between audio and video better when using ffdshow than when decoding using mplayer cvs from approximately four days ago (This is on a system with heavy load on the processor). Nice work.

Hellfred

[ChronoReverse]

Is it just me or is that link to the snow-version of ffdshow giving a 404?

It works again. I must've done something stupid.

[celtic_druid]

Updated the installer. ffdshow now shows up fine in VDub, etc. Also changed the opt flags for ffdshow.ax, seems more stable now. It also includes s264 support for h.264 mp4 playback via the moonlight splitter.

You must have tried while I was replacing the file.

[Teegedeck]

Now that's something new... The codec can't be configured in VDub anymore.

[celtic_druid]

That is with the new or the old version? I put an MD5 file up, if the version you have doesn't match, download the new one.

The first version that I put up, crashed with audio playback for me and didn't work on my Athlon 800 box. The one currently there, seems to be fine on both accounts.

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

[ChronoReverse]

Call me stupid but how do I get rid of the error that pops up whenever I try to use the configuration? Something about MSVCR71.dll being missing?

I've tried downloading that dll and putting into the system directory, but it asks for another one (MSVCP71.dll).

Downloading that and putting it into the system directory makes the message go away. But the dialogue still doesn't show up :(

[celtic_druid]

CPU & OS?

Full list of dependencies:
ADVAPI32.DLL
COMCTL32.DLL
COMDLG32.DLL
DINPUT.DLL
GDI32.DLL
KERNEL32.DLL
MSVCP71.DLL
MSVCR71.DLL
MSVCRT.DLL
NTDLL.DLL
OLE32.DLL
OLEAUT32.DLL
RPCRT4.DLL
SHELL32.DLL
SHLWAPI.DLL
USER32.DLL
WINMM.DLL

Tested and working under win2k SP4 on an Athlon-XP and WinXP SP1 on a Athlon TBird.

[ChronoReverse]

Windows XP SP1 - Athlon XP 2000+

I'm downloading the VC++ .Net 2003 toolkit and installing that to see if it gives me the dlls I need.

[celtic_druid]

Think I know what is happening. Registering the ax failed due to the lack of DLL's. You now have the DLL's, but the ax is still not registered.

Re-install or manually registering ffdshow.ax should sort the problem. Guess I better either include the DLL's or compile a version that doesn't require them.

[Tommy Carrot]

@Akupenguin

Do you know what is the reason Michael decided to change the entropy coder to range coder? Simply patent issues, or there is technical benefit too? Just because in my knowledge cabac is a little bit more efficient than the range coder.

[MfA]

Efficiency difference of range coder compared to other arithmetic coders is miniscule at best.

[akupenguin]

Purely aesthetic and legal reasons.
CABAC is heavily patented, while range coding was invented in 1979 and is thus free now.
Range coding is theoretically and practically simpler. (rangecoder.c,h are half the size of cabac.c,h)
The new range coder is slightly faster than the old CABAC, but that might just be optimizations.
There is absolutely no difference in compression efficiency (like, 4 bytes difference over a full movie.) Both algorithms can come arbitrarily close to the entropy of your probability model. They are limited by arithmetic precision, but it's the same limitation for both.

[ChronoReverse]

Originally posted by celtic_druid
Think I know what is happening. Registering the ax failed due to the lack of DLL's. You now have the DLL's, but the ax is still not registered.

Re-install or manually registering ffdshow.ax should sort the problem. Guess I better either include the DLL's or compile a version that doesn't require them.

That would be very good. I have the dll's now, but it's still not working (even with a reinstall).

I'll try manually registering ffdshow.ax in a bit (once I find the command to do it).

Okay, it _seems_ to work now that I've manually registered ffdshow.ax

Time to try out the "Snow"


Meh, I still need msvcr71d.dll
It's using the debug runtime? In any case, still a no go since I can't seem to find a place to get this dll =(

[celtic_druid]

Suprised that you didn't already have the dll's, many apps use them. Anyway I updated the installer, now only requires msvcp60.dll which most people probably already have 10 copies of, it is included anyway so now you can have 11.

I screwed up the installer (ffdshow.ax wasn't registered) when I fixed the long names problem, that is now fixed to. Everything is now hopefully 100%.

Yeah on some of them ff_wmv9.dll was somehow the debug version, so I guess that explains the debug dll. Not sure how that happened with the workspace set to release. Anyway, that is also fixed now.

[ChronoReverse]

I have the 70 version of the dll (I have VS .Net installed but not the 2003 version).

I've managed to find the dll and now I can configure the codec at least ;)

Trying a little 640x480 animated CGish video to see what happens (settings default). ~6fps on my AthlonXP 2000+


Hmm, I can't play it back at the full 30FPS :(

Some parts it runs at 25FPS, in other parts it dips all the way down to <10FPS (screen static transitions).

I still find it fascinating how wavelet codecs don't block.


I'll try a re-encode for fun. Q50, qpel8, 4mv.

I'm downloading the updated one and I'll try that too

[celtic_druid]

After all that: updated libavcodec: non-backward compatible changes to ffv1 and snow.

Guess I better do a new build.

[akupenguin]

Originally posted by ChronoReverse
I still find it fascinating how wavelet codecs don't block. It's quite simple: they encode a whole frame at once, not in blocks. I guess a non-blocking motion compensation is more problematic, but it looks like Snow's obmc is working.

I'll try a re-encode for fun. Q50, qpel8, 4mv. Somehow I don't think 4mv will help at quant 50.

[virus]

Originally posted by akupenguin
CABAC is heavily patented, while range coding was invented in 1979 and is thus free now.
Well, do you really believe that if a wide-adopted free standard (say, for example, Theora) includes a range coder the IBM's lawyers won't try to sue?

AFAIK the original paper by Rissanen on arithmetic coding dates back 1978 (but his work started as early as 1975 or before). And they're very, very similar - the fundamental concepts are exactly the same. A bit too much similarities to be sure to avoid a patent litigation... do the original patents granted to IBM expired?

[akupenguin]

If it was invented in 1978, and we use the techniques presented in that paper rather than the CABAC implementation, then any possible patent expired in 1998, no matter what anyone has done since then. It may still be that IBM has patented some optimization not present in the original paper, and that it's impossible to implement a fast range coder without it. In which case Snow will have to go under --disable-risky-and-patent-encumbered-codecs-for-those-who-care (actual option name: --disable-risky), like half of lavc already.

Theora isn't free because of not infringing on patents. It's free because On2 has already dealt with the patent issues and donated it.

[ChronoReverse]

Originally posted by akupenguin
It's quite simple: they encode a whole frame at once, not in blocks. I guess a non-blocking motion compensation is more problematic, but it looks like Snow's obmc is working.

Somehow I don't think 4mv will help at quant 50.

Yes, I'm aware how wavelet compression works. I'm just merely stating the obvious.


And yes 4mv didn't help at quality 50. Although it's really hard to tell what quality 50 really means.

[Tommy Carrot]

Quality 50 is way too low to get watchable result, it gives around 100-150 kbit/s from a full-sized dvd source. I think snow is starting to be usable from quality 80 (the scale is not really balanced in ffdshow).

[virus]

Originally posted by akupenguin
It may still be that IBM has patented some optimization not present in the original paper, and that it's impossible to implement a fast range coder without it.
Well, AFAIK there are several practical implementations which have been developed, but I think that only 2 are the most used. One developed by IBM itself (Langdon, Rissanen and others) in 1979 or maybe a bit later, involving the use of bit-stuffing to limit the propagations of carries in the additions. I think this is the one used by CABAC (or maybe a technique derived from it), but I'm not familiar with this stuff. The other comes from Witten, Neal and Cleary and dates back 1987. It's the bit-plus-follow idea, which is featured in their CACM multisymbol coder, freely available.

None of this implementations is probably strictly required for a range coder, though. But it's all the same: if patents have not been dealt clearly before, you risk a costly trial. And no matter if you're right or not, you're probably already cooked ;)

[Tommy Carrot]

I've made some medium bitrate (xvid quant 6-7 range) comparison against x264, and this again showed that Snow has a good potential to beat even h.264 if it gets developed further. It preserves more details, and the contours of the objects are more precise, although x264 has slightly sharper contours (i hope it's understandable what i want to say :)). It's still not perfect though, similarly to rududu codec it lacks some image stability, there is a noticable vibration during playback, not to mention the slight miscolorizations. I hope these are not the sign of some fundamental problem with the motion compensation of the wavelet codecs, and can be fixed later, because these can be quite annoying during playback.

At higher bitrates neither codec has a noticable advantage over xvid, but hopefully this will change with the progress of the developments.

[Teegedeck]

This is also my impression, I think the turning point is somewhere around XviD with SixOfNine-HVS @ quant=7 (adaptive quantization, default b-frame settings) or MPEG-quant=4.

Leaves a lot of space for future development in the high-quality area.

[netchris]

I agree too,but there is another "problem" with snow right now. It keeps changing so rapidly that tomorrows version might not be compatible with todays.
I made a compilation of todays mencoder source and snow-videos cant be decoded by latest ffsdshow without problems.
About the "slight miscolorizations" and the other snow problems, i am optimistic they will be fixed in the future (only speculation ofcourse).

[Tommy Carrot]

Originally posted by netchris
I agree too,but there is another "problem" with snow right now. It keeps changing so rapidly that tomorrows version might not be compatible with todays.
True, but this approach gives the flexibility to change the algorithms if they find better ones than the currently used, so the codec can be even better in the end.

[billou2k]

Sorry if it is documented already but I couldn't find it: does Snow support interlaced encoding? if it is how to encode interlaced in mencoder and ffdshow? In ffdshow there is "assume interlaced if height > 288" does it have any impact on it?

[akupenguin]

Snow does not currently support interlacing. I have no idea if it's planned (I don't remember if Michael is one of the people who detests interlacing).

[morsa]

Man, this codec is AMAZING!!
Also quite fast at encoding compared to some others....
Hope it gets better every day....

[Nic]

I too am a big fan of snow, tried optimising the decoder a little last night, still not enough to play 720x576 on my PC well though :(

The next version of QuEnc, strangely as it's a MPEG-1/2 encoder really, will support Snow (to AVI format, I've already written all the code, so i'll release it in due course)...In a hope of getting more interest in it, and therefore perhaps get Michael Niedermayer working on it more again :)

Vibration during playback can often be fixed by raising the GOP size (and therefore widening the distribution of I-Frames). Although I-Frames shouldn't pulse like that...It does solve the problem somewhat.

-Nic

[Teegedeck]

Whoah! :) Thanks, Nic! An unforeseen move!

As you are about to make QuEnc the universal encoding-tool, anyway (;)), you know how much I'm longing for something with hardcoded hi-Q XviD presets...

How about making QuEnc change its used codec according to the compressiblity-results of a quick pre-pass (XviD, whatever...)? MPEG-2 for extremely good compression ratios (DVD-to-DVD copy), XviD for transparent encodes below that (don't know to which compressiblity, now, but down to a filesize that can be reached with the SixOfNine matrix at quant=4), and Snow for anything below that!! :D :devil:

Please! Pretty please.

[Koepi]

Noooooo! Not such automatisms! (I.e. I sometimes encode 2hrs movie to SVCD @ 800MB. Wouldn't be possible anymore... ;) )

Regards
Koepi

[Nic]

Lets not turn this into a QuEnc discussion, I'm really not going to progress QuEnc much further...Mainly because it can go so far then things like Subtitles, etc get very tricky (and as always, I don't have the time, I want to get it into a state, where I can leave it, I think Peter Cheat will carry on it's work in NuEnc anyway...then I can go back to ReJig and finally DVD2AVI (as well as get rid of one last bug in MPEGDecoder to finally finish that...That will raise a whole big discussion because I'm sure i'm dealing with TFF/RFF right, but DGDecode sometimes acts differently to me)

Anyway back on Topic:
The Snow support to QuEnc will only be a small adjustment and not well supported, but will hopefully be a bit more accessible to the average user and will drum up support for it, and get people looking at it.

As an example:
The company I worked for had to provide around 3000 odd hours of video clips as WMV8 at one stage. We did them at around 384x288 resolution at 512kbps, and to be honest they looked cr*p. Yesterday I encoded some of the same clips at 512kbps 720x576 and looked very close to the 5mbps originals. Only a few little artefacts....Impressive huh? Ok RV10, VP6.x and Nero's H264 can do similar things, but none of them are opensource....

Anyway sorry for the long post, feeling quite verbose today,

-Nic

[lithoc]

I think not long in the future, Quenc wil become the official FFMPEG frontend for windows? :D

way to go, NIC

[plonk420]

hrm, just now seeing this codec (still need to download a recent ffdshow). should be interesting to see how it performs (loss of detail a la my recent single experiment with helix producer?). the last wavelet format i played with was (IIRC) the FIF image format and the VIVo video format ^_^ haven't seen much like this in a while

*taps foot impatiently as he waits for a 720p wmv9 test encode to finish in VDub*

[RadicalEd]

? :|
vivo was just H.263

[Sirber]

Yep. Just H263... :(

[plonk420]

hmm. i must be thinking of something else.

first test of SNOW has been a bit odd. first encode @ 50% wasn't that good (i AM doing a killer clip, tho). 80% was still pretty painful, but getting close. however, the 90% encode was the same size, or to be exact, 6K smaller. going to try 95% after i go to sleep i guess.

[Teegedeck]

Any news, yet?

Fiddled around with HDTV a bit, and Snow seems to be very good with crisp and clean sources. Though I now think the turning point where Snow starts to look better than XviD is a bit higher than I thought - perhaps around H.263 quant=5 or 6. Where savings start to get really good is more in the Realvideo arena. 85% quality is perhaps the lowest I would go. It doesn't have to hide behind Ateme's h.264 at these bitrates, I believe. At that quality percentage Snow still looks quite yummie with clean sources and is 1/3 or so smaller than XviD at h.263 quant=5 -- it doesn't look so nice when the source is of the shabby kind.

[Nic]

Me and trbarry (when he can) are working on Assembly for it.

I've got snow.c compiling in Visual Studio with Intel Compiler, which makes things a little faster...

Slow and steady... ;) (nothing new from Michael though)

-Nic

ps
I'll encode a Matrix scene and put it up, for you to look at when I get chance :)

[Teegedeck]

Thanks for the work, Nic! :) And so good to hear of trbarry; he's only here on the forum once a month or so lately.

[Nic]

grr, my computer's fan's broken so it was getting too hot to create a demo, i'll try it again tonight, might put up my little commandline app I use for testing too (AVS->Snow AVI)

-Nic

[Nic]

Snow Demo:

http://nic.dnsalias.com/snow_860kbps.avi
(SNOW 860kbps, 18mb, 2:54secs, 640x336)

Only try to play this with the latest version of VideoLan or MPlayer and only if you have a fast computer! (and I mean fast ;) )

This example isn't the best, I just coded it up quick, even with a few tweaks quality can be better, and remember that Snow's overlapped motion code doesn't even work yet....the improvements should be impressive when it finally does.

-Nic

[Tommy Carrot]

Originally posted by Nic
Only try to play this with the latest version of VideoLan or MPlayer

The recent FFdshow builds can play it back too. Btw, this (http://www.fw.hu/carrotland/snow_278.avi) is my contribution to show the low bitrate capability of this codec. ;) It is 278 kbps, and the resolution is 720*288. /Actually it's the same clip i made at the beginning of this thread, but that's not decodable with the current version anymore, so i simply remade it with the latest build./

[Nic]

Nice clip :)

I'm thinking about starting a thread in the development forum to help me with mmx'ing of alot of the code and addressing which bits are slow and how to speed them up (only really looked at encoding so far (as that's been easier for me to test))

recent FFdshow builds can play it back too
I can't remember now how I turned it on in the latest build of ffdshow...but I remember it taking more processing power than MPlayer (which plays it the best (for me) anyway)

-Nic

[Mug Funky]

yes, very nice clip. i seem to be getting some jumpiness - sort of halfway between dropped frame(s) and frame-order problem. particularly at the start of the jump scene (around morpheus' jump).

decoding with ffdshow (haven't downloaded an updated mplayer binary yet, and too n00b to compile my own). think i'll give celtic druid's site a visit.

[Tommy Carrot]

Originally posted by Mug Funky
yes, very nice clip. i seem to be getting some jumpiness - sort of halfway between dropped frame(s) and frame-order problem. particularly at the start of the jump scene (around morpheus' jump).

There is no dropped frame or frame-order problem, it's just snow's horrendous playback requirement. :D Your cpu is probably not sufficient for realtime playback. Snow in it's current form is very unoptimized, but Nic and Trbarry are already working on the case.

[billou2k]

It plays fine here (P4 dual 3Ghz;-)
Quite impressive I must say! 720x288 @ 278kbps...
Of course it's not DVD quality but way more watchable than most lower resolution clips based on DCTs codecs with more than twice the bitrate...
The force is strong in this one!

[Nic]

trbarry is working on little bits I show him when he can, I will start posting in the development forum about it, so perhaps other great coders (like sh0dan, etc) can offer help....But for now I've only been working on the encoding code, I think it's the decoding code that really needs attention

(The clip I made runs fine on my 3.2ghz at home, but my 2.4ghz can barely play it)

-Nic

[Mug Funky]

definitely the decoding side needs work. encoding is expected to be slow, but when people start getting useful decoding speeds the enthusiasm for this codec will grow a lot.

@ tommy carrot: yeah, under the mplayer i just downloaded (defaults to no framedrops), it plays every frame. nowhere near realtime of course :) my machine is old and it's going to stay old - i hate throwing things out, and i can't really afford to anyway.

[edit]

OBMC isn't on yet? wow. i can't wait to see it when it works! it's already giving me bitrates that i wouldn't consider even for audio, but delivering good quality. with OBMC i feel that artefacts would be reduced hugely.

[akupenguin]

OBMC is enabled, but the encoder doesn't take it into account. It runs motion estimation and macroblock decisions based on plain block-based motion, and then overlaps them. This is better than nothing, but far from optimal.

[chilledoutuk]

It does use a fair wack the decoder but never the less it only used 80% of my athlon xp barton core running at 2ghz.

nic the qulity of that scene is nice but out of aspect.

[Joe Fenton]

I was playing the two clips in Fedora Core 3 for the AMD64 on my Opteron 240 (1.4GHz CPU). The snow_278.avi clip takes about 50%-55% CPU and the snow_860kbps.avi takes 88%-94% CPU in ffplay (cheesey SDL player for ffmpeg). This is a straight 64-bit compile of ffmpeg without any optimizations. So I would say that any 64-bit machine will handle snow rather well. Looking forward to future updates to this codec.
:)

[Mug Funky]

for a bit of fun, try this with mplayer:

mplayer -idx blurt.avi

and attempt seeking with the arrow keys after a couple of seconds (it crashes if you hit it too fast).

nice effect :) dancing, pulsating gelatinous wavelets.

one thing - i've noticed a tendency for this mess to drift to the upper left. is that a motion estimation thing?

[MfA]

Just curious (and lazy) has snow been profiled? How is decoding time divided between inverse wavelet transform and bitstream decoding?

[akupenguin]

A decode at qscale=4:
7% bistream reader (including dequant)
19% wavelet
74% motion compensation

The same movie, at qscale=2:
7% bistream reader (including dequant)
17% wavelet
76% motion compensation

[Nic]

I'm using Visual Studio 6's profiling and CodeAnalyst to help me profile snow.c, if you'd like a csv dump of the functions / lines cpu usage let me know.

Basically the functions inside snow.c that take the most processing are (from memory):
lift/lift5
mc_block (or it's h264_put_pixel equivalent)
add_yblock
(the vertical compose wavelet functions too)

For decoding...those are the main ones.

-Nic

[trbarry]

Nic -

What percentage of time does mc_block take?

- Tom

[SteMa]

What do you mean by "horrendous playback requirement"
I was doing a nero recode process (to h264), and meanwhile i was able to play both clips fine on my athlon xp 2000+ (latest mplayer: MPlayer-mingw32-dev-CVS-041204.zip)

[Nic]

@Tom:
Some statistics from profiling for you :) :
(This is for decoding)


Profile: Function timing, sorted by time
Date: Mon Dec 06 20:52:52 2004


Program Statistics
------------------
Command line at 2004 Dec 06 20:51: "C:\Development\Projects\SNOW\Release\SNOW"
Total time: 5259.269 millisecond
Time outside of functions: 23.526 millisecond
Call depth: 9
Total functions: 1345
Total hits: 43844295
Function coverage: 8.9%
Overhead Calculated 1229
Overhead Average 1229

Module Statistics for snow.exe
------------------------------
Time in module: 5235.744 millisecond
Percent of time in module: 100.0%
Functions in module: 1345
Hits in module: 43844295
Module function coverage: 8.9%

Func Func+Child Hit
Time % Time % Count Function
---------------------------------------------------------
1001.903 19.1 2742.057 52.4 2048004 _add_yblock (snow3.obj)
761.687 14.5 761.687 14.5 1551723 _mc_block (snow3.obj)
620.398 11.8 620.398 11.8 780600 _lift (snow3.obj)
326.461 6.2 486.348 9.3 7159351 _get_rac (rangecoder.obj)
291.836 5.6 1508.446 28.8 4526556 _pred_block (snow3.obj)
231.708 4.4 231.708 4.4 9184554 _same_block (snow3.obj)
200.973 3.8 200.973 3.8 260200 _lift5 (snow3.obj)
189.875 3.6 666.051 12.7 9600 _decode_subband (snow3.obj)
159.888 3.1 159.888 3.1 7159351 _refill (rangecoder.obj)
136.218 2.6 136.218 2.6 130400 _vertical_compose97iL1 (snow3.obj)
126.815 2.4 126.815 2.4 129800 _vertical_compose97iH1 (snow3.obj)
81.404 1.6 81.404 1.6 129800 _vertical_compose97iH0 (snow3.obj)
79.923 1.5 79.923 1.5 130400 _vertical_compose97iL0 (snow3.obj)
77.051 1.5 77.051 1.5 3962304 _av_log2 (snow3.obj)
65.789 1.3 65.789 1.3 246160 _ff_emulated_edge_mc (extras.obj)
61.215 1.2 61.217 1.2 395408 __intel_fast_memset (vecmem.obj)
60.451 1.2 324.188 6.2 279435 _decode_q_branch (snow3.obj)
49.982 1.0 2792.038 53.3 600 _predict_plane (snow3.obj)
48.142 0.9 193.481 3.7 631993 _get_symbol2 (snow3.obj)
44.996 0.9 175.282 3.3 574188 _get_symbol (snow3.obj)
28.785 0.5 28.785 0.5 49004 _put_h264_qpel8_mc23_mmx2 (dsputil_mmx.obj)
28.680 0.5 28.680 0.5 550527 _put_h264_qpel4_mc00_mmx2 (dsputil_mmx.obj)
27.580 0.5 27.580 0.5 46571 _put_h264_qpel8_mc21_mmx2 (dsputil_mmx.obj)
26.202 0.5 26.202 0.5 47627 _put_h264_qpel8_mc12_mmx2 (dsputil_mmx.obj)
25.142 0.5 25.142 0.5 62559 _put_h264_qpel8_mc22_mmx2 (dsputil_mmx.obj)
24.313 0.5 24.313 0.5 44534 _put_h264_qpel8_mc32_mmx2 (dsputil_mmx.obj)
24.143 0.5 845.514 16.1 260200 _horizontal_compose97i (snow3.obj)
23.213 0.4 23.213 0.4 373798 _put_h264_qpel8_mc00_mmx2 (dsputil_mmx.obj)
21.921 0.4 33.737 0.6 1 ___sti__$E (avsreader.obj)
20.266 0.4 20.266 0.4 49035 _put_h264_qpel8_mc10_mmx2 (dsputil_mmx.obj)
19.951 0.4 19.951 0.4 65588 _put_h264_qpel8_mc31_mmx2 (dsputil_mmx.obj)
19.628 0.4 19.628 0.4 67245 _put_h264_qpel8_mc33_mmx2 (dsputil_mmx.obj)
19.413 0.4 1295.746 24.7 3000 _spatial_compose97i (snow3.obj)
19.364 0.4 19.364 0.4 67889 _put_h264_qpel8_mc13_mmx2 (dsputil_mmx.obj)
18.937 0.4 18.937 0.4 63764 _put_h264_qpel8_mc11_mmx2 (dsputil_mmx.obj)
18.263 0.3 18.263 0.3 608150 _mid_pred (snow3.obj)
17.101 0.3 17.101 0.3 279435 _set_blocks (snow3.obj)
14.358 0.3 14.358 0.3 1 _dsputil_static_init (dsputil.obj)
14.099 0.3 14.099 0.3 117 _av_malloc (mem.obj)
11.884 0.2 11.884 0.2 1 _avpicture_fill (imgconvert.obj)
11.816 0.2 11.816 0.2 1 CAVSReader::CAVSReader(void) (avsreader.obj)
10.770 0.2 10.770 0.2 54939 _put_h264_qpel8_mc30_mmx2 (dsputil_mmx.obj)
10.294 0.2 10.294 0.2 50518 _put_h264_qpel4_mc22_mmx2 (dsputil_mmx.obj)
9.726 0.2 9.726 0.2 63952 _put_h264_qpel8_mc03_mmx2 (dsputil_mmx.obj)


Sorry for the long post,

@SteMa: Good for you :) But for other low spec machines, it takes a little too much processing. (Like a Duron 800 can play DivX just fine, it wouldn't play any Snow)

-Nic

[trbarry]

Nic -

Thanks. I'm still tinkering with mc_block. Should hopefully have something soon.

- Tom

[Nic]

Thanks loads Tom, something's cropped at work, that will keep me busy most of the week, but after that I can get back to working on it. Hope your work on it goes well, let me know if you need any stats or anything...

-Nic

[Paazabel]

I know this isn't exactly the forum for this question, since things here revolve around storage of existing content.

However, the low-bandwidth encodes from this codec are staggeringly impressive. What are the prospects of it being optimized enough at some point to actually stream a live input? Slim to none? Needs 50 tons of hardware? Just a hobby and hadn't thought about it?

I'm simply awed by the quality of the 278k clip. It is really jaw-dropping.

[Paazabel]

Oh, I would also like to beg for smart interlacing support. There are lots of ways to do it, from unfolding the fields to doubling the rate. Having this done at the codec layer would be massively helpful, but I'm sure it's low on your list of things to do (if it's there at all).

Things like classic superbowl games or other sports still look better in a 50 or 60 field format.

[PatchWorKs]

Any friendly interface ideas ?

Check out QuEnc or NuEnc

http://www.pcpages.com/dragongodz2/
http://www.petersplace.000k2.com/projects/

[Teegedeck]

Actually, QuEnc is Nic's baby, so you don't need to worry about the interface.

[dragongodz]

QuEnc is Nic's baby
so does that make me an uncle ? ;)

sorry couldnt resist. :D

[Teegedeck]

Ohhh; I didn't want you to feel left out! :)

[MSlv]

So, you're saying Snow will soon be no. 1 when it's ready? Who's developing it? Is it open source? Will there be a tool to encode DVDs to Snow? How much % is it done?

[Tommy Carrot]

Yep, it's opensource, it's part of the libavcodec, so there are many programs with snow support (ffmpeg, ffdshow, mplayer/mencoder, videolan, etc.).

It's hard to say what will become from it, it's an experimental codec, very promising but not mature enough for practical use, and there is no guarentee that it ever will be (i guess it depends on Michael Niedermayer, the main developer). Dirac, which is a similar codec, will probably be a safer choice.

[Teegedeck]

Aren't Dirac's sources a little developer-unfriendly (or so I remember to have heard)?

[Nic]

Dirac's sources are fine really. Heavy C++ code, but fine...But i've tried Dirac on several occasions, and have never been impressed :( Which is a shame, because i'd like the BBC to succeed :)

Snow wouldn't take much IMHO, to become mature enough for practical use. I can decode FD1 it in over 2x realtime and encode at 10+ fps. And the quality is superb. I'm not sure, unless things have changed dramatically, the same can be said for Dirac.

-Nic

[Tommy Carrot]

No doubt, right now Snow is a lot better, Dirac is really not impressive, but i still feel that Dirac might have a more assured future. It has a commercial support, a roadplan, etc, while snow is developed purely by enthusiasm, so if you or the other developers become bored with it, the development would probably stop, while the involvement of BBC prevents this to happen with dirac. But this is just the worst case scenario, obviously i hope Snow will soon surpass h.264 and take over the video-encoding scene. :D

[Paazabel]

My take on the playout of Snow is that it will spur the commercial companies to make a better product. The likes of Microsoft or DivX may or may not surpass Snow's capability, but it will force them to make something that is at least competitive. Right now, they both look like crap at low bandwidth where Snow may still look very usable.

After playing with it for a week, I really like this codec. There's a lot of promise, here, even if in the long run it is not realized by the Snow developers themselves.

I also think the killer app for Snow is live programming. You can get a very usable video from Snow at bandwidth much below some of the others. Snow would have to be multi-processor-friendly to accomplish this in real time, but it's certainly not out of the question to process in real time.

As said by others, my experience has been that at higher bandwidth, you are better off with other techniques -- so for "DVD backup," the application may be more limited. I am starting to bias toward quality in that arena, particularly as bigger hard drives get ever cheaper. However, having a really good-looking 500kbps live, streaming video -- that is something none of the other codecs can really deliver (despite their claims).

[chilledoutuk]

I must say that having recently updated ffdshow the quality of snow has improved a lot.
I am begining to see how good this codec could become possibly to wavelet codecs what xvid is to DCT codecs.

[PatchWorKs]

Interesting discussion... do you think that Snow could be an incarnation of Tarkin ? :rolleyes:

I mean... what about Xiph ? Could them help ? Or... could you help them ? :cool:

[iwod]

Originally posted by Nic
Dirac's sources are fine really. Heavy C++ code, but fine...But i've tried Dirac on several occasions, and have never been impressed :( Which is a shame, because i'd like the BBC to succeed :)

Snow wouldn't take much IMHO, to become mature enough for practical use. I can decode FD1 it in over 2x realtime and encode at 10+ fps. And the quality is superb. I'm not sure, unless things have changed dramatically, the same can be said for Dirac.

-Nic

Well... Even though i like BBC but i hate the name Dirac :D :D so much and love the name Snow too much :cool: so i really hope Snow can suceed... I would just like to know who is currently developing Snow...

[Nic]

It's all Michael Niedermayer that created and develops Snow. It's part of the ffmpeg project (which he kind of runs/oversees).

I want to develop it further, and hopefully will with christmas coming up (and therefore hopefully, some spare time)

-Nic

[Tommy Carrot]

Originally posted by PatchWorKs
Interesting discussion... do you think that Snow could be an incarnation of Tarkin ? :rolleyes:
I think the they have different goals. Tarkin would've been a royalty- and patent-free codec, but because of this restriction, xiph was unable to make it remotely competitive with the modern codecs (in fact, they couldn't make a working version of it, and it has been proved that making a competitive codec without motion compensation is impossible). I the case of Snow, i doubt Michael cares about patents, i think he just wanted to make a state of the art wavelet codec.

[Nic]

I know Michael is concerned with patents, but he may well ignores the ones he feels are "stupid" ;) . I know he wrote a different arithmetic coder for ffv1 and snow rather than use CABAC, because of patent reasons...

What patents exist on OBMC, Daubechies wavelets, lifting scheme, etc are unknown to me...anyone else know?

-Nic

[Teegedeck]

The codec really has improved a lot - the 85% quality-setting becomes watchable. I encoded a DVB-T movie last night and it came out 200 kbps... quite staggering. I think I'm gonna use Snow for intermediate storage of that bad DVB-T stuff when I don't get around viewing it at once. Good work, Nic and Tom! Thank you.

[chilledoutuk]

Dont forget Michael Niedermayer and yes what to me has improved the most is the stability of the image.

p.s what settings everyone using I am not using qel at the moment as it just use to much cpu to playback.
On my music videos it seems to be evry good indeed and I look forwad to further improvements.

[trbarry]

Good work, Nic and Tom!

Thanks, but I really haven't done anything on it yet except look at optimizing a couple things in asm that have probably not been released yet.

The credit goes to Nic, and of course Michael.

- Tom

[Joe Fenton]

Originally posted by Nic
I know Michael is concerned with patents, but he may well ignores the ones he feels are "stupid" ;) . I know he wrote a different arithmetic coder for ffv1 and snow rather than use CABAC, because of patent reasons...

What patents exist on OBMC, Daubechies wavelets, lifting scheme, etc are unknown to me...anyone else know?

-Nic

Pretty much anything associated with wavelets is patented. Last time I checked, there were several hundred patents covering wavelets for video compression. Even just using the term wavelet is patented. ;) :D

A quick search on the USPTO database on the term wavelet gives a hit on almost 3600 patents. So you can get an idea of just how easy it is going to be to make a commercial wavelet codec in the next 20 years. :p

People could see the promise in wavelets, so every conceivable idea in which wavelets could be used has been patented three or four times over. The sheer quantity of submarine patents on wavelet usage is mind-boggling. Yet another reason I hope that software patents will one day get thrown out.

[trbarry]

People could see the promise in wavelets, so every conceivable idea in which wavelets could be used has been patented three or four times over. The sheer quantity of submarine patents on wavelet usage is mind-boggling. Yet another reason I hope that software patents will one day get thrown out.

That is extremely depressing and I will try not to think about it.

- Tom

[iwod]

Originally posted by trbarry
That is extremely depressing and I will try not to think about it.

- Tom

What happen if we do use it. I mean patent is properly the most stupid thing about Software development. Simple thing now get patent for no reason.

OH... how i now learned to love open source.

[PatchWorKs]

Pretty much anything associated with wavelets is patented.
If is true, i think that BBC can cover some costs...

Or do you wanna see another "OpenDivX to XviD" mutation ?

[Paazabel]

The big problem would be people who want royalties. Making their "patented idea" into an open source where everyone had access to it for free would probably make their skin crawl ...

One way to keep such people at bay would be to use a corporate investment or front for this codec/technology accompanied by an insurance policy. Essentially, you would buy "patent insurance" to pay off anyone coming after your work. Make an insurance company lawyer go fight with any "submarine" patent holders ...

This, of course, would incur a cost; but it would be way cheaper than paying off everyone who shows up at your door crying "wavelet theft." That would still make the technology accessible, although for a small fee instead of free.

Killing technology with lawyers is just an evil practice. I hope we get past it, someday. I would hate to see SNOW end up a casualty of such incivility. It really does amazingly well with very little bandwidth.

Side note:
I've been pre-processing my SNOW encodes with PixieDust, Kernel Deinterlacer, and the Dup filter, and I have gotten some very usable video even down in the sub-200k ranges. It works especially well with "talking head" video from work that I have been experimenting with. Everyone has said it already, but there is really a lot of promise, here. For this particular training video, I used a mono 32k voice track with about 180-190k video encode. It gives a really small file, but when the speaker flashes up a slide (static video), SNOW has a little fit. I noticed that even after using the dup filter where each frame is made identical, SNOW seems very busy. :devil:

[Dali Lama]

Originally posted by Nic

(The clip I made runs fine on my 3.2ghz at home, but my 2.4ghz can barely play it)

-Nic

Just wanted to let everyone know that I can play Nic's and Tommy Carrot's clips fine on my 1.7 Ghz Centrino. Actually, I have no problem playing back 1080p24 MPEG2/WMV on my computer either. I wonder why the Centrino can do this while other processors can't, even at higher clock speeds?

-Dali

[Tommy Carrot]

Originally posted by Dali Lama
I wonder why the Centrino can do this while other processors can't, even at higher clock speeds?
Probably because it's better. :D Intel sacrified efficiency for higher clockspeed in the Netburst(P4) architecture, because higher clockrates are more marketable. Centrino is much more efficient for a given clockspeed, it's comparable to athlon 64.

[chilledoutuk]

I would say more comparable to an athlon xp processor clock for clock.

[Joe Fenton]

It's more efficient at integer operations. Centrino/PentiumM suck at floating point. I'm not sure how the MMX/SSE operations compare. So depending on the codec, Centrino/PentiumM do very well at low frequencies compared to P4s.

[ffmpeg]

In my AMD 850MHz,
It's terrible to try SNOW codec!

[Mug Funky]

you're welcome to have a go at optimizing it :)

[b0b0b0b]

Just wanted to chime in, snow is looking very good. At 95 quality, the file size ended up being about 1gig for a 2.5hr movie, and the picture was great. Thanks Michael Niedermayer, you the man

[Teegedeck]

At that quality you'd do better with an MPEG-4 (ASP or AVC) codec, though. It seems to me that Snow's sweetspot is more around 85-90%.

[Tommy Carrot]

Originally posted by Teegedeck
At that quality you'd do better with an MPEG-4 (ASP or AVC) codec, though. It seems to me that Snow's sweetspot is more around 85-90%.
Well, Snow is not worse than xvid at higher bitrates, or at least it has the potential to beat it even there if a few issues will be fixed. The biggest problem is the picture vibration, xvid has very smooth (not in the blurry meaning), rock-solid motions, probably due to the highly polished ME, while there are little jumps, vibrations in Snow. The other problem is the color mismatching: in spots the image is more green or purple than the original frame was.

I think these are some general illness of the wavelet codecs, because Rududu had both of them as well, but if Michael or someone else can fix them, i think Snow will catch Xvid even at high bitrates, because in my opinion Snow is just as sharp and preserves just as much or even more details at high bitrates too, just these problems are spoiling the quality a little bit.

[Teegedeck]

I certainly hope so. :) Delivering DVD transparency (being undestinguishable from the original DVD) is the aspect which interests me most in a codec's performance.

At the moment I'm very content with XviD for transparency at about 40-50% of the original MPEG-2 and Snow for non-transparent but higher compression.

[gino25]

Hello,

i have read all but i haven' t understand.

How can i use snow codec?

Must i download and install ffdshow?

Thank you very much

[hellfred]

There are two main ways to encode using snow codec.
Either get yourself latest ffdshow and encode with any encoding utility that makes use of M$ vfw or DShow API.
That would be e.g. VirutalDub(Mod), avs2avi etc.
CelticDruid build some ffd_snow.dlls to replace those that come with ffdshow, but i do not know wether they are still needed or not.
The other way to test the codec is to download latested precomliled binaries from mplayerhq.hu (or compile mplayer yourself) that ship with the encoding app of mplayer, called mencoder. mencoder is run via commandline, provides you with a varity of filters to process the image. There are also some GUIs to help you getting started. Have a look on the mplayer homepage in the section related projects (nav menue on the left side!).
And didn't Nic enhance his QuEnc to encode using snow?
That should be enough to get you started.
Hellfred

[celtic_druid]

Snow is part of libacdodec.dll, you also need a ffdshow frontend that is new enough to use it.

Otherwise mencoder or ffmpeg.

[hellfred]

Originally posted by celtic_druid
Snow is part of libacdodec.dll, you also need a ffdshow frontend that is new enough to use it.

Otherwise mencoder or ffmpeg.
Sorry, i have mixed it up with x264, havn't I?
Hellfred

[gino25]

thank you very much

[ffreese]

are there any video-samples available on the net? trailers or whatsoever?

[bond]

Originally posted by ffreese
are there any video-samples available on the net? trailers or whatsoever?what about reading the thread? there are some links to samples... :rolleyes:

[ffreese]

Originally posted by bond
what about reading the thread? there are some links to samples... :rolleyes:

ok - Give me a RTFM :)

I´ve read the thread another time and I found them :)

Even though i´m too blind to see links, I am very impressed of the quality. But as long as no standalone-dvd-player supports snow-wavelet, nobody cares for it. So what about chip-desginers implemating snow-decoding?

[Razorblade2000]

what about developing the codec to a level near beta stage and THEN thinking about specifications for decoder chips :rolleyes: :D :sly:

[Shinigami-Sama]

Originally posted by Tommy Carrot
Probably because it's better. :D Intel sacrified efficiency for higher clockspeed in the Netburst(P4) architecture, because higher clockrates are more marketable. Centrino is much more efficient for a given clockspeed, it's comparable to athlon 64.
I thought even one knew this by now there was a big thing going about a while back
centrino=3 parts working to gether
cpu+moble thing+I forogt the other part:(
but anyways
the parts work to reduce overehad bs and bottlenecks that intel has like freackles on a rednhead
and on a side note
does anyone know if this now playable on "the core media player" yet
or do I have to get yet anohter mediaplayer to play them yet?

[akupenguin]

Snow should work in any media player via ffdshow.

[Shinigami-Sama]

thats what I was thinking but weirder things have happened to me:rolleyes:
so I'll try out hte snow samples soon :)
I have a fairly fast rig
so it be a desent test subject to snow:devil:
:)

edti
well
tcm winamp and mpc don't play it
I just looked at hte codec list of teh ffdshow I just got off source forge
snow isn't there :confused:
the vers i have is newest one thre
but it;s only oct 12 :confused:
this is weird
when I get back I'll look for the new one...
*is off for chinise food :p*

[celtic_druid]

Oct 12 didn't contain SNOW. Check the encoder list and if it doesn't show up, then it can't decode it.

[Shinigami-Sama]

I noticed
so I'm going to find the new one
even though sourceforge should have is :confused:
I;ll check around here for it
~~edit~~
well I must be blind
I've just finished looking for a newer one
for last 15min
and cheked the dl section of the main page
sourcefourge again
the ffdshow "about" menu for more links
and searched the boards for it
and still can't find it :(
~~edit2~~
ok I found it =)
had some hassles installing it
had to rename ffdshow.ax or what ever
but it all works
and that "snow_860kbps.avi" test file
man it;s sweet quality for only 860..
but no sound
so that would bring it up to about 1k
but the vid looked a bit smuched like it wasn;t letterboxed enough
other than that
exalant start for a codec :)
ok cpu % and system specs on next post
<sorry for the double post but I think I'm running out of space in this one>

[Shinigami-Sama]

system specs
~~~~~~~OS Name Microsoft Windows XP Home Edition
Version 5.1.2600 Service Pack 2 Build 2600
OS Manufacturer Microsoft Corporation
System Name ORE-NO
System Manufacturer MICRO-STAR INC.
System Model MS-6728
System Type X86-based PC
Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3000 Mhz
Processor x86 Family 15 Model 2 Stepping 9 GenuineIntel ~3000 Mhz
BIOS Version/Date American Megatrends Inc. V3.3, 12/10/2003
SMBIOS Version 2.3
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume1
Locale United States
Hardware Abstraction Layer Version = "5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)"
User Name ORE-NO\Shinigami-Sama
Time Zone Pacific Standard Time
Total Physical Memory 1,024.00 MB
Available Physical Memory 623.79 MB
Total Virtual Memory 2.00 GB
Available Virtual Memory 1.96 GB
Page File Space 2.40 GB
Page File C:\pagefile.sys
~~~~~~~~~
cpu usage
lowest 20%
highest40%
average 32%-34%

[avih]

@Shingami-Sama:
obviously, you're very enthusiastic, which is a good thing :), HOWEVER, your posts are a bit hard to read as you seem to write them very hastely.

please take a minute after you write a post to review it, and make it easier to understand, especially for those who are not native english speakers.

thanks ;),
avih

[Shinigami-Sama]

ok I've fixed the posts
sorry but I've been watching a bunch of Japnsese shows latly and started to talk/type like them :)
it;s a good and bad thing though
and my wireles keyboard drops a few keys and mixes up the order ><
so I'll try and make them easier to read :)

[ZikZak]

I'm doing some tests with SNOW and I have to say that it is incredible.
Here is a trailer of a french movie : http://gameclash.org/bonus/Double_zero-FR.SNOW.avi

Video bitrate : 518.564kbps (snow)
Audio bitrate : 128kbps (mp3)
Size : 12MB

I used the following command line :
mencoder dvd://3 -alang fr -srate 44100 -af volume=15 -oac lavc -ovc lavc -vf crop=704:432:10:70,scale=480:208:0:0,eq2=1:0.8:0:1,pp=al/dr/vb/hb,hqdn3d -sws 7 -lavcopts acodec=mp3:abitrate=128:vcodec=snow:vstrict=-1:vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:scplx_mask=0.1:tcplx_mask=0.1:p_mask=0.05:naq:vqcomp=0.8:mpeg_quant:v4mv:qpel:trell:pred=0:mbd=0:subcmp=1:cmp=1:precmp=1:mbcmp=1:subq=8:vqscale=3 -o Double_zero-FR.SNOW.avi

You can play the file with the latest version of VLC, it is available on this page : http://videolan.org/vlc

Regards
--
ZikZak

[Shinigami-Sama]

wow
thats prety good
12mrg file and 2.5min
and good qual too
this would be a nice little codec if there was some more work done on it

[akupenguin]

@ZikZak:
You know that
vlelim=-4:vcelim=9:lumi_mask=0.05:dark_mask=0.01:scplx_mask=0.1:tcplx_mask=0.1:p_mask=0.05:naq:vqcomp=0.8:mpeg_quant:trell
does nothing in Snow, right?

[ZikZak]

Thanks for the tip akupenguin, I will remove these options if they are not used.
vqcomp is not useful ?
Trell doesnt change the quality on my video if I remove it, Is it useful to keep it ?

[akupenguin]

All of those options are useful in MPEG-4, but are not yet implemented in Snow.
vqcomp is related to 2-pass.
Trellis may never be useful in Snow, since trellis is a method of optimizing for Run-Level coding, while Snow uses Arithmetic coding.

[ZikZak]

Is there a way to have the list of options used by SNOW ?
Currently, this codec is unbelievable, the result is incredible but there is a big problem, it is cpu intensive, one of my test doesn't run smooth on a P4 2,4GHz with 512MB.

Sorry for my bad english.
--
ZikZak

[Doom9]

@ZikZak: perhaps not what you're looking for, but MeGUI is a mencoder GUI for the lavc mpeg-4 asp codec, the x264 codec and the snow codec. In case of the latter two, all mencoder switches offered for those codecs are exposed.

[akupenguin]

There is no list in the manpage or the program. But the options are:

vqscale
cmp, subcmp, mbcmp: useful values = 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet). I find SSD to be best most of the time.
pred: 0 (9/7 wavelet), 1 (5/3 wavelet), 2 (13/7 wavelet). I find 9/7 to be best for lossy coding, 5/3 for lossless.
qpel: always helps compression, but costs some cpu time both encoding and decoding.
v4mv: may or may not improve any given video.

v4mv and the wavelet cmp functions are theoretically good, but in practice won't work well until we get OBMC-aware motion estimation.

[Shinigami-Sama]

it;s nice to see things moving her again
I would love ot help out by testing but...
I found out my power supply is to small and everytime I run a high power app I run out of power and I crash so no encoding for me for a while :-(

[ZikZak]

Originally posted by akupenguin
There is no list in the manpage or the program. But the options are:

vqscale
cmp, subcmp, mbcmp: useful values = 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet). I find SSD to be best most of the time.
pred: 0 (9/7 wavelet), 1 (5/3 wavelet), 2 (13/7 wavelet). I find 9/7 to be best for lossy coding, 5/3 for lossless.
qpel: always helps compression, but costs some cpu time both encoding and decoding.
v4mv: may or may not improve any given video.

v4mv and the wavelet cmp functions are theoretically good, but in practice won't work well until we get OBMC-aware motion estimation.

For pred=2 : I do not use it because VLC crash if my video is encoded with this value.
In fact all these options are available in the mplayer manpage but i did not know wich one was related to the SNOW codec.

Thank a lot for the help.

[DeathTheSheep]

What the heck is going on with SNOW? The revolutionary new codec has fallen into ... what? Nothingness?

Nobody wants to work on SNOW anymore? It could beat Xvid. And it would rock at low bitrates if some of that terrible noise was cirvumvented.

Has no one realized its power? Or is it too dang abnormal and difficult to code because it uses a completely new approach (or if not new, then different...)?

Well, I'm still curious. And anxious. C'mon SNOW!! After all of that praise and attention, you just... died?

My heart is broken.:scared: :scared:

[Razorblade2000]

Originally posted by DeathTheSheep
What the heck is going on with SNOW? The revolutionary new codec has fallen into ... what? Nothingness?

Nobody wants to work on SNOW anymore? It could beat Xvid. And it would rock at low bitrates if some of that terrible noise was cirvumvented.

Has no one realized its power? Or is it too dang abnormal and difficult to code because it uses a completely new approach (or if not new, then different...)?

Well, I'm still curious. And anxious. C'mon SNOW!! After all of that praise and attention, you just... died?

My heart is broken.:scared: :scared:

uhm yeah, what he said...

[Tommy Carrot]

Yep, it's truely disappointing... This is the curse of the one-man projects, if the developer is getting bored with it (or his free time is taken by the maintaining of ffmpeg), the progress is going to stop. The same happened to rududu codec. Ok, Snow is open source, so someone could continue to improve it, but very few people has the necessary knowledge to do it, and they are probably busy with other things.

[guada 2]

Hello Tommy,

I had an idea to keep the file HDTV 720p/24 achieved by Scharfis brain and, recode with Snow.

http://home.arcor.de/scharfis_brain/720p24.avi


I made some regulating of FFDshow. (92) and others..
There is the result:
- 720p/24 23 trames/s 392Kbts 12 bits xvid 2.66mo
- 720p/24 23 trames/s 196Kbts 24 bits ffds 1.33mo

The quality of the picture is superb.
But I have a problem, no player reads it in totality, it crashe to mid path and it is indeed a pity.
Do you think that this codec supports the high resolution?
What player will be asure the playing of this file?
Is that a mistake of the codec even him: Experimental Snow?

Thank you

Note: You'll excuse me if I missed a few something

[DarkFoon]

Originally posted by DeathTheSheep
What the heck is going on with SNOW? The revolutionary new codec has fallen into ... what? Nothingness?

Nobody wants to work on SNOW anymore? It could beat Xvid. And it would rock at low bitrates if some of that terrible noise was cirvumvented.

Has no one realized its power? Or is it too dang abnormal and difficult to code because it uses a completely new approach (or if not new, then different...)?

Well, I'm still curious. And anxious. C'mon SNOW!! After all of that praise and attention, you just... died?

My heart is broken.

I agree. I like this codec and the future it may have had... it was all bright and sunny with unicorns... *ahem*
Anyways, without any programming knowledge, I can't contribute to keep it alive. Thus, this is a plea to other programmers that they will pick up this forgotten child of codec world, and raise it to the glory it is destined. Otherwise, we'll have to wait until it is reincarnated as some other codec, maybe with a catchier name, and then hope that codec will make it in this cruel world...

[*.mp4 guy]

This is a real shame, especialy considering that it already scored higher on metrics then asp codecs...ah well:(

[Shinigami-Sama]

If I could code
I wuld gladly help
til then
bye snow ;_;

[ZikZak]

Originally posted by guada 2
Hello Tommy,

I had an idea to keep the file HDTV 720p/24 achieved by Scharfis brain and, recode with Snow.

http://home.arcor.de/scharfis_brain/720p24.avi


I made some regulating of FFDshow. (92) and others..
There is the result:
- 720p/24 23 trames/s 392Kbts 12 bits xvid 2.66mo
- 720p/24 23 trames/s 196Kbts 24 bits ffds 1.33mo

The quality of the picture is superb.
But I have a problem, no player reads it in totality, it crashe to mid path and it is indeed a pity.
Do you think that this codec supports the high resolution?
What player will be asure the playing of this file?
Is that a mistake of the codec even him: Experimental Snow?

Thank you

Note: You'll excuse me if I missed a few something

Hi,

Do you have a link to the ffds file ?

[Doom9]

could've, would've, should've. You know what programmers need: helping hands that write code.. not people asking for this and that (that's just annoying and kills your motivation faster than anyone can say please).

And Snow is not dead by the way.. just because you don't see progress for a while doesn't mean it is dead. Keep in mind that libavcodec is a huge construct... and not all parts won't progress at the same speed.

[Tommy Carrot]

Originally posted by guada 2
Hello Tommy,

I had an idea to keep the file HDTV 720p/24 achieved by Scharfis brain and, recode with Snow.

http://home.arcor.de/scharfis_brain/720p24.avi


I made some regulating of FFDshow. (92) and others..
There is the result:
- 720p/24 23 trames/s 392Kbts 12 bits xvid 2.66mo
- 720p/24 23 trames/s 196Kbts 24 bits ffds 1.33mo

The quality of the picture is superb.
But I have a problem, no player reads it in totality, it crashe to mid path and it is indeed a pity.
Do you think that this codec supports the high resolution?
What player will be asure the playing of this file?
Is that a mistake of the codec even him: Experimental Snow?

Thank you

Note: You'll excuse me if I missed a few something
I don't think that archiving with Snow is a good idea, as you said, it's experimental, so it's not made for practical usage. Not to mention that the decoding requirement is too high due to the lack of optimization, i doubt there is any CPU which could handle HDTV content (perhaps Power5, but that's all :D).

There is a bug in ffdshow, when the cpu usage exceeds 100% (in other words when it cannot decode the video realtime - this can easily happen with Snow :)), it simply freezes, and we have to manually shut it down in the task manager. It's also possible that the Snow decoding is borked, as it happened often in the past versions. I didn't experience this in the latest builds, but that doesn't mean it is completely fixed.

@Doom9: i don't think anyone has bugged Michael about Snow codec, he's simply not motivated anymore. Yep, people could help in coding, but - see my previous post.

[Doom9]

@Doom9: i don't think anyone has bugged Michael about Snow codec,not true.. I know I have just recently.

he's simply not motivated anymore.I can't speak for him but I didn't get that impression.. but email exchanges are essentially private so if he wants to say more it's up to him.

[guada 2]

Thank you Tommy for these explanations, :)

I confirm it this codec is very impressing and full of possibility.
The only problem remains its stabilization.
it pleases me a lot this codec.

It is astonishing its analysis, it makes me think about a codec Lossless video, when one reaches the value 100.
I can only encourage its development.

[mailto_robin2000]

I'm a novice in coding ...

Just how to compile the latest snow.c and update into the libavcodec.dll ...

[celtic_druid]

run ./configure with --enable-shared and it will build libavcodec.dll and libavformat.dll.

[JimiK]

I already tried that under MinGW. Should these files be usable for ffdshow? Besides, I get avcodec.dll and not libavcodec.dll
Best regards, JimiK

[celtic_druid]

No for ffdshow you need to run make in ./ffdshow/src/ffmpeg and as far as I am aware it is already using the latest snow.c as it hasn't been updated in the ffmpeg cvs since ffdshow last got updated.

There are also MSVC 6/7 make files.

[Tommy Carrot]

Good news! It seems Snow is not completely dead after all. :) A few weeks ago Aku committed a patch which makes the decoding 10% faster, and today there is another change. Could someone explain to me what is this "slicing patch (http://sourceforge.net/mailarchive/forum.php?thread_id=6964451&forum_id=42241)", and what does it improve (i guess the speed, but encoding or decoding speed)?

[guada 2]

Look at here: http://home.att.net/~rpml/p02b/p02b_21.htm

[akupenguin]

Originally posted by guada 2
Look at here: http://home.att.net/~rpml/p02b/p02b_21.htm Huh? That link has nothing to do with wavelets or video.


The "slicing" used by Yartrebo and I is a technique whereby you send a small region of pixels (the "slice") through the entire decoding/display process before moving on to the next pixels. The alternative (which was done before because it is simpler) is to parse the whole bitstream, then motion compensate the whole frame, then compose the whole wavelet, then add prediction and residuals together, then display the frame.
Slicing does not change the amount of computation performed, but it improves cache coherence. And most video operations are memory-bound (at least once you have good SIMD; we're working on that too).
Slicing is trivial in MPEG-like codecs, since they are naturally broken into macroblocks that can be decoded one by one. But it requires some more complexity in wavelets.

So far we have only applied slicing to decoding. It would help encoding too, but encoding speed is less important so we'll do that later.

[guada 2]

Hello akupenguin, :)

I do not understand. The fact of maximaliser cutting in section should be enough to improve quality, whereas quality lies in the quantity of calculation. That would be then more complex than I believe it. But on what would the speed of coding be based then if this technique does not influence the distribution of calculation? Could you explain me that because I loses myself.

Thank you

[hellfred]

Originally posted by guada 2
Hello akupenguin, :)

I do not understand. The fact of maximaliser cutting in section should be enough to improve quality, whereas quality lies in the quantity of calculation. That would be then more complex than I believe it. But on what would the speed of coding be based then if this technique does not influence the distribution of calculation? Could you explain me that because I loses myself.

Thank you
Though i am no expert, here a short explanation. The codec needs data to work on. The data is stored in the file on your HD, transported slowly to the ram, from there to the much faster cache, which is on the CPU itself and can be accessed much faster then the data in the RAM, which can be acessed much faster than the data on the HD. So the CPU will be able to calculate non stop without having to wait for data from RAM or even HD, if you shorten the amount of data needed for the next decoding step in the way, that it easily fits into the cache. Without slicing, all the information for decoding a whole frames (with intermediat data which may be generated in the process of decoding) needs to fit into the cache to avoid, that the CPU is waiting for data from RAM or HD. But older system have usualy only limited cache, all neede data may not fit into the cache, and during decoding the CPU may have to wait for data from RAM. For those systems, slicing helps you the most, as the amount of data needed for no-stop decoding is reduced an fits into the smaller cache.

Hellfred

[guada 2]

hellfred, thank you for this explanation.

Moreover, by admitting that this system relieves the capacity of response of the treatment of the CPU, would not be it a brake with the decoding of video file HD?
Sincerely, I find judicious to use this codec at honourable ends such decoding of file vidéos HD. In made, I think that "Slice Patch" is not sufficient to answer the capacities of the decoding of this powerful codec.
I perceives it like a restritive alternative to decoding.

Note: sorry for my english and for the Link akupenguin.

[Yong]

Snow codec now is able to do 2-pass encoding in the new version of Mencoder (http://mplayerhq.hu/homepage/design7/news.html) , and faster decoding in mplayer, 640x480 playback in realtime only use ~70% of CPU usage :)

Here is the encoding options i used:
start /b /low /w mencoder %1 -audio-preload 2.0 -oac copy
-noskip -o nul: -ovc lavc -lavcopts
vcodec=snow:autoaspect:vstrict=-1:vqscale=1:vpass=1
-passlogfile "snow.log"

start /b /low /w mencoder %1 -audio-preload 2.0 -oac copy
-noskip -o "%userprofile%\desktop\%~n1.avi"
-ovc lavc -lavcopts vcodec=snow:autoaspect:vstrict=-1:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel:vpass=2:vbitrate=500
-passlogfile "snow.log"

Don't try to decode with ffdshow... :p
EDIT: removed the v4mv option, it sligthly slowdown the encoding/decoding speed...

[Doom9]

nice.. gotta update megui..

[guada 2]

Thank you Yong,

Then, Mplayer would be able to decode and read the codec Snow carried out with ffdshow?

[akupenguin]

Originally posted by guada 2
Then, Mplayer would be able to decode and read the codec Snow carried out with ffdshow?

No. Snow's bitstream format is frequently changing. Always use the newest CVS MPlayer or FFmpeg to encode or decode snow. Anything older will probably break.

[Doom9]

has anyone tested if the vrc_override (curve compression override, useful for credits and such) command in mencoder can be used for snow?

[Yong]

@Doom9:
From "Mplayer\DOCS\tech\Snow.txt"
OPTIONS RECOGNIZED BY SNOW:
vqscale=<0.01-255>
vpass=<1|2>
vbitrate=<value>
cmp, subcmp, mbcmp
pred=<0-2>
last_pred=<0-3>
qpel
v4mv

In short:
The best options in almost all cases are
vcodec=snow:vstrict=-1:vqscale=$N:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel

You can try it but i think it will be ignore by mencoder :P

[akupenguin]

Actually, most of the generic ratecontrol options also apply to snow w/ 2pass. I just updated snow.txt with some of them, but I forgot vrc_override. It should work, but I haven't tried it.

[Doom9]

I'm wondering about vrc_override.. in the manpage, allowed quantizers are 1-32, yet in snow, the entire range from 0.01 to 255 is allowable. What happens if you specify a credits quantizer > 32.0?

[akupenguin]

Despite what the manpage says, mencoder's only restriction is that it be an int. So quants 1-255 are available in rc_override.
Interally in lavc it's a float, so I'll fix that sometime.

[Doom9]

Does it make sense to offer non integer quant settings in snow? What is a non integer quant?

I realize 0.01 is the special lossless case (I'm using a checkbox for that in MeGUI so basically the up/down control increases/decreases the quant by one.. but so far I've not removed the possibility to specify decimal values)

[akupenguin]

A fractional vqscale does make sense:
In Snow, the internal quantizer is on an exponential scale (much like h264, except with 2% increments instead of h264's 12%), and just happens to be mapped to a linear scale in the API.
In lavc's mpeg-1/2/4, quantizer is an integer like you're used to. But vqscale controls rate-distortion decisions, and those need not be rounded to anything in particular. You can specify fractional vqscale for constant-quant encoding, and 2pass ratecontrol also produces fractional vqscales (which is why lavc doesn't have to dither quants like xvid does).


0.01 isn't a special case. 0 is a special case (lossless), and <=0.05 or so gets rounded to 0. But mencoder hasn't been modified to accept vqscale=0.

[yokem55]

Has development on Snow come to a crawl again? Does anyone know what Micheal's plans are with the codec?

[Zak Kingston]

Hi there,

has anybody downloaded the snow-parameters from the mplayer-site (mplayerhq.hu/docs/tech/snow.txt). It's been offline for days now :(

Thanks

[Yong]

Hi there,

has anybody downloaded the snow-parameters from the mplayer-site (mplayerhq.hu/docs/tech/snow.txt). It's been offline for days now :(

Thanks
hmm, this text file is included in mplayer source code, its under the "...\MPlayer\DOCS\tech" directory :)

[CREXbzh]

Yes, MPHQ had a great HW breakage, and the admin has not fixed it yet. Someone else is trying to put it back in business as we speak, but that's quite hard as it has to be done remotely.

As far as the doc is concerned: use a mirror: http://mplayer.ethz.ch/DOCS/tech/snow.txt you may find this post interesting: http://article.gmane.org/gmane.comp.video.mencoder.user/1366

[hellfred]

Hi there,

has anybody downloaded the snow-parameters from the mplayer-site (mplayerhq.hu/docs/tech/snow.txt). It's been offline for days now :(

Thanks

HOW TO TEST SNOW
----------------

Snow is an experimental wavelet-based codec made by the FFmpeg developers,
and while it is still in heavy development, it is already giving very good
results.
Be very careful though, as the format of the bitstream produced might
change, do not rely on it to store videos that you value.
For this reason, MEncoder will not encode without 'vstrict=-2' on the
command line.


OPTIONS RECOGNIZED BY SNOW

* vqscale=<0.01-255>
Encoding quality, sane range 1-10, default: 0 (lossless). May be
fractional.
A given quality in snow needs a somewhat lower qscale than the same
quality in MPEG-4.
Note that 0 may not be specified; if you want lossless encoding, you
must leave out vqscale.

* vpass=<1-3>
Activates internal two (or more) pass mode.

* vbitrate=<value>
Specify bitrate of the 2nd pass.
Don't use it for 1st pass as CBR isn't implemented yet, use vqscale
instead, and set it to a quantizer near the target average quant
of the final encode.

* lmin, lmax, vqcomp, vratetol, vrc_eq, vrc_override
Generic multipass ratecontrol options, subject to the same suggestions
as in other codecs.
lmin=1 can be useful for medium to high bitrates (see vqscale).

* cmp, subcmp, mbcmp
Set the comparison function, default: 0 (SAD).
useful values = 0 (SAD), 1 (SSD), 11 (5/3 wavelet), 12 (9/7 wavelet).
Experience shows that SSD is the best most of the time, while SAD is
slightly better the remainder of the time.
You can add 256 to any of the options to enable chroma motion
estimation for that comparison (e.g. mbcmp=257 for SSD with chroma),
but it doesn't seem to help much for the moment.

* pred=<0-2>
Wavelet type. 0 (9/7 wavelet), 1 (5/3 wavelet), 2 (13/7 wavelet).
9/7 is probably better for for lossy coding, and 5/3 for lossless.
NOTE: 9/7 wavelet doesn't work with lossless mode.

* last_pred=<0-3>
Tries a few extra predicted motion vectors before doing EPZS search,
default: 0.
This option has negligible effect on both speed and quality of snow,
so just leave it off.

* qpel
Refines motion estimation, default: off.
This setting always helps compressibility, but costs some CPU time
both while encoding and decoding.

* v4mv
Allows smaller motion partitions, default: off.
The current MB decision algorithm doesn't make very good use of this:
It improves quality, but also increases bitrate. (You could get
more quality per bitrate by reducing quantizer instead.)


v4mv and the wavelet cmp functions are theoretically good, but in practice
won't work well until we get OBMC-aware motion estimation.

In short:
The best options in almost all cases are
vcodec=snow:vstrict=-2:vqscale=$N:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel

[Zak Kingston]

Thank you guys :) :) :)

[Doom9]

has anybody ever gotten two pass mode to work? CQ works fine for me, but when I start using bitrates, I get completely unusable results and weird error messages (QP<=0.0 and tons of them before mencoder even starts the second pass). Here are my commandlines:

mencoder.exe "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.avs" -ovc lavc -o NUL: -passlogfile "2pass.log" -lavcopts vcodec=snow:vpass=1:vbitrate=700:pred=0:cmp=1:subcmp=1:mbcmp=1:vstrict=-2

mencoder.exe "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.avs" -ovc lavc -passlogfile "2pass.log" -lavcopts vcodec=snow:vpass=2:vbitrate=700:pred=0:cmp=1:subcmp=1:mbcmp=1:vstrict=-2 -o "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.avi" -of avi -ffourcc SNOW

[CREXbzh]

Do the first pass at constant quant, then the second pass with your target bitrate

[Doom9]

that worked, thanks. Kinda annoying though that either MeGUI remains broken, or I implement a workaround that I have to take out again once the first pass gets fixed.

[hellfred]

that worked, thanks. Kinda annoying though that either MeGUI remains broken, or I implement a workaround that I have to take out again once the first pass gets fixed.
By the way, the avs-input was implemented into mplayer/mencoder by Gianluigi Tiesi aka sherpya. But if i remember right, the implementation worked well only with one colorspace (AFAIK YV12) and had problems with other colorspaces. Has this issues been addressed?

Hellfred

[Doom9]

@hellfred: nope, but that's unrelated to snow, isn't it? couverttoyv12 should help though..

[hellfred]

@hellfred: nope, but that's unrelated to snow, isn't it? couverttoyv12 should help though..
If you get strange artefacts in snow encodes on win32 using mencoder and avs input, it might be your parameters, or problems with avs input. converttoyv12 should do the trick in the later case, if yv12 was the colorspace without problems. I have pmed sherpya and asked him.

Hellfred

[Liisachan]

Inspired by MeGUI, I tested SNOW 2-pass by encoding the same anime OP (opening clip) with about 20 different settings. I also asked a few people using different CPUs to try to play the resulted file on Windows 2000 or XP. One of the interesting results was, it doesn't play smoothly with ffdshow+Athlon 64 3200+, but it plays fine using CPU-optimized mplayer.

(1) Encoding
The following are what I found in my tests. Some of them may be just accidental, limited to this sample, and/or only valid for anime.

In the pre-tests, I felt SSD (cmp=1) is better than cmp=11/12, and slightly better than SAD (cmp=0), so I decided to use SSD this time.

The bitrate is 2200kbps, which is normal for anime OP: when the average bitrate for the whole episode is like 900kbps or so, OP often gets 2000-3000 because it's usually extremely high-motion compared to the body of the episode.

I also encoded the same clip with XviD and x264 for reference.

The same part of the same frame, magnified 200%:
http://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow/2src.pnghttp://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow/2xvid.pnghttp://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow/2snow.pnghttp://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow/2x264.png
Left to Right:

source
XviD (VfW) 1.1.0 beta2 (Koepi): 2-pass: MPEG, VHQ4 (also for bvop), qpel, Chroma, Trellis, No Turbo, No Cartoon mode
SNOW: dev-CVS-050813-01:18-3.4.4 (celtic_druid): 2-pass: cmp=SSD+Chroma, pred=1, last_pred=3, qpel, v4mv
x264: revision291 cli (celtic_druid): 2-pass: me 6, umh 64, bframes 6, pyramid, ref 15, analyse all+8x8dct, temporal, weightb, --filter 0:3
More sample pictures (http://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow.html). The actual video clips (http://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/).

I'd say, if (hypothetically) XviD scored 100 points and x264 scored 130 points, SNOW/VP7 would get 120 ~ 125 points. Maybe it's a bit unfair to compare x264 and SNOW now: I read that one of the essential parts of SNOW, Overlapped Block Motion Compensation (OBMC) (http://en.wikipedia.org/wiki/Motion_compensation#Overlapped_Block_Motion_Compensation), has not yet been implemented. This OBMC thing seems to be great. Besides, deblocking in x264, which is often problematic, works exceptionally well for anime. SNOW was, however, obviously better than XviD quality-wise in this test. Of course XviD is much better about the encoding speed, CPU load in decoding, and stability. As rough indicators (not necessarily reflecting the perceived quality), lumi-wise error-free pixels for XviD/SNOW/x264 were 42%, 58%, 69.5% respectively, chroma-wise error-free pixels were 66%, 73%, 79%.

Settings and results
pred=0 (9/7 wavelet) might be better, but:
- I couldn't use qpel with pred=0 because with that combination:

if v4mv is disabled, the encoding failed and stopped in the middle (with or without chroma ME)
if v4mv is enabled, the encoder worked but I got a lot of "dotted horizontal line" artifacts.


- pred=0 without qpel worked decently, but I got an artifact ('echoed' line) along this high-contrast horizontal edge.

http://www.fairyland.to/celtic_druid/Media_Player_Classic/codec_test/snow/art2.jpg

Those artifacts are gone with SSD and pred=1 (5/3 wavelet). So I focused on SSD+pred=1. (pred=2 (13/7 wavelet) was not usable, generating messed-up images.)


qpel without chroma ME didn't help much. The result could even become worse.
chroma ME without qpel helped chroma-wise (which may be obvious) but the result became slightly worse lumi-wise: With chroma ME, chroma errors (difference against the source) significantly decreased. In all the pixels (640x480) in 2217 frames, chroma-wise error-free pixels (Diff_U and Diff_V checked separately and averaged) are 70.9% without chroma ME, and 73.8% with chroma ME. However lumi noise slightly increased.
With both qpel and chroma ME, the result was the best both chroma-wise and lumi-wise.
The result was even better without v4mv but only numerically. Without v4mv, I got a lot of tiny artifacts, and the subjective quality was much better with v4mv.


Then I tested last_pred for qpel+chroma ME:

For last_pred=0 without v4mv, the encoding failed.
For last_pred=0 with v4mv, the result was worse than last_pred=3.


So, tentatively, this is the best settings I found for this sample so far:
mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:pred=1:cmp=257:subcmp=257:mbcmp=257:last_pred=3:qpel:v4mv:vqscale=2.0 -of avi -ffourcc SNOW -o "snowq2.avi"

mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=2:pred=1:cmp=257:subcmp=257:mbcmp=257:last_pred=3:qpel:v4mv:vbitrate=2200 -of avi -ffourcc SNOW -o "snow.avi"

(2) Decoding
Overlay Mixer and VMR-9 Renderless were tested:

AMD, 1808MHz: The sample file doesn't play smoothly.
Celeron 2 GHz: The sample file (video-only) plays decently, but the tester had a synch problem for the same video muxed with Vorbis audio.
Athlon 64 3200+: The file doesn't play with ffdshow smoothly, but it plays fine with CPU-optimized mplayer, i.e. celtic_druid's mplayer2005.08.13.Athlon-64.7z. It plays fine even when muxed with Vorbis.
Pentium 4, 3390MHz: The file plays flawlessly if the output colorspace is YUY2. The CPU load is around 50%. Fullscreen works fine too. RGB32 (ffdshow-side conversion to RGB) is possible but very CPU-intensive.
Pentium 4, 3.20 GHz +HT: The file plays flawlessly even if the output colorspace is RGB32. The CPU load is around 50%. Even the 'sourest' settings (fullsceen, MPC's internal softsub, max texture=desktop, buffering=0) are possible.


2005-09-07
VP7 sample added to the directory for reference.

[ReinerSchweinlin]

You took quite an effort on this one!! Thanx!!

[FireArse]

Where is the development with this project going? How has it progressed in the last few months?

F

[Tommy Carrot]

Breaking news! :D It seems that after several months of stagnation in the development, Michael finally found some new motivation, apparently he started to write a new overlapped block based motion estimation algorithm for Snow (the previous ME was developed for block-based codecs, so it was far from optimal for wavelets). I couldn't test it yet (and i'm not sure it's finished), but from what i've heard it can improve the quality big time, and also it's good to see that Snow is not completely dead after all.

[Sirber]

woot woot

looking after a new release! :D

[Sirber]

is "mbd=0:mbcmp=1" better than "mbd=1" ?
Which one is faster?

[Caroliano]

Good news!

[CruNcher]

Yeah indeed :)

[Liisachan]

CVS log for ffmpeg/libavcodec/snow.c (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/snow.c?cvsroot=FFMpeg)

And btw... mplayer 20060101 compiled by celtic_druid (http://ffdshow.faireal.net/mirror/mplayer/)

[CruNcher]

celtic_druid new builds require iconv.dll and intl.dll

[Sirber]

http://www.dll-files.com/dllindex/dll-files.shtml?iconv
http://www.dll-files.com/dllindex/dll-files.shtml?intl

Could someone comment on those settings?

http://forum.doom9.org/showthread.php?p=758553#post758553

[Liisachan]

I did quick tests with mplayer that celtic_druid compiled yesterday.
(1) OBMC (vme=8) may or may not help. If I'm not wrong, some resulted frames are pixel-identical even with or without OBMC. I need to do more testing.
(2) OBMC makes encoding about 10 times slower.


http://www.faireal.org/tmp/codec_test/5pics.png

300%
Original (Huffyuv RGB) / XviD 1.2.0-dev <cvs.head.2006.02.28> / RV40 aka RealVideo10 <Helix DNA Producer 11.0.0.2013>
x264 rev.458 <2006.03.06> / SNOW +OBMC <MEncoder dev-CVS-060306-21:51-4.0.2>

XviD / x264 / mplayer are the newest builds by celtic_druid.

Sample Clips (http://www.faireal.org/tmp/codec_test/) ~11MB

* SNOW encoding params are just copied from snow.txt (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/DOCS/tech/snow.txt), Revision 1.9, something like,

mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:vqscale=1:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel -of avi -ffourcc SNOW -o NUL
mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=2:vbitrate=732:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel:vme=8 -of avi -ffourcc SNOW -o "out.avi"

This is just a quick test. Unlike our September 2005 test (http://forum.doom9.org/showthread.php?p=708057#post708057), I didn't try to tweak anything yet...

[PatchWorKs]

XviD 1.2.0-dev / x264 rev 458 / SNOW

Can you post the original (uncompressed) frame too ?

[Liisachan]

Ok, I edited my post.

[Yong]

@Liisachan:
one more request,
can you post your snow encoding parameter? :)
(tested encode MPEG1 640x368 @ 30 fps, with v4mv + vme=8. now snow encoding speed is 1.63fps...)

[Liisachan]

Um, updated the post, but this was just a quick test, and I just copied the params from snow.txt. Unlike our tests in September, no tweaking at all... I'd like to do that later.

[iwod]

What were the bitrate done on RMvb?

[Liisachan]

avarage bitrate is (about) the same for each codec tested. as you can see, the resulted files (http://www.faireal.org/tmp/codec_test/) have the same size.

[Yong]

@Liisachan:
snow encoding with obmc really (unbearable :D )slow,
but im not sure celtic_druid already include this patch http://students.washington.edu/lorenm/src/x264/snow_obme_sse2.tar.gz
this patch might be help encoding speed with amd64 or p4 machine.(?)
My build had this patch included, but it still slow :p ...

[celtic_druid]

Nope. Not included in my ffmpeg/mencoder builds.

[CREXbzh]

Nope. Not included in my ffmpeg/mencoder builds.
It will eventually be committed in several days or weeks. You can follow the discussion here: http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/thread.html#8625

[Tommy Carrot]

I did quick tests with mplayer that celtic_druid compiled yesterday.
(1) OBMC (vme=8) may or may not help. If I'm not wrong, some resulted frames are pixel-identical even with or without OBMC. I need to do more testing.
The new iterative ME is definitely better, especially at low bitrates. I made 2 samples to show the difference, with the old (http://carrotland.uw.hu/snow_q10.avi) and the new (http://carrotland.uw.hu/snow_q10_obme.avi) ME algorithm. The improvement in motion accuracy is obvious.

In my experience the new ME works best with SATD cmp functions (xxxcmp=2), sometimes SSE method (xxxcmp=1) causes strange twirling effects and chroma artifacts. Also, v4mv is still harms the quality more than it helps, it's not a good idea to use it yet.

[bratao]

i geting better fast !!
5 months ago i do a encode at ~1fps and the output has a bad quality output, the xvid has far superior..

But today i do a encode at solid 4 fps (remember i have a slow processator, an 1.6 p4 with 133 sdram) and very good quality ! imho far better than xvid/divx and comparable with some fast x264 encodes..

And look at source , it easy to see that it at a very alpha stage , with a very unoptimized code..
It had a Very big potential !!
Keep on the good work !

[celtic_druid]

"Informer you no say daddy me Snow me I'll go blame
A licky boom boom down"

Cool name to.

[ods15]

And look at source , it easy to see that it at a very alpha stage , with a very unoptimized code..
It had a Very big potential !!


The encoder could still get some optimiaztions, though not many. The decoder is fully optimized in C code, and there are pending patches for mmx, which help up to 50% in best case scenario (for decoding), and that's about it. With a P4 2.4ghz I can play a high quality 944x544 smoothly, that's about the maximum. I'm working on adding slicing support to Snow, which could help in some cache restricted situations, but I'm generally pessimistic on Snow speed. It has only one big advantage of H.264 in regards to speed - if you have an HDTV res snow video, you can decode it at half res (or even forth), and reduce cpu usage by a 1/4th (or 1/16th), which makes it quite nice...

- ods15

[Liisachan]

@Tommy Carrot
thank you for posting them. I'd like to run my own tests too, but you are right. The improvement is easily noticeable in you clips (for example in the sky)

I don't care about encoding speed much, especially when it's still in alpha or beta. 1 fps is fast enough for me. VSFilter is often < 1fps when subbing complicated effects anyway, even tho the codec is fast.

[MfA]

Ods15, just curious (and lazy) do you have a breakdown on where a recent version of the decoder spents all its time?

[akupenguin]

The decoder is fully optimized in C code, and there are pending patches for mmx, which help up to 50% in best case scenario (for decoding), and that's about it.
That's not the limit or anything, that's just what the pending patch gives. While I don't believe dalias's claims of OBMC as fast as conventional MC, I do know how to make it algorithmically faster than it is now. And that applies to both encoder and decoder.

[pest]

@akupenguin

is an iterative obmc really worth the time?
why not use a simple obmc as in h263+ and
more variable blocksizes (8x8,8x16,16x8,16x16)?
why not write the rangecoder in asm, this would
give the most speed improvements.

[akupenguin]

It's not "iterative obmc". It's "iterative obme".
The decoder performs Overlapped Block Motion Compensation. This is not iterative, and only slightly more complex than h263's.
The encoder performs Overlapped Block Motion Estimation, which can be as slow/complex as you want. h263 would benefit from iterative obme too, if anyone bothered to write it.

Snow does not effectively use the block sizes it has, so we need to work out heuristics for that before we tackle even more.

What makes you think you (i.e. I) can write rangecoder asm better than gcc? Asm is needed because compilers can't effectively use SIMD operations. Scalar math and scheduling is much better studied.

[pest]

sorry about the difference,
i only wanted to say that BME and a OBMC as simple
as h263+ could fit the purpose. that's the same as you explained.


Snow does not effectively use the block sizes it has, so we need to work out heuristics for that before we tackle even more.


using more blocksizes could slow down the iterative me really.
that's why i asked if it makes any important improvements
over BME.


What makes you think you (i.e. I) can write rangecoder asm better than gcc? Asm is needed because compilers can't effectively use SIMD operations. Scalar math and scheduling is much better studied.

the speedup is not as huge as exploiting SIMD operations
but there is some. you could process the subband
data in blocks to further parallel the entropy encoder
until the rangecoder level.

[akupenguin]

The entropy encoder is a trivial fraction of the total encode time. There's no point in asming it.
And there's no parallelism possible in the entropy decoder.

[pest]

in my tests entropy-encoding/decoding takes the most time
but it just could be that :stupid: , we'll see ;)

[CREXbzh]

in my tests entropy-encoding/decoding takes the most time
but it just could be that :stupid: , we'll see ;)
It probably means that you should be careful when you interpret the results of your profiler. You may want to re-try with oprofile for example.

[pest]

the conclusions i draw are from my wavelet-codec
it's somehow different than snow. i thought the same
rules apply to snow but this is apparently not the case.

[CREXbzh]

Oded Shimon has further optimized snow decoding (an maybe encoding also). The patch is available here: http://tuxrip.free.fr/transperl/MPlayer/snow_mmx.patch

[Yong]

Oded Shimon has further optimized snow decoding (an maybe encoding also). The patch is available here: http://tuxrip.free.fr/transperl/MPlayer/snow_mmx.patch
Thanks for the link ;)
Just tested the normal version againts patched version, with 640x480 @ 30 fps, 650 frames,
patched version give 70 fps decoding in benchmark
unpatched is 37 fps
Wow :D

EDIT: unfortunatly the encoding speed(vme8) still same slow as unpatched version...

[DarkFoon]

I want to thank all of the developers/testers/etc. who work on the Snow codec. Though a bumpy road it's been, I believe that Snow has potential.
I want to use a high quality codec for all my TV captures that isn't patent encumbered, and I believe that Snow will be that codec. Xvid isn't high enough quality for me, H.264 is patented (I use x.264 currently, but I don't like the feeling that I'm supporting a big corp). And the Ogg wavelet codec, tarkin, is no longer developed.
So, thank's guys (and ladies, where applicable) and keep up the good work!

[akupenguin]

There are encoding optimizations pending too, but that will come after this patch is finalized. It's huge enough already.

[Liisachan]

snow.c Revision 1.91 (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/snow.c?rev=1.91&content-type=text/x-cvsweb-markup&cvsroot=FFMpeg&sortby=date) Mon Mar 13 01:27:13 2006 UTC
"seed iterative_me with mvs from conventional search.
+15% speed, +.1 dB"

by courtesy of celtic_druid:
http://ffdshow.faireal.net/mirror/mplayer/

[celtic_druid]

Guess I should update the ffmpeg build to.

[Liisachan]

the above sample, the same settings.
640x376@23.976fps [YV12] 2577f
P4 3.4GHz


2nd pass
+---------------------+-------------+------------+
| MEncoder dev-CVS- | vme=4 | vme=8 |
+---------------------+-------------+------------+
| 060306-21:51-4.0.2 | 12.76fps | 1.74fps |
+---------------------+-------------+------------+
| 060316-21:45-4.0.2 | 12.80fps | 2.02fps |
+---------------------+-------------+------------+

:D

[celtic_druid]

Should point out that the P4 build from the 6th has SSE/SSE2 enabled where as the one from the 16th doesn't.

[Liisachan]

MEncoder dev-CVS-060306-21:51-4.0.2 (C) 2000-2006 MPlayer Team
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

MEncoder dev-CVS-060316-21:45-4.0.2 (C) 2000-2006 MPlayer Team
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2


0 means "not optimized for SSE/SSE2"? in short, this could be even faster?

[Yong]

A first part of speed-enhancing patches just summited to ffmpeg 84mins ago :)
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFMpeg&sortby=date#dirlist

[CREXbzh]

A first part of speed-enhancing patches just summited to ffmpeg 84mins ago :)
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/?cvsroot=FFMpeg&sortby=date#dirlist
Note: this part doesn't yet feature any speed enhancement. It just prepares the ground for them.
The idea being to split the changes in small enough parts so that they can be reviewed and understood easily.

[Sirber]

0 means "not optimized for SSE/SSE2"? in short, this could be even faster?not optimized for 3DNow, SSE is fine

[akupenguin]

Should point out that the P4 build from the 6th has SSE/SSE2 enabled where as the one from the 16th doesn't.
The pending patches will add SSE2 stuff, but there isn't any yet so you didn't lose anything in that test.

[Liisachan]

Iterative Motion Estimation is obviously effective in a high-motion scene, or when the bitrate is not sufficient.

The same part of the same frame, 200%

Input
http://www.faireal.org/tmp/codec_test/204huff.png

vme=4
http://www.faireal.org/tmp/codec_test/204vme4.png

vme=8
http://www.faireal.org/tmp/codec_test/204vme8.png


mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=1:vqscale=3.0:lmin=1:pred=1:cmp=257:subcmp=257:mbcmp=257:qpel:v4mv -of avi -ffourcc SNOW -o 1st.avi

mencoder "input.avs" -ovc lavc -passlogfile "pass.log" -lavcopts vcodec=snow:vstrict=-2:vpass=2:vme=<4|8>:vbitrate=1150:lmin=1:pred=1:cmp=257:subcmp=257:mbcmp=257:qpel:v4mv -of avi -ffourcc SNOW -o <snow257.avi|snow257obme.avi>

snow257.avi (http://www.faireal.org/tmp/codec_test/snow257.avi) 5.4MB
snow257obme.avi (http://www.faireal.org/tmp/codec_test/snow257obme.avi) 5.4MB


vme=8 always works in various settings...
http://img101.imageshack.us/img101/6616/snowdemo5xj.th.png (http://img101.imageshack.us/my.php?image=snowdemo5xj.png)

[bratao]

Wonderful quality image in snow257obme.avi .
Perfect and liquid decoding until get in 8 seconds, at that point crash my ffdshow 2.2.2006.

I´m cant wait for this speed patches, to see the results.
Witout this pacthes, snow already only 7 times slower than xvid in this premature stage.

[Liisachan]

You might want to try mplayer (http://ffdshow.faireal.net/mirror/mplayer/)

(commandline) mplayer snow257obme.avi

maybe MPlayer is less cpu intensive. milan's ffdshow (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/milan/) 2005-11-15 works fine for me too.

[celtic_druid]

ffdshow works fine here... current cvs build.

[hellfred]

Hi folks
It is time for benchmaring snwo once more. The second patch of the mmx + sse2 acceleration of snow by Robert Edele has been committed to libavcoded cvs rep. This patch actually contains assembler code for speeding up encoding with snow.
See http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009245.html
Sorry for not being able to privide some numbers myself.

Hellfred

[CREXbzh]

This patch actually contains assembler code for speeding up encoding with snow.
See http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009245.html
Sorry for not being able to privide some numbers myself.

No it still doesn't contain any asm. It just changes a few things in the C code so that the next patch will be simpler.

No visual benchmark needed then, though it's possible that the speed of the current C code is affected by that patch, so it could be interesting to see if there aren't any regressions. I doubt that it's measurable in fps though if there's any regression. You'd need to use hardware counters to have a precise measure.

WJMP

[hellfred]

No it still doesn't contain any asm. It just changes a few things in the C code so that the next patch will be simpler.WJMP
Oh, you are right. I had hoped that all preparations for an easy inclusion of the asm code were done in the first patch already.:o
So my hope for improvement of the snow coded mislead me here. I beg your pardon.

Hellfred

The third part of the patch, including the asm code for the function ff_snow_vertical_compose(), was just placed on the ffmpeg mailing list. Let's see how long it will take to be reviewed and comitted.
See here (http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009297.html).

EDIT: Info about patch part 3

[CREXbzh]

The third part of the patch, including the asm code for the function ff_snow_vertical_compose(), was just placed on the ffmpeg mailing list. Let's see how long it will take to be reviewed and comitted.
See here (http://mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/009297.html).

EDIT: Info about patch part 3

Done! ;-) Knock yourself out!

[Liisachan]

fps-wise only slightly, or maybe in the margin of erros:
0.98fps @ MPlayer dev-CVS-060316-21:45-4.0.2
1.00fps @ MPlayer dev-CVS-060321-16:16-4.0.2

the 2nd pass of vme=8:cmp=257:qpel:v4mv

[celtic_druid]

Well I just got:
1.61fps for the 21st
1.64fps for the 16th

[CREXbzh]

fps-wise only slightly, or maybe in the margin of erros:
0.98fps @ MPlayer dev-CVS-060316-21:45-4.0.2
1.00fps @ MPlayer dev-CVS-060321-16:16-4.0.2

the 2nd pass of vme=8:cmp=257:qpel:v4mv

That's to be expected: the patch is mainly to speed-up decoding routines.

[Liisachan]

Tested "mplayer snow.avi" a few times, and the difference was not clear on my Windows 2000. P4. Perhaps the avarage cpu load is less. The peak CPU load is always higher with the 21st build. Maybe because I'm always testing extreme options like vme 8 qpel and the speed-up is for more normal part?

[CREXbzh]

Tested "mplayer snow.avi" a few times, and the difference was not clear on my Windows 2000. P4. Perhaps the avarage cpu load is less. The peak CPU load is always higher with the 21st build. Maybe because I'm always testing extreme options like vme 8 qpel and the speed-up is for more normal part?

Don't know... You should run several times:

mplayer -vo null -nosound -benchmark snow.avi

That would give you smth like:

BENCHMARKs: VC: 24.293s VO: 0.005s A: 0.000s Sys: 0.126s = 24.423s
BENCHMARK%: VC: 99.4644% VO: 0.0213% A: 0.0000% Sys: 0.5143% = 100.0000%

Which tells you how much time was spent on the VideoCodec.
Experience shows that the optimizations give a larger speed-up on small resolutions, or that they work better one CPU with a large L1 cache (which is not the case of the P4).

[Liisachan]

2006-03-16
24.570s
24.440s
24.443s

2006-03-21
25.565s
25.547s
25.595s




MPlayer dev-CVS-060316-21:45-4.0.2
BENCHMARKs: VC: 24.570s VO: 0.002s A: 0.000s Sys: 0.217s = 24.789s
BENCHMARK%: VC: 99.1165% VO: 0.0081% A: 0.0000% Sys: 0.8754% = 100.0000%

BENCHMARKs: VC: 24.440s VO: 0.001s A: 0.000s Sys: 0.224s = 24.665s
BENCHMARK%: VC: 99.0878% VO: 0.0041% A: 0.0000% Sys: 0.9082% = 100.0000%

BENCHMARKs: VC: 24.443s VO: 0.001s A: 0.000s Sys: 0.207s = 24.651s
BENCHMARK%: VC: 99.1562% VO: 0.0041% A: 0.0000% Sys: 0.8397% = 100.0000%

MPlayer dev-CVS-060321-16:16-4.0.2
BENCHMARKs: VC: 25.565s VO: 0.005s A: 0.000s Sys: 0.190s = 25.760s
BENCHMARK%: VC: 99.2430% VO: 0.0194% A: 0.0000% Sys: 0.7376% = 100.0000%

BENCHMARKs: VC: 25.547s VO: 0.000s A: 0.000s Sys: 0.209s = 25.756s
BENCHMARK%: VC: 99.1885% VO: 0.0000% A: 0.0000% Sys: 0.8115% = 100.0000%

BENCHMARKs: VC: 25.595s VO: 0.001s A: 0.000s Sys: 0.186s = 25.782s
BENCHMARK%: VC: 99.2747% VO: 0.0039% A: 0.0000% Sys: 0.7214% = 100.0000%

[CREXbzh]

MPlayer dev-CVS-060316-21:45-4.0.2
BENCHMARKs: VC: 24.570s VO: 0.002s A: 0.000s Sys: 0.217s = 24.789s
BENCHMARK%: VC: 99.1165% VO: 0.0081% A: 0.0000% Sys: 0.8754% = 100.0000%

BENCHMARKs: VC: 24.440s VO: 0.001s A: 0.000s Sys: 0.224s = 24.665s
BENCHMARK%: VC: 99.0878% VO: 0.0041% A: 0.0000% Sys: 0.9082% = 100.0000%

BENCHMARKs: VC: 24.443s VO: 0.001s A: 0.000s Sys: 0.207s = 24.651s
BENCHMARK%: VC: 99.1562% VO: 0.0041% A: 0.0000% Sys: 0.8397% = 100.0000%

MPlayer dev-CVS-060321-16:16-4.0.2
BENCHMARKs: VC: 25.565s VO: 0.005s A: 0.000s Sys: 0.190s = 25.760s
BENCHMARK%: VC: 99.2430% VO: 0.0194% A: 0.0000% Sys: 0.7376% = 100.0000%

BENCHMARKs: VC: 25.547s VO: 0.000s A: 0.000s Sys: 0.209s = 25.756s
BENCHMARK%: VC: 99.1885% VO: 0.0000% A: 0.0000% Sys: 0.8115% = 100.0000%

BENCHMARKs: VC: 25.595s VO: 0.001s A: 0.000s Sys: 0.186s = 25.782s
BENCHMARK%: VC: 99.2747% VO: 0.0039% A: 0.0000% Sys: 0.7214% = 100.0000%


I can't help but suspect that there must be smth broken on the build you're using. You should either experience no speed-up (with huge resolution maybe) or a pretty sensible speed-up.

What resolution are you testing it with? Is it a multiple of 16?

Anyway, last patch got just applied...

[Liisachan]

yes 640x480, = 0 mod 16.
the binary (mplayer) I'm using is compiled by celtic_druid as usual.

I can't help but suspect that there must be smth broken on the build you're using. Maybe. It's an experimental build after all.

[Liisachan]

~4% faster now :D

2006-03-16
24.570s
24.440s
24.443s

2006-03-21
25.565s
25.547s
25.595s

2006-03-23
23.543s
23.504s
23.496s

MPlayer dev-CVS-060323-00:54-4.0.2

BENCHMARKs: VC: 23.543s VO: 0.002s A: 0.000s Sys: 0.211s = 23.756s
BENCHMARK%: VC: 99.1034% VO: 0.0084% A: 0.0000% Sys: 0.8882% = 100.0000%

BENCHMARKs: VC: 23.504s VO: 0.000s A: 0.000s Sys: 0.240s = 23.744s
BENCHMARK%: VC: 98.9892% VO: 0.0000% A: 0.0000% Sys: 1.0108% = 100.0000%

BENCHMARKs: VC: 23.496s VO: 0.001s A: 0.000s Sys: 0.247s = 23.744s
BENCHMARK%: VC: 98.9555% VO: 0.0042% A: 0.0000% Sys: 1.0403% = 100.0000%

[Yong]

Ive compare the current cvs build(snow mmx part 5) with the old pacthed (http://forum.doom9.org/showthread.php?p=797618#post797618) build,
the old patched build is still the fastest, 70fps,
comapare with the current build which only gives 57 fps,
and CREXbzh mentioned its the last patch...

Anyway, thanks ffmpeg/mplayer devs for their amazing works :)

[CREXbzh]

Ive compare the current cvs build(snow mmx part 5) with the old pacthed (http://forum.doom9.org/showthread.php?p=797618#post797618) build,
the old patched build is still the fastest, 70fps,
comapare with the current build which only gives 57 fps,
and CREXbzh mentioned its the last patch...

I almost forgot about that patch: This patch indeed features some additionnal improvement I had forgotten about. Oded just post his modifications to FFmpeg's mailing list (about 3 1/2 half ago): http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/30712


Those changes aren't related to the MMX and SSE changes, as they are written by 2 different ppl, and mainly take a higher level aproach to speed decoding up.
It's meant to speed-up decoding of files with qpel.

Anyway, thanks ffmpeg/mplayer devs for their amazing works :)

I'll tell them :p

[Liisachan]

MPlayer dev-CVS-060326-23:31-4.0.2
Windows 2000 P4

2006-03-23
23.543s
23.504s
23.496s

2006-03-26
23.130s
23.171s
23.139s


BENCHMARKs: VC: 23.130s VO: 0.001s A: 0.000s Sys: 0.262s = 23.393s
BENCHMARK%: VC: 98.8757% VO: 0.0043% A: 0.0000% Sys: 1.1200% = 100.0000%

BENCHMARKs: VC: 23.171s VO: 0.001s A: 0.000s Sys: 0.237s = 23.409s
BENCHMARK%: VC: 98.9833% VO: 0.0043% A: 0.0000% Sys: 1.0124% = 100.0000%

BENCHMARKs: VC: 23.139s VO: 0.001s A: 0.000s Sys: 0.264s = 23.404s
BENCHMARK%: VC: 98.8677% VO: 0.0043% A: 0.0000% Sys: 1.1280% = 100.0000%

[krasi0]

Is the SNOW codec suitable for live streaming to network?

[siddharthagandhi]

lol i get better results with xvid than snow

[708145]

Is the SNOW codec suitable for live streaming to network?

If your PC is fast enough then yes. :)

[akupenguin]

Snow doesn't have a 1pass CBR mode, so you'll have a hard time streaming it even with a fast enough computer.

[708145]

Snow doesn't have a 1pass CBR mode, so you'll have a hard time streaming it even with a fast enough computer.

Good to know there is something to do :)

[Dayvon]

Is there anything happening with Snow? Is there any kind of user info for encoding (i.e. explanation of options)?

[nm]

SVN log: http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/snow.c?view=log
Instructions: http://svn.mplayerhq.hu/mplayer/trunk/DOCS/tech/snow.txt?view=markup

[akupenguin]

I'm experimenting with mesh-based motion compensation in Snow. But it's not ready for y'all to test yet.

[Shinigami-Sama]

ohh I'd almost forgoten about snow
once I get my PC all set up for work again I'll be happy to test(its in a horrible mess )

[ReinerSchweinlin]

I'm experimenting with mesh-based motion compensation in Snow. But it's not ready for y'all to test yet.

Sounds interessting :) Thanx for keeping on working on this, can´t wait to see:D

[MfA]

I'm experimenting with mesh-based motion compensation in Snow. But it's not ready for y'all to test yet.
Warping or discontinuous?

[akupenguin]

Warping. But it isn't continuous over the whole frame, since each block gets to choose between mesh and obmc.

[Quince]

Any news?

[Liisachan]

Well, this is not very good news, but just so everyone here knows...

SNOW support in ffdshow-tryout has been temporarily disabled. Some of the devs were like: "Does anyone know of anyone who is actually using the SNOW codec in real life? Afaik it is still an experimental codec. Perhaps it would be best to just remove it altogether." "Remove it Permanently."

Oh well, imho being an experimental codec is the very reason why we need decoding support to test, debug, and hopefully improve it... Sure, ffdshow is not a must to test SNOW, but they could have been a bit more eager to try out new things. However one of the devs, haruhiko_yamagata, was a bit different, saying "Let's remove it temporarily and restore when ready. ...it's not good to ignore SNOW."

I'm not blaming anyone. It was what happened anyway. I must confess myself that I don't have much time to test new things lately. I still am very interested in snow.

[Quince]

I'm curious if there's any codec that can be sped up significantly by decoding or even encoding using the GPU. Looking at the various papers at gpgpu.org, quite general purpose parallelizable computations can be done. HiDef resolution Snow encoding in realtime, perhaps?

[martino]

What would be a minimum technical specification for a PC to be able to play video encoded using the Snow codec?

[708145]

What would be a minimum technical specification for a PC to be able to play video encoded using the Snow codec?

at which resolution?

[Sharktooth]

... and framerate?

[CREXbzh]

What would be a minimum technical specification for a PC to be able to play video encoded using the Snow codec?

The best is just to test yourself. I have 2 samples of the same video here (688x576@25fps):
http://tuxrip.free.fr/transperl/MPlayer/The_Godfather-1972_snow.avi
http://tuxrip.free.fr/transperl/MPlayer/The_Godfather-1972_x264.avi

[708145]

The best is just to test yourself. I have 2 samples of the same video here (688x576@25fps):
http://tuxrip.free.fr/transperl/MPlayer/The_Godfather-1972_snow.avi
http://tuxrip.free.fr/transperl/MPlayer/The_Godfather-1972_x264.avi

decoding your 20s clip on a 2500+ took
9.96s with x264
25.5s with snow

=> full PAL for snow would take ~3300+ (linear scaling assumed)

[martino]

D'oh!

http://img325.imageshack.us/my.php?image=snowproblemjg3.png -Mplayer 1.00rc1
http://img325.imageshack.us/img325/2714/snowproblem2al5.png

[foxyshadis]

April 2005? Isn't it time you updated your mplayer?

[martino]

Where can find the newest build then???

[CREXbzh]

D'oh!

http://img325.imageshack.us/my.php?image=snowproblemjg3.png -Mplayer 1.00rc1
http://img325.imageshack.us/img325/2714/snowproblem2al5.png

Sorry, can't reproduce here (linux AMD64)

[Liisachan]

@martino you can try celtic_druid's binaries (http://ffdshow.faireal.net/mirror/mplayer/)

[wyrd]

@martino, It reproduce here too.

+- build -+- date -+- result
Offcial 20050417(pre7) fine
Offcial 20050928 fine
celtic_druid's 20051114 fine
celtic_druid's 20060101 fine
celtic_druid's 20060316 fine
celtic_druid's 20060501 fine
celtic_druid's 20060515 fine
celtic_druid's 20060602 reproduce (block_max_depth= 3 is too large [signal 11])
Offcial 20060612(pre8) reproduce (block_max_depth= 3 is too large [signal 11])
Offcial 20061028(rc1) reproduce (block_max_depth= 3 is too large [signal 11])
celtic_druid's 20061203 reproduce (block_max_depth= 3 is too large [signal 11])

with winxp(P4)/win2k(P3/VIA C3).output.png (http://tirnanog.fate.jp/tmp/snap/mplayer_snow_test_output.png)
Hmmmm.. windows port only pb??
dose anyone confirm?

thanks

[akupenguin]

The obvious separation is by date.
r5417 | lorenm | 2006-05-28 15:44:47 -0600 (Sun, 28 May 2006) | 4 lines

Snow multiple reference frames
(bitstream is not backwards compatible, even if refs aren't used)

The file must have been encoded before then, so new builds can't play it.

[CREXbzh]

The obvious separation is by date.


The file must have been encoded before then, so new builds can't play it.

That must be it. I encoded it a while ago.

[wyrd]

Snow multiple reference frames
(bitstream is not backwards compatible, even if refs aren't used)Ahhh.. i've missed it.
@akupenguin,CREXbzh
Thank you for clarification.:)

[martino]

Even with the newest version I still keep getting the same error message...

[akupenguin]

That's the point. The error message means that new versions are not compatible with old snow encodes. While snow doesn't break compatibility every week anymore, it's still not stable.


vstrict=-2
Enables experimental codecs and features which may not be playable
with future MPlayer versions (snow).

[Koti]

Error encoding to snow with mencoder-svn-r22519 and SVN-r22503

Assertion failed: iscore >= 0, file snow.c, line 2169
This application has requested the Runtime to terminate it in an unusual way.

"mencoder.exe" "J:\Tool\Parabola\Parabola.avs" -ovc lavc -passlogfile "J:\Tool\Parabola\Parabola -Snow.log" -lavcopts vcodec=snow:vstrict=-2:lmin=1:vpass=1:vbitrate=600:pred=0:vme=4:cmp=2:subcmp=2:mbcmp=1:qpel -nosound -of avi -ffourcc SNOW -o NUL

Error occurs consistently between about 200 - 12000 frames encoded on all files (1st pass) with various sources avi and avs.
Also getting a similarly worded error with ffmpeg rev8310 pointing to the same file (snow.c) and line (2169).

MEncoder 1.0rc1-3.4.2 has no errors with same input/cli and completes both passes but uses a older bitstream of snow.

XPpro Sp2 - P4 3.2 Prescott

Any ideas ? :thanks:

Update Assertion bug seems to have been fixed :) FFmpeg Revision 9163 (http://svn.mplayerhq.hu/ffmpeg?view=rev&revision=9163) May 30 2007

[nm]

I have the same problem when deinterlacing with yadif+mcdeint using recent MPlayer and libavcodec revisions. I haven't investigated further, but developers are probably willing to help if you can provide a small sample file that introduces this problem. Bug report instructions for FFmpeg (snow is part of it) are here: http://ffmpeg.mplayerhq.hu/bugreports.html

[taeuber]

Hi you all!

I'm very, very interested in a fixed snow specification 1.0 .
Two others and me have donated (http://ffmpeg.mplayerhq.hu) some euros for a completion of the specification and a working implementation.
But there seems to be no one that is able and likes to help Michael with this work.

Is here someone reading who wants to help or is willing to increase the donation sum?

I'm frustrated, because I'm not skilled enough to understand the code or the mathematics behind the codec.

Please help.
I really like to have a performant, patent free open source codec that encodes my private family videos for archiving.

Thank you very much!
Lars

[Liisachan]

Will you tell me more? Sadly now I have little time to 'play' with new codecs, unlike I did before, and don't know exactly what's going on. I still am interested nevertheless.

>> Good idea! Ok, I offer 400 eur to Michael if he restarts works on the
>> snow codec

Does this mean Michael is not motivated anymore? OR does it just mean Michael IS motivated but needs some money to go on for some reason? If so, I'm willing to make some donation. My finances are tight so I can't be like those 3 persons, though...

[taeuber]

Hi Liisachan,

Michael is not motivated enough to make it alone.
Everyone that is willing to help with the codec makes him work further on the codec. A good patch for the code or the documentation (specification) every Month or so will speed up the developement significantly.

I think it will be the best codec for years. No commercial company will release a codec that is as effective as snow for the masses. Snow has no restrictions in resolution or color space or anything.

If you can help please do. Gain your portion of the donation!

Take the latest tarball from here (http://ffmpeg.mplayerhq.hu/ffmpeg-export-snapshot.tar.bz2) and read the snow.txt (http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co) from the doc directory.
This might be a good point for a starting.

Thank you!
Lars

[shevegen]

Well I wouldn't mind to donate somewhat significant amount of Euro although I dont think I can donate 400 Euro singlehandedly ;) but I'd also like to know about the status of it, ie. how much work would be needed before it reaches a more solid state, and even more importantly if there are devs that have the motivation to continue on it (to me, motivation on a project is critical, I have seen many projects fall apart because the motivation dropped even below the "maintain it" part of things)

[akupenguin]

Snow has no restrictions in resolution
Nor does any other codec since h263 (and even that was fixed in h263+).
or color space or anything.
Snow's only colorspaces are 4:2:0 and gray.

how much work would be needed before it reaches a more solid state
Is it not solid now?

IMO one of the biggest potential improvements in Snow's compression quality is dealing with intra blocks in inter frames. But I have no idea how to fix it. None of the other wavelet codecs deals well with intra blocks either, nor have I found any likely-looking proposals in the wavelet research papers I've read. (Wavelets deal just fine with whole intra frames; it's the edge between inter and intra that causes problems.)

[Liisachan]

Hi taeuber,
I didn't notice your reply for months, sorry for that,
and in that tarball I see snow.c is dated 2007-07-28,
and so I assume snow is still very alive!

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 just tried to PayPal to Michael's address I see in the list (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-May/030091.html), but PayPal says "This recipient is not yet registered. PayPal will send an email to the recipient explaining how to complete your transaction." Can I go on, or is there any more preferable way to make a donation? I read several pages on mplayerhq but I'm clueless. I hope I'm not blind...
On another note, I'm running a mirror hosting ffmpeg (http://ffdshow.faireal.net/mirror/ffmpeg/) etc compiled (for Windows) by celtic_druid, so in a way, indirectly I was always supporting the project too :)

[akupenguin]

Snow is subject to maintenance that affects all of libavcodec. But the last snow-specific commit was 2007-01-30.

[Dark Shikari]

Am I doing something wrong?

I assumed that, since it requires vastly more CPU to encode and decode than H.264 and it is more advanced than H.264 (wavelet instead of DCT) that Snow would provide better compression, albeit in an experimental and slow package.

x264 667b on best settings:
SSIM: 0.98414
PSNR: 43.10942

Snow on best settings (VME 8, Wavelet+Chroma comparison for everything but mbcmp which had SSD+Chroma, 8 Refs, 9/7 wavelet):
SSIM: 0.98169
PSNR: 42.53070

H.264 had about 5% higher bitrate than Snow as I couldn't get it to the correct target bitrate, but that doesn't make up for the large difference here. Source is Rushhour.yuv denoised and resized to half size.

[akupenguin]

Snow currently lacks B-frames, RDO, trellis, adaptive transform, and a good partition decision (4mv often hurts instead of helping). All of which could be added, though I'm not claiming they'll have the same cost or benefit as in H.264.

[Dark Shikari]

Snow currently lacks B-frames, RDO, trellis, adaptive transform, and a good partition decision (4mv often hurts instead of helping). All of which could be added, though I'm not claiming they'll have the same cost or benefit as in H.264.
OK, I'll compare to x264 with limited commandlines then.

--subme 5 --me umh --deblock 0:0 --ref 8 --mixed-refs --direct-auto (twopass bitrate)

AVG: 0.98045,AVG: 0.98169

So now Snow comes out ahead.

What about the entropy encoder; how good is Snow's as compared to H.264?

[akupenguin]

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.)
Entropy coder frontend (choice of contexts, etc): hard to say. How would one compare one entropy coder for wavelet against a different entropy coder for DCT?

Snow doesn't have a tuned default probability table. All the probabilities start at 50% and then adapt to the observed data. H.264 initializes the probabilities based on frame type and QP, and then adapts to the observed data. At sufficiently low resolution and bitrate this could be a penalty for Snow, but I don't know what is "sufficient". OTOH, Snow resets the probabilities only at I-frames, while H.264 resets the probabilities at the beginning of every frame. So long GOPs could compensate.

[Dark Shikari]

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.)
Entropy coder frontend (choice of contexts, etc): hard to say. How would one compare one entropy coder for wavelet against a different entropy coder for DCT?
So its basically comparable to CABAC. Does it have an inloop filter like H.264? Or does the wavelet transform not produce the same sort of blocks DCT does?

[akupenguin]

Wavelet doesn't produce any blocks.

Also, try CQP to normalize for differences in ratecontrol. x264's ratecontrol is somewhat derived from lavc's, but they're not identical. (But note that Snow should use 2pass CQP, since it doesn't currently support scenecut detection in the same pass as iterative ME, and as metioned above Snow doesn't like intra blocks in P-frames.)

[microchip8]

which wavelet type is best for encoding?

[Dark Shikari]

Wavelet doesn't produce any blocks.

Also, try CQP to normalize for differences in ratecontrol. x264's ratecontrol is somewhat derived from lavc's, but they're not identical. (But note that Snow should use 2pass CQP, since it doesn't currently support scenecut detection in the same pass as iterative ME, and as metioned above Snow doesn't like intra blocks in P-frames.)
I'm using an input video with no scenecuts at all so one-pass iterative ME works fine.

And oh god is the encoding slow... 0.04 FPS at the settings I previously described, for a 960x536 video :)

[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.