[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 ;)

[drbuzz0]

Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.

the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?

Or is there actually a problem with the torrent?

[Dark Shikari]

Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.

the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?

Or is there actually a problem with the torrent?
You don't need to use the torrent--there's an FTP link there, I believe.

[CruNcher]

here is an example of x264 not so perfect p frame block decission compared vs Ateme useing the prestige matrix it was useing only i and p prediction

X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct (--no-fast-pskip plays no big difference here)
http://s3.directupload.net/images/070828/pDx5eAq4.png

X264 p-frame --deadzone-inter 0 (impacts rc imidiatly compression loss) --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct (--no-fast-pskip plays no big difference here)
http://s1.directupload.net/images/070828/CZr9Q4BW.png[/URL]

X264 p-frame --deadzone-inter 0 (impacts rc imidiatly compression loss) --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "all" --8x8dct (--no-fast-pskip plays no big difference here)
http://s3.directupload.net/images/070828/cWIEIDyk.png

Ateme p-frame --qual fastest ,part,hpel,qpel,xf8x8
http://s1.directupload.net/images/070828/FB93RWt8.png

times
X264 7:10
Ateme 7:30

target bitrate 3000 kbps
Ateme = 2990 kbps
X264 = 2983 kbps
X264 = 2981 kbps (--deadzone-inter 0)
X264 = 2975 kbps (--partitions "all")

even with a little deblocking applied Ateme would still preserve more details, where in X264 all the details are lost allready, and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)

another Ateme this is so great they achived with H.264 what i never could have achived with XviD EDP it's really the XviD of H.264 :)

this is how Low Bitrate HD H.264 has to Look & Feel :) (no blurring sharp edges fantastic)
[see post #60]

[akupenguin]

here is an example of x264 not so perfect p frame block decission compared vs Ateme useing the prestige matrix it was useing only i and p prediction
A picture doesn't illustrate the block decisions. And do you have the same frame with flat matrix?

even with a little deblocking applied Ateme would still preserve more details, where in X264 all the details are lost allready, and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)
Do you see any details? I only see noise, turned into blocky noise. (For the first frame, that is. The second frame looks great.)

[chickenmonger]

Um... the bit torrent link for the source doesn't work for me. I tried it with uTorrent, which should be Bittorrent version 4.x compatible. It gives an error on the torrent file.

the current bittorrent official client is version 6.0. Do I need to track down the old version 4.0?

Or is there actually a problem with the torrent?

I had trouble with the torrent file, too. I tried using Azureus, and it seemed to at least start the torrent, but it took a -long- time. I think it creates all the files at once. As you may imagine, there's a -lot- of files in that torrent. The following website has the files up for http download. It's how I got the first 2000 frames. I wouldn't use it for the entire movie, though.

http://media.xiph.org/

[zambelli]

I had trouble with the torrent file, too. I tried using Azureus, and it seemed to at least start the torrent, but it took a -long- time. I think it creates all the files at once. As you may imagine, there's a -lot- of files in that torrent. The following website has the files up for http download. It's how I got the first 2000 frames. I wouldn't use it for the entire movie, though.

http://media.xiph.org/
Download a the Wget client (http://users.ugent.be/~bpuype/wget/#download) and run this:
wget -r -l 1 -A png http://media.xiph.org/ED/ED-1080-png/

[zambelli]

Do you see any details? I only see noise, turned into blocky noise. (For the first frame, that is. The second frame looks great.)
The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.

[akupenguin]

"second frame" = the one that Cruncher only showed one version of.

For the first frame with 3 versions of x264 and 1 of Ateme, I don't see any details in any of the 4 versions. Just that Ateme preserved some noise which x264 smoothed out.

[Golgot13]

The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.

You're right because Ateme is a professional encoder (not yet compliant with BD and HDDVD but sure soon...).
I listen some project to include "grain" optimization in X264....
And we will see after :devil:


and if the marketing of Microsoft is correct the detail preservation for this and VC-1 should be even much better ;)


Like St Thomas, I agree when I see. May be Zambelli can make a test with PEP at 3000Kbps but...
CruNcher can you give a little sequence at Zambelli?

A picture doesn't illustrate the block decisions.

Agree. It's much better to watch a small video encoded sequence to judge the picture quality.

[CruNcher]

"second frame" = the one that Cruncher only showed one version of.

For the first frame with 3 versions of x264 and 1 of Ateme, I don't see any details in any of the 4 versions. Just that Ateme preserved some noise which x264 smoothed out.

you right im gonna post the x264 version of that frame later today, but i doub't that x264 gonna look better (in detail preservation terms) im almost sure it will smooth out details, especialy with the standard deadzone settings. Im also prepareing a much more complex stream with different scenes to better be able to rate the decission and quality differences those are fairly short test sequences wich don't resamble a full source that precise this was just to see the general Look & Feel of both not how good they are @ compression.
Im not their yet to rate RDO of both also im no fan of to heavy compression and the Look & Feel this results in, im starting from the lowest point possible going the way up and this takes time.


The second x264 frame? All 3 x264 frames look pretty bad to me compared to the Ateme frame. The skin details are nearly entirely gone in all 3 x264 frames.
This is also very interesting you rate the quality based on what you see but you didn't saw the source yet as i didn't post that, aku looks @ it very different not from a user point of view but more from a tech guy pov :) "the power of visuall (p)(d)e(r)ception :D" best example to see why HVS is so important in lossy codecs.

Here are the dark sequence results

Ateme p-frame --qual fastest ,part,hpel,qpel,xf8x8
http://s1.directupload.net/images/070828/ABhGEu97.png

X264 p-frame --deadzone-inter 0 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct
http://s2.directupload.net/images/070901/C4HoYsAB.png

X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "p8x8" --8x8dct
http://s3.directupload.net/images/070901/qweWgNf7.png

X264 p-frame --deadzone-inter 21 --subme 1 --me dia --no-deblock --no-dct-decimate --partitions "all" --8x8dct
http://s3.directupload.net/images/070901/AY4FfFHA.png

[CruNcher]

VC-1 (consumer encoder WMP11) results


http://s4.directupload.net/images/070905/Jthcj885.png

http://s5.directupload.net/images/070905/iYfjmhUc.png

cscript WMCmd.vbs -input full.avs -output test.wmv -v_codec WVC1 -v_mode 0 -v_bitrate 3000000 -videoonly -v_dquantoption 0 -v_bframedist 0 -v_loopfilter 0 -v_complexity 0 -v_lookahead 0 -v_mbmodecost 0 -v_mmatch 1 -v_mslevel 0 -v_msrange 1 -v_mvcost 0 -v_percopt 0 -v_preset fast

this settings can be speedwise compared with the x264 and Ateme ones i used, only difference for the VC-1 encode is old ASP problems like smearing texture trails with this speed settings.

@zambelli wich option i have to increase to get rid only of those smearing trails ?

[Sharktooth]

ateme and VC-1 SS look sharper than x264 and pretty similar but VC-1 shows some blocking (and x264 too).
x264 seems to kill the small details and with deadzone set at 0 it seems to lack bitrate.
maybe subme 2 or more (maybe 4 or 5 but not higher) will do better in conjunction with deatzone-intra about 6. i would also use all partitions except p4x4, maybe umh and obvioulsy 8x8dct... im unsure about dct decimation too but i would remove it.
cruncher, could you post a screenshot encoded with those parameters?

[CruNcher]

yep gonna try that later (but i feel that highering the ME in anyway is gonna kill the grain even with a low deadzone) deadzone-intra 6 shouldn't really improve anything -deadzone-inter 6 you mean ? -deadzone-intra can be very high without any bad effect on the p-frame decission, if im correct intra frames only get a little more blurry then (this doesn't have any effect on p-frames except that they get more bits that where taken from the intra frames, i think) but they are so far away (in an unconstrained encode) from each other that this shouldn't get realy visible.
(in the first VC-1 frame you can really see how it preserved the grain almost completly, the second frame lacks from dquant i think so better balanced settings should improve that with hopefully don't destroy the grain that much as H.264 does, but a more important visually problem in the VC-1 encode are those smearing texture trails we know from ASP times @ the moment)

[CruNcher]

here are the results sharktooth (it got even more bad then i expected, im heading into unreality (source wise not real life) tough for sure nice for Anime/Comic or Digital Cinema :P )

--partitions "i4x4,i8x8,p8x8" --8x8dct --bframe 0 --no-deblock --me umh --subme 2 --deadzone-intra 32 --deadzone-inter 6
http://s4.directupload.net/images/070906/hchExq2o.png

http://s5.directupload.net/images/070906/vYq6TxX9.png

[Sharktooth]

yeah. looks smeared... but why deazone-intra 32?!?!? that's the source of smearing :p
use deadzone-intra 6 or something...

[benwaggoner]

@Cruncher

Those are pretty non-quality optimized settings! You'd likely get a lot better results for this test with the below (just general starting settings - I haven't seen the source yet):

cscript WMCmd.vbs -input full.avs -output test.wmv -v_codec WVC1 -v_mode 3 -v_bitrate 2000000 -videoonly -v_dquantoption 2 -v_bframedist 1 -v_loopfilter 1 -v_complexity 4 -v_mmatch 0 -v_mslevel 2 -v_msrange 0 -v_percopt 2

Why did you turn lookahead off in your settings? It's a nice help with all 1-pass encodes. Of course, 2-pass does better yet.

Of course, our new VC-1 Encoder SDK would be quite a bit faster and higher quality:

http://www.microsoft.com/presspass/press/2007/sep07/09-06VC1EncoderToolsPR.mspx

[CruNcher]

Of course, our new VC-1 Encoder SDK would be quite a bit faster and higher quality:


For sure as it isn't 1 Year old *rofl*

And to answer your lookahead question because i wan't to find out how advanced the encoders are and Grain and Low Bitrate are perfect to find out (without useing a workarround like FGT) how advanced the visual quality is and i test @ wich speed this target can be hit by the encoders, first without any additional extras so lowest speed settings possible and then i go slowly higher and look again and again and again and again very time consumeing process that is especialy for a full 3h HD source @ this low bitrate, your settings are still far away and sound very slow btw.
Lookahead is indeed a nice thing, because it doesn't take much speed and gives a nice precission boost (just a little more ram usage) but it doesn't change much of how the encoder handles different scenes visualy just the precission is enhanced and it wouldn't also get rid of those smearing trails i talked about most probably higher ME does but then the question is if VC-1 will keep the grain.

And sure Grain is bad and an old analog recording problem that most of Hollywood Directors sell nowdays as an "Artistic" thing that people get used to or better "druged" from it over the years especialy the older Generation (people that don't know anything else old Hollywood Lab workers for example), that's also why i doubt it will vanish in the coming Digital Cinema era completly it won't for sure and so more advanced codecs need to handle Grain (they shouldn't tough, because Grain is still an artifact) in the future for sure, todays Video Codecs arent advanced enough to preserve the grain @ those low bitrates (that's why FGT is exisiting, a simple workarround) but the way they handle a Grainy source nowdays is interesting for example the smearing trails of VC-1 at this bitrate aren't noticeable with H.264 at the same speed settings and this shows at least for me that current H.264 implementations are more advanced handling grainy sources (at low bitrates) for sure not optimal but good enough to give good results without any extra user interaction as degrain/noising or setting extra parameters (but as you said H.264 wise im testing with the newest from the newest and VC-1 wise im testing with 1 Year old technology, so im almost sure that i could spare my time and just throw VC-1 out of my tests :P (as the results would be allready outdated), and im sorry but i can't understand Microsofts consumer politics in that way this is only marketing for sure you gonna provide the average users with the new Encoder Core with WMP 12 that comes maybe next year or whatnot so you hold this advances back from the general public and i have no idea what this brings for Microsoft why do you hide your advances from the average users i can't understand it and seeing your press release this software is far away from the average users budget, and don't say it would take to much time doing a Encoder update for WMP11 VC-1 that you wan't to wait till WMP 12, if that's really the case it's no wonder that Microsoft can't keep up with the pace and sooner or later is gonna fall like the Roman Empire did ;) .

[Sharktooth]

you still havent tried my settings with a lower deadzone-intra... :p

[benwaggoner]

@CruNcher

Sorry, I've got too much jet lag to mentally figure out where to stick all the punctuation.

But if your challenge is to try and preserve film grain with FSDK 11, I recommend you try these settings:

DQuant: I+P frames only
DQuant Method: Regular
Perceptal Option: Adaptive Dead-Zone 1
I-Loop Filter: On
Overlap Filter: On
Motion Search Level: Fixed True Chroma
Motion Match Method: Adaptive
B-Frame Number:1

As for the commercial license, we're not saying there won't be future updates to the free codec. But the Format SDK 11 is a Windows Component, and it's up to Windows to release those updates on their schedule. We're doing the VC-1 Encoder program as a way to provide additional improvements to commercial compresion products and processes on a more rapid schedule than tying to a Windows release schedule and release requirements would allow.

I realize that isn't a big help to this specific community, but certainly will address the needs of most professional compression service providers, and the viewers of commecial compressed media. But I hope we can find a good way to provide improvements to the user-generated content market as well.

I keep hoping someone is going to start a robust open-source "xvc1" effort to compete with our VC-1 implementation...