|
Notes |
(0003048)
EternalStudent07
2023-06-10 12:11
|
I agree this area is broken. For me, I think combining SVP4 (that wants to change the video to match the current screen refresh rate) and madVR's custom modes is partially the problem.
I've never managed to trigger a mode change from madVR, other than when editing or testing modes on the custom tab. No matter how I tried to adjust my player (MPC-HC x64) or display method (windowed or full screen or attempting exclusive full screen), nor "display modes" tab options I changed.
I'd initially added custom modes for any frequency I thought might be useful. Then listed many of those modes manually. And tried to trigger mode changes at playback time. Never happened.
Also with long display modes lists I think a long string of text is a bad experience for the user (it's a hack to allow export/import, right?). Meaning why isn't there just a check box next to each custom mode that you enable/disable with instead? Then they just add any mode they want to allow to the list, and enable it.
That's all on top of the confusing and annoying "optimize" process. That I can't edit the current mode, and that if I change a setting for X hz, test it fine, then save it... I often end up with an "active" mode that's X-1 or X+1. I realize it's rounding and I'm guessing Windows cared about those values once. Now it just lists refresh rates down to 3 decimal places like "74.860 Hz"
Maybe the NVIDIA API is the issue there instead? Either way... You should hide the confusion from users. I doubt that is a new issue, but I wanted to explain more of my annoyance with this area (beyond just it never seems to activate or do anything).
In case my environment matters... Acer BE270U using DP cable 1440p@75hz native screen, NVIDIA 1080 ti x 2 (currently... the 2nd card doesn't do much for me though so I've run with 1 before and saw the same results), latest Windows 10 x64 + NVIDIA gaming drivers + SVP4 + "AviSynth+" + AviSynthFilter (not ffdshow) + "old cuda" hwdec mode in LAV Filters. Intel i7-4790k at stock, 32GB RAM, z97 motherboard.
If I was going to fix this, I'd want more automation in the testing and matching process. And personally I don't care the precise frequency results. I just wanted less extra work and changing of things if they don't need to be. To remove up/down sampling, yet fully use my hardware (use highest "good enough" and matching refresh rate). Seems more communication between the player and you might help here.
Though maybe my situation/goal is very unusual? That this won't help or be wanted by most. I can't say... Though I wish this was open source so I could see where the problem is, and maybe offer a fix. |
|
(0003079)
cyberloner
2023-12-10 12:54
|
really hope newer beta release fix this issue...it still not changing display mode |
|
(0003080)
madshi
2023-12-11 09:23
|
Do you use the official build (which is very old and outdated) or the latest "test" build from AVSForum?
http://madshi.net/madVRhdrMeasure202.zip (just copy the files over the official build) |
|
(0003081)
cyberloner
2023-12-11 10:23
|
old version is working perfectly... only report the latest beta ... including the 202 version... display mode is not changing at all sir....
sdr mode display auto changing mode into hdr if hdr movie is play (use with amd ags silent changing mode) |
|
(0003082)
madshi
2023-12-11 10:24
|
Are you talking about resolution / frame rate switching or about SDR <-> HDR switching? Those are completely different things. |
|
(0003083)
ParanormalBanana
2023-12-11 18:19
|
Hi there I just checked the answers to the post, I updated the version according the link provided and now, the display mode switching works, but not always the best way.
For example; I'd like to have 1080p24, but since 2160p24 is also in the list, madvr uses that instead of 1080p for 1080p movies. I had to change the order of the modes for it to select 1080p, but now I don't know what will happen with other modes further in the list. IMO madvr should select the mode that is best and not the first that is compatible in order.
Next is HDR, I just checked and it works also even though colors were off. maybe I need to look at the settings. Red was orange. |
|
(0003084)
ParanormalBanana
2023-12-11 18:19
|
EDIT:
I spoke too soon, mode chage worked but going back to the previous mode fails every time. |
|
(0003085)
madshi
2023-12-11 18:25
|
Fails how? |
|
(0003086)
ParanormalBanana
2023-12-11 23:28
|
it simply stays the same. |
|
|
Notes |
(0002994)
madshi
2023-02-10 23:06
|
Did you disable the OS HDR switch? If Windows 7 even has such a switch, I can't be sure. Maybe it was introduced in newer OSs. In any case, I don't really know what to do. I'm telling the Nvidia driver that I'm rendering HDR and Nvidia isn't supposed to do anything other than settings the "HDR Flag" so the display switches to HDR.
Anyway, why do you want to use "passthrough"? Most people consider madVR's internal tone mapping to be superior, and the 3060 Ti should be fast enough to run it. So why not using it? |
|
(0002995)
huhn
2023-02-11 14:50
|
how.
pretty much every TV looses brightness in SDR mode even when you pump it.
you need to change the max brightness of the device every time you watch an HDR file this alone is enough reason to give up.
you have to deal with bt 2020 not everyone has an nvidia card so this needs interaction too.
pretty much all TVs dim the image madVR has no clue about that but the TV has so it can compensate for the brightness loss by tone mapping accordingly.
an S95B OLED does less than 500 nits in SDR mode and easily 1000 in HDR. |
|
(0002996)
madshi
2023-02-11 14:57
|
With newer LG OLEDs, there's an option to force full brightness in SDR mode. Not sure about other brands, though. |
|
(0002997)
huhn
2023-02-11 15:50
|
having an desktop with 1000 nits in gamma light wouldn't be much fun anyway.
and i'm pretty sure this is about the services menu. disabling the ABL completely is not a good idea sadly because that's what kills them excessive SDR brightness. |
|
(0002998)
Wolfi
2023-02-11 18:00
|
Very Thanks for reply.
Win7 not have any HDR switch and functions, thats the problem.
The MadVR HDR switch works, and the signal informatinos in LGs hidden extented secrets info menues are the same on GTX980Ti and RTX3060Ti
But with GTX980Ti it switchs only in HDR BT2020 modus, and the BT2020 HDR Picture are correctly.
With RTX3060Ti and same driver it switch also in HDR BT2020 but makes also a bad SDR Transformation. (probably the nvidia driver)
Of Course i use the MadVR Passthrough for looking 4K bluray HDR mastered movies with 800nits peak on oled tv.
The HDR switch is not only need for full HDR brightness on TV, it is also need for correctly BT2020 colours.
It is the only reason use MadVR for me.
https://www.reddit.com/r/techsupport/comments/j05g8z/rtx_3080_not_doing_hdr_correctly_on_windows_7/
He is the only other i found with probably same problem, and he have the problem also in games (this i not testet)
It will be very nice Madshi can report this heavy bug to nvidia.
It is complete senseless make HDR to SDR tranformation in Win7 with no way for disabling.
For me the RTX3060Ti have no future if he kill the BT2020 HDR feature in win7.
In Win10/11 the HDR switch is stored in the registry ?
Maybe the nvidia driver read in Win10/11 windows HDR settings, and try read this entrys also in win7 ?
For me the nvidia driver have only wrong behaviour.
Anybody know the HDR regitry path in win10/11 ? (if he exists) |
|
(0002999)
madshi
2023-02-11 18:11
|
Unfortunately, Nvidia has stopped officially supporting Windows 7 and 8 more than a year ago, see here:
https://nvidia.custhelp.com/app/answers/detail/a_id/5201/~/support-plan-for-windows-7-and-windows-8%2F8.1
So I don't think there's much hope to get it fixed. You may have to switch to Windows 10 or 11. |
|
(0003000)
Wolfi
2023-02-11 18:27
|
Switch to new windows is absolutely no way in my case.
If i can not resolve, i will stand with GTX980Ti or buy a GTX 10XX or RTX20XX. (But this is a bad solution, because i wanted and waited for RTX 30XX with HDMI2.1 for have 4K 120hz RGB on HDMI)
In this case it is very interessting for me, people with RTX20XX and win7, hdr is working ?
Yes, low hope for nvidia fix it.
You try report it to nvidia ? |
|
(0003001)
madshi
2023-02-11 20:04
|
There's no hope in reporting it to Nvidia from my side. |
|
(0003002)
Wolfi
2023-02-11 22:57
|
yes, but why not try. |
|
(0003005)
Wolfi
2023-03-08 04:06
|
If anybody find in future (10 years) a solution or usefull information, i am very thankfull it post it here.
I have notification on, and become email if new post here. |
|
|
Notes |
(0002955)
madshi
2023-01-11 08:46
|
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. |
|
(0002956)
denis_fdrv
2023-01-11 10:19
|
Ok, thanks. Will try reporting this to Nvidia then. |
|
(0002957)
madshi
2023-01-11 10:41
|
If it helps, you can say that I'm using the API called "NvAPI_Disp_InfoFrameControl" to set the BT.2020 flag. |
|
(0002958)
denis_fdrv
2023-01-12 08:31
|
Reported this to Nvidia. They requested some debug info. Will give an update if anything new comes up regarding this issue. |
|
(0002959)
madshi
2023-01-12 09:23
(Last edited: 2023-01-12 09:23) |
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)?
|
|
(0002960)
denis_fdrv
2023-01-12 09:30
|
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 |
|
(0002961)
denis_fdrv
2023-01-12 09:33
|
The BSOD that I showed there happens after enabling the TDM debug mode in the registry. |
|
(0002962)
denis_fdrv
2023-01-12 09:34
|
TDR* |
|
(0002963)
denis_fdrv
2023-01-12 09:44
|
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. |
|
(0002964)
madshi
2023-01-12 09:52
|
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! |
|
(0002965)
denis_fdrv
2023-01-12 10:02
|
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. |
|
(0002966)
madshi
2023-01-12 10:20
|
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... |
|
(0002967)
denis_fdrv
2023-01-12 10:22
|
I see. Probably visible to the reporter only. I'll update this page if anything new comes up. Thank you! |
|
(0002968)
denis_fdrv
2023-01-13 06:23
|
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 |
|
(0002969)
madshi
2023-01-13 09:20
(Last edited: 2023-01-13 09:20) |
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 !! :-)
|
|
(0002970)
denis_fdrv
2023-01-13 14:01
|
Thank you! :) Doing my best to help. I'm also interested in getting this resolved. |
|
(0002971)
denis_fdrv
2023-01-15 11:59
|
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. |
|
(0002972)
madshi
2023-01-15 12:12
|
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. |
|
(0002973)
denis_fdrv
2023-01-15 13:37
|
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. |
|
(0002974)
madshi
2023-01-15 13:59
|
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. |
|
(0002975)
denis_fdrv
2023-01-15 14:19
|
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? |
|
(0002976)
madshi
2023-01-15 14:29
|
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. |
|
(0002977)
denis_fdrv
2023-01-15 14:59
|
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? |
|
(0002978)
madshi
2023-01-15 15:37
(Last edited: 2023-01-15 15:37) |
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"
|
|
(0002979)
denis_fdrv
2023-01-15 16:06
|
Thank you for the info and help. The profile switching seems to be working :) |
|
(0002980)
madshi
2023-01-15 16:13
|
Well, I'm motivated to help if you're helping, too... :-) |
|
(0002981)
denis_fdrv
2023-01-18 00:32
|
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. |
|
(0002982)
madshi
2023-01-18 09:52
|
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? |
|
(0002983)
denis_fdrv
2023-01-18 12:19
|
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. |
|
(0002984)
denis_fdrv
2023-01-19 07:14
|
Verified again: the signal switching (from RGB to YCbCr and from YCbCr to RGB) happens with both the official and test 165 madvr build. |
|
(0002985)
madshi
2023-01-19 08:51
|
Thanks! |
|
|
Notes |
(0002314)
madshi
2018-07-29 10:48
|
If the problem does not occur with default settings, then I'd suggest that you compare your default settings to your non-default settings. E.g. start with the default settings, then step by step change one setting at a time, to gradually change the default settings to your non-default settings. This way you should be able to figure out which exact setting is responsible for the problem. |
|
(0002316)
Zaoshi
2018-07-29 11:18
|
Changes to settings and render queue results in order:
1. Default settings: queue at 23-24/24
2. Set chroma upscaling to NGU anti-alias high: 23-24/24
3. Set image upscaling to NGU anti-alias high: 23-24/24
4. Enabled reduce banding artifacts (high/high): 23-24/24
5. Enabled reduce ringing artifacts: 23-24/24
6. Enabled reduce compression artifacts, strength 8, quality high, +process chroma channels: 17-19/24
7. Enabled reduce random noise, strength 2, +process chroma channels: 7-9/24
8. Set image upscaling to Bilinear: 17-18/24
9. Enabled upscale refinement > sharpen edges 1.0: 14-16/24
10. Enabled upscale refinement > thin edges 1.0: 12-13/24
11. Enabled upscale refinement > activate anti-bloating filter 50%: 11-13/24
12. Enabled upscale refinement > activate anti-ringing filter: 10-12/24
It seems increasing number of processing steps reduces render queue even if GPU can keep up. |
|
(0002317)
madshi
2018-07-29 11:37
|
That's somewhat weird, I'm not sure why that would happen. What kind of average render times do you get? Does it change anything if you add a flush after intermediate render steps?
In any case, if the problem does not occur in fullscreen exclusive mode, then I'm not sure if there's anything I can do, because my code is nearly the same in FSE vs windowed mode. So it must be either Direct3D or the GPU driver which makes the difference here.
FWIW, most users don't like "reduce random noise" much. Might make sense to disable that and increase the "reduce compression artifacts" strength instead. That should save a lot of performance. |
|
(0002318)
Zaoshi
2018-07-29 12:10
|
I think render times are reported incorrectly so I'm not sure if it will be of any help. When I increase upscaling quality OSD shows 16ms but I get 3 frame drops / second.
Without flush OSD reports 13.25ms. With flush - 15.50ms and I get 2 frame drops / second.
In FSE mode without flush I get 19.50ms. With flush - 21.30ms. In both cases there are no frame drops.
I noticed that if I reduce GPU queue size to 8 my render queue stays at 4-5/8 and frame drops disappear (in case when flush is enabled).
I did notice that "reduce random noise" causes a lot blurriness. That is why I keep it at low value to get rid only of fine noise.
"reduce compression artifacts" has similar issue - at high value it blurs image and eliminates fine details. I had a few cases where it replaced texture with almost solid color, so I do not want to increase it.
For now I'm still experimenting with these options, but thanks for the information. |
|
(0002319)
madshi
2018-07-29 12:16
|
Well, as I said, I don't really know anything I could do to improve this situation. I'm doing the same thing in FSE mode and in windowed mode. So if it works well in FSE mode, then it's unlikely to be my fault if it doesn't work as well in windowed mode.
Both "reduce random noise" and "remove compression artifacts" remove fine noise to some extent. Enabling both is probably superfluous. I've already considered removing "reduce random noise" completely. |
|
(0002320)
Zaoshi
2018-07-29 12:38
|
Alright, thanks. I tried to reinstall driver but that did not help. It seems I'll have to reduce my queue to 8. At least this way it's partially filled.
Thanks for heads up. Will experiment to get by without it. |
|
(0002321)
Nakasyma
2018-07-29 13:31
|
I can confirm this is an issue and I have some additional information:
- The problem only occurs after Windows 10 Version 1803 (April 2018 Update) upgrade
- The problem only occurs with NGU upscalers, all of the other upscalers are working well (including super-xbr)
- For me it seems the problem is only with the queue information. I don't have any issues with the playing quality despite of the nearly empty queues (and also don't have any dropped frames) |
|
(0002322)
madshi
2018-07-29 13:35
|
There have been some functionality additions to win10. IIRC, some users on doom9 suggested to turn some of those new win10 features off to make madVR perform optimally. I don't remember the details, you'll have to dig through the doom9 madVR thread, or ask there. |
|
(0002329)
Msarc
2018-08-08 08:34
|
Same issue, some more info:
- I can confirm that this started happening immediately after Windows 1803 update (I only updated yesterday).
- It's not an NGU issue, other upscalers suffer from this as well, including Super-XBR. Less demanding upscalers simply lower the impact and allow better hardware to compensate with raw power.
- Lowering GPU queue size has the same effect - lowers the impact, but not enough to help when more demanding processing is being done.
- Enabling/disabling flush made no difference in regards to the issue, but disabling flush raised rendering times by about 3.5 ms in both windowed and FSE mode.
- DX9 or DX11 - no difference. Tried setting both in MadVR and LAV decoder.
- The only new feature in v1803 of which I could find mentions on the forum is "Focus Assist", but having it disabled made no difference on my system.
MadVR v0.92.14
MPC-HC v1.7.17
AMD drivers v18.4.1 and v18.8.1 (no difference)
CPU: Intel Q9550
GPU: AMD R9 290 |
|
(0002330)
madshi
2018-08-09 11:19
|
Yes, I think it was "Focus Assist" which I've heard mentioned. Other than trying different drivers, I'm not sure what else to suggest. Obviously, if it was an OS update which introduced the issue, it's more likely to be a problem with the OS update or the GPU drivers than with madVR.
I've been telling users for months (years?) now that Windows 8.1 is the best OS for video playback. But nobody seems to listen to me. madVR users get screwed over time and time again with every new Windwos 10 update. |
|
(0002331)
Zaoshi
2018-08-09 19:39
|
Disabling Focus Assist helps with issues that occur when switching to FSE, but it doesn't seem to do anything for windowed fullscreen. |
|
(0002332)
Msarc
2018-08-10 11:23
|
Given that both Nvidia and AMD users are having this problem, it's less likely to be a driver issue. But it could be that Microsoft broke something that both camps need to fix. Just not sure any of them, including MS, will bother.
But back to the issue: I had noticed that both render times and CPU/GPU utilization are lower than normal in windowed mode after 1803.
For example, same video file, same madVR settings:
- Before 1803, 10-11 ms render times and no drops/repeats
- After 1803, 6-7 ms render times and massive drops/repeats
Like 1803 is preventing madVR from using the system at full power in windowed mode, for whatever reason.
And some more things I tried with no success:
- Checked Windows power settings - everything is still set to "max performance" as before.
- Set Windows system timer to 0,5 ms during playback, using "Windows System Timer Tool" (easily googled).
- Opened "Game Bar" during playback in MPC-HC and set it as a game.
- Disabled everything in "Settings > Gaming".
- Disabled the new "Settings > Personalization > Colors > Transparency effects".
- Set MPC-HC to "High performance" in "Settings > System > Display > Graphics Settings". |
|
(0002430)
madshi
2018-09-30 17:30
|
This problem should be fixed in v0.92.17, so I'll close this bug report. If you guys still have the problem with v0.92.17, then please re-open. |
|
(0002936)
ProphetWild
2022-09-23 06:17
|
I've been having this issue for a few years now. The render queue will fall to 3-4/8 and I will drop frames. This happens randomly but I can also trigger it in windowed mode by mousing over/pulling up the seek bar.
I have changed CPU and GPU as well as done clean installs of Windows 10 and 11 over the years and the issue persists. It does not happen in FSE.
I've tried different CPU/GPU queue values, vsync options, all of the flush options, and it still happens over all different content.
I've been using the HDR betas and it happens in those as well.
Really have no idea what it could be, I remember seeing something about the windowed mode having a weird interaction if you're running in 10bit/12bit but seems like a strange bug. |
|
(0002937)
madshi
2022-09-23 08:41
|
If it doesn't happen in FSE mode, why don't you simply use that? It's there for reasons like this... :-) |
|
|
Notes |
(0002820)
huhn
2021-08-20 11:43
|
this is more to let you know. i will keep you updated on this with the upcoming new windows versions. could be fixed in the next version could be the new default behaviour time will tell just a couple more months. |
|
(0002821)
madshi
2021-08-20 12:01
|
Yeah, Microsoft continues to screw things up more and more with each OS update. That's not really surprising. Hopefully they can get it solved somehow. That said, madVR's DTM is probably the best there is, anyway, so the importance of having HDR output is not as high as it used to be. The latest LG OLEDs support getting full brightness in SDR mode, so there's no need to send them HDR, anymore. |
|
(0002822)
huhn
2021-08-20 12:37
|
taking my shitty OLED and AMD into account i'm not so sure and the majority doesn't have OLEDs.
because there is no report BT 2020 and such.
not that i care about HDR.
what so ever there is a chance microsoft will do something about this because they broke older HDR games that doesn't use windows OS HDR but AMD and NVIDIA API. there are now games out there that will not be able to send HDR at all. usually they take backwards compatibility kinda serious. HDR games are just a couple of years old. on the other hand just look at 11... |
|
(0002823)
madshi
2021-08-20 12:53
|
I think it might be more of an AMD driver problem, actually, and less of an OS problem. Because if SDR playback works fine, the OS shouldn't even know (or care) if the AMD/Nvidia private HDR APIs are used or not. So there's a chance that a new AMD driver might fix this. |
|
(0002824)
huhn
2021-08-20 16:46
|
just for context.
i'm using win 11 dev builds since the release and everything was working fine with the last dev build.
this does not mean i don't update GPU driver too. |
|
(0002825)
huhn
2021-10-06 02:35
|
win 11 is out now and it still "broken" it outputs an image now but the levels are wrong it not off by 16 levels it'S less but. i don't know
even through there is a new driver the problem was the same it changed with windows version.
currently the AMD API is working at 8 bit and even in windowed (tone mapping and it seems to do a good job...)so .... that'S not supposed to be happening.
there are reports HDR and refreshrate switching broke completely on nvidia. |
|
(0002826)
madshi
2021-10-06 11:51
|
Might make sense to wait for newer drivers from both AMD and Nvidia. There's not much I can do about this, I fear. |
|
(0002827)
huhn
2021-10-06 17:29
|
it worked on AMD to wait for new windows versions. it was literally not engaging HDR with older windows versions.
there are some other things that break with madVR that should be related to your code.
the identifications are now stacking up i'm already at 120. it's reported that if more than one device is listed in devices 10 bit doesn't work on nvidia (which is kinda random).
but my first response was also wait for a new driver first and than have a look. |
|
(0002828)
madshi
2021-10-06 17:34
|
Can you reproduce the IDs stacking up problem? If so, can you zip and upload the settings.bin file with such a flood of IDs inside? |
|
(0002829)
huhn
2021-10-06 17:55
|
sure and a log. the settings are relative random from testing.
not sure what trigger it i had to switch between tone map and passthrough to relibile add a couple of new idetification to madVR. could be an LG OLED issue too... |
|
(0002830)
huhn
2021-10-06 18:01
|
there is no error when uploading so i zipped a 7z together with the bin which feels very wrong. |
|
(0002831)
madshi
2021-10-06 18:08
|
That's interesting, some of the IDs are unique, but there are a *LOT* of duplicates in there. That's not really supposed to happen. |
|
(0002832)
w
2021-10-20 03:20
|
Update: Other color managed applications are working again on Win 11 dev 224478.1012 (chrome, ff, etc. don't work on Win 11 release 22000), but MadVR doesn't select a device and still has the many identifications. |
|
(0002833)
madshi
2021-10-20 09:29
|
At some point I will install Win11 myself and fix the problems, but I'm too busy for that right now, unfortunately. So it will have to wait... |
|
(0002834)
huhn
2021-10-24 15:38
|
this seems to be more and more of been a driver issue/windows issue.
i only have one HDR game and that game has the wrong ranges too just like madVR even outside of HDR which makes absolutely no sense.
windowed HDR passthrough(where it was tone mapping) is now broken it has the wrong ranges too and the only thing that changes is the OS version.
win 11 is a new low for microsoft. |
|
(0002835)
madshi
2021-10-25 09:25
|
Yeah, they continue to make things worse and worse, it seems. I've no idea how such big a company can't manage to release a new OS update without breaking things all over again every time. |
|
(0002839)
thomasrc
2021-11-07 01:48
|
Unfortunately it is affecting everything that is related to the display settings as well. HDR, display modes, calibration, etc. If you have multiple displays connected to the computer, madVR just fallbacks to the first display's settings, because it can't detect the display correctly or something similar stuff is happening (see the ID duplication thing above). My projector is configured to switch refresh rate automatically by madVR according to the movie, but under Windows 11 it just does nothing, unless I place all the projector's config into the primary display's settings (which would be a great workaround, but it won't work correctly, because it applies to the other displays too of course). |
|
(0002840)
madshi
2021-11-08 09:37
|
I'm in the process of building a new development PC, based on Windows 11, and will then try to fix any madVR related bugs I can find. I'm not sure if HDR can be fixed, though. Depends on whether it's my fault or not. |
|
(0002911)
thomasrc
2022-06-20 16:07
|
Are there any news about this issue?
I'm using Win 11 21H2 now, latest nvidia game ready driver and the latest madVR Test Build that I found on videohelp.com and I'm still experiencing the mentioned display modes issue. However I realized now that madVR recognize my secondary display (is entry is bolded when playing video on it) that is connected via DVI cable to my computer, but not the other two that are connected via HDMI and DP. |
|
(0002932)
huhn
2022-09-19 13:09
|
the device page issues are fixed for me with version beta 165.
after deleting the duplicates it still trigger until i installed it again.
makes no sense to me but i tested it 2 times...
please stick to HDR issues now.
if this still doesn't fix it for you go here and reopen it: http://bugs.madshi.net/view.php?id=682
the hard bugs started with 22H2. |
|
(0002933)
Peabutt
2022-09-19 14:46
|
Is the HDR issue only present for AMD gpus or NVIDIA also? I have AMD i HDR wont work. never had an issue b4. Windows 11 latest build and latest amd driver. |
|
|
Notes |
(0002884)
thighhighs
2022-04-27 17:26
|
Similar symptoms, but in my case everything freezes completely. And this only happens when Native D3D11 decoder is used. GTX 1660 Ti, Windows 10/11
Madshi look at this please. The test build still has this problem. |
|
(0002885)
madshi
2022-04-27 18:01
|
Try decreasing the size of the GPU and/or CPU queue, maybe? |
|
(0002886)
thighhighs
2022-04-27 18:54
|
madshi
I've tried various madVR settings, checked system settings, etc. It had no effect. Tried to change players (MPC, PotPlayer), decoders (LAV, Pot built-in). The symptoms described above are still there. In my case this only happens if native d3d11 decoder is used. Native d3d9 decoder (DXVA2) works fine. Also d3d11 c-b work fine. I also tested native d3d11 decoder with the Pot built-in VR, it works fine. Looks like a bug in the madVR. |
|
(0002887)
madshi
2022-04-27 19:10
(Last edited: 2022-04-27 19:11) |
Well, it works fine for me, and seems to work fine for most other users. Fixing problems one can't reproduce are always a nightmare for every software developer.
|
|
(0002888)
thighhighs
2022-04-27 22:24
|
madshi
I don't know if it will be useful, but I did freeze report |
|
(0002889)
madshi
2022-04-27 22:45
|
Does not seem to be stuck inside of madVR. I might be able to say more if you had PDB files for the native DXVA decoder. |
|
(0002890)
thighhighs
2022-04-27 23:26
|
madshi
Hm... I googled and found where clsid2 say how to create dump. It can help?
madHcCtrl.DMP - https://www83.zippyshare.com/v/ht86nmwA/file.html
PotPlayerMini64.DMP - https://www2.zippyshare.com/v/rQ7zVXMk/file.html |
|
(0002891)
thighhighs
2022-04-28 01:20
|
And log. Hope some of this helps. |
|
(0002892)
madshi
2022-04-28 10:31
|
Looks like there's a decoder reconnect, and afterwards the media player gets stuck in paused mode.
You could try using LAV Video Decoder instead of the internal decoder.
Or try disabling the "delay playback start until render queue is full" option. |
|
(0002893)
thighhighs
2022-04-28 15:20
|
It seems that the decoders work identically. The option has an effect. There is no more stability. If I go to full screen without pausing playback, there may be a complete freeze of the PC (hard reset). When I do this, the audio can play, but the video freezes for a few seconds (0000001:0000010). If I use the seeking keys when it is frozen, there may be a complete freeze of the pc.
New logs. To test, I chose this scenario: open a file, pause, go to full screen, resume playback, pause again, exit full screen, play again, then close the player. LAV filters are used. Also did a test with native d3d9 which works fine, hope you can see the difference. |
|
(0002896)
madshi
2022-04-30 10:26
|
Instability like this can have multiple causes. One common cause could be running out of GPU RAM. Also, some decoders don't like having too many "active" frames at the same time. For both reasons, I'd recommend trying with much smaller CPU and GPU queues, to check if that helps. Try the smallest queue sizes possible. Also, keep "delay playback start" disabled for now. Finally, try with smooth motion disabled, as a test. I don't know if any of that helps, but since most other users (including myself) don't seem to have this problem, I'm not sure what else I can say. |
|
(0002897)
thighhighs
2022-04-30 17:21
|
madshi
As the user above said, the key is in the "switch to matching display mode... when playback starts" option. But this does not allow me to use madVR comfortably. BTW, I'm pretty sure the user above is actually using native d3d11, but was unable to select that on the form, as someone wrote in posts here. It looks like the advantage of native d3d11 is not the "better stability".
Maybe someday the users or developers of LAV and MPC will provide more useful information and you can fix it. |
|
(0002912)
pcp7
2022-07-01 02:28
|
I've the exact same problem, switching the display rate works fine, but only if stay in windowed mode. Switch to full screen and the video freezes, and won't play. Turning off the switch display rate makes everything work fine. I'm using RTX3080 and MPC |
|
(0002913)
madshi
2022-07-01 11:00
|
See my reply above, those tests are still useful. |
|
(0002914)
thighhighs
2022-07-01 13:39
|
madshi
I said above that the "...when playback starts" seems like a workaround. But at some point I noticed that the video memory usage increases with each new file opened, 2.3 -> 3.5 and more (memory leak?). This happens after using D3D11 Native (C-B work fine), and stops after restarting the player.
I also noticed that PotPlayer, MPC, KMP - the result is the same. MPC-BE - works differently. D3D11 Native still doesn't work correctly, but the symptoms are different. In all scenarios it only happens to madVR. But does it make sense to consider the problem from the side of the player? |
|
(0002915)
madshi
2022-07-01 13:49
|
Well, I did make a number of other suggestions... ;-) |
|
(0002916)
thighhighs
2022-07-01 15:03
|
madshi
For me there is no solution in settings. I have tried different combinations. Two options affect symptoms: "switch to matching display mode..." and "delay playback start". But it was not possible to set up to play without problems.
In the google, I met a discussion of similar symptoms with the MPC player. Now I can't find it... There the user did a debug. As a result, the developer who gave the debug versions said he couldn't fix it. It would not be difficult for me to contact the developers of MPC-BE (no language barrier), but with a high probability the result will be the same. |
|
(0002917)
madshi
2022-07-01 15:08
|
Well, delay playback start is a tricky option, it can cause instability. So if it helps, you should be able to disable this option without losing much.
Is there a reason you can't simply use copyback? It has several advantages over native, e.g. black bar detection. The only true reason to use native is if copyback is too slow (stuttering). |
|
(0002918)
thighhighs
2022-07-01 16:45
|
madshi
D3D9 CB or D3D11 CB is enough for me. But I consider quality/gpu load for my normal settings and maybe D3D11 Native would help to upgrade to heavier settings for free in some cases. It's hard to appreciate its benefits when it's not working properly. But in general, at the momment there is nothing critical in using a different decoding method in my case. |
|
(0002919)
madshi
2022-07-01 17:16
|
I don't think Native decoding would give you much extra GPU power. The cost of copyback is simply the travel back of the video frames from GPU RAM to system RAM. That's usually not something which slows down GPU rendering. The RAM transfer is done in a different thread, and I think it's done in hardware by DMA, or something like that. |
|
|
Notes |
(0002280)
SLKabaker
2018-04-24 04:25
|
eac3to does not have a problem with UHD and Seamless Branching for extracting Chapter Information and Video Streams. The problem seems to be with extracting Dolby TrueHD and Dolby Atmos (specifically with creating the embedded AC-3). The root of this problem looks to be with "libav/ffmpeg"; when using "-nero" (Nero 7 with Blu-ray/HD DVD Plug-in) there is no error. I was able to successfully extract Chapters, Video and Audio from an UHD with Seamless Branching by either doing the Chapters & Video without Audio or all three by including "-nero". Only when trying to extract audio and using the default "libav/ffmpeg" does the extraction have errors & fail. I have not tried a disc with DTS (DTS-HD MA or DTS-X), yet (ArcSoft or "libav/ffmpeg"). |
|
(0002281)
SLKabaker
2018-04-25 09:36
|
I decided to double check that it was "libav/ffmpeg" causing the problem. So, I attempted to extract the Dolby TrueHD (Atmos) track to LPCM (W64) from an UHD with Seamless Branching. It, still, had all the same errors. I uploaded the LOGs from using Nero and "libav/ffmpeg". |
|
(0002283)
SLKabaker
2018-04-26 18:35
|
I have UHD Blu-rays with E-AC-3 Audio as well. I decided to see if, along with Dolby TrueHD (Atmos), eac3to had an issue with UHD Dolby Digital Plus. It turns out, yes, that eac3to cannot extract E-AC-3 Audio from UHD Blu-ray Discs. The UHD Blu-ray Discs with E-AC-3 Audio are, also, seamless branching discs. I do not have any UHD Blu-rays with E-AC-3 Audio that are not seamless branching. So, I cannot verify if this is exclusive to seamless branching like Dolby TrueHD (Atmos) is. However, it seemed likely since both are Dolby. I uploaded the logs from my attempts to extract E-AC-3 Audio with and without Nero; as well as, extracting the AC-3 Core. |
|
(0002456)
nautilus7
2018-12-28 13:16
(Last edited: 2018-12-28 19:25) |
I have the same issue. It happens with seamless branching discs. eac3to detects gaps for every kind of track.
-no2ndpass seems to give correct results (in sync) for ac3 and dts tracks. I was able to compare them with the audio tracks (same format) extracted from a blu-ray disc of the that movie. dts and ac3 tracks from uhd bd and bd seemed identical.
For truehd (with atmos) eac3to doesn't produce correct output (in sync). It's confirmed. -no2ndpass doesn't make any difference since gaps cannot be fixed in the truehd bitstream.
For e-ac3 I was not able to test if with -no2ndpass the output is correct.
Please madshi fix this! eac3to is one of a kind tool and provides functionality no other software does.
Thanks for the support!
|
|
(0002598)
deathbringer
2019-12-07 16:55
|
Having the same problem with the Dolby Atmos track from the seamless branching BD and UHD of Baywatch (https://www.amazon.it/Baywatch-Blu-Ray-4K-UltraHD/dp/B072FP6TBN/). The audio gets mor out of sync with the video, the longer the video lasts.
I came here, trying eac3to as a workaround suggested by Moritz Bunkus from MKVToolNix (https://gitlab.com/mbunkus/mkvtoolnix/issues/2684).
According to Nevcairiel from LAV Filters, the TrueHD streams have a timestamp, which has to be continuous and needs to be patched when (de)muxing from a seamless branching disc. (https://github.com/Nevcairiel/LAVFilters/issues/282) |
|
(0002898)
kasper93
2022-05-02 01:11
|
For reference, here is open source tool that correctly stitches truehd stream https://github.com/domyd/mlp |
|
(0002899)
madshi
2022-05-07 11:38
|
Can you guys list a couple of UHD discs which are well suited for me to analyze this problem? |
|
(0002900)
kasper93
2022-05-07 16:49
|
I can provide some of the titles to consider:
Cars (2006)
Close Encounters of the Third Kind (1977)
Dirty Dancing (1987)
Encanto (2021)
Eternals (2021)
F9 The Fast Saga (2021)
Frozen II (2019)
Halloween Kills (2021)
Luca (2021)
Midway (2019)
Monsters University (2013)
Onward (2020)
Pitch Black (2000)
Psycho (1960)
Raya and the Last Dragon (2021)
Requiem for a Dream (2000)
Rogue One (2016)
Star Trek II: The Wrath of Khan (1982)
Star Wars: Episode IX - The Rise of Skywalker (2019)
The Suicide Squad (2021)
Thor: Ragnarok (2017)
True Romance (1993)
Turning Red (2022)
Underworld (2003)
While mlp (which I linked) looked promising, seems like author is not maintaining it anymore and according to reports it is not always working. I think nowadays DGDemux is goto tool. But people still love eac3to! :) |
|
(0002901)
madshi
2022-05-07 16:58
|
I'll see what I can do. I'm also considering open-sourcing eac3to. Though, it's Delphi code, not C++, and the source code is not in great shape (due to constant lack of time). |
|
(0002902)
nautilus7
2022-05-08 20:58
|
Hi madshi, hope you're doing well.
This opensource tool claims to doe the best job in correcting truehd / mlp streams. https://github.com/domyd/mlp
Regards, nautilus7 |
|
(0002903)
madshi
2022-05-08 21:33
|
Yeah, kasper93 already mentioned that tool, but he also said there are reports that it doesn't always work. @kasper93, in which way does it not always work? Does it crash? Or are there still audible pops/noises? Or does sync get lost? Do you have information about which movie the tool has problems with? Maybe a link to a forum? |
|
(0002904)
madshi
2022-05-08 23:05
|
New build available on doom9. The new build *only* tries to get rid of any TrueHD audio artifacts caused by seamless branching. It does not do any sync related stuff. Also, I don't know why eac3to detects gaps in various audio tracks when handling UHD Blu-Rays. However, the new build now auto-disables 2nd pass gap processing for Blu-Rays and UHD Blu-Rays, since that's usually not needed for this type of content, anyway. |
|
(0002905)
kasper93
2022-05-09 00:37
|
@madshi, About mlp, you can look at the github issues. Specifically the last comment of author (from Dec 6, 2020) https://github.com/domyd/mlp/issues/3#issuecomment-739534770 (where he mentions his tool is missing audio samples, while makemkv "somehow magically" extract them) and since then there wasn't any update. Because of that, even tho tool looks promising it never got adopted by community, simply because DGDemux and MakeMKV are more compatible and people trust them more to produce proper output. (btw. from MakeMKV v1.15.4 changelog "Implemented seamless joining of TrueHD streams with overlapping frames based on Dominik Mydlil's idea") so the method is working, just there are other issues on top.
Sorry, I don't have more info, I haven't really dive into the issue. |
|
(0002906)
madshi
2022-05-09 08:38
|
Ok, let's leave it to users to test these issues with eac3to. I don't think eac3to should have the issue that mpl seems to have. |
|
|
Notes |
(0002628)
madshi
2020-01-30 10:31
|
I think the problem is that madVR tries to interpret what the media player wants (zoom, AR and shift), and fails to do so properly in this specific case. The reason why madVR tries to interpret the media player wishes is that madVR automatically detects black bars in the image and zooms them away and also supports CIH, CIW and CIA front projection setups (if the user has activated these features in the madVR settings).
Have you already seen this document?
http://madshi.net/89notesForDevs.pdf
It's quite old, but still applies.
You say you're maintaining a DSPlayer build - does that mean you're a developer and can also do changes (at least minor ones)? If so, if it's not too difficult, it would be great if you could teach DSPlayer to communicate its wishes to madVR clearly, by using the madVR communication interfaces. See 1c) in the PDF above. I believe that would fix all the issues. |
|
(0002629)
justsomemadvrdude
2020-01-30 13:43
(Last edited: 2020-01-30 15:03) |
Thanks for the unexpected fast reply and the PDF (which i have not seen before).
If relevant:
Black bar detection ("automatically detect hard coded black bars" is disabled on the test setup. (madVR "zoom control" settings tab all checkboxes unchecked)
I tried finding a workaround and did experiement with all settings i thought might do the trick.
Could not find any workaround in the end.
Now that you know that this happens while "automatically detect hard coded black bars" being disabled, does that change any of your assumptions?
So if i understand correctly, it looks like my wary suspision was correct, that in case of the existing DSPlayer, madVR interprets what the user has set in DSPlayer and acts on it (zoom/ar/shift) and Kodi itself is _not_ telling madVR what to do by sending commands to it or something like that.
I tried to think about what is different when Kodi has the video playing in the background rather then playing it in VideoFullScreen/VideoOSD (where madVR interprets everything flawless as it seems).
When VideoFullScreen/VideoOSD is used in Kodi, there is not even a "videowindow" control-tag in the Kodi skin, because it's most likely is all done by the Kodi core.
As soon as you switch to the home screen while playing video, the skin uses a very simple <control type="videowindow"></control> where the video is then displayed.
Looks like madVR does not get the information (zoom/ar/shift) it wants from this somehow "other" video player window.
As you can see it in the screenshots madVR seems to get _some_ information (even if they end up wrong) from the "background-video", because if that would not be the case you would assume that the background video maybe just would be displayed without any zoom/shift at all, but at least always be of correct AR.
I'm not really a C developer, but coming from the ux/ui/qa/web-dev world i have some background in coding php/js.
I have a machine set up which is able to compile DSPlayer x64 successfully.
I did create the build with the fixed/better gui scaling via mipmapping for Linux and Windows and was able to add some smaller(!) changes and backports to make DSPlayer a little more future proof.
I checked 1c) of the PDF and seem to understand your intent regarding implementing SetDestinationPosition/SendCommandX to have Kodi always tell madVR exactly and directly what Kodi wants to avoid the misinterpretation in this background-video-case.
Although i'm not shy of the work hours and happy to have a further look into the DSPlayer code, i have to assume that such more videoplayer related programming will be above my abilities.
In case i can't implement this on my own, do you have any further assumptions why madVR interprets DSPlayers user zoom/ar/shift flawless (even in the most exotic combinations) when being VideoFullScreen/VideoOSD in opposition to the video playing in background?
The discrepancy of the flawless interpretation on the one hand and the messup on the other hand is what really irritates me.
IF madVR's interpretation in VideoFullScreen/VideoOSD would also only be "mostly correct, but still not flawless" i would think that implementing IMadVRCommand::SendCommandStr would most likely be the only clean and rock solid way to go.
But at this point i would still have hope that we may find a way to change whatever is different in Kodi when the video is playing in background so madVR acts exactly like it does when playing in VideoFullScreen/VideoOSD.
So far for my quick feedback.
As said, i'm happy to have a deeper look at the code, but i don't want to get my/our hopes up about me implementing SetDestinationPosition/SendCommandX. :-/ :-)
Thanks again for your time.
|
|
(0002632)
madshi
2020-02-03 12:41
|
madVR tries to interpret the media player wishes by looking at things like changes to the rendering window size, changes to the parent window size, and calls to IVideoWindow::SetWindowPosition etc. Depending on these things, and the timing and order of changes to these properties, madVR tries to "understand" what the media player wants to achieve. And usually that works reasonably well, but occasionally it may fail. I assume if not the full screen is covered with the video, it makes things more difficult for madVR to understand fully.
I'm not sure if you can fix this by just playing around with the current code. I think you would waste a lot of time doing that. It would be more effective if you tried to use the madVR "SendCommandStr" API. It can't imagine that it would be very difficult. I think the key things you would have to do are:
1) Locate all code places in DSPlayer which call IVideoWindow::SetWindowPosition.
2) Find a way to access IMadVRCommand at all the same code places.
3) Try to understand the IVideoWindow::SetWindowPosition code. How does DSPlayer call the numbers to feed into SetWindowPosition? I assume DSPlayer will access the DSPlayer settings and then do some math to calculate the numbers.
4) Based on your understanding of 3), call SendCommandStr() with the appropriate zoom mode.
I'm not sure which of these 4 things will be the most difficult to achieve. In theory they could all be easy. Or difficult. |
|
(0002633)
justsomemadvrdude
2020-02-04 00:49
(Last edited: 2020-02-04 03:35) |
Thanks for the guidance.
Before your update note i already made some first searches regarding the code places of SetDestinationPosition.
With your further hints and proposed steps (especially mentioning to focus on SetWindowPosition, not SetDestinationPosition) i have some success to report.
I made a test build with some kodi debug notifications to understand when and which area of the code triggers.
After some hours of getting used to the new area of programming and code i now have some first test builds which already go in the right direction.
I'm now using multiple SendCommandX which are also documented in the mvrInterfaces.h file.
Just a code snippet to get a feel of what i'm trying:
_____________________________________________________________________________
if (Com::SmartQIPtr<IMadVRCommand> pMadVrCmd = m_pDXR)
{
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode != ViewModeOriginal)
pMadVrCmd->SendCommandString("setZoomMode", L"touchInside");
else
pMadVrCmd->SendCommandString("setZoomMode", L"100%");
pMadVrCmd->SendCommandString("setZoomAlignX", L"center");
pMadVrCmd->SendCommandString("setZoomAlignY", L"center");
pMadVrCmd->SendCommandDouble("setArOverride", 0.0);
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode == ViewModeNormal)
{
pMadVrCmd->SendCommandDouble("setZoomFactorX", 1.0);
pMadVrCmd->SendCommandDouble("setZoomFactorY", 1.0);
}
else
{
pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
}
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift > 1.0)
pMadVrCmd->SendCommandDouble("setZoomOffsetY", -(1.0 - CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift < -1.0)
pMadVrCmd->SendCommandDouble("setZoomOffsetY", (1.0 + CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
else
pMadVrCmd->SendCommandDouble("setZoomOffsetY", 0.0);
CGUIDialogKaiToast::QueueNotification(CGUIDialogKaiToast::Info, "DSPlayer", "madvr debug", TOAST_MESSAGE_TIME, false);
}
_____________________________________________________________________________
This direction of progress already results in a stable and predictable madvr video on homescreen with correct vertical shift and zoom. (Not possible before outside Kodi videofullscreen/videoosd window)
As we hoped for, madVR now strictly follows what is set above, no matter in which kodi window the video is displayed.
Still some work to do though. The custom video "pixel ratio" setting is not implemented yet for example.
Will report further on progress or roadblocks. :-)
|
|
(0002634)
justsomemadvrdude
2020-02-04 01:55
(Last edited: 2020-02-04 03:36) |
Questions for the meantime:
1)
Let's say everything works out as discussed regarding adding robust zoom/vshift/originalsize-mode/custom-aspectratio support - there is one thing i don't know if i have to account for it in the code:
3D content
I have absolutely no experience on how original Kodi or even DSPlayer-Kodi-madVR handles 3D.
Do i have to account for anything in that regard?
My only experience with home cinema 3D content is on retail hardware players with retail 3D BD.
2)
Is madVRs "setArOverride" what should be used to adapt the Kodi optional custom video "pixel ratio" feature/setting?
Or is this the wrong approach and should i maybe just use additional conditions for setZoomFactorX/Y instead?
Something like this seems to work to adapt the setting:
_____________________________________________________________________________
pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio != 1.0)
{
if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio < 1.0)
{
pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
}
else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio > 1.0)
{
pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
}
}
_____________________________________________________________________________
Thank you
|
|
(0002635)
madshi
2020-02-04 08:55
|
Glad to hear you made good progress! :-)
I assume (hope) that Kodi's "pixel ratio" option has a default value which is something like "auto detect" or "don't change" or something like that? I think using "setArOverride" is preferred over adjusting the zoom factors manually, because really this option sounds like it's primary purpose is to modify the AR, right? The end effect might be the same, though. Still, I tend to prefer "setArOverride" in this case.
I'm not completely sure about 3D content in this case. I'd suggest that you start by ignoring it and treating it like 2D. If that doesn't work for some reason just let me know, then we can brainstorm about it. |
|
(0002636)
madshi
2020-02-04 09:01
|
Btw, great work on the improved downscaling, it's really hard for me to understand how the Kodi main devs don't seem to feel a need to fix this.
I don't suppose you managed to port DSPlayer to Leia? Last time I checked it still seems to be stuck on the previous release. |
|
(0002640)
justsomemadvrdude
2020-02-05 17:19
(Last edited: 2020-02-22 00:12) |
Here we go with a test build. :-)
I also handed it to a friend and will throw some everyday-testing at it myself:
Edit: Removed old links
custom video pixel ratio:
-------------------------
Yes, Kodi's per video custom video "pixel ratio" defaults to 1.0 (which is the neutral value doing nothing) and the setting itself is just another simple per-video setting like "zoom".
According to the wiki it's just a correction option for videos which have a messed up AR for example.
The slider ranges from 0.5 to 2.0
0.5 results in 50% image width while keeping the height untouched, meaning: keeping height at whatever size it's already at
1.0 is neutral and changes nothing
1.5 results in 150% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at
2.0 results in 200% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at
For now i went with the setZoomFactor implentation for the setting. It just seemed to work so solid and my previous attempts at using "setArOverride" instead ended up not working correct for some reason.
Is there some more background info regarding on which "setArOverride" values are allowed and what they will do exactly in order to maybe achieve the above mentioned?
It seemed like i ended up with a blank black video if "setArOverride" has been set to a value it did not seem to like.
I'm open to changing the implementation to "setArOverride" if i know how. :-)
3D:
---
+1
Let's ignore it for now and hope that it's not affected by the changes.
I already asked in the DSPlayer thread if someone is willing to test 3D on an old DSPlayer+madVR build vs the new build.
Maybe this confirms easily if 3D works as good (or bad) as before. I think this is all we would want to know.
I'll report if i found some willing testers.
|
|
(0002641)
madshi
2020-02-05 17:27
|
Sorry, no time to test the test build, unfortunately. I'm extremely busy working on the Envy atm. However, based on your description of the Kodi "pixel ratio" feature, I'd say that probably using "setZoomFactor" is a good choice instead of "setArOverride". So I think you should just leave it like that. |
|
(0002642)
justsomemadvrdude
2020-02-05 17:34
(Last edited: 2020-02-05 17:34) |
No worries, just wanted to post it here for informational/archival purposes.
Okay, let's keep the setZoomFactor variant at least for now then.
Thanks for the input, i'll just update when there is further feedback or progress.
Good look with your work on the Envy.
|
|
(0002643)
madshi
2020-02-05 18:25
|
Thx! |
|
(0002677)
justsomemadvrdude
2020-02-22 00:16
|
Just for the archives:
From now on, builds with the implemented correct "API-communication" solution (and some more changes/backports/fixes for other stuff) can be found here:
Kodi 17.7 DSPlayer x64 BETTERGUI
https://forum.kodi.tv/showthread.php?tid=351534 |
|
(0002678)
madshi
2020-02-22 00:38
|
Great stuff - thanks! |
|
(0002681)
justsomemadvrdude
2020-02-29 13:12
|
I got so used to the fixed "non-picture-squeezing" behaviour that i'm now irritated when i have to use an old build for a short time for debug reasons. :-)
Regarding 3D feedback after API-picture-size-stuff changes:
I got not much but some feedback by 2 users which sounded like 3D works as before. (Since our goal was to not brake it or make it worse, it should be okay.) Would have preferred to test myself also, but since that's not an option...
--
Bonus question while working on some additional stuff for DSPlayer:
In regards of DSPlayer<>madVR i was wondering about the "preset queue" setting:
- Preset queue (windowed+exclusive) is set to 8 (default) via madVR tray settings
(rendering->windowed mode, rendering->exclusive mode)
- The madVR-overlay shows that it uses the setting of 8 correctly (x/8)
But:
When Kodi DSPlayer has _any_ own GUI element showing on top of the playing madVR video, madVR changes the "present queue" maximum count temporarily from 8 to 2 - as long as DSPlayer shows said GUI elements. (See screenshots)
As soon as all Kodi-GUI elements are hidden again, the temporary reduced count jumps back to 8 instantly.
Just to be sure: I'm not talking about how filled the present queue is, but shown maximum count x/8. It jumps to x/2 for the temprary situation.
Is this bevaviour intentional and maybe unavoidable for some technical reasons?
http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_001.jpg
http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_002.jpg
http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_003.jpg
Side notes:
- I suspect this behaviour is handled from inside madVR itself, since my build of DSPlayer does not set any "preset queue" setting
- I cleaned the build of being able to change madVR settings. Everything is configured via madVR tray settings. Besides the discussed picture-size-API-stuff DSPlayer does not "control" madVR in any further way anymore.
Thanks! |
|
(0002682)
madshi
2020-02-29 13:28
|
It's intentional. Having a queue size of 8 means that for 24fps, that would be 333 milliseconds latency/delay. So you press a key to move the Kodi "cursor"/focus, and it takes 333+ milliseconds for that to become visible. That's not good, of course, which is why madVR limits that to 2 frames when any active GUI is visible, to make GUI feel less sluggish. |
|
(0002683)
justsomemadvrdude
2020-02-29 15:10
(Last edited: 2020-02-29 15:14) |
Interesting, thanks.
1) I'm aware of the typical sluggishness in 23hz/low-fps scenarios which feels about identical on all devices (apple tv 4k @ 23hz, kodi devices @ 23hz etc.)
In the discussed matter we are talking about an additional "present-queue"-delay which would add even on top of the known typical 23hz-sluggishness - do i understand that correctly?
2) Is this implementation Kodi DSPlayer specific?
3) Would it be possible to consider a future madVR setting for DSPlayer to use like:
Variant A (most simple but already very helpful):
m_pSettingsManager->SetBool("preRenderFramesReductionOnGUI", false);
OR
Variant B (more flexible):
m_pSettingsManager->SetBool("preRenderFramesReductionOnGUI", true); // Should be true by default, of course.
int framesCount = 3;
m_pSettingsManager->SetInt("preRenderFramesReductionOnGUICount", framesCount); // Purely optional override of the default value of 2
There would be _no_ need for a setting in the madVR-settings-UI itself. The existence of any option itself to be used by DSPlayer code would be very sufficient.
Reasons:
Besides having control for special use cases there are higher end 21:9 projection screen users which for example use a standard projector resolution of 3840x2160 while using a Kodi skin with additional features to mask all the visible content which is outside of their 21:9 screen.
These features are therefore detected as GUI by madVR which leads to these users being stuck with an absolute maximum present queue count of 2.
Besides this example i can think of more use cases which would make Kodi show GUI permanenty on top of a playing video while there is no user input/navigation going on.
|
|
(0002684)
madshi
2020-02-29 15:35
|
> do i understand that correctly?
Yes.
> Is this implementation Kodi DSPlayer specific?
No.
> Would it be possible to consider a future madVR setting
You already have some control over it. Please check "mvrInterfaces.h". If you search for "low latency" you'll find what you need. |
|
(0002805)
justsomemadvrdude
2021-06-18 19:36
|
After some time catching up with real life and still being happy with the latest 2020 version of DSPlayer, i again wanted to thank for the help and good info/communication.
I found all the information on low latency mode based on your hints and made multiple tests in the meantime to see how it feels with it being disabled.
Result: In regards of Kodi usability it's really unusable with the high input delay which makes all button presses very irritating and confusing.
So i ended up with not implementing any DSPLayer user option to disable low latency mode it.
Hope work with the Envy is well. Best regards. |
|
(0002806)
madshi
2021-06-24 11:16
|
Makes sense, thanks for letting me know.
Working on Envy 24/7, it's fun and constantly improving. |
|
|
Notes |
(0002711)
B1gD4ddy
2020-07-09 22:59
|
problem is in new 451.67 whql still present. |
|
(0002714)
Cineaste
2020-07-19 12:19
(Last edited: 2020-07-19 15:19) |
It appears I am now at a point where I have to update the driver purely to keep on top of my games. madshi, do you know what they did to the API? Is it entirely new code?
|
|
(0002718)
zeus0r
2020-07-27 15:32
|
same problem here!
current "solution":
when activating win 10 desktop HDR madVR uses OS HDR instead of NV HDR and everything is fine. is there any way to tell madVR to always use OS HDR without enabling/disabling it all the time? |
|
(0002719)
B1gD4ddy
2020-07-27 16:10
(Last edited: 2020-07-27 17:42) |
ehm nope.
not same problem there since when you do it right like i described and like how everybody uses it currently madvr since 45x.xx always autoactivates os hdr instead of nv hdr and the movie is still washed out sdr.
what you call the solution and are asking for is the damn problem we have.
madvr hdr passthrough is build so nobody needs the disgusting os hdr and for auto activating/deactivating nv hdr at start/close of movie.
btw @ madshi: did you look into that? can you change something and make hdr passthrough work again with 45x.xx?
|
|
(0002720)
B1gD4ddy
2020-07-27 18:02
(Last edited: 2020-07-27 18:10) |
this would be very nice because as we speak people research on dolby vision mkvs.
makemkv for example just added the new matroska 1.6.0 specs for storing dv metadata in mkv.
dolby vision mkvs already work when build with makemkv 1.15.2 and played back by a modified exoplayer apk in kodi!
having working madvr hdr and later on dolby viosion passthrough with 45x.xx+ would be gold.
please tell us the current status.
|
|
(0002721)
zeus0r
2020-07-28 20:16
|
ok sorry, that's weird B1gD4ddy.
i just tested it with the latest nvidia drivers (gtx1660 super):
win10 HDR enabled: madvr uses OS HDR & fullscreen windowed and everything works perfectly fine
win10 HDR disabled: madvr uses NV HDR & fullscreen exclusive and HDR is washed out although my display goes to HDR mode |
|
(0002722)
B1gD4ddy
2020-07-28 20:34
(Last edited: 2020-07-28 20:36) |
yes, when you manually activate win hdr and then start the movie everything works fine.
but when win hdr is turned off and you start the movie and let madvr turn on hdr on its own then it turns on win hdr automatically but movie is still washed out sdr.
but manually activating win hdr everytime before you start a movie is no solution, since we use the madvr hdr passthrough feature for the very reason that it automatically turns on nv hdr when you start the movie and it turns off nv hdr automatically when you close the player. win hdr had never to be touched. it always worked that way until nvidia released 45x.xx.
|
|
(0002724)
Cineaste
2020-07-30 06:59
|
Whilst we're waiting I have set up an AutoHotKey that toggles Windows HDR on/off by pressing a button. That button is mapped to a key on my remote so that all I have to do is use my Logitech Harmony (start Kodi > press button to toggle HDR > play movie > press button to automatically turn off HDR).
Not as convenient as madVR auto-switching but much better than manually having to fiddle with settings every time. |
|
(0002725)
cccleaner
2020-07-31 22:32
|
can confirm this behavior too.
I hope madshi can find some time beside his big hardware project to keep the original source alive and properly working. please check this problem.
thank you so much. |
|
(0002731)
cccleaner
2020-08-15 17:40
|
I was just trying to find out if other people have same issues in other forums and I am wondering why there are not more people noticing the same.
I thought MadVR is THE one and only filter out there to get the best HDR experience on a PC. MadVR is mentioned everywhere but nevertheless we have almost no reaction on this issue?
Is there a workaround? Or any config item I do not see? |
|
(0002735)
B1gD4ddy
2020-08-25 17:14
|
madshi????????????????????????????????? |
|
(0002736)
madshi
2020-08-25 19:37
|
This bug report is "assigned" which means I plan to work on it, when I find the time.
Please note that I've *always* recommended to users to stick to Windows 8.1, where you wouldn't have this problem. Also, you could go back to 44x.xx drivers where you also wouldn't have this problem. Also, you could complain to Nvidia for breaking what was once working. It's not a bug in madVR that this doesn't work, anymore. It's Nvidia's fault, they *intentionally* broke the API that madVR (and several games) have been using for years.
IMHO what Nvidia did was bad, not just because they broke a nicely working solution, but also because the new solution they implemented IMHO completely sucks. They got the OS involved, and I fear (although I'll have to double check to be 100% sure) that this will result in the HDR output not being lossless, any longer. With 44x.xx drivers and the old API madVR was able to achieve perfectly lossless output quality. Every bit output via HDMI was fully defined by madVR and not modified by Nvidia drivers or the OS behind madVR's back. I assume that with 45x.xx drivers this will no longer be the case. Which could potentially hurt image quality. But, as I said, I'll have to double check to be sure. |
|
(0002737)
B1gD4ddy
2020-08-25 20:42
(Last edited: 2020-08-25 20:44) |
thank you. would love to hear back from you.
the current workaround is to manually activate winhdr and then start the movie with mpc be madvr hdr passthrough.
do you think that is losless or not?
|
|
(0002738)
madshi
2020-08-25 20:46
|
Most likely not. |
|
(0002739)
B1gD4ddy
2020-08-25 20:48
|
thats shit.
but dont want to annoy you any longer.
would just love to hear back from you in the future when you had time to analyze that more.
thank you! |
|
(0002740)
Cineaste
2020-08-26 06:32
|
madshi, not wanting to add fuel to the fire but it appears Nvidia are playing the blame game:
https://old.reddit.com/r/nvidia/comments/ibfawg/game_ready_driver_45206_faqdiscussion/g1vmsuc/
According to their rep it is an app bug (yours?) and that a workaround will be provided with the next driver. Perhaps you don't need to do anything after all? |
|
(0002741)
madshi
2020-08-26 10:28
|
Haha, sure, it's all my fault. :-D Not.
Nvidia did contact me, they said they changed the way their API works, but that it should still work fine in FSE mode. And I could make it work for windowed mode, as well, by calling some additional APIs.
So yes, I should be able to make it work, by adding more code. But it's a change in API behaviour that Nvidia requires me to do now which wasn't necessary before.
Plus, I was being told that everything should still work fine in FSE mode. Seems that's not the case?
Plus, I fear that the new solution may no longer be lossless, but I can't be 100% sure about that because I haven't tested it yet. |
|
(0002742)
cccleaner
2020-08-26 19:17
|
hello Madshi
Thank you to react! Please understand, there is nothing else than a windows 10 pc as the main center of my multimedia rig anymore. I am directly depending on such problems like HDR Passthrough throuhg Nvidia GFX card to my 75" tv. .
I have no clue how to interact with nvidia in such matters but believe me I need full passthrough through windows 10 and nvidia GFX card with latest GFX Driver at all times..
how can I help you ?
Can we add some AI and Cloud computing to it and use agile mthodology (not) ?
:-)
Sorry.. sometimes I am tired of IT.. |
|
(0002743)
cccleaner
2020-08-28 17:58
|
I just tested the FSE Mode again but I have the same behavior. HDR Mode is not switched on automatically. I have Nvidia Driver 452.06 installed.
What my setup always does when I start a Movie, it switches to 23Hz. (TV turns black for 2 Secs in FSE and Normal Mode, and during that switch HDR was also turned on. |
|
(0002744)
huhn
2020-09-01 00:08
|
what ever it is worth games don't really care about the driver version and HDR work with them.
the only game i tested that nearly for sure uses the nvidia API has some special needs to enter HDR mode.
it only uses FSE at all times and the image(windows desktop) get's totally disrupted when you tab or anything. so i wanted to test the only FSE mode from MPC-HC but that option has been removed for madVR.
i can later try a different game that may uses the nvidia API but that game doesn't even have finished HDR support... |
|
(0002745)
B1gD4ddy
2020-09-17 15:31
(Last edited: 2020-09-17 15:37) |
good and bad news guys.
nvidia stated in changelog of new driver 456.38 that they fixed the issue.
[madVR][MPC-HC]: Various HDR issues occur when using the madVR renderer with MPC-HC. [3038381]
but thats only halftrue, in fact they added more annoying things.
while it is true that when you now start a movie via mpc-be madvr hdr passthrough windows hdr indeed keeps being turned off, but hdr is still applied to the whole screen instead of only to the player.
that leads to the problem that as long as the player is windowed it shows washed out sdr. you have to make the player fullscreen so that you finally see hdr.
next very very annoying bugs that got added in this new driver are
1. when you touch the scroolbar of the player to jump through the video the video turns washed out sdr. you have to leave the scroolbar and put the cursor back on the video to make it hdr again.
2. whenever you window/fullscreen the player or resize the player the whole screen flickers atleast 2 times.
3. sometimes when closing the player the screen keeps being extremely brightend up.
tldr: bug: hdr is applied to hole screen instead of only the video player which makes the video washed out sdr until fullscreened + the 3 new problems i described.
|
|
(0002746)
madshi
2020-09-17 15:36
|
> but hdr is still applied to the whole screen instead of only to the player
But that was always this way in 44x.xx drivers (and older)! Or is it different now compared to 44x.xx drivers?
(the scrollbar and flickering things are new, of course) |
|
(0002747)
B1gD4ddy
2020-09-17 15:57
(Last edited: 2020-09-17 16:04) |
no, it was just perfect.
456.38
you start a movie and tv insta activates hdr and the complete screen is brightend up and player shows washed out sdr. you have to go fullscreen to see hdr. plus the problems 2 and 3
446.14
you start a movie and tv does not turn on hdr, everything is normal and fine and player shows sdr not washed out sdr. when you go fullscreen tv activates hdr and turns it off when you close player or go windowed.
btw i now also have the scrollbar problem with 446.14...odd, did my memory fool me or is it a windows 20h2 problem? i dont remember havin problem 1 ever.
|
|
(0002748)
madshi
2020-09-17 16:03
|
Ok, I'll have a look at 45x.xx some point "soon". Soon means could be weeks... :-( |
|
(0002749)
Cineaste
2020-09-17 16:20
|
I suppose the above is a non-issue for me since I set up mpc-BE to always start in fullscreen as an external player in Kodi, meaning it used to activate HDR the moment I pressed play for as long as I remember. |
|
(0002750)
B1gD4ddy
2020-09-17 16:25
(Last edited: 2020-09-17 16:41) |
still problem 1 and 3 and maybe the flickering of 2
|
|
(0002751)
huhn
2020-09-17 17:07
|
i only have the "issue" of 3. that it takes a sec or longer to leave HDR mode when the player is closed.
i have a delay when switching between full screen and windowed but nothing major windowed HDR works totally fine here to even through the windows desktop is over saturated |
|
(0002752)
B1gD4ddy
2020-09-17 17:11
(Last edited: 2020-09-17 17:15) |
my 3 is that it stays ultra bright.
yes windows desktop is over saturated since hdr is applied to the whole screen, no matter if player is full screen or a little window, unfortunately
you have no hdr turnoff when using or hovering over scrollbar of player when in fullscreen hdr movie with 456.38?
and no screen flickering when resizing player with 456.38?
|
|
(0002753)
huhn
2020-09-17 20:32
|
no none of that but i'm using overlay rendering. |
|
(0002754)
cccleaner
2020-09-18 16:45
|
indeed very special behavior:
(not using FSE:)
when I start a HDR movie my TV switches into HDR Mode although windows is not switched automatically to HDR mode (before windows always fully switches to HDR)
Desktop colors seem to be oversaturated little bit but this is because the frequency changes to 23Hz I thinks.
When I go fullscreen with MPC BE the HDR seems to be correct and when I move the cursor down the slider appears and the movie goes back to SDR washed out.
So it seems the player makes an isolated HDR pass through not touching the Windows setting and my TV recognizes the HDR Stream directly from the player. As soon as a windows overlay jumps in the setting does not apply anymore and uses the windows setting (no HDR Mode)
that is indeed very new.. For me it is till not clear how I should use HDR on a windows PC. Movies and Games should switch my TV to HDR when started like before?
Or can I always switch HDR Mode on?
I'd love to leave windows always in HDR mode but the OS seems still not to be designed to have a beautiful HDR Surface..
So what does the Windows HDR mode stand for anyhow? |
|
(0002755)
B1gD4ddy
2020-09-19 08:49
(Last edited: 2020-09-19 10:13) |
hey buddy,
did you read my last posts?
you experience the exact same 456.38 behavior as i do and don't forget the 2time flickering i described.
and i noticed when i go back to 446.14 i still have the touch-slider-hdr-gone-thing.
i don't remember having this when 446.14 was current. do you?
maybe a win 20h2 problem?!
|
|
(0002756)
ParadoxDelta
2020-09-19 16:42
(Last edited: 2020-09-19 16:42) |
Not entirely shure if this is related: I got NV HDR working with MadVR 0.92.17 and driver 452.06 by right clicking the .exe of MPC-HC and PotPlayer -> Properties -> Compatibility -> and checking "Disable fullscreen optimization". Now the faded colors disappear when I enter exclusive fullscreen mode. Worked for both players.
|
|
(0002757)
B1gD4ddy
2020-09-19 16:53
(Last edited: 2020-09-19 16:55) |
we already have nv hdr fullscreen working since win hdr is turned off and keeps being turned off when starting a movie with madvr hdr passthrough and 456.38.
that never was a problem.
but we have alllll the other problems i listed.
btw i started a thread in geforce forum, got insta 3 downvotes and got told im too dumb to use madvr...oh the humanity...deleted the thread in this cancer forum again.
maybe someone else wants to try.
|
|
(0002758)
cobravision
2020-09-20 15:35
|
I recall when using madvr for the first time around April 2019 that any change from fullscreen (windowed or activating OSD) would disable HDR passthrough and change the colors and switching out of HDR caused the screen to blink. There was some driver change that I can't pinpoint where HDR passed through at all times. |
|
(0002759)
cccleaner
2020-11-24 14:25
|
Hi all
Sorry for late reply.
@B1gD4ddy: unfortunately I cannot remember when exactly the issue started. I did not check after all windows and updates carefully enough.
At the moment with 4Nvidia 457.30 and Windows 20H2 OS build 19042.630 everything seems to be working. Windows however does not switch to HDR Mode anymore and when I touch the slider the Player switches from HDR to SDR. So far I can live very well with this.
However please allow me to mention the following on my current odyssey to hit the perfect screen refresh rate of 23.976Hz for my mkv files, which in the end actually even confused me much more. I was not sure anymore about if the player is really sending 10bit HDR content to my Samsung 10bit Panel or not:
When I checked the Overlay Information of my player I noticed that my display is almost at 23.976Hz but only > (8bit, RGB, full)
Further in fullscreen the next output information was displaying D3D11 windowed fullscreen (8bit)
so all this confused me even more (madVR is REALLY doing a superb job regardless if you use HDR or the HDR simulation on SDR, the difference is not obvious) and I started to mess around with the settings again to head for REAL 10bit HDR output with following conclusion:
It is out of a sudden possible to switch Nvidia Driver to 23Hz AND 12bit(!) output color depth, while color format is RGB and output dynamic range is Full. And when the player switches to 23Hz the color depth remains at 12bit (!?) Is this new or was I just sleeping?
GREAT!
the D3D11 output in my app chain (MPC BE, LAV Filters, madVR) can obviously only be set to REAL 10bit output if I disable the ThumbNailPreview Service for Icons in the Windows Explorer View Setting. This Service is obviously producing a windows layer over the player that lets it stick to 8bit (and yes this holy crap I only figured out by using the thankful debug mode.)
GREAT!
So only now I am really sure that my setup outputs 10bit HDR content to the Samsung Panel.
My only issues for now is I have still some juddering when I activate the Smooth Motion in the Samsung Options. I still dont get it how I setup the perfect 23.976Hz. (tried CRU utility, Windows Custom Resolution)In fast motion pictures I have judders and blurs and small black and white detailed patterns are starting to flicker badly.
It is clear that the Smooth Motion Option has issues with this, but I think the root cause is based on this unbelievably complicated pull down between frames and frequency.
That mess is hopefully finally soon resolved with the new worldwide standardized and harmonized media presenting technologies ((I forgot the name of this new Master Film Studio Standard)
So to cut a long story short: for me its almost everything perfect, I believe I really get what my hardware is supposed to be delivering.
Looking forward to 4k120Hz, replacing again GFX Card, AV Receiver and TV ;-) and thanks again to madshis superb work. |
|
(0002795)
B1gD4ddy
2021-03-10 13:34
|
with new nvidia drivers hdr passthrough works again.
also no hdr off for me when putting mouse on scroll bar.
but as madshi said the passthrough is not lossless anymore.
i hope he can do something about that. |
|
(0002799)
Sym3
2021-05-22 05:56
|
After days of searching on why i my screen keeps going black when i move the mouse over to seek bar (back and forth)i ended up here. Is the issue I'm describing same as this 0000660?
There is a workaround i found to stop this black screen on and off issue by using Potplayer Direct3d11 from skins-->on screen control and using d3d11 in lav decoder, down side is i can no longer use seek bar but if i enable preview i can hover the mouse around to get timeline. |
|
(0002800)
madshi
2021-05-22 09:00
|
There are different ways to render a seekbar. The way Nvidia HDR currently works is that it's active only if the playback is fullscreen. If the seekbar results in the video no longer seeming to be fullscreen to Direct3D, then HDR gets deactivated, which will result in the display resyncing. There are ways to render a seekbar in a way that doesn't lose fullscreen mode, though. I'm not a PotPlayer expert, though. I don't know which option it is you have to toggle there. |
|
(0002801)
Sym3
2021-05-24 10:27
|
I was just using potplayer as an example cause i was able to "fix" the switching at the cost of seekbar not being visible anymore. Any workaround for mpc-hc player? Seems like MPC video renderer (https://github.com/Aleksoid1978/VideoRenderer) is a decent alternative at the moment for HDR passthrough without glitches but the upscale and downscale filters are a downside compared to madVR. |
|
|
Notes |
(0002774)
madshi
2021-01-31 08:48
|
Does this also occur using the latest HDR test build?
http://madshi.net/madVRhdrMeasure122.zip
Btw, using a 3DLUT for HDR tone mapping is no longer recommended because it results in static tone mapping, while the latest HDR test builds do very high quality dynamic tone mapping. You will need a reasonably fast GPU to use those new algorithms, though. |
|
(0002775)
goraelec
2021-01-31 17:55
|
Yes, build 122 also has this issue. I'm using 3DLUT for HDR in order to correct some of its inaccuracies in the neutral axis. Is there any way to have dynamic tone mapping with 3DLUT in the future? |
|
(0002776)
madshi
2021-01-31 18:00
|
You can let madVR do dynamic tone mapping and combine that with a BT.2020 or DCI-P3 SDR 3dlut. That should give you the best of both worlds.
Actually doing calibration while sending the display HDR is rather questionable because the 3DLUT cannot really know what the display's tone mapping algorithm will do. Unless it's so simple and stupid that it's predictable for the 3DLUT, but if it is, then it must be really bad. |
|
(0002777)
goraelec
2021-01-31 18:08
|
It's simple and stupid in my case. It has FALD, and in each zone, it looks at the brightest pixel and sets the backlight brightness to that value, but it does not exceed the maximum content light level (at least, this is what I observe) |
|
(0002778)
goraelec
2021-02-01 00:46
|
It would be great if there was a way to determine how tonemapping works on a display precisely using madTPG and measurement software like ArgyllCMS and find ways to correct for that |
|
(0002779)
madshi
2021-02-01 00:54
|
That's a job for the calibration software, not for madTPG. madTPG simply renders whatever test pattern the calibration software asks for. How to actually make use of the measured data is the job of the calibration software. |
|
(0002782)
omarank
2021-02-02 18:28
|
Interestingly, I too have been thinking about HDR dynamic tone mapping via 3DLUTs. I think I should describe my idea:
madVR's dynamic tone mapping has two attributes which are dynamic:
1. Dynamic max light and tone map target calculation: madVR dynamically calculates a rolling-average based max light for each frame/scene and also the dynamic target for tone mapping (if DTN is enabled)
2. Dynamic colorimetric processing: madVR dynamically adapts the tone mapping curve depending upon the max light and the dynamic target etc.
For dynamic 3DLUT tone mapping, madVR should just expose the settings/functionality for 1. Even in that, it should just provide the settings for determining the max light (i.e. the optimized maxCLL per frame/scene) and expose the max light as a profile variable. The user can then set up profiles to use different HDR 3DLUTs for different max light ranges. So, when an HDR video is played, madVR will switch between different 3DLUTs depending upon the max light value of the frame/scene.
Certainly, there may be brightness jumps in certain places (or maybe you can take care of them), but all in all it should be possible to have a good dynamic tone mapping experience with 3DLUTs taking care of tone mapping.
What do you think? |
|
(0002783)
madshi
2021-02-02 18:58
|
This is a bug report. I don't think it's the right place to discuss potentially adding support for dynamic tone mapping with 3DLUTs.
Anyway. madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable. In any case, there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention. |
|
(0002784)
omarank
2021-02-03 09:14
|
I understand that this may not be the right place to discuss this idea. So, I will not continue here. But I will just make some remarks. My comments are inline:
"madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable."
Yes, I understand that madVR adapts the tone mapping curve within scenes too. But that is the colorimetric aspect of madVR's implementation, which we are not concerned about for 3DLUT based tone mapping. A 3DLUT is always going to be a static tone map. I was referring to a very basic dynamic implementation, where on the basis of the range in which maxCLL lies, madVR gently switches between LUTs. And all that interpolation or any complex processing is not really needed. Nor we need a large number of LUTs. Typically, I and others (some projector owners who I provided HDR tone mapping+calibration LUTs) felt just the need for two 3DLUTs. One for very dark scenes and the other for all other scenes. Basically, people were quite satisfied with my LUTs except for one issue that the dark scenes were looking too dark. I believe with just 2 to 4 3DLUTs, the users can have a very good HDR experience with dynamic tone mapping.
"there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention."
Fair enough. Maybe I can bring this up again in future to hear your thoughts then. I will just share my perspective though:
madVR's HDR tone mapping is quite resource intensive. I am sure you will optimize it, but still it is going to be heavy. 3DLUT based tone mapping can provide flexibility to some users to allocate more resources to scaling algorithms or other processing algos or use less powerful GPUs while still getting a good dynamic tone mapping experience.
madVR already supports tone mapping HDR LUTs, so why not make that feature more useful? |
|
|
Notes |
(0002701)
madshi
2020-05-27 18:49
|
IIRC, the DisplayCAL dev made some improvements to help with issues like this, but it seems you're already using the latest DisplayCAL build, so I'm not sure what it could be. Are you using WLAN or wired LAN? Try wired LAN, maybe?
Might make sense to ask once more on the DisplayCAL forums? After all, the threads you linked to are both from 2018, which is quite some time ago. |
|
(0002704)
phbgjf
2020-05-28 12:36
|
Now that you say that I am going to try with the firewall disabled. Not that I'm positive with that since I could get some calibrations with 79 patches. Florian is very intermittent and all I could read from him was to run as admin or reinstall madVR, which I already did -as admin- (it's a trivial thing). |
|
(0002709)
phbgjf
2020-06-19 10:49
|
I tested with firewall disabled and had the same issue. And again only profiling with 79 patches finished successfully. Would like to run longer tests for more accuracy. |
|
(0002710)
madshi
2020-06-19 16:04
|
Are you using the official madVR build? If so, maybe you can try this one, as a test (just overwrite the files)?
http://madshi.net/madVRhdrMeasure113.zip
I'm not sure if that will change anything, though, but might be worth trying, due to lack of better ideas right now. If DisplayCAL has a "madHcNet32/64.dll" in its directories somewhere, also please replace that with the latest build from the zip above. |
|
(0002712)
phbgjf
2020-07-16 12:30
|
I tested yesterday and overwrote the folder, curious not to see madTPG there.
It failed again at 175 patches. I think it might have to do with network settings, I had issues connecting to my laptop in the past as a local network. But I just don't know what's required for madVR to communicate, open ports, remote access, and so on... Also I use tinywall firewall, in case that's a known issue.
On another note, I observed an issue on the calibration targets, they (or maybe only the blue one) is off compared to DisplayCAL Rec.709 targets so I can't use the same monitor hardware settings for both madVR and Windows. I will open a ticket if there's none open already. |
|
(0002713)
phbgjf
2020-07-16 16:15
|
I was using a correction file so forget about the color targets thing. |
|
(0002715)
phbgjf
2020-07-20 16:25
|
Ok, have been trying to calibrate my monitor for the last two days without success after about 10 attempts (testing different things).
I'm a little bit fed up so I went and created a madVR LUT out of my previous monitor calibration (large patch count). Is this ok or does madVR targets have something different than default? |
|
(0002716)
madshi
2020-07-22 00:17
|
Sorry for the lack of replies. I'm currently extremely busy. Some weeks from now I might look into the whole topic of calibration once more. Right now, there's not too much I can say. Whether or not you can convert your previous monitor calibration into a madVR LUT with DisplayCAL is not something I know. Might make more sense to ask that question in the DisplayCAL forum. |
|
(0002717)
phbgjf
2020-07-22 14:15
|
No prob. I asked already there. Will report back if doing so is an option (as a workaround at least). |
|
|
Notes |
(0002667)
madshi
2020-02-20 17:10
|
Have you forced the Nvidia GPU to RGB Full Range output? That's the recommended configuration. |
|
(0002673)
zeus0r
2020-02-21 11:22
|
okay, now i'm even more confused.
i'm pretty sure i actually chose "RGB/full range/12 bit" in nvidia settings but when i just checked "YCbCr/limited/8 bit" was active. and even weirder: i can't change it to RGB, it's just not there.
so i changed the resolution to 1080p/60 (2160p/60 before) and then i can pick RGB/full/12bit. so i checked black levels again but the problem was still there:
0-255: correct SDR black levels but greyish blacks for HDR content
16-235: correct HDR black levels but bad black crush for SDR content
then i tried pretty much every combination possible and with RGB/limited/12bit: correct black levels for SDR and HDR.
wtf?! why can't i choose RGB with 2160p anymore? and why is limited the correct choice now when it was full range before?! |
|
(0002674)
madshi
2020-02-21 13:09
|
Not being able to choose RGB for 2160p60 means that whatever device your HTPC is connected to (display or AVR or whatever) seems to report that this device's HDMI port doesn't have enough bandwidth for 2160p60 RGB. The HDMI input port of the display/AVR needs to be 18Gbps for that to work. Seemingly it's only being reported as 10Gbps instead.
I don't know why RGB Full doesn't work for you. It works for most other users, including myself. Not sure how to fix it. It's probably some sort of Nvidia driver issue. Try reinstalling the Nvidia drivers in "cleanup" mode, maybe? |
|
(0002675)
zeus0r
2020-02-21 13:40
|
okay, interesting. i'll try that, thank you! |
|
(0002676)
huhn
2020-02-21 15:51
|
there are more than one report of user needing or getting different level between HDR and SDR in the past days.
if listed they where Phillips Tvs. |
|
(0002702)
Deam
2020-05-28 04:49
(Last edited: 2020-05-28 04:50) |
I would just add to this, and it may very well be an Nvidia bug. I am using MadVR with Kodi DS player (for HDR passthrough). Win 10, GTX 1050ti, Vizio P659-G1 Tried latest drivers and reverted to older ones.
Specifically, if I leave it as a "full" color space path (i.e. MadVR, Kodi DS Player, Nvidia CP and TV), SDR works fine, as confirmed with test clips for black level clipping. However, once I try HDR, the black levels get blown out (such that the entire black level clipping video turns grey and I can see all the bars whether or not they are flashing).
If I then set the TV to limited range (or set Nvidia control panel to limited and leave TV to auto), HDR works. However, unlike the issue noted, my SDR is also displayed correctly verified with clipping test videos.
I'm just noting this here, as it may not necessarily be a MadVR issue as this issue occurs for me when using other Kodi HDR forks that rely on Windows HDR API and not MadVR. I am forced to have the GPU set to limited as I use the PC for other purposes and thus can't have the color clipping using the other options.
|
|
(0002703)
madshi
2020-05-28 11:09
|
If you can, it's always a good idea to force your display to treat the HTPC input as having specific levels instead of using "Auto", for the simple reason that the HTPC doesn't always inform the display about the correct levels. Nvidia sometimes reports the levels to the display which you set in the Nvidia GPU control panel, and sometimes Nvidia doesn't report any levels at all, so the display has to guess.
However, if you're talking about HDR passthrough using Nvidia's private API (= *not* turning the OS HDR mode on), then I think it's more likely that Kodi might be doing something wrong, like e.g. rendering TV levels although Kodi is set to PC levels. But I can't say for sure. Just guessing here. My personal experience with madVR is that HDR passthrough works fine and doesn't screw up levels, but maybe it depends on the circumstances, driver version or whatever. |
|
(0002705)
Deam
2020-05-28 17:46
|
Thank you, Madshi. Yes, I have just set the TV to accept YCBCR (limited range) for the time being - the issue being this combination of factors requires the less optimal setting of the GPU doing a color space conversion.
It's a Vizio television, and you are correct, it could be a Kodi/DS Player issue, or possibly an issue with the TV receiving a full range signal with HDR metadata. I've read it can be "resolved" by lowering the brightness from 50 to 32 (though I also understand you shouldn't really fiddle with the brightness slider in HDR mode as this doesn't so what it normally does).
I have a ps4 pro and may test forcing it to use rgb full range and engaging hdr to see what happens with the tv. I’ll have to wait until evening as it’s too bright to really see anything.
Thanks for the feedback (and recognize this may not be a Madvr bug at all, so am appreciative of that) |
|
(0002706)
madshi
2020-05-28 23:24
|
FWIW, HTPCs are inherently bad at outputting YCbCr. Usually it's recommended to set the GPU control panel to RGB with PC levels. |
|
(0002707)
Deam
2020-05-29 05:25
(Last edited: 2020-05-29 05:36) |
It appears for this combination of equipment that I am using I won't have a choice. For posterity (as this is nothing to do with MadVR), I tested the combination with the PS4 Pro running in HDR. I set it to RGB/Full. However, it sends HDR in YCBCR regardless of that setting (so limited color space). This was confirmed by checking the receiver signal, which shows Bt2020 YCBCR vs. BT2020 RGB that the PC sends if left in RGB full. And setting the TV's color space to auto worked as expected. I'm not sure if keeping it at least in RGB format going into the TV, albeit at limited range, is better or worse than having the GPU convert to YCBCR as you've noted.
I'm left to conclude that it may be something with the TV, or the receiver and TV, in which an HDR signal being sent through RGB (full) causes problems requiring a change in the brightness setting in the HDR picture mode. This wouldn't necessarily be a problem, except given the receiver there is only one input being used in the TV and so it would required changing the picture mode/settings going between the PS4 Pro and the PC.
One solution I will look at is whether I can change, in Nvidia Control Panel, the color range for different resolutions, such that when it switches to 23hz it goes to limited RGB, but reverts to RGB full at 60hz.
|
|
|
Notes |
(0002583)
tomeq82
2019-11-29 20:18
|
If there is need for more debugging, reproduction scenarios etc. i'm ready - quite power user so nothing really scares me much ;-) |
|
(0002584)
tomeq82
2019-12-01 17:16
|
I have performed some debugging myself and the problem seems to be in the way the madVR is trying to do exclusive fullscreen mode, switch to fullscreen or some sort of interop between MPC-HC:
- when I set the player to start playback in fullscreen mode+switch screnmode when playback starts, the video starts playback, but after "initialization" it drops back to window + desktop. This causes 3 times switching the resolution: from desktop resolution 4k 60hz, to 4k 24hz, then back do desktop and if I want full screen I need to AGAIN push MPC-HC to fullscreen. My TV is switching the resolution for 3-5 seconds (Panasonic TX-50CX700E) so this is extra annoying.
- setting MPC-HC to not go to fullscreen+set madVR to switch screenmode when playback starts, ofcourse removes one mode switch, but still screen blinks during madVR init and additional action is needed from me (go fullscreen after playback start) - this is safest setting
- setting madVR to switch to matching display mode when media player goes fullscreen + set MPC-HC to go fullscreen after playback starts causes drop to desktop from fullscreen, mode swtiching many times and usually "forever pause" or black window, no video,just audio. This is worst setting to have in my scenario.
- when I set "delay playback start until render queue is full" mostly 100% of video launches with mode switching ends in "forever pause" mode. No matter what other settings are set to.
- when I set "delay switch to exclusive mode by 3 seconds" it ends in audio only video, black screen or current frame stand still. Same as above it kills playback.
I must say it is a mess. I never managed to have stable solution for this and dropped using madVR in my htpc setup. |
|
(0002585)
madshi
2019-12-01 17:19
|
Have you tried using windowed mode instead of FSE? In Windows 10 fullscreen windows mode is not so bad. |
|
(0002586)
tomeq82
2019-12-01 18:16
|
I tried - the effect is less painful indeed but MPC-HC never enters fullscreen automatically in that mode. Despite the setting explictly set to start playback in fullscreen, It ends in a window on desktop, I need to manually go fullscreen (doubleclick, alt+enter whatever) None of the madVR settings in windowed mode caused MPC-HC to go fullscreen automatically. |
|
(0002587)
madshi
2019-12-01 18:21
|
That's weird, that seems to work for me. I also don't have the FSE problem you're reporting. Sadly, HTPCs are a mess and every user has different issues. |
|
(0002588)
tomeq82
2019-12-01 18:52
|
Hm, I meant "htpc" is a normal computer for home entertrainment, nothing sophisticated :) nVidia 1050Ti, Pentium G4500 Gold and B360 chipset based board. All standard. The only thing I didn't change since I had those issues is the TV and AVR receiver. Reinstalled windows number of times, I tried with 1030 card and Intel GPU with DP-> HDMI active converter (which caused separate set of problems with 4K output). What puzzles me much is why the player skips out to windowed mode no matter what. It looks like it times out waiting for TV to change display mode and skips out to "safe" mode which is desktop? Is it possible at all? |
|
(0002589)
madshi
2019-12-01 18:55
|
The PC doesn't know or care when the TV switches. That information isn't sent through HDMI. |
|
(0002590)
huhn
2019-12-02 00:43
|
i had this problem too.
with pretty much the same TV TX55CXW704. pretty sure it had nothing todo with it but just saying.
there are 2 different "types" of FSE on windows now.
the normal one that allows overlays from the notification centre, game DVR, geforce experience and so much more. which could be the issue.
sou you could try getting rid of these for a test.
use with cautious:
then we have the original FSE which can be accessed by right clicking the mpc-hc64.exe -> properties -> compatibility -> disable fullscreen optimisation. |
|
(0002591)
tomeq82
2019-12-02 08:33
|
Will do some tries with FSE and disabling all overlays (I think I did but I will check again), but let's say I will stick to windowed mode - as it seems switching screen modes is the real issue here.
When video is launched via mpc-hc -> open file, it willl never get to fullscreen, it will stay on desktop I need to make it fullscreen manually, but here we will have 100% of success in playback, it will switch screenmode, etc.
When I open video via "open with" or doubleclick video icon it will go fullscreen (i see fullscreen logo of mpc-hc for a while), change screen mode and most probably:
- drop from fullscreen to mpc-hc window, but video can be played then (it will normally run)
- stay fullscreen (yay! finally!) but will not start playing automatically (why?) and here another problem branching: will end on audio only or forever pause. SOMETIMES it will just play correctly. I tried maaaaany different videos to find any common denominator, which video plays normally, which don't. I'm unable to.
Ofcourse none of the issues are here when the screenmode is already set or I don't use screenmode change feature in madVR. |
|
(0002592)
madshi
2019-12-02 09:54
|
> disable fullscreen optimisation
I didn't even know that one! |
|
(0002593)
tomeq82
2019-12-02 14:27
|
checked - no overlays, nvidia or Windows Game Overlay enabled. Disabled full screen optimization for mpc-hc64.exe. Same story. No change. Just to be sure, checked with FSE and windowed fullscreen. No change in behavior.
Expected behavior is:
- MPC-HC has option "start playing in fullscreen enabled"
- despite the option in madvr is set: FSE or windowed fullscreen I got video played on fullscreen :) no matter if "doublecliked" video icon, used "open with" from right click menu or "open file" in MPC.
This is something I can't achieve.... |
|
(0002594)
tomeq82
2019-12-02 15:18
(Last edited: 2019-12-02 18:55) |
attached debug with FSE enabled, 4K HDR file opened from right click, open with. Screenmode changed, then black screen. Didn't even started and ctrl+j not able to open....
second log is with disabled delay playback until render queue is full. It gets further though not without a problems. Audio is on, video is "one frame" and debug memu pops-up.
|
|
(0002600)
kristoffer
2019-12-16 19:36
|
I just wanna chime in and say I think I have the same issue.
Just built a new pc primarily for use with mpc-hc and madVR, and have been sorting through issues for two days now.
Although my issue doesn't seem to occur all of the time, more like in cycles. Last night it worked well, today i'm having issues 80-90% of the time.
I'm using the same software, and also have an nVida gpu (2070rtx). |
|
(0002601)
tomeq82
2019-12-16 20:27
|
@kristoffer, you say "cycles" I would say bugless playing depends on if I do fresh restart of the pc or if the pc is working for a while and display is being switched to pc. Those two scenarios differ, it fail when I switch my audio receiver to pc and try to play video. |
|
(0002602)
kristoffer
2019-12-16 22:32
|
That resembles my experience. last night for whatever reason I rebooted my pc, and it was working fine afterwards. Don't recall why I rebooted, could be when I tried to re-install mpc-hc and madVR. Today it didnt work.
Anyways, I've settled with your workaround for the time being, opening my movies in windowed mode before I go fullscreen.
If I can help with anything to figure out this bug just ask. Just tell me how and i'll provide logs and try stuff. |
|
(0002690)
Daniel715
2020-04-23 17:26
(Last edited: 2020-04-23 17:36) |
I have exactly the same bug but I can confirm it 100% depends on the File.
I encountered this issue recently and have confirmed that some Files (mkv) regardless of SDR or HDR just can't start playback, you can skip in the File and you get a proper still image but it is impossible to start playback.
I have not found a solution for this yet and it's very annoying.
The only thing i noticed is that in the madVR OSD it shows that on the "faulty" Files the "present queue" hangs at 1-1 / 8
My System:
Win10 1909 Build 18363.778
Nvidia RTX 2070 Driver 445.87
MPC-BE 1.5.4
madVR 0.92.17
File 1 "RO HDR" works not
Mediainfo:
https://pastebin.com/8FJ8wr7E
madVR OSD:
https://imgur.com/a/ZyVAJn3
File 2 "KDL SDR" works not
Mediainfo:
https://pastebin.com/L4vGL99W
madVR OSD:
https://imgur.com/a/4jTDHut
File 3 "KDL HDR" works not
Mediainfo:
https://pastebin.com/We5UdtBC
madVR OSD:
https://imgur.com/a/1a9roNX
I want to help resolve this so ask me anything
Greetings
|
|
(0002693)
Daniel715
2020-05-03 15:47
|
Heres another 3 Files that don't work:
File EP1
Mediainfo:
https://pastebin.com/pHf0iuxz
madVR OSD:
https://imgur.com/a/35QiDZl
File EP2
Mediainfo:
https://pastebin.com/yXbL2rU4
madVR OSD:
https://imgur.com/a/j9kR0Ow
File EP3
Mediainfo:
https://pastebin.com/GiYd82f5
madVR OSD:
https://imgur.com/a/ZaqcvAo
Seems like the files that can't play get more common since recently.
Greetings |
|
(0002694)
cgbug
2020-05-03 22:43
|
Could be an audio driver issue. Test with NULL audio renderer. |
|
(0002695)
Daniel715
2020-05-04 21:20
|
@cgbug:
I just confirmed it is not related to the audio driver.
It is unclear to me why these files can't play back properly but still show the correct still image if you seek around.
Maybe it is some weird encoding that madVR can't handle?
I don't know and we still have to hear from madshi, maybe he has some advice.
Is there a way to output a log file for further diagnostic means? |
|
(0002696)
cgbug
2020-05-04 22:38
|
madVR can handle such files without issues, and the player/codecs that you use as well.
Test with DXVA hardware decoding disabled in the player. If that works the problem is the fault of the graphics driver. |
|
(0002697)
Daniel715
2020-05-05 19:11
|
I'm not using DXVA at all as you can see in the madVR OSD screenshots.
I also tested going back to the previous Nvidia Driver since some users on doom9 reported issues with the latest 445.87 and HDR. But it didn't solve it.
Its very unlikely that the graphics driver or the player is the issue here.
Since most Files play without issues, it is just on some files where it can't start playback.
The issue is somewhere in the "present queue" since the decoder, upload and render queue are full. |
|
|
Notes |
(0002612)
mclingo
2020-01-09 17:16
|
Hi, just some more info on this from user DMU on doom9, this is a support request he sent in to AMD which I dont think he's had a reply on yet, just thought it might be useful to you in case you had any ideas on a workaround as going forward its likely all new AMD will have this bug of this generation and it hasnt been fixed for months, so might not get fixed.
Hi there.
You have entered support for HDR mode. The agsSetDisplayMode() function used to set a specific display in HDR mode, does its job perfectly: it sends metadata to the display device, which is defined in section 6.9 «Dynamic Range and Mastering InfoFrame» according to Table 5 of the CTA-861 standard. But in the same Table 5 there is also «Auxiliary Video Information (AVI)» defined in section 6.4. And all display devices are required to use the color space (colorimetry) from this data section (AVI InfoFrame) for the current video signal.
Suppose we are in SDR mode with the standard sRGB color space. And we want to switch to the HDR mode with the BT.2020 color space, which is the main one for this mode. By calling the agsSetDisplayMode() function, we put the display device in HDR mode. And we see distorted or unsaturated colors. This is because the display device did not receive the corresponding flag from the GPU in the AVI InfoFrame and is trying to display our BT.2020 color space in its sRGB.
Please tell me, do you think that such HDR support in AGS_SDK is sufficient? If yes, then advise what else needs to be done so that the display device passes into the correct color space when activating the HDR mode using AGS? |
|
(0002645)
DMU
2020-02-12 07:29
(Last edited: 2020-02-12 13:06) |
Received response from gareththomasamd.
https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK/issues/33
Cool, but with 20.2.1 version the AMD AGS HDR does not work at all.
|
|
(0002646)
madshi
2020-02-12 16:27
|
AGS HDR has a few requirements, e.g. it has to be D3D11, fullscreen and 10bit. Are all those requirements met in your case? Which is the last driver with which AGS HDR worked at all for you? |
|
(0002647)
mclingo
2020-02-12 16:32
|
Hi, yeah I have all those requirements in place, the fact that HDR works in MADVR with windows HDR turned on it quite telling though, it suggests that windows is locked at BT2020 and overrides MADVR somehow. with the 5700 series none of the drivers have worked with MADVR HDR unfortunately :(
So thw workaround right now is to turn on windows HDR then use video app + MADVR as normal, this works fine but it looks like we'll need some sort of force BT2020 switch in MADVR for AMD NAVI cards for the forseable future. |
|
(0002648)
madshi
2020-02-12 16:35
|
Oh wow, so the dynamic HDR switch doesn't work at all with 5700, with any driver version? That's disappointing, for sure.
Have you tried the sample garththomasamd linked? Does that sample have the same problem? Or does that sample actually manage to switch to HDR mode, with the OS HDR switch turned off? |
|
(0002649)
mclingo
2020-02-12 16:44
|
Hi, no its never worked, its a shame as its a really great card with MADVR, just glad there is a workaround as your recent tone mapping work is incredible.
I had a look at those links and could not find the actual samples other than some freesync stuff. i'm currently downloading everything on there but its taking ages for some reason. |
|
(0002650)
madshi
2020-02-12 16:46
|
Thx, glad you like my tone mapping!
Would be great if you could find and test that sample. If that sample works, maybe I can figure out why madVR doesn't. But if the sample also fails, then it's clear that it can't be madVR's fault. |
|
(0002651)
mclingo
2020-02-12 16:54
|
they all look to be code samples no actual video samples as such, I cant see anything to test i'm afraid. |
|
(0002652)
madshi
2020-02-12 16:56
|
So just source code, no EXE files to run? That's a pity. No time atm to compile that stuff for you. Maybe garththomasamd can provide a simple EXE sample for you to try?
Might help if you told him that madVR worked fine with AMD 4xxx series (using AMD AGS), but never worked with AMD 5xxx series? |
|
(0002653)
mclingo
2020-02-12 17:11
|
ive asked for a sample but I dont think we'll learn anything to be honest, I think we're all now sure its not a MADVR issue as it still works with last gen RX400/500 cards and they are using the same API, it must be something to do with the NAVI driver itself. |
|
(0002654)
mclingo
2020-02-12 18:48
|
thanks for having a look though, we know you're super busy with envy / tone mapping. |
|
(0002655)
DMU
2020-02-12 20:55
(Last edited: 2020-02-12 21:05) |
I can check using HDFury. But I am not a programmer and I can not create code for verification. And the following is required:
https://gpuopen.com/using-amd-freesync-premium-pro-hdr-code-samples/
---------------------------------------------------------
After confirming the monitor supports HDR, the swap chain is created using standard DX12 code. It is important to initialize its color format to the required HDR color format that we want to support. This would be DXGI_FORMAT_R10G10B10A2_UNORM for DisplayNative or Gamma22 and DXGI_FORMAT_R16G16B16A16_FLOAT for scRGB. The app also needs to setup its window to get exclusive full screen mode via the Windows® API. This is achieved by creating a window with borderless full screen flags and making its size and resolution match that of the monitor.
---------------------------------------------------------
All that is needed is to create a full-screen window according to their requirements. And I will launch the AGS in it.
PS
This problem concerns not only AMD Navi video cards, but Vega too.
|
|
(0002656)
mclingo
2020-02-12 21:21
|
sorry you're quite right, its just polaris which isnt affected I think.
let us know what you find out DMU |
|
(0002657)
madshi
2020-02-12 21:33
|
> After confirming the monitor supports HDR, the swap
> chain is created using standard DX12 code.
FWIW, madVR uses DX11. But other than that, all the requested details are fulfilled by madVR. |
|
(0002658)
huhn
2020-02-13 00:36
|
polaris cards work totally fine with your current code as confirmed.
so you have to yet again workaround a driver bug if you want to change something about this situation.
maybe it works with dx12 correctly. who knows. AMD doesn't seem to really care about video playback at the moment and other stuff that doesn't crash the driver. |
|
(0002659)
mclingo
2020-02-13 01:06
|
i guess if we could find a game that uses dx12 and amd api we could test that theory Huhn, i had a look for one a while back but its impossible to get this sort of info without looking at every single game in detail one by one. |
|
(0002660)
DMU
2020-02-13 08:31
(Last edited: 2020-02-13 08:34) |
Microsoft has a sample DX12 fullscreen code.
https://github.com/microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12Fullscreen
I tried to introduce the AGS HDR into it - the result is negative (no BT.2020 flag).
But I'm not a programmer, maybe I did something wrong.
|
|
(0002662)
mclingo
2020-02-17 17:00
|
Hi Madshi, do you think you'll be able to create some sort of workaround within MADVR itself at some point when ENVY is released, it doesnt look like AMD are going to move on this any time soon with all the other issues they have at the moment. |
|
(0002663)
madshi
2020-02-20 16:57
|
As you said earlier:
> I think we're all now sure its not a MADVR issue
So I'm not really sure what I could do here. |
|
(0002664)
mclingo
2020-02-20 17:05
|
Hiya, could you maybe set MADVR to always force BT2020 output for all HDR movies somehow, or maybe create a switch we can turn on or off using a profile?
The fact that it works fine in MADVR when windows HDR is also turned on suggests that MADVR can be forced to output BT2020, if you see what I mean. |
|
(0002665)
madshi
2020-02-20 17:08
|
My understanding is that it's just the HDMI InfoFrame BT.2020 flag which is missing. Which I have no control over. The pixel data madVR renders and outputs seems to be correct, as far as I understand. |
|
(0002666)
mclingo
2020-02-20 17:10
|
another option would be to add windows HDR API back in so that could be selected over the GPU private API. |
|
(0002668)
madshi
2020-02-20 17:11
|
Windows API is supported. You can manually switch the OS into HDR mode, and madVR should happily output HDR that way. |
|
(0002669)
mclingo
2020-02-20 17:14
|
Hi, yes but it can only be switched on manually, we're already using that as a workaround, is it not possible to bake in windows HDR so that HDR can be turned on automatically like it does for AMD/NVIDIA API? |
|
(0002670)
madshi
2020-02-20 17:15
|
Maybe. |
|
(0002671)
mclingo
2020-02-20 17:16
|
a "use windows HDR" switch that could be toggled in MADVR so it bypasses the other API's |
|
(0002672)
mclingo
2020-02-20 17:17
|
I know you are super busy with ENVY though mate so we're not expecting anything from you at all right now, but something you could maybe think about for V1.0 relese :) |
|
|
Notes |
(0002607)
madshi
2019-12-31 21:24
|
Some media players override the madVR settings. Maybe that's what's happening here? I'm not very familiar with KmPlayer. Maybe there's a setting for that in the KmPlayer options? |
|
(0002608)
totalz
2020-01-02 04:02
(Last edited: 2020-01-02 07:29) |
Actually, I think KMPlayer is now closely and kind of identical to MPC-HP. And I don't think there's any HDR setting in KMPlayer.
After more testing, I found that the issue happens when Windows HDR is off. But then I only enabled the fullscreen exclusive mode while Windows HDR was off. I'm not dare to test the mode while Windows HDR is on. I did try clean install display card driver, but that didn't fix the problem.
Device HDR setting in madvr set to "passthrough HDR to display", and checked "send HDR metadata to the display". Is the HDR metadata for HDR10+ & Dolby Vision?
I'm wondering if madvr has to enter "fullscreen exclusive" in order to passthrough HDR to display. Cause whenever I need to access KMPlayer's menu, the screen goes black, wait 3 sec if that option is checked in exclusive mode. And there are times that I couldn't get the menu, video picture shown, then back to black screen for 3 sec... And color can be all wrong when playback resumes, 50% of times it goes to Black&White. Windows 10 itself could be the issue here when Windows HDR is off.
|
|
(0002609)
madshi
2020-01-03 09:29
|
madVR should never go fullscreen exclusive unless you either have it enabled in the settings, or if the media player overwrites your settings.
The HDR metadata is simple HDR10. Dolby Vision and HDR10+ are not supported at the moment.
For best HDR quality I'd recommend using the latest test build from AVSForum and letting madVR do the tone mapping. That requires a good GPU, though. |
|
(0002610)
totalz
2020-01-03 09:53
|
The effect of switching to fullscreen exclusive mode is very obvious, and I never see that in KMPlayer unless I use madVR as the Video Renderer and enabled fullscreen exclusive mode. Except in this case I couldn't disable it... |
|
(0002611)
madshi
2020-01-03 09:56
|
What does the madVR OSD say (Ctrl+J)? Does it say fullscreen exclusive mode? |
|
(0002615)
dom
2020-01-16 12:17
|
I'm encountering the same issue with MPC-HC.
The display goes black for a moment and then comes back - exact behavior of my display when mode/resolution/whatever is changed.
- Only occurs with MadVR
- Switch to exclusive happens a few seconds after going to full-screen in MPC
- No matter what options are set in MadVR - it always occurs
- All mode-switching and exclusive options in MPC are disabled as well
This is made worse by the fact that I'm also experiencing something sort of similar to issue 0000596 (http://bugs.madshi.net/view.php?id=596).
However, in my case, the image is significantly darker only after the switch has occurred -> dark in FSE and better-looking in FSW - i.e. the other way around.
If I watch the video in normal windowed mode (no full-screen whatsoever) then it looks fine.
-> This is what leads me to believe that the display switch that occurs after a few seconds is to full-screen exclusive |
|
(0002617)
pittyh
2020-01-20 11:06
|
Created a account here, just confirm i am having the same issue.
Windows 10 1909
9900K
2080ti
Nvidia driver version 441.12
Potplayer 1.7.20977
Disabled(unchecked) automatic full screen exclusive mode, but still entered exclusive mode while full screen.
I just cannot get fullscreen windowed without it going exclusive.
Changing to EVR renderer in potplayer allows fullscreen windowed no problem. |
|
(0002618)
madshi
2020-01-20 11:11
|
Again guys, I've asked but you didn't answer:
What does the madVR OSD say (Ctrl+J)? Does it say fullscreen exclusive mode? |
|
(0002619)
pittyh
2020-01-20 13:07
(Last edited: 2020-01-20 13:24) |
Hi madshi,
Nope it says D3d11 fullscreen windowed (10Bit) but it's acting like it's fullscreen exclusive, because if i mouse over the seek bar or adjust volume, screen flashes black
Also lists "1 frame drop every 1.00 seconds" appears when in windowed mode, and disappears in fullscreen
Link to madvr settings image - windowed mode
https://imgur.com/DFGDyX0
Fullscreen mode
https://imgur.com/a/C1ROtoQ
|
|
(0002620)
pittyh
2020-01-20 13:49
|
Think i fixed it by totally uninstalling madvr and reinstalling. |
|
(0002621)
madshi
2020-01-21 23:43
|
FWIW, Windows 10 has a special mode called "direct scanout", which is automatically activated by the OS and GPU driver in fullscreen windowed mode. The OS and GPU driver do this directly, practically behind the back of madVR. Which is normally fine, because this mode improves performance to near FSE levels. Plus it allows 10bit output in fullscreen windowed mode.
My best guess is that this "direct scanout" mode is somehow causing these issues for you. There's not much I can do about that, unfortunately.
Not sure why uninstalling and reinstalling madVR would fix that, though. That seems weird. |
|
(0002626)
dom
2020-01-26 16:09
(Last edited: 2020-02-01 09:13) |
uninstall/reboot/reinstall/reboot does NOT seem to help on my end.
It says D3D11 fullscreen windowed - the same BOTH immediately after going fullscreen in MPC-HC - and after the delay of a few seconds elapses and the screen switches and the HDR display becomes much darker.
After the "switch" it definitely behaves like fullscreen exclusive, even if MadVR debug OSD doesn't say so.
E.g.: Just mouse right-click to bring up the MPC context menu causes another switch (to what really is FSW, I think) - with the display becoming more light again... after dismissing the context-emu, there is again a "switch" (back to FSE) with display becoming much darker again.
As I mentioned before, the FSE dark display is too dark - it is unusable for watching movies.
Grey value 72 is just barely visible an non-black on my (admittedly weak) HDR display.
If in windowed mode, it is 66.
It's not just the low end - the curve seems different, e.g. dark/FSE 100 looks equal to light/FSW 80
I'm the above I'm using this: "01. black-level-v1.mp4" from "Mehanik HDR10 test patterns" (https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html)
EDIT 2020-02-01: inserted important NOT in first line (ouch typo!) and fixed other minor typos
|
|
(0002627)
madshi
2020-01-26 16:13
|
As I said, it's a "feature" of Windows 10. There's nothing I can do about it. Maybe you can work around it by choosing appropriate GPU driver settings. E.g. make sure you're using "RGB Full" in the GPU control panel etc.
It's also possible that it only occurs when using D3D11 presentation or when using 10bit output. You could try disabling D3D11 presentation or force 8bit output instead. |
|
(0002630)
dom
2020-02-01 10:20
|
@madshi: For my understanding, please:
What are the parameters under which this "direct scanout" gets activated?
With your tips, I experimented a bit:
- "Full RGB" was always set in nvidia settings
- "tone map HDR with pixel shaders" always set in madVR HDR settings (200, BT.2390, balanced, medium)
- the "switch" only occurs if HDR is enabled in Windows display settings (OD HDR) and "output video in HDR" is disabled in MadVR
- no difference if 8 or 10 Bit selected in nVidia settings
- If I disable OS HDR and enable "output in HDR" in MadVR (NV HDR), there also is no switch when going fullscreen (but one when the player starts, obviously). However, the image quality is bad in this NV HDR mode (way too dark) |
|
(0002631)
madshi
2020-02-03 10:15
|
It is usually recommended that you disable the OS HDR switch and instead let madVR do the tone mapping by using pixel shaders. If you do that, I would recommend that you disable "output in HDR". Unless you're using an LG OLED display? In that case using "output in HDR" might be beneficial because the OLED might then run in a higher brightness setting.
Hopefully you're using the latest (or one of the latest) madVR HDR test builds from AVSForum? E.g. try this one:
http://madshi.net/madVRhdrMeasure112b.zip |
|
(0002637)
dom
2020-02-04 18:58
|
My display is an ASUS PA24AC - not very good at HDR - but better than nothing.
It has a normal and an HDR mode - if I leave both "OS HDR" and "output in HDR" (NV HDR) off - then it never switches into HDR mode...
My understanding so far was that tone-mapping alone won't be good enough in this situation...?
No, I have the normal public version... I try this newer build in the next few days, Thanks. |
|
(0002638)
madshi
2020-02-04 19:02
|
Your display doesn't do anything magical if it's in HDR mode. It practically only means that your display applies tone mapping. If you let madVR do the tone mapping instead it's better to keep your display in SDR mode, so tone mapping isn't applied twice. So the recommended approach is to disable the "output in HDR" option.
Might make sense to double check image quality, of course. |
|
(0002639)
dom
2020-02-04 19:42
|
will do - likely will only have time next weekend, though |
|
|
Notes |
(0002475)
madshi
2019-02-07 18:30
|
Which OSD do you mean exactly? |
|
(0002476)
Ashkaan
2019-02-07 18:31
|
The MPC-HTC OSD. The one that tells you the time/time remaining and the filename when you first open a file. |
|
(0002477)
madshi
2019-02-07 18:32
|
It seems to work fine for me. Is this with MPC-HC default settings? |
|
(0002478)
Ashkaan
2019-02-07 18:38
|
Yes, totally default. Admittedly, I played with some of MadVRs settings to try to get this to work, so I don't remember what default was. Here are my settings:
Checked:
delay playback start until...
delay playback start after...
enable windowed overlay...
use a separate device for presentation...
Unchecked:
enable automatic fullscreen...
disable desktop composition...
use Direct3D...
use a separate device for DXVA...
Greyed:
only when media player...
present a frame...
CPU queue size: 16
GPU queue size: 8 |
|
(0002479)
madshi
2019-02-07 18:41
|
Did it ever work?
FWIW, I don't remember anyone ever reporting this issue yet. So it must be really rare/weird.
You can reset madVR settings to default by double clicking "restore default settings.bat" in the madVR folder. |
|
(0002480)
Ashkaan
2019-02-07 18:55
|
I installed MadVR with Chocolatey and the .bat file isn't in the install location. |
|
(0002481)
madshi
2019-02-07 18:57
|
Don't really know what to say. It works here. If I can't reproduce the problem, it's hard for me to do anything about it. |
|
(0002482)
Ashkaan
2019-02-07 18:58
|
With those exact settings, it's working fine? |
|
(0002483)
Ashkaan
2019-02-07 19:05
|
I'm trying to upload my settings for testing, but it won't let me. What format can I upload? |
|
(0002484)
madshi
2019-02-07 19:15
|
Try zipped. |
|
(0002485)
Ashkaan
2019-02-07 19:36
|
Nice! Zip worked. 7z didn't. |
|
(0002486)
madshi
2019-02-07 20:33
|
I tried, activating each of your 3 monitors, and it always works fine for me with your settings.
Suggestions:
1) Try downloading MPC-BE, just as a test. Same problem there?
2) Try downloading madVR and install it in a separate folder, just as a test. Does it work then? |
|
(0002487)
Ashkaan
2019-02-07 22:06
|
1) I just downloaded a portable MPC-BE with default settings, I added MadVR as preferred under external filters, and same problem.
2) I downloaded madVR portable, ran the install script, totally default, same problem (in both HC and BE). |
|
(0002488)
madshi
2019-02-07 22:15
|
I've no explanation.
FWIW, when using madVR, the MPC-HC/BE OSD is no longer drawn by MPC, but by madVR instead. Which means that it looks different. But it should still appear. At least it does for me.
Maybe try a different GPU driver? But I really have no hope for that. Nobody else has ever reported this problem, so I've no idea what's going on. |
|
(0002489)
Ashkaan
2019-02-09 20:07
|
PS: This guy has the same issue:
https://www.reddit.com/r/software/comments/25std5/mpcbe_with_madvr_no_osd/
I bet a lot of people have it, but they just don't notice. Any other ideas or leads for me to try? How does it work? Does it rely on GPU in any way? |
|
(0002491)
madshi
2019-02-11 15:19
|
I'd say we should wait for the next official madVR build (I don't have an ETA for that yet). The next build will have some changes which could change the OSD behaviour. If the problem then still occurs, we'll have to do some debugging/digging. So I'll leave this bug report open until then. |
|
(0002492)
Ashkaan
2019-02-11 17:02
|
Thank you |
|
(0002596)
niczoom
2019-12-06 04:15
|
Ok, I had madvr setup under 'External Filters' and under 'Playback\Output' was EVR (custom pres.). This setup had no OSD showing. When I removed madvr from the 'External Filters' and set it under 'Playhback\Output' the OSD now works. |
|
(0002597)
madshi
2019-12-06 11:38
|
Yes, it's recommended to set madVR under "Output", because otherwise MPC will think it renders with EVR, and thus behave differently. |
|
|
Notes |
(0002501)
madshi
2019-03-17 11:48
|
It's a known issue with the newer Nvidia drivers. I've already reported this to Nvidia, but they've not fixed it yet. I hope it will be fixed in a future driver version. For now you can downgrade to an older driver version. I think the last one that sent correct metadata to the display was 397.93. |
|
(0002502)
kryptonite
2019-03-17 14:33
(Last edited: 2019-03-17 14:41) |
Hi,
I just tried drivers 385.25 through 398.11, and with the same files, I still see HDR 1000 nits in the madVR stats for these clipping tests, so something is still off.
I should have mentioned this before, there are other videos/movies in my collection @ 4000 nits and # 10,000 nits and madVr shows the rights stats for these, irrespective of whether I use driver 385.25 or 417.75, so I guess my issue is specific to these files. And these files themselves seem to be fine because they cleanly tone map on my TV upto 4000 nits if played directly from the TV via USB, but only upto 1000 nits when played through madvr.
Would be great if you could please take a look.
Thanks.
|
|
(0002503)
madshi
2019-03-17 15:38
|
What do you mean with "madVR stats" exactly? |
|
(0002504)
kryptonite
2019-03-17 15:59
|
I'm referring to the debug OSD - the CTRL + J shortcut.
Also attaching 3 pictures
1) 03. 900-4000nits.mp4 on PC with Madvr.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 and you can see the blocks upto 1000 nits are lit, others are clipped
2) 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 with the debug OSD enabled and you can see HDR 1000 nits being reported, which also explains why everything above 1000 nits is being clipped as seen in (1). I think this file is at 4000 nits.
3) 03. 900-4000nits.mp4 on TV directly via USB.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my LG C8 TV directly via USB, and you can see the TV is tone mapping to almost 4000 nits, beyond which it's clipped |
|
(0002505)
madshi
2019-03-17 16:06
|
You mean the "HDR 1000 nits" information in the OSD? That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder? |
|
(0002506)
kryptonite
2019-03-17 16:10
|
->You mean the "HDR 1000 nits" information in the OSD?
Yes, correct
->That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder?
Yup, LAV 0.73.1, also tried 0.74 that was released yesterday. |
|
(0002507)
madshi
2019-03-17 16:51
|
Ok, I've checked file "900-4000nits.mp4". It has the following metadata:
Mastering Display Peak: 1000 nits
MaxCLL: 4000 nits
MaxFALL: 1600 nits
All of this data is incorrect, though. madVR actually measures more than 6000 nits.
Anyway, the latest madVR test build should forward the proper metadata to the display, when using a proper Nvidia driver version. I'm not sure right now if the official madVR build also does that. You can try the latest test build here:
http://madshi.net/madVRhdrMeasure78.zip |
|
(0002508)
kryptonite
2019-03-17 17:06
|
I'm actually right now on http://madshi.net/madVRhdrMeasure78.zip, and I've set it to pass through to display
With this madvr build, I tried 385.25 through 398.11 and also the latest 417.x and 419.x drivers, but nothing helps tone map to 4000 nits really.
With 385.25 & 398.11, I see peak white tone map to 1000 nits, I see one or 2 colours extend to about 1500 nits maybe, but cyan for example doesn't even tonemap to 700 nits, clips way before that
With 417.x & 419.x, I see peak white and all colours tone map very well to 1000 nits, but nothing beyond.
And everything is very different when natively played on the TV, where peak white and colour all tone map well upto 3000 nits+.
So, I'm not sure where the issue is |
|
(0002509)
madshi
2019-03-17 17:19
|
I don't really know. Of course the video is going through very different processing paths when playing with the internal TV player vs when being fed via HDMI. So it's possible the TV doesn't handle HDR input via RGB very well.
I suppose you've already set your GPU and madVR and your TV all to RGB Full (0-255), right? |
|
(0002510)
kryptonite
2019-03-17 17:26
(Last edited: 2019-03-17 17:27) |
MadVR and NVIDIA Video player settings are at 0-255
Display is at 3840x2160, YCBCR 4:2:2, 12bit, 60Hz, which will be 16-235, can't do RGB 10/12bit over HDMI 2.0b
HDMI Deep colour is enabled on TV to switch to HDR on demand
If I set display to 3840x2160, RGB Full (0-255), 8bit, 60Hz, then the TV tone maps to 600-650 nits with these files, and clips everything after that, which is even worse
|
|
(0002511)
madshi
2019-03-17 17:35
|
I've no idea what happens if you send YCbCr to the TV. The Nvidia driver will convert my RGB rendered pixels to 4:2:2, using an unknown color matrix, an unknown chroma downscaling algorithm, and possibly no dithering. It's really really bad. RGB 8bit should be *much* better. Have you tried that with a proper driver, e.g. 397.93 or older?
People worry too much about bitdepth, to be honest. 8bit RGB is perfectly fine, if you use lossless high quality dithering. We do need as high as possible bitdepth for lossy content encoding. But during lossless HDMI transport, dithered 8bit is plenty good enough. |
|
(0002512)
kryptonite
2019-03-17 17:56
(Last edited: 2019-03-17 18:00) |
Appreciate your quick responses mate, I hadn't tried, but just did.
Driver = 397.93
Madvr set to pass through
RGB 8-bit Full 0-255 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255
And I got exactly the same thing as
Driver = 417.75
Madvr set to pass through
YCBCR 12bit Limited 16-235 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255
Both tone map up to 1000 nits (whites & all the colours), that's it. They're identical.
|
|
(0002513)
madshi
2019-03-17 18:55
|
Maybe the LG ignores MaxCLL when receiving RGB via HDMI? The Mastering Monitor Metadata is only 1000 nits, maybe the LG uses that in this situation? I'm only guessing, of course. |
|
(0002514)
kryptonite
2019-03-18 12:42
|
Might very well be the case, I've made a post there on the creator's thread, hope he could share some ideas:
https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set-7.html |
|
(0002515)
kryptonite
2019-03-20 12:54
|
Hi,
Hope you had a chance to follow the discussion here:
https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set-8.html
I think we've provided that Mastering display level has an effect on the TV's tonemapping when using MPC-HC + MadVR, but if the same file is played through the TV's internal player via USB, it responds to MaxCLL instead.
While the author of the files has offered to re-encode the files using matching MDL/maxCLL values, I was wondering if there is anything we should do on the madvr front to help the TV respond to maxCLL instead of MDL while using MPC-HC + madVR (we know the TV does repond to maxCLL when using it's internal player via USB) |
|
(0002516)
madshi
2019-03-25 09:45
|
What are you suggesting? That I set MDL to maxCLL? The problem with this approach is that maxCLL doesn't have to be accurate. So if I set MDL to the same value as maxCLL, this might make things worse for some movies/display combinations. E.g. there are several movies which have these values set to some standard values which can be far too low, which would result in clipping, if the display actually made use of those values.
Actually these test patterns don't have accurate maxCLL values, either. madVR detects that by looking at whether the numbers are rounded to xxx50/xxx00. If both maxCLL and madFALL are rounded that way, there's a 99.96% chance that they were manually set and not properly calculated. In that case madVR completely ignores the maxCLL and maxFALL data. |
|
|
Notes |
(0001850)
madshi
2017-10-15 20:33
|
With that TS file eac3to reports "The format of the source file could not be detected" on my PC. Maybe the file is too short? |
|
(0001851)
msg7086
2017-10-15 20:42
|
My apologies, when cutting the file to get around the size limitation I seemed to cut in a weird position.
Double checked this time and uploaded a new sample.
Thank you for your time. |
|
(0001920)
madshi
2017-11-15 15:02
|
Is it fixed in this build?
http://madshi.net/eac3toHevcTest.rar |
|
(0001921)
msg7086
2017-11-15 20:46
(Last edited: 2017-11-15 20:46) |
Testing 4k-test2.ts
----------
Testing 01.ts
-
Testing 02.ts
Testing 03.ts
-
Testing 04.ts
Testing 05.ts
Testing 06.ts
Testing 07.ts
Testing 08.ts
-
9 negatives. log.txt file shows nothing useful.
|
|
(0001928)
madshi
2017-11-18 21:55
|
Hopefully fixed in v3.33?
http://madshi.net/eac3to.zip
The attached file was too short to properly detect the HEVC properties, but at least it doesn't exit silently, anymore. |
|
(0001930)
msg7086
2017-11-19 04:11
|
Testing 4k-test2.ts
TS, 1 video track, 1 audio track, 0:00:03, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -740ms
Testing 01.ts
TS, 1 video track, 1 audio track, 0:30:21, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -1063ms
Testing 02.ts
TS, 1 video track, 1 audio track, 0:30:21, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 179kbps, 48kHz, -652ms
Testing 03.ts
TS, 1 video track, 1 audio track, 0:30:09, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -1040ms
Testing 04.ts
TS, 1 video track, 1 audio track, 0:30:27, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -601ms
Testing 05.ts
TS, 1 video track, 1 audio track, 0:30:37, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -713ms
Testing 06.ts
TS, 1 video track, 1 audio track, 0:30:23, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 192kbps, 48kHz, -613ms
Testing 07.ts
TS, 1 video track, 1 audio track, 0:30:15, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 186kbps, 48kHz, -570ms
Testing 08.ts
TS, 1 video track, 1 audio track, 0:30:17, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -882ms
I'll upload a longer example for further testing. Also I'll report if the audio delay is correct after comparing with my previous test. |
|
(0001931)
msg7086
2017-11-19 04:46
|
https://drive.google.com/file/d/1vQUNV32Wu64jaqjNZYsAMLxmbRzje7q6/view?usp=sharing
Should be long enough for HEVC properties.
Regarding the audio delay, here's what I ear-detected against videos encoded with DGNV avisynth source filter.
01.ts: eac3to reports -1063ms, ear detected -700ms.
02.ts: eac3to reports -652ms, ear detected -600ms.
03.ts: eac3to reports -1040ms, ear detected -600ms.
04.ts: eac3to reports -601ms, ear detected -650ms.
05.ts: eac3to reports -713ms, ear detected -750ms.
06.ts: eac3to reports -613ms, ear detected -600ms.
07.ts: eac3to reports -570ms, ear detected -450ms.
08.ts: eac3to reports -882ms, ear detected -850ms.
Since those video clips are just landscapes with music, no accurate sync point can be found. And we wouldn't know how DGNV determines its first usable frame either, so this is for reference only. |
|
|
Notes |
(0001713)
TheLastOfUs
2017-07-13 09:25
|
eac3to v3.31
command line: eac3to "WAVPCM.wav" "wow.m4a" -slowdown
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.50> with NeroAacEnc...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 32 bits.
eac3to processing took 19 seconds.
Done. |
|
(0001714)
TheLastOfUs
2017-07-13 09:26
|
^ Runtime of the top is 10.25.602. Not the correct 10.25.626.
Difference always varies from 24ms to 26 ms. |
|
(0001715)
madshi
2017-07-13 11:15
|
I've just done the following test with the Robin Hood (Disney) audio track:
1) "eac3to English.flac Stereo.wav -downStereo". Audacity reports final audio file to be 1:23:01.984.
2) "eac3to Stereo.wav Slowdown.wav -slowdown". Audacity reports final audio file to be 1:26:34.756.
Now let's do the math:
1:23:01.984 = ((1 * 60 + 23) * 60 + 01) * 1000 + 984 = 4981984 milliseconds
4981984 * 25 / (24.000 / 1.001) = 5194756 milliseconds
5194756 / 1000 / 60 = 86 minutes
5194756 - 86 * 60 * 1000 = 34756 milliseconds
So final length should be 1:26:34.756 - which is exactly what eac3to produced! So we have a *perfect* match. At least in this specific test I just made.
Two things you might not have been aware of:
A) 23.976 is really 24.000 / 1.001 = 23.976023976023976023976023976...
B) When decoding from or encoding to some compressed formats like e.g. AC3, DTS, AAC etc, audio gets either shortened or lengthened to match the compressed format's frame size. So for a really exact test both your source and target format should ideally be WAV(64), because WAV is one of the very few formats which doesn't partition the audio data into frames of a specific size. |
|
(0001716)
TheLastOfUs
2017-07-13 21:57
|
Dear Madshi
Thanks for your response.
I did try WAV of a 10 minute sample as you can see in my 1st note. That 10 minute sample ends up becoming 10.25.602 .WAV and not 10.25.626 like a simple -4.096 on Audacity is doing.
Did you try on Audacity? I mean I am adding 23.976 (i may not be putting in 023976023976023976023976) but then how come the audio is shorter (especially wav)?
Please try just 10 minute sample of any audio. |
|
(0001717)
madshi
2017-07-13 22:06
|
I'm not interested in whether Audacity resamples to a different duration than eac3to. I'm only interested in whether eac3to does things correctly. And as you can see in my previous comment, in my test it produced perfect results.
Your log includes AAC, which can screw everything up.
You're welcome to repeat my test with any file of any (reasonable) runtime. But if you do, please don't compare with what other software is doing (when slowing down). Instead just do the math manually to double check if eac3to is doing things correctly or not. That's the only thing that counts! And if you do this test, please use WAV for both input and output. |
|
(0001718)
TheLastOfUs
2017-07-13 22:11
|
Ok....
I honestly can't say I know the math entirely.
eac3to v3.31
command line: eac3to wavpcm.wav nice.wav -slowdown
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "nice.wav"...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 9 seconds.
Done.
For 10 minute sample at 25FPS runtime is 600000 |
|
(0001719)
TheLastOfUs
2017-07-13 22:15
|
600000 * 25 / (24/1.001) aka 15000000/23.976023976 = 625625 ms
Audacity says EAC3To audio is 10 minutes 25 seconds 592 milliseconds
10 mins = 600000 ms
25 seconds = 25000ms
592 ms = 592ms
total:
625,592 ms......
Crap |
|
(0001722)
madshi
2017-07-13 22:19
|
Did you really repeat the test, using WAV input and WAV output? Or did you just do a writeup based on your older tests? |
|
(0001723)
TheLastOfUs
2017-07-13 22:23
(Last edited: 2017-07-13 22:23) |
I did a new test....attached for your reference. Apologies but it still isn't adding up right...wouldn't waste your time with lies! I'm trying hard to figure this out on my end.
|
|
(0001724)
TheLastOfUs
2017-07-13 22:25
|
Sorry I'm adding craptastic pictures. I'm adding a better one... |
|
(0001725)
TheLastOfUs
2017-07-13 22:27
|
On the right - is the NICE.WAV i converted to. |
|
(0001726)
TheLastOfUs
2017-07-13 22:27
|
On the left is the original nice wavpcm.wav file |
|
(0001727)
TheLastOfUs
2017-07-13 22:28
|
I am willing to teamviewer if necessary but yes...tried WAV to wav..I will try again.... |
|
(0001728)
TheLastOfUs
2017-07-13 22:31
|
Newtestagain.png added. Wavpcm.wav to nice.wav
Final result is 10.25.592 as reported by audacity. Not 625625 ms as I calculated with your exact ratio. If I try a bigger file - up to 30 minutes, same discrepancy in numbers |
|
(0001729)
madshi
2017-07-13 22:49
|
Strange. Why does it work on my PC? My file is not float32, though, but I don't think that's likely to make a difference. Can you upload the "Wavpcm.wav" somewhere? Then I'll try to reproduce the problem here with the exact same file you've been testing with. |
|
(0001730)
TheLastOfUs
2017-07-13 23:00
|
Sure thing boss! |
|
(0001731)
TheLastOfUs
2017-07-13 23:08
|
https://www.amazon.com/clouddrive/share/4YcJaGELKcf44BwzmTMZ7HvXBCCmu8NcWUykOPr8Efu?ref_=cd_ph_share_link_copy |
|
(0001732)
madshi
2017-07-13 23:40
|
Interesting. It seems to be the sampling rate. When I convert the audio to 48khz, slowing down produces perfect results. But at 44.1khz it's not perfect.
After checking my source code it seems that the libSsrc library I'm using for resampling has "integer" parameters for source and target sampling rate, not "floating point". Which means the sampling rates are rounded down, no decimals supported. I'm not sure if there's much I can do about this. |
|
(0001733)
TheLastOfUs
2017-07-13 23:46
|
Ah...wow that would explain a lot. Yes all my audios I work on are 44.1 - and yes I don't think there's anything you could do about it....thank you for looking into this.
Is there a way for the audio to be converted to 48 Khz right from within EAC3To or would it require me to use Audacity > save to wav > then process? |
|
(0001734)
madshi
2017-07-13 23:50
|
Why are your audio files 44.1khz? I mean usually slowdown is needed for *movie* tracks, and both DVDs and Blu-Rays (and UHD Blu-Rays and HD DVDs) are all 48khz, IIRC. So I don't understand where you would get 44.1khz movie tracks from? Except maybe from Laserdisc or something?
For non-movie tracks of course it isn't nice if slowdown isn't perfect, but it's probably not a too dramatic problem, either, because there's no matching video track that lipsync needs to match with. But if there's no video track, I don't think slowdown would ever be useful, anyway?
eac3to can directly resample, e.g. "eac3to source.wav target.wav -resampleTo48000", but then you resample twice: From 44.1khz to 48khz, and then afterwards the slowdown, which isn't ideal. |
|
(0001735)
TheLastOfUs
2017-07-14 00:07
(Last edited: 2017-07-14 00:27) |
It's a laserdisc of winnie the pooh from Europe. Which is why it's probably 44.1 KHz....
wouldn't resample be just once? eac3to source.wav (resampled) -slowdown ?
Oh you mean the audio gets manipulated twice? I thought it was close to perfect if your sources are lossless?
|
|
(0001740)
TheLastOfUs
2017-07-14 00:41
|
I did Resampleto48000 and it changed the file length from 22.09.876 to 22.09.853 difference of 24 ms.
Basically if I work with any 44.1 KHz file - no go in terms of libSsrc I am guessing....now I understand what you mean by resampling 2wice. |
|
(0001741)
madshi
2017-07-14 01:25
|
Yeah. Don't know how to solve it. I mean I could lie to libSsrc about the sampling rate and pretend it were 48khz instead of 44.1khz, but I don't know enough about the technical aspects of resampling. It might harm audio quality if I lie, I don't know for sure. |
|
(0001742)
TheLastOfUs
2017-07-14 04:07
|
Is it possible to humbly request to you - a build in which any 44.1 KHz file is interpreted as 48 KHz?
Thank you.... |
|
(0001743)
madshi
2017-07-14 09:47
|
I don't really want to do that by default, because I don't know if it might not harm audio quality. I could add it as an (undocumented) option. It's not a matter of 5 minutes to add this, though, so it will have to wait... |
|
(0001744)
TheLastOfUs
2017-07-14 20:38
|
An undocumented option would be MAGNIFICENT. Totally understand it isn't a 5 minute thing. Thank you for all your help brother :) |
|
|
Notes |
(0000706)
madshi
2015-02-14 09:53
|
Can I have a small sample of the video + PGS, please? The sample may be very short, I just something to reproduce the problem on my PC. |
|
(0000707)
Neroldy
2015-02-15 07:21
|
Of course, I will upload the sample. It has 4 parts. |
|
(0000812)
madshi
2015-03-22 16:42
|
Hmmmm... This is a difficult problem which needs some discussion:
The PGS is 1920x1080. The movie was 1280x720 and was then cropped to 1280x534. Now madVR has to scale down the PGS subtitles somehow. Currently the PGS X and Y downscaling factors are simply calculated by doing x=1920/1280 und y=1080/534. However, this results in the AR ratio of the subtitles changing.
Now I wonder what the best solution is? Probably I should be using the same scaling factor for both X and Y? But how should I calculate the scaling factor? Should I calculate both factors and simply use the smaller one?
One additional problem is that currently subtitles are drawn in a moment when madVR still only renders the active video rect. Which means that drawing subtitles into the black bars currently doesn't work yet. This will be fixed in a future version. |
|
(0000817)
cyberbeing
2015-03-22 19:10
|
If you were going to allow PGS typesetting, I'd assume you'd need to:
Resize PGS Width to Output Width.
Resize PGS Height with the same factor used for PGS Width (maintain AR)
1920x1080 PGS + 1920x800 Output
=
1920x1080 as-is, display centered vertically on the output frame.
1920x1080 PGS + 1280x534 Output
=
Resize to 1280x720, display centered vertically on the output frame.
The problem, is that you would need to support rendering to black bars or else dialog may be hidden. If you wanted madVR to behave intelligently, you'd have a fallback behavior when black bars were not present or too small to fit the entire PGS frame in original aspect ratio.
__
One fallback solution could be to crop the top and bottom edges of the PGS frame and move them inside the video frame, though you'd probably need to double check your crop lines were transparent:
1920x1080 PGS + 1920x800 Output
=
1920x1080 cropped to 1920x800 Center + 1920x140 Top + 1920x140 Bottom. Top and Bottom crop shifted inside Center crop and displayed.
1920x1080 PGS + 1280x534 Output
=
Resize to 1280x720, crop to 1280x534 Center + 1280x93 Top + 1280x93 Bottom. Top and Bottom crop shifted inside Center crop and displayed.
__
Another fallback solution could be to resize the frame to fit inside the Output frame, while maintaining aspect ratio. This would be at the expense of typesetting positions and subtitle size:
1920x1080 PGS + 1920x800 Output
=
Resize to 1422x800, display centered horizontally on the output frame.
1920x1080 PGS + 1280x534 Output
=
Resize to 949x534, display centered horizontally on the output frame.
__
The last solution is what madVR currently does, stretching the PGS frame to match the output frame, ignoring Aspect Ratio:
1920x1080 PGS + 1920x800 Output
=
Resize to 1920x800, display.
1920x1080 PGS + 1280x534 Output
=
Resize to 1280x534, display.
__
My only concern for any solution is that fixing this for PGS does not break VSFilter compatibility in regards ASS subtitles and anamorphic video, particularly when the "Render to Original Video Size" option is enabled. |
|
(0000819)
madshi
2015-03-22 19:22
|
Rendering in black bars is planned for a future version, so that's what I'll be doing.
The question is which scaling factor I should be using. You're saying I should only look at the width. But what happens if a 4:3 Blu-Ray is cropped? Then the encoded movie would be 960x720. In this case I'd have to look at the height, wouldn't I? I think I should calculate both X and Y downscaling factors and pick the smaller one, no?
I don't think any of this should break ASS subtitles. ASS subtitles are supposed to be rendered by XySubFilter in exactly the resolution I need, so no scaling needs to be done there. Any changes I'll do because of this bug report it going to be only for subtitle images that need scaling. |
|
(0000825)
cyberbeing
2015-03-22 21:26
(Last edited: 2015-03-22 21:28) |
> Rendering in black bars is planned for a future version, so that's what I'll be doing.
You'll still need some kind of fallback for situations where black bars may not exist, like Windowed mode?
> I think I should calculate both X and Y downscaling factors and pick the smaller one, no?
Yes, that sound right.
1920x1080 PGS + 1440x1080 Output
=
1920x1080 as-is, display centered horizontally on the output frame.
1920x1080 PGS + 960x720 Output
=
Resize to 1280x720, display centered horizontally on the output frame.
> Any changes I'll do because of this bug report it going to be
> only for subtitle images that need scaling.
Which is why I feared it would affect XySubFilter's "Render to Original Video Size" option, unless I'm forgetting how madVR handles that option. From the point of view of madVR, that option causes XySubFilter to report the size of ASS bitmaps in a similar way to PGS. If madVR blends subtitle bitmaps which match originalVideoSize immediately, prior to anamorphic and other scaling, it shouldn't be an issue.
|
|
(0000828)
madshi
2015-03-22 21:59
|
If the subtitle frame's "GetOutputRect()" happens to match the unscaled video resolution then I *think* madVR should not apply any scaling. |
|
(0000857)
kasper93
2015-03-25 13:39
(Last edited: 2015-03-25 13:41) |
It is indeed tough case to handle. We did add so called "best fit" in MPC-HC's renderer. Subtitles have always preserved aspect ratio and scaled to the video (if needed). Idea here is that to always get perfect (source like) subtitle placing and sizing also on cropped video frames. Of course in this case user need to simulate "black bars" in case there are subtitles to be drawn there. Otherwise they will be cropped. But this is by design.
(Additionally I wanted to add adaptive mode to scale down subtitles (preserving AR) if they don't fit in window rect, but we didn't decide to do that after all.)
For reference here is my commit with all math to calculate target rect. All magic is there to handle cropped 4:3 and alike.
https://github.com/mpc-hc/mpc-hc/commit/752ba8d9e651e3f19d2f2dd74cd5b391cab14cbf
We did exclude anamorphic videos later on because DVB subtitles doesn't play well with this logic, I mean it works fine but subtitles are not corrected for anamorphic since we always preserve aspect ratio of sub frame. DVB subtitles are ment to be drawn on video and streched along with it. Though I never seen cropped anamorphic sample ;p
|
|
(0000858)
madshi
2015-03-25 14:47
|
Thank you kasper95, I'll have a look at your implemention when I get around to implement/fix this. |
|
(0001280)
fawarion
2016-02-13 10:30
|
Yeahhh.... I have Get the Same problem
when Using DXVA for Chroma Upscaling or Chroma Downscaling in HP Pavilion G4-1314au VGA is AMD APU radeon(tm) HD 6480G, if use another scaling alogarithms except DXVA. Scaling from DXVA in AMD are bettter colour from another scaling but got Cropped display.
When i have using same configuration setting in my Dell notebook with AMD ATI Radeon, there are no crooped display, nothing seriuously problem.
I'am Using same new Catalyst version 15.7.1
AMD HD Radeon APU was better than AMD ATI radeon.
Whats wrong ......? ?_? |
|
|
Notes |
(0000184)
madshi
2013-06-11 11:24
|
Ok, I have Tangled, will see if I can reproduce it, if I find some time (can take a while). |
|
(0000270)
Shevek
2013-07-04 03:37
|
This is also happening on Shark Night 3D |
|
(0000717)
madshi
2015-03-10 20:18
|
My Blu-Rays are currently out of reach, due to being boxed up during my recent move. Is there any way you can provide a small sample? |
|
(0001224)
madshi
2015-11-01 14:46
|
Closed due to lack of reply. |
|
(0001230)
r0lZ
2015-11-03 10:05
|
Sorry, I have not been notified of your comment asking for a sample.
But finally, here it is: http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts
It's the beginning of the file, because if I cut later, eac3to doesn't recognise the format any more. As a consequence, demuxing the subtitles from the sample produces only some discontinuity warnings, and the subtitle can be demuxed. With the full original SSIF (20.4 GB), after a lot of discontinuity warning, the demux is aborted with this message:
[...]
s07 0:26:43 The source file seems to be damaged (discontinuity).
s07 0:26:46 The source file seems to be damaged (discontinuity).
process: 47%
s07 0:26:51 The source file seems to be damaged (discontinuity).
s07 0:26:51 The source file seems to be damaged (discontinuity).
s07 The SUP reader received unknown data.
s07 0:26:55 The source file seems to be damaged (discontinuity).
Aborted at file position 10261364736.
The same problem happens with all 3DBDs containing subtitles in the M2TS of the dependent view. It's not always the case and I don't understand why some BDs (notably the Disney and Pixar BDs) include the subtitles in the dep view. As far as I know, it's totally useless.
For your information, here is the analysis of the files of the Tangled movie by eac3to:
E:\>eac3to Z:\BDMV\PLAYLIST\00004.mpls 1)
M2TS, 2 video tracks, 4 audio tracks, 5 subtitle tracks, 1:40:16, 24p /1.001
1: Chapters, 17 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, Russian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
7: AC3, Ukrainian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
8: Subtitle (PGS), English
9: Subtitle (PGS), Russian
10: Subtitle (PGS), Ukrainian
11: Subtitle (PGS), Russian
12: Subtitle (PGS), Ukrainian
E:\>eac3to Z:\BDMV\STREAM\SSIF\00000.ssif
M2TS, 2 video tracks, 4 audio tracks, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/MVC (right eye), 1080p24 /1.001 (16:9)
3: DTS Master Audio, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3 Surround, 2.0 channels, 320kbps, 48kHz
5: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
6: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
7: Subtitle (PGS)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)
E:\>eac3to Z:\BDMV\STREAM\00000.m2ts
M2TS, 1 video track, 4 audio tracks, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
3: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
4: AC3, Russian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
5: AC3, Ukrainian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), English
7: Subtitle (PGS), Russian
8: Subtitle (PGS), Ukrainian
9: Subtitle (PGS), Russian
10: Subtitle (PGS), Ukrainian
E:\>eac3to Z:\BDMV\STREAM\00001.m2ts
M2TS, 1 video track, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/MVC (right eye), 1080p24 /1.001 (16:9)
2: Subtitle (PGS), English
3: Subtitle (PGS), Russian
4: Subtitle (PGS), Ukrainian
5: Subtitle (PGS), Russian
6: Subtitle (PGS), Ukrainian
00001.m2ts is the M2TS of the dep view. As you can see, it contains also the same subtitle streams. The stream IDs are identical. Therefore, in the SSIF, the same streams with the same ID are included two times! It's probably the cause of the problem.
Demuxing the subtitles directly from one of the two M2TS work fine, without any warning. The bug occurs only when demuxing the MPLS or SSIF. |
|
|
Notes |
(0000389)
turbojet
2014-02-28 15:48
|
Here's 3:2 detected as 4:2:2:2 http://www.mediafire.com/download/150g9d9f7ahmph2/3_2_as_4_2_2_2.mpg |
|
(0000407)
huhn
2014-03-03 15:59
|
are you sure the 3:2:3:2:2 sample is 4:2? if the sample is 4:2 that would mean it is 20 fps.
after a short look at it. it is 3:2:3:2:2 or something like that at least 3:2 is in there. and the output fps should be 25 fps. and 3:2:3:2:2 should result in 25 fps.
the problem is not the wrong cadence detection, because they are both totally right. the problem is the decimation and frame rate control.
i'm just looking here because i was going to report a 4:2:2:2 issue where the wrong frame is droped when played with 23p like your 3_2_as_4_2_2_2.mpg |
|
(0000418)
turbojet
2014-03-03 22:45
|
The file in the original post is 4 good, 2 duplicate frames, isn't that 4:2? Madvr should remove the second duplicate and output 24.975 fps and switch display to a multiple of 25hz. |
|
(0000419)
huhn
2014-03-04 09:47
|
that's not how telecine work.
i think this is a bad place to talk about telecine and top/odd field so you can read the Frame rate differences part from http://en.wikipedia.org/wiki/Telecine .
you are right about the 25fps and that madvr drops the wrong frame but the source of this issue is not the cadence.
a 30i source like ntsc tv got 60 fields per sec and if these fields are 3:2:3:2:2 it should result in 25 fps. but madvr switches to 23p and drops more frames then it should be. on top of it it got quiet some cadence breaks too. |
|
(0000420)
madshi
2014-03-04 09:50
|
madVR currently always switches to 23Hz when having forced film mode on while playing 59i content. Yeah, with some cadences 23Hz is not the optimal refresh rate. But that's not so easy to solve, especially because cadence detection can be unstable. E.g. what happens if cadence detection switches between 3:2 and between 3:2:3:2:2 all the time? Should madVR then always switch between 23Hz and 25Hz all the time, in the middle of playback? This is a problem I'll have to revisit later, but I don't consider it a "bug" right now. It's as intended, even it might not be the best (or even the correct) solution. |
|
(0000421)
madshi
2014-03-04 09:55
|
I've downloaded the sample, added it to my cadence collection, and added an entry to my to do list to look at which refresh rates to switch to with different cadences. But as mentioned above, this will not be easy to do well, because we don't want to switch back and forth between different refresh rates all the time. So this will have to wait until I get back to the whole deinterlacing topic. For now I'll close this bug entry. |
|
(0000422)
madshi
2014-03-04 10:02
|
P.S: Actually, I think there *is* a cadence misdetection of some sort here. Haven't had the time to look at it in detail, but this is different than just failing to switch to the correct framerate. As such I'll leave this open, after all, but it will take some time before I get to this. |
|
(0000423)
huhn
2014-03-04 10:19
|
should i at least create a bug report for a problem with 2:2:2:4 or 4:2:2:2? because in this case madvr drops the wrong frame and the output should be 24 fps. i even found a cadence like this on a bd. |
|
(0000424)
madshi
2014-03-04 10:31
|
Just send me a sample (or multiple samples) via PM or eMail. Thanks. |
|
(0000453)
turbojet
2014-03-05 00:08
|
I thought cadence worked on frames instead of fields, 3:2 would be correct on either but thanks for the info.
I wouldn't expect madvr to change refresh rate every time the cadence changed but I'd expect FRC to toggle on the fly which it already can do without any noticeable change. Refresh rate changes take seconds on 2 displays here. While this wouldn't fix the issue using 24/25/30 hz displays it should work fine using higher multiples, which in some cases should be used currently.
The original post file plays wrong when 50hz is forced, like huhn said it's probably removing the wrong frame. |
|
(0000454)
madshi
2014-03-05 00:11
|
FWIW, the cadence is for fields, not frames. E.g. the typical NTSC 3:2 cadence has one field repeated 3 times and one repeated 2 times. |
|
