View Full Version : madVR - high quality video renderer (GPU assisted)
Moony349
8th October 2012, 22:14
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.
Agree with Madshi... but I might be mistaken as to why. Could anyone clarify?
I was under the impression that there is always a conversion from 16-235 to 0-255 at some point along the chain when you're using a PC because video cards don't like 16-235.
If you set MadVR to 16-235 you're getting 1 video card up-conversion, 1 video card down conversion:
16-235 source
MadVR converts to RGB; upsamples chroma in 16-235 colorspace (No BTB/WTW color information at all)
After MadVR, video card converts 16-235 to 0-255, does its thing
Video card converts back down to 16-235 and outputs 16-235
You're better off doing the following (1 MadVR up-conversion, 1 video card down-conversion):
16-235 source
MadVR converts to RGB, upsamples chroma in 0-255 colorspace
Video card converts back down to 16-235 and outputs 16-235 (Lose BTB/WTW color information here, which is later)
Best case is only 1 MadVR up-conversion:
16-235 source
MadVR converts to RGB, upsamples chroma 0-255 colorspace
Video card outputs 0-255 (Keep BTB/WTW)
turbojet
8th October 2012, 22:23
Oh well, I remember. The point is: I'm afraid of making the settings dialog too complex. It's already frightening to new users as it is right now. Maybe some time in the future...
Thanks for considering. Speaking for myself, playing with resizers are the fun part, not the complicated part. The complicated part being the tweaks and queues needed to get it to work on various video cards. With the latest nvidia drivers out now the only default thing I need to change to work as expected is the queues to 4/4, rest being optional. Maybe a simple setting that hides all the tweaks and things that don't need to be touched by most with defaults could simplify the gui.
Bicubic's negative blur makes things 'pop' like the the aforementioned darbee darblet (http://darbeevision.com/gallery) for free. Leaving default at 0 would behave as current bicubic and users may find something they really like by adjusting blur, like me. Negative blur is becoming a common suggestion to gain sharpness without affecting speed in avisynth.
Look for "EWA Lanczos" in ImageMagick, that's pretty much the same as Jinc. ImageMagick is open source. So it shouldn't be too hard to make it work in AviSynth for someone with AviSynth development experience. ImageMagick doesn't have an anti-ringing filter, though, that's purely my own invention. I've explained that in my "non-ringing Lanczos" thread in the doom9 AviSynth area, though. None of the AviSynth devs seemed to be very interested at the time, though (I had started that thread a loooong time ago, years (?) before I actually finally implemented the anti-ringing filter in madVR).
It's a very interesting thread, would be nice to be able to test everything in it on videos, only thing I could find is an image reader based on an old imagemagick version. Like you said avisynth plugin devs haven't given it attention but it doesn't seem like many new or updated plugins in the past few years, mainly scripts to run plugins. Perhaps vapoursynth will pique their interest.
NicolasRobidoux
8th October 2012, 22:28
Mathias:
Given how well your "overshoot limiter" seems to work, I understand better your use of many lobes.
Thunderbolt8
8th October 2012, 22:47
regarding the seeking bar, would it be possible to add additional time information when seeking, the time within a movie the mouse is moving the seeking bar? would be way easier to find specific scenes or spots.
guess you could do it either when the mouse is dragging the seeking bar or also when hovering over different places of the seeking with the mouse.
NicolasRobidoux
9th October 2012, 00:31
Note: I have never liked Jinc 4 (EWA Lanczos 4-lobe in ImageMagick speak) for natural images. Even with the deblur optimized, it is a very unusual scheme, very different in character from Jinc 3.
I may have to triple check on this, but my opinion right now is that if you are going to go higher than Jinc 3 lobes, skip 4 and go up to 5.
Also: The "best" deblurs for Jinc depend on the number of lobes.
I'll try to be more specific in a future post.
Xaurus
9th October 2012, 00:53
Best case is only 1 MadVR up-conversion:
16-235 source
MadVR converts to RGB, upsamples chroma 0-255 colorspace
Video card outputs 0-255 (Keep BTB/WTW)
This is interesting. I was under the impression that it was best to set LAV to NV12. Or am I not following here?
I have it configured like you say (I think), 0-255 hdmi, 0-255 in madvr and 0-255 in TV.
blackjack12
9th October 2012, 01:25
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.
The original problem you were reporting, on which of those 4 systems did it occur? On all 4?
On all systems except system 2. System 2 actually worked correctly with all content for the first time after testing with 0.83.x builds and has ever since. So whatever deinterlacing logic you changed at that point “fixed” this legacy 4000 series Radeon system but has caused problems with much newer 6000 series systems
Did the original problem only occur with interlaced content, btw, or also with progressive content?
Originally, I saw it with any content, just jump around with any file that I tested and it would eventually freeze the que/s and start dropping frames.
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.
With interlaced content, the test build madVR actually crashes and generates the crash reports that I gave a link to. It crashes and you get a black screen, no video at all and only sound with the AMD 6570 systems. With the NVidia system just massive frame drops.
With all other progressive content that I tested I did not see any problems, except that on a “qualitative” basis things seemed to take a little longer to load up and start.
Did System 2 have issues with the official v0.84?
No … As noted above, system 2 worked well with all 0.83-0.84 builds that I tested. But it actually did not work correctly with interlaced content with 0.82.5 … It actually worked correctly with the first version of 0.83.x that I tested and has ever since …
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.
Again … thanks for the great work and hope this helps.
andyvt
9th October 2012, 01:28
Is it possible to configure madVR to use different algorithms for different resolutions?
kerman
9th October 2012, 01:36
Does this work with MPC-HC x64?
jaagil
9th October 2012, 01:46
Looks like Jinc 3 taps with anti-ringing on image upscaling runs fine on GTX 285 & I5-750, I get few dropped frames and usually just one delayed frame when fullscreening. (Running windowed mode.)
Can someone explain me what is the difference in Chroma and Luma(Now "Image") (Up)scaling? (Or link to it, I have a feeling it's been asked more than twice already)
I have Chroma upscaling set as SoftCubic 100, without Anti-ringing, and it has no ringing so there would be no difference I guess?
When SoftCubic is set to 100 and you activate anti-ringing it makes SoftCubic go to 50 automatically. (For the first time, after you set it back to 100 you can activate it but I guess that's meant to show there's no point in doing so?)
Thanks.
andyvt
9th October 2012, 02:04
Does this work with MPC-HC x64?
No. madVR is 32-bit only.
Moony349
9th October 2012, 02:18
This is interesting. I was under the impression that it was best to set LAV to NV12. Or am I not following here?
I have it configured like you say (I think), 0-255 hdmi, 0-255 in madvr and 0-255 in TV.
For LAV I check off all of the output formats and leave RBG output levels as untouched.
To check your colorspace, what I've found works best is downloading the mp4 version of these test videos:
http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration
Use the APL clipping (Basic Settings #2) to make sure your colors are correct. Nvidia cards notoriously will output 16-235 over HDMI unless you hack the monitor INF or use Madshi's madnvlevelstweaker (I haven't tested it but I assume it works).
You want to be able to see blinking in the white area up to at least 234 (And black down to 17 or so ideally). If the whole screen is blinking your card is probably converting down to 16-235 and you should try using madshi's tweak.
NicolasRobidoux
9th October 2012, 02:56
Mathias:
IMHO, instead of adding more lobes to Jinc (3 is enough), I'd add quadratic B-spline-windowed Jinc 3-lobe with no deblur ("blur=1") or with the same deblur you use with Jinc if it's easier.
Examples: sigmoidized EWA quadratic B-spline windowed Jinc 3-lobe (http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=21933).
(I do realize you have many many many other things to do.)
rahzel
9th October 2012, 04:41
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.
Thanks, thought so.
sunnah
9th October 2012, 05:54
Chroma upscaling: Jinc 8 taps
Image upscaling: Jinc 8 taps
Image downscaling: Lanczos 8 taps
(I have the anti-ringing option enabled on everyone of them.
All work great on the NVIDIA GTX 570M without dropped/delayed frames. The image and colours of 1080p, 720p and below are magnificent. And the display modes option also works really well for me.
Keep up the good work Madshi.
edragon
9th October 2012, 06:08
sunnah:
Chroma upscaling: Jinc 8 taps
Image upscaling: Jinc 8 taps
Image downscaling: Lanczos 8 taps
(I have the anti-ringing option enabled on everyone of them.
All work great on the NVIDIA GTX 570M without dropped/delayed frames. The image and colours of 1080p, 720p and below are magnificent. And the display modes option also works really well for me.
Keep up the good work Madshi.[/COLOR][/COLOR]
do you play 60fps video?
sunnah
9th October 2012, 06:15
sunnah:
do you play 60fps video?
Most of the time I run 30fps (Korean/Japanese tv shows) and 24fps videos. (the display ofcourse changes with the framerate, but 60fps videos also worked well without problems.)
edragon
9th October 2012, 06:23
Most of the time I run 30fps (Korean/Japanese tv shows) and 24fps videos. (the display ofcourse changes with the framerate, but 60fps videos also worked well without problems.)
even with 720p 60fps?
my gtx550ti can only run jinc3 without antiring when play 720p 60fps!
sunnah
9th October 2012, 06:36
even with 720p 60fps?
my gtx550ti can only run jinc3 without antiring when play 720p 60fps!
Then I'm lucky I guess lol, I really took the laptop just for these high-end purposes.
What is the combination that you use if I may ask? MadVR + LAV, including CUVID?
edragon
9th October 2012, 06:45
Then I'm lucky I guess lol, I really took the laptop just for these high-end purposes.
What is the combination that you use if I may ask? MadVR + LAV, including CUVID?
I use mpc+madvr+ffdshow video audio+haali +SVP+reclock
but i do not use LAV
video use soft decoding
maybe gtx570 is much greater than gtx550ti.....
sunnah
9th October 2012, 06:48
I use mpc+madvr+ffdshow video audio+haali +SVP+reclock
but i do not use LAV
video use soft decoding
maybe gtx570 is much greater than gtx550ti.....
Of course the difference between the cards is truly big.
Well hardware decoding with CUVID could really help to decrease your processor intensity and it will put it into your graphic card. It's more efficient that way.
There are many tutorials, I think you should give it a try with your favourable MadVR settings.
madshi
9th October 2012, 08:19
If you set MadVR to 16-235 you're getting 1 video card up-conversion, 1 video card down conversion:
16-235 source
MadVR converts to RGB; upsamples chroma in 16-235 colorspace (No BTB/WTW color information at all)
After MadVR, video card converts 16-235 to 0-255, does its thing
Video card converts back down to 16-235 and outputs 16-235
If you set the video card to 0-255 then it does not do any conversion on its own. (At least it should not.) That's why I recommend to set the video card to 0-255. The only conversion should be done by madVR because it does it in high bitdepth with dithering. So set the video card to 0-255 and then switch between 16-235/0-255 in madVR, depending on whether your display supports 0-255 or not.
Thanks for considering. Speaking for myself, playing with resizers are the fun part, not the complicated part. The complicated part being the tweaks and queues needed to get it to work on various video cards. With the latest nvidia drivers out now the only default thing I need to change to work as expected is the queues to 4/4, rest being optional. Maybe a simple setting that hides all the tweaks and things that don't need to be touched by most with defaults could simplify the gui.
Bicubic's negative blur makes things 'pop' like the the aforementioned darbee darblet (http://darbeevision.com/gallery) for free. Leaving default at 0 would behave as current bicubic and users may find something they really like by adjusting blur, like me. Negative blur is becoming a common suggestion to gain sharpness without affecting speed in avisynth.
Well, I would much rather implement a *real* sharpening algorithm, to be honest. That's why I'm also reluctant offering so many more tweaks: It costs many hours of my time which I could instead spend on doing the "real thing". Personally, I don't like Darbee pop at all. I much prefer something like Didee's FineSharp. So if you ask me to add this and that, and a couple of other tweaks in between, basically you're keeping me busy with so-so stuff, instead of allowing me to move on to bigger and greater things. I've said it so many times before: Let me first add all the missing features, before spending my time by twiddling with 1% improvements. I'm feeling held back at the moment, by all the constant requests for small tweaks and changes everywhere. Aren't you guys interested in getting things like custom shader support, 3D support etc?
It's a very interesting thread, would be nice to be able to test everything in it on videos, only thing I could find is an image reader based on an old imagemagick version. Like you said avisynth plugin devs haven't given it attention but it doesn't seem like many new or updated plugins in the past few years, mainly scripts to run plugins. Perhaps vapoursynth will pique their interest.
Interesting, never heard of vapoursynth yet.
regarding the seeking bar, would it be possible to add additional time information when seeking, the time within a movie the mouse is moving the seeking bar? would be way easier to find specific scenes or spots.
guess you could do it either when the mouse is dragging the seeking bar or also when hovering over different places of the seeking with the mouse.
Sure it's possible, but time consuming. So no, for now.
Is it possible to configure madVR to use different algorithms for different resolutions?
Not at the moment. Planned for a future version.
The original problem you were reporting, on which of those 4 systems did it occur? On all 4?
On all systems except system 2. System 2 actually worked correctly with all content for the first time after testing with 0.83.x builds and has ever since. So whatever deinterlacing logic you changed at that point “fixed” this legacy 4000 series Radeon system but has caused problems with much newer 6000 series systems
But when using the official v0.84.2 build, the problems with 6000 series are not specific to deinterlacing, correct? They also occur with progressive content, correct? Could you please double check, just to be safe? It's important to know.
Did the original problem only occur with interlaced content, btw, or also with progressive content?
Originally, I saw it with any content, just jump around with any file that I tested and it would eventually freeze the que/s and start dropping frames.
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.
With interlaced content, the test build madVR actually crashes and generates the crash reports that I gave a link to. It crashes and you get a black screen, no video at all and only sound with the AMD 6570 systems. With the NVidia system just massive frame drops.
With all other progressive content that I tested I did not see any problems, except that on a “qualitative” basis things seemed to take a little longer to load up and start.
So the special test build I created for you makes everything progressive work just fine, and the only problems left are when using deinterlacing? Is that correct? How about the official v0.84.2 then? Could you please double check if maybe the official v0.84.2 also plays progressive content fine? I'm asking because the only difference between the official v0.84.2 and your special test build is deinterlacing. So for progressive content v0.84.2 and your test build should behave identical.
I'm sorry that fixing this problem takes so long. If only I could reproduce it on my PC !!!
Can someone explain me what is the difference in Chroma and Luma(Now "Image") (Up)scaling? (Or link to it, I have a feeling it's been asked more than twice already)
Digital video is normally stored as 4:2:0, which means that brightness information is stored in full resolution, and color information is stored with half width and half height. So madVR in the first step has to upscale color information to the same resolution as brightness information, before converting both into RGB. The color information upscaling is named "Chroma upscaling". Then scaling the final RGB frames to whatever target resolution you need is "image upscaling".
When SoftCubic is set to 100 and you activate anti-ringing it makes SoftCubic go to 50 automatically.
I can't seem to be able to reproduce this problem. Can you write an exact step-by-step description on how to reproduce this bug?
Chroma upscaling: Jinc 8 taps
Image upscaling: Jinc 8 taps
Image downscaling: Lanczos 8 taps
(I have the anti-ringing option enabled on everyone of them.
All work great on the NVIDIA GTX 570M without dropped/delayed frames.
Cool! That said, please double check whether image quality is really better than Jinc 3 or 4 taps. More taps isn't always better. Yes, it's ever so slightly sharper, but there may be more ringing artifacts left. Anyway, your choice, of course.
madshi
9th October 2012, 08:20
@Nicolas, thanks for your continued input, I appreciate it!
3) It is on my to-do list to provide high accuracy low flop approximations of the key Jinc functions
I'm looking forward to that. However, I'm now using a very small Jinc LUT for my pixel shaders, using linear LUT interpolation, and it works surprisingly well. For your interest: I started with a LUT with 8 * 1024 values. Then I lowered the LUT size and compared images. I was surprised how small the LUT could be without getting any visible differences. I went down as far as 32 values only and still couldn't see any difference with bare eyes, although in a hex editor I could see some colors changed by a value of 1 (in 8bit). I'm now using a LUT size of 64 values. GPUs seem to handle that really well (due to texture caching), so it will be interesting to see whether your low flop math will be any faster.
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".
Thanks. I'll play around with the blur values once more.
Your overshoot suppression method appears to work impressively well.
Thanks, I'm glad you like it.
You are aware that such limiters are probably not desirable, or not as desirable, when downsampling, yes?
Actually, no. From what I can see, my anti-ringing filter seems to work just as fine for downsampling as it does for upsampling. If you're interested to see how it looks, just send a link to an image you want to see downsampled and I can show you how it looks with my downsampling anti-ringing filter. I don't support Jinc downsampling yet, though, so I'd have to downsample with Lanczos.
Given how well your "overshoot limiter" seems to work, I understand better your use of many lobes.
Yeah. I personally do not really recommend 8-taps, though. I usually recommend either 3 or 4 taps.
Note: I have never liked Jinc 4 (EWA Lanczos 4-lobe in ImageMagick speak) for natural images. Even with the deblur optimized, it is a very unusual scheme, very different in character from Jinc 3.
I may have to triple check on this, but my opinion right now is that if you are going to go higher than Jinc 3 lobes, skip 4 and go up to 5.
That's interesting! FWIW, when comparing Jinc 3 vs 4 taps I can't see much of a difference when using my anti-ringing filter. 4 taps is ever so slightly sharper, that's all the difference I can see. I can't really see a different character. Not sure whether that's because of the anti-ringing filter? Anyway, here's a comparison between 3, 4 and 8 taps, all with anti-ringing filter:
parking - jinc 3 taps (http://madshi.net/parking2-jinc3.png) -|- parking - jinc 4 taps (http://madshi.net/parking2-jinc4.png) -|- parking - jinc 8 taps (http://madshi.net/parking2-jinc8.png)
There's not really a different look, is there? I only see small changes in sharpness and ringing.
Also: The "best" deblurs for Jinc depend on the number of lobes.
I'll try to be more specific in a future post.
Interesting. I'm now using the same value for all Jinc taps. I guess for more taps, a lower deblur value can be used (resulting in even sharper images)?
IMHO, instead of adding more lobes to Jinc (3 is enough), I'd add quadratic B-spline-windowed Jinc 3-lobe with no deblur ("blur=1") or with the same deblur you use with Jinc if it's easier.
But why? It seems the only advantage of the quadratic B-spline window is less haloing, and that is of no use to me because my anti-ringing filter takes care of the halos, anyway. Or does quadratic B-spline windowing have any other advantages that I'm not aware of right now?
sunnah
9th October 2012, 08:20
Cool! That said, please double check whether image quality is really better than Jinc 3 or 4 taps. More taps isn't always better. Yes, it's ever so slightly sharper, but there may be more ringing artifacts left. Anyway, your choice, of course.
Thanks I'll try what you said. :)
sunnah
9th October 2012, 08:24
Thanks I'll try what you said. :)
Madshi, what are your Chroma upscaling, image upscaling and image downscaling preferred settings, i'm just curious.
I tried the the change from linc 8 taps to 3, I saw the positive difference between the ringing so thanks for that tip. :)
toniash
9th October 2012, 08:31
Aren't you guys interested in getting things like custom shader support, 3D support etc?
Of course we are VERY interested!
madshi
9th October 2012, 10:21
Madshi, what are your Chroma upscaling, image upscaling and image downscaling preferred settings, i'm just curious.
I guess I'll end up using Jinc 3 or 4 (not sure yet) for Luma and Chroma upsampling and Lanczos 4 for Luma downscaling. All with anti-ringing enabled, of course. But it's a matter of taste.
madshi
9th October 2012, 10:25
@NicolasRobidoux,
I've tried your suggestions:
(1) Ginseng looks exactly the same as standard Lanczos to me, at least when upscaling that parking lot image 400%. At first I thought I made a mistake because I saw no difference, but I double and triple checked. I can't really see any difference between standard Lanczos and Ginseng! :confused:
(2) I could see using a blur factor a bit lower than I'm using right now, but I'm not sure which exact factor I should be using. The difference is subtle, anyway. As you say, something around 0.96 might be a good compromise. Is there any theoretical disadvantage to using a "simple" number like "0.96000000"? I've also checked with 4 taps and 8 taps and from what I can see, similar blurring factors make sense there, too. I didn't feel the need to use a different blurring factor for 8 taps compared to 3 taps.
(3) I've retried your invert + sRGB -> RGB conversion trick, and I guess I made a mistake when originally testing this because the results I get now are better than when I originally tested this. Here's how it looks now with the parking lot image:
jinc 3-tap normal (http://madshi.net/parking3-jinc3.png) -|- jinc 3-tap "hacked" (http://madshi.net/parking3-jinc3hacked.png)
Does that look as expected to you? Any comments anyone on which image you prefer? I guess the "hacked" image does look a bit better? At least it looks different.
@Nicolas, is the full Sigmoidal stuff better compared to the simple invert + sRGB -> RGB hack? If so, is the Sigmoidal math explained anywhere? Maybe a web article? Or a science paper or something?
ryrynz
9th October 2012, 11:04
I guess the "hacked" image does look a bit better? At least it looks different.
I'm preferring the hacked image also.
aufkrawall
9th October 2012, 11:06
Sorry if this has already been discussed, madshi.
Are you aware of the problem that when using Win XP qdvd.dll for DVDs on Windows 7, the whole window of MPC HC gets unresponsive after seeking (nothing can't be clicked anymore)?
It doesn't happen with EVR CP, seeking multiple times seems to work just fine with it.
So, it might be a madVR issue?
Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7. :)
namaiki
9th October 2012, 11:10
Sorry if this has already been discussed, madshi.
Are you aware of the problem that when using Win XP qdvd.dll for DVDs on Windows 7, the whole window of MPC HC gets unresponsive after seeking (nothing can't be clicked anymore)?
It doesn't happen with EVR CP, seeking multiple times seems to work just fine with it.
So, it might be a madVR issue?
Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7. :)
Not sure about this, but I think it was possible to play DVDs without hacks if you didn't use ffdshow. If you aren't using ffdshow at the moment, then I guess not.
patul
9th October 2012, 11:15
@NicolasRobidoux,
Any comments anyone on which image you prefer? I guess the "hacked" image does look a bit better? At least it looks different.
"hacked" image does look better to my untrained eyes. The perception of being 'clearer' is given by that image, specifically if I look to that "No parking at" and the green logo as well as the "Camden" areas.
AndreaMG
9th October 2012, 11:30
Aren't you guys interested in getting things like custom shader support, 3D support etc?
Me VERY VERY interested!:D
AndreaMG
9th October 2012, 11:40
I use mpc+madvr+ffdshow video audio+haali +SVP+reclock
but i do not use LAV
video use soft decoding
maybe gtx570 is much greater than gtx550ti.....
Try without SVP, which eats a lot of CPU, but also GPU if enabled to do so. I have a 460GTXM overclocked and with both chroma and luma upscale Jinc 3 taps and SVP I have drop frames...
AndreaMG
9th October 2012, 11:47
Would be great if you would fix this since it seems to be the only reliable method to get DVDs working with madVR on Windows 7. :)
I play dvds under MadVR without the "qdvd.dll" trick simply by adding in MPCHC external filters Cyberlink video decoder and Microsoft dvd navigator.
Budtz
9th October 2012, 12:07
Well, I would much rather implement a *real* sharpening algorithm, to be honest. That's why I'm also reluctant offering so many more tweaks: It costs many hours of my time which I could instead spend on doing the "real thing". Personally, I don't like Darbee pop at all. I much prefer something like Didee's FineSharp. So if you ask me to add this and that, and a couple of other tweaks in between, basically you're keeping me busy with so-so stuff, instead of allowing me to move on to bigger and greater things. I've said it so many times before: Let me first add all the missing features, before spending my time by twiddling with 1% improvements. I'm feeling held back at the moment, by all the constant requests for small tweaks and changes everywhere. Aren't you guys interested in getting things like custom shader support, 3D support etc?
Yes i'd very much like a proper sharpener. The avysynth-ones are not very userfriendly plus it would be a better place in the chain to have it in madvr. I could also get rid of ffdshow and only use madvr and lav filters.
AndreaMG
9th October 2012, 12:45
Yes i'd very much like a proper sharpener. The avysynth-ones are not very userfriendly plus it would be a better place in the chain to have it in madvr. I could also get rid of ffdshow and only use madvr and lav filters.
And most of all it would be awesome to able to sharpen AFTER resizing, which is impossible via avisynth in conjunction with MadVR. In my opinion the integration (with pixel shaders?) of a sharpener in MadVR is priority N. 1:D
NicolasRobidoux
9th October 2012, 12:56
Mathias:
I'll try to address your questions without adding more noise and pointless things to program.
I see that you almost always try "the right things" and ask the right questions, so I can "chill" a little.
NicolasRobidoux
9th October 2012, 12:59
General warning:
Don't assume that increasing lobes and the like has quite the same effect when using Jinc ("EWA Lanczos") as it does when using Sinc ("tensor a.k.a. orthogonal a.k.a. 2-pass Lanczos").
EWA Jinc and tensor Sinc filtering are very different beasts. Some of the intuition you've built with Sinc carries over, but some does not. Actually, it mostly has to do with the difference between EWA and tensor methods.
Some tweaks that make EWA windowed-Jincs better make tensor windowed Sincs worse, and vice versa.
For example, in my book, there is generally little point going above 3 lobes with EWA. Less of a point than with tensor Lanczos. I'd actually say no point whatsoever when this is to be a default, unless possibly you want to reproduce the perceptual sharpness of tensor Lanczos and its relatives, which is most likely misguided UNLESS YOU ARE DOWNSAMPLING (because EWA is much better at moire reduction than tensor methods at roughly equivalent sharpness).
If you allow me to venture why, I'd say that it's because additional Sinc lobes compensate for the fact that you are using a tensor method, which does not dampen the checkerboard mode because it filters both directions separately. As as been noticed by some of the posters, EWA Jinc dampens the checkerboard mode more than a bit. It's built into the Jinc function, and the 2D frequency response plots make it obvious.
I realize that video upsampling (or downsampling) is a different context than cheap camera or scanned photographs or DSLR or line art resizing, but I'd be really surprised if what I've learned w.r.t. the latter does not carry over to the former. This being said, my back of the envelope hunches are often wrong, so don't take what I say too seriously.
TheLion
9th October 2012, 13:14
I'm preferring the hacked image also.
I also prefer the "hacked image" by an ever so small margin.
aufkrawall
9th October 2012, 13:16
I play dvds under MadVR without the "qdvd.dll" trick simply by adding in MPCHC external filters Cyberlink video decoder and Microsoft dvd navigator.
Could you please explain this a little more complete? :)
I installed PowerDVD but couldn't find the DVD decoder in the DS filter list.
TheLion
9th October 2012, 13:21
Well, I would much rather implement a *real* sharpening algorithm, to be honest. That's why I'm also reluctant offering so many more tweaks: It costs many hours of my time which I could instead spend on doing the "real thing". Personally, I don't like Darbee pop at all. I much prefer something like Didee's FineSharp. So if you ask me to add this and that, and a couple of other tweaks in between, basically you're keeping me busy with so-so stuff, instead of allowing me to move on to bigger and greater things. I've said it so many times before: Let me first add all the missing features, before spending my time by twiddling with 1% improvements. I'm feeling held back at the moment, by all the constant requests for small tweaks and changes everywhere. Aren't you guys interested in getting things like custom shader support, 3D support etc?
I am looking forward to features like a sophisticated "real" sharpening filter, custom shader support and 3D support so badly that I will refrain from making any more requests/proposals :) I am very confident that your choice of development priorities is best for all of us.
Blight
9th October 2012, 13:28
Madshi:
I would also welcome 3D support in the renderer, if there's anything I can do to help push it forward, let me know.
AndreaMG
9th October 2012, 13:33
@aufkrawall, in MPCHC disable all internal filters (both source and transform), enable audio switcher and in "external filters" add:
- LAV Splitter (it will not be triggered by dvds...)
- LAV Video decoder (same as previous, currently not supported, but NEV is working at dvd support now)
- Cyberlink video/SP Video decoder (mine is PDVD10, as far as I know it is sufficient you install a trial version then the decorer remains there fo you:)
- ffdshaw raw video filter (required by SVP, which for me is a MUST)
- LAV Audio decoder (supported by dvds)
- Microsoft dvd navigator
This set up allows me to play any video but dvds using LAV Video (because it is set at top in the merit list), and only for dvds automatically MPCHC switches to Cyberlink Video decoder: no more problems with freezings when seeking and displaying menus.
Hope it helps:)
NicolasRobidoux
9th October 2012, 13:58
FWIW, when comparing Jinc 3 vs 4 taps I can't see much of a difference when using my anti-ringing filter. 4 taps is ever so slightly sharper, that's all the difference I can see. I can't really see a different character.
I just checked, and I would guess that the anti-ringing reduces the differences. When I compared the two long long ago in a distant galaxy, the EWA Lanczos 4 halo made me puke. It's not only that the second halo is really obvious. The first halo is also deeper, esp. where straight, high contrast lines, meet.
Some examples are found here: http://web.cs.laurentian.ca/nrobidoux/misc/madVR/glyphs/
They show EWA LanczosSharp (3-lobes) and results obtained with 4 and 5 lobes. To keep things simple, I used the same deblur for all three enlargements, which each correspond to a different number of lobes (the same one as madVR, and the same one as the default EWA LanczosSharp in ImageMagick), and I enlarged sRGB pixel values directly (no colorspace shenanigans).
P.S. There may be something broken with my ImageMagick install. I may have to update the images later.
P.S.2 No: It's Firefox making things look strange.
P.S.3 Now I remember what made me go "these schemes look really different" (besides the haloing): I was using very strong deblurs, roughly 0.885, in the hope of gettting something as sharp as tensor Lanczos. When deblurring this much, the three schemes look really different. (Again, this is from memory.) So, my comments about them having a different character may have to do with pushing the EWA Lanczoses where, really, they should not go.
-----
The parking meter image is fairly soft. I vaguely remember someone mentioning that it was "obvious" that it had been obtained by downsampling with box filtering, and I remember looking carefully and agreeing.
When enlarging blurred images, decent windowed Sinc and Jinc methods will generally give roughly similar results.
Are video images typically that soft and similar to the results of downsampling by box filtering?
edragon
9th October 2012, 14:42
Try without SVP, which eats a lot of CPU, but also GPU if enabled to do so. I have a 460GTXM overclocked and with both chroma and luma upscale Jinc 3 taps and SVP I have drop frames...
But SVP is very important for me , i can not watch anime without it .... though it really eats a lot of CPU and GPU!
So now i just use jinc3 without antiR ... but still have good image when upscalng 480p to 1080p
aufkrawall
9th October 2012, 14:52
@aufkrawall, in MPCHC disable all internal filters (both source and transform), enable audio switcher and in "external filters" add:
- LAV Splitter (it will not be triggered by dvds...)
- LAV Video decoder (same as previous, currently not supported, but NEV is working at dvd support now)
- Cyberlink video/SP Video decoder (mine is PDVD10, as far as I know it is sufficient you install a trial version then the decorer remains there fo you:)
- ffdshaw raw video filter (required by SVP, which for me is a MUST)
- LAV Audio decoder (supported by dvds)
- Microsoft dvd navigator
This set up allows me to play any video but dvds using LAV Video (because it is set at top in the merit list), and only for dvds automatically MPCHC switches to Cyberlink Video decoder: no more problems with freezings when seeking and displaying menus.
Hope it helps:)
Thanks, but unfortunately it doesn't work for me.
With PDVD 10, now the filters appear in the list (with 12 they don't) but I still get Macrovision error.
NicolasRobidoux
9th October 2012, 14:57
I'm looking forward to that. However, I'm now using a very small Jinc LUT for my pixel shaders, using linear LUT interpolation, and it works surprisingly well. For your interest: I started with a LUT with 8 * 1024 values. Then I lowered the LUT size and compared images. I was surprised how small the LUT could be without getting any visible differences. I went down as far as 32 values only and still couldn't see any difference with bare eyes, although in a hex editor I could see some colors changed by a value of 1 (in 8bit). I'm now using a LUT size of 64 values. GPUs seem to handle that really well (due to texture caching), so it will be interesting to see whether your low flop math will be any faster.Suggestion: Base the LUT on EWA_disc_radius^2 - distance^2. This saves square roots, and makes the LUT denser where it should (near the center) at no cost.
P.S. My guess is that with this trick, and offsetting sampling locations just a bit so that the "outermost" one does not have a weight equal to 0, you may be able to get away with 32 with no worries whatsoever? 16 even?
Computing the fast approximations just went down the priority list.
Budtz
9th October 2012, 15:06
And most of all it would be awesome to able to sharpen AFTER resizing, which is impossible via avisynth in conjunction with MadVR. In my opinion the integration (with pixel shaders?) of a sharpener in MadVR is priority N. 1:D
for me as well. i second that
madshi
9th October 2012, 15:07
Madshi:
I would also welcome 3D support in the renderer, if there's anything I can do to help push it forward, let me know.
It's on my to do list, but there are some other things with higher priority. But it isn't too far away, I hope...
I just checked, and I would guess that the anti-ringing reduces the differences. When I compared the two long long ago in a distant galaxy, the EWA Lanczos 4 halo made me puke. It's not only that the second halo is really obvious. The first halo is also deeper, esp. where straight, high contrast lines, meet.
Some examples are found here: http://web.cs.laurentian.ca/nrobidoux/misc/madVR/glyphs/
They show EWA LanczosSharp (3-lobes) and results obtained with 4 and 5 lobes. To keep things simple, I used the same deblur for all three enlargements, which each correspond to a different number of lobes (the same one as madVR, and the same one as the default EWA LanczosSharp in ImageMagick), and I enlarged sRGB pixel values directly (no colorspace shenanigans).
P.S. There may be something broken with my ImageMagick install. I may have to update the images later.
P.S.2 No: It's Firefox making things look strange.
P.S.3 Now I remember what made me go "these schemes look really different" (besides the haloing): I was using very strong deblurs, roughly 0.885, in the hope of gettting something as sharp as tensor Lanczos. When deblurring this much, the three schemes look really different. (Again, this is from memory.) So, my comments about them having a different character may have to do with pushing the EWA Lanczoses where, really, they should not go.
Interesting. With that image, when using Jinc upscaling, my anti-ringing algorithm removes most of the halos, but it has ugly harsh edges. I'll have to see if I can fix that. FWIW, the anti-ringing filter doesn't look harsh at all with Lanczos. Wonder why that is, will have to check...
FWIW, with that image, with anti-ringing enabled, Jinc 3-taps and 4-taps look very similar.
The parking meter image is fairly soft. I vaguely remember someone mentioning that it was "obvious" that it had been obtained by downsampling with box filtering, and I remember looking carefully and agreeing.
When enlarging blurred images, decent windowed Sinc and Jinc methods will generally give roughly similar results.
Are video images typically that soft and similar to the results of downsampling by box filtering?
Different film studios are using different downscaling methods. Some use things like Lanczos. Others appear to use Nearest Neighbor sampling (shudder). I guess some are using box filtering. Many DVDs are *very* soft, much softer than the parking meter image, and still sometimes have ringing artifacts in them, despite being so soft. Good Blu-Rays may be a bit sharper than the parking meter image, but I doubt they're much sharper. Generally I think movies are softer than photos.
I don't remember which method I used exactly to create that parking meter image, it was a couple years ago. It is a downscale, but I don't remember which algorithm I used. I think I used one which didn't ring (at all) because I wanted to have a source image with not even a hint of ringing, so I could properly evaluate which upscaling algorithms add ringing and which don't.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.