madVR - high quality video renderer (GPU assisted)

[6233638]

62228345904589305483, are you using the new anti-ringing? Positive or negative thing as far as your upscaler choices go?

p.s. get a nickname people can remember :PI only planned on lurking, but that clearly changed. I don't know if there is a way to change your username here. I regret my decision.


I need to do a lot more testing as there have been several changes made since I last had a chance to properly evaluate it. Hardware problems meant I was unable to, and I've still been too busy to do anything like that recently. (haven't even had the time to sit and watch a whole film yet!)

From preliminary testing, it seems to be a positive thing overall.
Right now, I like SoftCubic 50 with Anti-ringing for Luma upscaling (previously SoftCubic 80) and Bicubic 75 with anti-ringing for Chroma upscaling.

This is going to take a lot of testing though, as there are so many more variables now, but I wouldn't be surprised if I ended up with those as being my preference again.

What is likely to change, is which of the sharper algorithms end up working best with the anti-ringing function. Now that its strength has been reduced, to reduce artefacts, I don't know that I'd recommend Lanczos.

The Bicubic variants all seem to do quite well with it. I don't normally like Catmull-Rom, but it seemed like that maybe had potential, or you could just go with Bicubic 75 which is always a safe bet. (even without the anti-ring filter, it's one of the better choices to balance sharpness and artefacts)

EDIT: Actually now I'm not so sure. The very next thing I loaded up, is showing clear aliasing with many of the Bicubic variants for luma upscaling, including SoftCubic 50. This is why I need time to do proper testing...

[madshi]

If i enabled something in PotPlayer, i can't find what. I have this problem since 0.83
Ok, about the problem with the seekbar making madVR leave FSE mode: Could you please make a debug log with a madVR v0.83.x version which shows the problem, and could you please also make a debug log with an older madVR version (e.g. 0.82.5) which does *not* show the problem? Please make the debug logs like this:

(1) delete log file (if there is any)
(2) start media player
(3) start playback in FSE mode
(4) make sure the madVR debug OSD is *on* (Ctrl+J)
(5) show the PotPlayer seekbar
(6) wait 5 seconds, while the seekbar is visible
(7) close PotPlayer
(8) zip the log file

If I can look at those log files from different madVR versions which behave differently, then maybe I can figure out what's going on.

So, when switching from windowed to fullscreen (in player) it enters directly in FSE. If i right click to exit FSE, after 3 sec it enters FSE normal. It is a new problem since v0.83.
Actually this is exactly the intended behaviour. If you switch from windowed to exclusive mode, there's no good reason to wait 3 seconds. But if you right click, and then choose an option from the context menu which opens another window, it is possible that there's a small delay between the context menu being removed and the new dialog window being opened. So there the 3 sec delay makes sense to avoid madVR switching between FSE and windowed mode twice.

Madshi:
This is basically what I'm doing:

If TaskbarThumbnails <> nil then Try TaskbarThumbnails.Thumbnails[tnvPlay].ImageIndex := tniPlay; Except End;

That's the only place that I change the icons during a load, is that not enough?
I don't see this code in "dwTaskbarThumbnails.pas". The crash report does not indicate that "TaskbarThumbnails.Thumbnails[tnvPlay].ImageIndex := tniPlay" crashed, so putting a try..except around that might not help much. The code which crashed is the line in "TdwTaskbarThumbnails.DoUpdate", so you have to add the try..except block there. I'm not sure, maybe this is not even your own code. But still, that's where the exception occurred, so that's why you gotta place the try..except block, if you want to "hide" the exception.

I'm having an issue whereby the video will randomly (like maybe once every few hours of playing various videos) that the video stops on a frame and the audio keeps playing. If I try to pause, unpause, FF or RW it makes no difference to the video being stuck on the exact same frame but the audio is changing in the background.
Does the debug OSD still change? Can you enable/disable the debug OSD in that situation? Does the media player still react to your commands (e.g. do the buttons react to clicks) or is it totally frozen? It might be necessary to create a debug log for this situation. I know it might be difficult if you can't reproduce the problem. Another try would be to create a freeze report in that moment. I don't think it will help, but it might be worth a try...

madVR v0.83.7 is super stable for me now. I think it's twice to three times as fast as the previous versions. I bumped up luma upscaling and downscaling to Spline 3 taps going from 1080p -> 2048 x 1152 and it fills up the queues. I'm amazed.
Not sure why it would be faster, it shouldn't! Well, maybe shutdown or changing video files could be slightly faster. But rendering performance should not be faster! I'm confused...

Reproduced it in 0.83.4, so now I'll try 0.83.3

Edit: Reproduced it in 0.83.3, so now I'll try 0.83.2
Edit: Reproduced it in 0.83.2, so now I'll try 0.83.1
Edit: So far, it doesn't seem to occur in 0.83.1, but I'll continue testing over the next couple days to make sure.
The only differences between v0.83.1 and v0.83.2 are Overlay related, or affect closing playback or changing video files. You're not using Overlay, are you?

I got a freeze, so here is the report.
In which situation did this freeze occur? It seems that PotPlayer contains *some* debug information, but it appears to be rather incomplete. Because of that the use of the freeze report is of limited use, unfortunately. Is that the latest PotPlayer build?

With 0.83.7 files begin and play correctly, but if you jump ahead or back a number of times all of a sudden frames start dropping, stuttering and it does not stop or correct after pausing. It is consistent. Go back to 0.82.5 and there are no problems. Jump around between 3-5 times and always see the problem.

The render and back buffer que appear that they are not being filled once the problem starts.

Running in FSE mode is flawless.

I could not get the debug log as you requested. Double clicking “activate debug mode.bat” yielded access denied and when run as administrator said file madVR.ax not found … even though it is right in the same folder …
A debug log is needed. Not sure why the batch file doesn't work, but the batch file is really only for your comfort, you can do the same thing the batch file does manually: Just rename "madVR.ax" to "madVR - release.ax" and then rename "madVR - debug.ax" to "madVR.ax". After that a debug log should appear on your desktop, when madVR runs. When trying to reproduce the problem, if you can't reproduce it for a longer time, please delete the log file and start again. This will make sure the log file doesn't grow too big. When the frame drops start occurring, please let it run for maybe 10 seconds, then stop the media player, zip the log file and upload it somewhere. Thanks!

what factors of graphic cards other than bandwith and memory type are decisive for speed for madvr? in recent two years, not much has changed regarding bandwith and memory type, there are still the budget and higher priced graphic cards which feature bandwith of roughly said between 20 - 200 GB/s.

but for some reason when having two cards with the same value for bandwith, the newer card still seems to be a bit faster than the old one. so which other stuff comes into consideration for madvr?
New GPUs often have small efficiency improvements, so they make better use of the available memory bandwidth. Shader power is also important.

What message you send, what message MPC-HC must handling instead of e.Wait() ?

P.S.
Try on this test build http://rghost.ru/40672681
I'll reply via PM. Thanks for looking into this.

[madshi]

madshi
With 83.7 video does not stop.
But when switching Film - Video - Film (23->59->23), madvr starts dropping frames (queues are full) and dtshd audio starts stuttering.
We're talking about fullscreen exclusive mode here, right? I can't seem to be able to reproduce the problem on my win7 x64 PC in FSE mode. Can I have a log file, please? Let the dropping continue for 10 seconds, then stop the media player. Thx.

[madshi]

Edit: I've obtained a copy of MadVR 0.82(.0) and the issue is there, making that the first version it appears in.
Ok, I've found the change which is responsible for the effect you've been reporting. I'll undo that change in the next build. Unfortunately I'm not sure why I implemented that change in the first place, so I hope there won't be any negative side effects...

[Blight]

Madshi:
Any word on the API callback function to notify players before and after MadVR has entered FSE (so I can work-around the keyboard-focus issue)?

[madshi]

It will be in the next official build.

[cyberbeing]

The only differences between v0.83.1 and v0.83.2 are Overlay related, or affect closing playback or changing video files. You're not using Overlay, are you?
No, I'm not using Overlay. Doesn't changing/toggling subtitles via the splitter reload the graph or some such, as it sometimes results in a small backward or forward seeking jump from your present position?

I'm testing 0.83.7 now, which I haven't done yet, to make sure this didn't somehow get resolved in the latest version.

[vomanci]

Ok, about the problem with the seekbar making madVR leave FSE mode: Could you please make a debug log with a madVR v0.83.x version which shows the problem, and could you please also make a debug log with an older madVR version (e.g. 0.82.5) which does *not* show the problem?

Well, i have the logs but now FSE doesn't work with any madVR versions (i tred like 4 old ones before 0.82.5). Strange. It seems to be PotPlayer's fault, but i clearly remember not installing a new version before 0.83 when it first appeared. PotPlayer is the latest version installed 1.5.34186, i always keep it updated.
One thing though, when i move the mouse over the seekbar i see for a split seccond your seekbar.

In which situation did this freeze occur? It seems that PotPlayer contains *some* debug information, but it appears to be rather incomplete. Because of that the use of the freeze report is of limited use, unfortunately. Is that the latest PotPlayer build?

The freeze occured when swithcing from windowed to fullscreen the player, FSE being enabled, in all PotPlayer versions (when the movie was playing of course). With the latest updates in player and madVR (after 0.83) appears very rare.


http://www.sendspace.com/file/ye2h9x

[madshi]

Well, i have the logs but now FSE doesn't work with any madVR versions (i tred like 4 old ones before 0.82.5). Strange.
I half expected this. The logs say that there's a window covering the madVR window. That's why madVR leaves FSE mode. It's as intended. If you don't want this to happen, you have to reconfigure PotPlayer. There are some options in PotPlayer that allow madVR to stay in FSE mode. Don't ask me how these options are named, though, I don't know.

[mzso]

I half expected this. The logs say that there's a window covering the madVR window. That's why madVR leaves FSE mode. It's as intended. If you don't want this to happen, you have to reconfigure PotPlayer. There are some options in PotPlayer that allow madVR to stay in FSE mode. Don't ask me how these options are named, though, I don't know.

For one Skin > Control > Image overlay on screen > Direct9d seems to work.

[oddball]

For one Skin > Control > Image overlay on screen > Direct9d seems to work.

Does anyone know if there is a similar method for MPC-HC? It's annoying when you select the properties of a filter and it causes FSE to exit.

There is another bug whereby if I open a window whilst FSE is running the window does not - always - appear (But it is really there). If you move the window (blindly) it will appear. Also minimizing the window makes the window appear (But it's now not there and is minimized so clicking on it or trying to move it then does nothing until you maximize it again).

Not sure if this is a Windows/Nvidia bug though.

EDIT: There is another bug I forgot. If you bring up a filter window that pops up on the playback screen and try to drag it over to another display and use it. After 3 seconds the new window becomes locked out/dead. It's there but I cannot appear to make use of it. I will edit this again or reply if I can demonstrate this as I can't recall which filters do this.

EDIT: I just tried loading LAV Audio Decoder. It pops up on the playback display (My HDTV). If I drag the window to my primary PC display after 3 seconds I am unable to do anything within that window other than move it about. All the functions become unusable. This is not unique to LAV as it occurs in other filters.

[vomanci]

I half expected this. The logs say that there's a window covering the madVR window. That's why madVR leaves FSE mode. It's as intended. If you don't want this to happen, you have to reconfigure PotPlayer. There are some options in PotPlayer that allow madVR to stay in FSE mode. Don't ask me how these options are named, though, I don't know.

Well, i reinitialized PotPlayer and no FSE, so they changed something in their latest versions. The skin sugestion doesn't work, it disables madVR.

EDIT: It's not the player. Tried older versions since 4 stable releases back and the same thing, they don't work in FSE but they used to. So it has to be something on my machine, but i can't figure out what.

Thank you.

[mzso]

Does anyone know if there is a similar method for MPC-HC? It's annoying when you select the properties of a filter and it causes FSE to exit.

I don't think that's possible. If you bring up another window like the filter properties then it won't be exclusive. How do you even open the filter properties? You can't even have menus in FSE.

[oddball]

I don't think that's possible. If you bring up another window like the filter properties then it won't be exclusive. How do you even open the filter properties? You can't even have menus in FSE.

Systray icon ;)

[Moony349]

For FSE in Potplayer:

General - Skin - Control - Method = Disable

This works for me. Any method besides disable (D3D9 or Image Overlay) will not allow MadVR to go FSE for me.

Speaking of FSE: I don't use it right now because my card is quite capable. That being said, I would love to if I could get MKV bookmarks on to the timeline! :)

[blackjack12]

Windows 8 RTM (64) – build 9200
AMD Radeon 6570
AMD Radeon driver ver. 12.8
MPC-BE 1.0.3.1
LAV Filters 0.51.3-94 (not for VC-1, LAV filter issues with VC-1, AMD and Windows 8)
madVR - Comparing 0.82.5 (with antiringing 6 updates) - 0.83.7
MKV Blu-Ray direct rip files tested - VC-1, VC-1i, H264, H264i material
CPU Que = 12
GPU Que = 8
Windowed Mode back buffers = 3

Problem:
With 0.83.7 files begin and play correctly, but if you jump ahead or back a number of times all of a sudden frames start dropping, stuttering and it does not stop or correct after pausing. It is consistent. Go back to 0.82.5 and there are no problems. Jump around between 3-5 times and always see the problem.

The render and back buffer que appear that they are not being filled once the problem starts.

Running in FSE mode is flawless.

I could not get the debug log as you requested. Double clicking “activate debug mode.bat” yielded access denied and when run as administrator said file madVR.ax not found … even though it is right in the same folder …

Madshi -
The debug file you asked for can be found here:
http://sdrv.ms/P9pWXC

Hope this helps ...

[madshi]

Madshi -
The debug file you asked for can be found here:
http://sdrv.ms/P9pWXC

Hope this helps ...
Thanks. I do wonder why you upload a text file unzipped, but anyway. Can you please try these 2 test builds:

http://madshi.net/madVR837test.rar

Does either of them fix the problem (if so, which)? If neither of them fixes the problem, please double check whether the problem also occurs with v0.83.1, which you can download here:

http://www.videohelp.com/tools/madVR/old-versions#download

[Blight]

Prinz:
Here's a new ZP build that should show a proper error message instead of the OLE error message:
https://dl.dropbox.com/u/104094858/zplayer_madExcept3.rar

Let me know which error message you see, it may help me track down the issue.

Madshi:
Do you think you can add image orientation (rotation) feature into MadVR API?
Something similar to the JPEG EXIF orientation modes:
http://sylvana.net/jpegcrop/exif_orientation.html

With all the people capturing video using their cellphones, I get requests for this feature every so often.
I asked nev to do it in the decoder, but he says it should be done in the renderer.

Lastly, do you think you can support the IQualProp interface in MadVR? I already support it for all other renderers and it would be nice for the users to get this info without having to enable MadVR's OSD display.

[madshi]

@Blight, I've image rotation and IQualProp on my to do list already. Although for image rotation currently I was only planning to support monitor rotation. I suppose you'd like to tell madVR to manually rotate the image in 90, 180, 270 degrees?

[Prinz]

Prinz:
Here's a new ZP build that should show a proper error message instead of the OLE error message:
https://dl.dropbox.com/u/104094858/zplayer_madExcept3.rar


http://i50.tinypic.com/eugigi.jpg

[blackjack12]

Thanks. I do wonder why you upload a text file unzipped, but anyway. Can you please try these 2 test builds:

http://madshi.net/madVR837test.rar

Does either of them fix the problem (if so, which)? If neither of them fixes the problem, please double check whether the problem also occurs with v0.83.1, which you can download here:

http://www.videohelp.com/tools/madVR/old-versions#download

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

[mzso]

Systray icon ;)

Same thing. :) How do you imagine it being exclusive when something else is on screen than madVR? (BTW the systray brings up a context menu too)

For FSE in Potplayer:

General - Skin - Control - Method = Disable

This works for me. Any method besides disable (D3D9 or Image Overlay) will not allow MadVR to go FSE for me.

Not my experience. the d3d9n adds the capabilit to show the potplayer skin in FSE.

[Blight]

Madshi:
To cover all the bases I would like the option to:
1. Rotate 90, 180, 270
2. Flip vertical & Horizontal

And yes, monitor orientation doesn't have anything to do with this feature request as I intend it to be a user-function.
You should make the user-initiated rotation value relative to the monitor orientation if you support that feature too.


Prinz:
Sadly, I don't know what's causing this error, in the next build, you wont see any error as ZP's code now catches it.
I'm not sure though what side-effects it may have (hopefully none).

[omarank]

I installed madVR v0.83.7 on an old laptop, which has mobile Intel 4 series express graphics. I wasn’t expecting it to handle madVR but to my surprise it handled pretty well. I just had to play with the scaling algorithms and I could play Blu Ray videos without any dropped/ delayed frames. I could set any of the chroma algorithms other than Lanczos and Spline, but I could only set Nearest Neighbour or Bilinear for luma. I did my testing using Mitchell Netravalli for chroma and Bilinear for luma.

I found two issues however:
1. When I play any interlaced video, I see a “deinterlacing failed” message.
2. If I select Overlay mode, I see a jerky video (like having back and forth motion). Even though the video is jerky, queues remain stable and dropped/ delayed frames or glitches counters don’t go up.

There are two observations:
1. If I use yCMS, I can’t play videos without any dropped/ delayed frames even if I select all the “trade quality for performance” options with the 3dlut bit depth set as 6 bit and use Bilinear for both chroma and luma scaling.
2. I see one or two presentation glitches every 15-20 minutes in some videos.

I don't consider the above observations as issues, simply due to the fact that the hardware used is rather old.

I just wanted to confirm if deinterlacing and overlay mode are not supported for old Intel integrated graphics.

[mbordas]

Can anyone verify a problem with the latest LAV filters (0.51.3-89-g8c3b2ec) with dvd decoding? Certain dvds seem to display a black screen for the menu (eg Michael Clayton, Syriana, Princess Mononoke) and the only way to fix it is to disable automatic source detection in madVR. Many other dvds play just fine.

Unfortunately, disabling source detection isn't a good solution (for me) cause it leads to other problems - the display refresh rate is for some reason set to 23.9999 instead of 23.976 even though this isn't in madVRs list of display modes..?

I'm posting here rather than in the LAV forum since the fix seems related to madVR, but given that the dvd decoding is a brand new feature in LAV the problem may actually be there.

[Pat357]

Unfortunately, disabling source detection isn't a good solution (for me) cause it leads to other problems - the display refresh rate is for some reason set to 23.9999 instead of 23.976 even though this isn't in madVRs list of display modes..?

You don't have 24Hz in madVRs list of display modes..?
How do you play real movie-content then ??

[mbordas]

Well, with nvidia drivers, I've always had to create a custom resolution. You're right that it says 24Hz but it's really 23.976. So I guess I don't know, where does the "true" 24 hz refresh rate come from? (and I don't think I have any content that is true 24 Hz anyway).

I'm getting weirdly different results from different dvds. Some exhibit the behavior I described, some don't, some just hang. So I'm just really confused, and curious if anyone else is seeing these problems.

[6233638]

Slight bug with the stats when the clock stabilises:

http://www.abload.de/img/1jdayscyj9a.png

I assume this happens when it reaches 1 frame repeat every 10 days, but I've only ever noticed once it has already happened.

I don't think this is anything new, I only started noticing it after making some tweaks to the system timers.

Well, with nvidia drivers, I've always had to create a custom resolution. You're right that it says 24Hz but it's really 23.976. So I guess I don't know, where does the "true" 24 hz refresh rate come from? (and I don't think I have any content that is true 24 Hz anyway).

I'm getting weirdly different results from different dvds. Some exhibit the behavior I described, some don't, some just hang. So I'm just really confused, and curious if anyone else is seeing these problems.If you want 24/1.001, you should specify 1080p23, rather than 1080p24. (1080p24 = 24.000Hz)

I recommend using 1080p24 and ReClock however.

[cyberbeing]

In the past madshi has said 1#J days was likely a math overflow, which basically means you're exceeded the maximum duration which madVR is capable of measuring. This has been a known issue since madshi first added these readings to the OSD. It's common to see 1#J days when using Reclock, though still possible if less common without Reclock, by just using an extremely fine tuned refresh rate.

[nevcairiel]

Just feel happy when you see it there. :)

[6233638]

In the past madshi has said 1#J days was likely a math overflow, which basically means you're exceeded the maximum duration which madVR is capable of measuring. This has been a known issue since madshi first added these readings to the OSD. It's common to see 1#J days when using Reclock, though still possible if less common without Reclock, by just using an extremely fine tuned refresh rate.With ReClock I was previously getting times in the 3-5 hours range, but after making tweaks to the system timers, that now stabilises at days. (seems to get more stable the longer it's active)

What I did was: Enable HPET (http://en.wikipedia.org/wiki/High_Precision_Event_Timer) by turning it on in the BIOS and running bcdedit /set useplatformclock true in a command prompt (Windows 7) then rebooting.
Set Timer Resolution to 0.5ms with TimerResolution (http://www.lucashale.com/timer-resolution/)

Just feel happy when you see it there. :)I'm definitely not complaining, just hadn't seen any discussion of it before.

[madshi]

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
Weird. Ok, I guess the only way to get to the bottom of this is create some test builds which are somewhere between 0.82.5 and 0.83.1 to find out which exact change cause the problems. I'll do that later today, or maybe during the weekend.

Madshi:
To cover all the bases I would like the option to:
1. Rotate 90, 180, 270
2. Flip vertical & Horizontal
Ok, will put that on my to do list. But it might take a while until I get to that.

I installed madVR v0.83.7 on an old laptop, which has mobile Intel 4 series express graphics. I wasn’t expecting it to handle madVR but to my surprise it handled pretty well. I just had to play with the scaling algorithms and I could play Blu Ray videos without any dropped/ delayed frames. I could set any of the chroma algorithms other than Lanczos and Spline, but I could only set Nearest Neighbour or Bilinear for luma. I did my testing using Mitchell Netravalli for chroma and Bilinear for luma.

I found two issues however:
1. When I play any interlaced video, I see a “deinterlacing failed” message.
2. If I select Overlay mode, I see a jerky video (like having back and forth motion). Even though the video is jerky, queues remain stable and dropped/ delayed frames or glitches counters don’t go up.
Not sure why deinterlacing fails. I think it should work. Or are you still using XP? In that case maybe you don't have .NET 3.0 (or higher) installed? That's required for DXVA2 deinterlacing. Or maybe the Intel drivers don't support DXVA2 deinterlacing in XP? Don't know. If you're on a newer OS then in theory I think it should work. It would be very hard for me to fix. Does deinterlacing appear to work in EVR?

Can't say much about Overlay mode. Well, I'm presenting frames in a different thread, maybe that confuses the Intel driver. But reportedly it works fine on newer Intel GPUs, so it's probably a driver bug. Nothing I can do about it...

Can anyone verify a problem with the latest LAV filters (0.51.3-89-g8c3b2ec) with dvd decoding? Certain dvds seem to display a black screen for the menu (eg Michael Clayton, Syriana, Princess Mononoke) and the only way to fix it is to disable automatic source detection in madVR.
What "source detection" do you mean exactly? FWIW, madVR does not officially support DVD playback yet. If this problem is reproducable and only occurs with LAV, then maybe you could ask nevcairiel to look into it? Not sure if he's interested in fixing that, though. Of course it could also be a bug in madVR, can't really say...

[madshi]

madVR v0.84.0 released

http://madshi.net/madVR.zip

* added media player screenshot functionality (IBasicVideo::GetCurrentImage)
* added "Jinc" image upscaling algorithm
* added anti-ringing filter for downscaling
* added "user interface\keyboard shortcuts" settings page
* added option to apply keys "only if media player has keyboard focus"
* added options to adjust the keys for all existing keyboard shortcuts
* added shortcut option for directly selecting specific source primaries
* added shortcut option for directly selecting specific deint content types
* added shortcut option for en/disabling automatic fullscreen exclusive mode
* added shortcut option for disabling exclusive mode for 10 seconds
* added shortcut option for en/disabling the display mode switcher
* added shortcut option for en/disabling dithering
* added shortcut option for changing the display bitdepth
* added various shortcut options for selecting scaling algorithms
* added IMadVRExclusiveModeCallback interface for exclusive mode notifications
* renamed "luma up/downscaling" to "image up/downscaling"
* renamed "use 10bit luma buffer ..." to "use 10bit image buffer ..."
* scaling algorithm parameters (softness, sharpness, taps) are remembered now
* scaling algorithm red/green graphs (settings dialog) now cover anti-ringing
* modified shader storage to decrease madVR.ax file size
* fixed: KMPlayer + madVR decoders + "delay playback start" was always paused
* fixed: settings dialog had problems with yCMS data when using Overlay mode
* fixed: cosmetical issue in fullscreen windowed mode when changing video files
Some notes:

(1) Screenshots are done after deinterlacing and color conversion, but before scaling and aspect ratio correction. Screenshots are always converted to 8bit fullrange RGB (0-255), using error diffusion, which is a higher quality dithering algorithm compared to what madVR does during playback. Screenshots only work if the media player supports it. MPC-HC does out of the box, haven't tested other media players, but they will likely work, too.

(2) The "Jinc" (3 or 4 taps) image upscaling algorithm is totally new. It's somewhat similar to Lanczos, but Jinc is slower and has slightly higher quality. You can think of Lanczos as a rectangular resampling filter. In comparison Jinc is a circular resampling filter. Jinc is slightly softer than Lanczos, but it has very low aliasing artifacts (lowest of all algorithms) and ringing is less strong compared to Lanczos. Furthermore the madVR anti-ringing filter works especially well together with Jinc, so with the anti-ringing filter Jinc is pretty much ringing-free without any negative side effects that I could see. In certain situations Lanczos might look better (because it's slightly sharper than Jinc), but overall I believe Jinc beats Lanczos in quality, thanks to a more natural look with less ringing and aliasing artifacts. Jinc comes at a quite big performance cost, though. At low scaling factors, Jinc is comparable in performance to Lanczos8. However, with bigger scaling factors, Jinc3 can be twice as slow as Lanczos8 and Jinc4 twice as slow as Jinc3. Ouch...

[ryrynz]

Holy crap it's Christmas, and I was going to head to bed.. This improved 8 bit dithering done with screenshots, how come this isn't an option in real time? Is it that slow?
I thought MadVR took "no shortcuts, highest quality has priority over anything else" :D

[madshi]

Error diffusion can't be done with GPU pixel shaders because error diffusion processes one pixel at a time, using the result of the previous pixel calculation for the next pixel. GPU pixel shaders more or less work on all pixels at the same time, which is the opposite of what error diffusion needs. *Maybe* it might be possible to do error diffusion using OpenCL/CUDA, but it will be difficult to do and likely not perform very well. For screenshots error diffusion is easy because madVR is doing the screenshot processing via CPU instead of GPU.

[SamuriHL]

Jinc eh? Guess I'm gonna have to get my head out of the Android world for a bit and do some testing. Thanks!

Sent from my Xoom using Tapatalk 2

[ryrynz]

The Keyboard shortcuts are awesome, I was hoping for an auto populate when the keys were pressed instead of typing them in but that's okay. Status messages on the hotkey activations as well! It's everything I asked for last year. Thanks!
Jinc is very similar to Lanczos as you said. I think I'd generally prefer Jinc but as far as ringing goes they're both very close to each other at least as far as dark line animated content anyway..
Is there any ETA on the more advanced anti-ringing filter?

I think though what I love most of all about this build is this


* fixed: cosmetical issue in fullscreen windowed mode when changing video files


Ive noticed that on animated content Jinc with 4 taps has ringing closer to dark lines on animated content which doesn't really look better or worse than 3 taps as far as ringing is concerned but with anti-ringing enabled
4 taps due to having it's ringing closer to the dark lines has more of it's ringing wiped out than 3 taps. As a result 4 taps looks better than 3 taps when anti-ringing is enabled, it murders my HD3000 however, so no go.

Madshi what's your thoughts on having a upscaling or downscaling value listed in the OSD? Or perhaps a combined output res along with upscaling/downscaling value depending on what's being done.

[madshi]

Jinc is very similar to Lanczos as you said. I think I'd generally prefer Jinc but as far as ringing goes they're both very close to each other at least as far as dark line animated content anyway..
Is there any ETA on the more advanced anti-ringing filter?
The Jinc anti-ringing algorithm is already more advanced. You still see problems with dark lines with Jinc anti-ringing?

[Moony349]

Madshi,

Would it be theoretically advantageous/possible to allow more taps for Jinc upscaling and/or chroma upscaling with Jinc?

Also: MadVR is amazing! :) Forgot to mention that one.

[THEAST]

Weird. Ok, I guess the only way to get to the bottom of this is create some test builds which are somewhere between 0.82.5 and 0.83.1 to find out which exact change cause the problems. I'll do that later today, or maybe during the weekend.

Actually I had the exact same issue as blackjack12 with the builds between v0.82.5 and v0.83.7 both on my dekstop (AMD HD 7950) and laptop (Nvidia 520M) but I just tested build v0.84 on my desktop and the issue is gone. Though I was on XP at that time and now I'm on 7.

[madshi]

Would it be theoretically advantageous/possible to allow more taps for Jinc upscaling?
It would be *possible*, but useful? I don't know. Jinc4 is already very slow. I had tried Jinc8: Rendering took more than 1 second per video frame with my old Radeon 3850 when upscaling DVD 400%. I just think that the image quality gain is too small compared to the performance cost.

Lanczos3 reads 12 source pixels to create 1 output pixel
Lanczos4 reads 16 source pixels to create 1 output pixel
Lanczos8 reads 32 source pixels to create 1 output pixel
Jinc3 reads 36 source pixels to create 1 output pixel
Jinc4 reads 64 source pixels to create 1 output pixel
Jinc8 reads 256 source pixels to create 1 output pixel

Basically doubling taps for Lanczos means double memory bandwidth consumption. Doubling taps for Jinc results in a 4x increase in memory bandwidth consumption.

Actually I had the exact same issue as blackjack12 with the builds between v0.82.5 and v0.83.7 both on my dekstop (AMD HD 7950) and laptop (Nvidia 520M) but I just tested build v0.84 on my desktop and the issue is gone. Though I was on XP at that time and now I'm on 7.
That's interesting! blackjack12, can you please retest with v0.84?

[ryrynz]

The Jinc anti-ringing algorithm is already more advanced. You still see problems with dark lines with Jinc anti-ringing?

Optimized just for Jinc yeah? I couldn't see really any difference in that area between lanczos and Jinc with ringing which manifests itself as haloing around dark lines.
This is why I continue to use Mitchell, it's the sharpest resizer that doesn't create ringing halos on animated content.

I'll take a close look at how anti-ringing compares with Jinc vs Lanczos at a later since they're using different techniques?
I've just been looking at the ringing(haloing) at this point not how it effects the lines when zoomed in, although you did grab that sample from me, did you look any further into it there?

Your thoughts on the OSD addition for scaling I suggested? I thought it would be handy to see that although people can always work this out themselves.

[Pat357]

Madshi,

It seems you solved the problem with yCMS / Overlay too : no crashes anymore !
Thanks a lot !
(What was the cause of the problem btw ?)

[madshi]

Optimized just for Jinc yeah?
It's the same logic, but due to how Jinc works, madVR can look at 4 source pixels to control anti-ringing, while with all other algorithms, madVR can only look at 2 source pixels. That should make anti-ringing less prone to introducing aliasing/stepping artifacts. Plus, it also allowed me to make the ringing-removal stronger without losing contrast/detail.

I couldn't see really any difference in that area between lanczos and Jinc with ringing which manifests itself as haloing around dark lines.
This is why I continue to use Mitchell, it's the sharpest resizer that doesn't create ringing halos on animated content.
I'm slightly confused. I thought the original issue with the anti-ringing filter and anime content was not the ringing itself, but actually stair-stepping (aliasing) in some dark lines, which only occurs when anti-ringing is enabled? Now you seem to say that the anti-ringing filter doesn't remove enough ringing? That's a totally different issue!

If it's really the ringing itself which worries you now, Jinc with anti-ringing enabled should really get rid of most ringing. If you find it's not working as well as expected, please send me a sample. Please note, though, that Lanczos and Jinc do tend do make already existing ringing more obvious, which Mitchell might not does as much. So maybe the issue isn't really that Jinc adds ringing by itself but instead that the source already has ringing and Jinc just makes it more obvious compared to Mitchell? You might be able to work around this issue by running a de-ringing avisynth script in ffdshow.

Madshi what's your thoughts on having a upscaling or downscaling value listed in the OSD?
Not sure what you mean exactly.

It seems you solved the problem with yCMS / Overlay too : no crashes anymore !
Thanks a lot !
(What was the cause of the problem btw ?)
I've told the compiler to use "." as decimal separator very early during the initialization of madHcCtrl.exe. Somehow when Overlay was used, the decimal separator was switched back to "," for some reason. I don't understand (at all) why and where. I've now simply force the decimal separator back to "." when the settings dialog is shown.

[robpdotcom]

* added options to adjust the keys for all existing keyboard shortcuts

Awesome. I've wanted this for a long time, but I figured it was way down on your priority list.

[ryrynz]

It's the same logic, but due to how Jinc works, madVR can look at 4 source pixels to control anti-ringing, while with all other algorithms, madVR can only look at 2 source pixels. That should make anti-ringing less prone to introducing aliasing/stepping artifacts. Plus, it also allowed me to make the ringing-removal stronger without losing contrast/detail.

Ah okay, so that's pretty much the final algorithm then.


I'm slightly confused. I thought the original issue with the anti-ringing filter and anime content was not the ringing itself, but actually stair-stepping (aliasing) in some dark lines, which only occurs when anti-ringing is enabled? Now you seem to say that the anti-ringing filter doesn't remove enough ringing? That's a totally different issue!


Yeah the original issue was that smoothness that occurred when anti-ringing was enabled but since nothing has changed with that except for with Jinc I haven't looked at it, I am only commenting on the haloing which anti-ringing does work quite well to remove and how that compares between lanzcos and Jinc, not specifying any problems are all, just my observations.


If it's really the ringing itself which worries you now, Jinc with anti-ringing enabled should really get rid of most ringing. If you find it's not working as well as expected, please send me a sample. Please note, though, that Lanczos and Jinc do tend do make already existing ringing more obvious, which Mitchell might not does as much. So maybe the issue isn't really that Jinc adds ringing by itself but instead that the source already has ringing and Jinc just makes it more obvious compared to Mitchell? You might be able to work around this issue by running a de-ringing avisynth script in ffdshow.


There is very minor haloing in places, It's just that lanzcos and Jinc make it extremely noticeable. I have been running a de-ringing filter recently but I've still noticed haloing when using lanzcos. I'll have a good hard look at it later today but you're probably right it's likely more the source than anything else, I'll test more content and if I notice something I'll be sure to post it.


Not sure what you mean exactly.


Source resolution=640x480
Output resolution=1920x1080
Scaling= 3x/2.25x

Reason for mentioning it was that I was wondering how much work my resizing work my GPU was doing for it to be running so slow and by displaying the scaling it saves looking at the source and output resolution and dividing it to find out.. for the lazy I guess, thought it would be nice. *shrug*

Awesome. I've wanted this for a long time, but I figured it was way down on your priority list.

I kept mentioning it every "few months" :D

[6233638]

Wow, you weren't kidding about Jinc being demanding. It's 9–12ms depending on the video being played and whether or not it needs deinterlacing.

If I play a 720p video at maximum zoom in MPC-HC I've had it hit 140ms! (something I do when evaluating algorithms, not an issue in the real-world)


Looking forward to comparing it with everything else though. Sounds like it could be a winner if your system is up to the task.
There does seem to be more aliasing than Lanczos at high frequencies though. (Lanczos 4 and Jinc 4 are similar, Lanczos 8 has less)


P.S. I love that you now save settings for algorithm sharpness/taps/etc.
Would it be possible to save the anti-ringing filter option on a per-filter basis as well? Some filters seem to be better off without it. (SoftCubic for example)

[Xaurus]

madshi,

Thanks for the new version with Jinc, which I believe you made just for me since I bought the GTX 660 the other day. :D

[nlnl]

We're talking about fullscreen exclusive mode here, right? I can't seem to be able to reproduce the problem on my win7 x64 PC in FSE mode. Can I have a log file, please? Let the dropping continue for 10 seconds, then stop the media player. Thx.

madshi
Thanks for .84
Please have a look at those logs:
https://dl.dropbox.com/u/43376972/madvr%20-%20logs%2023%20-%2059%20freez.zip

[TheShadowRunner]

Excellent as usual, confirming frame capture/screenshot works perfectly on ZP ;)