I still can't understand how is this a bug in the video stream but is only appearing in AMD specific chips...
nikosd With LAV this appears to be the only problem now, but with microsoft codecs I had video corruption on Live TV after half an hour of playing without switching channels.
If only someone could explain to me why this is happening with polaris cards and not with Intel or nVidia or older AMD (such as 290).
The problem now is that AMD engineers think that this is totally fixed and probably they won't try to improve anything further.
My HD TV box also sometimes displays a corrupted HD image, which corrects after a while.
unfortunately i can also confirm some corruption does still exist in movies but only with skips by the looks of it, plus it corrects itself after a few seconds instead of sometimes remaining corrupt or taking a good 10 -20 seconds or next scene.
I guess I can live with this but obviously it would be nice to have a 100% fix.
its actually perfectly fine with KODI using FFMPEG, the corruption starts when LAV enters the frame, this means I have a 100% working solution for KODI which is all I personally need for now.
I use LAV filters for 3D MVC playback though so it would be nice to get the full fix, can we let the engineers know there is still more work to do with LAV filters.
chrome uses the video card to play youtube videos, very slightly
try it and see if the video card flinches
The problem is NOT 100% fixed for sure.
So, besides nikospot issues with Microsoft's H.264 decoder and the others, I also tried a different ffmpeg based decoder/ player which is PotPlayer.
Using PotPlayer the problems are still huge during seeking, most of the times the result is corrupted image which recovers after a while, but sometimes the stream can't recover its fluidity, it's broken.
I also see occasionally corrupted image using LAV Video when you skip/ jump a lot of frames and in the first H.264 progressive clip I posted, it breaks the fluidity after the jump.
The fix needs definitely a little more fine tuning, to be called 100% fix.
I suggest the developers of LAV put some time into fixing their software too
Other codecs work so do not blame AMD when it may be LAV at fault
When using software decoding, all is fine, so why should LAV Filter be at fault? The only question I have, which I can't answer because I don't know how it all works: when hardware decoding is involved, where does the responsibility ends for the user software (LAV Filters in this case) and where it begins for the hardware/driver.
I've also tested Windows Media Player (Windows 10), which doesn't use LAV Filters. In this case, the decoder is also unable to recover after the stream discontinuities. I've tested with the sample I submitted to AMD for Crimson 17.2.1, drive.google.com/open?id=0B1LFjoQAxESONWxSZlBYU1lDRjg (you must download it, don't use the webplayer, because the video is re-encoded by Google).
But Windows Media Player doesn't give any information if hardware or software decoding is used, so I can only assume it's hardware decoding, because if I disable the Radeon RX 480 video adapter in Device Manager, Windows switches to the basic adapter driver and when playing the sample, WMP is able to continue playing normally after passes over the discontinuities.
Not an expert on this but this is roughly what I was told.
Based on the clip provided:
When the user performs a seek, the player is supposed to locate the key frame first. The first frame that the decoder received is indeed a key frame and the output is displayed without corruption.
However, the issue starts happens with the next frame player sends out – the reference frame. While the bitstream is correct, the picture parameter sent by the player is not correct and not following DXVA2 specs supported by Microsoft.
The picture parameter provided for the second frame shows 4 frames in reference list. However, there should only be 1 because this frame is right after the I-frame
This triggers the driver code that when it detects a frame is outside the reference list, it marks this frame as an error frame and trying to hide the error by copying from the latest frame in reference frame buffer. This propagates the error and results in image flipping and corruption.
In software decode, the reference frame in always kept in memory, so it is always able to find the reference frame even though it is outside the limit.
Which clip ?
In my previous reply, you can find a drive.google.com reference.
@ray_m seeking is not required with my sample. The sample contains a stream discontinuity, just let it play.
So you're saying that even Microsoft's codec doesn't respect the DXVA2 standard. You're saying that the user software component (LAV Filters/MS video decoder) should sanitize the stream before passing it to the video driver? Also, you're saying that the software decoders (LAV and MS's decoder) are working outside specs when doing software decoding, since they are able to recover?
The clips were the two Jellybean ones provided by Mclingo.
mhanor I'm not saying anything, I'm just reporting what the EXPERTS on this subject matter told me. They were clear that the Lav filters were buggy which were based on the FFMpeg codec, which also has the same bug.
However, at this point in time this issue will now have to move to the back burner since resources are currently 100% focused on the upcoming product launches.
OK, but the Microsoft Video Decoder shows the same problem.
In other words, it won't be fixed.
No, the issue reported by the OP has been fixed and confirmed by him as well.
This is LAV's video developer reply:
"The decoder works in accordance to the H264 specification.
If a reference frame is missing, a dummy frame is generated (ie. a blank one) to take its place, so its very well possible that the second frame after a seek already lists 4 references - 3 of those may just be empty dummy frames that are not available due to the seek."