[WiP] madVR support in MP1 (3 Viewers)

[GeYe]

Can confirm DXVA native didn't work at all for me. I also had crashes if i remember right. By the way first time the AMD h264 bug was confirmed by a AMD supporter in RX480 DXVA H.264 not working. | Community:

The corruption with the clip only occurs on seeking.

When user perform seek, the player supposed to locate the key frame first. I’ve verified that the first frame that decoder received is indeed a key frame and the output is fine without corruptions.

However, the issue starts happens in the next frame player sent out – the reference frame. While the bitstream is correct, the picture parameter sent by the player is not correct. You can reference the following dxva2 specification provided by Microsoft:


https://msdn.microsoft.com/en-us/library/windows/desktop/cc307941(v=vs.85).aspx



The picture parameter provided for the second frame shows 4 frames in reference list:


However, there should only be one because this frame is right after the I-frame (key frame), analyzer shows this as well:



This triggers the driver code that when it detects a frame is outside the reference list, it will mark this frame as an error frame and trying to conceal this error by copying from the latest frame in reference frame buffer. This error propagates and user will see some image flipping and corruptions


Why this issue doesn’t happen with software decoder? In software decode it always keeps all reference frame in memory and will not destroy it, so it will always able to find the reference frame even though it is outside the limit.



------

I'm still following up why it affects RX cards and not earlier gen products.

Gives me hope this will be solved.​

 

[microfast]

Well 24P content works fine with my Bravia + GTX1080, smooth playback and no judder whatsoever
Some TV screens just suck at image processing so not really the fault of the software, for instance with LG the 24P playback in general is bad when panning.

You can create a custom resolution for have the correct 23,976Hz. rather than 23,971Hz., however so doing the 3D doesn't work anymore ...

 

[joecrow]

I am currently running the standard 1.16pr as part of an investigation into a crash on resume problem but I did want to report back on zapping with this version:-
As far as I can tell the clunky zapping is neither better nor worse than with v280. I spent some time this morning running some tests and as with v280 zapping is mostly very good with just 1 of my 4 tuners in use (just very occasional it will clunk a little bit) but once I start a recording it becomes very clunky, interestingly adding a further 1 or 2 simultaneous recordings does not seem to worsen the problem.

 

[daWooky]

hi joe, it acts here just the same it only happens if ya change the tuners.
and it seems more obvious on single seat than on clients. but it happens there too..
zapping on one and the same tuner is pretty good and stable overall...

 

[daWooky]

And played a little with the recordings yesterday. If one runs and a second directly starts the osd infos not getting changed if ya switch to the second. The information from the first still persist not the correct now playing.

 

[joecrow]

@Sebastiii I know you are aware of the crash on resume from sleep problem I've been having and the testing done but just to confirm and let the others know: the problem does seem to be specific to or possibly worse with v280 (not tested with earlier versions, but I think also a possibility) and does not occurr with the std. 1.16pr.
See here

 

[Sebastiii]

I have update the branch against latest master code (label to V281) so same as 280 + newest latest fixes
Can you try based on this to confirm if it crash or not ?
Thanks.

 

[joecrow]

OK I'm now up and running on v281, so far so good but it can take a while/overnight before the problem shows itself.
I will report back as soon as I have anything

UPDATE:-(9-Feb-17)
No problem this morning, looks promising.

 

[daWooky]

Hi guys
with v281 zapping with tuner change seems better - just a little pixelation after change of channels
but yesterday while installing the annoying font error handle32 occurred again

and the videoOverlayTop missing xml stuff similar like @GeYe reported in the ares thread. [URL="https://forum.team-mediaportal.com/threads/bug-reports.135426/page-7#post-1211075"]Bug Reports[/URL]

today it seems ok and the little border is getting also displayed again and btw. it happens also with the defhd skin not only ares.
if it happens nothing helps to get rid of it exept mepo restart.
i dont know if ya able to reproduce it seb,but just in case^^ nothing special.
start tv, go back to tv mainmenu and than into the recordings. tada there it is the missing xml -although it's not missing or corrupted

 

[joecrow]

v281:- No problem again today on resume from sleep, that's a fix for me.
I do not see an improvement with zapping though, it still gets clunky sometimes, but no big deal there. Not sure yet whether the high render times intermittently on some 3D vids is fixed, it definitely, is on 4K vids, I still need to do more testing there.
Everything else is working great for me.