Elephants Dream SD (360p) challenge

[Inventive Software]

Not to dig at the HD challenges going on, but I have the lossless 360p source, cause it's all I can handle at the moment until I get my new laptop PSU, and I intend to make good use of it. :D

So far, the little tests I've done involved encoding just the video to: DivX, Xvid, WMV8 (included because it's apparantly the last generation of MS MPEG-4 codecs that fly through encoding, but need high bitrates), WMV9 AP, x264 AVC and VP7. 2 pass settings were used, and the target bitrate was 1 Mbit, with a 5 Mbit peak bitrate. Defaults were used for most codecs. All the codecs bar WMV8 performed great (though I think I mis-set the peak bitrate on DivX and Xvid, so may have to re-encode them to check), so I did some quick calculations on plausible target bitrates.

Sagittaire in the 1080p challenge thread is targetting 18, 12, and 6 Mbit bitrates for MPEG-2, AVC, and VC-1. 6 Mbit I thought was a real challenging bitrate for 1080p, so I worked out the relative bitrate difference between the SD 360p source and the HD 1080p source.

The way I calculated the difference was to see how many 360p sources would fit in a 1080p source. I didn't do an AviSynth script, since that would almost certainly kill my computer! But... (this is all theory, but works out coshure in the real world), when you double the resolution of 640x360, you get: 1280x720. However, because we're working with 4 sides (think squares / rectangles / quadrangles / whatever you call it) when you double the resolution, you double the width and height, therefore you can fit 4 of the 640x360 in the 1280x720 space. Now, we can't double it again, since that's too big for 1080p, but we go back to 640x360 and multiply it by 3. This gives us 1920x1080. Bingo, our 1080p resolution. There are now 9 640x360 images in our 1920x1080 image.

1 Mbit I found was quite easy for the codecs to encode, and no wonder. 9 Mbit on an HD source is easy for both ASP, VC-1 and AVC codecs to encode. Even VP7 could tackle that with no problems. So my next target is to halve the bitrate, and encode at 500 kbits.

This is where I need the codec settings, since I'm sure what I'm using is almost completely wrong (especially in the VC-1 case). WMV8 gets thrown out of the window cause it'll be crap (preliminary tests told me this!). So (basically) I need settings suggestions for: DivX, Xvid, x264, WMV9 AP, and VP7. Please. ;) Target bitrate is 500 kbits/sec.

[Dark Shikari]

x264?

--subme 7 --no-fast-pskip --me umh --deblock -1:-1 --b-pyramid --weightb --bime --trellis 2 (only use trellis 2 on second pass) --ref 6 (--ref 16 if you want to be crazy) --threads auto --thread-input --mixed-refs --bframe 16 --partitions all --8x8dct --progress

If you feel like wasting tons of CPU time, use my modified x264 build (http://www.mediafire.com/?4dotcwznuy1) (singlethreaded only) and it will beat out the regular x264 build by a decent amount in terms of SSIM metric, which you can see in the 1080p HD test.

[CruNcher]

im not sure if this is the correct way to compare codecs shouldn't we compare everything @ alone first and so for example left the ratecontroll aside and do a raw I,P comparision first and latter B and then ratecontroll ? also to get an idea of the Visual Quality (and maybe even find bugs this way) for every of those 3 at @ constant quant so also checking the complete quant range and Decoding Efficiency without a ratecontroll involved sure it will be a massive testing (also taking bitrate into account and even different samples), and dont forget Vp7 doesn't use b-frames @ all gives it an decoding (complexity) advance over the others so just to compare codecs in the full form i think that's a easy way but wrong (especialy ratecontrolls are improved fast these days but the basics not so fast ;) )

So yes what i really suggest is to start @ 0 for every encoder (and passing 3 tests SSIM,PSNR and blind test) and work the way up (this will be a massive amount of data we would get about every encoder and indeed very time consumeing i did something similiar based on PSNR with XviD lab (automated aproach) (blind testing was done by myself here on doom9) and alot of different possible codec tools in different situations and this way indeed found some bugs in XviD) so 1 encoder @ the time and maybe even first try different encoders from different standards and compare them against from 0 (and then chose the best overal winner from the (PSNR,SSIM and Blind test) and then compare it against the other winner from the other standard (jesus that would be really massive) 24 hour 7 days a week testing for several weeks (especialy if you would also seperatae HD/SD with different samples for every Encoder) (sure most probably the results would be outdated for every new update) so if this takes a half year for every encoder you could for sure improve them in that time also at least report alot of bugs :P.

[Inventive Software]

I forgot to mention some things.... I don't give a flying **** about metrics. :D They're numbers, and can't account for the (in)accuracy of human eyesight. I will be uploading the encoded videos online soon so you's can all view them at your leisure. PNG screenshots of certain frames and areas are of course obligatory. :)

EDIT: Thanks for the command line Dark Shikari. I wasn't aware of the --trellis 2 switch only being useful on 2nd pass, so thanks, and may save some time on 1st pass. :) What's the difference between your build and Cef's build that I use currently?

CruNcher: Can you see a fault with wanting to compare codecs visually (not with numbers) at a target bitrate? In theory, all the codecs I picked can hit that target, so let's have them attack it and see. ;)

[shon3i]

Very good idea indeed :) I thinked to do some thing, but i don't have time.

Inventive Software, i agree with you about codec choice, but i think we can include Ateme Digitral Serie Encoder AVC (not Nero Recode), Elecard Converter Studio AVC. Can you provide me source i can make encodes with this two encoders @ 500kbps :)

[Dark Shikari]

I forgot to mention some things.... I don't give a flying **** about metrics. :D They're numbers, and can't account for the (in)accuracy of human eyesight. I will be uploading the encoded videos online soon so you's can all view them at your leisure. PNG screenshots of certain frames and areas are of course obligatory. :)

EDIT: Thanks for the command line Dark Shikari. I wasn't aware of the --trellis 2 switch only being useful on 2nd pass, so thanks, and may save some time on 1st pass. :) What's the difference between your build and Cef's build that I use currently?

CruNcher: Can you see a fault with wanting to compare codecs visually (not with numbers) at a target bitrate? In theory, all the codecs I picked can hit that target, so let's have them attack it and see. ;)
--trellis 2 on the first pass is very bad as it can destroy visual quality. If you're really looking for visual quality, adaptive quantization might not be a bad idea either!

If you're using human visual quality instead of metrics, I might also suggest you avoid --trellis 2 altogether.

My build uses a different motion search metric that is completely unoptimized at the moment but is tuned for SSIM metric, which is well-correlated with human perception, which hopefully means that it looks better to the human eye, too.

For the encoding, I don't see why one should use a Constant Quantizer--we're testing each of the codecs as a whole, and that includes their ratecontrol aspects.

[Inventive Software]

Source is Elephants Dream lossless, 360p. http://media.xiph.org/ED. AviSynth script:
ImageReader("%05.png",1,15691)

(Off the top of my very bad head).

I have chosen just one implementation of AVC and VC-1 because at the moment it's a casual test, and I'm not playing about with others that I'm unfamiliar with. They also (IIRC) aren't free. DivX and Xvid are quite different in their philosophies, so they are both included (DivX is faster than Xvid).

[Golgot13]

I forgot to mention some things.... I don't give a flying **** about metrics. :D They're numbers, and can't account for the (in)accuracy of human eyesight.


Can you provide me source i can make encodes with this two encoders @ 500kbps


It's clear @500kbps we will not need metric to compare codec (VC1 vs H264).
VC1 is adapted to high bitrate (need low CPU than H264 with CABAC option).

And about Ateme software and Elecard, all people can test himself the result
because the software are not free (about Ateme software it's the CLI version ?).

[CruNcher]

Inventive you should also add Nero Digital ASP (Ateme) and 3ivx they should also have improved over the years (but sure this makes it even more complex then it allready is, especialy if i think from the "from zero idea" and don't forget libavcodec) :P

For me it looks like this



Low Bitrate Contenders High Bitrate Contenders
H.264,Vp7,RV10,AVS,VC-1,XVD Mpeg-1 (still questionable),Mpeg-2,SP/ASP,H.264,VC-1,VP7,RV10,AVS,XVD



The same look & feel (not taking into account how much Detail they preserve or compression efficiency just the look & feel based on Technology they use)

Generations:

1st/4th: Snow,Dirac,Rududu,Loco,BergWave (a not so complete new look and feel more like Indeo 4.1/5.1,VDO) jep a big Comeback you could say ;) and it will blast big time :D
1st: Mpeg-1,Mpeg-2
2nd: SP/ASP,WMV8,XVD (look a little different to Mpeg-1/2 but not like the next Generation Codecs it's in between those with PP it goes more into the next Generation look & feel)
3rd: H.264,VP7,RV9/10,AVS,VC-1 (introduced a new look & feel)

[shon3i]

because the software are not free (about Ateme software it's the CLI version ?).OK, i realise that but i think to test AVC codec's in same time :)

About ateme, isn't cli, but is more detailed than nero recode, it have open gop, VBR (CRF), ABR, CBR, 2Pass, CQM, Lossless, AQ, Pulldown, ability to set different number of references frames indepedently for P and B frames and much more

EDIT: The main reason why i was to include Ateme and Elecard is their AQ's both have exellent solutions comparing to x264 AQ. AQ can help much on 500kbps.

[akupenguin]

--trellis 2 on the first pass is very bad as it can destroy visual quality.
Got some evidence to back that up?
My theoretical knowledge of how it works says that the only effect that any option can have on the first pass is to modify frame types or bits-per-qp. Trellis isn't used during frame type decision (no quantization at all is needed there), and trellis-2 vs trellis-1 makes very little difference to bits-per-qp. For that matter, trellis-2 only affects RDO, and I (and most other people who've posted their options here) usually don't use RDO on the first pass.
Granted, I haven't specifically tested the effects of trellis-2 on 2pass. I don't think I've ever encoded anything with trellis-2 enabled on the first pass, because I know that it can't make any difference. But please prove me wrong.

[microchip8]

Interesting read, akupenguin. I aways use trellis=2 for both the first and second pass, however on the first pass I use turbo=2. Does the turbo option disable trellis?

[Dark Shikari]

Got some evidence to back that up?
My theoretical knowledge of how it works says that the only effect that any option can have on the first pass is to modify frame types or bits-per-qp. Trellis isn't used during frame type decision (no quantization at all is needed there), and trellis-2 vs trellis-1 makes very little difference to bits-per-qp. For that matter, trellis-2 only affects RDO, and I (and most other people who've posted their options here) usually don't use RDO on the first pass.
Granted, I haven't specifically tested the effects of trellis-2 on 2pass. I don't think I've ever encoded anything with trellis-2 enabled on the first pass, because I know that it can't make any difference. But please prove me wrong.
I've always read that --trellis 2 is bad for the first pass. I haven't seen any proof, just echoing what I've seen passed around as advice.

In terms of visual quality, I also have seen (especially in the Trellis/AQ thread) that the degradation caused by Trellis-2 can require more AQ to make up for it visually, to the point where one loses efficiency.

[Sagittaire]

I've always read that --trellis 2 is bad for the first pass. I haven't seen any proof, just echoing what I've seen passed around as advice.

In terms of visual quality, I also have seen (especially in the Trellis/AQ thread) that the degradation caused by Trellis-2 can require more AQ to make up for it visually, to the point where one loses efficiency.


In first pass you write only stat for second pass. Use exactly the same setting for first and second is certainly little better for prediction.

[IgorC]

ED source isn't real movie but digital anime.
What if to use one of QT 1080p trailers. Choose one with high bitrate like 11-12 mbps and with high texture and filmgrain.
If Resize it with sharp resizer like Lancsoz4 to 360/480p it would be lossless stuff for this kind of resolution.

[benwaggoner]

Are you using WMCmd.vbs or Windows Media Encoder for the Windows Media version?

Also, what rate control model are you looking at (CBR, VBR, and with what buffer sizes)?

360p and these bitrates are interesting examples for streaming, and hence a CBR encoding shootout might be interesting.

I get a little frustrated by all the codec tests that use unbound peaks, which really isn't feasible for most real-world content, and doesn't provide real-world stresses on the rate control.

[benwaggoner]

Following up, for optimized visual appearance with WMV9-AP with this content, I recommend you use these registry keys:

DQuant: I and P frames
DQuant Method: Regular
Perceptual Method: Off
In-Loop Filter: On
Overlap Filter: On
Motion Search Level: Luma + True Chroma
Motion Search Range: Adaptive
Motion Match Method: Adaptive
B-Frame Number: 1
(if 1-pass encode) Lookahead=16
(if don't care much about encode time) Thread Number: 1

It's possible that 2 B-frames might be better at that frame size and bitrate; I haven't tried.

More broadly, you want to use Complexity 4/80. For VBR, use the unconstrained mode unless you're constraining the other codecs. For CBR streaming, use 2-pass, and an 8-second buffer is optimal for Advanced Fast Start from Windows Media Services.

Keyframe every 10 sec is probably a good default at this bitrate.

[Inventive Software]

Thank you benwaggoner, I was planning on using either one (WMcmd.vbs or WME) that I have encoding suggestions for, so I'll try at first with WME and those registry settings. I am constraining the other codecs to 5 Mbits, so I'll set that peak. It *should* be more than enough for all the codecs, so we'll see. ;)

CBR is interesting, I might try that later on, when this is all finished. :)

[Inventive Software]

ED source isn't real movie but digital anime.
What if to use one of QT 1080p trailers. Choose one with high bitrate like 11-12 mbps and with high texture and filmgrain.
If Resize it with sharp resizer like Lancsoz4 to 360/480p it would be lossless stuff for this kind of resolution.

No it wouldn't. ;)

Those trailers are not indicative of "normal" sources. Trailers usually have fast-moving action sequences, with lots of fades. They're not suitable for what I'm trying. ED is free and a reasonable challenge for all codecs. ;)

[zambelli]

Those trailers are not indicative of "normal" sources. Trailers usually have fast-moving action sequences, with lots of fades. They're not suitable for what I'm trying. ED is free and a reasonable challenge for all codecs. ;)
I don't know, I think ED is a little bit too easy. You might want to consider adding artificial grain to it with TrBarry's or FoxyShadis' AddGrain() plugin and then scaling it down. I think it'll make for a slightly more interesting source.

[zambelli]

What is the criteria for this encoding challenge? Metrics? Blind test? Popular poll?

500 kbps for 640x360 is pretty difficult, I think. 750 kbps might be more appropriate. Also, 5 Mbps peak might be a little overkill. That's 10 times the size of your average. That'be like encoding HD at 15 Mbps with a 150 Mbps peak. :) If you're going to use a peak that high, I think you might as well just go unconstrained.

Also, make sure you decide ahead of time whether you're going to be including decoder post-processing in the comparison - it's a pretty integral part of the coDEC experience at low bitrates.

[Golgot13]

What is the criteria for this encoding challenge? Metrics? Blind test? Popular poll?

500 kbps for 640x360 is pretty difficult, I think.


Me, I think 500kbps is good, today lot of people have access at web with ADSL 512kbps.
I prefer lower bitrate than 500kps, because with specific custom matrix in High Profil
H264 encoder can make some nice picture (I saw some H264 broadcast video and audio at 700kbps from live source!!!).

[Inventive Software]

The criteria is just simply to see which codec can produce the best picture at said average bitrate. It's not necessarily a blind test, but if fanboys start spouting how one codec is better than the other, I'll post screenies that ARE blind. You've been warned. ;)

@zambelli: You think a lower peak would do well? Bear in mind that SD content usually has quite a wider range for the bitrate than HD content does (think backing up your DVD to CD). Suggest a nicer peak bitrate, I was thinking probably 2 Mbps.

[zambelli]

The criteria is just simply to see which codec can produce the best picture at said average bitrate. It's not necessarily a blind test, but if fanboys start spouting how one codec is better than the other, I'll post screenies that ARE blind. You've been warned. ;)
I think blind tests are a good idea. In fact, my tired mind is thinking it'd be cool to write some server side code that extracted random frames from encoded videos and posted them on a website for people to rank. :) Consider this scenario: you write an Avisynth script that interleaves source video and compressed videos A, B and C. An ASP or PHP page generates a random frame number, then seeks to that position in the Avisynth script and saves the 4 frames to disk as PNGs, and finally posts them to the web page for visitors to rank in terms of quality. Enough visitors trigger this process - and you've got yourself some nice stats. :D
@zambelli: You think a lower peak would do well? Bear in mind that SD content usually has quite a wider range for the bitrate than HD content does (think backing up your DVD to CD). Suggest a nicer peak bitrate, I was thinking probably 2 Mbps.
I just meant to say that if you're going to have such a high peak, you might as well just remove the peak constraint all together.

[Golgot13]

The criteria is just simply to see which codec can produce the best picture at said average bitrate. It's not necessarily a blind test, but if fanboys start spouting how one codec is better than the other, I'll post screenies that ARE blind. You've been warned. ;).


:D so some people think I support H264 ? =>
Yes and no, I'm support and will support the best codec on specific use only.
I prefer WM9 than DiVX or I prefer h263 that "RealPlayer" format on nokia phone, WM9 for VoD on web,.....

About the screen picture, it will be nice if the people don't know which picture come from which codec
to be sure we judge the visual quality only. And it will be important that the colour, contrast, brightness
are exactly same (no post/pre process before encoding)

[Dark Shikari]

Lower bitrates are good for subjective tests because its much easier to distinguish between varying quality using only the eyes.

[IgorC]

It will be usefull to include vp6 codec since its web popularity and it has higher metric score comparing to ASP and VC-1 at low bitrate.

http://forum.doom9.org/showthread.php?t=90784
It's 2 years old test. Some codecs like VP7 and x264 were improved but it's pretty the same situation nowdays.

btw on2 is starting to support H.264 http://www.on2.com/company/news-room/press-releases/?id=411

[benwaggoner]

No one else likes my CBR encoding for streaming suggestion?

That said, 1 Mbps would be a more typical data rate for a streaming encode for SD.

[Inventive Software]

CBR is interesting, I might try that later on, when this is all finished. :)

I never said I'd rule it out totally. VP7, VC-1 support CBR, and both the ASP codecs I *THINK* support CBR, so this could be interesting.

1 Mbps for CBR streaming, 500 Kbits for VBR (constrained or unconstrained) sound OK? ;)

[benwaggoner]

I never said I'd rule it out totally. VP7, VC-1 support CBR, and both the ASP codecs I *THINK* support CBR, so this could be interesting.

1 Mbps for CBR streaming, 500 Kbits for VBR (constrained or unconstrained) sound OK? ;)
Yes, those are both interesting?

Should we cap the peak rate for the VBR? A good device peak could be 1.5 Mbps over 4 seconds.

[Inventive Software]

I had a fair amount of spare time yesterday, so set about encoding using benwaggoner's suggested registry settings within WME, with the one exception of using 2 B-frames. I used VBR unconstrained, with a bitrate of 500 Kbps. It took about 6 hours cause my computer's so slow. The result has been uploaded.

http://rapidshare.com/files/49519412/ED_VC-1_500_Kbit.wmv

@benwaggoner, zambelli (or those in the know for VC-1): the resulting encode didn't do too badly for the blocks, it's watchable, however the credits are, to put it mildly, bloody awful! When the credits aren't scrolling upwards, and are just some letters put on the screen, they look frankly dire. Is there a way of increasing the quality of that so that it's better?

[Sagittaire]

I had a fair amount of spare time yesterday, so set about encoding using benwaggoner's suggested registry settings within WME, with the one exception of using 2 B-frames. I used VBR unconstrained, with a bitrate of 500 Kbps. It took about 6 hours cause my computer's so slow. The result has been uploaded.

http://rapidshare.com/files/49519412/ED_VC-1_500_Kbit.wmv

@benwaggoner, zambelli (or those in the know for VC-1): the resulting encode didn't do too badly for the blocks, it's watchable, however the credits are, to put it mildly, bloody awful! When the credits aren't scrolling upwards, and are just some letters put on the screen, they look frankly dire. Is there a way of increasing the quality of that so that it's better?

Well I think that it's possible to produce really better result with VC1. For me quality is here really bad ...

[benwaggoner]

I had a fair amount of spare time yesterday, so set about encoding using benwaggoner's suggested registry settings within WME, with the one exception of using 2 B-frames. I used VBR unconstrained, with a bitrate of 500 Kbps. It took about 6 hours cause my computer's so slow. The result has been uploaded.

http://rapidshare.com/files/49519412/ED_VC-1_500_Kbit.wmv

@benwaggoner, zambelli (or those in the know for VC-1): the resulting encode didn't do too badly for the blocks, it's watchable, however the credits are, to put it mildly, bloody awful! When the credits aren't scrolling upwards, and are just some letters put on the screen, they look frankly dire. Is there a way of increasing the quality of that so that it's better?
Yeah, there's something weird about those credits that triggers that with the released codec. We're looking at it.

I used 2-B and didn't see that in my original result I posted.

[Inventive Software]

Sooooo.... what did I do wrong if any? I used them settings, and I got said result. In theory, that shouldn't happen, especially with unconstrained VBR.

I'm trying H.264 with both unconstrained and 1.5 Mbps peak bitrate to see the difference. Hopefully, all things equal and ordered, I'll have those files before I go on holiday, but it's unlikely. 10 days working holiday at a festival. Wish me luck! :)

[Inventive Software]

OK, I did that 500 Kbits VC-1 encode again, same settings (unconstrained VBR 2-pass), but with 1 B-Frame. The encode looked a LOT better in the credits. I'll upload later on. Perhaps it's a WMV9 or VC-1 quirk. :p

EDIT: VC-1 with 1 B-frame: http://rapidshare.com/files/54237006/Elephants_Dream_500_Kbit_1_B_Frame.wmv

[zambelli]

You might want to give Adaptive Dead Zone (-v_percopt 2) a try too. It might soften some of the texture detail, but it ought to reduce blocking in smooth areas.

[Inventive Software]

Seems 2 B-frames really isn't the way to go. So that's that one sorted. :)

ADZ at level 1 seemed to help a little bit, but would it help to go a bit further?

[benwaggoner]

Seems 2 B-frames really isn't the way to go. So that's that one sorted. :)

ADZ at level 1 seemed to help a little bit, but would it help to go a bit further?
Give it a shot - ADZ 1 is the default, but more sometimes helps. It's hard to predict when it does help, though.

[zambelli]

Increasing the ADZ strength is going to increase the deadzone delta in textured areas more aggressively. To put it differently: higher strength values will require less texture to trigger increases in deadzone, thus possibly also causing a deadzone increase in smooth areas.

Final attempt to translate that to English: if you increase ADZ strength, you're likely to see less detail retained overall.

[Inventive Software]

My intention was just to increase it to 2.

What I'm trying to (attempt to) do is reduce the blocking, which is reasonably annoying. I'll post the x264 file I encoded later on this afternoon so you can see the difference.

[bobololo]

I'll post the x264 file I encoded later on this afternoon so you can see the difference.

I'm curious to see how good will x264 be compared to the vc-1 clip you posted. Hehe I could feel like having my hands on that challenge and warming up some pieces of software that are lying around ;)

[Inventive Software]

Ask and ye shall receive (at least in this unique case! :D). This is the x264 file I encoded.

http://rapidshare.com/files/55384608/Elephants_Dream_AVC_500_Kbits.mp4

[bobololo]

Ask and ye shall receive (at least in this unique case! :D). This is the x264 file I encoded.

http://rapidshare.com/files/55384608/Elephants_Dream_AVC_500_Kbits.mp4

Pretty nice. It makes life hard for vc-1 which from my point of view is actually quite below... Maybe our MS fellows could jump into the game as well and submit something that would save VC-1 honour ;)

Btw did you those insane settings that Dark Shikari suggested ?

Beside, has anyone tried to produce an equivalent encode with MainConcept ? (I guess there are still improvements to expect among H.264 representatives compared to x264).

[Dark Shikari]

Pretty nice. It makes life hard for vc-1 which from my point of view is actually quite below... Maybe our MS fellows could jump into the game as well and submit something that would save VC-1 honour ;)

Btw did you those insane settings that Dark Shikari suggested ?

Beside, has anyone tried to produce an equivalent encode with MainConcept ? (I guess there are still improvements to expect among H.264 representatives compared to x264).
Since I made the suggestions in my original post, I've done a number of patches to x264, which I'll try when encoding for this thread once all the patches are compiled and ready:

--me imh (15-25% slower than UMH, about 1-1.3% higher quality)
--hadamard (50% slower with UMH, 60-70% slower with IMH, but up to 2%+ quality gain)
Improved --subme 7, 0.75% quality gain for 2.5% lower speed. Though this one isn't that big of a change, I like it because now --subme 6 to --subme 7 has almost the same gain that --subme 6 has over --subme 5, making it much more worthwhile.
Just posted this one: an ME prepass option, which improves quality about 1% (same as --me imh) for about 10-20% speed loss depending on encoding settings.

Small benefits, but they do add up.

If you really have too much time on your hands, run a --hadamard --me esa encode with the new patches :p

[Inventive Software]

I'm liking the --subme 7 option. Hadamard and --me imh are not worth the speed slow-down IMHO.;)

Off the top of my very ragged head, these were the settings I used for that encode:

CABAC, 4 Ref frames, mixed refs, 4 B-frames, adaptive b-frames, Inloop deblocker @ 0:0, Analyse all, all the b-frames options, 3 threads, --thread-input, no-fast-pskip, adaptive quantization @ 0.4.

I think you can use a hex editor on the MP4 file if anything I've told you's complete BS. :D

EDIT: I'm doing ANOTHER VC-1 encode with WME9 and WMV Powertoy. Powertoy settings I'll post an image of later.

[Inventive Software]

New VC-1 encode is on it's way. Powertoy settings were as follows:

http://img513.imageshack.us/img513/6326/wmv9vb6.jpg

2-pass VBR at 500 Kbits. About 2 hours to encode on my laptop. It actually looked quite good, but still wasn't up to H.264, especially in the fades. What could be done to improve that?

Note: I've done more VC-1 encodes than H.264. Doesn't that say enough? ;)

[Sharktooth]

pwnage...:)

[Inventive Software]

Absolutely! :D

That VC-1 encode if you're interested: http://rapidshare.com/files/55693442/Elephants_Dream_VC-1_500_Kbits_V3.wmv

[Sharktooth]

yes, i already had a look at it. however we all knew h.264 was way more efficient at lower bitrates, however VC-1 has some more "voice" at high bitrates. at least the h.264 advantage is heavily reduced.

[Dark Shikari]

yes, i already had a look at it. however we all knew h.264 was way more efficient at lower bitrates, however VC-1 has some more "voice" at high bitrates. at least the h.264 advantage is heavily reduced.
All codecs tend to converge at high bitrates to be honest. Low bitrates is where the codecs really start to shine.