#78 Post-processing for H.264 (redux 2991713)


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.


  • Kigaruna

    Kigaruna - 2010-05-20

    "Even though MPEG-4 AVC has its own deblocker, its use by the encoder is optional"
    You probably mean its use by the DEcoder is optional? If so, then NO. Its not optional. All AVC decoders in any cases should produre exactly the same output. And this can be achieved only if AVC deblocking is on. Yes, it can be disabled manually, but thats when you need to trade some quality for speed. Other than that it always ON.
    In other words if some check will be implemented (which is useless) result will be the same as now - all h264 streams won't get additional deblocking.
    And set deblocking to be ON always is not an option since videos looks oversmoothed.

  • Kigaruna

    Kigaruna - 2010-05-20

    And if you actually mean ENcoder, then yes, you can specify not to use deblocking when you encoding video, but no sane people will do that.

  • Pa3PyX

    Pa3PyX - 2010-05-21

    "And if you actually mean ENcoder, then yes, you can specify not to use
    deblocking when you encoding video, but no sane people will do that."

    I disagree; if something can happen, it will. There is a number of popular software which uses x264 as a backend, but doesn't care to use it properly. Take Xilisoft Video Converter -- it disables deblocking by default; and let alone deblocking -- it doesn't even use b-frames on highest-profile settings.

  • Kigaruna

    Kigaruna - 2010-05-21

    Well, even if so, IMO this is not something ffdshow should care about. You better talk to Xilisoft so they can fix their crappy converter.
    But maybe adding option "allow deblock for h264" can be implemented without much trouble.
    Also note, that, that this option we talking here is not the only way to get deblocking in ffdshow. Using raw filter, everything will be deblocked.
    And by the way, deblockers available through avisynth filter can give better results.

  • vosya

    vosya - 2010-05-22

    Addition of an option "allow post-processing for h264" will solve all problems. It will allow everyone to choose: whether postprocessing is necessary PERSONALLY to him. Why others should choose it instead of him?

  • Pa3PyX

    Pa3PyX - 2010-05-22

    Sure -- if the user chooses to, they can manually construct their DirectShow graph by including any additional transforms they need; that's what I've been doing when converting videos. But very few DirectShow *players* allow the user to manually adjust the graph; this solution is more tailored towards video encoding/conversion scenarios, and the same goes with AviSynth. Secondly, for a casual user it is highly undesirable to have to switch settings back and forth for every particular video -- they would prefer a "works across the board" solution, which is why I was suggesting to check the streams whether they actually *use* in-loop deblocking, rather than just assuming that if the codec is capable of this feature, then it gets used. But yes, at least giving the user control to force deblocking for such codecs would be a whole lot better than nothing. The option should probably be called more generically "Skip deblocking for codecs with in-loop filters" though (checked by default), because other codecs beside H.264 also have in-loop deblocking capabilities (VC-1/WMV9 comes to mind).

  • clsid

    clsid - 2011-07-14
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks