I think you misuntersmood my post. I only explained how RGB32 and other interleaved formats suffer flippings, and the fact that FFDShow or some other filters may have issues when handling these formats, and how FFDShow does not fit high bit depth playback. I never say that LAV, the provider of RGB32, should be blamed.
From your thread I think I can figure out solutions like:
1.Set LAV Video Decoder output to RGB exclusive or 8bit exclusive,disable all 10bit and 16bit colorspaces.That shall force LAV VIdeo Decoder to dither 10bit source to 8bit.
Not exactly. Leave LAV settings as is, it does not do any weird thing at all. What csp it provides is determined by what csp is requested by the downstream filters, not LAV itself.
For example, as madVR or xy-vsfilter accepts P010 csp, LAV will offer P010 for 10-bit 4:2:0 sources; as FFDShow does not accept P010 pin in, LAV automatically provides RGB32/YV12/NV12/... instead. LAV choose output csp in a good logic according to the downstream filter's need. It does not require special tweak in normal cases.
The weird problem is that if I simply bans LAV and uses ffdshow in MPC-HC,problem of "flipping 10bit unflipping 8bit" remains!
It already explains where the problem came from. Clearly it is not LAV but ffdshow. So,
2.Not use LAV Video Decoder,just use ffdshow instead.That 's a pain because LAV has better hardware acceleration(CUVID and DXVA copy-back) while ffdshow has only QuickSync and native DXVA.
No, LAV is the best solution currently.
Now, let us double check what filter filps the video by: disable P010 and other high bit depth stuffs in LAV output csp, also disable FFDShow, vsfilter and any other filter chains between LAV and madVR, thus LAV will directly output RGB32 to madVR (taro's mod version, or with official version you also need to disable YV12/NV12/YUY2/any other YUV csps). Inspect if the RGB32 video is still flipped or not in this situation. If not, the problem is not caused by LAV or madVR, but FFDShow or some other funny stuffs you added in between, which is exactly the thing you need to fix, or get rid of. If the video still flipped with only LAV and madVR, it is most likely that something went wrong in LAV, and you should use something else instead.
In my personal test, LAV+madVR works fine, no matter the source is 8bit or 10bit, and the output csp is YV12/NV12 or RGB32 or P010. I tried to insert ffdshow raw video filter and let LAV output RGB32 to it, still nothing breaks and the video shows normally. So my current concern is whether ffdshow's AviSynth server works fine. I added some simple filter accept RGB32 in the AviSynth script editor like Blur(1), Sharpen(.5), etc., and it still works as it should.
In the second stage, what you need to do is testing if SVP works fine in RGB32. AFAIK, SVP uses a hacked version of avisynth.dll. I don't know if it also hacks FFDShow or not. So you'd better check the ORIGINAL version of AviSynth and FFDShow at first as mentioned in the previous stage, with simple filters. If you already find video flips at this step, I can only say that your playback environment is quite different from mine, as it works well for me. If it works well for you too, use SVP's AviSynth & FFDShow instead, but still disable SVP, only use the same simple filters. And if the video flips now, SVP sucks as its hack is broken. If it still works good, enable SVP, and as you expressed, video flips hence SVP still sucks, at least it does not handle RGB32 correctly.
I am eager to know if there is a similar but more mature solution that offers real time interpolation on PC.Because I find it hard to stand judders.All players show judders,so perhaps this is just a problem about source fps...am I right?
No. If the judder was introduced during playback environment like 24->60 conversion, active madVR's smooth motion FRC. If the judder was in video source itself, then a good playback system should keep it as is. Playback only works to show the original look of sources, so if you don't like something in the sources, fix them instead of fix your playback.
If you really cannot live without SVP, the only solution is not using RGB32 for SVP. SVP's SVSuper/SVAnalyse for AviSynth works only for YV12 sources, which makes me highly doubt if SVP works for RGB32 at all. Maybe it just try to act as if it can, without even a warning, while it actually can't. Since many AviSynth filters works only in YV12, you can try to tweak the "input colorspaces" checkboxes only in ffdshow raw video filter's AviSynth function by disabling YUY2/RGB24/RGB32 and only enabling YV12. It will not affect other dshow chains and is a safe option. If SVP does not even live with this tweak, it must have done some hacks in FFDShow's AviSynth provider, which actually makes FFDShow's AviSynth provider and AviSynth runtime a private garden for itself, and the only option is either only enabling YV12 in LAV output csp, or only enabling YV12 input in FFDShow raw video filter's "Raw video" of codec function instead of "all supported", or using InterFrame in FFDShow raw video filter's AviSynth server instead, which enables you to use official AviSynth & FFDShow without those dirty hacks, and you'll clearly get warnings that it does not accept any csps other than YV12.
Anyway, if you did find something use such many unstable hacks to unsuccessfully achieve a goal ( mosly people can easily find artefacts by SVP's bad motion search and interpolation ), and you still trust in it, being keen on it, I personally cannot offer any further useful advices for you. Wish you a good tour with it.