Graphics Cards

[jlamazon]

Hi,

I think there is a problem with AMD drivers for 5700G GPU:

when I watch a x264 movie encoded with some "high" bitrate (about 10Mb/s), I experience freezes from time to time. Video just stops for a couple of seconds and resumes.

This is happening with VLC or Media Player Classic players when using GPU to decode. Using CPU, it just works fine.

I tried the same test on Ubuntu 20.04 with VLC: no freeze at all using either CPU or GPU.

So I believe there is a bug on Ryzen 5700G x264 video decoding driver for Windows 10.

I tried some parameter changes AMD Software: Adrenalin 22.4.2 or previous one, no changes.

Can you please help?

Thanks,

Jean

[fsadough]

Here is the link again:
https://we.tl/t-icJzXY7i22

[MADZyren]

Removed content after a while, but can put it back if needed.

[MADZyren]

Was that what you were looking for?

[fsadough]

Can you please provide an AMDZ Report?

AMDZ Report
- Please extract the amdz-v319.zip available from https://we.tl/t-lg0ggkF944
- Run amdz.exe file as an Administrator
- Select “Save All“ and “TXT“ as the output format
- Click on the blue button to save the report
- The .txt file will be saved in the same folder where you extracted the zipped file

[jlamazon]

Hi fsadough,

here is the screenshot for rjedi.webm:

Looks it's the very same.

HTH,

Jean

[fsadough]

I have escalated the problem to our Video team.

[jlamazon]

Thanks fsadough,

First, happy new year and thank you again for your support!

Hope they'll come back with some workaround or open a bug ticket.

Cheers,

Jean

[fsadough]

Happy New Year Jean,
A ticket is already filed and they will test it at their end and let me know.

[fsadough]

The problem has been tested by our Video team and it turns out the problem is related to the clip. Even using a discrete GPU (Radeon Pro WX 4100) shows the same video freeze on exact same locations. Please check your clip.

[jlamazon]

Hi fsadough,

thanks for coming back to me.

That's my point: every AMD GPU (did not know for discrete but you confirmed it)  fails to render.

Please use a non AMD GPU or any CPU (AMD or Intel) and you'll see that this clip is rendered nicely.

So that can't be an issue with the clip but with the Radeon (discrete or not) chips/drivers.

Cheers,

Jean

[fsadough]

Hi Jean,

Let me check the clip using non-AMD GPU and get back to you.

[fsadough]

Hi Jean,

Please be specific to the scenarios you had tested. You wrote:
"Please use a non AMD GPU or any CPU (AMD or Intel) and you'll see that this clip is rendered nicely."

I just tried an Nvidia GPU on the same motherboard and APU (Ryzen 5650G) and the clip is stuttering. I have tested the clip on the following systems with the same stuttering results:

• Lenovo P620 with Threadripper + upcoming Navi3x GPU 
• Threadripper + Radeon W5700
• Ryzen 5650G + Radeon WX 4100
• Ryzen 5650G + Nvidia P2200

So, let me know what non-AMD GPU on which motherboard / OS and CPU you have tested.

[jlamazon]

Hi fsadough,

I have tested rjedi.mkv successfully on these configurations:

Laptop MSI GF65 Thin 9SE using to decode:

- Intel core i7-9750h cpu

- uhd graphics 630 (GPU of i7)

- Geforce RTX 2060 (using this trick to force VLC to choose RTX)

Using my PC with 5700G:

- 5700G CPU

When you tested with Ryzen 5650G+Nvidia P2200, did you use the same trick ? Because if you are using VLC it picks the 5650G integrated graphics to H/W decode by default.

Hope that helps,

Jean

[jlamazon]

Hi fsadough,

any update? Were you able to test using CPU only or another non AMD GPU?

Cheers,

Jean

[fsadough]

Our multimedia team is investigating the issue. Please stand by.

[fsadough]

We have a fix and I tried it. Although we see some spikes in Video Codec but the clip plays much smoother with no stuttering. Waiting for the fix to be implemented into our future driver release. Won't be in the next driver release in 10 days though. 

[jlamazon]

Hi fsadough,

great news! Can't wait for new release but will wait anyways

Can you share any detail regarding the fix? J uust curious.

Cheers,

Jean

[fsadough]

We needed to tweak the VCN, that's all I can tell.

[fsadough]

We have identified the root cause along with a workaround. Please stand by.

[fsadough]

We have analyzed the two video clips that you provided, analyzer reported couple of hundred issues that does not comply with the H264 standard, including first Access Unit of the coded sequence is not an IDR. These issues might cause VLC parsing the video differently compared to Media Player.  Can we get more information about the source of these video clips? Are they coming from any video streaming services?

[MADZyren]

End result with my 7950X:

- Removed FFMPEG or whatever that was
- Went to edge://flags/ in Edge browser and chose OpenGL to "Angle Graphic Backend"
- Disabled hardware acceleration whenever possible from every and all software. 

This enables me to watch videos without crashes.

[fsadough]

I can't replicate this on 5000 series APUs, I need to obtain a 7000 series APU and run the test.

[fsadough]

I wish you would have created a new thread for your issue. I am unable to find your original message describing the problem. 

[jlamazon]

Hi fsadough,

I encoded these videos long ago using i think handbrake. Note that on my pc, it dosen't matter If i use vlc or média player, same result: freezes only with gpu.

What is the workaround you mentioned?

[fsadough]

The clips do not comply with the H264 standards. The workaround most likely won't work on your clips due to other issues mentioned in my previous message. 

[jlamazon]

Hi fsadough,

OK so to make it short, my videos have some issues on some Access Unit of the coded sequence not being an IDR. These issues are properly managed by software decoder/non AMD GPU but AMD GPU codec is possibly more strict on this and that leads to freezes during AMD GPU decoding.

OK, I would have preferred a workaround or some fix in AMD driver if it was possible but that's life.

Thanks for your investigations anyway, at least there is an explanation now.

Cheers,

Jean

[jlamazon]

Hi fsdough,

about these x264 errors, I switched on VLC messages at debut level for GPU and CPU decoding (see GPU message output and CPU message output).

After parsing file to get information and prepare resources, when video is rendered, VLC outputs these warning/debug messages only for GPU decoding:

main warning: picture is too late to be displayed (missing 86 ms)
main warning: picture is too late to be displayed (missing 44 ms)
main debug: picture might be displayed late (missing 2 ms)
main warning: picture is too late to be displayed (missing 133 ms)

But VLC does not report any x264 error in the video itself, which, I guess should be the case in CPU or GPU decoding.

This is confirmed by ffmpeg using command line:

ffmpeg -v error -i rjedi.mkv -f null -
[h264 @ 00000225182fd100] mmco: unref short failure

According to VLC output during GPU decoding, my understanding is more like GPU takes too long to decode, which would explain the high GPU counter "video Codec 0" shown by task manager.

What tool do you use to check x264 file consistency?

Cheers,

Jean

[fsadough]

Try any of the .mkv files from the ffmpeg link below. On my system all play smooth. I sent over your clip to our multimedia team and they checked it. It does not comply with H264 standard.
https://samples.ffmpeg.org/4khdr/

[jlamazon]

They play smoothly on my PC as well using 5700G GPU, because they don't have same x264 profile as my videos.

I understand that my videos are using a specific, probably rare x264 profile. What I'm not convinced of is whether or not they fail x264 standard as:

- Every CPU and every GPU but AMD is able to decode them smoothly

- ffmpeg only reports one default in the stream, this can't explain long freezes of several seconds

- When freezing, AMD GPU counter "Video Codec 0" goes to 100%, so it tries, it does not just fail because data is inconsistent

So I'm more thinking about rare x264 options that work on any CPU/GPU but AMD GPU maybe either a little bit too strict or not considering this x264 option.

That's why I would be interested in what errors are reported by the tool used by AMD multimedia team when they say it does not comply with x264 standard.

Don't get me wrong, I'm trying to understand; if my video are not compling with x264 standard I'm fine with that. But I still have doubt that this may also hide some too strict/not properly handled AMD GPU decoding as only AMD GPU is failing to decode.

Thanks,

Jean

[fsadough]

You wrote:

- Every CPU and every GPU but AMD is able to decode them smoothly

This is not true. Please review my post. I tried Nvidia Quadro P2200 on the same Ryzen system, OS and VLC Player and both your clips stutter. 

Your clips are playing just fine using DivXPlayer, 5KPlayer, KMPlayer. Why are you insisting on VLC Player? 

Your clips are not properly ripped and you have bad/missing frames as per our analysis. The tool we are using is an internal tool. 

[jlamazon]

Hi fsadough,

If you are using a Nvidia graphic card together with an AMD CPU including a GPU, as I mentionned previously, if you are not using this trick, chances are that your player is using AMD GPU to decode, so clip stutters.

I used VLC to check errors in the video x264 format it self and as reported in a previous post, there is no error pointed out by VLC on video itself, just GPU is late to decode.

I already tried KMPlayer, same outcome when AMD GPU is used: clip stutters.

I tried K5Player, smooth rendering and then I went to hardware acceleration settings (sorry french):

K5 settings 1st start

So GPU is not used, when I checked DXVA or AMD H264 decoder, clip stutters.

I tried DivPlayer, this one is interesting as using CPU or 5700G GPU, it decodes smoothly (and I checked it uses 5700G GPU as "Video Codec 0" shows activity with no high usage as when it stutters:

5700G acitivity with DivXPlayer

So maybe, divXPlayer is using 5700G hardware x264 codec in a different way. This is the only player (I tried about 10) to decode smoothly my clips with a 5700G GPU.

To me, there is something wrong at 5700G GPU x264 decoding, I'm more betting on a x264 standard mis-interpretation or rare x264 option not properly managed by AMD, else why every CPU would be able to decode smoothly?

I used ffmpeg to check against video errors, it does not detect bad/missing frames, but just one "mmco: unref short failure" which can't explain long freeze periods during rendering.

The AMD internal tool is maybe making the same mis-interpretation/rare option handling as the AMD decoder? Else why other tools checking against error do not report such bad/missing frames?

Cheers,

Jean

[fsadough]

You are right, your clips stutter with 5KPlayer with HW Accel enabled. But only yours and not the ones from the link I provided.

Do you have the original material and can you rip the clip again? I am still waiting for the workaround from our MM team and see if it works on VLC.

[jlamazon]

Unfortunatly it would be very difficult to rip it again as I don't remember at all the x264 settings I used in a very old version of handbrake.

These settings are messing up x264 decoding on AMD GPU, curious but very interesting is that divXPlater manages to drive AMD GPU x264 decoding in such a way it is smooth. Maybe a hint?

What kind of workaround MM team is thinking of?

[fsadough]

DivXPlayer coverts the codec of the clip to it's own codec, that's why. No comment to workaround by MM team.

[jlamazon]

OK, so if I understand correctly, DivXPlayer gets the stream, decodes it with CPU (if it was with GPU we would experience freezes), re-encodes it with either CPU or GPU, and then decodes it with GPU. As the x264 stream has differents encoding settings, AMD GPU renders it smoothly.

Just a remark but possibly not significant/realiable: when I look at CPU/GPU figures, here it what I see:

- Almost no CPU activity when DiXPlayer decodes using GPU, but GPU 'video codec 0' at about 10%

- Some activity (<10%) when using CPU, GPU 'video codec 0' at 0%

So if GPU decodes the stream, decodes and/or re-encodes with CPU, I think I should see more activity on CPU when GPU is used to decode as CPU at least decodes the original stream. But yeah, CPU/GPU are so powerful nowadays it could also be just a wrong readings on my side.

Anyway, if you want me to install any tool on my PC that could help investigate, I'll be happy to help.

Cheers and again thanks for your continuous support,

Jean

[jlamazon]

Hi fsadough,

as they were a couple of updates since you mentionned that this issue has been fixed, I tried Adrenalin 23.4.1 but I still experience the issue.

Any idea what version will include the fix of interest?

Cheers,

jean

[fsadough]

Please stand by, I am looking into it.

[jlamazon]

Hi again fsadough,

Any chance this fix is included in 23.4.2?

Cheers, Jean

[fsadough]

We still need to port the fix for other VCN versions. Won't make it to 23.4.2

[fsadough]

The plan is to have the fix in 23.10 driver. That would be 23.Q2 driver