madVR - high quality video renderer (GPU assisted)

[SamKook]

I have to admit that I'm not exactly sure of what chroma upscaling does, but is it normal that the chroma upscaling setting come into play when I do 1080p->768p and not when I actually upscale something?(After more testing, it seems it also affect upscaling, but to a much lesser extent since I can use jinc taps 8 fine for 480p->768p)

I was trying the jinc tap8 settings with it and noticed that 1080p video started stuttering on my 720p TV so I was quite surprised since I assumed it would only affect upscaled videos.

[mzso]

Yes, that's the main reason. But why would that change next year?

Well, if what they say is true. The AMD's Kaveri APU-s will have a shared memory space for IGP and CPU. So no moving around since there's only one memory.

[LoRd_MuldeR]

I have to admit that I'm not exactly sure of what chroma upscaling does, but is it normal that the chroma upscaling setting come into play when I do 1080p->768p and not when I actually upscale something?

Chroma is the "color" information, as opposed to Luma, which is the "brightness" information.

This distinction is made in YCbCr colorspace, where the Y-channel is the Luma and the Cb/Cr channels are the chroma. In RGB colorspace we don't have that distinction.

Now video is usually stored in YCbCr colorspace, but displayed on the screen in RGB colorspace. Also in YCbCr colorspace the Chroma is usually stored at half the resolution of Luma!

This is called Chroma sub-sampling. And, as a consequence, when converting YCbCr to RGB, we have to upscale the Chroma, even if the (Luma) resolution didn't change.

(Given that your input is 4:2:0 Chroma sub-sampled, which it most likely is, I think chroma up-scaling is always required, except when down-scaling to exactly 1/2 of the original size)

See also:
* http://en.wikipedia.org/wiki/File:Barns_grand_tetons_YCbCr_separation.jpg
* http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios

[TheLion]

With the new anti-ringing feature I switched back to using madVR instead of EVR. But the reason for using EVR is still present in the newest revision. I have severe issues with DPC spikes using madVR together with my AMD/ATI 5870 board. When using EVR DPC latency is excellent with no spikes. The big problem about this is that I get issues with audio playback (pops, clicks, even sync is lost on DPC spikes). I have seen other madVR users mention this with the 58xx series as well.

I tried to optimize my ASIO buffer settings and also change the queue sizes in madVR. Both of these help somewhat but the spikes are still there.

I am not sure how to find the "right" GPU flushing settings in madVR - is this just try and error? I haven't touched these yet.

Is there anybody who has a stable madVR configuration (queue and flushing settings) running with an 58xx ATI/AMD board? Thanks!

[Pat357]

We gotta try it though. ;) I mean, if the 3770k and the 680 can't handle it, well, then it's not a very useful option. LOL! :D
We could still have the 39xx CPU (6+6 cores) with a 690 (=2x680) ! ;)

[mindbomb]

@TheLion
what are you using to decode the video?
I've found that older radeon cards have these problems when using dxva copyback in lav video with madvr.

also, what player has asio support?

[SamuriHL]

We could still have the 39xx CPU (6+6 cores) with a 690 (=2x680) ! ;)

And they tell me MY HTPC is overkill. LOL

[TheLion]

@TheLion
what are you using to decode the video?
I've found that older radeon cards have these problems when using dxva copyback in lav video with madvr.

also, what player has asio support?

I am using software decode (LAV or the internal madVR decoders). This doesn't matter because using EVR with the same configuration the DPC spikes are gone.

The player is JRiver MC18.

[edragon]

jinc is too slow that my card only can run jinc3 without anti-ringing....

my card is nvidia gtx550ti
my setting
chroma softcubic 100
image upscale jinc3 without anti-ringing

use exclusive mode 8 frames

[Coalgirls]_Sora_wo_Kakeru_Shoujo_19_(1280x720_Blu-Ray_FLAC)

use mpc+ffdshow+reclock+SVP3.0

[blackjack12]

Here are the results from testing all 4 versions

TEST 1 Trial - madVR837test1:
Windowed Mode: Bad – but seems to take more jumps before problem
FSE Mode: Good

TEST 2 Trial - madVR837test2:
Windowed Mode: Worse
FSE Mode: Good

TEST 0.83.1:
Windowed Mode: Bad
FSE Mode: Good

TEST 0.82.5:
Windowed Mode: Good
FSE Mode: Good

Madshi -

This is worse in latest 0.84.2 build. Even FSE showing problems ... back to 0.82.5 and no problems.

Can't upload huge BD rip files but worst case test is always full BD rip that contains VC-1i or h264i (interlaced) content.

VC-1i - "Life"
h264i - "National Parks Americas Best Idea"

Created from original BD with makeMKV 1.7.7 and remuxed with latest mkvmerge ver 5.8

[THEAST]

Regarding the issue with video playback becoming jerky after a few jumps in the video which blackjack12 reported earlier, I just tested v0.84 on my laptop which still has XP, the issue still existed, then updated to v0.84.2 and latest build of MPC-HC and the issue is 100% gone.

[madshi]

ATI 5750, 12.8, W7. Yes, I have updated.
Oh well. I guess I'll make a test build with some changes later.

I have to admit that I'm not exactly sure of what chroma upscaling does, but is it normal that the chroma upscaling setting come into play when I do 1080p->768p and not when I actually upscale something?(After more testing, it seems it also affect upscaling, but to a much lesser extent since I can use jinc taps 8 fine for 480p->768p)

I was trying the jinc tap8 settings with it and noticed that 1080p video started stuttering on my 720p TV so I was quite surprised since I assumed it would only affect upscaled videos.
Chroma upsampling is always active (at least with normal movie sources).

Well, if what they say is true. The AMD's Kaveri APU-s will have a shared memory space for IGP and CPU. So no moving around since there's only one memory.
I don't think it will be as simple as that. If they create shared memory, it will probably not be as fast as GPU dedicated memory. Anyway, even if it were full speed, I still won't implement a solution which only works for some selected products of one manufacturer.

With the new anti-ringing feature I switched back to using madVR instead of EVR. But the reason for using EVR is still present in the newest revision. I have severe issues with DPC spikes using madVR together with my AMD/ATI 5870 board. When using EVR DPC latency is excellent with no spikes. The big problem about this is that I get issues with audio playback (pops, clicks, even sync is lost on DPC spikes). I have seen other madVR users mention this with the 58xx series as well.

I tried to optimize my ASIO buffer settings and also change the queue sizes in madVR. Both of these help somewhat but the spikes are still there.

I am not sure how to find the "right" GPU flushing settings in madVR - is this just try and error? I haven't touched these yet.

Is there anybody who has a stable madVR configuration (queue and flushing settings) running with an 58xx ATI/AMD board? Thanks!
Do you really think it has anything to do with the ATI card? I mean you're running audio via Firewire, aren't you? I could create a test build with a lower priority for the madVR VSync thread. Maybe that could help, not sure...

This is worse in latest 0.84.2 build. Even FSE showing problems ... back to 0.82.5 and no problems.

Can't upload huge BD rip files but worst case test is always full BD rip that contains VC-1i or h264i (interlaced) content.
Ouch. What happens if you switch madVR to Bilinear for all up- and downscaling options? Does that work around the problem? Are you using software or hardware decoding? I'm not really sure what to do here because I can't reproduce the problem and it seems most people don't have this problem. I could try creating a test build, but I'm not sure how difficult it will be...

Which media player are you using? Maybe updating the media player to the latest build could help?

Regarding the issue with video playback becoming jerky after a few jumps in the video which blackjack12 reported earlier, I just tested v0.84 on my laptop which still has XP, the issue still existed, then updated to v0.84.2 and latest build of MPC-HC and the issue is 100% gone.
Interesting, so the problem is gone for you, but not for blackjack12.

[nevcairiel]

Ouch. What happens if you switch madVR to Bilinear for all up- and downscaling options? Does that work around the problem? Are you using software or hardware decoding? I'm not really sure what to do here because I can't reproduce the problem and it seems most people don't have this problem. I could try creating a test build, but I'm not sure how difficult it will be..

IMHO, the problem is at least partially related to him running Windows 8, maybe buggy drivers on AMDs on, or something else.

[Superb]

Oh well, just tried that for the first time, and yes, I can reproduce the freeze here. However, it seems that madVR continues to run just fine. Well, playback stops, but try pressing Ctrl+J to show/hide the debug OSD, it still works and the debug OSD is updated regularly. That indicates that the madVR private threads still run just fine. The freeze seems to be somewhere inside of MPC-HC. I think it's likely a bug in MPC-HC, but I can't say for sure. Maybe if you upload a freeze report from this situation, created with an MPC-HC debug build (with PDB files), I might be able to comment on where MPC-HC is stuck and why.This is the function that generates and saves the thumbnails: http://pastebin.com/1NFDXGBf (https://github.com/mpc-hc/mpc-hc/blob/master/src/mpc-hc/MainFrm.cpp line 4797)
Can't comment on where it's stuck... I don't have a VS environment installed...

[madshi]

@nev, that's quite possible, but then why does v0.82.5 work for him? It must be related to a change in madVR, too, somehow.

@blackjack12: Try this test build:

http://madshi.net/madVRblackjack.rar

Does this work better for you? If not, there are 2 more things that could explain the difference:

(1) In v0.83 and newer I've removed some of the tweak settings that v0.82.5 still had. When you switch back to v0.82.5 do you have any of these tweak settings enabled? I'm talking about the bottom most 3 options in the exclusive mode settings page. And about the D3D11 presentation option. Do you have any of them activated in v0.82.5? If so, try deactivating them one by one to find out which of them you need.

(2) In v0.82.5 the "delay playback start until render queue is full" option applied to seeks, too. In v0.83 and newer it does not. Instead there's a new sub option "delay playback start after seeking, too". Did you have "delay playback start until render queue is full" activated in v0.82.5? If so, try activating "delay playback start after seeking, too" in v0.84.2. Does that fix the problem?

[TheLion]

Do you really think it has anything to do with the ATI card? I mean you're running audio via Firewire, aren't you? I could create a test build with a lower priority for the madVR VSync thread. Maybe that could help, not sure...



You are right, Firewire to Prism Orpheus. I am positive about the ATI card being part of the problem. DPC latency spikes are usually related to "bad hardware interactions"/drivers stalling the system. My DPC latency is excellent during audio only playback AND video playback with EVR. As soon as I switch to madVR trouble begins.

It is interesting that changing the CPU/GPU queue sizes as well as the numbers of frames presented in advance (exclusive mode) have significant impact on the DPC spikes. It is just that I could't find any configuration to avoid them completely.

When I posted this issue in the JRiver forum ATI 58xx users told me they had the same issue, and it was only gone by switching to another card/nVidia. Something I would like to avoid for the time being.

I know it is practically impossible for you to help me here. That's why I asked other ATI 58xx users for stable configurations.

Thanks!

[madshi]

@TheLion,

here's a test build for your DPC problem:

http://madshi.net/madVRlion.rar

Does this build change anything? If not, try disabling fullscreen exclusive mode. Does that change anything?

[THEAST]

Interesting, so the problem is gone for you, but not for blackjack12.
Actually I just tested again and the issue is still there, not sure why I couldn't reproduce it the first time I tried. Considering the fact that blackjack12 is using Win 7 while I can only reproduce the problem on my laptop which has windows XP but can't reproduce it on Win 7 on my desktop, I doubt the issue is OS related; can the problem be caused by forcing Vsync in the VGA driver?

[madshi]

I don't think so, but what do I know. Try disabling that option. Also try the blackjack test build I posted a few posts above. And try the suggestions I posted in the same post.

[madshi]

@nlnl,

try this one:

http://madshi.net/madVRnlnl.rar

Does it fix the problem?

[TheLion]

@TheLion,

here's a test build for your DPC problem:

http://madshi.net/madVRlion.rar

Does this build change anything? If not, try disabling fullscreen exclusive mode. Does that change anything?

Thank you very much! I just spent some time testing this again. Trial and Error with all relevant madVR parameters. I have found a config which avoids the DPC spikes and brings the latency down to the level with EVR.

CPU/GPU queue size: 12/6
Frames in advance: 3
Flush, Don't Flush, Don't Flush, Flush&Wait (sleep)

does the trick.

Thanks for your build. It didn't significantly improve the DPC latency further - which isn't necessary at all since the spikes (and therefor audio drop outs) are gone it seems.

I guess you changed the VSync thread priority. It is fine by me now either way.

THANK YOU!

[6233638]

How high is your DPC latency spiking over what it is if you just leave your system idling? My system idles in the 60-100 range, but seems to have hit just under 300 with madVR running. (300 is well below the threshold of it impacting audio though)


Generally the first steps to try and reduce DPC latency would be to:
Update all your drivers.
Disable unnecessary devices in your BIOS. (if you aren't using the on-board audio, disable it etc.)
Disable power-saving options. (switching between power states tends to spike DPC latency)
Remove any unnecessary peripherals.
If you are still experiencing problems, people have reported success in reducing their DPC latency by changing HPET settings. Personally I would recommend enabling it and setting Windows to exclusively use HPET with the bcdedit /set useplatformclock true command. I find that it tends to stabilise DPC a lot. Other people report success by doing the exact opposite and disabling HPET. (which definitely lowers DPC latency, but I found it unstable)

I would also suggest leaving LatencyMon (http://www.resplendence.com/latencymon) running to help identify what it is that's actually causing you latency issues.

[mzso]

I don't think it will be as simple as that. If they create shared memory, it will probably not be as fast as GPU dedicated memory.
I also heard that memory might be a problem since GDDR5 is significantly faster. So madVR is very memory speed demanding?
Anyway, even if it were full speed, I still won't implement a solution which only works for some selected products of one manufacturer.
I wasn't pushing for it, just mentioned it. I don't even know if error diffusion ditherings is any good at all. Although if it turns out to be good then it might be years before others catch up. As I understand AMD has quite an advantage in integration.

[TheLion]

How high is your DPC latency spiking over what it is if you just leave your system idling? My system idles in the 60-100 range, but seems to have hit just under 300 with madVR running. (300 is well below the threshold of it impacting audio though)


Generally the first steps to try and reduce DPC latency would be to:
Update all your drivers.
Disable unnecessary devices in your BIOS. (if you aren't using the on-board audio, disable it etc.)
Disable power-saving options. (switching between power states tends to spike DPC latency)
Remove any unnecessary peripherals.
If you are still experiencing problems, people have reported success in reducing their DPC latency by changing HPET settings. Personally I would recommend enabling it and setting Windows to exclusively use HPET with the bcdedit /set useplatformclock true command. I find that it tends to stabilise DPC a lot. Other people report success by doing the exact opposite and disabling HPET. (which definitely lowers DPC latency, but I found it unstable)

I would also suggest leaving LatencyMon (http://www.resplendence.com/latencymon) running to help identify what it is that's actually causing you latency issues.

My DPC latency idles between 65 and 112 us (under Windows 7 64bit (DPC measurements aren't reliable under Win8 yet, measured with LatencyMon and DPC Latency checker). It doesn't significantly change under load - even when e.g. 4k RED Epic content is played with EVR. So in general it is very good.

Only when using madVR I had spikes in the 2000us to 4000us range. This had severe impact on the audio playback as you can imagine.

As reported above with the latest madVR and "hand tuned" queue and GPU flush settings it seems I am now back my idle DPC latency. So something madVR does in its default configuration causes ATI 58xx boards (Catalyst version isn't a relevant factor) to "stall".

[Pat357]

When I posted this issue in the JRiver forum ATI 58xx users told me they had the same issue, and it was only gone by switching to another card/nVidia. Something I would like to avoid for the time being.
Have you ever done a test with a different card in that PC ?
If yes, was the problem completely gone, independent from tweakings in Madvr settings ?
Is the problem worse or less with increasing queue sizes ?

[agustin9]

I'm having the spikes problem too. Using cpu 8 / gpu 4 queues and presenting 8 in advance is more stable.

TheLion, please try the catalyst 10.6 drivers, they worked fine for me. I have a 4850 btw.

I noticed the problem using a fasttrack usb soundcard, that with madvr had dropouts all the time. With my soundblaster audigy the spikes are there but it doesn't drop any audio at all

[nlnl]

@nlnl,

try this one:

http://madshi.net/madVRnlnl.rar

Does it fix the problem?

Thanks!
I will be able to try only on Sunday :(

[TheLion]

Have you ever done a test with a different card in that PC ?
If yes, was the problem completely gone, independent from tweakings in Madvr settings ?
Is the problem worse or less with increasing queue sizes ?

Sadly I don't have another card at my disposal. The latency peaks generally get worse when increasing GPU queue sizes. But it is not so easy because there are interactions with the other parameters (CPU queue, frames in advance, GPU flushing).

I am wondering if it would be a viable idea to include default profiles depending on the graphic card (nVidia/AMD/Intel, perhaps per generation) in madVR based on user feedback?!

[JarrettH]

Wow, testing just got so much faster. I just had a look at the keyboard shortcuts section, and there are shortcuts to directly switch between scaling algorithms! :D

Previously I would have to manually take screenshots of an image with each setting, and paste them into Photoshop as layers to compare them. Now I can just hit a key to switch between them and compare inside madVR!



So far Jinc seems pretty interesting in my testing. Jinc 3 seems to be sharper than Jinc 4 at high frequencies, but Jinc 4 is sharper at lower frequencies, and has less aliasing. This is probably a good thing, as most high frequency detail is going to be noise unless you are upscaling Blu-rays.

Strangely, Jinc shows even less high frequency detail than SoftCubic in some tests—presumably because it's a "circular" filter rather than a "square" one.

Jinc 4 with anti-ringing enabled:
http://www.abload.de/img/j4ar5wb0g.png

SoftCubic 80 with anti-ringing disabled:
http://www.abload.de/img/sc80narimxwd.png

I've now been able to confirm that pretty much universally, anti-ringing adds aliasing to all the Bicubic variants. (Mitchell-Netravali through to SoftCubic)

Bicubic 100 also has a serious amount of aliasing with or without it, for some reason. Drastically more than any other Bicubic option.



If you're a fan of sharper algorithms, it definitely seems worthwhile to give Jinc a try.

I'd probably suggest Jinc 4 with anti-ringing for now, and Jinc 3 if your system can't handle it. (Jinc 3 also seemed OK without anti-ringing, to further reduce the demands) I wouldn't recommend Jinc 4 without anti-ringing.

I still like SoftCubic 80 without anti-ringing for highly compressed sources though.

But now thanks to the keyboard shortcuts, you can easily assign keys for Jinc, SoftCubic, and to toggle anti-ringing.



As before, Bicubic 75 with anti-ringing is still my preference for Chroma right now. (while anti-ringing increases the chance of aliasing, the ringing reduction is more important for Chroma)

What I love about Jinc is the analogue feel, but with a good amount of sharpness. Works wonders with HD content and SD as long as it's not interlaced. What I found with DVDs is there was too much aliasing (line crawling) when using Jinc. Could that have to do with them needing to be upscaled more plus interlacing artifacts might get sharpened?

[Gser]

I'm using 5870 and I've never had any problems with MadVR (that were out of the expected).

[NicolasRobidoux]

I don't think it has anything to do with the anti-ringing filter. Try it without, you'll see similar results. Jinc simply looks different because it's a circular resampler compared to rectangular Spline or Lanczos. Jinc does look softer in some situations, but on the positive side it has noticeably less aliasing than even Lanczos. I already mentioned in my v0.84 announcement post that Lanczos still may look better in some situations due to being sharper.
Mathias:
I've not read the whole thread, but I have 3 suggestions:
1) If you find tensor Lanczos (the standard one), which is "orthogonal 2-pass" Sinc-windowed Sinc 3-lobe, too jaggy near diagonals (it's the checkerboard mode rearing its ugly head) as well as too halo-y, substitute Jinc windowing for Sinc windowing. It "softens" the rough edges of standard Lanczos just a little.
(Informal name of this filter: "Ginseng", for "Jinc-Sinc".)
Methods Recommended by Nicolas Robidoux: Recommended Upsampling Methods (Enlarging) (http://www.imagemagick.org/Usage/filter/nicolas)
2) If you find EWA Lanczos (Jinc-windowed Jinc 3-lobe) too soft, you can sharpen it doing something which does not work so well with tensor Lanczos: rescale the filter extent, which is a fairly trivial change once any of them is programmed. In particular, you get an EWA filter which is about as sharp as the above tensor Ginseng (which itself is about as sharp as standard Lanczos) by rescaling the EWA disc so that it has radius exactly 3. A side effect of this rescaling is that any scanline of the enlargement only needs 6 scanlines of the original as data, just like for tensor Lanczos. This method is often called "EWA Lanczos Radius 3". The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x). Specifically, it is .9264075766146068. It's not as free of artifacts as the "full width" EWA Lanczos. But it sure is sharper.
In any case, I don't recommend using "full width" EWA Jinc-windowed Jinc 3-lobes. At least, "tighten it" a little. With a rescaling factor of .99, .98, .95 or ???. But don't use it at full width. Maybe start with 0.9891028367558475 (I'm afraid this value may not be exact down to last full decimal because the library I used to compute it is not as accurate as I wish when dealing with Bessel functions), which minimizes worst case "cross-talk" between the original scan lines. This is one of two variants of a method called EWA LanczosSharp. (Which is not much sharper than the plain EWA Lanczos.)
3) If you want to be a bit more adventurous, I suggest you sigmoidize. Given that I imagine that you have a luma or luminance channel at the ready, the idea is that you convert to a synthetic color space that pushes non-extreme pixel values toward the center of the gamut, do the upsampling using a linear or nonlinear filter on these values, and then undo the compression. What this does is that it minimizes the extreme halos that arise from mid-tones. Or you could do it with all three channels. If you use (which I'm sure you don't) sRGB as input and output colorspaces, you can fake this by computing the color negative, converting applying the transformation from linear RGB to sRGB (as if they are not already), resampling, and then applying the transformation from sRGB to linear RGB, and finally taking the color negative. I imagine that similar "faking" can be done with, say, La*b*.
Examples involving sRGB to sRGB enlargements are found here: Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal...? (http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21804&sid=e7d6d08d872edc5d33d1da6d5a4fc1a7)
Warning: Use a very recent ImageMagick, preferably in HDRI, if you want to try this yourself with it.

[NicolasRobidoux]

Summary of my last comment #2: The EWA Lanczoses (which I believe you call Jinc) have an easy "knob" which fairly predictably affects sharpness.

[TheLion]

Summary of my last comment #2: The EWA Lanczoses (which I believe you call Jinc) have an easy "knob" which fairly predictably affects sharpness.

Personally I like the "organic" look of madVRs EWA Lanczos aka Jinc implementation. But it is a touch too soft compared to Lanczos3/4 for my taste.

So your suggestion, Nicolas, is probably just what is needed ;-)

Looking at your link "Ginseng" looks like a sweetspot and is probably an even "better" alternative than standard Lanczos.

[NicolasRobidoux]

Personally I like the "organic" look of madVRs EWA Lanczos aka Jinc implementation. But it is a touch too soft compared to Lanczos3/4 for my taste.
Warning: Ginseng is a very lightly "tamed" tensor (standard orthogonal) Lanczos.
It does not have the "look and feel" of EWA Lanczos. But it's closer to it than standard Lanczos.
To get more sharpness out of EWA Lanczos without losing the organic feel, use the "knob" described in 2).

[blackjack12]

@nev, that's quite possible, but then why does v0.82.5 work for him? It must be related to a change in madVR, too, somehow.

@blackjack12: Try this test build:

http://madshi.net/madVRblackjack.rar

Does this work better for you? If not, there are 2 more things that could explain the difference:

(1) In v0.83 and newer I've removed some of the tweak settings that v0.82.5 still had. When you switch back to v0.82.5 do you have any of these tweak settings enabled? I'm talking about the bottom most 3 options in the exclusive mode settings page. And about the D3D11 presentation option. Do you have any of them activated in v0.82.5? If so, try deactivating them one by one to find out which of them you need.

(2) In v0.82.5 the "delay playback start until render queue is full" option applied to seeks, too. In v0.83 and newer it does not. Instead there's a new sub option "delay playback start after seeking, too". Did you have "delay playback start until render queue is full" activated in v0.82.5? If so, try activating "delay playback start after seeking, too" in v0.84.2. Does that fix the problem?

A few notes.
I have 4 systems

2 HTPC clients running AMD 6570/2GB DDR3 graphics, one using Windows 7 64 bit the other Windows 8 64 bit RTM
1 system running AMD 4890/1GB DDR5 “legacy” graphics, Windows 7 64bit
1 system running NVidia 560Ti/2GB DDR5, Windows 8 RTM


0.84.2 madVRblackjack test build

Initial test on systems listed in 1 with Windows 7 OR 8 RTM – all MKV container material for playback
(NOTE: This is not a Windows 8 issue. It is seen in identical systems, one running Windows 7 and one running windows 8)

MPC-HC 1.6.4.6052 or MPC-BE 1.0.3.1
Catalyst Driver ver 12.8
LAV Filters 51.3-118
madVR – all delay playback checked, GPU flush settings default

Windowed Mode or FSE:
With any interlaced content madVR causes an error and does not load at all, you can hear sound but see no video. All other content plays without issue – non-interlaced h264, VC1 and MPEG2 and there is no jumping around issues causing dropped frames and what appears to be rendering or buffering freezes.

The madVR crash report for the Windows 7 system is here:
http://sdrv.ms/VRKJ2h

System 2 above does not have any issues when using 0.84.2 std. … Another note that system 2 never worked correctly with interlaced material and in other areas until the 0.83.x updates … ? Was anything changed in the linking and handling of interlaced content with the new versions of madVR?

System 3 has dropped frame issues with 0.84.2, will load with the test build but still has dropped frame issues when jumping around. This system uses the latest NVidia drivers and CUVID with LAV.

I probably have more and broader material than many if not all, over 2100 files stored on over 48TB server array. Over 99% MKV content prepped from original materials. It is the interlaced content that is now causing problems. With this latest test build, madVR actually causes an error message and will not even load with this kind of material with the AMD Radeon systems …

I test all the time with:
"Life" - VC1 interlaced content (1080i)
"Our National Parks, Americas Best Idea" - h264 interlaced content (1080i)

These are the first files I look at as they have always been a tough test in the past. If these work then go to a number of other demanding BD conversions such as Avatar, Baraka and many others. All material converted from original with makeMKV and then remuxed with the latest version of mkvmerge.

Hope this may help.

[TheLion]

Warning: Ginseng is a very lightly "tamed" tensor (standard orthogonal) Lanczos.
It does not have the "look and feel" of EWA Lanczos. But it's closer to it than standard Lanczos.
To get more sharpness out of EWA Lanczos without losing the organic feel, use the "knob" described in 2).

Thanks, I do understand that. What I meant was using "Ginseng" instead (or as another option) of tensor Lanczos in madVR (as you suggested in 1) Just because standard Lanczos can be a touch "harsh" at times.

Making "Jinc" a little sharper as you suggested in 2) is also probably a very good approach.

So in the end I guess I just completely agree with your suggestions ;-)

May I ask what is your preferred upsampling method for high quality content (pure luminance and chroma upsampling)? Thanks for your knowledgeable input!

[NicolasRobidoux]

The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x).Correction: It has to do with the fourth root of J_1, which is its third nonzero root, which is the third root of Jinc.

[madshi]

What I love about Jinc is the analogue feel, but with a good amount of sharpness. Works wonders with HD content and SD as long as it's not interlaced. What I found with DVDs is there was too much aliasing (line crawling) when using Jinc. Could that have to do with them needing to be upscaled more plus interlacing artifacts might get sharpened?
If it works well for you with progressive content then probably deinterlacing quality is simply not good enough.

I have 4 systems
The original problem you were reporting, on which of those 4 systems did it occur? On all 4?

Did the original problem only occur with interlaced content, btw, or also with progressive content?

Windowed Mode or FSE:
With any interlaced content madVR causes an error and does not load at all, you can hear sound but see no video. All other content plays without issue – non-interlaced h264, VC1 and MPEG2 and there is no jumping around issues causing dropped frames and what appears to be rendering or buffering freezes.
Not sure if I understand this correctly. So basically deinterlacing doesn't work, but progressive content plays perfectly. Did I get that right? Not sure why deinterlacing doesn't work. The test build was a quick hack of moving some v0.82.5 code back into the v0.84.2 source code. It's *really* difficult because there was a very big change between v0.82.5 and v0.83.0 in the source code. The change itself shouldn't do much, but it makes it hard for me to create versions that sit between v0.82.5 and v0.83.0.

System 2 above does not have any issues
Did System 2 have issues with the official v0.84?

Was anything changed in the linking and handling of interlaced content with the new versions of madVR?
Yes, there was a change in deinterlacing logic. Which is the code which I tried to revert in the best build I made for you.

I've not read the whole thread, but I have 3 suggestions:
1) If you find tensor Lanczos (the standard one), which is "orthogonal 2-pass" Sinc-windowed Sinc 3-lobe, too jaggy near diagonals (it's the checkerboard mode rearing its ugly head) as well as too halo-y, substitute Jinc windowing for Sinc windowing. It "softens" the rough edges of standard Lanczos just a little.
(Informal name of this filter: "Ginseng", for "Jinc-Sinc".)
Methods Recommended by Nicolas Robidoux: Recommended Upsampling Methods (Enlarging) (http://www.imagemagick.org/Usage/resize/#nicolas_upsampling)
Good to hear from you!

Yeah, I could try that, thanks for the suggestion. You do mean to keep it 2 pass, correct? One worry I have is that madVR already has sooo many scaling options right now. I'm a bit afraid of adding so many more. I don't want to frighten new users. So it's always a hard decision whether I should add a new scaling algorithm or not. But I'll give your Ginseng :D idea a try to see how it works.

2) If you find EWA Lanczos (Jinc-windowed Jinc 3-lobe) too soft, you can sharpen it doing something which does not work so well with tensor Lanczos: rescale the filter extent, which is a fairly trivial change once any of them is programmed. In particular, you get an EWA filter which is about as sharp as the above tensor Ginseng (which itself is about as sharp as standard Lanczos) by rescaling the EWA disc so that it has radius exactly 3. A side effect of this rescaling is that any scanline of the enlargement only needs 6 scanlines of the original as data, just like for tensor Lanczos. This method is often called "EWA Lanczos Radius 3". The rescaling factor is 3 over the radius of the "raw" Jinc 3-lobe disc, which is the third root of J_1(pi*x). Specifically, it is .9264075766146068. It's not as free of artifacts as the "full width" EWA Lanczos. But it sure is sharper.
In any case, I don't recommend using "full width" EWA Jinc-windowed Jinc 3-lobes. At least, "tighten it" a little. With a rescaling factor of .99, .98, .95 or ???. But don't use it at full width. Maybe start with 0.9891028367558475 (I'm afraid this value may not be exact down to last full decimal because the library I used to compute it is not as accurate as I wish when dealing with Bessel functions), which minimizes worst case "cross-talk" between the original scan lines. This is one of two variants of a method called EWA LanczosSharp. (Which is not much sharper than the plain EWA Lanczos.)
I'm currently using 0.9812505644269356 in madVR. Got that number from somewhere when researching how to implement this algorithm. I had tried other values, like 1.0 or 0.88, but I ended up going back to 0.9812505644269356 cause it looked like a good compromise between aliasing and sharpness to me. Much lower than 0.9812... and too much aliasing crept back in for my taste.

3) If you want to be a bit more adventurous, I suggest you sigmoidize. Given that I imagine that you have a luma or luminance channel at the ready, the idea is that you convert to a synthetic color space that pushes non-extreme pixel values toward the center of the gamut, do the upsampling using a linear or nonlinear filter on these values, and then undo the compression. What this does is that it minimizes the extreme halos that arise from mid-tones. Or you could do it with all three channels. If you use (which I'm sure you don't) sRGB as input and output colorspaces, you can fake this by computing the color negative, converting applying the transformation from linear RGB to sRGB (as if they are not already), resampling, and then applying the transformation from sRGB to linear RGB, and finally taking the color negative.
I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it. I've added my own anti-ringing filter to the algorithm, though, which is quite effective. If you want to check for yourself:

parking original image (http://madshi.net/parking-org.png) -|- 400% with jinc (4 taps) (http://madshi.net/parking-jinc4.png) -|- 400% with jinc (4 taps) with anti-ringing filter (http://madshi.net/parking-jinc4ar.png)

If you've fun you can try yourself if sigmoidization can compete with my anti-ringing filter? :D

[Warlock]

Guys, what is the ideal setting for a GF 8600GT 512 DDR3? I am currently using the default madvr. What are the best filters for it: Jinc, Spline or Lanczos? 3, 4, or 8 taps?

[cyberbeing]

I have severe issues with DPC spikes using madVR together with my AMD/ATI 5870 board.
I have found a config which avoids the DPC spikes and brings the latency down to the level with EVR.

CPU/GPU queue size: 12/6
Frames in advance: 3
Flush, Don't Flush, Don't Flush, Flush&Wait (sleep)

does the trick.

Interesting, I was wondering why my ATI 5750 system was always showing extremely high DPC latency with madVR, while my NVIDIA systems never has such issues.

From my own testing, it looks like my ATI 5750 freaks out with constant +600µs high DPC latency if the GPU Queue is set to 8+, or if the the FSE present frames in advanced is set to 8+. The other settings you list seem to have no effect, but setting both GPU Queue and Present Frames in Advance to 6 resolves the high DPC problem I had with madVR on that system. I don't see any difference with the special build madshi created.

[JustinChase]

Guys, what is the ideal setting for a GF 8600GT 512 DDR3? I am currently using the default madvr. What are the best filters for it: Jinc, Spline or Lanczos? 3, 4, or 8 taps?

Unfortunately, that's like asking "which coffee is the best?"

Try searching this thread for "upscaling comparison", and you can get some personal opinions, but there is no "best" setting. Sorry :(

[Ver Greeneyes]

I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it.
Speaking of sRGB, have you ever considered doing the scaling in a perceptually uniform color space like CAM02-UCS J'a'b'? If you're interested I could probably supply (given a little time) a shader that implements the forward and inverse transforms.

[rahzel]

Hi madshi,

Question, earlier in this thread, you suggested to certain AMD/ATI owners to use 16-235 in madVR with AMD Vision set to RGB Full. Would you still recommend this config, even if your display has an option for 0-255 and 16-235? It seems to me that it would be better to avoid any unnecessary conversions and to output 0-255 (assuming your display supports it). Is the reason you recommended 16-235 because most TVs are setup this way, or is there another reason?

[madshi]

Speaking of sRGB, have you ever considered doing the scaling in a perceptually uniform color space like CAM02-UCS J'a'b'? If you're interested I could probably supply (given a little time) a shader that implements the forward and inverse transforms.
I have some doubts whether it would improve image quality. But if you think it could help, I'd like to try, if you can provide the shader code for the conversions.

Question, earlier in this thread, you suggested to certain AMD/ATI owners to use 16-235 in madVR with AMD Vision set to RGB Full. Would you still recommend this config, even if your display has an option for 0-255 and 16-235? It seems to me that it would be better to avoid any unnecessary conversions and to output 0-255 (assuming your display supports it). Is the reason you recommended 16-235 because most TVs are setup this way, or is there another reason?
Actually I usually recommend to set everything to 0-255 (which is also what I'm using myself). But some displays don't support that.

[NicolasRobidoux]

Good to hear from you!Nice to see you're making great strides.
You do mean to keep it 2 pass, correct?Yes: Same everything, just swap the windowing function (sin(pi*x/3)/x -> Jinc(root*x/3)), where root is the first crossing of the Jinc function you use. When you plot your window function, it should look an awful lot like the first lobe of the Sinc function. which itself looks an awful lot like the first lobe of the Cosine function.
----
I understand the "frighten new users" business. Suggestions: Just keep "fancy options" hidden unless some sort of "Expert options" toggle is turned "on". Otherwise, the menus only contain reasonable defaults. Hide "expert options" late in the documentation (in an Appendix?).

I'm currently using 0.9812505644269356 in madVR. Got that number from somewhere when researching how to implement this algorithm. I had tried other values, like 1.0 or 0.88, but I ended up going back to 0.9812505644269356 cause it looked like a good compromise between aliasing and sharpness to me. Much lower than 0.9812... and too much aliasing crept back in for my taste.It's the usual tug-o'-war between aliasing and sharpness.

Let me explain, in simple termps, the value you currently use (which also is the built-in value in ImageMagick) VS the one I currently recommend, mostly based on mathematical principles, not "it's clear this one is better" (there is little visual difference between them).

0.9812... is defined by the following property: When you have a single scanline of colour A (I assume all colour channels sit at the same pixel locations) on a background of colour B and you enlarge in such a way that there is an output scanline either at the original scanline location just above the lone scanline or just below (or both), then the colour of this scanline in the output is B. (Of course the same applies to a single pixel wide vertical line of colour A...)

0.9891... is defined by the following property. If your input image is A up to a certain scanline and B below that, and you enlarge in such a way that there is an output scanline at the last A scanline in the input image, then the colour of this output scanline is A. And conversely: If there is an output scanline at the first input B scanline, it is also colour B in the output. (Of course the same applies to an image which is colour A left of some vertical boundary, and B thereafter.) It turns out that 0.9891... has some additional mathematical properties which are why I now prefer it.

Correction: The above "simple" characterizations only work "exactly" if you keep the same resolution in the "other direction".

This being said, these values were computed with a slightly innaccurate library for the Bessel functions, so they may be very slightly off. But they're already close to each other, and both of them are very close to 1.

I did try your "RGB -> sRGB + negative + ..." trick, but the results didn't convince me to use it. I've added my own anti-ringing filter to the algorithm, though, which is quite effective. If you want to check for yourself:

parking original image (http://madshi.net/parking-org.png) -|- 400% with jinc (4 taps) (http://madshi.net/parking-jinc4.png) -|- 400% with jinc (4 taps) with anti-ringing filter (http://madshi.net/parking-jinc4ar.png)

If you've fun you can try yourself if sigmoidization can compete with my anti-ringing filter? :DI certainly will. Sigmoidization is kind of a hack. (Although, IMHO, it works amazingly well: Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal...? (http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21804&sid=e7d6d08d872edc5d33d1da6d5a4fc1a7#p89704).)
This being said, my terse description assumed that your input was in a perceptual color space which is very roughtly described by a cube, like sRGB.
If you start and end at sRGB, the detail goes like this (but note that this is a hack meant to avoid programming reversible sigmoidal-contrast transformations, which is not hard to do, is fairly cheap, but is not universally implemented):
sRGB -> negate -> pretend it's linear RGB with sRGB primaries -> sRGB -> upsample -> linear RGB with sRGB primaries -> pretend it's sRGB -> RGB -> negate -> sRGB.
The negations can be moved inward by one or two operations.
Again, this is an approximating hack. But an easy to try approximating hack.

[Ver Greeneyes]

I have some doubts whether it would improve image quality. But if you think it could help, I'd like to try, if you can provide the shader code for the conversions.
Cool, I'd be interested to find out myself :) I have about 90% of a C++ implementation done, so I'll get to work on finishing that and converting it to HLSL code.

[NicolasRobidoux]

A few quick comments so everybody knows where I'm coming from and where I may be going:
1) I know little about video processing. I'm a still image guy (ImageMagick/GEGL/VIPS/NIP2/GIMP plugin).
2) So far, everything I've stated relates to 3-lobe methods. I generally do not like 4-lobe methods. Although I remember liking a tweaked version of EWA Lanczos with 5 lobes at some point, and I suppose I could look again.
3) It is on my to-do list to provide high accuracy low flop approximations of the key Jinc functions (Sinc too. There is an outdated version called SincFast in ImageMagick). I know how. It's a matter of customizing the Boost C++ Minimax package, running it, and validating the results. I unfortunately have to balance labour of love with paid consultant work.
4) I don't know if you guys are halo haters. If so, another interesting method, besides Ginseng and EWA LanczosSharp and variants, is EWA quadratic B-spline windowed Jinc 3-lobe. It basically has no second halo, and it's decently sharp given that it is really good at moire suppression.
5) I do not recommend the same methods for upsampling, resampling (barely changing the sampling rate) and downsampling.
EWA LanczosSharp and tensor Ginseng and then EWA quadratic B-spline-windowed Jinc are at the top of my list for upsampling.
EWA LanczosSharp, EWA quadratic B-spline-windowed Jinc and then the very sharp (sharper than tensor Lanczos) tensor Cosine-windowed Sinc are at the top of my list for downsampling. The last method is recommended based on that digital photographers value sharpness a lot. I actually prefer tensor Ginseng.
All of them are 3-lobe methods.
6) The version of Methods Recommended by Nicolas Robidoux (http://www.imagemagick.org/Usage/filter/nicolas) which currently is on the server is outdated. I don't have direct access to the server, and this is a work in progress.

[agustin9]

Sadly I don't have another card at my disposal. The latency peaks generally get worse when increasing GPU queue sizes. But it is not so easy because there are interactions with the other parameters (CPU queue, frames in advance, GPU flushing).

I am wondering if it would be a viable idea to include default profiles depending on the graphic card (nVidia/AMD/Intel, perhaps per generation) in madVR based on user feedback?!

Please try the catalyst 10.6 drivers, they worked fine for me. I have a 4850.

[NicolasRobidoux]

Mathias:
RE: what de-blur to use.
Although I have no mathematical basis for this recommendation, it appears to me that a value somewhere between .95 and .97 is probably the sweet spot, at least with EWA Lanczos 3. But I have not tried these values enough to be sure. And at this point, this would have to be based on the "eyeball metric".

[NicolasRobidoux]

Mathias:
Your overshoot suppression method appears to work impressively well.
-----
You are aware that such limiters are probably not desirable, or not as desirable, when downsampling, yes?