How strong deblocking filter do you prefer?

[IgorC]

It might be usefull to know what deblocking is more or less preferible for people.

Mostly metrics as SSIM like high deblock as -1 or 0 for tipical case as dvd source and bitrtaes 600-1500 kbit/s
But most of people say that they prefer less deblocking like -2

I uploaded 2 samples http://www.mytempdir.com/1090663

One has higher deblocking and it has higher metric. Another has one step weaker deblocking and for me it's more pleasant.

It will be also helpfull if someone will describe conditions of watching like distance, envoirment, CRT/LCD etc.

It's not a thread like 'what is the better'. Each one just say what prefer and it permits to recolect some statistic information.

[check]

For anime, I tend to use a deblock of 0,0. Generally I play with reducing threshold more than strength (so 0,-2 more than -2,0), but I tend to run a gamut of tests to compare for every major encode I do. For me, I tend to prefer the appearance of 'nominal' deblocking to mosquito noise and related stuff. I watch with a CRT usually around a meter away.

[DarkZell666]

I personally didn't find the need to use anything else than 0,0.

It probably depends on what folks do with their material. For near-transparent (read: high-bitrate) encodes, it'll be better to use a negative deblocking, and for very low bitrate encodes it'll be better to use a positive deblocking (high quality/bitrate distortion).

*Edit: I like how you describe -1 or 0 has "high deblock" xD. Sorry for being a little sarcastic but ... can't you count up to 6 ? ;)

[foxyshadis]

0 is a strong deblock, because x264 is weighted that way. The commonly useful range is about -3 to 1; I've never needed to use anything outside that except for testing, and I use a very wide range of bitrates (or crfs or however you want to describe it). If it was centered for sharper high quality instead of low, the current -1 or -2 would be 0. 0 now is perfect for around the "one-cd" quality range though.

[DarkZell666]

If you're right, and if other AVC implementations are tuned differently, does this mean the deblocking values are written to the bitstream as something different from the -6 to +6 integer values ? How do the decoders treat the deblocking scale ?

Imagine x264 encodes a file at 0,0 and that Nero (supposing it's tuned differently) encodes the same file with 0,0. If the (0,0) value couple is stored in the bitstream "as-is", the decoder will obviously be wrong for one (or both) of the encodes, and one of them will look a bit more blurred. There must be a common deblocking scale defined somewhere ... unless different values are computed by the encoder for the decoder to "know" how the encoder deblocked. This leaves me wondering quite a bit :p

[Seb.26]

If you're right, and if other AVC implementations are tuned differently, does this mean the deblocking values are written to the bitstream as something different from the -6 to +6 integer values ? How do the decoders treat the deblocking scale ? :p
IMO:
I don't think the deblocking setup is stored like that ( a level in result file ) ... but your value will setup the amount of deblocking in the result data ...

Else, where is the interrest ?! ... FFDShow can do the same by post processing ... ;)

( maybe this is unreadable ... sorry for that ... :p )

[Edit]
IMO :
If the deblocking is a deblock setup value stored in video file ( -1 for exemple )
-> in this case, some decoder may apply different deblocking power due to their interpretation of this value.
-> in this case, FFDShow can do (about) the same by post processing, so why add that ?!

but IMO the value in x264 is used to compute how much "block" will "request" for deblock in the result video stream ...

[DarkZell666]

Deblocking in AVC isn't as simple as in ASP, there's a decoding part to it :)

As you (didn't :D) see in CoreAVC, there's an option to disable deblocking. It's natively part of the AVC standard ;)

[Seb.26]

Deblocking in AVC isn't as simple as in ASP, there's a decoding part to it :)
As you (didn't :D) see in CoreAVC, there's an option to disable deblocking. It's natively part of the AVC standard ;)
... Sorry, I haven't understand what you want to say ... :confused:
( Or you don't understand what I want to say ... lol ... I will edit my previous post )

NB: I haven't seen the deblocking setup in CoreAvc 1.2 cause I can't use it ... :( ... but I saw it in 1.1 ... :D

[foxyshadis]

If you're right, and if other AVC implementations are tuned differently, does this mean the deblocking values are written to the bitstream as something different from the -6 to +6 integer values ? How do the decoders treat the deblocking scale ?

Imagine x264 encodes a file at 0,0 and that Nero (supposing it's tuned differently) encodes the same file with 0,0. If the (0,0) value couple is stored in the bitstream "as-is", the decoder will obviously be wrong for one (or both) of the encodes, and one of them will look a bit more blurred. There must be a common deblocking scale defined somewhere ... unless different values are computed by the encoder for the decoder to "know" how the encoder deblocked. This leaves me wondering quite a bit :p

In the bitstream, Alpha deblock ranges from 0-255, Beta deblock ranges from 0-18. (Or maybe they both have a range of 156 possible values, I'm not exactly sure how to read this code.) I have no idea exactly what those numbers mean or how they translate to actual deblocking strength, although I do know Nero and x264 scale their deblock settings differently.

Seb26, deblocking is done by the decoder in AVC because motion compensation works better, the encoded stream doesn't get out of sync with what the encoder sees. However, if AVC deblock is disabled, then extra post-processing can pick up some of the slack.

[Seb.26]

In the bitstream, Alpha deblock ranges from 0-255, Beta deblock ranges from 0-18. (Or maybe they both have a range of 156 possible values, I'm not exactly sure how to read this code.) I have no idea exactly what those numbers mean or how they translate to actual deblocking strength, although I do know Nero and x264 scale their deblock settings differently.
So if the a_Deblock and b_Deblock values produced by both encoder are the same ( obtain this can need differents deblock setup in the encoder ), them the deblocking will the same ... of course ...

[Edit] Yes, it's logic ... FFDShow doesn't have the motion vectors ( and a lot of other usefull data ) so it can only work with the frame as a bitmap ... CoreAvc can use the frame as a bitmap but with all data from the encoder ...

Seb26, deblocking is done by the decoder in AVC because motion compensation works better, the encoded stream doesn't get out of sync with what the encoder sees. However, if AVC deblock is disabled, then extra post-processing can pick up some of the slack.
( hum ... how to write what I think ... ?! )
The deblocking is done by the decoder, ok, but does it "only" use the frame with associated data ( motion data & Co ) like a simple posts processing filter but with access to more data, or does the encoder pre-define "where and how" the deblocking will occur ?!

Thanks :)

[DarkZell666]

Just as I thought then ^^

So x264's [0;0] deblock could in fact be [160;6] and nero's [0;0] could be [128;5].

Thx for clarifying foxyshadis ;)

[Manao]

Actually, both Nero & x264 defines deblocking strength 0 in the same way ( i.e, the value in the bitstream will be the same ). However, the two encoders have a different decision, which leads to x264 having a different size/psnr than nero at the same quantizer. That can be translated as nero Q 24 ~ x264 Q 25.5 ( or the reverse, I don't remember ). But since the deblocking strength is function of the quantizer, it means that, at the same size/psnr, x264 will deblock more ( in my example ) than nero, since Q25.5 is more deblocked than Q24.

[shon3i]

@IgorC, what encoder you used in examples, and what deblocking settings you use.

I found that x264 0,0 sometimes have sharper picture than elecard -1,-1

[IgorC]

@IgorC, what encoder you used in examples, and what deblocking settings you use.


last Elecard with light settings. aa.mp4 deblock -2 , bb.mp4 deblock -1

[DarkZell666]

From the poll results, I believe I'm the only one to prefer smooth-looking pictures ... :rolleyes:

How come so many didn't spot a difference though ? There definitely was *something* different ... =)

[GmorG McRoth]

Third option is not for "I don't see difference", it's for "I don't know which one looks better", I think.

I picked 3rd option, test was with FFDShow and LCD monitor.

[Prettz]

The last 2 movies I ripped with x264 were very high quality (and sensitive) for the resolution, and I used -4,-4 for both.

[xyloy]

I see almost no difference(ffdshow no PP, CRT monitor)

0:0 looks fine to me(I hate blocking). I Have tested -2:0 -2:-2 -4:-4 and some other combinations a lot of people seem to apply on each film.. But I must be blind( :P ) as it looked not so much different... there was only a little more smeging blocking and ringing. :devil:

[shon3i]

I see almost no difference(ffdshow no PP, CRT monitor)

0:0 looks fine to me(I hate blocking). Me too, aslo in x264, 0,0 to me looks nice, but i have dilema with elecard, because his -1,-1 looks smoother than x264 0,0

[Morte66]

I prefer the sharper one, despite it having less deblocking. But ideally I like a sharp deblocking setting (I start at -2-2 for x264) with mp4guy's anti-blocking custom quantization matrix. That gives the best of both, i.e. sharp and block-free on a suitable source, at the cost of maybe 30% increased bitrate (still beats Xvid).

[Manao]

That gives the best of both, i.e. sharp and block-free on a suitable source, at the cost of maybe 30% increased bitrate30 % is roughly equivalent to lowering the quantizer by two, so it would amount to lower the CRF by 2 and use 0:0, which would amount to the same deblocking strenght as not lowering the CRF and use -2:-2.

You can't say it's better when the bitrate increases by 30%.

[Morte66]

30 % is roughly equivalent to lowering the quantizer by two, so it would amount to lower the CRF by 2 and use 0:0, which would amount to the same deblocking strenght as not lowering the CRF and use -2:-2.

I don't know the theory, but in my practical experience...

- x264 suffers shadow blocking with the default matrix, however much bitrate you use. Just turning the bitrate up 30% does not solve it, because x264 spends the extra bitrate outside the blocky areas. But if I also use a CQM that devotes a larger fraction of the bitrate to smooth dark areas, that does solve the problem.

- x264 looks soft (to my taste) at deblocking -0-0 at any bitrate. If I want it to look sharp, I lower the deblocking. Increasing the bitrate doesn't make it look sharper on my usual crf22 encodes.

- Since I usually do fairly high quality encodes (crf22 or so), the things that are improved by going to a higher crf/bitrate (i.e. not sharpness/blocking) usually weren't bothering me anyhow. If I normally did crf26, which often suffers pretty bad "grease on the lens", simple bitrate increases would be more use to me.

So IMHO using default settings with a higher bitrate might be "equally good overall" in some neutral mathematical sense, but it doesn't actually look the same.

As for "better", I'm not claiming that. I'm just saying "I prefer". I'd rather spend the extra 30% on bitrate and hard drives to get the look I want.

[akupenguin]

@Manao: Actually, each unit of deblocking stength is 2 units of QP. (don't ask me why, that's just what the standard says)

@Morte66: Can you provide an example of a clip encoded with (crf22 deblock -2:-2) and with (crf20 deblock -1:-1) where you prefer the former?

[Morte66]

@Morte66: Can you provide an example of a clip encoded with (crf22 deblock -2:-2) and with (crf20 deblock -1:-1) where you prefer the former?

http://rapidshare.com/files/7435292/4D.zip.html

In the matter of sharpness, I prefer 4D.crf22.deblock-2-2.nocqm.mp4 (4958kb) to 4D.crf20.deblock-1-1.nocqm.mp4 (7386kb). If you view it fullscreen and look at the FBI guy's forehead he's a bit "craggier" at -2-2, the -1-1 version looks like there's some thin makeup added. The crf20 encode certainly has other stuff going for it, but it doesn't grab me the same. I could understand if somebody else preferred it.

The way I prefer it is 4D.crf22.deblock-2-2.M4GV3.mp4 (7120kb) which has mp4guy's anti-blocking CQM and --direct-none. To me, that's got the best of both worlds. In my experience it's also "safer", the crf22 cqm encode is always good whereas straight crf20 can be fine or it can have blocking problems.

Hmm... I just noticed that I'm talking about the deblocking setting in terms of sharpness and the CQM in terms of blocking. I guess I do look at the x264 deblocking settings primarily as a sharpness control, they seem to have a relatively mild impact (compared to matrices) on the sort of blocking that bothers me.

[squid808]

Just an observation; when played in VLC 0.8.6 the 4D.crf20.deblock-1-1.nocqm.mp4 looks quite a bit darker than the two other encodes. What is the reason for that?

[Morte66]

Just an observation; when played in VLC 0.8.6 the 4D.crf20.deblock-1-1.nocqm.mp4 looks quite a bit darker than the two other encodes. What is the reason for that?

I don't know, but I've just played them both in VLC, separately or side by side (in both orders), and they do seem different. But "who's darkest" switches around. I'm confused. In ZoomPlayer they look the same.

[DigitalDivide]

After reading all this I'm still not sure what to do. Normally I encode all my movies using HQ Slower profile and set the deblocking to 0,0. I usually set a target bitrate of 2,500. No resizing. All my movies are film. I'm just wondering if I should be going to -1,-1 for deblocking? But then I'm also wondering if at 0,0 at a high bitrate maybe it's fine. The problem is my tv isn't the greatest right now and when I do buy my 50inch LCD some time this year I down't want to have to reencode my movies because I'm not happy with the quality.

[DarkZell666]

I think that with 2500kbps at DVD resolution you'll be fine enough quality-wise ;) The only thing is that your 50inch LCD (HD screen ?) might decieve you on SD content (but it won't decieve you more than with normal DVD anyway, and AVC is "cleaner" anyway ;)).

A friend of mine has a HDTV, and watching a DVD on it was like watching a crappy 2mbps MPEG2 broadcast, or even worse: colors were so dithered all over the place it was like watching 256-color GIF animation (no joke, sadly :/). So ... be reassured that in any case your actual backup's won't look worse than traditional DVD's ;)

If you want to be sure they'll look good even on a cheap HDTV (everything is relative but ... :p), you'll be better off encoding your DVD's in 1280x720 at around 5mbps. I hope someone will be able to confirm that my friend's HDTV is just god damn cheap quality though, 'coz in your situation I wouldn't like reencoding all this stuff just for a new TV ... ^^'

Edit: just to sum all this up: the problem isn't your encodings but the eventual cheap quality of your new TV.

[foxyshadis]

I don't know, but I've just played them both in VLC, separately or side by side (in both orders), and they do seem different. But "who's darkest" switches around. I'm confused. In ZoomPlayer they look the same.

That's what happens when there's contention for the overlay renderer. One will get it, the other is forced to use VMR7/9 rendered, which often plays in a "PC mode" 0-255->0-255 conversion. (Overlay is always "TV mode" 16-235->0-255, as is most video.)

A friend of mine has a HDTV, and watching a DVD on it was like watching a crappy 2mbps MPEG2 broadcast, or even worse: colors were so dithered all over the place it was like watching 256-color GIF animation (no joke, sadly :/).
Sounds like a plasma tv, that's the most common complaint by far. ("Too bright" occasionally pops up too.) LCDs don't have that problem at all, though they can have response time and low brightness issues; overall, the best are easily better than plasma and even crt now, however, and even the cheap junk is damn good compared to two years ago. (But their deinterlacing and upscaling often sucks more, you get what you pay for there. Use ffdshow-lanczos to watch dvds with a laptop hooked to one if you can, the difference is enormous.)

[check]

overlay is 16-235? err, what? If that was the case, pure black output would appear as 16,16,16 next to an RGB image... but it doesn't. VMR9 is known to do that on some systems, but never overlay

[foxyshadis]

I meant 0-255->0-255 and 16-235->0-255, but yeah, the last thing I need to do is cause even more confusion around colorspaces, so I'll edit specifics in.