[HD 1080p Challenge: Low bitrate!]

[Dark Shikari]

Most other challenges focus on high bitrates, often HD-DVD-like bitrates where, quite honestly, the quality difference between even MPEG-2 and VC-1 is hard to notice.

But in my opinion, the real strength today's latest codecs is at low bitrates. Internet bandwidth is limited, and when distributing video files, companies would much prefer if they could give consumers a 2 megabit video than a 20 megabit video. And in streaming, such as at Stage6 or Joost, this is even more important; in 5 years, almost everyone will have at least a 3-5 megabit connection, but streaming such a bitrate is quite expensive. Max bitrate doesn't matter nearly so much as average bitrate in this case.

So this is a test of low-bitrate capability for use on computers, not hardware decoders. The rules are:

1. It must be able to play back, in real time, on a 2Ghz Core 2 Duo with a decoder that I can acquire.
2. It must be able to be muxed into a Matroska container.
3. 2 megabit average bitrate, +/- 5 kilobits per second.
4. If you want your encoder to take part in this contest, upload the resulting file and post a link so that it can be tested. Additionally, if you are working with a less popular codec, such as VP7 or perhaps something totally new, post a link to a decoder.

The reason for 2) is so that subjective tests can be carried out without knowing which is which until after the fact. A different file extension would make it blatantly obvious. Obviously a dishonest person could look at the video info or the streams, but its useful to avoid self-bias. Also note the complete lack of encoding restrictions, such as max bitrate, etc.

Source: here (http://orange.blender.org/blog/original-lossless-source-available/). Elephant's Dream, same as in the other test.

You must use this Avisynth script for encoding:
Source=ImageSource("C:\LossLess\images\%05d.png", start=1, end=15691, fps=23.976)
Source=ConvertToYV12(source, matrix="Rec709")
return source

I will upload an x264 sample when its finished encoding. I may post SSIM values and such but the real goal of this test is to have subjective comparisons by doom9 members, both to find which is better and to make specific commentary on each encoding. High bitrates make it very difficult to perform accurate subjective tests, so in a sense this test is ideal for a subjective comparison.

Download links will be posted later once I get a few entries and the subjective test is ready.

Note: bitrate has been raised to 2 megabits per second on Puzzler's advice. 1 megabit looked too shitty anyways.

Entries so far:
x264 w/Hadamard patch (Dark Shikari):
SSIM: 0.9754294
Average PSNR: 45.763
Global PSNR: 42.254
Bitrate: 2001.88

[Sharktooth]

2. is useless. anyone can acquire the stream(s) info with mkv tools or even look at the video properties within the media player...

[Dark Shikari]

2. is useless. anyone can acquire the stream(s) info with mkv tools or even look at the video properties within the media player...Obviously, the point is for honesty here. One would expect that people who want to take part in a subjective test will follow the rules of that test, especially here on doom9. If you can think of a better way, say so.

Even if you took the videos and re-encoded them into lossless and then viewed them, you'd still be able to figure out what codec was used simply by the type of artifacting.

The point is so that the following can be done:

1. Person X downloads Video 1, Video 2, Video 3.

2. Person X views Video 1, Video 2, Video 3, and makes comments on each and rates each of them.

3. Person X posts his results, and then looks at the video streams and says to himself "Oh, so the one I liked most was VC-1" and so forth.

The problem with objective tests is that there are many types of artifacting that are very good SSIM/PSNR-wise but aggravate viewers to no end.

[bond]

first of all, a great idea! thanks for starting the challenge

2. is useless. anyone can acquire the stream(s) info with mkv tools or even look at the video properties within the media player...well, for those seriously wanting to do the test it makes sense to avoid selfbias

Dark Shikari, if you are collecting the encodes please also calculate the SSIM and PSNR for all that care about it

[Dark Shikari]

Dark Shikari, if you are collecting the encodes please also calculate the SSIM and PSNR for all that care about itYes, I'll do that using the MSU Video Quality Tool, since the Avisynth plugin seems to be somewhat finicky on my system.

[woah!]

we are talking 1000kbs at 1920x1080 ???

[Dark Shikari]

we are talking 1000kbs at 1920x1080 ???
If enough codecs can do it, hopefully.

Basically the idea is to use a bitrate low enough that all artifacting is blatantly obvious for a subjective test.

[woah!]

just wanted to make sure that was correct before i played about with it..

[akupenguin]

3. 1 megabit average bitrate, +/- 0.5%.
IMO a simpler and more reasonable rule is: 1 megabit limit; undershoot by however much you need to to be sure it will fit.
With your wording it's essentially a 1.005 megabit limit, and what kind of number is that?

[Dark Shikari]

IMO a simpler and more reasonable rule is: 1 megabit limit; undershoot by however much you need to to be sure it will fit.
With your wording it's essentially a 1.005 megabit limit, and what kind of number is that?
I'm doing the same that Sagitaire did in his thread. Since we're mainly dwelling on subjective tests here, odds are 5 kilobits per second won't make a difference. And if an encoder overshoots the given bitrate, it also is a comment on its (lack of) ratecontrol ability.

Most importantly I don't want to have people (including me) spend 20 hours encoding something and have to throw it out because its 1 kilobit per second too high.

[CruNcher]

we are talking 1000kbs at 1920x1080 ???

Yep that is no problem todays but the look & feel at such low bitrates can be very different, for most New Generation Codecs based on the same algorithms it looks almost the same tough, very subtitle differences also from different implementations of different standard the look @ feel is basicly the same for example Ateme,Mainconcept,X264 and yes even RV9/10 they look almost identical but they are definatly optimized for different user cases and to what i have gathered X264 can be made the sharpest of all 3 (H.264) like XviD is compared to DivX, especialy at High Bitrate HD (HD-DVD,Blu-Ray) this gives it an advantage i would say X264 can be very well compared in those regards with Mainconcepts Quality the cool thing about X264 is it lets you decide what you wan't to achive it can be very easily adapted for different cases, so if you wan't high quality sharp image @ high bitrates this is no problem same ofcourse in the other direction low bitrate range (blurry) it can be adapted very well (lot of this internal stuff can't be changed with Ateme or Mainconcepts implementations) so yeah you can decide the look & feel with X264 even more then with other H.264 implementations that are hard set to one, wich imo makes it very powerfull :)

[PuzZLeR]

If enough codecs can do it, hopefully.

Basically the idea is to use a bitrate low enough that all artifacting is blatantly obvious for a subjective test.

Give the codec a chance to breathe here. 1mbps at a DvD type rez sure, but in this case you may be comparing what looks like mud to another case of what looks like mud...:eek:

Just like you mentioned that high bitrate comparisons can mean very little (I agree) I also need to add, for another, yet parallel reason, very, very low bitrates may not be conclusive either.

In both cases, at a very high bitrate and at a very low bitrate, we are comparing codecs in unrealistic cases. I don't even think we can appreciate the hypothetical value here either.

Nevertheless, good idea for a thread. I will be watching it with interest...:thanks:

[Dark Shikari]

Give the codec a chance to breathe here. 1mbps at a DvD type rez sure, but in this case you may be comparing what looks like mud to another case of what looks like mud...:eek:

Just like you mentioned that high bitrate comparisons can mean very little (I agree) I also need to add, for another, yet parallel reason, very, very low bitrates may not be conclusive either.

In both cases, at a very high bitrate and at a very low bitrate, we are comparing codecs in unrealistic cases. I don't even think we can appreciate the hypothetical value here either.

Nevertheless, good idea for a thread. I will be watching it with interest...:thanks:What do you think would be a realistic bitrate then? 1.5Mbit/s? 2Mbit/s?

I would not be surprised if over the next few years H.264 is used in Youtube-like applications... with the expectation of Youtube-like quality.

[PuzZLeR]

What do you think would be a realistic bitrate then? 1.5Mbit/s? 2Mbit/s?For true HD type rez, which has 5-6x more pixels than SD rez (depending on region), I'd say 2Mbps should be a serious lower bound, and a good "low bitrate test" to get some semblance of watchable quality, yet enough of an artifact sample in the analysis.

Honestly, at that crushingly low bitrate of 1Mbps in HD rez, I could not criticize any modern codec for looking like mud.

As well, bumping up the bitrate a little bit would add less relative significance to the few bits in the over/under-shoot interval.

I would not be surprised if over the next few years H.264 is used in Youtube-like applications... with the expectation of Youtube-like quality.For us hardcores, never. But yes, I can see that for the next few years in general public expectations - but only for a few years. I do see that eventually, when tech limitations widen, the general public will tolerate higher bitrates, beyond dinky toy cell phone specs of today, for higher quality (we're looking at 2011 or so here... my guess.)

[Dark Shikari]

For true HD type rez, which has 5-6x more pixels than SD rez (depending on region), I'd say 2Mbps should be a serious lower bound, and a good "low bitrate test" to get some semblance of watchable quality, yet enough of an artifact sample in the analysis.

Honestly, at that crushingly low bitrate of 1Mbps in HD rez, I could not criticize any modern codec for looking like mud.

As well, bumping up the bitrate a little bit would add less relative significance to the few bits in the over/under-shoot interval.

For us hardcores, never. But yes, I can see that for the next few years in general public expectations - but only for a few years. I do see that eventually, when tech limitations widen, the general public will tolerate higher bitrates, beyond dinky toy cell phone specs of today, for higher quality (we're looking at 2011 or so here... my guess.)
That's reasonable. I will raise the bitrate to 2 megabits per second.

x264 actually didn't look bad at all, but there were a couple of scenes where it completely choked (the running scene in particular, with all the wires).

[PuzZLeR]

That's reasonable. I will raise the bitrate to 2 megabits per second.Super. We can get a better idea of how the lab rats behave here. Better yet, we can actually see them better...:-D Thanks.

x264 actually didn't look bad at all, but there were a couple of scenes where it completely choked (the running scene in particular, with all the wires).You can get a picture at 2Mbps in HD, but motion will certainly melt, and may melt beyond what can properly be measured between codecs.

[vsv]

2Mbps is good for 720p24(25) but very low for 1080p

Check this h264 720p sample (48,6MB) at SVCD bitrate:
http://labs.adobe.com/technologies/flashplayer9/fullscreendemo/backcountry_bombshells_4min_HD_H264.mp4

[Sharktooth]

we're always talking about a CG (very compressible) source. 2mbps will be interesting... :)

[Dark Shikari]

2Mbps is good for 720p24(25) but very low for 1080p

Check this h264 720p sample (48,6MB) at SVCD bitrate:
http://labs.adobe.com/technologies/flashplayer9/fullscreendemo/backcountry_bombshells_4min_HD_H264.mp4
Well V for Vendetta, heavily denoised, looks just fine encoded at 670kbps albeit with some background blocking.

Elephant's Dream however is a much harder source IMO than a denoised movie because of the very high detail, which is one of the reasons I agreed to raise the bitrate.

[Kurtnoise]

why restrict the users to use an avisynth script (e.g windows users) as input ?

imo you should also accept mencoder or FFmpeg tools as input to have more users for this challenge...

mencoder c:// -mf w=1920:h=1080:fps=23.976:type=png -ovc .......



/just my 0,02 €

[708145]

Wow this is interesting/insane stuff. I thought I was pushing it with my idea to get 1080p60 in 5Mbit/s. But this is just more crazy :>

I hope somebody will include snow ;)

bis besser,
T0B1A5

[Dark Shikari]

why restrict the users to use an avisynth script (e.g windows users) as input ?

imo you should also accept mencoder or FFmpeg tools as input to have more users for this challenge...

mencoder c:// -mf w=1920:h=1080:fps=23.976:type=png -ovc .......



/just my 0,02 €That isn't a problem as long as it is functionally equivalent.

[akupenguin]

The question is whether mencoder's rgb->yv12 conversion is identical to avisynth's. Any differences would reduce metrics if you compare one to the other, without affecting real quality.

[Dark Shikari]

The question is whether mencoder's rgb->yv12 conversion is identical to avisynth's. Any differences would reduce metrics if you compare one to the other, without affecting real quality.
Of course. There's an easy workaround though; use Avisynth to losslessly compress the original to a YV12 format (FFV1, Lagarith, etc) and use that as the mencoder input.

[zambelli]

Whoa. 1080p at 2 Mbps? That's like trying to compress 480p at 330 kbps! Most QPs will be in the upper range of what the codec supports. :)

Any restrictions on buffer size or codec features?

[Dethis]

Whoa. 1080p at 2 Mbps? That's like trying to compress 480p at 330 kbps! ..........



It is rather equivalent to 480p@500-600 kbps according to this

http://forum.doom9.org/showthread.php?t=109569

[bond]

hm i would have more prefered a 1mbit test at DVD resolution instead of this more insane thing maybe hardly being used in reallife

[buzzqw]

i agree with bond

even on lan server the streaming don't go over dvd resolution

i would prefer too dvd resolution at 1mb

hd material (over/equal 720p) i doubt will be in streaming in a near future (5 year).. well maybe in japan... with all those optical cables

BHH

[Dark Shikari]

i agree with bond

even on lan server the streaming don't go over dvd resolution

i would prefer too dvd resolution at 1mb

hd material (over/equal 720p) i doubt will be in streaming in a near future (5 year).. well maybe in japan... with all those optical cables

BHH
Stage6 already streams up to 1080p, and it only uses MPEG-4 ASP.

[buzzqw]

at witch bitrate ?

BHH

[Dark Shikari]

at witch bitrate ?

BHHProbably depends on the uploader. The SD stuff I've found is mostly 1 megabit.

[arfster]

1080p @ 2mbit is quite possible with x264, at least with more compressible stuff. Sure it looks poor by HD standards, and high movement scenes really suffer, but it's whole lot better than SD mpeg2 at the same bitrate.

[Dark Shikari]

1080p @ 2mbit is quite possible with x264, at least with more compressible stuff. Sure it looks poor by HD standards, and high movement scenes really suffer, but it's whole lot better than SD mpeg2 at the same bitrate.I would guess it should be possible with VC-1, VP7, Snow, and many other modern codecs too; all that I need is for them to come forward and put in an entry :cool:

[arfster]

hd material (over/equal 720p) i doubt will be in streaming in a near future (5 year).. well maybe in japan... with all those optical cables


You don't need fibre - they've been doing 1080p in France for a while now over adsl2+. In Germany vdsl2 50mbit is entirely based on HDTV revenues.

[buzzqw]

with my misery 512kbps i will able to stream hd.. but the quality ?

here in italy the mayor ISP, ex monopolist Telecom, offer a 20mb adsl2 ... but the streaming sucks, hard.

they can offer what want in HD (from sport to movie) but HD material need bitrate, a lot... expecially if you know what is HD and what quality can be achivied.

i will stay away from a such service as offered by this challenge, i will not subscribe an offer of HD on 1mbs. Point.

just my 0.02€

BHH

[woah!]

can this test be trimmed down to say 2000frames instead of doing the whole 16591. as long as its agreed which part to test with, it could help with changing settings and not having to wait 10hrs an encode...

[Dark Shikari]

can this test be trimmed down to say 2000frames instead of doing the whole 16591. as long as its agreed which part to test with, it could help with changing settings and not having to wait 10hrs an encode...Well you can optimize the settings for the first 2000 frames, and then do the final encode on the all the frames. Usually what helps the first frames helps the rest too.

[woah!]

but the result might not best the ssim/psnr even if the first 2000frames encode did. you are still guessing/waiting to see.

if the test is 2000-3000 frames it can be used for 100% testing every time.

[drbuzz0]

This is an interesting challenge. I don't see the problem with using 2 megabits. True, 1080p is going to look pretty crappy at that bitrate, no matter what codec you use, but it's a decent rate to tell the difference between various codecs. At that bitrate there will certainly be plenty of noticable degradation.

It can be a starting point to say "If this video looks even semi-tolerable at 2mbps with this codec, then it ought to be decent at 4mbps, good at 5 and pretty damn good at 6-8mbps"


Alright... it's not a perfect measure but it's an interesting challenge. I may bite when/if I get that nice fast computer I've been planning for a while...

[zambelli]

It is rather equivalent to 480p@500-600 kbps according to this
http://forum.doom9.org/showthread.php?t=109569
Not according to my math.
720*480 *2000 kbps / (1920*1080) = 333.33 kbps
Granted, that's only taking bits/pixel into consideration and not bits/macroblock.

1080p @ 2mbit is quite possible with x264, at least with more compressible stuff. Sure it looks poor by HD standards, and high movement scenes really suffer, but it's whole lot better than SD mpeg2 at the same bitrate.
I really doubt that. The only thing you gain by going from SD to HD while keeping the same bitrate is less obvious pixelization in the HD picture. However, the high quantization in HD will smooth away most detail, producing a blurry picture that when viewed from afar (where pixels can't be recognized) will look no sharper than the SD. The SD, on the other hand, won't suffer from anywhere near the blockiness of the HD encode due to its reasonably low quantization levels.

In general, I think the winner of this challenge will be the encoder with the most agressive filtering. HD at 2 Mbps stands to produce a high level of blockiness. I would assume that most people will prefer a softer but consistent picture over a sharp but blocky picture. The same probably holds true for SSIM.

[akupenguin]

Not according to my math.
720*480 *2000 kbps / (1920*1080) = 333.33 kbps
Granted, that's only taking bits/pixel into consideration and not bits/macroblock.

bits/pixel is the same metric as bits/macroblock (unless you have a codec with variable-sized macroblocks?)
The point of Dethis's link is that the required bits for a given quality (in both HVS and objective quality) scales sub-linearly with resolution.

[Sagittaire]

Not according to my math.
720*480 *2000 kbps / (1920*1080) = 333.33 kbps
Granted, that's only taking bits/pixel into consideration and not bits/macroblock.


It's true for bits/pixel but not for quality/pixel or quantisation/block. Same "quality" by pixel use this empirical function:

Bitrate / ( Width x Height x framerate ) ^ N
N = 0.75 work well in general case.


Bitrate / ( 720 x 480 x 24 ) ^ 0.75 = 2000000 / ( 1920 x 1080 x 24 ) ^ 0.75

Bitrate ~ 525 kbps if you want the same quantizer. And here it's just quantizer comparison. Anyway there are not the same relative size for video artefact (blocking, ringing ...) with 8x8 dct based structure in 1080p and 480p encoding. For real visual comparison you can certainely use N at 0.5.

[drbuzz0]

Not according to my math.
720*480 *2000 kbps / (1920*1080) = 333.33 kbps
Granted, that's only taking bits/pixel into consideration and not bits/macroblock.


I really doubt that. The only thing you gain by going from SD to HD while keeping the same bitrate is less obvious pixelization in the HD picture. However, the high quantization in HD will smooth away most detail, producing a blurry picture that when viewed from afar (where pixels can't be recognized) will look no sharper than the SD. The SD, on the other hand, won't suffer from anywhere near the blockiness of the HD encode due to its reasonably low quantization levels.

In general, I think the winner of this challenge will be the encoder with the most agressive filtering. HD at 2 Mbps stands to produce a high level of blockiness. I would assume that most people will prefer a softer but consistent picture over a sharp but blocky picture. The same probably holds true for SSIM.

I agree that there's not a lot of point in going to HD from SD if the bitrate is not sufficient for additional information to be effectively conveyed.

Although it depends a lot on how the compression is set, the codec, bitrate and such, I've seen HD that is so heavily compressed that I would honestly rather watch the same content in SD without noticable blocking and artifacts than in HD with the godaweful compression artifacts.

Decent SD scaled up to HD is very much watchable and in most cases pretty good.

When I watch HD and see an explosion or a waterfall turn into a mess of blocks I can feel a little part of me die inside. It's just torturous to see that.

[zambelli]

The point of Dethis's link is that the required bits for a given quality (in both HVS and objective quality) scales sub-linearly with resolution.
It's true for bits/pixel but not for quality/pixel or quantisation/block. Same "quality" by pixel use this empirical function:
Bitrate / ( Width x Height x framerate ) ^ N
N = 0.75 work well in general case.
Thanks for the clarification!

[zambelli]

I agree that there's not a lot of point in going to HD from SD if the bitrate is not sufficient for additional information to be effectively conveyed.
The Elephants Dream source is somewhat deceitfully easy to compress actually, so I'm not surprised people want to try to compress it to 2 Mbps. A lot of scenes will look surprisingly good and might give some merit to HD encoding at that bitrate, but those action sequences with the guys running - forget about it, no way. Compressing "real world" HD content at 2 Mbps would definitely be more like the difficult sequences in ED - a big blocky blurry mess.

[Dark Shikari]

The Elephants Dream source is somewhat deceitfully easy to compress actually, so I'm not surprised people want to try to compress it to 2 Mbps. A lot of scenes will look surprisingly good and might give some merit to HD encoding at that bitrate, but those action sequences with the guys running - forget about it, no way. Compressing "real world" HD content at 2 Mbps would definitely be more like the difficult sequences in ED - a big blocky blurry mess.My denoised V for Vendetta compressed easily at about 670kbps with relatively little blocking at 720p. The "blocky mess" is due to noise I would think, not the content itself. ED has a lot more motion than most movies, I would think. And the high-motion scenes don't really choke--remember, this isn't CBR, so more bits do get allocated to those scenes. I wouldn't be surprised if the peak bitrate was 5, 6, 7 Mbit/s or higher.

[CruNcher]

but Dark Shikari face it Vendeta looks unatural @ the faces they are clear like nothing (angelized) that's not what HD was made for i arrived now @ 1080p keeping alot of details :) but it still looks a little artificial tough, because of the inloop filtering (and x264s bad angelized p frame quality) i use now but not as artificial as your (hyper ultra low bitrate example).
i reach arround a PSNR of 40 dB now (for most scenes) without altering the source alot now and with very decent compression settings and encoding time exactly what i had in mind when i created EDP i can gain the same with X264 but in HD only difference i was able to keep the grain with Mpeg-4 ASP even @ lower SD resolutions with X264 that's a no go i tried everything it endsup in being a no real visible layer (only i frames don't destroy the grain layer @ so low bitrates even @ high quants, p and b no go) thats moving in the background (but it doesn't flicker at least like it did in the beginning of H.264 codecs) but it's better i think then to eliminate it completly :)
so yes basicly i reached 3h DVD5 1080p (Visualy acceptable (not that far away of Visuall loossless, if the detail preservation problems wouldn't exist and x264 would blur less) now and i have still power left in terms of compression i really wonder if i could reach this with VC-1 too this way) no problem with H.264 (x264), but for this you have to keep in mind im working with allready compressed Mpeg-2 source (im still visuall tweaking to find ways to spend the bits more efficient in the proper places and how this reacts on other scenes with high motion and when it becomes visible useing high deadzone values in the proper places can help alot without destroying those scenes to much (they get more blurry but it isn't really that perceptable for high motion scenes (it's a decent blurring much less then a external denoiser would add (but can help in getting qp difference of more then 3 steps) keeping fine textures much better preserved especialy on faces i allready compared it vs removegrains lowest mode and it's much more efficient).
Btw im not sure (based on all my tests and visuall experience now with different H.264 implementations) that X264 is gonna position high @ this years MSU Codec test there are major differences now compared to the commercial encoders especialy in terms of Visual Tweaking (HVS improvements) Ateme and Mainconcept seem to be much farther by now.

PS: Alone the visual quality of p frames in Atemes implementation is stunning compared vs x264 they preserve much much more details and even background grain/noise without useing any fgm @ all
x264 --deadzone-inter 0, --no-fast-pskip, --no-dct-decimate nor --partitions all can't help with this (also @ lower quants the visual quality is stying the same no more detail preservation then Ateme), also a higher --me doesn't help subme was 1 but still slower then Atemes fastest mode, i really wonder were x264 wastes all the bits on, that makes abr even not hit the correct bitrate most of the time.

[chickenmonger]

Just this last weekend, I downloaded the first 2000 frames of Elephants Dream to try my hand at this compression test. Just for fun, I used MeGUI to encode those 2000 frames to Snow. Five hours later, I had the approximately 80 seconds of video encoded. My computer (Athlon XP 2200+) wasn't even close to being up to the task of playing back that file in realtime. The few frames it did decode looked decent, though. I was able to "play" it in MPC 6.4.9.0+ with ffdshow tryouts revision 1437, and also in ffplay Rev 10141. Other software may also work.

http://rapidshare.com/files/51720698/ED_snow.avi.html


Starting job job1 at 4:46:40 PM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
"C:\ed\input.avs" -ovc lavc -o NUL: -passlogfile "C:\ed\input.stats" -lavcopts vcodec=snow:vpass=1:vqscale=5:cmp=1:subcmp=1:mbcmp=1:qpel:vstrict=-2
successfully started encoding
Processing ended at 8:56:00 PM
----------------------

Log for job job1

MEncoder dev-SVN-r23107-4.3.0 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2200+ (Family: 6, Model: 8, Stepping: 0)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
success: format: 0 data: 0x0 - 0xd8
AVS file format detected.
VIDEO: [YV12] 1920x1080 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:1920x1080 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
videocodec: libavcodec (1920x1080 fourcc=574f4e53 [SNOW])
[VE_LAVC] Using constant qscale = 5.000000 (VBR).
Selected video codec: [rawyv12] vfm: raw (RAW YV12)
==========================================================================

Video stream: 2140.126 kbit/s (267515 B/s) size: 22315297 bytes 83.417 secs 2000 frames

------------------------------------------------------

Starting job job2 at 8:56:03 PM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
"C:\ed\input.avs" -ovc lavc -passlogfile "C:\ed\input.stats" -lavcopts vcodec=snow:vpass=2:vbitrate=2000:cmp=1:subcmp=1:mbcmp=1:qpel:vstrict=-2 -o "C:\ed\input.avi" -of avi -ffourcc SNOW
successfully started encoding
Processing ended at 9:50:01 PM
----------------------

Log for job job2

MEncoder dev-SVN-r23107-4.3.0 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) XP 2200+ (Family: 6, Model: 8, Stepping: 0)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.
success: format: 0 data: 0x0 - 0xd8
AVS file format detected.
VIDEO: [YV12] 1920x1080 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:38 fourcc:0x32315659 size:1920x1080 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
videocodec: libavcodec (1920x1080 fourcc=574f4e53 [SNOW])
Selected video codec: [rawyv12] vfm: raw (RAW YV12)
==========================================================================
Forcing output FourCC to 574f4e53 [SNOW].

Video stream: 1999.924 kbit/s (249990 B/s) size: 20853400 bytes 83.417 secs 2000 frames
desired video bitrate of this job: 2000 kbit/s - obtained video bitrate (approximate): 2005 kbit/s
----------------------

[Dark Shikari]

Just this last weekend, I downloaded the first 2000 frames of Elephants Dream to try my hand at this compression test. Just for fun, I used MeGUI to encode those 2000 frames to Snow. Five hours later, I had the approximately 80 seconds of video encoded. My computer (Athlon XP 2200+) wasn't even close to being up to the task of playing back that file in realtime. The few frames it did decode looked decent, though. I was able to "play" it in MPC 6.4.9.0+ with ffdshow tryouts revision 1437, and also in ffplay Rev 10141. Other software may also work.
Can't play it nearly realtime here either, but still, this clip is quite interesting.

I'd say in terms of quality Snow and H.264 are like Ogg and HE-AAC+. At very low bitrates, AAC sounds much better, but on the other hand, Ogg's "failure mode"--the noticable artifacting that can be heard when the bitrate is too low--is much more pleasing than the metallic warbling of MP3 and AAC. Snow is the same way; H.264 blocks when it runs out of bits, but Snow does a strange sort of liquid blurring that is not nearly as bad visually.

H.264 in this case still easily beats Snow in terms of visual quality, but if one lowered the bitrate on H.264 until the SSIM was equal, Snow would look much better visually at that point.

[CruNcher]

yep but that look & feel is nothing new Dark Shikari the old time Wavelet codecs behaved the same ways then the new ones like Indeo Interactive or VDOnet, it's just that the new ones (Snow, rududu,Dirac,Bergwave) are more efficient then the older ones (compression), but for example one thing that's also possible with Mpeg now is to almost stream all the complexity to the decoding (with wavelets back the time this was almost allways the case encoding was superfast decoding super slow, and i think not much changed even with the new Wavelet Generation here, but if even the researcher (Detlev Marpe) that has the patents for CABAC writes in one of his paper that the new Wavelets seem to be more efficient then what H.264 (block based) is able off now, then this allready means something i think ;)