Video Decoders & Renderers ...color conversions, luminance levels & banding

• Στην πρώτη περίπτωση έβαλα και τους 3 decoders έτσι ώστε να στέλνουν στον
  renderer ΥV12 χωρίς καμία άλλη παρέμβαση στο video και όλη την επεξεργασία να την κάνει ο MAdVR και πήρα screenshots πρώτα ρυθμίζοντας τον MAdVr να βγάζει την εικόνα σε PC Levels και μετά σε ΤV Levels.
• Στην δεύτερη περίπτωση ρύθμισα και τους 3 decoders να στέλνουν έτοιμο το βίντεο στον ΕVR, με όλες τις επιλογές ενεργοποιημένες να στέλνουν RGB, με ενεργοποιημένο το dithering, HQ Conversions και άλλαξα τα Luminance Levels μέσα από τις ρυθμίσεις των decoders.
  

• LAV Video:
  
  
• FFdshow:
  
  
• CoreAVC:
  

• Περίπτωση 1:
  Oλόιδια συμπεριφορά από όλους τους Decoders όταν είναι ρυθμισμένει να στέλνουν YV12 κάτι θεωρητικά αναμενόμενο.
  Λίγο περισσότερο banding στα PC levels του MAdVr άπο τα TV LEVELS. Προφανώς λόγο μεγαλύτερης έκτασης (range).
• Περίπτωση 2:
  Στην δεύτερη περίπτωση το τελικό αποτέλεσμα χειρότερο από την πρώτη περίπτωση.Ο FFdshow φαίνεται να υπερτερεί λίγο έναντι του LAV Video , ο CoreAVC είναι αισθητά χειρότερος. Δευτερο μέγαλο πρόβλημα τουλάχιστον στην έκδοση που χρησιμοποίησα εγώ, φαίνεται δεν λειτουργεί η επιλογή για το Output Range του CoreAVC. Και στις δυο περιπτώσεις φαίνεται να στέλνει PC LEVELS.
  
  

madshi said:

Some comments:

(1) Personally, for me, when no scaling is involved, the image quality difference between madVR and an optimized and perfectly working EVR/VMR is rather small, sometimes even invisible, in most screenshots. Other people say they see a big difference, so maybe it's a subjective thing. However, getting EVR/VMR to work perfectly is sometimes hard to achieve. You need to carefully turn off all the video manipulation algorithms, color settings etc. And even if you do that, they sometimes are still turned on for some reason. Once you have it all working, it may break with the next driver release. madVR behaves like a game, so many of those ugly video manipulation algorithms are automatically turned off when using madVR. Also madVR doesn't use any of the GPU algorithms for color conversion and chroma upscaling. That all means that there's less that can go wrong when using madVR.

(2) The madVR scaling algorithms should be superior to what is normally used with EVR/VMR, so if scaling is involved, the image quality difference should be bigger. The bigger the scaling factor, the bigger the difference should be.

(3) There are certain scenes where the image quality difference is bigger. E.g. red stuff on black background, especially with ATI cards. You can work around the issue with ATI cards by using MPC-HC with the chroma smoothing shader. But that only works with media players that have custom pixel shaders support (mostly only MPC-HC, I think). If you use a different media player, at least with ATI cards you may eventually have to live with bad chroma upscaling, when not using madVR.

(4) There's one big advantage of madVR, and that is its internal high-bitdepth processing pipeline with a final dithering step. This all means that madVR produces more accurate results and avoids adding banding artifacts. EVR/VMR tend to work in rounded 8bit. The problem is that DVDs are natively YCbCr 4:2:0 content and after conversion to RGB you have floating point values. So if you round the RGB floating point data down to 8bit, you do introduce some minor banding artifacts. This is once more visible only in specific scenes (e.g. very foggy scenes, generally scenes with a lot of smooth gradiants). This type of banding is more visible in motion than it is in screenshots, because the eye more easily detects if the banding "patterns" change from one frame to the next, so this may be hard to capture with a screenshot. This may also explain why many people claim that madVR produces a more "film-like" image, without being able to show it in screenshots. If you want to see this effect with your own eyes, give madVR a try, and then try the madVR test patterns (see madTestPatternSource directory). Try "colors.ytp". That one should show an easily visible difference between madVR and standard EVR/VMR implementations. The difference is caused solely by the high-bitdepth processing + dithering, used by madVR.

(5) madVR has a couple of benefits over EVR/VMR that don't have to do with frame-by-frame image quality. One advantage is that madVR has a monitor management built in, so you can use different settings (e.g. black level settings) per monitor. Also you can let madVR automatically switch refresh rates, again per monitor. More features like that are planned for future versions.

(6) One important aspect of madVR is the "presentation", which means the exact timing of showing the frames on screen. This is purely a timing thing, the video frames themselves are not modified, so this cannot be captured by screenshots. On my HTPC, I'm not able to get smooth motion when playing back 25fps content on 50Hz, with any other renderer than madVR. Only madVR displays this smoothly without stuttering. With a more capable GPU, maybe EVR/VMR can get nearer to madVR's smoothness, but overall I've invested a lot time and effort to make sure that there are not *ever* any frame drops/repeats. Of course this only works if the video refresh rate is spot on (or if you're using Reclock). With EVR/VMR this can be hit-and-miss. It might be possible to achieve perfect motion smoothness with VMR/EVR, too, but it's more difficult and less reliable, compared to madVR, at least according to my personal experience, and also confirmed by many madVR users.

(7) Seeking works best for me with madVR compared to any other renderer. With VMR/EVR, sometimes if I seek, the video stutters for many seconds afterwards, and sometimes audio/video get out of sync and I have to re-seek to fix that. This depends on the video clip and container format, though. madVR has a different seeking logic compared to EVR/VMR and for me it works much better.

Let me end with saying that madVR has still not reached version 1.0, so it's still a work in progress. More improvements are planned for future versions.

Click to expand...