0.9.1, 10-bit video doesn't show with EVR #37
Comments
|
This is in fact a bug introduced in v0.5.6, but was lucky never surfaced. I recently changed the way how FORMATS are managed and added extra checks, and thus exposing this bug. Try this AviSynthFilter.zip |
|
seems to work |
|
broken again, somewhere between 0.9.4 and 0.10 |
|
Can't reproduce with current. The file you mentioned in #49 was P010, and I could play it fine. Do you mean the old version was broken (which already got fixed) and ask me to backport the fix? |
hmm...
I mean the current version is broken again since 0.10 |
Fixed the log lines. Didn't think renderer would make any difference. |
|
the thing in EVR doesn't want to load with 0.10+ AND 10-bit video, and it loads simple "Video Renderer" instead, which doesn't render 10-bit video at all 0.10 + EVR + 10-bit video --> ??? build from 24.03 - works (as NV12) |
|
MPC-HC, by the way. |
|
I can see the Video Renderer problem. I'll check the problem. However, it says P010 works, weird:
You can see in my log that it works as P010. Maybe post your MPC-BE log for diag? |
|
OK, I found out why. 933813a fixed a problem that generates incorrect media type for pin connection. Here is the log before the fix: Here is immediately after the fix: This was the problematic line: A simple workaround on our end is to tick off P010/P016 from LAV Filters, so that NV12 is used as input type. Alternatively, we could add something like But the real problem is probably:
|
then how it works in P010 without AVSF?
|
|
ah, yes... clsid2/mpc-hc#767 so, can we add a counter-heuristic specifically for MPC-HC? |
|
Glad we found out the cause. I don't understand what counter-heuristic you meant. Do you want AVSF to not offer P010/P016 as output type if we detect the downstream is EVR and the loading process is mpc-hc*.exe? Frankly, I think since MPC-HC seems to have the most knowledge (knowing the Microsoft bug), they should make a decision. Either allow all filter upstream to offer P010 to EVR (not only just LAV), or ignore the P010/P016 returned values from GetMediaType() if the renderer is EVR, so that it fallbacks to NV12. I think this is the right way, because you never know how many DS filters are out there. Requiring every single filters to add these special handling logic is overwhelming. |
kind of... cause from the user's point-of-view right now AVSF just doesn't work in the most common configiration, which is MPC-HC + EVR |
|
See my update. I think clsid2 should make decision. |
|
Let's say clsid2 will do something in the next version. That will mean AVSF will be fully compatible only with MPC-HC 1.9.14 and later. And if he won't do something then AVSF won't be compatible with MPC-HC ever. So, how can I finally make AVSF the default option when installing SVP? |
|
did you read clsid2's answer? don't you want to participate, cause I see a kind of deadlock here :D |
|
Yeah, I thought about 3. and it won't work.
I think let's wait for clsid2's decision, and work out a solution together. |
sounds like the best solution |
|
I saw clsid2's comment, and thought myself: hmm, that logic sounds awfully familiar. Turns out the last time I tried to fix this issue, I effectively disabled the input pin reconnection process. https://github.com/CrendKing/avisynth_filter/actions/runs/919855208 should reactivate it, so that MPC-HC EVR P010 would result in NV12 while everywhere else is P010 as expected. And if one day MPC-HC decides to allow P010, no change is needed in AVSF to get back to P010. Is it good enough? If yes, please let me know and I'll release a version. Please help me test this. I don't want it to be wrong the third time. Thanks. |
|
BTW, I was testing SVP with MPC-BE on the P010 video. If EVR is used, the initial output media type will be settled as P010 as expected. However, when SVP injects, it tries to dynamically change the media type to NV12 (with
This is because the input media type is already changed by SVP to NV12, but output media type stayed as P010. We could try to reconnect the input pin with P010, but then SVP won't work anyways. If madVR is used, the P010 to NV12 change is allowed, and it worked. So from SVP's perspective, it's actually better for EVR to not accept P010 as the initial media type. Of course the cost is losing 10-bit video, but it's infinitely better than wrong video. |
actually it depends on the App. settings -> Add. options -> Allow output in 10-bit
clsid2 told about it - if EVR is a 8-bit renderer anyway then feeding it with 8-bit after dithering is better than plain 10-bit. Cause EVR doesn't do dithering. so if I'd made a "SVP Filter", I'd just add a EVR-specific heuristic,... |
Are you sure? I set it to "Always" and it converted to NV12. Just tried Never and same result. Do you mean if set to Always it should not produce those two convert functions?
Is it? Any source? I mean I don't know any official document listing the support input format of either EVR, madVR or MPC VR. All those "EVR doesn't support 10-bit", "madVR supports 10-bit and HDR" are empirical knowledge. Even AviSynth doesn't have official documentation about their APIs. That's why I'm grateful that VapourSynth has a documentation site. If Microsoft offcially says EVR does not support 4:2:2 or 10-bit, then feeding it P010 is considered bug. It's not a matter of if I like or not. (Which also means MPC-BE is wrong, and also means MPC-HC is only right by orthogonal reason)
If there is one I can surely consider. Seriously, how many video renderers and splitters/decoders are out there? If we only support LAV, EVR and madVR (and maybe MPC VR?), and only MPC-HC, MPC-BE and PotPlayer, it's not a big list to begin with, right? |
"it typically gets converted to RGB32 in the renderer, so you might as well do conversion to 8-bit earlier in the chain and be able to apply dithering" (c) |
totally sure. however 10-bit output is not working w/o "GPU acceleration" ON, for example... |
seems to work in MPC-HC |
I meant is there official document from Microsoft stating that when given 10-bit content to EVR, it converts internally to RGB32? If you can find, then treating it as 8-bit seems reasonable. If not, is there an easy to test what kind of data it sends to graphics card?
You are correct. I disabled it. I was not aware of this conditon, and I didn't find any page from SVP wiki mentioning it. Once enabled GPU (NVOF or not), everything works.
I can repro. I'll look into it. |
|
so, ok... the only ultimate solution to all this: if you want quality - 10-bit gradients, tonemapping, etc - go for madVR no idea wtf is going on with PotPlayer's renderers, they doesn't work even with all 10/16 checkboxes unchecked |
|
About the option: AVSF already has the input format checkboxes. What if we just make a table listing the video renderers and their recommended input format selections (EVR: only NV12. madVR: all. MPC VR: only 4:4:4, just example ofc). It's not like people change their video renderer frequently. Then add a paragraph about writing custom avs script. I feel giving user more control and educate is better than doing everything behind the curtain. At least I never like others doing that to me. If SVP wants to make choice for your users, feel free to pre-populate relevant registry values or ini entries when installing. And it disallows any debugger to attach to the process. Very open minded /s. |
Not sure someone will ever need such flexibility and we can't test every renderer in every video player out there. So the proposed option will have two positions: 1 - do whatever you want, 2 - "just work" in every possible situation |
|
For PotPlayer, even if I disable all input formats other than 4:2:0 8-bit, I still connects to Video Renderer for the 10-bit video. Then if I switch to a 8-bit video, even if I select the DirectX 11 renderer, I get connected to Built-in Direct3D9 Video Renderer after multiple pin reconnections. There is a "10-bit output" checkbox, but doesn't do anything. So I'm guess there is some special treatment inside the player that whitelist only certain upstream for the built-in renderers. I'd suggest just stay away from them. |
|
About the option: what about if by default or new installation, the 10/16-bit input formats are disabled. And we put a note in README that 10-bit can be explicitly enabled by ticking them, with "Make sure you have 10-bit capable video renderers installed, such as madVR, MPC VR, etc". I think since these VRs are not available by default and always manually installed, we can assume whoever does that at least knows something about video playing. Also, I made checkboxes by duplicating whatever LAV Video Decoder has. I don't expect everybody to know or do anything about them, but if someone does, at least it's there. |
|
The thing is nobody reads readme. |
|
My thinking process is, SVP users might be non-tech-savvy people who don't know these details, but since you are their "guardian", you can do whatever you want to help them: changing registry or ini based on their selection in the installer/SVP manager. You can easily detect if they installed madVR (e.g. HKEY_CURRENT_USER\Software\madshi\madVR). If they have problem using the filter, they don't come here and create issue. They go to SVP forum and you help them. While my target audience is the ones that literally find this project, download and install themselves. I expect them to know how open source projects work and read docs. Anyways, I could even put a http linked text in that settings page to the relevant README section. Gonna be pretty much the same as your mockup pic. |
madVR is installed and enabled by default (i.e. if the user install SVP "blindly" by clicking next-next-next) another case: user observes that madVR is too heavy for his hardware, then right now all he have to do is switching the renderer. which is done via player's native options, even from the context menu in PotPlayer... and you want him to go to the filter's options. why? I really don't understand what bad side do you see in maximum compatibility with default settings? |
|
I understand your concern, but I don't know what do you suggest we do here? Do you want the filter to detect the downstream, and react according to an internal whitelist, such that if downstream is madVR, automatically enable 10-bit, if EVR, automatically disable 10-bit? What if user forcifully want 10-bit on EVR (if he uses MPC-BE)? What if user don't want 10-bit on madVR? Do we put the whitelist in configuration (registry or ini)? Do you expect people to edit that whitelist if they don't even use the GUI settings? So can you use a few clear bullets to summarize your suggestions? |
|
I don't think this checkbox is good idea. If the premise of using it is based on user reading README and understanding, then what I've put in that section should already suffice. If they don't read or can't understand, this only confuses them. As for default, I'm OK either all checked, or all but 10/16-bit checked. The difference is pretty much if we want user to have best video quality or best compatibility by default. I'm OK either way. I changed only because I thought you wanted MPC-BE EVR to not render P010. If I misunderstood you, I can change it back. |
SVP will check it at installation time, and w/o SVP nothing changed at all |
Are you saying SVP might change this setting during installation if it detects madVR being installed? That solves the "README" problem. But still, it confuses people who don't use SVP.
Are you saying SVP might dynamically inserts something like |
I want AVSF working in any of the following situations, w/o modifying any checkboxes before every run:
case 1 already solved |
|
If I revert the input format change but keep the README change, case 1 and 2 are already good, so our focus is on case 3, which is what I understood: you want non-MPC-HC EVR to not take P010. From what I can see, SVP installer does not include any non-MPC-HC DirectShow player. So imagine if I introduce this new checkbox and config. How do you plan to make use of it? Any combination from SVP already works out of box, so there is nothing to be done. If someone uses SVP just for the filter (they bring their own player and/or renderer), you can't just flip the checkbox for them blindly. You require that user to read the never read README, understand the checkbox, and make the choice themselves. How is it different to status quo? Imagine one day, SVP does include MPC-BE in the installer. Now you can detect the MPC-BE + no madVR combination and turn on the special checkbox. But again, without the checkbox you can just uncheck the 10/16-bit formats the same way. Similarly, if you include a checkbox in the installer asking user if they have the problematic combination, instead of turn on this one box, you can uncheck 10/16-bit. In short, my basic assumption is, for your average user, they use one player and stick to one renderer. They only need to make the input format choice once and be done with it, which can come from SVP installer. They don't need dynamic format detection and pin reconnection. If the user either have 1) multiple players and/or renderers; 2) frequently change those settings, then I think requiring these minority to make intelligent choice on input format is not too much to ask. Forgot if I mentioned before or not. As to a solution to case 3, we can
This does not require any change to the settings or checkboxes. It just works. What's concerning is that player detection method. It's very fragile. If someone rename MPC-BE to mpc-hc64.exe for whatever reason, it will fail. I asked clsid2 about reliable player detection and he didn't answer (I assume no better way). |
mpc-hc is fine w/o all these at all! (*) "any", not "other", but as long as MPC-HC is already covered, then a say "other" |
|
I don't know how to satisfy the 3 conditions at the same time
If you whitelist, it means you want to not give EVR 10-bit. But if you then sometimes want to give EVR 10-bit, you have to make another config. By its very nature, this config won't be straightforward. I think we've discussed this at length. I tend to just leave it as-is now. Besides, SVP (w/ MPC-HC) won't be impacted at all. If you want to discuss this furthermore with new thoughts, please create a new issue. |
Again, a regression in 0.9, works with 0.8.5
MPC-HC, EVR-CP renderer, any 10-bit video
0.8.5: connects as NV12, plays fine
0.9.1: doesn't connect at all, video isn't processed.
it works only if uncheck both p010 and p016 checkboxes
... and nothing else
The text was updated successfully, but these errors were encountered: