HDMI loss on 3D frame packed playback stop

[mclingo]

Hi, i'm hoping that maybe someone can give me some help or direction on a problem i'm having with all MADVR / LAV based players, I personal think this is an issue MADHI and NEV need to look at but they have pretty much shut me down stating its nothing to do with them.

The issue is as follows, i'll be using MPC-BE as my example player but it happens in MPC-HC and KODI DS as well.

When I play a MVC frame packed 3D movie it plays fine, my TV shows "3D mode enabled" and I get great smooth playback, however when I stop the movie I get the correct message from my TV stated 3D mode disabled but instead of getting my desktop I get HDMI handshake loss and a black screen.

I can replicate this in the following conditions.

Desktop resolution 3840x2160
Refresh rate switching MADVR
Decoder any
Outcome HDMI LOSS

Desktop resolution 1920x1080
Refresh rate switching MADVR or MPC-BE
Decoder any
Outcome NO HDMI LOSS

Desktop resolution 3840x2160
Refresh rate switching MADVR or MPC-BE
Decoder D3D11
Outcome HDMI LOSS

Desktop resolution 3840x2160
Refresh rate switching MADVR or MPC-BE
Decoder COPYBACK
Outcome NO HDMI LOSS

The issue appears to be that there is a problem with resolution switching from 1080p back to 4k when coming out of MVC frame packed 3D playback, however what is odd is D3D11, why does this also cause this problem as it should not have any effect on resolution changes according to NEV. MADSHI also reports he feels that there is no issue with refresh rate switching in MADVR, even though when I turn both MADVR switching off and D3D11 this corrects the problem.
Obviously the workaround is to not use refresh rate switching in MADVR or D3D11 decoding in LAV but D3D11 decoding gives me anything up 20% more number crunching in MADVR that COPYBACK does so I want to use this.

Can anyone hazard a guess what is going on here, why are players having issues jumping back out of MVC playback on 4K screens.
There aren’t many 3D 4k TV’s out there, and those that have them probably don’t use them which is probably why this hasn’t come up yet.

I’m aware that the current 3D system is on its way out but I can help feeling this problem is going to impact HTPC in other areas as some point too.

If someone could suggest a better forum to post this on let me know.

[Warner306]

This should be reposted in the LAV Filters thread.

[sneaker_ger]

Not according to the LAV author:
This is all outside the scope of LAV Filters, it has no control over your video output or your drivers. So please debug your problem elsewhere. :)
As said above, the hardware acceleration code is never executed with 3D decoding, since that all goes through the Intel decoder, not the typical hardware-accelerated path.

[mclingo]

This should be reposted in the LAV Filters thread.

Hope you are joking :), NEV just flat refused to look at this insisting its not an issue with LAV, I advised it was indirectly connected but he insists not.

No point arguing with the Dev, his world is final even if he's wrong.

[nevcairiel]

If the mere act of creating a D3D11 device at any point causes your HDMI output to go boom, then there is really only one part to blame: The driver.

But nevertheless I just double checked, and the D3D11 code in LAV is never executed when a H264 MVC stream is being decoded, it goes straight to the MVC software decoder - unless, as mentioned in the LAV thread, you actually open the LAV Config screen, which does some probing of the available hardware devices, or perhaps the player interacts with LAV the same way (MPC-HC does not, I don't usually test with MPC-BE). But even that does nothing more then create a device enumerator to get their names, and see if they work. Nothing that should harm anything.

[mclingo]

you could explain away any problem with a driver issue, that kind of response helps nobody mate, how do you know its not a problem with the way LAV/MADVR/D3D11 is communicating with the driver for instance?, why is COPYBACK working if the driver is broken?, why is KODI DS refresh rate switching working and MADVR's not if the driver is broken?

[nevcairiel]

Bugs don't necessarily follow an understandable logic. Doing operations in a different order can already result in a different outcome.

And why I think its a driver bug? Nothing LAV Video could ever do should result in that outcome. In fact, nothing any software does should result in that outcome.
(That doesn't change the fact that LAV Video doesn't actually do any hardware things when 3D decoding).

[huhn]

it's simple how can a problem create a HDMI handshake issue?
correct it can't you are just asking the driver to do it.

are there ways to work around it? maybe...
the next thing is you will not get a fix if no one else can reproduce the issue.
so what are the devs supposed to do? randomly change stuff?

so there are two things you can do contact AMD about that(in my experience they usual at least note it that more than i'm used with nvidia). and second you wait for madshi to maybe have a look at it and be patience for a change.

you complained about handshake issue with higher bandwidth setting so there is already something totally broken at your end.

[clsid]

Desktop resolution 3840x2160
Refresh rate switching MADVR
Decoder any
Outcome HDMI LOSSFocus on this issue and forget about decoders being related.

Create a debug log for Madshi.

[mclingo]

I just dont see that at all, you act as if the decoding is somehow completely separate in the chain of events which leads to the movie stopping correctly and returning to the desktop, any point in that chain that fails to work properly is going to produce the wrong outcome, if COPYBACK produces the right outcome in identical circumstances D3D11 MUST be doing something different in the chain of events or indirectly causing something else in the chain to misbehave, that’s just logical.

[nevcairiel]

I can only repeat myself because you seem to be overreading this: D3D11 in LAV Video is not doing anything at all when decoding a 3D file. I have specifically confirmed that just minutes ago without a shadow of a doubt.
Good luck with your problems. If you believe to know how LAV Video works better then I do, then feel free to fix your issue!

And even if it were to create a D3D11 device (which it is not, unless your player forces it to), if that alone causes your driver to lose the HDMI Handshake, then this is a driver bug, absolutely no question about that. You can stop trying to spread the blame between madshi or me, and actually contact the party that actually controls the HDMI output: AMD.

[mclingo]

Mate, i'm not saying that the actual decoding thats taking place is causing this, what I am saying is that using D3D11 in LAV is producing a different outcome to COPYBACK and that should not be happening, If you dont know why this is then this is surely a gap in your own knowledge too, simply saying its a driver issue is a cop out.

if you dont know whats causing thats fine, if you dont have time to look into it thats also fine but you know full well that a very specific issue like this will never be on AMD's radar, if you and MADSHI dont fix it nobody will and I guess we'll just have to live with that disappointment.

[mclingo]

Focus on this issue and forget about decoders being related.

Create a debug log for Madshi.

ive already done that, MADSHI also doesnt feel there is anything to look at here.

[mclingo]

I might have solved my HDMI loss issues with a hardware workaround, I had one of these I was using a while back but removed it when I rebulit my pc and forgot to put it back, this seems to hold HDMI handshake.

I also tested it with HDR, its seems to have enough bandwidth, so I can go back to D3D11, i'm going to test refresh rate swithing in MADVR with it as this also produced this issue so I had that disabled.

https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter


refresh rate switching working ok with MADVR in MPC-BE but not in KODI DS, more variables in DS though, however D3D11 now works in DS with DS rate switcing, this wasnt working before so thats a good thing as I get more processing grunt with d3d11.

[foxyshadis]

you could explain away any problem with a driver issue, that kind of response helps nobody mate, how do you know its not a problem with the way LAV/MADVR/D3D11 is communicating with the driver for instance?, why is COPYBACK working if the driver is broken?, why is KODI DS refresh rate switching working and MADVR's not if the driver is broken?

A good solid 80% of playback bugs end up being driver bugs, why wouldn't you expect it to be one? Almost everything works slightly differently between Intel, Nvidia, and AMD, and some things don't work at all in one or the other. Many things work differently in different hardware generations. That's all summed up as "driver bug" and is best reported to the manufacturer, though I've had very spotty luck in reporting bugs that don't affect an AAA game. It's maddening and I've been this close to tearing my hair out so many times; HTPC is definitely the red-headed stepchild to them. I know nev has personally reported a lot of driver bugs, but if he can't reproduce it, he can't report it.

[mclingo]

HI, I've never said it wasnt, the problem is that nobody seems prepared to look into this because its already been written off as a driver bug when nobody can possibly say it is or isnt, surely this needs some diagnosis before we come to this conclusion?, especially when the variables seems to suggest that MADVR's fresh rate switching is doing something different to KODI's

[Asmodian]

How is a developer supposed to look into a bug they cannot reproduce? Trying to discover workarounds for bugs you cannot reproduce is not productive.

[mclingo]

i'm sure its not easy but there has been discussion regarding how difficult it would be, it has simply been dismissed as a driver bug. I dont honestly know how they would diagnose it other than to own an RX card and a HDR, you surely dont have to exactly reproduce all bugs to be able to investigate them, otherwise MADSHU and NEV would have to have a warehouse full of kit :).

There has to be a reason that MADVR fresh rate changing is causing HDMI loss and KODI and MPC-BE does not, this should enough to go on to look into it at least, surely?

[huhn]

and what do you do steal the code from kodi?

[mclingo]

this is getting pedantic, forget it, its clear there is little interest in resolving this issue, no point discussing this further.