If this is a bug with the lav filter perhaps you could explain why DXVA also fails in KODI which does not use LAV filters !!!!! so it s a bug with FFMEG too then? come on now.
cant believe people are falling for this nonsense.
Also, I put my old ATI card in my PC yesterday using pre crimson 15.7.1 - guess what happens... no problems. So let put this its all LAV FILTERS fault to bed shall we please and not let AMD off the hook.
fxv300 - mate, you are not helping here, if you dont understand the problem its best you leave the thread alone, suggest this is a LAV filter issue when we know it isnt doesnt help, marking in correct information provided by AMD as useful doesnt help. Testing something that doesn't even use DXVA doesn't help.
I read that post but the problem exists only on RX4xx cards (and Fury as some other guy told us many days ago) both with Microsoft DTV-DVD video decoder and LAV filter. However with the exact same software and HW setup (except the GPU) there is no problem! So does it look like a codec's problem?
If so, Microsoft should release an update fix too.
let me try and make this clear one more time because this doesn't seem to sinking in for some people, this is not a LAV issue as on my own machine i've tested two ATI cards, my RX 480 has problems, i drop my old 1080p (HD 5450 I think) card in, nothing, nada no problems, smooth playback.
This also happens with KODI using FFMPEG codecs, you cant say its the codecs fault if multiple codecs are problematic with the same card, clearly there is a problem with the drivers or hardware
I've told AMD this several times for some people keep stating things like "it works ok if you do this", no it doesnt,you simply arent using DXVA so stop spamming the thread with this nonsense.
The problem with this thread is that it was opened initially by someone who thinks that the best reply is to forward people to his blog in order to advertise it.
Also, it is already 16 pages, basically full of nonsense.
I suggest you to open a new thread regarding this issue, which it is still unresolved and unfortunately it is not mentioned in the release notes of the new drivers.
I tested 17.1.1 drivers in a Windows 10 x64 system and the issue was still there.
BTW, did you test 17.1.2 ?
Hi, since a lot of People mixing up a lot, i try to recap the "current " Stand.
DXVA is broken on RX and Fury on several h264 file and streams, others works fine.(i bring again the example of german FreeTV (DVB), "Das Erste HD" broken "ZDF HD" works(this is strange because it should be the same.)
On DVB (Astra 19.2) its nearly every second Stream which is broken no mater if its 720p or 1080i.(so forget about AMD says stream is corrupt)
H265 works fine.
It appears with LAV Filter and Microsoft Decoder.(Nevcairiel Author of LAV says its AMD...)(if you disable DXVA in LAV and use Software its also fine)
A good hint for his saying is, that on older AMD Hardware 270x,280x, A10-7800 APU (thats what i have tested)it works fine without that error.
If AMD would show some Interest i would Test other Decoder....,but so far they say not a word.
not tried 17.1.2 yet, has anyone else?
ra_aly I am going to post this again for the third time so its absolutely clear
Play this clip on this card using a media player with DXVA LAV filters using hardware H264 decoding or DXVA FFMPEG (KODI for example) codecs you will get corruption, the common element here is DXVA.
This one works fine.
Both are H264 encoded.
If both these clips play properly (make sure you try to skip through them as well as play them) without any blocky corruption you cannot be using DXVA
This is as simply as I can make this, get this working AMD and you'll probably find all other issues DVB wise will also cease to be problematic, this should not be rocket science for AMD, get it fixed people.
This is the feedback received:
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:
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.
ray_m , well thanks for that, that is appreciated to finally have some real feedback.
Indeed though that has to be the crux of it, plus why doesn't it effect NVIDIA cards either, AMD cannot blame this on software or codecs if it only happens on AMD cards, and their newer ones to boot.
There is still no official acknowledgement though, we'd all like to see AMD finally admit there is a problem here and attach it to the next or current driver release as a "known" issue - this way at least though who need to get get an RMA and return it before they are stuck with it, like I am now, I cant get a refund, only a replacement which is pointless.
I'm already working on getting it back into the know issues list.
Thanks for the info Ray. Keep us posted.
3 of 3 people found this helpful
I got a reply from LAV filters developer for the explanation of ray_m
"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:"
Just because a frame is right after an I frame doesn't mean there is no further references, those can go beyond I frames in H.264.
It is fully possible that a reference frame might be missing right after a seek. When this is the case, a empty frame is generated in place of the missing frame, so its not actually missing - just an empty dummy frame. This will lead to corruption when its used as a reference, but this happens to all decoders - software or any hardware. The information just isn't available. When this corruption happens, it fixes itself as soon as new key frames arrive, which is typically rather quickly.
"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."
This is not true, on a seek all reference frames are destroyed, and all reference frames that are available are also given to the hardware. Software doesn't have any "extra" frames unavailable to the hardware.
The real question should be: Why does this issue not happen with any other hardware, even older AMD cards?