blocky results in out of focus "background" areas

[graysky]

I've been doing some DVD encodes using MeGUI and the "HQ-Slower" profile from Sharky. Most of the resulting x264 video streams contain what I can only describe as blockiness areas which mostly occur in the background, out-of-focus areas of some scenes.

Here is a section of a screenshot of my x264 encoded file (you have to get close to your monitor to see it but I assure you that it is VERY visible when viewed on a TV):
http://img442.imageshack.us/img442/5026/pixels2zu9.jpg

Here is a section of a screenshot of the original VOB:
http://img238.imageshack.us/img238/9762/originallb6.jpg:

As you can see the blocky areas are present in original, but are much less noticeable then in the x264 file.

I have tried altering the inloop settings from the standard 0,0 to sharky's -2,-1 and have even tried disabling the inloop filter all together. The results are the same.

I have also tried messing with the "no skip p-frame" option since the balloon help for MeGUI suggests that, "Fast Skip detection increases speed but may cause slight blockiness in areas of solid colour or slight gradients such as dark scenes or sky." So if I enable "No Skip P-Frame" that should disable the option and thus disable the blockiness but when I compare the results with this box either checked or unchecked they appear the same.

Any thoughts or suggestions?

Thanks all!

[Dark Shikari]

Tried adaptive quantization?

[Manao]

Add noise on playback.

[check]

you need more bits, or more specifically, more bits allocated to that area. Or you can hide it rather well as per manao's suggestion, which is easier overall.
As for allocating more bits, you can:
o increase the total bitrate
o use adaptive quantization, which is a custom option that sharktooth and a few others compile into their builds. Try --aq-strength 0.3 and see if it works.

[graysky]

@Dark Shikari: looked around for "adaptive quantization" but found no such option.

@Manao: all I see is denoise filters.

[graysky]

@check: I'm encoding 704x480 with about 2000 kbps and I don't wanna bump it up any higher to keep the file sizes manageable.

I added that --aq-strength 0.3 line to the custom commandline options section in the codec setup so it appears at the end of the commandline string which shouldn't matter should it? Then I re-ran a test encode. The result isn't any better:
http://img45.imageshack.us/img45/447/aqstrength03nb3.jpg

Here is the complete commandline from the log files:
--pass 1 --bitrate 1978 --stats "D:\test.stats" --bframes 3 --b-pyramid --direct auto --nf --subme 1 --analyse none --vbv-maxrate 25000 --me dia --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output NUL "D:\test.avs" --aq-strength 0.3
--pass 2 --bitrate 1978 --stats "D:\test.stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --nf --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads auto --thread-input --sar 40:33 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\test.mkv" "D:\test.avs" --aq-strength 0.3

[delacroixp]

You don't mention which container you use or whether you have an HTPC for playback.

Perhaps it worth your while to do an anamorphic encode...
MKV will allow you to encode your movie at full orginal resolution, without resizing... and playback at the correct DAR, even if you included some wayward cropping...

While you are about it... use the 18-CQ-CRF profile... for speedy results so quick... you'll start your encode today and it'll finish yesterday...


:):D:eek:
Pascal

[SealTooGreat]

Try M4G MRM V2 (http://forum.doom9.org/showthread.php?p=887125#post887125).And make sure to check "mpeg2 deblocking" in "AviSynth Script Creator". You should get less blocks!

[Episodio1]

Judging from the source you posted I think the result you got is good.
Anyway, when the source is not perfectly sharp (or not high bitrate) it would be better if you encode with a smaller resolution so you will avoid such artifacts.

[graysky]

@delacroixp - yeah, I always overcrop and encode via anamorphic signalling and I usually use mkv since I like to keep the oroginal ac3 or transcode to vorbis. Thanks for the suggestion.

@sealtoogreat - I'll tried using the deblocking option in avisynth, but it didn't do a whole lot of good:

DGDecode_mpeg2source("D:\test.d2v",cpu=4,info=3)
ColorMatrix(hints=true)

I'll try using that custom matrix and report back. Thanks for the suggestion. Here is the result for that script:

http://img337.imageshack.us/img337/2045/deblockingyn1.jpg

[foxyshadis]

BlockBuster is designed to add enough noise back in to cover up those issues, but probably better to avoid deblocking in that case.

ffdshow has both noise and debanding functions, and those are probably the only way to totally cover up mild blocking/banding as in the first post, short of doubling the bitrate and reducing deadzone quite a bit.

[*.mp4 guy]

Mpeg2 deblocking always makes problems like this worse, you should never use it if you are having trouble with blocking. Gradfun2db, on the other hand, can sometimes help.

[check]

yes, if you use ffdshow's deband filer on playback, it should mostly remove the last vestiges of a problem. It's a very useful filter.

[Didée]

In a sense, this blocking effect is kind of "unavoidable", in particular when the source is grainy and the encoder can't reproduce the grain because of too low bitrate. And the necessary bitrate for grain reproduction is quite high. Read here (http://forum.doom9.org/showthread.php?p=952813#post952813) for a short explanation (or a try of, at least;)).

Shortly: with those rather low bitrates that we got used to by the modern compression schemes, grain just can't be dealt with properly. That's why in h.264 the scheme of adding parametric grain was included: Coding grain "directly" is too expensive.

[graysky]

Thanks for all the great feedback, everyone. I gave the M4G MRM V2 (http://forum.doom9.org/showthread.php?p=887125#post887125) matrix a try using -1:-2 for the inloop and "--deadzone-inter 6 --deadzone-intra 6" added to the custom commandline like the thread suggested. The result is really no better than wo/ to me:

http://img176.imageshack.us/img176/9631/custom12if8.jpg

[Manao]

You still haven't given a shot to adding noise...

[graysky]

I may have missed it, but what method do you recommend to do so?

[Manao]

gradfun has already been advised ( you can use it with a recent ffdshow build ). FFDshow also have several (faster) noise generators, because gradfun is a bit CPU intensive during playback.

You can also add noise with mplayer.

[graysky]

Oh, sorry, I meant how can I do it hardcoded? The target output will be on by a HTPC (mplayer).

Thanks!

[graysky]

I tried the noise filter in FFDshow, and although it did improve the area of interest, it ruined the overall quality of the video :)

http://img402.imageshack.us/img402/615/noisekq9.jpg

[Terranigma]

try using foxyshadis's addgrainc() filter, or .mp4 guy's filmgrain script. Add only subtle grain.

[Atak_Snajpera]

I have the same problem when I try to encode long movie (casino royale for example) to fit on 1CD. The best solution in this case is to add noise in ffdshow.

DVD
http://img183.imageshack.us/img183/7372/dvdwi7.th.png (http://img183.imageshack.us/my.php?image=dvdwi7.png)

x264 - HQ-Slower but default deblocking (0,0) - 640kbps (700MB)
http://img361.imageshack.us/img361/6503/x264ed9.th.png (http://img361.imageshack.us/my.php?image=x264ed9.png)

with added noise in FFdshow
http://img353.imageshack.us/img353/9555/noisemt2.th.png (http://img353.imageshack.us/my.php?image=noisemt2.png)

http://img153.imageshack.us/img153/8968/x264plusnoisevz2.th.png (http://img153.imageshack.us/my.php?image=x264plusnoisevz2.png)

[woah!]

are you encoding at a 1280x544 res? with 640kbps bitrate?

[R3Z]

gradfun has already been advised ( you can use it with a recent ffdshow build ). FFDshow also have several (faster) noise generators, because gradfun is a bit CPU intensive during playback.

You can also add noise with mplayer.

I think the point is that we shouldnt have to resort to stop gaps to make a picture look fine. What happens when we stop using PC's to play h264 ?

If h.264 really does include a decoder side grain addition feature then hopefully someone will actually include it in their encoder/decoder.

[giandrea]

I think the point is that we shouldnt have to resort to stop gaps to make a picture look fine. What happens when we stop using PC's to play h264 ?

If h.264 really does include a decoder side grain addition feature then hopefully someone will actually include it in their encoder/decoder.

Is this added grain feature of AVC already supported in hardware players like Blue Ray and HD-DVD players (and PS3)?

[Chainmax]

I concur with R3Z, these are short term solutions for an issue that should be solved at the encoder level. While we wait for x264 to get to that level, the solutions provided here are good enough though. What I suggest is to either put AddGrain(x,0,0) (with 2<=x<=5) at the end of the script or to use this noise configuration that Sharktooth proposed a while ago and is very nice:

http://img232.imageshack.us/img232/8025/suggestednoisesettingsvk1.png (http://imageshack.us)

If ffdshow does indeed include gradfun2db now (I have beta2a_20070322_clsid which doesn't seem to include it), add it as well. Another option, which seems to be the preferred one around here if you want to keep detail, is to just use Xvid instead.

[delacroixp]

are you encoding at a 1280x544 res? with 640kbps bitrate?
I was thinking the same thing... I prefer to drop the resolution all the way downto 640x??? and increase the quantizer-CQ-CRF up a few levels... if I'm pushed for space and I'm playing-back on a standard 19inch 1280x1024 PC-LCD.

However, higher res movies probably encode more efficiently (per pixel) because of all the lazy (similar) pixels. At low res you've distilled out and left only with the essential stuff to maintain the image...

It just shows you what can be done with small files and hi-res IF you know your stuff...


:):D:eek:
Pascal

[Atak_Snajpera]

Casino Royale was encoded in 640x272@640kbps! I upscaled screenshot to 1280 only because I wanted to show you exactly how it looks like on regular LCD with native resolution 1280x1024 (or 800)
It was only an example. I'm not stupid to upscale DVD source to HD resolution and then squeeze on 700MB :)

[foxyshadis]

Chainmax, "DeBand" filter is the same codebase as gradfun.

It's better to have two noise profiles, one for movies and one for clean animation, but then again, they also need two avisynth profiles anyway, so it works out okay. Movies usually work out okay with very low grain strengths, like 2 or 3; it doesn't mess up the output nearly as much that way.

[delacroixp]

It looks like anamorphic encodes are the most economical... take an anamorphic 720x576 PAL / (16:9) movie, for example...

You're encoding IN 414,720 pixels (720x576) and getting OUT 589,824 pixels (1024x576 DAR) on playback... that's a 33% increase in viewing area...
If you resize first... for the equivalent resolution you get 859x483 and even 720x400 is a 1:1 correspondence AR=>DAR with no profit gained...

For a 4:3 anamorphic movie the increase is only 7% and for superWide movies the increase in viewing area is even greater than 33%.

Now... is it possible to resize a natural 16:9 HD movie from 1280x720 downto 1024x576... and then encode it as an anamorphic 720x576 movie ???


:):D:eek:
Pascal