madVR - high quality video renderer (GPU assisted)

[leeperry]

It doesn't? Nobody told me about that yet. FWIW, when I press ESC in PotPlayer, it just goes back to windowed mode, while KMP (with default settings) hides in the tray.
I've set the windows minimizing hotkey on one of my mouse buttons. When I invoke it while running PotP in FSE, I have PotP both in the tasktray and in the taskbar...as PotP did minimize but mVR didn't know about it. I click on either PotP icons and I'm back in FSE...I guess it couldn't get any better anyway.
the next build will come really soon, but in contrast to my original plans, it will be a bugfix only release.
you know what features I'd love to see(601/709 auto-detection off ffdshow, discrete LUT's opened automatically depending on the device -w/ different gamuts and 601/709 for each of them, so that's 6 LUT's per display-, possibly LUT compression to speed up the loading process) but I know that you know and you know that I know that you know, so I would never dare repeating myself once more http://forum-images.hardware.fr/images/perso/3/henri%20gaud-chiste.gif
This said, we're all very eager to try 0.35. Thanks for your hard work http://forum-images.hardware.fr/images/perso/the%20bloodhound%20gang.gif

[kostik]

[QUOTE=leeperry;1467122]it doesn't deband per se, it prevents additional banding, as LaTo explained here (http://forum.doom9.org/showpost.php?p=1405673&postcount=10) about his own SmoothLevels() script.

I keep mentioning his script because it looks eye popping through mVR, I posted some comparisons here (http://forum.doom9.org/showpost.php?p=1454344&postcount=96).

What Avisynth scripts are you using? can you copy it here? really would like to see how it looks !
Thanks

[THX-UltraII]

i m using the latest ffdshow, mpc-hc and madvr build. my subtitles flicker. what could cause this?

[pirlouy]

If you use MPC-HC subtitles, I'd say MPC-HC.
If you use ffdshow subtitles, I'd say ffdshow,
...vobsub... then vobsub.
etc.

Don't thank me. :-)

[THX-UltraII]

If you use MPC-HC subtitles, I'd say MPC-HC.
If you use ffdshow subtitles, I'd say ffdshow,
...vobsub... then vobsub.
etc.

Don't thank me. :-)

im using ffdshow subtitles

[madshi]

i m using the latest ffdshow, mpc-hc and madvr build. my subtitles flicker. what could cause this?
I've no idea.

[jmone]

Madshi - thanks for contacting the JR Media Center Devs - there are a bunch of us keen to use madVR in their DirectShow playback engine.

[pirlouy]

im using ffdshow subtitles
Disable all post-processing in ffdshow.
Maybe you have a filter who doubles framerate and is not compatible with subtitles.

[leeperry]

What Avisynth scripts are you using? can you copy it here? really would like to see how it looks
SmoothLevels(preset="tv2pc",Smode=0)

[szabi]

Depends on your card you may not have it, but if you are using the new CCC with the 10.12 drivers. While in Advanced View, on the left side you click on My Digitial Flat-Panels, under that there should be Properties (Digital Flat-Panels), Display Color (Digital Flat-Panel), HDTV Support (Digital Flat-Panels), LCD Overdrive (Digital Flat-Panels), Scaling Options (Digital Flat-Panels), and finally Pixel Format

I really does not have this function.

http://www.abload.de/thumb/ccc_no_pixel_formatzmk1.gif (http://www.abload.de/image.php?img=ccc_no_pixel_formatzmk1.gif)

szabi

[madshi]

I have a possible bug report for you. I love the implementation of separate devices with different settings, but I can't get this to work properly for me.
This should be fixed in the next build.

[DigitalLF]

madshi: i got a weird freeze lag then after 15-30 sec it fast forwards a bit then back to normal... has this been reported?

[madshi]

madshi: i got a weird freeze lag then after 15-30 sec it fast forwards a bit then back to normal... has this been reported?
Did this happen just once? Or does it happen now and then? Or does it happen all the time?

Please try with v0.35.

[madshi]

madVR v0.35 released

http://madshi.net/madVR.zip

* reverted back to v0.32 clock logic (not more clock jitter removal)
* fixed: ESC (= pause + minimize) in KMPlayer in exclusive mode -> freeze
* fixed: multi monitor device management didn't fully work
* maybe fixed: problem with ZP + MKV splitter + exclusive mode + playlist
* added logging to gather more info about one instance of madVR freezing
Please note that this is just a bugfix release. The new features I originally planned for v0.35 have had to be postponed to a future release.

[DigitalLF]

madshi: in a month i would say around 100 times... i will try 0.35 and come back to you if that helps me...

[fairchild]

This should be fixed in the next build.

Yep, this is working perfectly now! Thanks a bunch. :thanks:

[kostik]

Thanks MADSHI!!! I have been using Madvr since the beginning and its great!!!
I also strongly suggest you trying the smoothlevel() script along with madvr , I also find it does a good job working together with madvr (Thanks Leepery).

[madshi]

I also strongly suggest you trying the smoothlevel() script along with madvr
What for? All the smoothlevel() script does is modifying the video levels, as far as I can see, and madVR can do that, too, in perfect quality. I don't see any advantage of using smoothlevel() with madVR, unless for some reason you need to convert the levels *before* the video is fed to madVR. Or am I missing something?

[Thunderbolt8]

madshi, I think switching between PC and video levels (via shift+ctrl+alt+y) is broken. it does say it shifts to TV levels, but then I cannot shift back to PC and it doesnt show any change in levels at all.

EDIT: actually it seems it does change the levels, but not before you restart mpc-hc. so its no on-the-fly change any more.

[leeperry]

:thanks: for the update and for my FSE miniziming cosmetic problem w/ PotP, that is now fully fixed.

What for? All the smoothlevel() script does is modifying the video levels, as far as I can see, and madVR can do that, too, in perfect quality.
I've been using LaTo's experiments on a more enjoyable TV>PC conversion ever since his first shot using a plain .AVS script(before he released this DLL) and it increases the subjective "pop effect"...together w/ GrainF3, everything seems to pop out of the screen...so much for all that 3D bs :rolleyes:

There's a lot of algorithms behind LaTo's plugin, it's not just a plain 16-235>0-255 converter w/ some dithering on top...as he says it himself:
SmoothAdjust produces a soft conversion that results in a smooth histogram.
Theses 3 plugins have a smoothing & dithering algorithm to avoid banding issue.

They fully respect the 601/709 coeffs(exactly the same colors as mVR when going TV>PC), so it's not a matter of oversaturation...they might slightly mess w/ the gamma curves, anyway it looks awesome through mVR http://forum-images.hardware.fr/images/perso/ayuluna.gif

[madshi]

madshi, I think switching between PC and video levels (via shift+ctrl+alt+y) is broken. it does say it shifts to TV levels, but then I cannot shift back to PC and it doesnt show any change in levels at all.

EDIT: actually it seems it does change the levels, but not before you restart mpc-hc. so its no on-the-fly change any more.
Yeah, there's something weird going on, I'll check this out. It's probably broken since I added the device management functionality.

I've been using LaTo's experiments on a more enjoyable TV>PC conversion
More enjoyable compared to what? Your post isn't very clear.

kostik suggested to try SmoothLevel together with madVR, and right now I don't have the slightest clue what purpose that would have, from a technical point of view.

Does SmoothLevel do something in a better quality than madVR?

[leeperry]

Does SmoothLevel do something in a better quality than madVR?
"better" is subjective, I'll come back w/ some comparison screenshots.

[fairchild]

Using that smoothlevel AviSynth script would be detremental for me since now that MadVR is able to store the levels based on device, I can send the right levels to each of my output devices and voila. If I were to use that script, then obviously I'd be stuck using just one. (don't know if you can setup some advanced script to toggle based on the device, but I'm not that advanced)

MadVR sending 0-255 to my LCD PC monitor
MadVR sending 16-235 to my Plasma TV

[madshi]

"better" is subjective, I'll come back w/ some comparison screenshots.
You still haven't answered any of my questions in any way that I would understand... :( Is it so hard for you to explain in simple words what SmoothLevels does, in which situation it makes sense to use it (in your opinion) and whether it beats madVR in any areas? I'll ignore the whole SmoothLevels topic from now on, unless somebody tries to actually explain what it's all about. Right now I've no idea at all.

[leeperry]

You still haven't answered any of my questions in any way that I would understand... :( Is it so hard for you to explain in simple words what SmoothLevels does, in which situation it makes sense to use it (in your opinion) and whether it beats madVR in any areas? I'll ignore the whole SmoothLevels topic from now on, unless somebody tries to actually explain what it's all about. Right now I've no idea at all.
Yeah, sorry for that! There used to be a lot of explanations in the OP of that thread (http://forum.doom9.org/showthread.php?t=137479), but they've disappeared when LaTo's moved from the .AVS script to the plugin version.

This all goes way above my head, and I'm just an end-user...at the end of the day I crave for the best PQ I can get, and atm that's: SmoothL > LSF > GrainF3 > mVR.

It boils down to providing a "smooth histogram", whichever way it's done..I like it http://forum.slysoft.com/images/smilies/agreed.gif

I've helped LaTo finetuning the latest versions of SmoothL so the saturation would abide by the 601/709 coeffs, as the older versions were slightly oversaturated. So it doesn't mess w/ the saturations, I will try to use a gray levels test pattern..it might very well mess w/ the gamma curves. And it adds dithering, which has the side-effect of deblocking and debanding. Maybe a dither parameter in mVR would be desirable? I've played w/ the dithering parameter in SmoothL but my fav. is the default one(50)...that'd be really sweet to be able to finetune it in mVR as well :devil:

And I use SmoothL() instead of the nasty looking colorYUV(levels="tv->pc"), so it'd take some comparisons shots against mVR...I've never said that it looked "better" than mVR, I've only compared it to colorYUV() so far.

I've also compared the different versions of LaTo's scripts/plugins, they've all been an improvement over the other as far as the highly sought after "pop effect" was concerned.

LaTo said that the way his plugin worked was more or less explained in this thread (http://forum.doom9.org/showthread.php?t=79898). Maybe that'd give some clue as to wth happens: http://forum.doom9.org/showpost.php?p=528197&postcount=14
Ylevels simply blends the normal gamma curve, weightened with the inverse of the input's brightness. The result is similar to this

But maybe it's all placebo in SmoothL, reason why I said I'd come back w/ some comparison shots.

Using that smoothlevel AviSynth script would be detremental for me
then don't use it :p

[fairchild]

then don't use it :p

Don't worry, I'm not. I too strive for the best PQ I can get, so I tried it out, then discovered it had that drawback in my setup. :devil:

[leeperry]

Ah well, some simple rec709 colorimetry/gray levels don't pickup a single diff. between ColorYUV/mVR/SmoothL...I will have to resort to more demanding test patterns. I'm colorblind so w/o a colorimeter I'm rather hopeless anyway :p

it seems it does change the levels, but not before you restart mpc-hc. so its no on-the-fly change any more.
confirmed.

[madshi]

...at the end of the day I crave for the best PQ I can get, and atm that's: SmoothL > LSF > GrainF3 > mVR.
Yeah, but that doesn't help much because all I'm interested in right now is whether there's anything in SmoothLevel that duplicates some of madVR's processing with "better" quality. After all, madVR aims to do everything in best possible quality.

It boils down to providing a "smooth histogram", whichever way it's done..
I don't understand what that means. Is it an automatic image adjustment, based on analyzing the histogram of every frame and doing adjustments frame-by-frame in order to optimize the histogram? If so, it would work like some kind of auto image correction. I usually hate such algorithms because they rarely are clever enough to handle all situations well. They work great in some cases and screw up in others.

I've helped LaTo finetuning the latest versions of SmoothL so the saturation would abide by the 601/709 coeffs, as the older versions were slightly oversaturated. So it doesn't mess w/ the saturations, I will try to use a gray levels test pattern..it might very well mess w/ the gamma curves. And it adds dithering, which has the side-effect of deblocking and debanding. Maybe a dither parameter in mVR would be desirable? I've played w/ the dithering parameter in SmoothL but my fav. is the default one(50)...that'd be really sweet to be able to finetune it in mVR as well :devil:
I don't understand. In one of the posts you linked to earlier, LaTo explicitly stated that SmoothLevel would *NOT* remove banding from the source, but that it would just avoid adding more banding. Well, that's exactly what madVR does. Adding any less dither than madVR adds would result in banding. Adding any more dither would mostly just increase the noise level. Fixing source banding ("deband") is a totally different thing and a completely separate algorithm on its own, which is not something SmoothLevel does, according to LaTo.

And I use SmoothL() instead of the nasty looking colorYUV(levels="tv->pc"), so it'd take some comparisons shots against mVR...I've never said that it looked "better" than mVR, I've only compared it to colorYUV() so far.
So you advertize funny scripts in this thread, because they look better to you than some other funny scripts. But you haven't even compared any of them to madVR's own processing. Tell me, how can you advertize scripts in the madVR thread, if you don't even know if the scripts are better than what madVR does? :(

LaTo said that the way his plugin worked was more or less explained in this thread (http://forum.doom9.org/showthread.php?t=79898).
These are gamma curve adjustments, and don't have much to do with TV -> PC level conversion! Gamma tweaks are currently not supported by madVR, but that might change sooner or later.

[leeperry]

I don't understand what that means. Is it an automatic image adjustment, based on analyzing the histogram of every frame and doing adjustments frame-by-frame in order to optimize the histogram? If so, it would work like some kind of auto image correction. I usually hate such algorithms because they rarely are clever enough to handle all situations well. They work great in some cases and screw up in others.
Only LaTo knows what happens in his script, but as far as I can tell there's no dynamic adaptation...I hate it when the picture "pumps" all of a sudden.

In one of the posts you linked to earlier, LaTo explicitly stated that SmoothLevel would *NOT* remove banding from the source, but that it would just avoid adding more banding. Well, that's exactly what madVR does. Adding any less dither than madVR adds would result in banding. Adding any more dither would mostly just increase the noise level. Fixing source banding ("deband") is a totally different thing and a completely separate algorithm on its own, which is not something SmoothLevel does, according to LaTo.
yes, it smoothes the levels conversion..it doesn't "deband" per se.

Tell me, how can you advertize scripts in the madVR thread, if you don't even know if the scripts are better than what madVR does?
That's because I get a good percentage on sales :p

Well, this thread is about bug reports and success stories w/ mVR...As an end-user, I just said that this script adds dithering, smoothes the picture when using LSF and that I love how it looks...nothing more. kostik tried it and said he liked it too, maybe I'm not that crazy after all.

I still rest my case that it would be great if you'd let us finetune the amount of dithering in mVR. mVR adds dithering to smooth the 16>8bit downscale, but SmoothL() adds dithering to smooth the TV>PC conversion. I'm not the mad scientist here, and benchmarking dithering doesn't look too easy. I usually only run tests on colorimetry, and SmoothL passes 601/709 untouched.

You can see those real-world comparisons (http://forum.doom9.org/showpost.php?p=1454344&postcount=96) I made, both dithering passes together look better to my eyes on a CRT. The key is to finetune the dithering IMHO, as all displays react differently...you can read many ppl whining that some BD's are too grainy, that's usually because their LCD panel already uses heavy dithering IMHO. Some panels even dither to 6bit FWIR.

There's no one-size-fits-all figure to dithering, and I can attest that changing the dithering figure in SmoothL changes the subjective "pop effect"...it's all about finding the right balance between banding/deblocking and the right figure to match mVR's built-in dithering *depending on your display*. The human eye is a very poor measuring tool, and it's all about finding the figures that together will provide the most subjectively "best" PQ to the viewer.

[6233638]

I will never understand why people feel that they need to run all these various 'enhancements' in ffdshow/avisynth in addition to madVR. madVR displays what is stored on the disc as accurately as possible. Any additional processing you do on top of that is moving the image further away from how it was intended to look.

A histogram should not be 'smooth'. You want to avoid introducing banding when doing levels conversions but I am confident that madVR is doing it with enough precision to avoid that as much as possible. How much precision is this avisynth script using?

Madshi, thanks for the update. Everything seems good in 0.35 so far.

[leeperry]

yeah, I wonder why ppl use LSF at all. Maybe because it sharpens the motion blur and gives a sharper picture w/o any ill effect. I like my picture sharp...and grainy(which has the side effect of deblocking, and bringing back some of the cinema grain lost in the encode)...you keep watching 1:1 untouched BD if you like, it's a free world. I think LaTo said that all the computing in SmoothL runs in 32fp.

[madshi]

Only LaTo knows what happens in his script, but as far as I can tell there's no dynamic adaptation...I hate it when the picture "pumps" all of a sudden.
Then my best guess is that it's just a gamma curve adjustment, in addition to the TV->PC levels conversion, using dithering internally to avoid adding banding.

If that's the case, madVR can do most of it already in at least the same quality (maybe better). Only gamma adjustments are not supported (yet!).

I still rest my case that it would be great if you'd let us finetune the amount of dithering in mVR. mVR adds dithering to smooth the 16>8bit downscale, but SmoothL() adds dithering to smooth the TV>PC conversion.
Nope. SmoothLevel adds dithering for the very same reason madVR adds dithering. SmoothLevel *must* internally work in higher precision than 8bit, or else there would be banding, even with insane amounts of dithering. I don't see any difference between what madVR and SmoothLevel do. Exactly the same, except that SmoothLevel additionally offers gamut tweaks, which madVR does not (yet) do. I don't know in which bitdepth SmoothLevel internally works, but I doubt that it's higher than what madVR does. Adding dithering tweakability to madVR would serve no purpose. madVR adds exactly the scientifically correct amount of dithering. Adding less would be bad. Adding more would not help. If you want deblocking, use a deblocking algorithm. If you want debanding, use a debanding algorithm. Dithering is a mathematical process and it makes no sense to use any dithering strength other than what is mathematically correct, IMHO.

Everything seems good in 0.35 so far.
Glad to hear that.

[leeperry]

Yes, I like to use grain/noise to deblock and give a slight "analog" look...we all have different tastes and habits. I love grain, there's never too much of it...well except in 12 grams, that forces me to disable all my scripts :p

The "perfect" scientific figure is nice, but some(many?) LCD panels already use dithering...and sometimes the "best" PQ is not the most mathematically "accurate". I don't think that a 10bit native LCD/DLP display, a 6bit dithered LCD display and an old CRT in VGA would benefit from the very same dithering pattern in mVR. Movies are mastered on CRT's for the most part, they're not specifically meant to go through LCD panels processing/dithering.

Those test patterns can come in handy: http://thumbnails36.imagebam.com/11315/38d290113140266.jpg (http://www.imagebam.com/image/38d290113140266) http://thumbnails32.imagebam.com/11315/bb07c3113140268.jpg (http://www.imagebam.com/image/bb07c3113140268) http://thumbnails25.imagebam.com/11315/84d41b113140270.jpg (http://www.imagebam.com/image/84d41b113140270)

They look really funky in 1:1 on my CRT..they basically show the noise added by your display processing...but let's forget about it if you don't like the idea. SmoothL works in 32fp IIRC.

[cyberbeing]

Those test patterns can come in handy: http://thumbnails36.imagebam.com/11315/38d290113140266.jpg (http://www.imagebam.com/image/38d290113140266) http://thumbnails32.imagebam.com/11315/bb07c3113140268.jpg (http://www.imagebam.com/image/bb07c3113140268) http://thumbnails25.imagebam.com/11315/84d41b113140270.jpg (http://www.imagebam.com/image/84d41b113140270)

They look really funky in 1:1 on my CRT..they basically show the noise added by your display processing...

Those images are specifically created for revealing Moiré Interference. It looks funky on your CRT since all higher quality CRTs will have some degree of Moiré Interference since that it's just a limitation of CRT tech. That said, it is not 'noise added by your display processing' and such Moiré Interference usually only shows up in artificially created pixel-wide uniform patterns such as those.

[ajp_anton]

When you move the mouse to the bottom, there's like a half a second delay before the search bar shows up.The reason for that is that madVR is prerendering the frames to fill the render queue. This is one of the tricks to make sure that smooth motion can be achieved. Now if you move the mouse to the seek bar, the seek bar is drawn immediately by madVR - but only to newly rendered frames. If your rendering queue is full, there are still 8 prerendered frames to be displayed, which don't have the seekbar visible. Of course I could dispose of all prerendered frames when you try to activate the seek bar. But if I do that, you might get some stuttering instead.How do I reduce the render queue?
And what is backbuffer queue? It doesn't seem to change anything in the OSD (not even the backbuffer queue line).
What does "7-8 / 8" (and "2-3 / 3" for backbuffer) mean for the queues?

[trainspotter]

Thanks for the new version and the additional level of logging, madshi!

As promised here are two logs (http://rapidshare.com/files/440078221/madVR_0.35_log.rar) using madVR 0.35.
Interestingly even after mpc-hc is shut down, the madVR logo is still in the task bar and madHcCtrl.exe is not killable. The process just disappears automatically a couple of minutes after shutting down mpc-hc (probably when some kind of timeout is reached).

Let me know if there is anything else I can do to help.

[pankov]

madVR v0.35 released

http://madshi.net/madVR.zip

* reverted back to v0.32 clock logic (not more clock jitter removal)
* fixed: ESC (= pause + minimize) in KMPlayer in exclusive mode -> freeze
* fixed: multi monitor device management didn't fully work
* maybe fixed: problem with ZP + MKV splitter + exclusive mode + playlist
* added logging to gather more info about one instance of madVR freezing
Please note that this is just a bugfix release. The new features I originally planned for v0.35 have had to be postponed to a future release.

madshi, I did try the new version and I'm sad to report that the access violation problem with ZoomPlayer is still present
:(

Well, with the debug version it was a little bit tougher to reproduce so I guess it's some sort of timing/synchronization issue (just a wild guess).

Here is a log that shows three or four jumps to the next file in the playlist and the problem appearing only at the last one.

http://www.mediafire.com/file/6lh3ht4h95a522a/madVR%20-%20log%20-%20access%20violation%20%28v0.35%29.rar

I hope you'll be able to nail it down this time.

[leeperry]

Those images are specifically created for revealing Moiré Interference.
oh sure, the first one is a moirage test pattern at 2 and 41 IRE. It's also very useful on DLP because it triggers the shades where the mirrors spin the most. But yeah, so far it's only useful on CRT/DLP...the only two technologies I care for.

The two others are specifically meant to check for 1:1 mapping and they also stress my DLP pj a great deal, there's quite a bit of noise added on top...I only posted those test patterns to backup my theory that there's no one-size-fits-all dithering strength that will look equally good on all displays. But it's a non-issue as I finetune it w/ SmoothL anyway.

[THX-UltraII]

thanks for 0.35 Madshi! Keep up the good work and thumbs up for you!

[THX-UltraII]

When looks at the posts from a few months back ago on this page http://forum.doom9.org/showthread.php?t=146228&highlight=rgb&page=188, you can read that the ATI drivers where broken back then. If I m correct the drivers 10.12 are still broken and RGB Full and Limited give me THE SAME result on my display.

So I still don t know how to get a correct result without artifacts:

i THINK I need to use RGB Limited and display on HDMI standard (not enhanced since enhanced only works if ATI fixes RGB Full).

Correct?

[Razoola]

Just to report the video freezing that was happening with 034 has not happened so far with 035 so it seems that clock logic was the cause.

[leeperry]

Just to report the video freezing that was happening with 034 has not happened so far with 035
same here.

[madshi]

The "perfect" scientific figure is nice, but some(many?) LCD panels already use dithering...and sometimes the "best" PQ is not the most mathematically "accurate". I don't think that a 10bit native LCD/DLP display, a 6bit dithered LCD display and an old CRT in VGA would benefit from the very same dithering pattern in mVR.
madVR outputs an 8bit image that is mathematically as correct as possible. For that the exactly correct amount of dithering is used. The rest is up to the display. If the displays are all working properly, then yes, a 10bit native LCD/DLP display, a 6bit dithered LCD display and an old CRT in VGA would all benefit from the very same dithering madVR pattern/strength. The only exception is if the display is only 6bit native and doesn't do proper dithering internally, then it would help if madVR increased dithering level.

BTW, gamma tweaks depend on how your display is calibrated. Ideally the calibration should apply the optimal gamma response for your room conditions. If the calibration is done properly then applying gamma tweaks to the movie via SmoothLevels should make image quality worse, not better. If applying gamma tweaks via SmoothLevels makes the image look better for you, then probably your display calibration is lacking.

At least that's how I see it right now...

Those images are specifically created for revealing Moiré Interference.
Btw, happy to see you back on the forum. Haven't see you for a while. Have you tried the latest madVR builds yet? IIRC the last time you posted exclusive mode wasn't even implemented yet! Does exclusive mode work well for you? FWIW, I've not yet implemented the final presentation logic for exclusive mode, so there's still room for improvement.

How do I reduce the render queue?
And what is backbuffer queue? It doesn't seem to change anything in the OSD (not even the backbuffer queue line).
What does "7-8 / 8" (and "2-3 / 3" for backbuffer) mean for the queues?
The size of the queues is currently fixed, maybe I'll make that adjustable in a future build. "7-8 / 8" means that since the last OSD update (it updates once per second, IIRC) the queue was always in the range 7-8 (out of 8). The backbuffer queue is a Direct3D queue for frames soon to be presented.

As promised here are two logs (http://rapidshare.com/files/440078221/madVR_0.35_log.rar) using madVR 0.35.
Interestingly even after mpc-hc is shut down, the madVR logo is still in the task bar and madHcCtrl.exe is not killable. The process just disappears automatically a couple of minutes after shutting down mpc-hc (probably when some kind of timeout is reached).
Hmmmm... The freeze occurs while madVR is trying to make itself known on the local network. madVR enumerates your network cards and sends a broadcast to all local subnets to announce its presence. Also a multicast is sent. I think the broadcasts are probably all timing out, which could be summing up to a quite high delay time. I think I should run the broadcasts on a separate thread, that should fix the delay. I'll do that in a future build.

madshi, I did try the new version and I'm sad to report that the access violation problem with ZoomPlayer is still present
:(

Well, with the debug version it was a little bit tougher to reproduce so I guess it's some sort of timing/synchronization issue (just a wild guess).

Here is a log that shows three or four jumps to the next file in the playlist and the problem appearing only at the last one.
Well, the crash appears to happen during madVR finalization. But that's about all I can see from the log. Logs aren't really too useful for crashes. Right now I don't know where the crash is coming from exactly.

If you want, I can look into this further, but I'd need from you:

(1) The MKV splitter download you're using (the exact version you're using).
(2) An explanation of how to setup ZP to make ZP use this splitter. I'm a ZP configuration noob.

When looks at the posts from a few months back ago on this page http://forum.doom9.org/showthread.php?t=146228&highlight=rgb&page=188, you can read that the ATI drivers where broken back then. If I m correct the drivers 10.12 are still broken and RGB Full and Limited give me THE SAME result on my display.

So I still don t know how to get a correct result without artifacts:

i THINK I need to use RGB Limited and display on HDMI standard (not enhanced since enhanced only works if ATI fixes RGB Full).

Correct?
You need to make ATI output RGB Full. FWIW, the Full/Limited switch doesn't seem to work on my 6850 with win7 x64, either, but I'm seemingly getting RGB Full all the time, so it's fine for me.

You can use this test image to check if you get banding artifacts:

http://madshi.net/banding.png

Show this image on your display/projector in 100% without any zooming. If the grayscale is completely smooth then you're probably safe and have probably RGB Full.

Just to report the video freezing that was happening with 034 has not happened so far with 035 so it seems that clock logic was the cause.
Great!

[THX-UltraII]

You need to make ATI output RGB Full. FWIW, the Full/Limited switch doesn't seem to work on my 6850 with win7 x64, either, but I'm seemingly getting RGB Full all the time, so it's fine for me.

You can use this test image to check if you get banding artifacts:

http://madshi.net/banding.png

Thxz Madshi,

and when I do have banding artifacts, is the clearly noticable at that moment? What do I see than?

[madshi]

If you have banding, you should see vertical bands (steps) in the gray scale. It's then simply not be perfectly smooth. If it's perfectly smooth then probably all is fine.

[THX-UltraII]

If you have banding, you should see vertical bands (steps) in the gray scale. It's then simply not be perfectly smooth. If it's perfectly smooth then probably all is fine.

ah ok, so THAT was the problem in the past when eg. a lamp was on in a dark scene in a movie. and I could clearly see 'layers'.

Haven t noticed any for some time but could be that I got used to banding.

I try the test pattern tonight.

[madshi]

ah ok, so THAT was the problem in the past when eg. a lamp was on in a dark scene in a movie. and I could clearly see 'layers'.
Well, some movies are also encoded that way. So the better way is to test with something you know is smooth by itself (like banding.png).

[yesgrey]

Hmmmm... The freeze occurs while madVR is trying to make itself known on the local network. madVR enumerates your network cards and sends a broadcast to all local subnets to announce its presence. Also a multicast is sent. I think the broadcasts are probably all timing out, which could be summing up to a quite high delay time.
Is not possible to simply add an option for disabling all that network stuff? For people that would not use any of that is a little annoying the delay caused by that...

[madshi]

Is not possible to simply add an option for disabling all that network stuff? For people that would not use any of that is a little annoying the delay caused by that...
You make it sound as if there is a delay for everybody - which is not the case. So far there is only one single person who has a delay, probably due to some OS or network configuration problem, and I'm thinking of a way to work around the problem.

There will be no option, because every additional option hurts usability.

[leeperry]

So far there is only one single person who has a delay
I also get a +1" delay(even w/ 0.35, I run XPSP3), and I've just tried to click 3 times in a row(closing the prefs window each time) and I got this: http://www.pixelz.fr/a/b/9/f435aefd673b5f74437ecfcbb0700.png

I run a software firewall, I don't allow localhost lookup and I've disabled every network thingie except TCP-IP. Want logs?
BTW, gamma tweaks depend on how your display is calibrated. Ideally the calibration should apply the optimal gamma response for your room conditions
if SmoothL were using any kind of gamma tweak, it'd show on gray levels test patterns...and it doesn't. I will try some more demanding patterns like slow white/black gradients. It seems rather obvious that it's the additional dithering that helps in my own personal case.