Deblocking cpu use?

[futurex]

Hello, i read in another thread that using inloop deblocking in x264 will increase encoding time and decoding cpu usage.

i can understand encoding times, but why would it take more cpu to play it? isn't the deblocking "hard" coded into the video like a filter?

[Sharktooth]

not properly... lets say the encoder "tells" the decoder when and where to deblock.

[akupenguin]

The encoder tells the decoder to apply a complicated mathematical function to millions of pixels.
The encoder also tells the decoder what the dct coefficients are, and what motion vectors to use, and so on. Decoding a motion vector and interpolating the pixels is faster than running motion estimation, but it's not free.
Same with deblock.

[futurex]

thanks for the wonderful explanations!

but what if i encode with the inloop filter, but disable deblocking in ffdshow? will i get the original, un-smoothed picture?

[akupenguin]

No, you'll get an ugly mess. It will be not only blocky, but also have tons of other artifacts caused by the ever-increasing desync between what the encoder intended to display and what the decoder produced. (At sufficiently high bitrates you might not notice anything, but only because loopfilter was mostly disabled anyway.)
Unless you set it to skip loopfilter on non-referenced pics only, in which case yes you'll get the unsmoothed versions of those frames.

[Didée]

... and what about (from here (http://forum.doom9.org/showthread.php?p=832122#post832122))
Technically, nothing prevents you from decoding the picture, showing it, and only then deblocking it for future prediction. That way, you still get the coding efficiency but not the deblocked look that some don't like.

Sounds like an option that would be nice to have. :)