5 Replies Latest reply on Oct 22, 2016 5:33 AM by lester

    RX480 State0-Bug: h.264 playback causes locked core/mem frequency @300mhz and the 100% fan speed bug


      I hope this is the right forum to post this-



      How to reproduce:

      - start a h.264 video file in your media player, make sure to use the "Microsoft DTV-DVD Video Decoder" as video filter.

      - start a YouTube video that uses the h.264/AVC codec



      What is happening:

      - in IDLE mode: The GPU/memory is fixed @ 300/300 mhz (State 0)

      - The memory clock tends to stay @300 more often then without the bug (almost all the time). Only during heavy load the memory speed goes up to 2000mhz, e.g. when textures are loaded in a game. In the game menu the memory tends to stay @300, which was never happening without the bug before.

      - Starting multiple other video streams rises the GPU frequency only by a small amount. Only about 10mhz more with each video.


      - during 3D LOAD: The GPU tends to stay below "State 5" frequency which results in an overall lesser performance. The GPU stays mostly @100% load.

      - only under very heavy load, the GPU switches to state 6/7, while always keeping the GPU load @100% (in some games).


      As long as the video, that is causing the bug is active, the State0-bug remains active. You can just pause the video to keep the bug active, it is not necessary to keep the video playing. (<- this is true for 16.9.2. In 16.7.3 the video have to keep playing. Pausing will disable the bug in 16.7.3 after ~7 seconds)


      It looks like the GPU frequency is more aggressively down clocked while this bug occur.


      Note: The 100% fan speed bug is more likely to be triggered in this bugged state. If you play something else besides the video, it raises the probability to cause the 100% speed fan bug.


      This bug is triggered by playback of AVC videos in a browser (Edge, Chrome, FF) and from any media player that uses the MS filter for h.264/AVC.


      My system: fresh Windows install - Win10 x64 AU, MSI RX 480 Gaming X, FX6300, Driver: 16.9.2, also tested with 16.7.3, 16.8.3, 16.9.1





      This bug happens when a h.264 video is played with the "Microsoft DTV-DVD Video Decoder" filter, that filter is the standard filter for h.264/AVC playback for all Windows OS. I have tried FFDshow & LAVFilter instead of the MS filter and the bug was not triggered with them.



      I first discovered this bug while watching this YouTube Video: https://www.youtube.com/watch?v=6dCn_Mz9MPQ (this video is now re-encoded to VP9 by google and is not causing the bug anymore. see my post below)

      There are 2 kind of video codecs used on YouTube -> Googles VP9 and h.264/AVC.

      Only the h.264 videos do cause the State0-bug if you play it in your Browser. Right click on the video and activate "statistics for nerds" to show which codec is used in the video.


      To reproduce this bug with your media player (I use ZoomPlayer), you have to use the "Microsoft DTV-DVD Video Decoder" filter for video decoding. If you have not installed any codec/filter pack on your system, then this MS filter should be the default filter in "Windows Media Player"


      I don't know for how long this bug exist. If you use an older driver. Please test the videos and check the core/clock frequencies and report back.

      The bug does not occur with the VLC player, probably because it has its own video filters build-in and does not use the MS filter.

      IMHO, It is very unlikely that the problem is the MS Filter. The MS filter just simply uses the hardware acceleration that is provided by the driver & hardware.

      The bug is rather on AMDs side, either the hardware acceleration component on the Polaris chip is defective, or the driver that controls the h.264 acceleration is broken.

      Maybe other video filers are affected by this bug. I could reproduce this only the MS filter. I have only tested LAVFilter with the default values.

      Lets hope for a quick fix for this bug and that it will also resolve the 100% fan speed bug.


      demonstration pics:

      -desktop usage: http://i.imgur.com/Eh9bKSX.jpg

      -3d load, Unigine Valley Benchmark: http://i.imgur.com/A3T7Yj8.jpg

      -100% fan speed bug occurs and causes overheat and pc shut down: http://i.imgur.com/iAVVm6x.jpg


      Edit:  I installed Win10 x64 14393 on a 2nd HDD with literally no other software installed, except the AMD driver 16.7.2, the same bug occurs.




      Edit2: LAVFilter does also cause this bug when i activate the DXVA2 hardware acceleration in the settings.


      Edit 3: This bug is NOT the same as the "energy efficiency" function that you can toggle in the driver settings. The bug is down clocking the frequency much more aggressively! Also i have the feeling that the voltages are stuck at a lower value while this bug occurs, compared to the "energy efficiency" function.




      This bug >may< also be the reason why many Benchmarks where so different for the RX480!?? In the case that someone watched a video stream or a h264 media file on the same computer that did the benchmark, this could lead to the state0 bug and the benchmark results would suffer from this.

      I know its a long shot and it is unlikely that a professional benchmarker would play a video (and pause it) and then start a benchmark, but it is possible.

        • Re: RX480 State0-Bug: h.264 playback causes locked core/mem frequency @300mhz and the 100% fan speed bug

          I've noticed identical problems with Twitch streaming service on a second monitor while using fullscreen 3D (not windowed fullscreen) games on the primary display. The GPU will sit at 300 MHz at 100% load causing unacceptable performance degradation. This is on a Sapphire Nitro RX480 running 16.9.2, I'm unaware of whether or not it was present in earlier drivers, and since I experienced a variety of bugs (random black screens etc) with earlier drivers I feel disinclined to reinstall to double check.


          Since Game on one screen and Stream/Video on second monitor is an extremely common setup this seems like a pretty significant bug.

          • Re: RX480 State0-Bug: h.264 playback causes locked core/mem frequency @300mhz and the 100% fan speed bug

            I've got a 4gig model and I got a second monitor connected which forces my gpu on a 24/7 high memory clock (which I find odd). What I've find is that Edge, New html5 players from twitch are not increasing the gpu clock which is causing terrible lag. I can't watch anything at the moment when my monitor is set at 120 or 144hz, when I set my monitor to 60 hz this issue isn't present. I also got the fan bug, and the black screen crashing.

            • Re: RX480 State0-Bug: h.264 playback causes locked core/mem frequency @300mhz and the 100% fan speed bug

              Hi All,


              I too have the same issue (h.264/fan bug), I have the Sapphire Nitro+ Rx480 8gb. Here's what I have done while waiting for AMD to fix their drivers.


              Downloaded both the 16.10.2 and 16.7.2

              Extracted the 16.7.2 drivers and here's a list of driver files which I guess have something to do with h.264 playback/hardware acceleration (some files i don't know their exact function but others are self explanatory).














              amdhcp32.dll <Universal adapter for Adobe - this could be for hw acceleration for flash>



              Extracted the 16.10.2 drivers and overwrote the files with  files mentioned on the list.


              Installed the modified 16.10.2 normally and its kinda working for me, i can have hw acceleration ON on the browser and adobe flash and no crash yet that i can notice. Here's the software i'm using for testing.


              Windows 10 x64

              Sapphire TriXX 3.0 (6.1.0)

              Palemoon browser (firefox clone)

              Adobe Flash v18_382

              CoreCodec CoreAVC v3 (really nice codec)

              Splash Pro v1.13.2 (there's already a version 2 and its free but it has ads)


              I tried the youtube video posted above on Internet Explorer and GPU coreclock did not fluctuate.