【已解决】ffdshow解码8bit/10bit视频奇怪问题

[TerrorJack]

播放器是MPC-HC，滤镜顺序是LAV Splitter->LAV Video Decoder->DirectVobSub(auto-loading version)->ffdshow raw video filter->LAV Audio Decoder->madVR->Reclock Audio Renderer。使用ffdshow raw video filter是因为希望用SVP做插帧。

问题在，启用ffdshow raw video filter时，播放10bit视频时，画面上下颠倒；播放8bit视频时，画面上下不颠倒但是madVR的OSD显示render queue和backbuffer queue值低且丢帧严重。 禁掉以后没有问题。

请问各位大大可能是哪个环节出了问题？谢谢 :D

HAPPY END：
问题已解决（感谢Billy Herrington）。LAV Video Decoder和ffdshow raw video filter中仅保留YV12输出，这样一来8bit/10bit视频播放都不会出现颠倒问题且不丢帧。
使用SVP时，Jinc改Lanczos解决丢帧问题。取消DirectVobSub(auto-loading version)，转用ffdshow raw video filter载入字幕，解决字幕tearing问题。
该调的软件参数调遍了，该调人参数了。。

[Billy Herrington]

FFDShow's raw video filter does not allow P010 input pin, so it request YV12/NV12/RGB32/sth. like those.

So, if your decoder prefers YV12/NV12, everything should go fine, except for the dithering down precision may not be as high as RGB32 output in decoder.

While if your decoder prefers RGB32 output for 10-bit videos ( like taro's LAV on this forum ), although it should ( or not, never guaranteed ) gives better result than YV12/NV12 output, it is possible for some odd filters to perform unnecessary data flipping for each RGB channel ( like for YUY2, these interleaved/packed formats always suffer some order issues ), or simply doesn't handle the data order correctly, and thus the picture is flipped. That is why both FFDShow-tryout and DirectVobSub provide functions like FLIP VERTICALLY. What you need to do is to check these settings in your filter chain, i.e., "Output->Stream settings->Flip video vertically" in FFDShow (raw) video decoder configuration ( be careful FFDShow's raw filter and video decoder save settings in different registry path, so you need to make sure to check the setting of the one you used during playback ), and "Misc->Picture Output->Flip picture vertically" in DirectVobSub. If you didn't check those funny boxes, do it, but one only one of them; or if you did, uncheck one.

Generally, it is sugguested not using FFDShow raw video filter along with high bit depth video, as it cannot accept high bit depth colorspace, even though it can output those HBD csps, and you definitely need breaking the high bit depth processing chain to perform csp conversion and dithering in the early stage, which, unfortunately, is never a good idea for a high-quality playback. SVP is another pain. It uses AviSynth for real-time playback, regardless the terrible memory leak and cache mechanism. It is too far from stable, in terms of both quality and performance. Even some television with internal 24->60 interpolation gives you better, or at least, more decent result. Also SVP outputs 60fps pictures, which requires a lot more system resources in the downstream filters like madVR, as without SVP it needes only to render 24 frames per second but with SVP it needs to render 60 frames, which is more than doubled, and you need to make sure you GPU is really powerful enough to handle it.

[TerrorJack]

FFDShow's raw video filter does not allow P010 input pin, so it request YV12/NV12/RGB32/sth. like those.

So, if your decoder prefers YV12/NV12, everything should go fine, except for the dithering down precision may not be as high as RGB32 output in decoder.

While if your decoder prefers RGB32 output for 10-bit videos ( like taro's LAV on this forum ), although it should ( or not, never guaranteed ) gives better result than YV12/NV12 output, it is possible for some odd filters to perform unnecessary data flipping for each RGB channel ( like for YUY2, these interleaved/packed formats always suffer some order issues ), or simply doesn't handle the data order correctly, and thus the picture is flipped. That is why both FFDShow-tryout and DirectVobSub provide functions like FLIP VERTICALLY. What you need to do is to check these settings in your filter chain, i.e., "Output->Stream settings->Flip video vertically" in FFDShow (raw) video decoder configuration ( be careful FFDShow's raw filter and video decoder save settings in different registry path, so you need to make sure to check the setting of the one you used during playback ), and "Misc->Picture Output->Flip picture vertically" in DirectVobSub. If you didn't check those funny boxes, do it, but one only one of them; or if you did, uncheck one.

Generally, it is sugguested not using FFDShow raw video filter along with high bit depth video, as it cannot accept high bit depth colorspace, even though it can output those HBD csps, and you definitely need breaking the high bit depth processing chain to perform csp conversion and dithering in the early stage, which, unfortunately, is never a good idea for a high-quality playback. SVP is another pain. It uses AviSynth for real-time playback, regardless the terrible memory leak and cache mechanism. It is too far from stable, in terms of both quality and performance. Even some television with internal 24->60 interpolation gives you better, or at least, more decent result. Also SVP outputs 60fps pictures, which requires a lot more system resources in the downstream filters like madVR, as without SVP it needes only to render 24 frames per second but with SVP it needs to render 60 frames, which is more than doubled, and you need to make sure you GPU is really powerful enough to handle it.

Thank you for your kind response.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.
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.
3.Not use SVP at all :)

The weird problem is that if I simply bans LAV and uses ffdshow in MPC-HC,problem of "flipping 10bit unflipping 8bit" remains! If I set flip vertically in ffdshow or VSFilter,10bit goes normal but 8bit goes flipped :D
Also,with ffdshow,frames keep dropping in 8bit. Even if I use cheapest algorithms in madVR and play a BDRip not so large.
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?

[Billy Herrington]

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.

[TerrorJack]

To my best knowledge,SVP do rely on a hacked avisynth.dll , which is AviSynth 2.5.8 MT optimized for SVP memory usage.When I use the latest AviSynth MT from Doom9, SVP memory leaks like hell. Using avisynth provided by SVP fixes memory issue.
SVP do not seem to hack ffdshow. I already tried the binded-in ffdshow,original ffdshow and ffdshow tmod,all of which encounter the same bloody "10bit flipped 8bit unflipped" problem(and regardless of VSFilter loaded or not). So I guess the problem is a matter of colorspace.
A thread in SVP forum suggests that SVP processes YV12. I shall try enabling only YV12 in LAV and ffdshow. Hope that works :)

[Billy Herrington]

To my best knowledge,SVP do rely on a hacked avisynth.dll , which is AviSynth 2.5.8 MT optimized for SVP memory usage.When I use the latest AviSynth MT from Doom9, SVP memory leaks like hell. Using avisynth provided by SVP fixes memory issue.

Interesting, but please Stop using Avisynth-MT.

Mt's threading and cache method is totally rubbish. Forgive me if my word sounds rude, but I really can't find any other softer phrase it deserves. Every time AviSynth updates, 2.5.7, 2.5.8, 2.6.0 and even latest 2.6.0alpha4, there were plenties of improvements regarding AviSynth's internal cache system. But what about MT? Never, as no one know what those Mt codes do. A single threading filter eats 200MB memory when filtering, and it is easy to increase it to 2000MB - just SetMTMode.

Yes, SVP fixed some memory leaks, and improved some cache system of MT. So did SEt and his 2.6 MT is much stable than original 2.5.8 one. So what? It is still rubbish. One should never use MT system in the first place. I'm not saying those people are not clever enough to do the job, but garbage like avs-MT has absolutely nothing worthing a fix. It is just a waste of time. If one filter needs threading, there is nothing preventing one from implementing an internal threading/cache system in the filter. Just see how dither's mvtools2 did. If one wants to create a superb filter with great performance and quality, how could one just hack into such a dirty code base? FWIW, SVP does not only use MT stuffs, it relies on it. I have never seen any other filter do in this way. Not even one.

[TerrorJack]

Interesting, but please Stop using Avisynth-MT.

WOW man that WORKS!
Just switched to official avisynth...no more halfway crash trouble :) that is a KIND warranty