DeathTheSheep United: x264 Guide and VfW Builds

[Omni]

Anyone got a short hint for improving scene fades?
i get some big blocks on fades not over the whole image but on certain almost uni-colored faces. i'd say it's something about b-frames but i'm not totally sure ^_^

[Audionut]

range: [-12,12]
I have no idea when it might be usefull. I just implemented it because it's one of those obscure headers that someone might want to play with.


But it seems to only work with "I Frames".

Is that correct?

[akupenguin]

chroma-qp-offset applies equally to all frames.

[Audionut]

Well it's just that when encoding I always get psnr return figures of say,

Y=45 U=48 V=50.

So I tried increasing the Chroma-qp-offset to 12.
From memory it only seemed to greatly affect the I frames.
P,B Frames still had larger psnr values for chroma.

I'm in the middle of a large encode ATM, so it will be 2-3 hours before I can confirm.

[akupenguin]

What was the qp? Above qp=28, chroma_qp doesn't increase as fast as luma_qp, and it maxes out at luma_qp=51, chroma_qp=39. chroma_qp_offset is added to the lumna_qp before converting it to the chroma scale, so no amount of chroma_qp_offset will reduce chroma quality beyond 39.

[Audionut]

I just tried another encode, ensuring low quants.
And Chroma-qp-offset made an impact on PSNR.


Pass1.
C:\Program Files\x264>x264.exe --pass 1 --bitrate 2000 --stats "F:\2pass.log" --bframes 2
--b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000 --output NUL
"F:\test.avs"


avis [info]: 704x288 @ 25.00 fps (7063 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:47 Avg QP:15.06 size: 23452 PSNR Mean Y:49.06 U:45.86 V:46.75 Avg:47.88 Global:47.48
x264 [info]: slice P:1225 Avg QP:17.51 size: 12292 PSNR Mean Y:46.29 U:44.57 V:45.45 Avg:45.78 Global:45.47
x264 [info]: slice B:728 Avg QP:18.87 size: 5991 PSNR Mean Y:45.13 U:44.46 V:45.02 Avg:44.95 Global:44.54
x264 [info]: mb I I16..4: 17.3% 0.0% 82.7%
x264 [info]: mb P I16..4: 11.3% 0.0% 26.5% P16..4: 24.1% 21.2% 11.2% 0.0% 0.0% skip: 5.7%
x264 [info]: mb B I16..4: 2.4% 0.0% 5.3% B16..8: 50.1% 5.0% 10.9% direct: 5.9% skip:20.3%
x264 [info]: PSNR Mean Y:45.930 U:44.562 V:45.326 Avg:45.529 Global:45.139 kb/s: 2052.16

encoded 2000 frames, 18.22 fps, 2053.30 kb/s

Pass2.
C:\Program Files\x264>x264.exe --pass 2 --bitrate 2000 --stats "F:\2pass.log" --bframes 2
--b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000
--output "f:\test1.mkv" "F:\test.avs"


avis [info]: 704x288 @ 25.00 fps (7063 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:47 Avg QP:15.66 size: 21978 PSNR Mean Y:48.69 U:45.71 V:46.50 Avg:47.61 Global:47.37
x264 [info]: slice P:1225 Avg QP:17.49 size: 12149 PSNR Mean Y:46.29 U:44.60 V:45.46 Avg:45.80 Global:45.59
x264 [info]: slice B:728 Avg QP:18.97 size: 5666 PSNR Mean Y:45.08 U:44.40 V:44.88 Avg:44.90 Global:44.66
x264 [info]: mb I I16..4: 18.2% 0.0% 81.8%
x264 [info]: mb P I16..4: 11.6% 0.0% 25.7% P16..4: 25.2% 21.2% 10.4% 0.0% 0.0% skip: 6.1%
x264 [info]: mb B I16..4: 2.2% 0.0% 5.4% B16..8: 50.4% 3.8% 8.3% direct: 6.8% skip:23.2%
x264 [info]: PSNR Mean Y:45.905 U:44.553 V:45.271 Avg:45.513 Global:45.263 kb/s: 2004.07

encoded 2000 frames, 20.34 fps, 2005.21 kb/s

[DeathTheSheep]

When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or ****. Fix this issue, i don't intend to reinstall windows for this.

Wow, that's certainly never happened for me... Are you sure your installation file wasn't corrupt? Any bytes missing near the end? Which revision were you using?
I'm terribly sorry for your loss (of Windows, time, and respect for the x264 package).

[Sharktooth]

And here goes the first complaining about x264... When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or shit. Fix this issue, i don't intend to reinstall windows for this.
Where you downloaded x264?

[Kenshin5]

It was posted by you on the forums, it's an official built.

[Sharktooth]

Well... something screwed your registry then. The uninstaller only removes the x264 installation dir that's stored in a registry key... if "something" (virus,program,whatever) modified the path in that registry key or if your windows registry is screwed than it's not my fault.

[stephanV]

uhm... what if someone decides to install it in systems32? it is normal behaviour for an uninstaller to not remove the installation dir, if any other files are present that are not from installing the software. I'd say this IS your problem.

[Sharktooth]

uhm... maybe you're right...
i'll update the installer script for the next build.
however if you install it in system32 you're an idiot :D

[stephanV]

Maybe not an idiot, just unexperienced. ;)

[Revgen]

however if you install it in system32 you're an idiot :D

LOL! :D

[carlo_0000]

possible to update the topic with the new version ?

[DeathTheSheep]

A new version was planned, but this very early guide was written primarily for the vfw x264 of yesteryear, and recent settings packs for the newer, more updated CLI-frontend MeGui are generally considered the encoding norms of today (look for Sharktooth's "MeGUI Custom Video Profiles" included in Sharktooth's x264 Full Installation builds).

If people want it though, I suppose I could revamp it after New Years ;)

[DarkFoon]

I want it :)
So I have a better idea of how to improve sharktooth's profiles for my own uses.

[Arcon]

ok, i just did my first x264 encodes and started to fiddle around with the options, but i'm still wondering if i'm expecting too much.

the results x264 produces are very smooth, i'm used to do high bitrate xvid encodes with qpel enabled and usually watch them without postprocessing, so i prefer a sharp picture with high details with some grain over the clinically smoothed version.

what settings are mainly responsible for this in x264 and how can i tweak them to get x264 to produce more detailed and less smoothed pictures? or is x264 and the postprocessing that coupled that i will have to say goodbye to the grain and start to get used to smoothed pictures?

[Caroliano]

The inloop filter setings. If you want sharper pictures, use negative values. Disable it is not recomended.

[DeathTheSheep]

Yeah, check out the Deblocking section of the guide! Maybe it'll help ;)

@all: OK, I'll revamp it right after New Years! (Or maybe as a Christmas present??)

Cheers! And happy holidays for those of us who have 'em comin' up!

[Arcon]

Yeah, check out the Deblocking section of the guide! Maybe it'll help ;)
but is x264 generally able to produce a picture similar to xvid+qpel or is the concept with the inloop deblocking that hardwired and part of the codec that the picture will always be smoother (or blockier if you set the inloop to negative values) than those asp-encoders create?

currently i wonder if i'm just using it the wrong way or if h.264 might only be superior to asp-encoders in situations where postprocessing is used to conceal low bitrate blocks.

[DeathTheSheep]

It definately produces a picture that is somewhat...different than XviD.
AVC and ASP are indeed 2 very different formats despite their conformance to one or another part of "MPEG-4."

is x264 generally able to produce a picture similar to xvid+qpel
Since the objective of a codec is to reproduce the source as accurately as possible, both will look pretty similar (like the source) if given high enough bitrate. The deblocking options control how much x264's resulting image is smoothed. The default deblocking tends to produce fewer visible blocking and ringing artifacts than ASP even while maintaining the same PSNR.

XviD's artifacts in high-detail scenes are often mistaken for detail. The Human Visual System tends to see XviD's artifacting in spatially complex scenes as the scene's actual detail. Indeed, the HVS often confuses artifacting for detail, and because x264 removes this artifacting by default, the HVS percieves this to be a "loss of detail" even though technically x264's detail is just as accurate.
However, reducing the deblocking in accordance to the guide is the best way to go about sharpening the image (reducing the soft smearing of deblocking). You might as well give it a try on a small clip: do a 30-second clip with XviD and x264 with -1 or -2 deblocking and then evaluate.

The general consensus as of yet (at least according to the metrics) is that x264 does tend to keep more detail more accurately than XviD at similar bitrates. However, the deblocker's removal of artifacts is occasionally confused by the HVS as a removal of legitamate detail, which the artifacts are occasionally mistaken for. If you find this to be the case, use a post-processing filter (AVISynth, mplayer, ffdshow maybe) to better synthesize noise.

[Tommy Carrot]

but is x264 generally able to produce a picture similar to xvid+qpel or is the concept with the inloop deblocking that hardwired and part of the codec that the picture will always be smoother (or blockier if you set the inloop to negative values) than those asp-encoders create?
If you disable the deblocking completely, x264 will behave similarly to xvid, except that the produced video will be even sharper. I think it's safe to disable deblocking up to quant 22 (bitrate-wise it's somewhere between quant 3-4 in xvid, usually used for 2cd rips), but over that the blocking is starting to become disturbing, a light deblocking is recommended.

[DeathTheSheep]

TC is right in general, but the resulting video won't have nearly as good of a quality measure as a video attained by using the default (or -1) deblocking settings; if you want noise, you'd almost always get better results with post-processing. I'd certainly never recommend turning off deblocking under any condition (unless the decoder doesn't support it or AVC playback is too complex for your machine).

[Tommy Carrot]

Disabled deblocking may have lower results in quality measures, but it can look better, especially in near-transparent encodings, where the artifacts are already unnoticable, and the deblocking would destroy the very fine details.

[DeathTheSheep]

but it can look better, especially in near-transparent encodings, where the artifacts are already unnoticable, and the deblocking would destroy the very fine details.
Using the default settings, deblocking is automatically scaled based on the quantizer used. If the quantizer is very high, default deblocking is heigtened accordingly by the encoder, and once the quantizer drops low enough that the encoder deems deblocking to be useless, it is automatically disabled.
Therefore, it is best to leave it as it is: at (0,0) unless you have specific preferences with deviation of no more than +2/-2. The encoder should handle the rest.

[Tommy Carrot]

Lol, i know that deblocking strength is adaptive, but the default settings are not always the best. If someone prefer the 'xvid look' over the smoothness of h.264, imo it's better to disable the deblocking at higher bitrates (<q22), where the default setting is washing away too much details unnecessarily, because the artifacts are rarely noticable there anyway. Afaik deblocking is turning off by default at quant 15, which is way too low imo, and this probably answers why many people prefers xvid over x264 at high bitrates.

At lower bitrates though, i agree, in-loop filtering is very useful and beneficial.

[Caroliano]

You tried -5,-5? It may be better than disable it completely. H.264 was thought with deblocking in mind. It shoud be more blocky w/o deblocking than Xvid. But I don't know. I haven't tested yet.

[Arcon]

I'd certainly never recommend turning off deblocking under any condition
i usually filter out noise during the preprocessing and want the codec to keep the picture as close to that input material as possible. removing noise afterwards was something i only liked for low bitrate encodes (i.e. avg quant ~4) where the pp had to filter out the shortcomings introduced by the encoding process, not by the source material.

thats why i was a bit disappointed in the x264 look compared to my beloved xvid.

but thanks for the tips, i'll fiddle around with the settings and try to find something that gets close to my expectations :)

[DigitalDivide]

*B-frames can be activated in "pyramid" mode, which allows B-frames to serve as references. If you wish to use a lot of references (and thereby increase quality slightly), consider selecting the "Use as references" checkbox.

Am I missing something here? I don't see a checkbox for "Use as references".

[foxyshadis]

It's called "Pyramid" in MeGUI, but the option is still there in the VFW B-frame section (in MBs&Frames tab). It only activates if you have more than one B-frame.

[LiFe]

A question that google hasn't been able to find on doom9:

What's the difference between Constant Quantizer (qp) mode and Quality (crf) mode?

Thanks.

[slavickas]

A question that google hasn't been able to find on doom9:

What's the difference between Constant Quantizer (qp) mode and Quality (crf) mode?

Thanks.
why google when forum search tool finds it perfectly
http://forum.doom9.org/showthread.php?t=101551&highlight=crf
probably post #20 most explaining

[[)370|\|470!2]

How many passes should be used to get the possible "best-out-of" x264.
And btw, does bitrate setting in 1st pass affect following passes?

[DarkZell666]

actually 2pass is pretty good already, but 3pass has been proven to give visible better quality in some cases (the examples that comes to my mind is anime @ low-bitrate, e.g. < 400kbps, with very sudden bitrate changes).

Ask Sirber :p
You could consider using --crf instead, all depends on what you are trying to do :)

[carlo_0000]

possible to update the topic with the last version
there is a lot of change

[Sirber]

DeathTheSheep is unavailable until March 10 due to circumstances beyond his control. You're gunna have to wait ;)

[DeathTheSheep]

I'm back, and with a massive update to the guide! It's much better than ever--now with detailed pictures, descriptions, instructions, and suggestions, the all new, fully revamped DeathTheSheep x264 VFW Guide is like nothing you've ever seen before!

[Sirber]

Seems you do productive things in your "forced freetime" ;)

[akupenguin]

http://gabe.5000megs.com/DeathTheSheepAVCguide.pdf
You got scenecut threshold and bitrate variability backwards.
Higher scenecut => more keyframes.
Bitrate variability = 0 => constant bitrate.

[DeathTheSheep]

Tweaked. ;) Thanks for catching that before it could do any damage!

that darn qcomp...

akupenguin: What do you think about the rest of the guide? :)

[Sirber]

No more GUI clutter, no more CLI mess!... use RealAnime! :D

[3ngel]

@DeathTheSheep
Where is gone the section dedicated to "Maximum quality regardless cpu time"?
And when it'll be back? :)

[DeathTheSheep]

3ngel:
Hi! My guide now includes information about the added quality and speed penalty of different options, so it allows you to choose for yourself whether or not to activate certain options based on the extra time they take to encode.

For instance, disabling fast P-skip, as is stated in the guide, results in a very small overall quality increase of the encode, but it results in a longer encoding process. Therefore, I didn't recommend it for fast encodes unless blocking on flat textures is experienced. However, if you want the little bit of extra quality regardless of the encoding loss, feel free to turn it off.

It also explains, for example, that more reference frames tend to increase quality, but the speed penalty clearly outweighs their quality gains after 8 are used. However, based on the information that more are better, despite longer encoding time, feel free to use the maximum (16).

I hope I have been helpful to you, and if you are still having issues with this matter, I will consider revising the guide.

Thank you for your interest in DeathTheSheep's x264 VFW Guide, and have a nice day!

[3ngel]

Oh, i see... so in other words you've changed the organization of the guide. I found very comfortable in the first version of the guide to skip the first two parts (in which i was not interested) and concentrate only on the third part (maximum quality). I found it very simple and clear.
Now i have to read the entire guide trying to districate myself in all the parameters... I think that if you reabilitate the three parts it would be more clear and simple, but if you're not, well i'll try to read the entire guide :)

[Dyolfknip]

Great guide! Thanx Sheep.

[thuongshoo]

Thanks you ! I'm using VirtualDub and K-lite codec pack 271 . I don't see where "fast skip" is . Did "New version vfw" remove this option ?
thanks !

[ChronoCross]

klite codec pack is stupid. probably doesn't have a newer version. I recommend staying awway from all codec packs.

[Audionut]

AFAIK, vfw never had fast p-skip.

[Sagittaire]

A good bet for most people interested in high quality video would be the range of 20 (highest
quality) to 30 (lower quality), depending on individual preference and the amount of disk space
reserved for the encoded file.

Q30 for full HD resolution will be high quality encoding
Q20 for CQIF resolution will be low quality encoding

Resolution is really important here because DCT artefact size are always the same but not DCT artefact relative size : it's hard to see high blocking level at 1080p but not soft blocking level at CQIF/QIF resolution.

Little example:
sample 1 q20 512*288 done 1057 Kbps
sample 2 q24 720*400 done 1021 Kbps
sample 3 q30 1280*720 done 1023 Kbps

Find the best sample for yours eyes ... ???