get rid of these blocks?

[ArcticFox]

Im trying to encode a film i captured using x264 using 1P-Maxspeed profile and if you look

http://fox.ugug.co.uk/blocks.png

in the backgrounds you can see a lot of blocks, how do i get rid of these without significantly affecting the encoding rate.

# PLUGINS
LoadPlugin("C:\Program Files (x86)\GordianKnot\DGMPGDec\dgdecode.dll")
LoadPlugin("D:\Encoding\TIVTC.dll")
LoadPlugin("D:\Encoding\Undot.dll")
#LoadPlugin("C:\path\to\FDecimate.dll")

# SOURCE
mpeg2source("G:\HDTV\Projects\Goldeneye\goldeneye.d2v")
UnDot()

# IVTC TIVTC
tfm().tdecimate()

#Use Fdecimate when source is 720P
#FDecimate()

# CROPPING
crop(2,132,1916,816)

# SUBTITLES
#VobSub("FileName")

# RESIZING
LanczosResize(1280,544)

Trim(50000,51000)

[fields_g]

What bitrate are you using?

Run your AVS file in a player and see if they are there. I'm guessing they won't be. That means that has less to do with your script and more to do with your encoding settings.

[ArcticFox]

i think it was about 6000

[DarkZell666]

For the Nth time, blocking is "normal" in low contrast/flat areas, no matter what the bitrate is.

I can only suggest trying the following :

- Using --no-fast-pskip switch
- Using a cqm (they all tend to fight blocking nowadays, but create a bit more ringing, your choice)
- Encoding at constant quantizer (qp 10 to 15 for example), but I doubt it will change anything.

This thread might help (http://forum.doom9.org/showthread.php?t=107547), and the one mentionned at the end of it too.

Could you post a video sample ? I would suggest running hqdn3D()
on it to reduce temporal fluctuations since those blocks I see might just be caused by noise.

[nurbs]

IIRC the use of CQMs results in less blocking because fast-pskip doesn't work for them.
Also I think I remember reading that denoising can increase the problem, so adding noise would be the solution if there is to much blocking in general. If the blocks are caused by temporal noise as DarkZell666 suggests this doesn't apply of course.

[Oline 61]

blockbuster(method="dither")

[*.mp4 guy]

This cqm (http://rapidshare.de/files/21536922/M4G_High_Detail_AVC.cfg.html) should get rid of the problem, and it shouldn't introduce any noticible ringing at the bitrate your using.

[asdfsauce]

Will there ever be a solution to blocking in low-detail areas in the encoder itself? Because it seems to be a common theme among all h.264 implementations from my experience.

You can throw any amount of bitrate at your encode, but it seems like h.264 doesn't want to give these parts of the scene any bandwidth no matter what. I have tried many things - custom matrices seem to help the most, but not nearly enough.

Definitely h.264's biggest problem IMO.

[*.mp4 guy]

Will there ever be a solution to blocking in low-detail areas in the encoder itself? Because it seems to be a common theme among all h.264 implementations from my experience.

You can throw any amount of bitrate at your encode, but it seems like h.264 doesn't want to give these parts of the scene any bandwidth no matter what.
Matrices reasign which parts of the picture are most likely to get bits, so the solution is to use matrices. There are encoder specific tweaks to the way quantisization is handled that can help aswell, but they tend to have a similar effect to using matrices. However blocking is an inherant problem with block based transforms and reducing it is going to have costs in other areas, so reducing it beyond a certain point causes worse problems then it soves.

[ArcticFox]

Thanks for the help guys, ill have a play with some of the suggestions.

[Manao]

Matrices reasign which parts of the picture are most likely to get bitsHuh ? How could that be ? Custom matrices don't act like adaptive quantization. No, custom matrices *might* help to fight against blocking because it can be made into trading details for lack of blocks. But it's imho not the right way to fight it.

An easy way to fight blocking is to add noise during playback ( *not* during the encoding ). Noise makes blocks disappear ( or rather, makes your eyes unaware of them ). It's imho the most efficient way, since you don't waste any bitrate to fight something a codec isn't designed to cope with well. Furthermore, noise helps make the video look "more real" to your eyes, and should always be used, especially with AVC codecs that tend to act a lot more like a denoiser than ASP ones.

Finally, one might also want to try the gradfundb filter, that was recently added to ffdshow. It tries to do what noise does, but in a more "intelligent" way : it specifically targets areas of low variance ( hence where those blocks happens ), and dither them. There again, to be used during the playback ( since using it before encoding would only result in a yet again denoised video ).

[*.mp4 guy]

Huh ? How could that be ? Custom matrices don't act like adaptive quantization.

Large smoothe gradients consist of low frequencies, always. So a matrix that favors low frequencies will favor gradients, always. Thats what i meant by "different parts", a matrix that quantisizes low frequencies less then high frequencies will effectively give a lower quantisizer to gradients and a higher one to fine detail. this makes them more effective then AQ at fighting blocking, since they work on a per frequency coeficient basis rather then a per **8 block or 16X16 macroblock basis.

No, custom matrices *might* help to fight against blocking because it can be made into trading details for lack of blocks. But it's imho not the right way to fight it. Well I can only assume that thats a very definate might, since its easy to make a matrix that always block more, or less then a flat matrix.

[Manao]

Indeed, gradients are mostly low frequencies. But lets say you make a matrix where all low frequencies are 8, and all high frequencies are 32. That amounts, roughly, to encode the low frequencies at q-6, and the high at q+6, if we were to compare that with the default matrix. But, since gradients are low frequencies, encoding at q-6 with the default matrix *should* give the same result ( size and distorsion ) as encoding at q with the cqm. The advantage of adaptive quantization is that you don't trash the other part of the picture with a matrix specifically designed to encode well only gradients.

So no, you won't convince me that easily that matrices are better suited to fight blocking in gradients.

[*.mp4 guy]

Indeed, gradients are mostly low frequencies. But lets say you make a matrix where all low frequencies are 8, and all high frequencies are 32. That amounts, roughly, to encode the low frequencies at q-6, and the high at q+6, if we were to compare that with the default matrix. But, since gradients are low frequencies, encoding at q-6 with the default matrix *should* give the same result ( size and distorsion ) as encoding at q with the cqm. The advantage of adaptive quantization is that you don't trash the other part of the picture with a matrix specifically designed to encode well only gradients.

So no, you won't convince me that easily that matrices are better suited to fight blocking in gradients.
It works out to the same result either way, quantisizing the gradients less costs bits. To make up for the lost bits AQ will have to quantisize things that aren't gradients more, things that arent gradients are either perfectly flat blocks or blocks with quite a few mid to high frequencies. In the end they do the same thing, accept one works on the frequency level and one works on the partition level.

[edit] Furthermore there isn't any aq patch that I know of that succesfully fights blocking on gradients in X264, and Xvid aq isn't even for fighting blocks.

[further addendum] Imo the best way to fight the type of blocking that X264 has the most trouble with (dropped low frequencies/droped blocks) is to tweak the Internal dct and quantisization routines, and I agree that matrices designed specifically to fight this type of blocking are a bad idea. The matrix I posted in this thread isn't designed specifically to fight blocking caused by too aggressively droped frequencies, it does help with the problem to an extent, but thats not what its specifically for.

[DeathTheSheep]

there isn't any aq patch that I know of that succesfully fights blocking on gradients in X264
Try checking out the "Adaptive Quantization v.5 by Haali" feature (http://mirror05.x264.nl/Sharktooth/force.php?file=./x264/patches/x264_aq.5-519.diff). Set a high AQ strength and watch what happens to the gradient blocking ;)

[*.mp4 guy]

Try checking out the "Adaptive Quantization v.5 by Haali" feature (http://mirror05.x264.nl/Sharktooth/force.php?file=./x264/patches/x264_aq.5-519.diff). Set a high AQ strength and watch what happens to the gradient blocking ;)
Iisn't that the one that isn't included in any builds anymore because it didn't work very well?

[unmei]

at least sharktooth's build still has the --aq-strength and --aq-sensitivity switches. So i assume that patch is still in there as it would be very confusing to reuse switch names for something different :) No idea about the currently used version of that patch tho, it always worked quite nice for me (using strength 0.33 for anime). Well it's true that it lowers the PSNR, but i guess that is intrinsic to AQ in general.

[foxyshadis]

If the idea is just to get rid of blocks caused by overquantized low frequencies, why not use a flat 16 with the top-left corners bent down toward 8? Has anyone tried such a beast? (I have no clips that currently exhibit this problem, if anyone can supply one I'd be grateful.)

[Sharktooth]

i use the version bobor linked in his post... and yes, it works.

[*.mp4 guy]

Thanks for clarifying that Sharktooth, I suppose I was thinking of the one that was supposed to fix the "blues sky" problem and never really did.