Win Fix: No video (black screen) with Hi10P files and DXVA renderer
#1
This is still annoying me to no end. And I still don't know whether it's a general issue or specific to Intel GPUs. I can only test with Intel G45 and HD4600, maybe someone else can enlighten me how AMD and Nvidia GPUs behave.

Either way, here's a patch that won't allow any other color space than YUV420P when DXVA or DXVA-HD rendering is being used. Perhaps it's helpful to anyone. Enjoy.

Edit: #4163 and #4192 merged.
Reply
#2
After looking at the code... the black screen has (almost) nothing to do with the hardware and should affect every Hi10P playback on any GPU when DXVA or DXVA-HD is selected as renderer, as long as the GPU supports D3DFMT_L16 (although I'm unsure why this is used for the check, since as far as I figured out, this is a monochrome format).

The code for both DXVA Renderers - for DXVA2 see CProcessor::Add() in DXVA.cpp and for DXVA-HD see CProcessorHD::Add() in DXVAHD.cpp - accepts only YV12 input (converts it to NV12) and errors out on any other color format.

So I guess the above patch is the proper fix for now.
Reply
#3
Thanks for looking into it. Unfortunately we don't have any active DXVA dev in the team anymore so its unlikely that you get any feedback here. You could try to create a pull request at github and we link in some peeps who helped in the past with stuff like that.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#4
The observation is corrrect and the patch looks good. Mind setting up a PR?

(For the long term the proper solution would be to use sws_scale color conversion instead of the current implementation in DXVA renderers.)
Reply
#5
Here you go: https://github.com/xbmc/xbmc/pull/4163
I hope I didn't mess anything up, since this is my first PR.

The proper solution would be to use any color space that the D3D device supports without conversion, and convert to the "closest" supported color space otherwise. But I'm not into DirectX coding while I figured out how to query the D3D device for supported color spaces, I don't know shit about what a video frame looks like in memory and how to convert between color spaces efficiently, so my skills aren't sufficient for that at this time... :-(
Reply
#6
I confirm the issue on nVidia (and also AMD) with hi10p material. I'll do some testing and let you know. Thanks for the contribution!
Reply
#7
Sorry, closed PR by accident. Re-opened.
Reply
#8
Just tested the patch and works fine.
Reply
#9
Thanks for reopening the PR and sorry for the mess - still getting the hang of working with remote repos...

I've been using this patch in similar flavors since pre-Frodo times already, so it's thoroughly tested - I just never bothered to post it here since I had no possibility to verify the behavior on other systems than mine.
Reply
#10
np and thanks for the contribution. Keep up and help us improving the DXVA path.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#11
I really hate to say this, but the merge of my PR was a little premature. I found a regression last night. :(

g_advancedSettings.m_DXVAForceProcessorRenderer (an undocumented advanced setting <video><forcedxvarenderer>) still defaults to "true" - likely because XBMC still crashes hard when it's set to "false". Afair it was supposed to default to "false" with the inclusion of the high speed HQ pixel shader code. I guess it never happened...

Now the effect is that my PR disables all color spaces other than YV12 for all renderers under Windows, not just for the DXVA renderers, causing unnecessary conversions and lower precision.

Here's a patch that corrects this. It's barely tested, but I added some debug code, so you can check your debug log to see whether it does what it's supposed to. I'll be afk for the weekend, will PR it next week after testing.


Edit: #4163 and #4192 merged.
Reply
#12
Take your time and make a proper PR after the weekend then others can test as well.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#13
https://github.com/xbmc/xbmc/pull/4192
Reply
#14
I hope this gets merged. From the discussion I see there's a lot of frustration going on.

Here's my take on it. Elupus says "It's a bug if it doesn't check the parameters it's given.", and I think everyone else is saying "yes, it is a bug, but right now we don't know how to do a better fix, and the alternative is a black screen and nothing played".

There seems to be this bad habit with XBMC where if the fix isn't perfect then the improvement isn't accepted, and the end result is being worse off.

At least form a non-programmer's perspective.
Reply
#15
Either it gets merged or the previous one should be reverted, too. As it is now, you have a severe regression that completely disables elupus' original 10-bit processing addition in Windows - my bad, I was actually aware of the regression when I originally created the patch almost 2 years ago, just completely forgot about it since then. Sad

As for "It's a bug if it doesn't check the parameters it's given.", I don't agree, see my comment in the PR. For all unsupported color spaces, the renderer should rely on a previous processing step (in this case: ffmpeg if I'm not mistaken) to do the necessary color space conversion, not fail initialization (=> major feature set reduction). So it's the correct and best way of dealing with the DXVA renderer's current limitation, imo.
Reply

Logout Mark Read Team Forum Stats Members Help
Fix: No video (black screen) with Hi10P files and DXVA renderer1