View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000696 | madVR | bug | public | 2023-01-11 06:56 | 2023-01-19 08:51 |
| Reporter | denis_fdrv | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows 11 Home 22H2 | OS Version | 22621.963 |
| Summary | 0000696: The "Report BT.2020 to display (Nvidia only)" setting in Madvr 165 makes NVIDIA driver crash on player closing | ||||
| Description | If the "Report BT.2020 to display (NVIDIA only)" check box is selected, as soon as I close the player (any player with madvr as renderer) or clear the check box while the video has already been started, the screen goes black for 0000001:0000007-10 sec (in the event viewer, I can see that the video driver crashes, and then restores) . This crash is consistent and can be reproduced every time. The driver crash happens in my case only if the following conditions are met: - "Report BT.2020" check box is selected, and you close the player or clear this check box while the video is started/stopped/paused. - When the projector (5050UB) is connected directly to the videocard via HDMI. If it is connected through a soundbar with passthrough, the crash doesn't occur. Also, the crash doesn't occur on a monitor connected via display port. - On madvr version 165. I tried uninstalling/reinstalling madvr, various NVIDIA driver versions, different players, different cables, etc. I've narrowed down the issue to the the "Report BT.2020 to display" setting and madvr 165. | ||||
| Steps To Reproduce | 1. Connect a projector to videocard directly through HDMI 2. In Madvr settings, select the "Report BT.2020 to display (Nvidia only)" check box. 3. Start a video (any). 4. While the video is playing/paused/stopped, either close the player or, in madvr settings, clear the "Report BT.2020 to display (Nvidia only)" check box. As soon as you do this, the crash occurs. If I roll back to 163 or earlier, the crash doesn't occur, though on earlier versions of madvr, madvr doesn't seem to work or have any effect (probably Windows-related). Also tried 164, but with that version, MPC-HC or other player won't launch at all. The issue may also be related to 4xxx series videocards, bacause other people on earlier series don't seem to have this issue. | ||||
| Additional Information | When a crash occurs, there are 4 messages in eventviewer: 3 errors from nvlddmkm (The description for Event ID 0 from source nvlddmkm cannot be found...): 1) Resetting TDR occurred on GPUID:100 2) Reset TDR occurred on GPUID:100 3) Restarting TDR occurred on GPUID:100 Followed by a warning: Display driver nvlddmkm stopped responding and has successfully recovered. | ||||
| Tags | No tags attached. | ||||
| madVR Version | 0.92.17 | ||||
| Media Player (with version info) | MPC-HC 1.9.24.55 (same in PotPlayer) | ||||
| Splitter (with version info) | LAV splitter 0.77.1.2 | ||||
| Decoder (with version info) | LAV Video Decoder 0.77.1.2 | ||||
| Decoding | DXVA2 Copyback | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | yes | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | all modes | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | RTX 4080 | ||||
| GPU Driver Version | 528.02 (+ recent earlier versions) | ||||
|
|
This sounds like a bug in the Nvidia driver. I'm simply calling an Nvidia API to set the BT.2020 flag. I'm not sure what I could do different. It might make sense if you reported this to Nvidia. |
|
|
Ok, thanks. Will try reporting this to Nvidia then. |
|
|
If it helps, you can say that I'm using the API called "NvAPI_Disp_InfoFrameControl" to set the BT.2020 flag. |
|
|
Reported this to Nvidia. They requested some debug info. Will give an update if anything new comes up regarding this issue. |
|
|
Maybe you can post a link to your Nvidia forum post here, to link these 2 threads? Then maybe I can also join there and help (where I can)? |
|
|
I actually reported this through their developer channel. I don't know whether you'll have access: https://developer.nvidia.com/nvidia_bug/3937720 Here is the link where I uploaded memory dump for them if you are interested: https://drive.google.com/drive/folders/1Lac-VN8iF-v-Jj4i4PheLsK3NLFg_bAG?usp=sharing |
|
|
The BSOD that I showed there happens after enabling the TDM debug mode in the registry. |
|
|
TDR* |
|
|
In addition, a reported this in the 528.02 driver feedback forum thread https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/507384/geforce-grd-52802-feedback-thread-released-1523/ However, it is unlikely that they will respond there. |
|
|
I thought I had developer access, but I don't have access to that link, for some reason. Anyway. If there's anything I can help with, just let me know. Thanks for bringing this to Nvidia's attention! |
|
|
You can try creating an account there. That's what I did to be able to submit a ticket. If that doesn't provide you access to the ticket, I'll keep you posted here on this issue. |
|
|
I do have an account there which is unlocked for the Nvidia developer program. But I still can't access your bug report. I think the bug reports may be private and only accessible to the reporter and to Nvidia? But I'm not sure... |
|
|
I see. Probably visible to the reporter only. I'll update this page if anything new comes up. Thank you! |
|
|
There is progress with the issue. After dump file analysis, they asked me to reproduce the issue with only one display connected. And here is what I have found: My setup includes three displays/devices: 1) A monitor (ASUS PG279Q), on which I do not have the issue. Connected via display port. 2) A projector (EPSON 5050UB), on which I have the issue, connected via HDMI to RTX 4080. 3) A soundbar (Samsung HW-Q990B), also connected via HDMI to RTX 4080. The soundbar is detected in Nvidia Control Panel as a display, though it is used for sound output. - Disconnecting the cable of the monitor (ASUS PG279Q) had no effect (the same issue). - Turning off the soundbar but leaving the HDMI cable plugged in had no effect (the same issue). - Disconnecting the cable of the soundbar indeed helped with the issue, but not fully. Without the soundbar plugged in, there is no TDR/driver reset and no BSOD (if the TDR debugging is enabled), and no errors in the event viewer. However, there is another issue that still occurs with the same repro steps: the screen goes black (but for a short period, 1-2 seconds), and then I see the cursor corruption (its edges partially disappear during movement) and it becomes sluggish as if the refresh rate is very low. This corruption can be fixed by, for example, making changes in NCP (refresh rate, color settings) or by changing inputs on the display. Note that this secondary issue with the cursor and sluggishness I also could see initially during the process of TDR reset and driver recovery (sometimes, not every time), and then I think it was fixed after the driver recovery was completed. Now, in the scenario without the driver reset/recovery, this corrupted state is not automatically corrected. For this secondary issue with the cursor, I have found out that it is triggered by the following: if before running a video (with that "Report BT.2020 to Display" setting enabled in madvr), in Nvidia Control Panel the color settings are set to YcbCr422 + color depth 10 bpc, the cursor corruption/sluggishness occurs. If the color settings are set to RGB + color depth 8 bpc before running a video, the cursor corruption/sluggishness doesn't occur. I discovered this because I noticed that during cursor corruption, NCP sometimes displayed RGB mode + empty color depth, even though it was YcbCr422 + color depth 10 bpc before starting a video. I tried to record the screen to show the corruption, but on a screen capture it is not visible well. So, I recorded with a phone camera for you to get an idea how it looks like: https://drive.google.com/drive/folders/12UJdCmryiPjlFauiNAw4iS97Iy5jcmOz?usp=sharing |
|
|
Good stuff, you're doing a really good job providing useful information! Thank you for working through this with Nvidia. I wish all madVR users would be as helpful !! :-) |
|
|
Thank you! :) Doing my best to help. I'm also interested in getting this resolved. |
|
|
I did some further analysis of the reported issues with various settings, and found some additional details that might be useful in resolving this. Also sent this info to Nvidia. Regarding the TDR/driver crash issue: - Having tried various combinations, I have found out that the driver crash occurs when both connected displayed (the 5050UB projector and the one that represents the connected HW-Q990B soundbar) are set in Nvidia Control Panel to 60 Hz, YCbCr422, 10 bit before starting a video with "Report BT2020 to Display" enabled in madvr. - Other combinations (when both displayed are not 60 Hz, or not YCbCr422, etc.) have other issues (like the reported corruption), but not driver crash. - The settings in madvr that can set the display refresh rate and resolution to match the video do not seem to affect this crash (happens with or without those settings). Regarding the "cursor corruption/sluggishness": - This corruption happens when the main display (with or without connected soundbar) is set to 60/59 Hz in NVC YCbCr422, 10 bit before starting a video with "Report BT2020 to Display" enabled in madvr. In this scenario, the projector input info shows that the signal is RGB-video while NCP shows YCbCr422. Also, the projector input info shows refresh rate 11.99 Hz (hence the sluggishness) while in NCP it's 60/59 Hz. - If I set the refresh rate in NCP lower than 59 Hz (e.g. 23, 24, 30...) before starting a video with "Report BT2020 to Display" enabled in madvr, then the refresh rate is not changed on closing the video, however the projector input info still shows that the signal is RGB-video while NCP shows YCbCr422. - I think this change of signal to RGB-video is what causes blinking on closing the video even when the refresh rate and resolution initially coincide with the video. Regarding the BT2020 flag: - When the driver crash happens, I noticed that the BT2020 flag, which is set by the "Report BT2020 to Display" setting in madvr is sometimes not reverted, even after PC reboot or changing various NCP settings. In this case, the projector signal info shown BT2020 regardless of the settings in NCP. To revert this flag, I had to try running another video (with "Report BT2020 to Display" enabled in madvr) to try set/revert this flag. I hope this info will come in handy. Cheers. |
|
|
It seems that the Nvidia driver may be trying to switch to 10bit RGB which is not supported by HDMI 2.0 at 4K60. Maybe that's causing the crash? I'm not sure. On a side note, why are you using YCbCr422? It's usually not recommended for an HTPC. So although Nvidia should really fix this problem and I'd be very happy if you could make that happen, you may already be able to workaround the issue by simply using RGB instead (and the recommended way is to set RGB to Full Range / PC levels). Of course at 4K60 you have to use 8bit RGB, but that's not really an issue, thanks to madVR's excellent dithering algorithms. |
|
|
Oh, thanks for the tip. I always thought YCbCr was the proper way for movies. And I also used YCbCr220 for 4K60 HDR gaming, because that projector supports 10 bit 4k60 only with YCbCr220. I don't mind switching between RGB and YCbCr220 depending on the type of content. Since movies are normally in 23/24 FPS, it's not an issue that HDMI 2.0 RGB doesn't support 10 bit with 4k60; with 23/24 Hz it does. I'm glad that RGB full is the recommended way, as with it, I don't experience any issues described above, though yes, NVIDIA should still fix it anyway. I was also always in doubt whether I configure the settings correctly in the [display] > Calibration settings of madvr: - With "tone map HDR using pixel shaders", for HDR content, I set "the display is calibrated to the following primaries / gamut" to "BT.2020" and select the "report BT.2020 to display" check box. - For SDR content, I set "the display is calibrated to the following primaries / gamut" to "BT.709" and clear the "report BT.2020 to display" check box. Is this the proper combination? And I also read somewhere that SDR content can work OK in the BT.2020 container, so there is no need to switch the settings for it. |
|
|
Movies are natively encoded in 4:2:0, so if our goal was to send the movies untouched to the display, it might make sense to use YCbCr 4:2:0 output in the Nvidia control panel. However, madVR has very high quality image processing algos which are probably better than what any display does, and displays natively work in RGB. So letting madVR upscale chroma from 4:2:0 to 4:4:4 is usually preferred. Furthermore, setting the Nvidia control panel to 4:2:2 output means that the applications (games and madVR) still do their math in RGB, but then the Nvidia driver after the fact converts the madVR/games output to YCbCr 4:2:2 behind the back of madVR/games. That is not really beneficial. It just adds to the amount of conversions that are being done. If you tell madVR that your display is calibrated to BT.2020 (and if that's true) then you can send both SDR and HDR content to the display that way. There's no need to switch. madVR can simply convert SDR content to BT.2020 and send it to the display that way. The only disadvantage may be that if you have a projector which uses a physical filter to achieve wider gamuts, you might lose some light output that way. However, if the games were written to output BT.709 colors, then your display will show widely oversaturated colors. |
|
|
Yes, this is exactly the case, the projector uses a physical filter for wider gamuts. I use a saved set of projector settings for HDR, which also engages the filter, and use a different set of saved settings, which don't use the physical filter, for SDR content. When talking about movies with madr, does it make sense in this scenario to switch the settings in madvr between SDR and HDR, or it is enough to do it in the projector only, and use HDR settings in madvr for both types of content? |
|
|
You could keep both picture modes in the projector set to BT.2020, one using the filter and one not using the filter, but both calibrated to BT.2020. That way, you wouldn't have to switch in madVR. However, as mentioned, the games will look oversaturated this way - unless they support outputting BT.2020 colors. You could add a 3rd mode for games, using no filter and calibrating the projector to BT.709 colors. But if you have such a preset for games, maybe it would be easier to also use it for madVR SDR playback? But then you need to switch colors in madVR, as well, of course. But you can automate that using the profiles with auto-rules. There's also a chance that a calibration to BT.709 might be slightly more accurate than calibrating to BT.2020 when the colors are only BT.709, anyway. But I'm not sure if the accuracy difference would be visible. |
|
|
The difference between two presets in the projector is not only the filter - the one without filter is calibrated for REC 709, the other (with the filter) is calibrated for BT2020. I use them for games as well, depending whether a game supports HDR or not. So, in projector I always switch between two modes, and thus there is no oversaturation in SDR movies/games. I tried setting up auto-presets in madvr, but couldn't figure out how to do it, so I gave up and switch manually (not an problem for me). If you say that calibration of BT.709 to BT.2020 can be less accurate than native BT.709, then I'll probably keep switching in madvr as well between two presets. Though with a naked eye, SDR content looks the same with BT.709 or BT.2020 (+"Report BT.2020 to display") settings in madvr. Thank you for clarification. As for games, I still don't quite get what is the best recommended combination of settings in NCP for HDR games on an HDMI 2.0 display where RGB 4k60 10 bit is not supported. In this case, it is better to stick to RGB 4K60 8 bit or use YCbCr 422 4k60 10 bit with its additional conversion? |
|
|
RGB 4k60 8bit should be fine for games, IMHO. The benefit is that colored GUI overlays should have better edges (if you switch your projector into a mode which supports 4:4:4 chroma) without color fringing. As mentioned, running SDR in madVR with BT.2020 is just fine, but you will lose light due to the filter. That said, light output is more important HDR content, anyway, so for SDR it might not even matter. Auto-switching is easy, just create 2 profiles, and use this very little script to auto switch: if (hdr) "name of your BT.2020 profile" else "name of your BT.709 profile" |
|
|
Thank you for the info and help. The profile switching seems to be working :) |
|
|
Well, I'm motivated to help if you're helping, too... :-) |
|
|
As I've been playing around lately with watching videos with RGB in NCP instead of YCbCr, I've noticed a consistent pattern that adds details to the issue with the "Report BT.2020 to display" setting. Both scenarios were tested in 23 Hz, color depth 10 bit: - If in Nvidia Control Panel, before starting a video with "Report BT2020 to Display" enabled in madvr, output color is set to RGB (10 bit, full), on starting a video, according to signal info in projector, the signal is changed from RGB-video to Composite (=YCbCr), and stays YcbCr after sclosing the video, and then also sticks after starting/closing other videos, until I change refresh rate in NCP. Also, in this scenario, the projector on starting the first video, for some reason cannot handle the switch of signal from RGB to Composite, and shows black screen, menu not accessible, with sound in the background, keyboard working, etc.; I have to switch HDMI input to another one and back to get the image back. The subsequent launches of videos (in the Composite signal), do not have the black screen on start or end. Furthermore, during the signal type switch, the color range also changes to Limited. - If before starting a video with "Report BT2020 to Display" enabled in madvr, output color is set to YCbCr442 (10 bit, limited), it's vise versa: on closing the video (not on start as in scenari 1), the signal, according to projector signal info, changes from Composite (YCbCR) to RGB-video, (BT.2020 not reverted to Rec 709), and stays in RGB until I change refresh rate. In this scenario, the projector manages the signal switch on closing the video (with a short blink). My workaround for all the issues above: I disable the "Report BT.2020 to display" setting, and, for HDR videos, manually set the color space in the projector menu to BT.2020 (even though it reports that it receives Rec 709). This seems to work fine, the image looks correct, there's no signal switch (If it was RGB-video, it remains RGB-video), no messing up with color range, and no black screen on start/close. The only downside is that I have to manually switch the color space for BT.2020 videos, and then manually revert it. As for the Nvidia, they responded that they will analyze the reported behavior with engineers. Fingers crossed it'll be fixed soon. |
|
|
Have you reported this new information to Nvidia? It seems that the driver switches between RGB <-> YCbCr in this situation which it is *not* supposed to do. Unless there's a bug in madVR, but I don't think so. Are you using the official madVR build, or one of the newer test builds from AVSForum? And I hope you have disabled HDR in the OS for your projector? |
|
|
Yes, this info is also sent to Nvidia. They said it's useful and promised to analyze it. I tried both the official and test builds before (when was trying to figure out the cause of the driver crash). Right now I'm not sure which one I have - will check later with both builds. Yes, HDR in OS is never enabled for watching videos; for some games only. |
|
|
Verified again: the signal switching (from RGB to YCbCr and from YCbCr to RGB) happens with both the official and test 165 madvr build. |
|
|
Thanks! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-11 06:56 | denis_fdrv | New Issue | |
| 2023-01-11 08:46 | madshi | Note Added: 0002955 | |
| 2023-01-11 10:19 | denis_fdrv | Note Added: 0002956 | |
| 2023-01-11 10:41 | madshi | Note Added: 0002957 | |
| 2023-01-12 08:31 | denis_fdrv | Note Added: 0002958 | |
| 2023-01-12 09:23 | madshi | Note Added: 0002959 | |
| 2023-01-12 09:23 | madshi | Note Edited: 0002959 | |
| 2023-01-12 09:30 | denis_fdrv | Note Added: 0002960 | |
| 2023-01-12 09:33 | denis_fdrv | Note Added: 0002961 | |
| 2023-01-12 09:34 | denis_fdrv | Note Added: 0002962 | |
| 2023-01-12 09:44 | denis_fdrv | Note Added: 0002963 | |
| 2023-01-12 09:52 | madshi | Note Added: 0002964 | |
| 2023-01-12 10:02 | denis_fdrv | Note Added: 0002965 | |
| 2023-01-12 10:20 | madshi | Note Added: 0002966 | |
| 2023-01-12 10:22 | denis_fdrv | Note Added: 0002967 | |
| 2023-01-13 06:23 | denis_fdrv | Note Added: 0002968 | |
| 2023-01-13 09:20 | madshi | Note Added: 0002969 | |
| 2023-01-13 09:20 | madshi | Note Edited: 0002969 | |
| 2023-01-13 14:01 | denis_fdrv | Note Added: 0002970 | |
| 2023-01-15 11:59 | denis_fdrv | Note Added: 0002971 | |
| 2023-01-15 12:12 | madshi | Note Added: 0002972 | |
| 2023-01-15 13:37 | denis_fdrv | Note Added: 0002973 | |
| 2023-01-15 13:59 | madshi | Note Added: 0002974 | |
| 2023-01-15 14:19 | denis_fdrv | Note Added: 0002975 | |
| 2023-01-15 14:29 | madshi | Note Added: 0002976 | |
| 2023-01-15 14:59 | denis_fdrv | Note Added: 0002977 | |
| 2023-01-15 15:37 | madshi | Note Added: 0002978 | |
| 2023-01-15 15:37 | madshi | Note Edited: 0002978 | |
| 2023-01-15 16:06 | denis_fdrv | Note Added: 0002979 | |
| 2023-01-15 16:13 | madshi | Note Added: 0002980 | |
| 2023-01-18 00:32 | denis_fdrv | Note Added: 0002981 | |
| 2023-01-18 09:52 | madshi | Note Added: 0002982 | |
| 2023-01-18 12:19 | denis_fdrv | Note Added: 0002983 | |
| 2023-01-19 07:14 | denis_fdrv | Note Added: 0002984 | |
| 2023-01-19 08:51 | madshi | Note Added: 0002985 |
