Deblocking question

[Comatose]

http://ffmpeg.x264.googlepages.com/mapping mentions, under the --deblock description, that it has a small hit on decoding performance, but neither --deblock nor --no-deblock mention anything about an encoding speed hit or gain, which led me to believe that it only happens when decoding.

However, somebody told me it happens both when encoding and decoding, but I haven't been able to find (with search) posts which really clarify this - only answers which go in detail but don't really give a clear answer.

So, could somebody please tell me whether it happens in both or only in one, and *then* continue to explain exactly where in the encoding/decoding process it happens?

Thanks

[Dark Shikari]

The same speed hit is on both encoding and decoding--its just that as a percentage of total time, the cost in encoding is negligible except at fastest settings.

[Sagekilla]

It's also something that isn't worth disabling for speed unless it's absolutely necessary, since disabling deblock filter during encode will result in lower quality video. Also, if you try to disable it during playback time, unless you absolutely have to (i.e. the video is unwatchable without it off) you'll get bad artifacts since deblocking is an integral part of decoding.

[Comatose]

I wasn't really wondering about the speed, but more about whether it's actually being done :p

What would be Deblock() settings equal to 0:0? If aOffset is the first number and bOffset is the second number (I'm assuming), then how does quant affect the deblocking in relation to --deblock's values?

[Sagekilla]

If Deblock is based off the same deblocking filter as in the H.264 standard, then I would have reason to believe the default settings correlate to 0:0, don't quote me on it though.

[Ranguvar]

Deblock() and the H.264 inloop deblocker are completely different.

If a frame is requested that references another frame, the H.264 deblocker deblocks the reference frame before it is used to create the current frame, which gives it an advantage over a simple post-processing deblocker, which works on the current frame only.

As for how Deblock() compares to the H.264 deblocker's deblocking of I-frames, I have no idea.

[Sagekilla]

Deblock() and the H.264 inloop deblocker are completely different.

If a frame is requested that references another frame, the H.264 deblocker deblocks the reference frame before it is used to create the current frame, which gives it an advantage over a simple post-processing deblocker, which works on the current frame only.

As for how Deblock() compares to the H.264 deblocker's deblocking of I-frames, I have no idea.

This says otherwise: http://avisynth.org.ru/mvtools/deblock.html

It's the same deblocker as in H.264, except you don't use it inside of the encoding and decoding process, only as post (or pre) processing.

[imcold]

Macroblock types & qp influence the h.264 inloop deblocker parameters, so result will be different if the deblocker would be run without any macroblock information (as avisynth filter etc.) anyways.

[Sharktooth]

if you dont use it inside the encoding process than it isnt the h.264 inloop deblocker.
it cant be compared.

[Comatose]

Well, then I'm guessing that the quant parameter is there to make up for the lack of that info...

[Sharktooth]

deblock() is the same function used in h.264 for deblocking... but it is implemented in a different and mucg simplier way.
the quantizer parameter is there to apply the 0:0 deblocking value relative to the specified quant (deblocking in h.264 is adaptive)... the higher the value the stronger the deblocking.
however it will be applied blindly (as if all frames have the same quant), without taking into consideration macroblock info, frames and macroblocks QPs, etc... coz it cant know them.
it will be WAY less efficient and the result, completely different than h.264 deblocking.
hope is it clear now.

[CruNcher]

It's also something that isn't worth disabling for speed unless it's absolutely necessary, since disabling deblock filter during encode will result in lower quality video. Also, if you try to disable it during playback time, unless you absolutely have to (i.e. the video is unwatchable without it off) you'll get bad artifacts since deblocking is an integral part of decoding.

Tough in reallity this is wrong and differs from Encoder to Encoder i think it's really important to balance it out on your current psy status, tough for X264 i see a catastrophic unbalance here between Psy enhancements and deblocking. (that shouldn't suprise as there have been so many enhancements in such a short time and nobody ever looked in how it effects the inloop deblocking)
So it hurts most of the time then it helps Psy wise @ certain bitrates, but sure if you want to have every frame of high motion block free to the last pixel you should leave it @ default and dont care about this anyways.

[Sharktooth]

damn... i need a decrypter...