madVR - high quality video renderer (GPU assisted)

[nevcairiel]

So request 16-bit support from AviSynth. Like i said, the whole DirectShow world is already full of hacks, adding more is a terrible idea.

Btw, the difference to 32-fp is that ffdshow already supported 32fp, and that its an official type, no hacks. Also, sansnom is gone.

[leeperry]

I still have his email, and he only joined the ffdshow team coz I whined for 32fp VST...he was working on MPC-HC in the first place.

Well, this hack would allow 16bit right here & right now. I would guess that IanB is well aware that post-processing in 8bit is a terrible idea.
Let's see what madshi has to say about this, shall wehttp://files.head-fi.org/images/smilies/popcorn.gif

[Atomix77]

If anyone is experiencing pixelated video after successfully installed madvr renderer, then you have obviously deleted the madvr folder.
I struggled with this problem for a long time until I found what caused my video to be extremely pixelated and low quality, even if madvr was selected as the renderer in MPC options.
So if you download latest version and extract it to a safe place, where you won't touch it in the future and then install it, you shouldn't have a problem.
It really should be written on the first page, that after madVR installation, you can't delete the folder containing the installation files, which is kinda stupid, because I like to delete every installation file after I have installed it, to get rid of excess files.

[Andy o]

It's not that stupid. If you know you can delete folders after installation, you should know which folders. Not that there's anything wrong with not knowing, but if you don't know, you shouldn't be in the business of deleting stuff anyway.

Rule of thumb: if the program you just downloaded opens a pretty window with colors and stuff and/or says "Windows installer blah blah" as the title, you probably can erase the folder. If it just opens a command prompt window and a message says "xxxxxxx.ax filter registered" or some such thing, and you can only press OK, then you don't delete that folder.

[cyberbeing]

madVR doesn't have an installer, so there are no installer files to delete. Possibly in the future madshi will create one, but as of right now, you extract the madVR program files and manually register the filter. Adding a blurb to the readme.txt should resolve the issue.

That this even happened means this is something the MPC-HC guys should fix. If a registered filter no longer exists on the system, MPC-HC shouldn't let you select it, but it looks like it does. That is bad behavior, especially if it falls-back to the default renderer without throwing an error that the selected renderer is missing.

[Andy o]

MPC-HC doesn't show the unregistered filters, but if a filter has been registered but its necessary files deleted, should MPC-HC take the time to look for them? Can it, even?

[Qaq]

MPC-HC doesn't show the unregistered filters
AFAIR it does. For External filters list.

Back to the topic. Is Half-floating (16fp) really enough for video processing (YUV>RGB, scaling)? Does anyone see any difference in HFP vs FFP with EVR CP? Sometimes GPU and VRAM load is not too high, so why not to use more accuracy in video processing? As an option. I'm pretty sure these questions were answered already, so it won't be hard to answer now :)

[Andy o]

It still shows them if you have unregistered after adding it to the externals list, but when you go to the "add" list they aren't there. Also, if they're in the externals list and you double-click on them they usually open their control panel, if they're registered. If they're not then nothing happens.

[Mikey2]

Hi all,

I have learned more so much on this thread that I think I now understand almost everything that is going on. So I thought I would return the favor and relay a "breakthrough" I just had.

Earlier I was having problems with dropped frames when trying to use the more advanced scaling algorithms such as multi-tap Lanczos or Spline, which seems to be the area in which the quality of this awesome renderer really shines. A few weeks ago, I was following along with most of you tweaking "flush" settings trying to get this to display as smooth as possible.

However, I always assumed that "hardware decoding" is preferable, if not necessary, to achieve optimum viewing. Thus for months I ran my NVidia-based cards in SLI being decoded via CoreAVC w/Cuda or even DXVA. In this configuration, even in SLI, I could barely run SoftCubic/Spline (my favorite combinations) without significant frame-droppage. I was about to buy a new expensive video-card to fix the problem. HOWEVER, in my case, I have an overclocked Q6600 CPU... So I tried disabling all hardware-based decoding, completely bypassing CoreAVC and instead using ffdshow's ffmpeg-mt software/CPU based decoder. (Remember there is no difference in image quality regardless of where the decoding calculations are performed.) Now I am elated to report that now that my GPU's are now exclusively dedicated to rendering/scaling via madVR, I can run every possible combination of resizing algorithm on my computer on practically any type of file without any dropped frames!

I hope this helps some of you; please let me know if you have any questions/concerns (or if I am not making any sense. ;)

Good luck, and thanks so much for this wonderful renderer!

PS - In regards to some of the discussion above, I run ReClock in PCM mode with DTS/AC3/AAC previously decoded to PCM in either AC3Filter or ffdShow. This allows ReClock to do its magic and send the "synced" PCM signal along HDMI. However, if you are stuck with SPDIF, I do NOT recommend decoding it to PCM just to re-encode it to ac3 in ReClock. (Unless you are dealing with PAL speedup...I suggest just dealing with the minor offsets. This is especially true if you are bit-streaming something like DTS-MA/TrueHD etc...there you cannot touch it without losing the lossless quality of the bit-stream.) I have found that the madVR info screen that says "1 frame repeat every x minutes" gives a good indication on how "off" you are. For instance, when playing a 23.976fps source on my 24Hz TV without Reclock it is usually in the range of "one frame drop every 2 mins 46 seconds" or so. However, when Reclock is on it says "One Frame drop every 1.5 days" or so. While the later is preferable, the former is IMHO not bad enough to lose a pure bit-stream by decoding it if you are just going to re-encode it again. (However, since I am not re-encoding the PCM and since AC3Filter is the best sounding audio decoder I have found, my setup works wonderfully for me. When playing a lossless bit-stream, I just deal with the frame delay every few minutes (which often do not come to pass anyway!))

Well I hope this helped...on the other hand, please let me know if *I* am confused. ;)

[alph@]

Ctrl +j,in average time, which is the most important parameter for a fluid movie, rendering time or present time,thank

[robpdotcom]

if you are stuck with SPDIF, I do NOT recommend decoding it to PCM just to re-encode it to ac3 in ReClock. (Unless you are dealing with PAL speedup...I suggest just dealing with the minor offsets. This is especially true if you are bit-streaming something like DTS-MA/TrueHD etc...there you cannot touch it without losing the lossless quality of the bit-stream.

But you cannot bitstream TrueHD or DTS-MA over SPDIF. You can, however, get lossless decoding via LAVAudio. I doubt you could hear the difference between bitstreaming the lossy "core", and letting Reclock encode what was decoded lossless.

[nightfly]

I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018

What do I lose not using exclusive?

Looks like I get tearing..

Regardless, it would seem my problem is due to Nvidia and a using a DVI - HDMI cable. On the straight HDMI to projector, I don't have the video level issue. Using custom resolutions also effect the issue. Oh well.

[mandarinka]

Why use hacks? There are pixel formats for real 16-bit (like the P016 mentioned above), any hack will just result in pain in the long run.

Besides, whatever "hack" people come up with, ffdshow has no developers anymore.

The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.

[e-t172]

I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018

Have you tried using a software decoder instead of LAV CUVID?

[kepke]

I have a issue with MadVR and video levels. Setting MadVR to output 0-255 (and using custom Nvidia resolution) I get black crush in exclusive full screen mode. In windowed mode video levels are correct. Disabled exclusive fullscreen mode and video levels match between fullscreen and windowed mode.

MadVR .61
LavCUVID .7
LAV Splitter/Audio .28
MPC-HC .3018

What do I lose not using exclusive?

Looks like I get tearing..

Regardless, it would seem my problem is due to Nvidia and a using a DVI - HDMI cable. On the straight HDMI to projector, I don't have the video level issue. Using custom resolutions also effect the issue. Oh well.

I had the same issue
Try to change the “Content type reported to the display” on the “NVidia Control Panel” -> “Adjust Desktop Color Settings” -> ” Content type reported to the display” -> “Full-screen videos”

[leeperry]

The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.
Well said, and it'd only be faster adopted if mVR supported 16bit input too. A full 16bit video pipeline, ouuuuh I like the sound of that :cool:

And that'd feed 10bit displays as well, whatever you'd need: sharpening, deinterlacing, etc etc. Minimal quality loss is the key, and I can't think of a better host than mVR for this. Hope it'll be considered http://forum-images.hardware.fr/images/perso/mzarella.gif

Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?p=1505499&postcount=234

[nevcairiel]

Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?p=1505499&postcount=234

Amazing? That looks like crap, the whole image has a pinkish tint, and some areas are over-brighted reducing details.

madVR already supports 16-bit input. If you want this to work, you should teach ffdshow to convert the "hack" into proper 16-bit on output (after its done with avisynth).
Keep the hack inside ffdshow, if you must, but having a "hacked" pixel format go out of ffdshow would be *terrible*. Should also not be that hard to transform it into a proper 16-bit pixel format on output, and madVR wouldnt even need changes.

[leeperry]

madVR wouldn't even need changes
Have you been appointed by madshi to provide tech support in this thread? Replying to your posts feels like troll feeding tbh.

[CruNcher]

Well said, and it'd only be faster adopted if mVR supported 16bit input too. A full 16bit video pipeline, ouuuuh I like the sound of that :cool:

And that'd feed 10bit displays as well, whatever you'd need: sharpening, deinterlacing, etc etc. Minimal quality loss is the key, and I can't think of a better host than mVR for this. Hope it'll be considered http://forum-images.hardware.fr/images/perso/mzarella.gif

Quite frankly, the latest build of SmoothAdjust() looks pretty darn amazing(it does stunning TV>PC conversions too): http://forum.doom9.org/showpost.php?p=1505499&postcount=234

And the use of this ? it can be done in Realtime these days as a Option in your GPU driver why in hells name invest the energy @ conversion with it and brake broadcast rules ? Sure you could say the broadcasters can do the PC->TV conversion but the Analog Broadcast standards are much older ;) Converting content from it's initial TV scale to PC scale is a bad thing and should be up to the decision of the Decoder part of the System not the Encoder.

[nevcairiel]

Have you been appointed by madshi to provide tech support in this thread? Replying to your posts feels like troll feeding tbh.

Your response right there is the only troll post, all i wrote are technical facts or opinions, not trolling.

All i'm saying is that madVR already supports 16-bit input, and since ffdshow needs changes anyway, just make it output the 16-bit in a "standard" format, that makes it easier on everyone.

Its not like ffdshow can already do this and just madVR needs changes.

[leeperry]

And the use of this ?
Quite simple: provide more levels to play around w/ to Avisynth scripts. LSF and GrainF3 look noticeably better when working on PC than on TV range...and I use PC range displays anyway, so there's no point in clipping my post-processing to TV when it'll expanded to PC afterwards. But this is OT, I was merely asking for madshi's opinion on this hack...as we've all be complaining about processing 16int audio and 8bit video. Can you feel the wind of change?

SmoothLevels() uses a different dithering algorithm from mVR, I find that they look amazing together in combo on a CRT, and I already posted comparisons a while back(the 2.0 beta has been a huge improvement as well). Ppl w/ 6bit dithered LCD displays hated it(TN panels and so), but don't shoot the messenger :p

[alph@]

leepery,you must be the only which use a crt display:)

[madshi]

Here you are!

My settings.bin is copied from old madVR version.
But I am not sure if it is the reason which gets D3D11 messed up...
Hmmmm... The log says playback was stopped barely 1 second after the windows <-> exclusive switch. madVR was just about to start presenting again. Not sure why the switch took so much time, but judging from the log, if you had had a bit more patience, playback would have (automatically) resumed.

Absolutely.

http://www.mediafire.com/?zdgi6alryd4bncv

1. Neither Option Selected
2. Limit Rendering Times
3. Run Presentation in Separate Thread
4. Both of the above selected.

It seems that my "fix" is an intermittent one, as taking that fourth log for you also resulted in a black screen.

Worked absolutely fine with three films in a row last night however.
Hmmmm... I like short logs. But these logs are so short that there's simply not enough information in them. Did you cut them down? Playback has barely started in these logs.

i got some problem with MadVR

problem : Blank Screen with sound in MPC -HC ( using High Performance Mode / AMD Radeon 6630 )
my conclusion : seems like MadVR can not detect AMD Radeon , since if i change MPC - HC priority to Power Saving ( using Intel ) the same video play flawlessly except stuttering ( maybe not powerful enough to play my Bluray rip video )

Notebook Sony VPCCA16FG
Specification :
Processor : Intel® Core™ i7-2620M Processor
Chipset : Intel® HM65
Video Card : AMD Radeon HD 6630M / Intel HD Graphics3000 (Hybrid)
Display resolution / Technology : 1600 x 900 / LED Backlight
Audio Type : Intel® High Definition Audio
Hard Drive : 500 GB Serial ATA 7200 RPM
OS : Microsoft Windows 7 Home Premium 64-bit

MadVR Log

http://www.mediafire.com/?irzogh2lb1l4xf4
The log looks just fine!! According to the log madVR is rendering your video and also displaying it. I've no idea why you get a black screen. Try updating your GPU drivers, maybe?

That log was from your Radeon, right?

I can't leave FSE mode sometimes (D3D11), log:
https://rapidshare.com/files/459642981/0.61-fse2window_fail.7z
Can't see anything wrong in that log on a quick check. What happens exactly in the problem situation? Please describe it in more detail.

using the d3d11 path, when double clicking out of an exclusive fullscreen mode to windowed mode, the mpc-hc window covers the entire screen (instead of getting back to the original size).
Happens on my secondary tv-monitor.
Doesn't happen on my primary monitor or when using d3d9 path.
Yeah, the fix I implemented to prevent the media player window to cover the entire screen seems to only work on the primary monitor, need to improve that.

sometimes when right clicking the tray icon, another tray icon menu opens up (the clock's right click menu). I remember eMule had the same issue and one of the developers found the cause. Maybe google will point in the right direction.

EDIT:
after some searching in Google... maybe you catch WM_RBUTTONDOWN instead of the proper (http://www.codeguru.com/forum/showthread.php?t=359190) WM_RBUTTONUP? :)
Yes, I've been using BUTTONDOWN. Have changed that to BUTTONUP now.

BTW is there any way to capture the stats display to a file? Or a logging option I have missed? I think it would be far better if people could post their results in a manner where Madshi can see which options were enabled and what the stats were. Not sure why he has not done this rather than asking us to post spurious details that are less objective.
The madVR debug logs already contain the stats, but reading logs is an extremely time consuming thing, simply because there's so much information in there.

I'm unable to get the MadVR resolution switching to work correctly. It supposedly overrides MPC-HC's fullscreen modes. I have it set thus.

1080p23, 1080p50, 1080i50, 1080i59, 720p23, 720p50, 720p60

I have 720p60 because I do have a true 60fps video I use to test.

Whenever I playback a 720p 23.976FPS file video it always defaults to 1080p23. However if I play a 720p 29.97FPS video it always defaults to 720p60.

Also when playing back 1080p 25FPS .ts files it plays at 720p60 (even if I use ReClock to PAL speedown).

Am I doing something wrong? I can understand if my HDTV does not support 720p at 24p/Hz but the .ts files are throwing me somewhat.

EDIT: OK changing 720p60 to 720p59 sorts out the .ts problem. But I still have 720p23 ending up as 1080p23. Could that be because my HDTV does not support 23/24 @ 720p?
The key thing is that all the modes you list in the madVR settings dialog must actually exist. If you list a mode that doesn't exist then Direct3D will switch to a "random" mode.

Can you make it displayer mode changer work with reclock?
I don't know in what way Reclock has a problem with madVR's display mode switching, but I don't think there's much I can do about it. I would rather guess it's a problem with Reclock. But I don't know for sure.

Ok Madshi, i have a question reguardling the fps override via renaming, and how the osd interprets that and whatnot. For example if there's a video that's 29.970 fps, and i want to play it back at 60hz (i have a resolution manually set to 60hz in the nvidia console, not the default 59.9) is it better to put 59p in the filename (to preserve the framerate, judging by the osd), or 60p? As if i put 59p, frame repeats happen a bit more often than 60p. And going by eye it looked like the osd wasn't lying, or maybe i was seeing it wrong?

So basically, is there any downside to not having the fps preserved perfectly/does it result in smoother playback, with no side effects? Or is the osd just showing what i'm telling it (and does it mean though that it repeats frames due to this more often?)?
What you write into the filename only affects which display mode madVR switches to. Nothing else. If both 59p and 60p will end up with the same display mode, there should be no difference between how fluidly they play.

Of course you should aim to get the best possible frame rate / refresh rate match. Which means that if the file is 29.970fps then you should try getting your display to do 59.940Hz instead of 60.000Hz.

Concerning the mouse visibility and the seekbar problems, I have done some tests (all with madvr 0.61 and MPC-HC 1.5.2.3056)
Looks like MPC-HC bugs, not madVR bugs to me. FWIW, the "D3D Fullscreen" option in the MPC-HC "Output" section is not supported by me. Which means that you can use it, but at your own risk.

I still get an access violation error when I switch to the next mediafile in the folder. I use PgUp and PgDown to do this often from within the media player - and whenever I do, I get an error.

MPC-HC says: Access violation at adress 4A50F54E in module MVRSETTINGS.DLL Read of adress 06FFFFFC. This has ben happening since v0.59 and changing settings dosn't seem to do anything.
Ouch. Is that 100% reproducable? Are the addresses always the same? This problem started with v0.59? So it does definitely not occur with v0.58?

[madshi]

I think further madvr version had better select most matchable display modes automatically just like reclock while playback,no need to type a series of digital manually in display modes box instead.Because many fans don't know how to type these digital in display modes box,I wonder if author(madshi) of madvr is thinking it over
The current version of the madVR display mode changer is only a first simple and stupid version. I've always said that. If you don't like, don't use it. There'll be an improved version in a future madVR version.

so is there a way to get smooth playback on 60hz monitors???
Currently no. But probably yes, with a future madVR version. That will take some time, though.

Entering 1080p60 in custom display switching in MadVR results in two instances of madHcCtrl in Task Manager.
That isn't a bug, if you're using the automatic refresh rate changer. madVR loads a helper instance of madHcCtrl which has the duty to restore the original display mode after the media player closed down. Since madVR is already gone at that time, madVR can't restore the original display mode. So madVR starts an extra madHcCtrl instance and tells it to restore the original display mode at that moment when the media player is closed. The additional madHcCtrl instance sits idle doing nothing but waiting for the media player to close. So no performance problem.

madshi, I have 1080i59, 1080p23, and 1080p50 in that order, in the auto rate change options. When I play a 59/60p video, madVR switches to the 23p option. Is it supposed to work that way? I'd rather have it switch to 1080i59. I don't have 1080p59 in the options cause I'd rather have the 29.97 fps videos play at 1080i59, and if I have 1080p59 there, 1080i gets ignored in its favor.
No, that's not how it's supposed to be. What happens if you only put 1080i59 in the auto rate change option? Does madVR switch to 1080i59 then? I rather guess that for some reason switching to 1080i59 doesn't work. Not sure why. Maybe Windows itself doesn't like it. Are you sure that this mode actually exists in your GPU display mode list?

I use the latest version (madVR v0.61) and I have some errors "updating vertex buffer failed" during playback.

Here's the log file: madVR log (http://www.megaupload.com/?d=8USXIBDR)

I didn't find anything useful in the previous posts, is there something to do on my side?
Weird. How much RAM does your GPU have? Is it possible that you're running out of RAM? Not sure what else it could be...

Anyway to autoset frequency to 50hz for 24/23p videos in madVR?
Maybe. Depends on what other refresh rates combinations you want with which movie frame rates. Give us a full list, then we can tell you if it's possible to do with the current madVR solution.

Since I've started using MadVR with MPC-HC, I have not been able to get the auto refresh rate changer to work, no matter what I do. My display will support 24HZ, but it stays on 60HZ for all my MKV's. Attempt to force it by renaming a file to "movie" p24.mkv won't work either. I can force 24HZ refresh using the rate changer in MPC-HC, but this creates the famous green bar/color distortions in MPC-HC. Any suggestions how I can troubleshoot the madvr rate changer? I'd love to get this working.
You have to enter the proper modes into the madVR settings dialog. These modes must actually exist. You can't just list modes you'd like to have. You must be able to manually activate those modes via the Windows control panels. Only then madVR can also automatically activate them.

I realized for the refresh rate feature to work, the option "use a separate device for presentation" in the general Madvr settings must be enabled.
No, the "use a separate device for presentation" option has nothing to do with the refresh rate feature.

I'm still getting a green bar and distorted colors in MPC-HC when refresh switches to 24HZ.
Try using a different decoder. Maybe that helps?

MadShi: i got a homemade 2:35:1 masking system and i use it on the lower part of my 16:9 screen and i would really like to see your seekbar to stay inside of the movie even when i resize 2:35:1 to 16:9 (ffdshow move blackbar to the lower part of the screen) would this be possible?? it would really mean alot to me :)
Properly supporting special projection setups is on my to do list (I have a CIH projection setup myself). I don't know if I will be able to comfortably support your special setup, though. Maybe yes, maybe no, can't say.

Hi Madshi could you add hermite scaling (i.e. bicubic with b and c at 0, something like this http://svn.int64.org/viewvc/int64/resamplehq/doc/kernels.html) to the scaling option of madvr please?
Why? Do you have sample images which show that it works better than the other resamplers in madVR? I'm a bit hesitant adding many more options. Don't want to make the settings dialog too complicated. So there better be a good reason to add a new filter, even if it's easy to implement (like this).

That said, there doesn't seem to be any measure of aliasing, and sharpness is very low.
Exactly. That website doesn't mention/measure aliasing at all, and it's a very important aspect of resampling.

Oh and there is a great example of why scaling should be done in linear light
That mostly applies to DOWNscaling, though. I'm not sure if linear light scaling brings much benefit for UPscaling, which is what most madVR users do.

What do you think about the "Magic Kernel" ?
I've double checked that Lanczos image on that website and found that it was produced with a broken Lanczos implementation. A proper Lanczos implementation (like the one in madVR) easily beats that "Magic Kernel", IMHO.

Since 0.61 a horizontal black or coloured (usually green) horizontal line appears after some time. It is about one pixel wide and stretches the entire width of the screen. I have also experienced a similar vertical line, and one time both at the same time. The line is only there in exclusive mode. The line disappears for some time after pausing or toggling between windowed and exclusive modes.
Things like this are often a result of a decoder <-> renderer miscommunication. Which decoder are you using? Try a different one. The MPC-HC internal decoders are especially notorious for making problems, in my experience.

I always assumed that "hardware decoding" is preferable, if not necessary, to achieve optimum viewing.
Glad you found the way to software decoding. Personally, I prefer it over hardware decoding.

anyways, there's one feature that would really rock: YV16/YV24 support :)
Funny. I've recently added YV16/YV24 support, and support for loads of other FourCC formats, too.

What I understood is that LaTo is stacking MSB/LSB 16bit into YV16/YV24...
Huh? YV16/YV24 are both strictly 8bit formats. There are several 16bit FourCC formats available, though, which the next madVR build will support.

Anyway, it would be great if we could find a "hack" that everyone would follow, so we could get >8bit post-processing in ffdshow.
Why implementing a hack if there's a proper solution available? Makes no sense to me.

The good thing about this hack is that it can use the existing avisynth infrastructure normaly (with some avs2yuv effort you can even encode it in x264) without causing any new problems, it is purely filter/function-side solution (thus can be dropped later).

Naturaly, real 16bit colorspaces in avisynth would be better, but avisynth developers are busy enough and the development is slow already - 2.6 still isn't done after several years.

So... real 16bit needs rewrite of filters AND avisynth, this hack only needs rewrite of filters. Some of them are already available, and as long as plugin authors are willing, it can take off, because no messing with avisynth core is needed. (And modifying those plugins for non-hacky core 16bit probably won't be hard one day). Imho, for an "ugly hack", this has a beauty of its own.
I understand that this "hack" is a good thing for internal avisynth use. However, avisynth by itself does not output to DirectShow. IMHO, avisynth filters should use this hack (if there's no better way), but at the very end of the avisynth filter chain, before the data is fed into the DirectShow chain, the hacked data format should be converted to a proper 16bit FourCC. DirectShow supports proper 16bit formats, so it would be very easy to implement.

A full 16bit video pipeline, ouuuuh I like the sound of that :cool:
No problem at all. Just find someone who makes ffdshow accept that hacked YV16/24 data from avisynth and convert it to a proper 16bit format. That solution would work right away with the next madVR version.

I don't really feel like supporting a hacked data format in madVR. And honestly, I see no benefit of doing that. ffdshow does not output YV16/24 now, so you need to find someone to improve ffdshow, anyway. Instead of making your buddy add YV16/24 output support to ffdshow, make him convert the hacked YV16/24 data to a proper 16bit FourCC format. This should be *really* easy to do and then we'd have a proper ffdshow version with a proper and documented 16bit output, which would work perfectly fine with the next madVR version.

[SamuriHL]

madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?

[Thunderbolt8]

Currently no. But probably yes, with a future madVR version. That will take some time, though.that would be awesome, because im also stuck at 60Hz displays.

[madshi]

madshi, are there any commercial decoders out there that support proper 16bit FourCC that will work with the next version of madVR?
I'm not aware of any, unfortunately. There are some high bit professional solutions, though. E.g. Video Editors with DirectShow interfaces or something like that. Also AVI and QuickTime movie files support high bitdepth uncompressed video storage. E.g. the samples from the following thread will play with full 10bit with LAV Splitter and the next madVR version:

http://forum.doom9.org/showthread.php?t=158836

Anyway, I don't like the Hen and Egg problem, so madVR comes first with full 10bit and 16bit support and with 4:2:0, 4:2:2 and 4:4:4 support. Hopefully decoders will follow. But of course for decoders it makes sense only if the encoded video stream is really native > 8bit or > 4:2:0.

[madshi]

madVR v0.62 released

http://madshi.net/madVR.zip

* added display "properties", "calibration" and "color & gamma" settings pages
* added option to define the native display bitdepth (affects dither strength)
* added options to define how the display was calibrated (gamut + gamma)
* moved "Video/PC levels" option to display "properties" settings page
* added options to define which gamma / transfer function to use
* replaced old "use 3dlut" option with new controls on "calibration" page
* added integrated GUI for yCMS 3dlut creation, no more console hacking needed
* added "please wait" dialog while yCMS is downloaded + installed
* added "please wait" dialog while 3dlut file is created
* added support for 6 and 7 bit 3dlut files (see trade quality for performance)
* added option to choose a manually created external 3dlut file (per display)
* there's only one 3dlut file per display now
* 3dlut is now always yRGB / RGB_Video input and RGB_Video output
* YCbCr -> RGB conversion is now always done by shader math, not by 3dlut
* Video/PC levels conversion is now always done by shader math, not by 3dlut
* rewritten rendering and pixel shader chain
* subsampled YCbCr is now upsampled & converted to RGB first, then scaled
* chroma upsampling got quite a bit faster (because it's now always exactly 2x)
* luma scaling got a tiny bit faster, depending on scaling factor and taps
* Strg+Alt+Shift+C displays & toggles color format (BT.709 -> BT.601 -> PAL)
* Strg+Alt+Shift+G displays and increases the Gamma value (2.20 -> 2.25 -> ...)
* Strg+Alt+Shift+F displays and decreases the Gamma value (2.20 -> 2.15 -> ...)
* Strg+Alt+Shift+T displays and changes the Gamma curve type (pure power / BT)
* dither is using a texture again instead of shader math
* dither is now colored and differs for every video frame
* added support for 8 bit 4:2:0 media types IYUV, I420, NV21, ICM*
* added support for 8 bit 4:2:2 media types YUY2, YVYU, UYVY, YV16, yuv2, ...
* added support for 8 bit 4:4:4 media types AYUV, YV24, I444, v308, v408
* added support for 8 bit RGB media types RGB32, RGB24, BGRA, ABGR, RGBA
* added support for 10 bit 4:2:2 media types P210, Y210, v210
* added support for 10 bit 4:4:4 media types Y410, v410
* added support for 16 bit 4:2:2 media types P216, Y216, v216
* added support for 16 bit 4:4:4 media types Y416, v416
* added support for 16 bit RGB media types RGB48, RGB64, b48r, b64a, ...
* added hints to "install.bat" and "readme.txt" to not delete the madVR folder
* fixed: madVR rendering window in GraphEdit didn't have correct size
* changed VSync priority back to "time critical"
* slightly changed tray icon mouse click behaviour
A couple of notes:

(1) Since a lot of stuff has changed internally, expect some new bugs.

(2) Some pixel shaders got a bit faster, but I've added a couple more processing steps. Not sure what the net effect will be. Maybe v0.62 will perform a little bit faster or slower for you, depending on settings.

(3) cyberbeing: Please check whether the 3dlut stuttering you have with out-of-gamut colors is gone when using a 7bit or 6bit 3dlut.

(4) 6233638: It was you who preferred Bicubic for chroma upscaling, correct? Please recheck your preferences with v0.62.

(5) Please note that madVR now accepts 4:2:2 connections. It is now *your* duty to make sure the decoder outputs the optimal format (which is usually 4:2:0).

(6) Below is the full list of FourCCs supported by v0.62. I'm looking for samples of AVI/QuickTime movie files with raw video data in as many of these FourCCs as possible, so I can test that my implementation of these FourCCs is correct. So if you have (or can create) any samples that could help, please upload (small) samples. Thanks!

// 8bit YCbCr
// 4:2:0
YV12
NV12
yv12
nv12
ICM1
ICM2
ICM3
ICM4
NV21
IYUV
I420
// 4:2:2
YUY2
yuy2
YVYU
UYVY
uyvy
cyuv
UYNV
UYNY
HDYC
uyv1
2Vu1
VDTZ
YUV2
yuv2
2vuy
2Vuy
yuvu
yuvs
YV16
I422
Y422
V422
Y42B
P422
YUNV
VYUY
AVUI
// 4:4:4
AYUV
YV24
I444
v308
v408

// RGB
// 8bit
RGB24
RGB32
24BG
BGRA
ABGR
RGBA
// 16bit
RGB48LE
RGB48BE
b48r
RGBA64LE
RGBA64BE
b64a

// 10bit YCbCr
// 4:2:0
P010
// 4:2:2
P210
Y210
v210
// 4:4:4
Y410
v410

// 16bit YCbCr
// 4:2:0
P016
// 4:2:2
P216
Y216
v216
// 4:4:4
Y416
v416

[SamuriHL]

I'm not aware of any, unfortunately. There are some high bit professional solutions, though. E.g. Video Editors with DirectShow interfaces or something like that. Also AVI and QuickTime movie files support high bitdepth uncompressed video storage. E.g. the samples from the following thread will play with full 10bit with LAV Splitter and the next madVR version:

http://forum.doom9.org/showthread.php?t=158836

Anyway, I don't like the Hen and Egg problem, so madVR comes first with full 10bit and 16bit support and with 4:2:0, 4:2:2 and 4:4:4 support. Hopefully decoders will follow. But of course for decoders it makes sense only if the encoded video stream is really native > 8bit or > 4:2:0.

Fascinating. Well, hopefully someday we'll get a decent, supported video decoder. :) This is a step in the right direction, though!

[Thunderbolt8]

(5) Please note that madVR now accepts 4:2:2 connections. It is now *your* duty to make sure the decoder outputs the optimal format (which is usually 4:2:0)so when watching remuxed BDs with coreavc, anything I need to change in coreavc settings now?

[SamuriHL]

Holy crap, madshi! That's an incredibly awesome changelist! And the hilarious part is I JUST TODAY started messing with 3DLUT, so, this is a very timely change! Thank you for this release! I won't get to test it until a bit later today, but, I am SERIOUSLY looking forward to it!

[madshi]

so when watching remuxed BDs with coreavc, anything I need to change in coreavc settings now?
Just make sure you have NV12 or YV12 (doesn't matter which) at the top of the list in the CoreAVC settings.

Holy crap, madshi! That's an incredibly awesome changelist! And the hilarious part is I JUST TODAY started messing with 3DLUT
:)

[nevcairiel]

Fascinating. Well, hopefully someday we'll get a decent, supported video decoder. :) This is a step in the right direction, though!

First we would need material thats actually encoded like this. 99.9% of all content is 8 bit these days.

[SamuriHL]

First we would need material thats actually encoded like this. 99.9% of all content is 8 bit these days.

Fair enough. :)

[Thunderbolt8]

how exactly does the 3dlut stuff now work? in general for the default HD and SD settings and in case of special 3dlut setting? e.g. when I clicked "calibrate this display by using an external 3dlut file" and I hinted at my HD 3dlut I created for japanese movie with black level correction, then eac3to tells me "this 3dlut file does not match the input format required by madVR" Im confused :S

[robpdotcom]

:eek: Madvr just went way over my head.

I'm almost too scared to install it.:scared:

[SamuriHL]

:eek: Madvr just went way over my head.

I'm almost too scared to install it.:scared:

I thought the same thing until I started reading about 3DLUT this morning and took a chance. It's nuts man! Come on, you wanna try it. You know you do. :D

[robpdotcom]

Oh yeah, of course I will. I'm just going to have to do a lot of researching if I ever want to take full advantage. Any tips on where to start?

[madshi]

how exactly does the 3dlut stuff now work? in general for the default HD and SD settings and in case of special 3dlut setting? e.g. when I clicked "calibrate this display by using an external 3dlut file" and I hinted at my HD 3dlut I created for japanese movie with black level correction, then eac3to tells me "this 3dlut file does not match the input format required by madVR" Im confused :S
Since you have special settings I'd suggest that you post your current 3dlut script in the yCMS thread and ask there how to make it work for madVR v0.62.

[SamuriHL]

Oh yeah, of course I will. I'm just going to have to do a lot of researching if I ever want to take full advantage. Any tips on where to start?

I sent you some info. :)

[madshi]

Oh yeah, of course I will. I'm just going to have to do a lot of researching if I ever want to take full advantage. Any tips on where to start?
In order to make proper use of the 3dlut functionality, you need to have your own meter to measure your display. If you don't have your own meter, then simply forget about all the 3dlut stuff and use madVR the same way you did yesterday.

[robpdotcom]

Gotcha. So, there's no new settings that you could use your own eyes, test patterns, etc. to improve image quality?

[madshi]

Actually there is. If you know how your display is calibrated, you can tell madVR about that in the display "properties" page. If you don't know how your display is calibrated, you can still play with those settings by using test patterns etc to find out which settings give you the most natural image. This way you can find out by try-and-error which calibration settings are probably nearest to how your display behaves. Be careful with this, though. If you change the settings to make one specific movie look good, maybe another movie will look twice as bad. So better use official calibration discs for playing around.

[fairchild]

I messed around with 3dlut for a bit since I own an i1Display2 LT and calibrated my plasma with colorHCFR, but since my meter is not the most accurate and the values/readings can vary a bit, I figured the benefit will not be that worthwhile in my case. The main reason I wanted to use it was for gamma boost, since my display has no gamma adjustment options and with yCMS I could boost the gamma closer to 2.22 from my sets 1.87

So basically with the new changes we only need to setup an hd 3dlut file and that will handle both the SD and HD conversions? For reference this is what my hd video levels config file looks like:

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using Video Levels (Black: 16 and White: 235)

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

# Gamut correction
Gamut_Measurements 2
20.027979 10.081485 0.193883
14.474010 29.748291 4.547331
8.679354 3.789106 45.662949
46.452229 48.580326 53.924377

# Grayscale correction
Grayscale_Measurements
20 2 3.462944 3.599591 4.022943
30 2 7.876838 8.235306 9.060005
40 2 13.712026 14.348957 15.907791
50 2 20.936159 22.056358 24.313534
60 2 30.698059 32.212700 35.946526
70 2 41.455574 43.527546 47.894981
80 2 52.848282 55.227596 61.580605
90 2 66.838257 70.423340 77.381279
100 2 80.136276 83.712715 92.825027

# Gamma correction Gamma_Curve 0.0 2.22 (has the most black crush 1.0 curve has almost no black crush)
Gamma_Curve 0.0 2.22

[Plutotype]

Hi madshi,

Thanks for incredible progress on madVR. Just a quick question to the properties page for the display devices:
- if my display is 16.7 million (6-bit + AFRC), then 8-bit should be chosen?
- display calibration. Gamut BT.709(HD), looks like a default
- display calibration. Gamma / transfer function - pure power curve / 2.20? Is this again a default setting ( correct setting )?
- color and gamma. Desired pure power curve / 2.20? Default?

Thanks
Pluto

[noee]

Some quick notes...

Performance on my trusty old HD2600XT is excellent so far (no 3DLuts yet). Testing on a 5670 next...
For some reason, my SD rips look better, even my wife noticed!
Seems like a very solid build so far

Two bugs from before...
- dual mon, playback on second mon, if I drag the mouse down to the bottom on the first mon, the seek bar shows
- dual mon, playback on second mon, Windows Key takes madVR out of FSE.

[leeperry]

No problem at all. Just find someone who makes ffdshow accept that hacked YV16/24 data from avisynth and convert it to a proper 16bit format. That solution would work right away with the next madVR version.
righty, sounds like a plan!

madVR v0.62 released
OMG, the changes list is giving headaches :D

I'll run many tests again, but I'm afraid to really need that "upload frames in render thread" option on my XPSP3/8800GS combo :o

leepery, you must be the only who uses a crt display
surely....me and pretty much all the bluray mastering houses that is: http://www.avsforum.com/avs-vb/showthread.php?p=14066458#post14066458

SmoothL() will prolly make an improvement on any true 8bit display as well, just not 6bit dithered(like all those cheapo LCD displays).

The day LCD will provide infinite native contrast ratio(my Eye One calibrations on LG Flatron CRT's -the most advanced consumer flat CRT's- usually state 300000:1 native CR), I'll be happy to finally upgrade. There's a french website that ran benchmarks on some forthcoming new models from LG(here (http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.lesnumeriques.com%2Flg-47lex8-p303_10129_35.html) and there (http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.lesnumeriques.com%2Flg-55lx9500-p303_10320_35.html)), it seems that this day will finally occur soon...but these models will be scarily expensive, so I'll give it another year or two to settle down.

The latest offerings from SONY carry 4000:1 native CR (http://translate.google.com/translate?u=http%3A%2F%2Fwww.lesnumeriques.com%2Fsynthese-evolution-taux-contraste-mesures-tv-lcd-6-ans-article-1177.html&sl=fr&tl=en&hl=en&ie=UTF-8)(no bs dynamic CR, and dead smooth 24p too). That'll be my next upgrade path I think, waiting from those killer LG's to become affordable.

[madshi]

Gamut Correction

madVR v0.62 now by default applies gamut correction. What's that? And why does madVR do that?

Let's talk about playing back NTSC DVDs (SD) on a newer display/projector. Newer displays/projectors are usually calibrated to show HD content as well as possible. Practically that means they're usually calibrated to the BT.709 standard. However, and here comes the catch: NTSC DVDs are intended to be shown on displays that were calibrated to BT.601! So if you watch DVDs on a BT.709 display, you will not get accurate colors. The difference isn't night and day, but in a direct comparison, it's visible.

madVR v0.62 now let's you specify what color standard your display was calibrated to (default is BT.709, leave it at that if you're not sure). If you play back NTSC or PAL content, madVR v0.62 will then automagically convert your video so that it plays with perfect colors on your display. This works even if you don't use 3dluts.

[noee]

I'm getting a crash with MC16. It is reproducible, but I think it might be jRiver's issue....

DUal mon
Play movie on second mon, using the Windows Task bar, using the MC icon hover control, stop the movie.
MC crashes in module madVR_unload

Can't get MPC-HC working right now, will try with it too.

[robpdotcom]

Actually there is. If you know how your display is calibrated, you can tell madVR about that in the display "properties" page. If you don't know how your display is calibrated, you can still play with those settings by using test patterns etc to find out which settings give you the most natural image. This way you can find out by try-and-error which calibration settings are probably nearest to how your display behaves. Be careful with this, though. If you change the settings to make one specific movie look good, maybe another movie will look twice as bad. So better use official calibration discs for playing around.

It's really about time I get my display calibrated, so maybe this will press me to get that done.

BTW, something I've been wanting to ask:

I recently started using an HTPC on my 1280x720 plasma in the bedroom, and was wondering if someone could recommend an algorithm for luma downscaling? I know everyone has their own preferences, but I'm just not sure where to start.