OK, then it looks like an incompatibility with LAV DXVA H.264 decoder.
Did you try all corrupted samples posted here with Cyberlink's DXVA H.264 decoder and look perfect, like in the video recording ?
For example, you could try my first progressive clip and an interlaced MBAFF H.264 clip.
No, its not just LAV as KODI shows the same picture breakup.
Your clips play in PowerDVD 14 but playback isnt perfect, there a black screen and a hiccup and the beginning and then they play and skip ok. With Media player classic and CPU decoding they are fine.
So to summaries i;d say the following.
Polaris as problems with H264 DXVA decoding with all filters but performance is just slightly better with cyberlink.
My clips are both progressive.
Did you try an interlaced MBAFF sample from previous pages ?
I can upload one if you want.
I have posted the video recording and your comments to LAV filters.
It is very well known that Cyberlink has some privileged and direct communication/connection with AMD, so probably they have adapted their H.264 DXVA decoder to Polaris "strange" HW H.264 decoder.
I wonder if free/ open source projects like LAV filters can access Polaris HW like Cyberlink.
AMD has definitely changed something in their Polaris HW H.264 decoder, the issue here is if those changes are documented and if they are proprietary and non standard DXVA compatible.
Most of the times proprietary non standard implementations of DXVA decoders, need money from the developers to access them.
i'm going to ease off this thread now until the next driver release, lets pick it up again then. At that point we should put one clip forward that we all agree on that has problems rather than confusing the issue by posting lots of links.
But the problem is, that according to you and others, there is no clip with problems using DXVA H.264 Cyberlink's decoder.
I didnt say that, when i play them I get a black screen and a hiccup before it plays ok, i've also noticed there is a slight hiccup when I skip as well, its not perfect, its not as perfect as CPU playback on MPC-HC
lets leave it and pick it up again on the next release, if it gets fixed none of this will matter.
The issues you describe are minor and are common to unoptimized drivers/HW decoders.
The issues with LAV filters are huge.
The playback looks like completely corrupted.
I agree but i'm getting a bit cheesed off with it all mate, i've been hammering on about this problem for months, ray says AMD might have a fix, lets see what happens on the next release.
1 of 1 people found this helpful
Things could be very positive if the problem is the non standard DXVA implementation of H.264 decoder.
That would mean the hardware is not a problem.
It could be fixed with the new driver, if they go back to standard DXVA implementation.
If I have something new, I'll post it.
As Cyberlink plays it better than LAV, Microsoft also plays it better than LAV but the problem still exists... When I am using Microsofts codec in Media Center, for the first time the program starts playing Live TV it is ok but after a while it starts the corruption. Or it starts when I move the timishift bar. Toggling between window/fullscreen mode sometimes temporary fixes the playback.
With LAV on the other hand, the problem is worse! It is corrupted from the beginning of the playback and toggling windowed/fullscreen mode doesn't fix the problem either.
So we have Cyberlink which is almost fine (Although I haven't check this because I am sick and tired of this), Microsoft which in some cases may be acceptable for a while and LAV that is total disaster. All of these are on different machines, different Windows versions, different players etc.... The only common is Polaris. So we have nothing else to blame except AMD.
I tried both Microsoft DirectShow and Microsoft MFT H.264 DXVA decoders and have the same problems like LAV, during playback or seeking.
Now according to the developer of LAV Video these are some possible solutions for the problem.
"There is so many things AMD could do to resolve such issues -
- Fix them in the drivers
- Send patches to open-source projects like FFmpeg to work-around their quirks
- Or at the very least, document their quirks somewhere so developers can work around them themselves."
So, it's not a non standard (proprietary) DXVA H.264 implementation but rather some quirks of AMD, as the developer of LAV Video wrote above.
Let's see what AMD will eventually choose to solve the issue.
Hi, this is unrelated to this problem but as some of you are HTPC users you might want to know this, or already know this. I knew about this problem a while back and I think the early crimson drivers had force 16-235 in place as default, this changed and I lost BTB&WTW in KODI so I decided to look into it.
see my new thread.
downloading now, fingers crossed.
HOUSTON WE DONT HAVE A PROBLEM.......
Its fixed, wonderful, this is going to save me a lot of faffing with turning DXVA odd and on in KODI to watch h264/h265 stuff, really happy.
I think it would be unfair not to thank ray_m for his help, so thank you ray but.. We still really really need your help with the dynamic range switch, this is so important for HTPC to get BTB/WTW.
ray_m I would be very grateful if you could pass on my new thread now to the engineeers as you've clearly got their ear.
I've re-written this is a bug fix, rather than a bit of a rant.