Sorry for reposting, but haven't found a way to re-open or comment on 2991713.
A better solution (than hardcoding the codec type check in the post-processing filter) would be to allow the user to manually select which codecs to use postprocessing for and which not to, and initialize that with reasonable defaults (turning it off for H.264 since the decoder in most cases already does deblocking of its own).
Yet another option is to decide dynamically whether to use post-processing based on the particular H.264 stream. Even though MPEG-4 AVC has its own deblocker, its use by the encoder is optional; even in ffvfw x264, the user can select whether the stream should use deblocking, and how much. The decoder must then use this exact setting when decoding frames, because motion compensation is computed with deblocking in mind, and if the decoder is not respecting the stream setting, it will output a mess. Consequently, post-processing is still often a useful feature even for H.264 -- I've personally seen a number of blocky H.264 videos on YouTube. Instead of just testing for the codec, the filter should probably test whether the stream in question actually makes use of deblocking, and allow full post-processing if not; otherwise, it should disable deblocking and allow only deringing and luma range fix.