madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000471madVRbugpublic2017-02-23 16:202017-07-04 23:29
Reporterdamien147 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSWindowsOS VersionWindows 10 64bit
Summary0000471: Black screen with DXVA2(native) and AMD GPU playing 10bit HEVC.
DescriptionWith AMD card when playing 10bit HEVC if you set decoder to DXVA2(native) you get as a result black screen.
EVR(custom presenter) has no black screen and plays file fine with same circumstances.
Steps To ReproduceHaving an AMD GPU set hardware decoder to DXVA2(native) and play 10bit HEVC.The result is black screen.
Additional InformationTwo more AMD users in doom9.org forum reproduced the black screen.
TagsNo tags attached.
madVR Versionv0.91.5
Media Player (with version info)mpc-hc(64 bit) 1.7.10
Splitter (with version info)Lav Splitter 0.69
Decoder (with version info)Lav Video Decoder 0.69
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modeall modes
GPU ManufacturerAMD
GPU ModelRX470 4GB
GPU Driver Version17.2.1
Attached Files

- Relationships

-  Notes
(0001593)
direx (reporter)
2017-03-10 21:33

I can confirm this issue.

Card: RX480 8GB
Driver version: 17.3.1
MadVR: v0.91.7
Player: MPC-BE 1.5.1 (tried both x64 and i386 versions)

Only 10-bit HEVC is affected, 8-bit HEVC plays back fine with MadVR.

10-bit HEVC is handled correctly without MadVR (e.g. with native MPC-BE renderer).
(0001628)
Firelight (reporter)
2017-04-13 06:22
edited on: 2017-04-14 14:22

Tested with the EVR-CP video renderer. 10-bit Integer and 32-bit Floating Point surface formats doesn't work but the other surface formats do. Turning off the DXVA video decoders and relying on software does NOT fix the EVR-CP video renderer with the above formats.

GPU: RX480
GPU Driver: 17.4.2
Player: MPC-BE x64 1.5.1 (build 2332) beta

Maybe the issue is a combination of a polaris architecture GPU along with v17 drivers causing this?

Edit: Tested the EVR-CP more thoroughly with the stats on.

Black screens with the following format:
| Input: P010
| Mixer: X8R8G8B8
| VideoBuffer: A2R10G10B10
| Surface: A2R10G10B10
| Backbuffer/Display: X8R8G8B8
Using DXVA2 Native

Works with the following formats:

| Input: P010
| Mixer: X8R8G8B8
| VideoBuffer: X8R8G8B8
| Surface: X8R8G8B8
| Backbuffer/Display: X8R8G8B8
Using DXVA2 Native

| Input: NV12
| Mixer: NV12
| VideoBuffer: A2R10G10B10
| Surface: A2R10G10B10
| Backbuffer/Display: X8R8G8B8
Using DXVA2 Copy-Back

Will test an R9 280x GPU with driver 17.4.2 soon.

(0001629)
damien147 (reporter)
2017-04-15 18:45

Problem seems to be RX4x0 specific but I can't edit my report.
(0001630)
Firelight (reporter)
2017-04-17 03:11

Well crap. R9 280X can only output NV12 for DXVA2 decoding. That means I can't use it to decode 10-bit videos. Also interesting, I can't get the EVR-CP renderer to accept anything but NV12 on my computer with the R9 280X. Regardless, I've still performed some testing.

Using EVR-CP video renderer

- H.264 8-bit video
  - Test 1 Result: Works
    - Decoder: DXVA2 Native
    - EVR-CP Surface Format Setting: 10-bit Integer
    - Input Format: NV12
    - Mixer Format: NV12
    - VideoBuffer Format: A2R10G10B10
    - Surface Format: A2R10G10B10
  - Test 2 Result: Works
    - Decoder: DXVA2 Native
    - EVR-CP Surface Format Setting: 8-bit Integer
    - Input Format: NV12
    - Mixer Format: X8R8G8B8
    - VideoBuffer Format: X8R8G8B8
    - Surface Format: X8R8G8B8

Using madVR

- H.265 10-bit video
  - Test 3 Result: Works
    - Decoder: Software (avcodec)
    - Input Format: P010
(0001631)
Firelight (reporter)
2017-04-17 05:17

And more tests on the RX480.

Using MPC-BE (64-bit) 1.5.1 (build 2491) beta
Using LAV Video Decoder 0.69.0
Using EVR-CP video renderer

Using H.264 8-bit video

Test 1 Result: Works
  - Decoder Processing: DXVA2 Native
  - EVR-CP DXVA Status: DXVA2 H.264 E, bitstream decoder, no FGT
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 2 Result: Works
  - Decoder Processing: DXVA2 Native
  - EVR-CP DXVA Status: DXVA2 H.264 E, bitstream decoder, no FGT
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

And I've retested some things using the same format for comparison.

Using H.265 10-bit video

Test 3 Result: Works
  - Decoder Processing: DXVA2 Native
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 4 Result: Black Screen
  - Decoder Processing: DXVA2 Native
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

Test 5 Result: Works
  - Decoder Processing: DXVA2 Native
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 16-bit Floating Point
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: A16B10G16R16F
  - Surface Format: A16B10G16R16F

Test 6 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 7 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

Test 8 Result: Works
  - Decoder Processing: Software (avcodec)
  - EVR-CP DXVA Status: Not using DXVA
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 9 Result: Works
  - Decoder Processing: Software (avcodec)
  - EVR-CP DXVA Status: Not using DXVA
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: NV12
  - Mixer Format: NV12
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

Interesting results here.

Using MPC Video Decoder

Test 10 Result: Works
  - Decoder Processing: Unknown
  - EVR-CP DXVA Status: Not using DXVA
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 11 Result: Black Screen
  - Decoder Processing: Unknown
  - EVR-CP DXVA Status: Not using DXVA
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

Test 12 Result: Works
  - Decoder Processing: Unknown
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 8-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: X8R8G8B8
  - Surface Format: X8R8G8B8

Test 13 Result: Black Screen
  - Decoder Processing: Unknown
  - EVR-CP DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - EVR-CP Surface Format Setting: 10-bit Integer
  - Input Format: P010
  - Mixer Format: X8R8G8B8
  - VideoBuffer Format: A2R10G10B10
  - Surface Format: A2R10G10B10

I can't test if the combination of the P010 Input format and the A2R10G10B10 VideoBuffer/Surface format is causing the issue since I can't force the EVR-CP renderer to accept P010 unless the video decoder is using DXVA2 Native processing.

Using LAV Video Decoder 0.69.0
Using Video Mixing Renderer 9 (Windowed Operation Mode)

Test 14 Result: Works
  - Decoder Processing: DXVA2 Native
  - VMR Mixer Mode: On
  - YUV Mixing: On
  - Input Format: NV12

Test 15 Result: Black Screen
  - Decoder Processing: DXVA2 Native
  - VMR Mixer Mode: On
  - YUV Mixing: Off
  - Input Format: P010

Test 16 Result: Black Screen
  - Decoder Processing: DXVA2 Native
  - VMR Mixer Mode: Off
  - YUV Mixing: N/A
  - Input Format: P010

Test 17 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - VMR Mixer Mode: Off
  - YUV Mixing: N/A
  - Input Format: NV12

Test 18 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - VMR Mixer Mode: On
  - YUV Mixing: Off
  - Input Format: NV12

Very Interesting.

Using Sync Video Renderer

Test 19 Result: Works
  - Decoder Processing: DXVA2 Native
  - SVR DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - Input Format: P010
  - Mixer Format: RGB32

Test 20 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - SVR DXVA Status: DXVA2 H.265, bitstream decoder, Main10
  - Input Format: NV12
  - Mixer Format: NV12

Using Haali Video Renderer

Test 21 Result: Works
  - Decoder Processing: DXVA2 Native
  - Input Format: YUY2

Test 21 Result: Works
  - Decoder Processing: DXVA2 Copy-Back
  - Input Format: YUY2
(0001672)
denali (reporter)
2017-06-24 19:10
edited on: 2017-06-25 10:13

Same here.
GPU: RX460 (4Gb)
CPU: Xeon3450
Madvr: 0.91.10
LAV: 0.70.0
mpc-hd: 1.7.11
Using H.264 8-bit video
- works nice with madvr
Using H.264 10-bit video
- black screen with madvr
- active decoder: dxva2n
- works nice with evr renderer (cpu 5-6%) but with washed out colors

(0001673)
madshi (administrator)
2017-06-24 22:03

There will be an improvement with the next build: Instead of a black screen, we'll get a proper luma channel. But the chroma channels are empty, resulting in a totally green tinted image. This appears to be an AMD driver bug.

You'll continue to have to use DXVA copyback for now.
(0001674)
denali (reporter)
2017-06-25 10:14

Thank you for replay! DXVA copyback is unusable, is there any other way to map hdr info properly without benefits of madvr scalers and still use dxva native?
(0001675)
madshi (administrator)
2017-06-25 10:16

Why is it unusable? It works for me, using RX560. For 24fps content, anyway. Probably 60fps will be problematic, though.
(0001676)
denali (reporter)
2017-06-25 11:33
edited on: 2017-06-25 11:36

With DXVA copyback (dxva2cb direct) and madvr colors are correct, otherwise it is slideshow with most frames dropped. Cpu 5-6%.
With DXVA copyback (dxva2cb direct) and EVR renderer it is better but still unusable - achieved framerate ~18fps (with 23,98fps content) + incorrect hdr mapping
EVR + dxva native = fluent + incorrect hdr mapping

(0001677)
madshi (administrator)
2017-06-25 12:36

It works fine for me. Maybe your PCIe bus is too slow? Do you have PCIe 3.0? Which queue (from top to bottom) is the first one empty in the OSD?
(0001678)
denali (reporter)
2017-06-25 12:50

PCIe is 2.0 (GA-P55-USB3). I have no idea about how to use OSD, I'm sorry. Still, how dxva native + evr is working fluently? Also 8-bit HEVC works without problem with native + madvr. Does this hdr mapping takes so much cpu power?
(0001679)
madshi (administrator)
2017-06-25 13:25

I can't answer your questions if you don't answer mine first. The OSD can be enabled by pressing Ctrl+J. It's key information to know which queues are filled and which are empty.
(0001680)
denali (reporter)
2017-06-25 13:33

OSD gives me red text arranged in order of:
-frame rate
-settings
-formats
- etc
- mixer output
Which one tells me about queue? Sorry for ignorance!
(0001681)
madshi (administrator)
2017-06-25 13:35

That sounds like EVR OSD? I'd suggest you make a screenshot of the madVR OSD when getting stuttering playback using DXVA copyback, and then upload the photo to some image host for me to look at.
(0001682)
denali (reporter)
2017-06-25 13:55
edited on: 2017-06-25 13:56

You are correct, thanks for patience!
Here are the links:
https://ibb.co/d6xvJQ [^]
https://ibb.co/dDuaJQ [^]
First is with copyback, second - native.

(0001683)
madshi (administrator)
2017-06-25 14:00

In both cases the "decoder" and "upload" queues are reasonably filled. So decoding is *not* the problem!! The first queue from top to bottom which is in trouble is the "render" queue. Which means your madVR settings are too demanding for your GPU.

What kind of GPU do you have? It seems to be rather slow?

Try setting the madV HDR settings to "passthrough". Does the video play smoothly then? Of course you'll be missing the HDR -> SDR conversion that way.
(0001684)
denali (reporter)
2017-06-25 14:39

OSD with hdr passthrough:
https://ibb.co/gWQkk5 [^]
https://ibb.co/gjG2Xk [^]
First is with copyback, second - native.
(0001685)
madshi (administrator)
2017-06-25 14:43

Strange. This time the decoder queue is empty, too!

Anyway, please try setting chroma upscaling and image downscaling to "Bilinear". Furthermore, in "trade quality" activate "scale chroma separately, if it saves performance". How does it look like then?

(You don't need to make screenshots for native DXVA.)
(0001686)
denali (reporter)
2017-06-25 15:04
edited on: 2017-06-25 15:04

This time it slightly less slideshow:
https://ibb.co/jccnyQ [^]
GPU is radeon rx460 4Gb

(0001687)
madshi (administrator)
2017-06-25 18:48

Do you have any funny options active in madVR? E.g. debanding or sharpening, or anything else?

One thing you could try is in the LAV Video Decoder settings uncheck everything higher than 8bit. That will force LAV to downconvert the video to 8bit before sending it to madVR. It's not a good configuration, but testing that will give us some more information.
(0001688)
denali (reporter)
2017-06-25 19:03
edited on: 2017-06-25 19:09

Uncecked in the LAV Video Decoder settings everything higher than 8bit. No demanding settings in madVR. Still same.
Could Win7Sp1 could be the culprit?
https://ibb.co/mFYG8Q [^]

(0001689)
madshi (administrator)
2017-06-25 19:11
edited on: 2017-06-25 19:12

Hmmm... It seems to be a decoder problem, after all. Can you make another screenshot with the same madVR settings, but this time using native DXVA decoding?

(0001690)
denali (reporter)
2017-06-25 19:22

Native+8bitLAV+bilinear:
https://ibb.co/dXNev5 [^]
(0001691)
madshi (administrator)
2017-06-25 20:18

All right. So considering all the information, the bottleneck for you seems to be the PCIe transfers when using DXVA copyback. The very first screenshot seemed to suggest otherwise, but it must have been a fluke.

One thing you could try is check BIOS settings of your mainboard or even try a BIOS update. I remember that there was one user in the past for whom that helped. However, PCIe 2.0 is of course slower than 3.0, so maybe PCIe 2.0 is simply not fast enough. Can't really say for sure. All I can say is that my PCIe 3.0 PC has no problems with 4Kp24 DXVA copyback, using an RX560.
(0001692)
denali (reporter)
2017-06-25 20:24

Thank you for your kind assistance!
(0001693)
denali (reporter)
2017-06-26 22:23

Still, could it be GPU issue? Here are screens with dxva copyback and gpu load:
https://ibb.co/dd6wtQ [^]
https://ibb.co/fojhYQ [^]
Gpu load is most of the time 100%, memory stays at 300MHz, is it normal?
With games performance difference with PCIe 2.0 and 3.0 is small, maybe rx 460 is just not powerful enough?
(0001694)
madshi (administrator)
2017-06-26 22:47

RX460 should be powerful enough, at least with everything set to Bilinear etc. Not sure why it's running at 100%, though. What's the normal memory frequency? 300MHz or more? You could try a GPU tweaker tool to force the GPU to max frequencies, but I don't think it will make a difference.
(0001695)
denali (reporter)
2017-06-26 23:02

Rx460 Memory clock - 1750 MHz.
(0001696)
madshi (administrator)
2017-06-27 00:38

Well, in that case you might be on to something. Try forcing the clocks to max somehow.
(0001697)
denali (reporter)
2017-06-27 19:16
edited on: 2017-06-27 19:31

Rx460 memory clock stuck at 300MHz appears to be common bug of wattman that is incorporated into amd driver suite. Forcing it to 1750MHz did not help though. Reportedly uefi bios (mine is legacy) is needed for correct functioning of rx460, may be motherboard change is in order. Before that I'd like to try rx480/580 to see if it helps.
How come dxva-native is so effective compared to copyback?
Here is example with 8-bit hevc:
- native, plays fluently with 30% gpu load https://ibb.co/cpQCYQ [^]
- copyback, basically still picture https://ibb.co/hsmx05 [^]
It is also interesting that dropped frames count does not correlate to visually freezed clip with copyback.

(0001698)
madshi (administrator)
2017-06-27 19:34

I think a PCIe 3.0 mainboard might be useful, to make DXVA copy back work as well as possible. I doubt that an RX580 will make a difference.
(0001701)
denali (reporter)
2017-07-04 21:52

Workaround for unfortunate rx460 owners for 10bit 4K hevc seems to be MPC-BE for now. Their own decoder knows how connect to dxva-native with evr custom. It is also possible to chose Lanzos3 as resizer. HDR color mapping is also ok (no washed out colors).
Switching from evr to madvr results in black screen as with MPC-HD.
https://ibb.co/exAX7v [^]
This result seems to confirm that it is more decoder than hardware issue.
Related result with weaker nvidia card than rx460:
http://forum.doom9.net/showthread.php?s=2b953a287937ffeb5da122b8f2644f9f&p=1810727#post1810727 [^]
(0001703)
madshi (administrator)
2017-07-04 23:29

Already there! :-)

- Issue History
Date Modified Username Field Change
2017-02-23 16:20 damien147 New Issue
2017-03-10 21:33 direx Note Added: 0001593
2017-04-13 06:22 Firelight Note Added: 0001628
2017-04-13 07:12 Firelight Note Edited: 0001628 View Revisions
2017-04-14 14:19 Firelight Note Edited: 0001628 View Revisions
2017-04-14 14:19 Firelight Note Edited: 0001628 View Revisions
2017-04-14 14:22 Firelight Note Edited: 0001628 View Revisions
2017-04-15 18:45 damien147 Note Added: 0001629
2017-04-17 03:11 Firelight Note Added: 0001630
2017-04-17 05:17 Firelight Note Added: 0001631
2017-06-24 19:10 denali Note Added: 0001672
2017-06-24 19:10 denali Note Edited: 0001672 View Revisions
2017-06-24 22:03 madshi Note Added: 0001673
2017-06-25 09:57 denali Note Edited: 0001672 View Revisions
2017-06-25 10:13 denali Note Edited: 0001672 View Revisions
2017-06-25 10:13 denali Note Edited: 0001672 View Revisions
2017-06-25 10:14 denali Note Added: 0001674
2017-06-25 10:16 madshi Note Added: 0001675
2017-06-25 11:33 denali Note Added: 0001676
2017-06-25 11:33 denali Note Edited: 0001676 View Revisions
2017-06-25 11:33 denali Note Edited: 0001676 View Revisions
2017-06-25 11:35 denali Note Edited: 0001676 View Revisions
2017-06-25 11:36 denali Note Edited: 0001676 View Revisions
2017-06-25 12:36 madshi Note Added: 0001677
2017-06-25 12:50 denali Note Added: 0001678
2017-06-25 13:25 madshi Note Added: 0001679
2017-06-25 13:33 denali Note Added: 0001680
2017-06-25 13:35 madshi Note Added: 0001681
2017-06-25 13:55 denali Note Added: 0001682
2017-06-25 13:56 denali Note Edited: 0001682 View Revisions
2017-06-25 14:00 madshi Note Added: 0001683
2017-06-25 14:39 denali Note Added: 0001684
2017-06-25 14:43 madshi Note Added: 0001685
2017-06-25 15:04 denali Note Added: 0001686
2017-06-25 15:04 denali Note Edited: 0001686 View Revisions
2017-06-25 18:48 madshi Note Added: 0001687
2017-06-25 19:03 denali Note Added: 0001688
2017-06-25 19:09 denali Note Edited: 0001688 View Revisions
2017-06-25 19:11 madshi Note Added: 0001689
2017-06-25 19:11 madshi Note Edited: 0001689 View Revisions
2017-06-25 19:12 madshi Note Edited: 0001689 View Revisions
2017-06-25 19:22 denali Note Added: 0001690
2017-06-25 20:18 madshi Note Added: 0001691
2017-06-25 20:24 denali Note Added: 0001692
2017-06-26 22:23 denali Note Added: 0001693
2017-06-26 22:47 madshi Note Added: 0001694
2017-06-26 23:02 denali Note Added: 0001695
2017-06-27 00:38 madshi Note Added: 0001696
2017-06-27 19:16 denali Note Added: 0001697
2017-06-27 19:28 denali Note Edited: 0001697 View Revisions
2017-06-27 19:31 denali Note Edited: 0001697 View Revisions
2017-06-27 19:34 madshi Note Added: 0001698
2017-07-04 21:52 denali Note Added: 0001701
2017-07-04 23:29 madshi Note Added: 0001703


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker