madVR - high quality video renderer (GPU assisted)

[e-t172]

madshi: I read your doc (http://madvr.com/crt/CustomResTutorial.html) about the way custom modes work, and I really like your "back porch hack" approach, very clever :)

However after I read the doc I was left wondering if you had considered possible optimizations for the case where the audio and video clocks are actually driven by the same hardware clock at the lowest layer. The typical example is audio over HDMI, where the audio and video are sent down the same output. In that particular case, it is my understanding that the audio and video clocks are the same because they are managed by the same chip (the GPU) and when one looks at the HDMI wire format, one realizes the audio is sent interleaved with the video (audio is sent inside the blanking interval), which AFAICT means that it would be difficult to use two different hardware clocks.

What I'm getting at is, I suspect that the only reason that playback is not "perfect" when using audio over HDMI (even though it should be) is because the video clock is not set precisely enough to allow for exactly 2002 audio samples (48 kHz /24/1.001) between two frames. Instead, it is set to, say, 24 Hz (2000 samples between two frames), or, the best one could do until your clever "back porch hack" came along, 23.98 Hz (2001.67... samples between two frames, still not good enough). Note that none of these calculations are hardware-specific, because the relationship between video and audio clock in such a setup is fixed and predictable, as the hardware clock is the same. (This contrasts with the case where the hardware clocks are distinct and separate, because in that case one gets random fluctuations in inter-clock variation caused by the specific oscillator chips themselves, temperature effects, etc. These can't happen if the two clocks are the same - a clock will always agree with itself.)

So it seems like, in theory, you could provide custom modes that, in the specific case where the audio and video clock are the same, would be universal (monitor input limitations notwithstanding), i.e. can be used by anyone without having to go through a lengthy optimization process. In other words you could provide these as "pre-made" optimized modes that would work for anyone who's using audio over HDMI (i.e. a lot of people), as long as the HDMI receiver accepts it. (I suspect that this simply a matter of coming up with modes that approximate the exact 24/1.001 number as closely as possible. This would, presumably, compel the GPU to insert exactly 2002 audio samples between two frames, resulting in perfect playback universally on any hardware.)

[EDIT: after taking a glance as to what the HDMI spec (http://www.fpga4fun.com/files/HDMISpecification13a.pdf#page=114) has to say on this (HDMI 1.3a §7.2 and especially table 7-3), this might be a bit more complicated than just aiming for 24/1.001, but I would still expect there is a consistent universal target that can be optimized for. The spec does say that sources are allowed to use different clocks for audio and video but it's not clear why a GPU would do that since it would just make things more complicated for no reason. There's no reason why a GPU would not just use the recommended values in table 7-3, in which case an universal target can be made for any hardware that uses these values.]

[SweetLow]

Obviously my tool can't fix driver bugs.
Of course. But when you mentioned "private API" I had (very little) hope that this can make possible some workaround. But no luck.

[Prinz]

Just to make it clear: The FSE problem only showing (8 bit) is only on the secondary screen (TV via AVR via HDMI), on the real PC monitor via DVI it switches to (10 bit)

[Manni]

The hard-coded threshold is exactly 10 minutes. Furthermore, it starts measuring only after 5 seconds or so. So you need to let it run for at least 10 minutes 10 seconds or so.


Makes sense, thanks for the confirmation. I then most definitely had stopped it just short of 10mn (I had not timed it precisely).


That's quite surprising! Both my LCD computer monitor and my Sony 4K TV accept virtually anything I throw at them. And at some point I did a very quick test with my X35 and changing some timing parameter manually worked just fine, too. Maybe I need to improve my "compatability rating" somehow, I'm not sure. Or could it be possible that your AVR doesn't like custom modes? Could you try without the AVR, just as a test?


The X35 doesn't have 4K input and the new JVCs are quite tricky with HDMI, so I don't think the comparison tells us much.

I'll do the test without the AVR when I find the time and will report back, but I wanted to answer your other questions first.


There's only 2 options: Either I call the Nvidia APIs correctly or incorrectly. If I call the APIs correctly, then anything that goes wrong is the Nvidia driver's fault, and there will be nothing I can do about it. If I call the APIs incorrectly, then of course it's my bug can I can fix it. So the key question is if I've done something wrong or not.

Does the "custom modes" tab list the modes incorrectly, too, after you've created a custom timing?


The "custom modes" tab always lists the modes correctly. When I optimize 23p, it's only 23p that is changed as far as MadVR is concerned, there is no mix up with 24p.

For the OS, all the modes remain avaliable in the dropdox list (both 23 and 24).

It's only in the nVidia CP control panel that 24p disappears from the list and moves into the custom res modes.

However, if I manually select 23p from the control panel and start playback with MPC-BE directly, it's the optimized 23p mode that is selected, and when I go back to the panel the nVidia custom 24p is selected. Of course MadVR isn't set to automatic refresh rate change, as this is handled by MyMovies.

If I start playback with MyMovies, MyMovies switches automatically to the custom 23p, so it works fine.

As far as I can see, it's only a problem in the nVidia control panel list, from a functionality point of view all works as expected, whenever a player/app requests 23p it's the optimized mode that is selected.


Good find, thanks!


You're welcome. :)

[imhh11]

Just the basic 3D drivers that come with nvidia. I went straight from 378.92 to 385.28 and things are working fine for me. This is the software i reinstalled during the clean installation

nvidia drivers 385.28
MPC-HC (x64) 1.7.13
madvr 0.92.1
lav 0.70.2

I am on windows 10 Pro 1703 (x64) with the latest aug update.

Please note that only 3D files work when I enable stereoscopic 3D in nvidia. I get a crash for any 2D file. Its not really a problem as I use a batch file to enable 3D, play the 3d file and then disable 3D.

same on my end. 3D is now working on the latest driver and 2D crash when Nvidia 3d is enabled.
But I have to use this to avoid the 3d vision setup because it still crashes if i try to activate nvidia 3d stereoscopic.
https://github.com/Eincrou/Adv3DVisionConfig/releases

[x7007]

same on my end. 3D is now working on the latest driver and 2D crash when Nvidia 3d is enabled.
But I have to use this to avoid the 3d vision setup because it still crashes if i try to activate nvidia 3d stereoscopic.
https://github.com/Eincrou/Adv3DVisionConfig/releases

Ye , it crashes, that's what I'm saying.

Someone says the wizard doesn't crash for him... can't understand how come we all have crash and only him doesn't.

I also use 3DTV .
3D always works, but the Wizard always crash on 384.xx drivers 385.xx.
works fine on 382.xx


Thank for the program , I'll check it

[huhn]

@e-t172

following the HDMI spec doesn't help with sync the issue come from more than 1 clock and it is very unlikely to run at the same speed. for what ever reason it doesn't look like HDMI audio and video are using the same clock at least on all of my GPU i have used.

you can try a true 24p 48 Khz source to check your theory.

[aufkrawall]

Forgive me my unknowingness:
Is it really necessary to prevent audio resampling at all costs if you want to feed your expensive amplifier well?
Or in other words: Why is A/V resampling with speed adjustment, if necessary, not the holy grail?

I'm confident I once knew such stuff, before smooth motion neglected my mind. :D

[Manni]

Or could it be possible that your AVR doesn't like custom modes? Could you try without the AVR, just as a test?


I did some tests with the 1080 Ti connected to the JVC RS500 directly. Of course, no sound.

I got very surprising results.

First of all, the EDID mode that works perfectly and gives me ate least 1 hour without a frame drop when the AVR is in the chain doesn't work so well with a direct connection. It frequently causes a picture corruption (strong magenta shift on the whole picture) and doesn't bring any improvement (5mn before a frame repeat). It is enabled though, as confirmed by the * in the custom modes list, but it's just not usable.

Even more weird, there is no custom mode created in the nVidia control panel, so 24p remains available in the list and there is no custom 24p created.

Finally, I tried to optimize it (it does get the data, which proves that the "ghost" optimised mode is selected) and no optimized mode work, whether the pixel clock is the same or not. I didn't try them all, but I tried the ones with the same pixel clock and a few of the ones showing a good compatibility (around 80%) as well as a few random ones with lower compatibility. No go for any of those tested (no signal).

I also did some tests with an HD Fury integral between the HTPC and the AVR (I'm using this to make sure that I get the same EDID when I switch between main zone and zone 2 as there is a bug in my Denon X7200WA that sets the native resolution to 720x480p is it combines the EDID of the two displays), and I get the same results as when the HTPC is connected directly to the AVR.

I hope this helps, but it looks like the JVCs (mine is a 2015 model, the 2017 models would likely behave the same) are not very good candidates for the auto custom res at this stage, at least with nVidia.

At least the EDID values give me a much better stability, even if it's not perfect. I do get a few frame drops per hour, but that's not as bad as one every 3-5mn, which is what I get by default.

I hope this helps, let me know if I can test anything else for you.

[Razoola]

There are 2 known issues where this happens: 1) Either if you have an AVR in between your HTPC and your display. Or 2) If you have profiles which include the "display modes" tab. Of course I'll try to fix this.

Ok, That explains the problem with my two TVs attached to the PC as both have an AVR between. My PC monitor however does not and I do not have profiles that include the display mode tab either.

Its a monitor connected via DVI directly to the GFX card. When I look at the identfication of it in madVR I see the following and there is no tab with 'raw edid data'. any idea why the custom resolution tab appears and then quickly disapeers in this situation? Screenshot below and I have confirmed windows has the monitors driver installed (win 7 x64 although I use 32bit madVR).

http://unibios.free.fr/madvr.png

[huhn]

Forgive me my unknowingness:
Is it really necessary to prevent audio resampling at all costs if you want to feed your expensive amplifier well?
Or in other words: Why is A/V resampling with speed adjustment, if necessary, not the holy grail?

I'm confident I once knew such stuff, before smooth motion neglected my mind. :D


a custom refresh rate doesn't change the video or the audio so that's a plus.

i personally think a proper resampling is absolutely save but you can't use that on object based audio.

[Razoola]

Forgive me my unknowingness:
Is it really necessary to prevent audio resampling at all costs if you want to feed your expensive amplifier well?
Or in other words: Why is A/V resampling with speed adjustment, if necessary, not the holy grail?

I'm confident I once knew such stuff, before smooth motion neglected my mind. :D

There is another option also.

If you are using reclock with bitstreaming it does not resample audio, it simply repeats or drop audio packets as needed. I prefer it this way given Id rather have dropped audio packet and dropped video frame.

IMO the best solution is custom resolutions. If thats not possible then its reclock with audio bitstreaming providing your refresh rate is really close. If not, then reclock with audio resampling.

[el Filou]

Colored steps in RGB? 24576 is suspiciously 3x 8192.That's how I guessed they calculated that figure. Plasma vendors have always used weird ways to present specs ("3000 Hz panel" comes to mind :rolleyes:), so I compared with the smallramp.ytp test pattern and the quality, from best to worst, seems to be:
1. NVIDIA set to 12 bit and madVR set to "10 bit (or higher)"
2. NVIDIA and madVR both set to 8 bit. I put this in second place because it looked to my eyes as if there was a slightly little bit more noise, but it's possible I was fooled and it was placebo
3. NVIDIA set to 12 bit and madVR set to 8 bit => visible banding (I blame the GPU rather than the display)

This was with a test pattern so I assume I wouldn't see a difference with real content and will just keep the NVIDIA to 8 bit, as it would be a hassle to change madVR config each time I change refresh rate.

[FDisk80]

Need a crash report, then.

Done! Here you go.

https://pastebin.com/6Yj8gstv


Another strange thing I found out. If I pause the video before I switch to full screen 24Hz and unpause after it's in full screen it does not crash.
After that I can go in and out of full screen 60Hz to 24Hz and 24Hz to 60Hz without pausing. It just must be paused one time for it not to crash anymore.
Also the picture while switching looks strange for a second, it looks very low quality pixelated. Than it recovers and returns to normal.


Here is how the image looks when it crashes and also how it looks after pausing the video and going full screen (when it crashes it just freezes like this and sound keeps playing and when it recovers it looks like this just for one second): https://i.imgur.com/3FfuRtW.jpg (The TV does switch to 24Hz but player just shows the info that was last seen before it went fullscreen).

And this is how it looks after it recovers: https://i.imgur.com/RAIdI5j.jpg

[aufkrawall]

a custom refresh rate doesn't change the video or the audio so that's a plus.

Ack. However, to some point it should be impossible for human perception to notice occasional speed adjustments.


i personally think a proper resampling is absolutely save but you can't use that on object based audio.
Ok, that's a showstopper if you have such equipment.

Btw. how cool is the new custom resolution feature?
A bit weird to have this in a video renderer, but madshi isn't taking any prisoners. :D
Buut: How can I remove the created resolutions? I searched the tutorial for the words "remove, disable, delete" but can't find it.

[Asmodian]

There is a delete button on the custom resolution tab in madVR. It appears when you select the custom mode.

[madshi]

Colored steps in RGB? 24576 is suspiciously 3x 8192.
Yes, that must be it!

after I read the doc I was left wondering if you had considered possible optimizations for the case where the audio and video clocks are actually driven by the same hardware clock at the lowest layer. The typical example is audio over HDMI, where the audio and video are sent down the same output. In that particular case, it is my understanding that the audio and video clocks are the same because they are managed by the same chip (the GPU) and when one looks at the HDMI wire format, one realizes the audio is sent interleaved with the video (audio is sent inside the blanking interval), which AFAICT means that it would be difficult to use two different hardware clocks.
I've no idea if an HDMI GPU has only one clock circuit for both video and audio. It could be true, or maybe not. In any case, doing a measurement should produce good results in both cases, so why not go the safe way and measure? Sure, it's slower, but it's not like you have to redo it all the time.

However, there might be a different option to speed things up a bit, but I'm not sure yet...

The X35 doesn't have 4K input and the new JVCs are quite tricky with HDMI, so I don't think the comparison tells us much.
I had hoped they had improved the HDMI input instead of making it worse... :(

The "custom modes" tab always lists the modes correctly. When I optimize 23p, it's only 23p that is changed as far as MadVR is concerned, there is no mix up with 24p.

For the OS, all the modes remain avaliable in the dropdox list (both 23 and 24).

It's only in the nVidia CP control panel that 24p disappears from the list and moves into the custom res modes.

However, if I manually select 23p from the control panel and start playback with MPC-BE directly, it's the optimized 23p mode that is selected, and when I go back to the panel the nVidia custom 24p is selected. Of course MadVR isn't set to automatic refresh rate change, as this is handled by MyMovies.

If I start playback with MyMovies, MyMovies switches automatically to the custom 23p, so it works fine.

As far as I can see, it's only a problem in the nVidia control panel list, from a functionality point of view all works as expected, whenever a player/app requests 23p it's the optimized mode that is selected.
Ok, thanks.

Ok I have created an optimized 23 and 24 Hz mode using madVR now. Using Win 10 Display Adapter Properties both are listed and I can switch between both just fine.

The Nvidia control panel shows the original 23Hz mode and a custom 24Hz mode. But both result in switching to the optimized 23.976 Hz mode. No way to get 24Hz from nvidia control panel.

This is what it looks like:
http://imgur.com/a/b5mI8
Ah ok, but it's not really a big problem, is it? Anyway, nothing I can do about it.

https://pastebin.com/P5yCW0dM
Done! Here you go.

https://pastebin.com/6Yj8gstv
Ok, thanks. Both crash reports are basically identical. Will see what I can do with them.

Forgive me my unknowingness:
Is it really necessary to prevent audio resampling at all costs if you want to feed your expensive amplifier well?
Or in other words: Why is A/V resampling with speed adjustment, if necessary, not the holy grail?
What happens if you resample a video from e.g. 1920x1080 to 1921x1081 with Lanczos? Or from 1920x1080 to 1920x1080 with a sub-pixel shift? I think this is somewhat comparable to audio resampling. If you have to touch the audio then I would at least upsample, but then the question is if the DAC is good enough to handle the higher stress in good quality. But this is a really complicated topic that I don't really want to get into right now. Generally, though, any processing that can be avoided should better be avoided, if possible. At least that's my opinion. Upsampling might be an exception to this rule, if the DAC can handle it well.

I did some tests with the 1080 Ti connected to the JVC RS500 directly. Of course, no sound.

I got very surprising results.

First of all, the EDID mode that works perfectly and gives me ate least 1 hour without a frame drop when the AVR is in the chain doesn't work so well with a direct connection. It frequently causes a picture corruption (strong magenta shift on the whole picture) and doesn't bring any improvement (5mn before a frame repeat). It is enabled though, as confirmed by the * in the custom modes list, but it's just not usable.

Even more weird, there is no custom mode created in the nVidia control panel, so 24p remains available in the list and there is no custom 24p created.
Very weird.

Finally, I tried to optimize it (it does get the data, which proves that the "ghost" optimised mode is selected) and no optimized mode work, whether the pixel clock is the same or not. I didn't try them all, but I tried the ones with the same pixel clock and a few of the ones showing a good compatibility (around 80%) as well as a few random ones with lower compatibility. No go for any of those tested (no signal).
It could still have measured the default non-changed mode, we don't know for sure, I would say. Anyway...

If you're up for some more tests, the following would be interesting:

1) It would be interesting to start with the EDID mode (which should work), then you could try manually modifying all of the 6 left side edit boxes (front porches, back porches, sync widths), one by one. E.g. try adding 1 pixel to horizontal front porch. If you try that, does the JVC accept it or not? If you try this with each of the 6 edit boxes, we will know for sure if the JVC accepts modifications to any of these 6 timing parameters at all, or not. Maybe it just doesn't like back porch changes (which is what my optimization does). Maybe it would be fine with front porch changes? FWIW, vertical values don't have a raster, just adding 1 there should work. But some displays don't like odd horizontal values. So there you could try to add either 1 or 2.

2) Do any of the standard timing modes work, e.g. CVT Reduced Blanking or GTF? If so, maybe the JVC will accept back porch changes based on any of those timings?

Ok, That explains the problem with my two TVs attached to the PC as both have an AVR between. My PC monitor however does not and I do not have profiles that include the display mode tab either.

Its a monitor connected via DVI directly to the GFX card. When I look at the identfication of it in madVR I see the following and there is no tab with 'raw edid data'. any idea why the custom resolution tab appears and then quickly disapeers in this situation? Screenshot below and I have confirmed windows has the monitors driver installed (win 7 x64 although I use 32bit madVR).

http://unibios.free.fr/madvr.png
This is surpising. I would have thought that all digital monitors send an EDID block. Your's doesn't seem to do that at all? Have you ever seen an EDID block for this monitor?

[aufkrawall]

There is a delete button on the custom resolution tab in madVR. It appears when you select the custom mode.
It's not there:
https://abload.de/thumb/madvr0esnt.png (http://abload.de/image.php?img=madvr0esnt.png)
I'm using EDID override via CRU, maybe that confuses madVR?

[Manni]

I had hoped they had improved the HDMI input instead of making it worse... :(


They haven't made it worse, they have made it more stable, but it takes 15-20 secs to sync now. It's because of the 4K input. Once it's synced, it's rock stable though unlike some of the former gen (not your X35, but the X500/X700 gen).


It could still have measured the default non-changed mode, we don't know for sure, I would say. Anyway...


This is why I requested an indicator in the OSD of MadVR when it's recording data, ideally specifying a unique ID for the mode being recorded. Say you give a 00-99 number to the modes in the list in custom modes, then we can check in the OSD. 1) if MadVR is recording data or not and 2) if it is recording data for the correct custom mode or not.


If you're up for some more tests, the following would be interesting:

1) It would be interesting to start with the EDID mode (which should work), then you could try manually modifying all of the 6 left side edit boxes (front porches, back porches, sync widths), one by one. E.g. try adding 1 pixel to horizontal front porch. If you try that, does the JVC accept it or not? If you try this with each of the 6 edit boxes, we will know for sure if the JVC accepts modifications to any of these 6 timing parameters at all, or not. Maybe it just doesn't like back porch changes (which is what my optimization does). Maybe it would be fine with front porch changes? FWIW, vertical values don't have a raster, just adding 1 there should work. But some displays don't like odd horizontal values. So there you could try to add either 1 or 2.


I will try to do the test above when I find the time and I'll report back.


2) Do any of the standard timing modes work, e.g. CVT Reduced Blanking or GTF? If so, maybe the JVC will accept back porch changes based on any of those timings?


No, none of the standard timings work apart from EDID. I tried them all, as I always try all the modes with the same clock.

In the optimised modes, I already tried those with the same back porch as the EDID (296 for the JVC off memory) as I thought they might be more compatible, but it didn't make any difference, they all fail.

[AngelGraves13]

I went back to DXVA2 copy-back because apparently, DX11 doesn't support VC-1 codec? The image was either black or blinking from black to pixelated and back to black. Switched back to copy-back and it works fine now. Guess it's not yet ready for prime time.

The source I was using was The Vampire Diaries Season 1

[lvqcl]

What happens if you resample a video from e.g. 1920x1080 to 1921x1081 with Lanczos? Or from 1920x1080 to 1920x1080 with a sub-pixel shift? I think this is somewhat comparable to audio resampling.

If you resample audio from 48000 Hz to 47995 or 48010 Hz you'll probably lose high frequencies. For example, 23 kHz and above. Or 23.5 kHz and above, depends on a resampler used and its settings. IMHO it will be inaudible.

[aufkrawall]

I went back to DXVA2 copy-back because apparently, DX11 doesn't support VC-1 codec? The image was either black or blinking from black to pixelated and back to black. Switched back to copy-back and it works fine now. Guess it's not yet ready for prime time.

The source I was using was The Vampire Diaries Season 1
Works here with VC-1 interlaced on GTX 1070. You probably stumbled over a driver bug?
Edit: Progressive also works here.

Btw: Has it already been mentioned that D3D11 deinterlacing already works with H.264 interlaced, but not VC-1?

Unfortunately, I just realized how bad GPU deinterlacing is. DXVA2, D3D11VA, CUDA and QuickSync all show nasty aliasing which YADIF doesn't show.

[nevcairiel]

Btw: Has it already been mentioned that D3D11 deinterlacing already works with H.264 interlaced, but not VC-1?

D3D11 Native mode should not support any deinterlacing right now.

[aufkrawall]

Seems like LAV Filters fall back to software for H.264 interlaced, so madVR can use DXVA2 deinterlacing.
https://abload.de/thumb/softwarechs3m.png (http://abload.de/image.php?img=softwarechs3m.png)

Here's the file:
https://drive.google.com/file/d/0BwxFVkl63-lEbFBzak1sbmU1N0E/view

[nevcairiel]

Thats intentional as a temporary work-around because deinterlacing is still missing. Once madVR supports deinterlacing, it'll also accept interlaced connections. I believe it only determines this on the framerate, which can be a bit hit or miss on some content, but hopefully its only short-term.
Also, it should really just switch to copy-back and not to software I would think.

[aufkrawall]

Agreed. This VP-1 interlaced "slips through" and gets decoded via native D3D11VA, so result shows combing:
https://drive.google.com/file/d/0BwxFVkl63-lERnhlY1pHeW5wbjQ/view

But shouldn't the H.264 interlaced file get decoded via DXVA2 and DXVA2 copyback if it's chosen in the LAV Filters settings? It also uses software decoding in these cases.

[nevcairiel]

Your file uses the "baseline" profile, which is not compatible with hardware decoding (or well, potentially not compatible depending on what features it uses, but can't determine that).
For H.264, only "main", "high", or "constrained baseline" (which is a strict subset of "main" then) are supported in hardware.

[aufkrawall]

However, Cuda and QuickSync seem to work (haven't checked CPU usage, but there is VPU usage with Cuda).
So it's the DXVA spec that doesn't know such video streams?

[nevcairiel]

Those probably just lack a profile check. Its a hardware limit.

Like I said, it *can* work, but you don't know if it will. A "constrained baseline" stream is also a "baseline" stream, just with extra constraints that forbid using certain features. But you could also just not use those features and forget setting the constraint flag, and you have a "baseline" stream that works in hardware.
Hardware typically doesn't check a profile value and then fails - hardware fails if features are used that it doesn't support, and the "baseline" profile has a bunch of those in it, but that doesn't say that every baseline stream uses them - but we won't know that, so we cannot support baseline decoding safely.

I tightened the profile checks for DXVA decoding recently because of issues with such cases. It may happen that some odd wrongly-flagged stream that used to decode before now uses software, but thats better in my book then failing to decode another stream entirely.

[Manni]

If you're up for some more tests, the following would be interesting:

1) It would be interesting to start with the EDID mode (which should work), then you could try manually modifying all of the 6 left side edit boxes (front porches, back porches, sync widths), one by one. E.g. try adding 1 pixel to horizontal front porch. If you try that, does the JVC accept it or not? If you try this with each of the 6 edit boxes, we will know for sure if the JVC accepts modifications to any of these 6 timing parameters at all, or not. Maybe it just doesn't like back porch changes (which is what my optimization does). Maybe it would be fine with front porch changes? FWIW, vertical values don't have a raster, just adding 1 there should work. But some displays don't like odd horizontal values. So there you could try to add either 1 or 2.


Okay, I've done the requested tests and here are the results:

1) I can change any vertical value with an increment of 1
2) I can change any horizontal value with an increment of 2
3) If I change the first two horizontal values (front porch, sync width) with an increment of 1, it looks like get a sync, but it's not the target rate (23p) it's my default rate (30p). I know this because I have a Vertex that reports on screen the actual picture parameters in real-time (resolution, frame rate with 3 decimals, color space, bit depth and HDMI frequency to give an indication of the bandwidth, so super useful for testing/debugging).
4) If I change the back porch with an increment of 1, I get the invalid mode (corrupted colors, not the magenta one) I've already reported when testing some of the optimized modes (usually those with the same pixel clock). It's so bad that the Vertex is unable to overlay its OSD, and my mouse cursor disappears.

The EDID values should give me a rate of 23.975757575. During playback, the effective rate reported by MadVR's OSD is 23.97515, so pretty close.

I couldn't get any closer to 23.976 changing only one of the six parameters in any direction, and my brain isn't powerful enough to guess which combination of two or more parameters might achieve this, so I'll wait for a fix.

In case it helps your debugging, here are my values:

1276+88+296
8+10+72

One last thing: I've noted that when you delete a custom mode, the associated recorded data isn't deleted, so it's still there when you re-create the mode. This could be desirable, but it's an issue when you do it for a different display.

[nevcairiel]

I know this because I have a Vertex

Perhaps thats your problem. If you keep adding devices in between the GPU and the Display, you increase the chances of failure each time. If you want to know what the display can actually do, you should try a direct connection - then you know if its one of those devices you throw into the mix, or if the display is really that picky.

General rule of debugging: Simplify to the absolute first, then check, and re-add until it breaks. At least you'll know what is to blame.

[aufkrawall]

I tightened the profile checks for DXVA decoding recently because of issues with such cases. It may happen that some odd wrongly-flagged stream that used to decode before now uses software, but thats better in my book then failing to decode another stream entirely.
Sure, totally agreed. Then I just have to switch to a video test sample which fits into the spec.

[Manni]

Perhaps thats your problem. If you keep adding devices in between the GPU and the Display, you increase the chances of failure each time. If you want to know what the display can actually do, you should try a direct connection - then you know if its one of those devices you throw into the mix, or if the display is really that picky.

General rule of debugging: Simplify to the absolute first, then check, and re-add until it breaks. At least you'll know what is to blame.


You should follow more closely, I have already tested a direct connection between the GPU and the display and reported the results, in fact it's worse :)

By the way, I don't really have a problem, I'm providing Madshi with the information he has requested. I'm pretty happy with the 1-2 hours that the EDID values give me, it's a big improvement over the 3-5mn before.

PS: I've already thanked you, but I'm aware I owe this to you too, so thanks again :)

[arrgh]

Originally Posted by arrgh View Post

since you have several times advertised to use Win81 instead of Win10, I have given it a shot…

the problem obviously are the graphics drivers; Intel & MS decided to support KBL graphics only in Win10 (in my case HD620)…

[...]

It works up to the point where I get the same problems with “jumping” frames (both, in 2D and 3D) which was already addressed some month ago for Win10 (…an Intel driver issue). You were able to fix it for Win10."

The fix I made was not specific to win10, it should work on all OSs. So there's not really much I can do about this right now. It's definitely a driver issue, but my fix is supposed to help, at least it did for me.

maybe, but on the other Hand MPC-BE's EVR-CP renderer does not show such problems in 2D (obviously I can not check for 3D); I have checked several Driver Versions on Win81 (4508, 4526, 4665, 4678) with the same result; somtimes it takes a Minute until the Problem sets in;
It did really work for you on Win81 with Kaby Lake Drivers? Which one?

an other issue I have, is (on both, Win10 and Win81) that when I exit 3D (Player: MPC-BE), madVR fails to set back the frame rate from 23p to 50p (which is my standard for TV); as a result MPC-BE hangs and I can only reboot;

best regards

[aufkrawall]

Why does madVR not enable deinterlacing for these two videos?
https://www.hdpvrcapture.com/hdpvrcapture/samples/20090227_233739-H.264.m2ts.mp4
https://www.hdpvrcapture.com/hdpvrcapture/samples/20090227_235906-H.264.m2ts.mp4
OSD says off because of "framerate". LAV Filters activates deinterlacing without forcing if it's allowed to do deinterlacing.

[madshi]

Okay, I've done the requested tests and here are the results:

1) I can change any vertical value with an increment of 1
2) I can change any horizontal value with an increment of 2
Interesting. But if this works, then why don't any of the "optimized" modes work for you? Some of them should have horizontal values with an increment of 2. Maybe the optimized modes differ too much from the EDID values?

For now it's not important that you actually achieve an optimized mode. It's more important to figure out why your JVC accepts some modes but not others. If you can figure that out, maybe I can improve the optimized modes to also work for your JVC.

One last thing: I've noted that when you delete a custom mode, the associated recorded data isn't deleted, so it's still there when you re-create the mode. This could be desirable, but it's an issue when you do it for a different display.
The recorded data is stored in a path which is unique to both the display and the GPU.

Why does madVR not enable deinterlacing for these two videos?
https://www.hdpvrcapture.com/hdpvrcapture/samples/20090227_233739-H.264.m2ts.mp4
https://www.hdpvrcapture.com/hdpvrcapture/samples/20090227_235906-H.264.m2ts.mp4
OSD says off because of "framerate". LAV Filters activates deinterlacing without forcing if it's allowed to do deinterlacing.
The indication "framerate" should be self-explaining, no?

madVR is told from upstream (LAV Decoder?) that this stream has a framerate of 59.940fps, which is a fieldrate of 119.88. That is not a framerate/fieldrate which is ever interlaced in normal user content. Consequently madVR disables deinterlacing. Which IMHO is the right thing to do.

My best guess is that the file or the file's metadata is broken.

[aufkrawall]

My best guess is that the file or the file's metadata is broken.
Hm, MediaInfo lists original frame rate of 29.97fps. Since LAV correctly enables deinterlacing when it is allowed to do so, I think it should really report the original frame rate as the actual framerate to madVR. Currently, it reports 59.94fps to madVR for the interlaced content.

Nev's opinion? :)

Edit: Ok, with LAV Filters deinterlacing it, it reports 120fps to madVR. Really seem to be broken flags.

[Manni]

Interesting. But if this works, then why don't any of the "optimized" modes work for you? Some of them should have horizontal values with an increment of 2. Maybe the optimized modes differ too much from the EDID values?


I have no idea. As I already reported to you, I specifically tested suggested custom modes with the same back porch value as the EDID values, that didn't work. I also tried testing modes with only even horizontal values, that didn't help.


For now it's not important that you actually achieve an optimized mode. It's more important to figure out why your JVC accepts some modes but not others. If you can figure that out, maybe I can improve the optimized modes to also work for your JVC.


I am providing all the info you are requesting and doing all the tests you are suggesting. I don't think I can figure this out on my own, but if you can think of any other tests or need any other info, I'm happy to help. I already have a near perfect rate for 99% of my content, so don't spend any time on this if you have better things to do. I'm happy to help, but the EDID timings are good enough for me from a practical point of view. I can live with 1-2 frame drops per film (in 2D). :)


The recorded data is stored in a path which is unique to both the display and the GPU.


I'm not sure this is correct. When I tested the direct connection to the JVC earlier, I'm almost 100% sure that when I added the 4K23 custom mode, it appeared with data available. It shouldn't be the case as technically it was a different display (AVR vs JVC). In any case, when we delete the custom mode, it might be a good idea to also delete the corresponding recorded data, to make sure we can start afresh if we decide to re-create the mode, without having to do a clean install of the drivers.

A few more things:

1) The custom resolutions come and go in the nVidia control panel. Sometimes it's there, sometimes it isn't. I haven't been able to see if there was a reason for the custom modes to disappear or reappear in the list, but it's definitely unstable. The modes are still there under the hood, they just come and go from the list.

2) The EDID values do not work for 1080p23 (the refresh is weird, some kind of double picture as if two different refresh rates were applied simultaneously, I know it's not possible, only trying to describe the effect). In that case, it's difficult to run the optimization.

3) I already asked but don't think I've seen a reply. I don't think the 1080p23 mode would be applied for 1080p23FP. Is there a way to optimize that mode? Even when stereoscopic 3D is enabled (so when specific 1080pFP and 720P 3D mode are listed in the nVidia control panel), I can't see any FP modes in the custom modes list. It would be great if they were listed so we could try to optimise them (if it's technically possible). My 1080p23FP mode has a frame repeat every 3-4mn, so that's not ideal.

[AngelGraves13]

Works here with VC-1 interlaced on GTX 1070. You probably stumbled over a driver bug?
Edit: Progressive also works here.

Btw: Has it already been mentioned that D3D11 deinterlacing already works with H.264 interlaced, but not VC-1?

Unfortunately, I just realized how bad GPU deinterlacing is. DXVA2, D3D11VA, CUDA and QuickSync all show nasty aliasing which YADIF doesn't show.

Likely a LAV Filters issue as unchecking VC-1 from the decoding list in LAV Video fixes the issue under DX11, and it works fine under Software, DXVA2 Native and Copy-Back as well as CUDA.

[omarank]

Thanks for the kind offer, guys! As I mentioned before, I want to wait for madVR v1.0, before accepting any kind of donations. I'be be thankful if you could remember your willingness to donate for that time... :)
Waiting for v1.0.. :)

madVR v0.92.0 released

1) new "custom modes" feature

2) native D3D11 DXVA hardware decoding

3) 10bit in fullscreen windowed mode

4) "let madVR decide" HDR configuration

5) support for AMD's private HDR switching API

Thanks for such an amazing update. I got good results with Custom Resolution: 1 frame drop every 1.18 days for a 59p custom mode on a 60Hz monitor. I found some issues:

1. madHcCtrl.exe stops responding when I change the refresh rate through display adapter properties in OS control panel and come back to access madVR settings.

2. madVR measurements for timings optimization do not happen if video is played in JRiver Media Center. In MPC-HC, it works perfectly.

3. How do I create a custom mode for resolutions like 48Hz or 72Hz? Do I have to find some standard timings to begin with on the net first?

I am on Windows 10 Enterprise Anniversary edition. GPU is AMD HD8970M. Drivers: Crimson Relive 17.7.2.


10 bit output in fullscreen windowed mode is really cool and works perfectly, however on my system with AMD card, FSE is more stable. The other features are also interesting.

Those of you who have crash problems with v0.92.1, can you please try this test build?

http://madshi.net/madVR0921b.rar

Does this fix the issue for you?
Yes, fixed, except for madHcCtrl.exe not responding issue mentioned above.

[nevcairiel]

Hm, MediaInfo lists original frame rate of 29.97fps. Since LAV correctly enables deinterlacing when it is allowed to do so, I think it should really report the original frame rate as the actual framerate to madVR. Currently, it reports 59.94fps to madVR for the interlaced content.

Nev's opinion? :)

Edit: Ok, with LAV Filters deinterlacing it, it reports 120fps to madVR. Really seem to be broken flags.

The MP4 claims 59.940 FPS, the video stream says 29.970. LAV prefers container info over stream info usually, but I do have some checks that try to detect such field/frame discrepancies, and I've updated that to also work for MP4 files, so it should be fixed in next LAV.

[SweetLow]

Here's a custom mode tutorial:

http://madvr.com/crt/CustomResTutorial.html
...
sadly on the fly pixel clock corrections are currently not technically possible!

Let say we did optimization, but still don't have exact rate (and have drop/repeat in one or two hours). But instead of exact dropping/repeating can we do some kind of SmoothMotion (blending) but not always - only in(near) the point where repeat/drop actually will take place without this blending?

[huhn]

and if you reach that point every frame needs blending which looks terrible. you are kind of only displaying blended frames at this point for about a 1h or you are finally repeating or dropping a frame.

[theonepugna]

so after all this updates, whats like the best chroma upscaller for anime/cartoons?

[huhn]

there is no best and that's the reason you should not ask for the best on this forum.

super xbr 100 and ngu aa are popular for chroma scaling.

[SweetLow]

every frame needs blending
Your "every" mean 1 or 2 frames (in limit).

[huhn]

nope "all" frames.

even if you blending the audio video clock is not in sync.

if you get 24 ms off sync you will stay 24ms of sync even with smoothmotion. a frame is still displayed every 41 ms no matter what.

if you blend at the end where is goes about 41 ms out of sync you will get a huge judder at this point about the same as a repeate/dropped frame.

[Razoola]

This is surpising. I would have thought that all digital monitors send an EDID block. Your's doesn't seem to do that at all? Have you ever seen an EDID block for this monitor?

I can use Monitor Asset Manager and it shows the edid for the monitor so I guess it does send it.

[Sarlaith]

Edit: nevermind....thought I found a bug but after tinkering around it was Windows and it's fun loving "let's enable or disable that setting!"

[Bernix]

Hi,
sorry if it was mentioned earlier, but when I do virtual crop in mkvtoolnix madshi render playing it in wrong way. Iam using potplayer. All other renderers like opengl, build in direct 3d 11 videorenderer etc. shows it propertly. It is in form of left, up, right, down. So f.e. if I use 0,140,0,140 then picture in Madshi renderer looks, that up crop is ignored and down crop is 2x140. So up crop and down crop is added to down side of picture. Similary to if I do in mkvtoolnix 0,0,280,0.
Sorry again if that was discussed earlier or if I did something wrong.
I even dont know if problem is related to madshi renderer or potplayer itself. But it seems to me that it is renderer issue.
Bernix
Edit:it seems that up croping is added instead of substracted or other way round.