madVR - high quality video renderer (GPU assisted)

[Thunderbolt8]

is #9201 still the same with v2.40.3644 ?

[ForceX]

Try with Directvobsub and double rendering resolution, that'll put all your CPU cores to use. ;)

Now why would you do that? It's ridiculous to use VSFilter to upscale your video. It probably uses a simple bilinear scaler.

[THEAST]

is #9201 still the same with v2.40.3644 ?

Haven't tried that version yet, I'll try it and report back.

Now why would you do that? It's ridiculous to use VSFilter to upscale your video. It probably uses a simple bilinear scaler.

Well, yeah, you're right, it seriously screws up the video (Causes obvious pixelation/aliasing in LQ material) but there are no other choices for me. Using Softcubic 50 for all the resizers in madVR nearly counters the effect of Directvobsub's crappy upscaling, though, without blurring the hell out of the video.

[ForceX]

Well, yeah, you're right, it seriously screws up the video (Causes obvious pixelation/aliasing in LQ material) but there are no other choices for me. Using Softcubic 50 for all the resizers in madVR nearly counters the effect of Directvobsub's crappy upscaling, though, without blurring the hell out of the video.
... -_-

Is there really a reason for upscaling with that instead of madVR? I doubt it gives better quality subs than rendered at default size and upscaled with a good madVR scaler (of course softcubic will make your drawn on video subs soft, spline would be better for sharper subs). There's no point in ruining video quality for minor sub quality differences.

But if you really HAVE to do it, it's better to use FFDhow's resizer to double it. It'll let VSfilter render the subs at the higher resolution, just better scaling for the video.

[Meowth]

Is there any reason you need to use the fullscreen exclusive mode? Just disable it if you want to take a lot of screenshots. You don't need exclusive mode unless you're on XP or have Aero disabled either way.

Whether I am using full screen or not the result is always "GetDIB failed, hr = 80004005" error when I press F5.

http://i.imgur.com/uKHh3.jpg

[nevcairiel]

Use Windows' capture feature, press print-screen and paste it in paint. MPC-HCs feature is only supported by its own renderers.

[Meowth]

Again, I only have a 1680x1050 screen and and simply switching output renderers allows me to get actual 1080p screenshots.

[nevcairiel]

Again, MPC-HCs screenshot feature only works with MPC-HCs own renderers. :)

[ajp_anton]

Feature request:
Give control of how many % of the (top+bottom)/(left+right) black bars are at the top/left.
For example, when the movie is wider than the screen, "0% top" puts the movie at the top of the screen, 50% in middle, 100% at bottom.

[Chipmonkey]

Why this forum requires new registered user to wait for FIVE days before posting? I almost forgot what I wanted to say here.

Anyway, I have been using madvr since 0.13. After 0.43 , theres always this bug in my kmplayer that whenever i stretch full screen Ctrl+Enter any newly opened video (1st time opening after each computer boot), the kmplayer will always hang and non-responding. After I terminate the kmplayer process and reopen the video and full screen, there will be tearings on the video while stretching to full screen. 0.43 and before had no such problem, everything was smooth.

[Chipmonkey]

sorry for double post, maybe its just me, i feel 0.43 graphics is better than current version if just using yv12 for all videos as in it looks slightly brighter and clearer. i know 0.73 supports rgb32, but thats different story since yv12 is incomparable to rgb32.

[leeperry]

Why this forum requires new registered user to wait for FIVE days before posting? I almost forgot what I wanted to say here.

avoid spambots and impulsive questions from newbies I would guess.

Anyway, I have been using madvr since 0.13. After 0.43 , theres always this bug in my kmplayer that whenever i stretch full screen Ctrl+Enter any newly opened video (1st time opening after each computer boot), the kmplayer will always hang and non-responding. After I terminate the kmplayer process and reopen the video and full screen, there will be tearings on the video while stretching to full screen. 0.43 and before had no such problem, everything was smooth.
I briefly tried mVR in a recent KMP build and it would always show the menus/ffdshow config windows behind mVR...very annoying, why not moving to PotPlayer instead?

i feel 0.43 graphics is better than current version if just using yv12 for all videos as in it looks slightly brighter and clearer.
post your specs, screenshots and so...subjective judgments need hard proofs ;)

[hdboy]

with system in sig, I get severe glitches if I check (ON) "use a separate device for presentation". Looks like my TV is having a seizure. It happens at random times and only with playback on second display (my TV). (Took me a while to nail down the problem. Hope this hepls someone)

[Gaius]

Why this forum requires new registered user to wait for FIVE days before posting? I almost forgot what I wanted to say here.

Anyway, I have been using madvr since 0.13. After 0.43 , theres always this bug in my kmplayer that whenever i stretch full screen Ctrl+Enter any newly opened video (1st time opening after each computer boot), the kmplayer will always hang and non-responding. After I terminate the kmplayer process and reopen the video and full screen, there will be tearings on the video while stretching to full screen. 0.43 and before had no such problem, everything was smooth.
Have you tried it in anything else but KMplayer? That player is considered largely obsolete.

[THEAST]

But if you really HAVE to do it, it's better to use FFDhow's resizer to double it. It'll let VSfilter render the subs at the higher resolution, just better scaling for the video.
Wow, I hadn't even bothered checking ffdshow's options, took me a while to configure it right (so that the video would be upscaled with the right ratio and the subs would be played inside the video frame and not outside it, etc) but I set it to automatically resize anything smaller than 720p to desktop resolution which forces Directvobsub to also render the subs at the same resolution and everything looks great now, with no loss of video detail/quality whatsoever! You're my savior, dude! :worship:
There is one small problem though, the same color change that happened with Directvobsub's resizing also happens here when I use madVR as renderer but Haali renderer is fine. :(


Is there really a reason for upscaling with that instead of madVR?
I don't see any options in madVR for resizing all videos to a specific resolution, am I looking in the wrong place?:confused:
And well, as far as I know/understand, since Directvobsub renders the subs before the renderer does, changing the rendering resolution isn't gonna help, only changing the decoding resolution will help and Directvobsubs doesn't work with madVR's internal decoders.


is #9201 still the same with v2.40.3644 ?
I just tried that version, the problem is still there; and as I mentioned above, it also happens if I resize the video with ffdshow. :(

[Mr Alpha]

Feature request:
Give control of how many % of the (top+bottom)/(left+right) black bars are at the top/left.
For example, when the movie is wider than the screen, "0% top" puts the movie at the top of the screen, 50% in middle, 100% at bottom.
Can't you do that with MPC's Pan&Scan feature?

[nand chan]

I just tested the latest threaded VSfilter with Hi10P material,

It “converts” 10 bit material to 8 bit by rounding down. Causes insane, immediately noticeable banding.

So that leaves us with no option other than the ISR for Hi10p.

Edit: Or maybe it does dither but the dithering algorithm is absolute shit. Either way, do *NOT* recommend using it on 10 bit streams.

[Budtz]

Any chance a sharpening filter is in the works?
As I understand it such a filter needs to be applied as one of the last things in the chain and thus it is not optimal that ffdshow does it. Plus their might be better sharpening methods then ffdshow has. This would go a great deal to improve picture quality as well as the usability of madvr’s internal decoders.

[leeperry]

Any chance a sharpening filter is in the works?
As I understand it such a filter needs to be applied as one of the last things in the chain
I don't think you could do much better than LSF tbh, and it should be done prior to mVR's dithering IMHO...so doing it in ffdshow sounds entirely reasonable. The only drawback being that it'll be processed in 8bit....supposedly masktools might support a 10bit kludge at some point, but then we'd need ffdshow to be tweaked as well. Requesting 10bit Avisynth support in mVR sounds quite demanding...innit? http://forum-images.hardware.fr/images/perso/zoubidawa.gif

[nevcairiel]

Running a sharpening pixel shader after madVRs scaling sounds like the best place for it, doesn't need to be avisynth.

Anyhow, i believe madshi has some future plans for this, but he generally doesn't comment on any specific plans. :)

[nand chan]

I checked ffdshow's dithering as well by loading the raw video filter on top of LAV Video - banding was just as apparent and bad as when loading VSFilter. It seems like anything other than madVR causes ridiculous drops in image quality.

[Budtz]

I don't think you could do much better than LSF tbh, and it should be done prior to mVR's dithering IMHO...so doing it in ffdshow sounds entirely reasonable. The only drawback being that it'll be processed in 8bit....supposedly masktools might support a 10bit kludge at some point, but then we'd need ffdshow to be tweaked as well. Requesting 10bit Avisynth support in mVR sounds quite demanding...innit? http://forum-images.hardware.fr/images/perso/zoubidawa.gif

Might be so but it should be done after madvr's various resizing and upscaling/downscaling etc. And that is not the case now as far as I can figure.

Also what does LSF stand for?

[nand chan]

Might be so but it should be done after madvr's various resizing and upscaling/downscaling etc. And that is not the case now as far as I can figure.

Also what does LSF stand for?

Wouldn't it be nice if madshi split up each component of the madVR pipeline into separate DirectShow filters so we could mix and match them as we please?

That way we could also do stuff like insert VSFilter after the dithering process but before the rendering.

[nevcairiel]

I checked ffdshow's dithering as well by loading the raw video filter on top of LAV Video - banding was just as apparent and bad as when loading VSFilter. It seems like anything other than madVR causes ridiculous drops in image quality.

Do you have a sample that clearly shows the banding?

[leeperry]

Running a sharpening pixel shader after madVRs scaling sounds like the best place for it, doesn't need to be avisynth.
There's no point in sharpening the chroma AFAIK and that's where mVR's scaling does magic, but indeed I don't use mVR to upscale...and sharpening the luma before downscaling allows for the so-called SuperSampling (http://avisynth.org/mediawiki/Supersampling) effect that sharpens w/o jaggies. LSF looks outstanding in SS mode :cool:

what does LSF stand for?
LimitedSharpenFaster() (http://avisynth.org/mediawiki/LimitedSharpen)

[nand chan]

Do you have a sample that clearly shows the banding?

http://www.mediafire.com/?5ea977kw5f6l6ny

With madVR, it's a practically perfectly linear gradient
With ffdshow, I can see the faint hints of bands, about 30 pixels in width.
With VSfilter, I see the same bands, but they're more pronounced.

If I use madVR but disable dithering in the performance tweaks menu, I see the same bands but they're much much softer.

I'll upload a screenshot of each tomorrow if you want me to.

[leeperry]

With madVR, it's a practically perfectly linear gradient
With ffdshow, I can see the faint hints of bands, about 30 pixels in width.
With VSfilter, I see the same bands, but they're more pronounced.

If I use madVR but disable dithering in the performance tweaks menu, I see the same bands but they're much much softer.
I'm not sure I'm following you, but Kazuya encoded this real-world dithering test pattern, maybe it could help: Banding 720p.rec709.mkv (http://www.mediafire.com/?wbmyif3yf2mijti)

I get the smoothest gradients on my pseudo-10bit CRT when enabling dithering in both SmoothLevels() and mVR(they use different algorithms). ffdshow's dithering's too noisy on top of those two and not as good looking as mVR's, but luckily you can disable it.

[nevcairiel]

I think i found the culprit - it looks like swscale (the component used for pixel format conversion in LAV Video and ffdshow) does not properly perform dithering when converting YUV 4:4:4 -> RGB, and since ffdshow raw and vsfilter do not natively support YUV 4:4:4 input, RGB32 is the next best format chosen.
Converting it to YV12 (4:2:0) in LAV Video first, and then sending it through vsfilter does not introduce the banding.

I'll see if i can maybe fix that, somehow. :)
Note that it only affects 4:4:4 material, which is rare as it is.

[nand chan]

I'm not sure I'm following you, but Kazuya encoded this real-world dithering test pattern, maybe it could help: Banding 720p.rec709.mkv (http://www.mediafire.com/?wbmyif3yf2mijti)

I get the smoothest gradients on my pseudo-10bit CRT when enabling dithering in both SmoothLevels() and mVR(they use different algorithms). ffdshow's dithering's too noisy on top of those two and not as good looking as mVR's, but luckily you can disable it.

Useless since it's not 10 bit.

I think i found the culprit - it looks like swscale (the component used for pixel format conversion in LAV Video and ffdshow) does not properly perform dithering when converting YUV 4:4:4 -> RGB, and since ffdshow raw and vsfilter do not natively support YUV 4:4:4 input, RGB32 is the next best format chosen.
Converting it to YV12 (4:2:0) in LAV Video first, and then sending it through vsfilter does not introduce the banding.

I'll see if i can maybe fix that, somehow. :)
Note that it only affects 4:4:4 material, which is rare as it is.

That sounds highly likely. I did notice that when disabling RGB32 output in ffdshow, DirectVobSub fails to connect. Seems like we need to re-encode the source file using 4:2:0.

[madshi]

Any approximate time frame on 10 bit output?
Not too soon. I have a couple of other things on my to do list which are more important, IMHO.

Yeah, I have to seek a few times for it to become noticeable, I wanted to make sure I captured the sync issue.

Correct, there is no sync problem when I'm using ffdshow. Currently I'm using LAV splitter 0.31 and the issue seems limited to that splitter as Haali's splitter didn't produce the same issue.
I can reproduce it on any VOB file I have, hopefully you can too.
Ok, I'll check that and try to fix it for the next build.

Not sure if it's a bug, but in my setup Reclock isn't detecting the video stream fps with the internal decoders. Tested with internal MPC and Haali Splitter.
Hmmmm... I'll need to check what Reclock exactly looks for. Maybe I can talk to James (SlySoft) to find a solution for that. Shouldn't be too hard.

When presenting lots of frames in advance, is it normal for the sound to be slightly out of sync (video comes too late)?
No, that shouldn't happen. Might be GPU driver bug. Try reducing the number of frames, for some people this problem only occurs if they render more than 8 frames in advance.

My solution to the ReClock problem was uninstalling and re-installing Haali Media Splitter and then checking the 'Preferred Decoder' check-box in CoreAVC. Without the 'Preferred Decoder' check-box checked in CoreAVC, ReClock won't detect the frame-rate via DirectShow using the internal madVR decoder. Since since the preferred decoder merit is higher than the madVR internal decoder, I then need to add CoreAVC as an external filter in MPC-HC with a custom merit of 00800000 or below.
So you're saying CoreAVC isn't decoding, madVR is, but still Reclock picks up the frame rate? That sounds weird...

Hate to say "I told you so"
Don't lie!! :devil:

Anyway, I think this problem should be easily solvable, at least if James is willing to talk to me.

1. If I jump to the next file in the folder (using the "]" key, which in ZoomPlayer is linked to "Media: Next Track" action) I get some contradictory OSD in madVR - the big one (with all the texts) says fullscreen exclusive mode, while on top of it there is the small one which says "windowed" and is stuck there forever. Strangely if I use the other function to play the next file in the folder (PgDn) I can't reproduce it. I'm not sure if it's madVR's fault or ZoomPlayer's ... or both ... but I thought I should report it. The strange part is that madVR is always in exclusive mode but still shows the "windowed" message. (btw I don't use the blanking function (creating black windows over inactive monitors) that you and Blight are discussing).
Sounds very weird. Is this 100% reproduceable?

2. If I use ZoomPlayer's control bar to jump to the next track/file in the folder the player will hang/crash if madVR's OSD API is used to draw the control bar. I guess this could be a bug in ZoomPlayer itself - using some memory already freed by madVR but it could be the other way around so I thought it's best to report it here too.
I think Blight told me the cause of this, I might have to change something there...

It's weird though. If I start a file it is windowed and plays fine. If I double click the video to make it full screen, the video plays fine. When I go back to windowed or right click to access the menu, the video starts stuttering.
Sounds weird. Can you try using a GPU tool to fix your GPU clocks to a specific value? Maybe that helps? Also make sure anisotropic filtering, antialiasing etc are all turned off or set to application preference. I've no idea where the problem is coming from. Some people are reporting this problem once in a while, but I've never yet been able to reproduce that myself. Maybe a log would help, but I'm not sure...

Does anyone have an idea why Potplayer crashes into a black square requiring a kill process when i go from full screen into window mode?? But if i go to "madvr window mode" by moving the mouse to show potplayer seek bar and then press "enter" to get out of potplayer fullscreen it works, no crash?? It does not crash every single time but most of it yes
Can any other Potplayer user reproduce this?

Did you change something in regard to this hibernation problem (forum.doom9.org/showthread.php?p=1508824)? I'm asking because when I tried the new version CPU usage was normal after hibernating but when I pressed play MPC crashed. Also after I played a game (Red Faction Guerilla) MPC was using a full core.
I don't remember, but I don't think I changed anything. I made some changes for locking the desktop, though, which might be somewhat related. But I don't know for sure.

I was today trying to find a madVR config that allowed me to go from windowed mode, into fullscreen exclusive and back and forth between the two, without getting an audio glitch (I assume d3d is doing this). I found that enabling "Use D3D11 for presentation" set to on fixes this but makes the renderer behaving a little strangely, the biggest problem for me is going into fullscreen mode sometimes doesn't work, screenshot attached for that one.
Looks weird, haven't seen this one yet. The problem for me is that it's hard to fix a problem that doesn't occur on my PC. What I can reproduce here is that sometimes switching to exlucisve mode with DX11 doesn't work at all. I'll look into that later. Maybe fixing that will also fix the problem you're having.

Question about, "the display is calibrated to the following transfer function / gamma:". I have already calibrated my display and targeted a 2.35 gamma so I set it to 'pure power curve - 2.35'. What effect does this setting have?
It doesn't have any effect if you have gamma processing disabled. If you enable it, madVR will adjust its gamma processing to work correctly with your display. So e.g. if you tell madVR to show a 2.2 gamma curve and set your display to 2.35, then madVR will actually make the image brighter.

Just got a low-end Toshiba Llano (A6/6520) in for casual use. About 15 minutes to set it and plug it into my TX-NR906. This is the strangest Microsoft experience I've ever had with a new machine. Loaded up madVR/LAV/Reclock/MPC-HC and it's been working flawlessly now. I wonder what's wrong? ;)
:)

Does anyone else have issues with PotPlayer and madVR when playing from a playlist where you have SD avi's followed by HD mkv's? madVR crashes (which then crashes PotPlayer) when the avi finishes and moves on to the mkv. I have to delete the avi's from the playlist, restart PotPlayer and then the mkv's play fine. Anyone else have this prolem?
Yeah, does anybody else have the same problem?

FWIW, crashes are currently hard to fix for me, if I can reproduce them. That might improve in some future version.

You mentioned it requires dedicated video graphics memory...so integrated video is a no?
Experience shows that integrated video performs less well. It might still possible to use it, but you may have to turn some quality options down. Don't really know for sure.

How do I make these empty folders that was posted in the 0.72 changelog with regards to force full range input" and "YCbCr"?
Just create an empty file in the madVR folder with the name listed in the changelog. The "YCbCr" is just for debugging, though, it doesn't have any use for normal users.

If "all work is done via GPU shaders" why are all high bitrate blu-ray movies played back jerkily, and re-encoded movies smoothly (sofar)?
That sentence "all work" was written before madVR learned how to decode MPEG2, h264 and VC-1. madVR does indeed do all of its work via GPU shaders - except MPEG2, h264 and VC-1 decoding. Since madVR currently doesn't support hardware video decoding, your CPU is used for decoding.

The only last minor issue I'm experiencing is that when I make realtimes changes to my Avisynth scripting(like toggling LSF), mVR always stutters like hell...and sometimes will resync after a little while, sometimes after a long while...in both cases, it's just faster to reseek. Sometimes reseek still stutters and requires another reseek. I've put logs here, it'd be great if mVR could resync instantly if any possible
These logs are a bit hard for me to understand because I don't know for sure what you did exactly at which point in time. Can you create one log (only one) where there's stuttering after an Avisynth scripting change? Then please add a description of when exactly what happened. E.g. like this:

0s - playback start
0s - 30s smooth playback
30s - avisynth script change
30s - 32s frozen image
32s - 50s stuttering
50s - 60s smooth playback
60s media player stopped

This way it's much easier for me to understand what's going on in your log. Reading logs is very time consuming. So it's better to have one good log with added information like shown above, instead of a dozen of logs, without additional info.

madshi If I set ffdshow in RGB32 and output 0-255, madVR process it like 16-235. madVR is supposed to handle it properly no ?
madVR should detect and treat ffdshow 0-255 RGB output properly. Please double check what madVR detected (press Ctrl+Shift+Alt + i). Does it say TV or PC levels?

Please note that madVR only detects this once at playback start. If you change the ffdshow settings during playback, madVR won't notice the change.

Can I leave nv12 ticked off in ffdshow for any content or is y12 preferred? Reason for wanting to use nv12 all the time is I can have my hardware do deinterlacing and the menus seem to work! :thanks:
madVR doesn't care whether you use NV12 or YV12, it's all the same to madVR. However, hardware deinterlacing only works when using LAV CUVID. With any other decoder, if you manage to get hardware deinterlacing, you must be using a different renderer.

Still, it lacks an important feature IMHO, and that's support for making screenshots in MPC-HC; do you have any plans to add it in near future? :cool:
It's on my to do list, along with a hundred other things.

Don't know if this belongs here, but... is there a preferred output range for Nvidia cards like there is for ATI? The general consensus for ATI is to output full range 0-255... is it the same for Nvidia?
Yes.

Also, is adding a custom resolution the only way to output 0-255 for both video and desktop?
There's also a driver tweak available which achieves the same thing, but you have to apply it before installing the driver. So creating a custom resolution is the easier solution, IMHO.

[madshi]

Anyway, I just wanted to report a small issue. Using madVR 0.73 and Directvobsub 2.40.3300 + ffdshow as renderer and MPC-HC as player and Haali as splitter, I'm experiencing some strange color changes by switching between original resolution and doubled resolution subtitle rendering in Directvobsub:

Original resolution:
http://i3.imgkeep.com/i/00051/4c7pmgp5p7q2.jpg

Doubled resolution:
http://i3.imgkeep.com/i/00051/gv15s31ya54o.jpg

This doesn't happen with other renderers, so I think it must be an issue with madVR, e.g. with Haali renderer:

Original resolution:
http://i3.imgkeep.com/i/00051/yobri8x0u1b6.jpg

Doubled resolution:
http://i3.imgkeep.com/i/00051/lfne1enoabe7.jpg

There also seem to be some cropping differences here. The first screen from madVR has one more row of pixels at the top and one more column at the left while it has one row less at the bottom and one column less at the right in comparison to the second screen.
And yeah, I'm 100% sure that the frames are identical.
Hmmmm... Can you please check whether madVR detects the same primaries (Ctrl+Alt+Shift+p) and decoding matrix (Ctrl+Alt+Shift+m) in either case? When using other renderers, is DirectVobSub outputting the same color format (e.g. YV12)?

oh yah, and I forgot a rather old feature request that would become the icing on the cake now: the ability to hide the "windowed"/"exclusive" OSD messages if any possible http://forum-images.hardware.fr/images/perso/taktateh.gif
You have requested this months ago and it's still on my to do list. You don't need to repeat your wishes.

As for the 0-255 issue, I've seen some people say that if you set the Dynamic Range in the Nvidia drivers, it only sets that for video... desktop remains compressed 16-235 when using HDMI. In order to get both to output 0-255, you have to create a custom resolution.
Correct.

When using nVidia drivers newer than 260.xx, I get constant presentation glitches (like thousands if I watch a 2h film) if the "use a separate device for presentation" setting is turned off. Turning it on fixes it.

With drivers </= 260.xx, I don't any glitches even when this settting is turned off. Turning it on doesn't hurt either.

And I do feel playback is smoother when I don't get any glitches (but I'm not so sure, 23.976 isn't exactly "smooth" anyway, so maybe it's placebo)

I suppose this is entirely nVidia's fault though, not yours.
Yeah, that appears to be the way it is. I think it's a driver issue.

I'm just curious, as I'm not sure what this setting does etc :p
The setting switches madVR into an alternative presentation mode, with the aim to reduce the presentation glitches. So it seems it does work exactly as intended.

Is there a "technically" correct setting for the "display bit depth" in the madvr device properties screen?

Should a 6bit+dithering panel be set a 8bit, 7bit or 6bit?
That's hard to answer. If the panel has built in dithering, and if the built in dithering is working well then you should set madVR to 8bit. If the display doesn't dither (well), you could check whether setting madVR to 7bit or even 6bit improves image quality for you. The best way to check this is IMHO to use the "madTestPatternSource" test pattern generator shipping with madVR. Zoom up the "colors.ytp" test pattern to fullscreen, then check if you can see any movement in the image. You shouldn't be able to. All you should see is changing colors. If you can see horizontal, vertical or diagonal movement, then you need to increase dithering strength. You can try to disable dithering to see the movement I'm talking about.

If using yCMS to generate a .3dlut, does it do YUV->RGB conversion still or RGB->RGB conversion? At what bit-depth are these conversions performed, and is dithering applied before or after?
The 3dluts needed by the latest madVR version are RGB->RGB. The YUV->RGB conversion is done via shader math by madVR in 32bit floating point math. The data is fed to the 3dlut as 32bit floating point. The 3dlut itself has only 8bit integer input bitdepth. However, madVR uses the GPU hardware to perform trilinear interpolation by using 32bit floating point adressing. The 3dlut output is 16bit integer. Dithering is applied as the very last step, of course after 3dlut processing.

Huh, but then what happens with 10 bit material?

10 bit YUV 4:2:0 -> 16 bit YUV 4:4:4 -> upscaling -> conversion to RGB 16 bit -> dithering down to 8 bit RGB -> 3dLUT -> conversion to target range -> dithering down to output depth?
There's no downconversion to 8bit RGB before the 3dlut. The 3dlut is addressed by 32bit floating point values, by using the GPU trilinear interpolation functionality.

One thing intrigues me. The script madVR uses for generation says:

Input_Range 16 235
Output_Range 16 235

Wouldn't it be better to use 0-255 as the output range of the 3dLUT when dealing with a 0-255 display? That way, the LUT itself would have a wider dynamic range available for its calculations and would be more exact.
That would be possible, but what happens if you switch between TV and PC levels on the fly in madVR? Then madVR would have to create & load two different 3dlut files. I wanted to avoid that, so input/output is always TV levels and stretching to PC levels is done afterwards via shader math, if necessary.

So when do the levels get pulled up to 0-255?
After 3dlut processing, before dithering.

Is it just me, or does directvobsub not work while using madvr as a decoder?
That's correct. If you want to use DirectVobSub, you can't use the internal madVR decoders (at this point in time).

It does not, it cannot, and it will not.
DirectVobSub needs to go between the decoder and the renderer. In madVRs case, thats no longer possible.
True. And not true. I might be able to make it work. Or maybe not. We'll see...

When using a 3DLUT with madVR there is at least one good reason, since MPC-HC subtitles don't get color corrected by madVR.
True. I could probably change that. However, it might cost performance, I'm not sure. How important is that? I mean we color correct video to make it look "correct". How can it matter for subtitles whether they're color corrected or not? Sounds weird to me.

Bug: ?
When exiting fullscreen exclusive mode, the last frame that was shown before going into fullscreen is shown for a very short time. Can you somehow get rid of this? Or just make it black or something.
Try disabling Aero. Does that help?

When madVR needs to render the subs with the ISR, subtitle frames getting delivered at late or at un-even intervals can cause issues like dropped/delayed frames if VSync gets missed, since madVR has less time to do the last steps prior to presenting. Any issues VSFilter has are hidden from madVR, as long as frames are delivered slightly faster than realtime to the Decode queue. For more significant yet brief slowdowns, VSFilter also has the advantage since the Decode queue can drop to around 3/8 before causing significant issues, while the Render queue which the ISR interfaces with can begin causing issues as soon as it drops to 6/8. VSFilter is just more resilient to slowdowns in general compared to the ISR.
It's true that the ISR and VSFilter have different slowdown effects due to in which thread they're doing their work. VSFilter works in the same thread as the decoder, so VSFilter slows the decoder thread down. The ISR is called in the context of the madVR rendering thread, which is by design of the ISR communication logic, so it slows down the madVR rendering thread. However, I don't really see why either slowdown should matter as long as both the decoder and render queues stay at 4/8 or higher. I don't see why the render queue dropping to 6/8 could cause any problems. It shouldn't, at least no in theory. Of course you (cyberbeing) have special needs due to your high refresh rate and using windowed mode, so things are very sensible in your situation. With a more "normal" setup, using exclusive mode and e.g. 24Hz, probably there's be no problem at all with the ISR and a render queue of down to 4/8.

i am using the latest madvr, with the latest MPC HC and ffdshow. if i watch a video with ordered chapters (anime, where the OP and ED are separate files from the original episode - mkv) when the treansition from the main video to op or ed should be made MPC HC crashes. this only happens if i use madvr, that's why i'm posting here :P
Can anybody reproduce this?

A sample might help.

i also have a question. how well does madvr perform on synchronization of video framerate to monitor framerate? to my eyes EVR Sync is a bit better then EVR CP. does madvr outperform EVR Sync? a small graph like in the case of the 2 EVR renders would be greatly appreciated!
I don't believe in these graphs. Trust your own eyes.

Feature request:
Give control of how many % of the (top+bottom)/(left+right) black bars are at the top/left.
For example, when the movie is wider than the screen, "0% top" puts the movie at the top of the screen, 50% in middle, 100% at bottom.
Please ask again after madVR v1.0 is released. I've too many things on my to do list already, which I consider much more important than this new feature request.

Anyway, I have been using madvr since 0.13. After 0.43 , theres always this bug in my kmplayer that whenever i stretch full screen Ctrl+Enter any newly opened video (1st time opening after each computer boot), the kmplayer will always hang and non-responding. After I terminate the kmplayer process and reopen the video and full screen, there will be tearings on the video while stretching to full screen. 0.43 and before had no such problem, everything was smooth.
Can anybody else reproduce this? kmplayer + madVR seems to work just fine for me.

maybe its just me, i feel 0.43 graphics is better than current version if just using yv12 for all videos as in it looks slightly brighter and clearer. i know 0.73 supports rgb32, but thats different story since yv12 is incomparable to rgb32.
Can you make comparison screenshots?

with system in sig, I get severe glitches if I check (ON) "use a separate device for presentation". Looks like my TV is having a seizure. It happens at random times and only with playback on second display (my TV). (Took me a while to nail down the problem. Hope this hepls someone)
Not sure why you have problems with that option, for most people it works very well. Too bad that the same settings don't work for everyone.

Any chance a sharpening filter is in the works?
Not in the works, but might eventually come at some time in the future. Not too soon, though.

Wouldn't it be nice if madshi split up each component of the madVR pipeline into separate DirectShow filters so we could mix and match them as we please?

That way we could also do stuff like insert VSFilter after the dithering process but before the rendering.
This wouldn't actually work, because the madVR pipeline is (except for MPEG2, VC-1 and h264 decoding) completely running on the GPU and has the video data stored in GPU RAM, while all the DirectShow filters require the video data to be in System RAM. madVR would have to copy the video data between GPU RAM <-> System RAM all the time to make this possible, and it would severely hurt performance. With ATI hardware, only one such copy operation would already make everything become a slideshow. With NVidia, it might still work, but it would definitely cost performance. So, this is not coming, not ever, as far as I can see right now. madVR's aim is to move everything to the GPU as fast as possible and to keep it there. So it doesn't make sense to have any other DirectShow filters being involved, because none of them can work with video data in GPU RAM. If anything, I might at some time offer a plugin API for madVR so that people can extend madVR's GPU processing algorithms. Not sure if that makes sense, though.

With madVR, it's a practically perfectly linear gradient
Weird, I see fairly noticeably bands with madVR, too. Maybe something is broken on my PC? :confused:

I'll upload a screenshot of each tomorrow if you want me to.
That'd be nice.

[pirlouy]

Wouldn't it be nice if madshi split up each component of the madVR pipeline into separate DirectShow filters so we could mix and match them as we please?

That way we could also do stuff like insert VSFilter after the dithering process but before the rendering.
No.
Madshi already explained some reasons why it can't be a separate directshow filter: he is sure there are no (bad) postprocessing from other directshow filters; the second reason is the fact he can do whatever he wants, for example, avoiding RAM use (prefering GPU usage). And he might have other reasons that we don't have to ask, because he does not want to be asked about his plans. :)

It definitively should be a good idea to create a wiki page somewhere (with a FAQ) in order to avoir repetitions

[THEAST]

Hmmmm... Can you please check whether madVR detects the same primaries (Ctrl+Alt+Shift+p) and decoding matrix (Ctrl+Alt+Shift+m) in either case? When using other renderers, is DirectVobSub outputting the same color format (e.g. YV12)?

Since the same problem occurs when I resize the video using ffdshow instead of Directvobsubs, the same thing would happen, I tested with ffdshow:

With resizing disabled in ffdshow, madVR does a SMPTE C --> BT.601 conversion while with resizing enabled, it does BT.709 --> BT.709.

This doesn't happen with Haali, which I also provided screenshots for, haven't tried other renderers, though.

[ForceX]

I just tested the latest threaded VSfilter with Hi10P material,

It “converts” 10 bit material to 8 bit by rounding down. Causes insane, immediately noticeable banding.

So that leaves us with no option other than the ISR for Hi10p.

Edit: Or maybe it does dither but the dithering algorithm is absolute shit. Either way, do *NOT* recommend using it on 10 bit streams.
VSFilter is not doing anything to the video. It does not support 10 bit or 16 bit colorspace input. Any banding you see is due to the dithering being done in the decoder while it converts it to YV12 or RGB32 before sending it to VSFilter.

we could also do stuff like insert VSFilter after the dithering process but before the rendering.
That's why you have LAV Video. You can't do madVR dithering in GPU, then bring the data to CPU so VSfilter does its work and then take it to GPU for rendering. The latency would be catastrophic.

[madshi]

Since the same problem occurs when I resize the video using ffdshow instead of Directvobsubs, the same thing would happen, I tested with ffdshow:

With resizing disabled in ffdshow, madVR does a SMPTE C --> BT.601 conversion while with resizing enabled, it does BT.709 --> BT.709.

This doesn't happen with Haali, which I also provided screenshots for, haven't tried other renderers, though.
Weird. madVR should detect that ffdshow is resizing and use SMPTE C for both. But anyway, this is unlikely to be the cause of the problem. The gamut conversion only results in rather small differences. Bigger differences are to be expected by the decoding matrix. What matrices are used (Ctrl+Shift+Alt+m) in either case? Probably BT.601 without resizing and BT.709 with resizing? The weird thing is that (although I expected madVR to be cleverer) other renderers should do the same thing.

Can I have a sample of the file?

[ForceX]

Hmm weird.. madVR doesn't render full picture when using RGB32 input. It just cuts off somewhere. And after a few seeks, it started to show a flickering present time in there. http://i.imgur.com/qs51w.png

[Thunderbolt8]

That's correct. If you want to use DirectVobSub, you can't use the internal madVR decoders (at this point in time).


True. And not true. I might be able to make it work. Or maybe not. We'll see...


True. I could probably change that. However, it might cost performance, I'm not sure. How important is that? I mean we color correct video to make it look "correct". How can it matter for subtitles whether they're color corrected or not? Sounds weird to me.Im for all these subtitle related changes, as long as directvobsub still looks a bit better than mpc-hc in some cases, it would be nice to be able to use it.

regarding colours, Im in favour of that as well, as I always use .ass subs and then you naturally would want to be able to see those colours you chose for specific lines on screen as they are supposed to be. if it costs performance, then maybe there could be an option to deactivate this for those who dont care.

[THEAST]

Weird. madVR should detect that ffdshow is resizing and use SMPTE C for both. But anyway, this is unlikely to be the cause of the problem. The gamut conversion only results in rather small differences. Bigger differences are to be expected by the decoding matrix. What matrices are used (Ctrl+Shift+Alt+m) in either case? Probably BT.601 without resizing and BT.709 with resizing? The weird thing is that (although I expected madVR to be cleverer) other renderers should do the same thing.

Can I have a sample of the file?

In SMPTE C --> BT.601, SMPTE C is the source primaries and BT.601 is the decoding matrix, so yeah, it is BT.601 without resizing and BT.709 with resizing. I tried some other files, this issue didn't happen with any of them. I also tried disabling Directvobsub on the same file, the colors were fine, seems the problem occurs only on this file, when some type of resizing is used, and in the presence of Directvobsub and madVR, quite strange IMO. Here is a small sample of the file:

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

[mzso]

Can any other Potplayer user reproduce this?
Well, I experienced something similar a day or two ago with one video file. When I went from full screen to windowed mode everything would disappear (video, GUI). But I couldn't click on other windows, because I guess the clicks were still captured by potplayer. Anyway I too had to kill the player (using keyboard only). Can't reproduce it at the moment

That sentence "all work" was written before madVR learned how to decode MPEG2, h264 and VC-1. madVR does indeed do all of its work via GPU shaders - except MPEG2, h264 and VC-1 decoding. Since madVR currently doesn't support hardware video decoding, your CPU is used for decoding.

Perhaps I was ambiguous. My CPU (E6750)is capable of decoding the video full speed with a (multi threaded decoder), I actually use the potp built in decoder. But when I use MadVR it stutters, with the blu ray videos, it doesn't with EVR. And since all work is done in the cpu I would think it should work as well as with other FullHD stuff since the images processed are the same size. But it doesn't for some reason full bluray videos stutter most of the time.

[noee]

@mzso:
If you check ctrl+J stats in madVR, what queues appear starved?

[ForceX]

The whole thing about color correcting subtitles seems stupid to me... Unless the sub is being rendered on the frame, it will always show the "correct" color. It's handled by the subtitle renderer, not the video renderer... Subtitles have specific color values, they don't suffer from chroma downsampling or whatever like videos.

[Thunderbolt8]

well if they are already correct, then its obsolete. but if not, please add :p

[kasper93]

@madshi:
Can you add support for MPC-HC subresync module to madVR. It load subtitles always with default frame rate instead of movie frame rate. The default is indeed 25.0 FPS. It's a task for the renderer to update it with the correct frame rate.(...) I know this is not important, but I think it takes not many work to fix it.

[mzso]

@mzso:
If you check ctrl+J stats in madVR, what queues appear starved?
Not sure. Seems to be decreasing. Render queue atm was 1-4/8 I think present cue 0-1/1. But I guess the latter is normal. Too bad I can't make a screenshot.

Edit:
Upload queue seems to change a lot. sometime goes down to 2-6, 1-5

What is presentation glitches? It seems to increase steadily.

Edit2:
Now it played withoud dropping frames for a few minutes. But the presentation glitches were still steadily increasing. Plus the playback didn't feel as smooth as it should.

[madshi]

Hmm weird.. madVR doesn't render full picture when using RGB32 input. It just cuts off somewhere. And after a few seeks, it started to show a flickering present time in there. http://i.imgur.com/qs51w.png
That's very weird. Does it occur with every video files, or just with one? I've never seen anything like that yet. Not sure, it must either be specific to that one video file, or maybe it's a GPU driver bug? In any case, I need to be able to reproduce it, otherwise a fix will be difficult.

Perhaps I was ambiguous. My CPU (E6750)is capable of decoding the video full speed with a (multi threaded decoder), I actually use the potp built in decoder. But when I use MadVR it stutters, with the blu ray videos, it doesn't with EVR. And since all work is done in the cpu I would think it should work as well as with other FullHD stuff since the images processed are the same size. But it doesn't for some reason full bluray videos stutter most of the time.
@mzso:
If you check ctrl+J stats in madVR, what queues appear starved?
Yep, as noee said, which queues are empty?

Can you add support for MPC-HC subresync module to madVR. It load subtitles always with default frame rate instead of movie frame rate. I know this is not important, but I think it takes not many work to fix it.
I don't even know what subresync is?

In SMPTE C --> BT.601, SMPTE C is the source primaries and BT.601 is the decoding matrix, so yeah, it is BT.601 without resizing and BT.709 with resizing. I tried some other files, this issue didn't happen with any of them. I also tried disabling Directvobsub on the same file, the colors were fine, seems the problem occurs only on this file, when some type of resizing is used, and in the presence of Directvobsub and madVR, quite strange IMO. Here is a small sample of the file:

http://www.mediafire.com/?w81nocpda59we61
Ah thanks, the autodetection fails there, need to check why. Do the colors look correct if you manually change the decoding matrix from BT.709 to BT.601?

Not sure. Seems to be decreasing. Render queue atm was 1-4/8 I think present cue 0-1/1. But I guess the latter is normal. Too bad I can't make a screenshot.

Edit:
Upload queue seems to change a lot. sometime goes down to 2-6, 1-5
Come on, looking at the stats, telling us which queue is where when it stutters shouldn't be so hard? Which queue is where? And why is the presentation queue max 1? What weird settings are you using?

What is presentation glitches? It seems to increase steadily.

Edit2:
Now it played withoud dropping frames for a few minutes. But the presentation glitches were still steadily increasing. Plus the playback didn't feel as smooth as it should.
Which movie frame rate? Which display refresh rate? Try checking the option "use separate device for presentation". Does that reduce the presentation glitches?

[QBhd]

@madshi:

Thanks for the follow up of my post. I have a few more details that I think I can add. The issue with madVR crashing when switching from and XviD to x264 file (also happens the other way as well) in a playlist, it happens only when using madVR to decode the x264. And it only happens in FS exclusive mode, windowed mode does not produce the crash when switching decoders for various files in a playlist. It may be a combination problem between PotPlayer and madVR, where the hand-off of decoding duties switches from the XviD decoder to madVR and back again.

I also have another problem that a solution has yet to be found. I play quite a bit of 720p 59.940 fps x264 files and madVR constantly drops frames to the point where it is un-watchable. It does not matter what decoder I use for the x264 files. I have found a reasonable set-up that is watchable, which is to use the madVR internal decoder (this is how I found the crashes above) in windowed mode, but it still drops the odd frame here or there. My system should be robust enough to handle anything I throw at it, PII X4 965, 4GB RAM, and AMD HD 5770 to name the core components. Any thoughts on this issue?

QB

[madshi]

Thanks for the follow up of my post. I have a few more details that I think I can add. The issue with madVR crashing when switching from and XviD to x264 file (also happens the other way as well) in a playlist, it happens only when using madVR to decode the x264. And it only happens in FS exclusive mode, windowed mode does not produce the crash when switching decoders for various files in a playlist. It may be a combination problem between PotPlayer and madVR, where the hand-off of decoding duties switches from the XviD decoder to madVR and back again.
Can you provide me with 2 small samples with which I can reproduce the problem here?

I also have another problem that a solution has yet to be found. I play quite a bit of 720p 59.940 fps x264 files and madVR constantly drops frames to the point where it is un-watchable. It does not matter what decoder I use for the x264 files. I have found a reasonable set-up that is watchable, which is to use the madVR internal decoder (this is how I found the crashes above) in windowed mode, but it still drops the odd frame here or there. My system should be robust enough to handle anything I throw at it, PII X4 965, 4GB RAM, and AMD HD 5770 to name the core components. Any thoughts on this issue?
What does the madVR OSD say? Which queues are where? Dropped/delayed frames? Presentation glitches? No smooth playback even in exclusive mode? You could try turning the scaling algorithms down a bit. E.g. try Bicubic or SoftCubic instead of Lanczos.

[leeperry]

The issue with madVR crashing when switching from and XviD to x264 file (also happens the other way as well) in a playlist, it happens only when using madVR to decode the x264. And it only happens in FS exclusive mode, windowed mode does not produce the crash when switching decoders for various files in a playlist. It may be a combination problem between PotPlayer and madVR, where the hand-off of decoding duties switches from the XviD decoder to madVR and back again.
I have the same problem when opening a lot of files in seamless playback mode, I thought it was due to the seamless parser which is quite buggy from what I was told on the official forum...or possibly ffdshow. If it's indeed due to mVR, it'd be great if you could provide samples to madshi so he could fix it :)

[mzso]

Come on, looking at the stats, telling us which queue is where when it stutters shouldn't be so hard? Which queue is where? And why is the presentation queue max 1? What weird settings are you using?


Which movie frame rate? Which display refresh rate? Try checking the option "use separate device for presentation". Does that reduce the presentation glitches?

Its hard to write something definite, its rather inconsistent. For example this time playback was totally smooth several minutes. Hardly any dropped frames, mostly at the start. Although the presentation glitches kept increasing, but slower than last time. The queue max was 1 because I was experimenting, but it didn't change things. This time the queue's were quite stable I'll try and pay attention to the stats if/when the playback stutters again

The movie is 23.976 fps, the display 60Hz. I tried the separate device setting and it seems the glitches were less. By the way what does "presentation glitches" mean? What should I associate it with?

[pankov]

Sounds very weird. Is this 100% reproduceable?
yes.
here is a log file from one such case
http://www.mediafire.com/?niuiu5y1s8aqpt7

I've also noticed (and reported to Blight) that if I simply let Zoom Player go to the next file in the playlist after reaching the end of the previous the same problem is present (the grey OSD "windowed" shows up and stays visible for ever).

I think Blight told me the cause of this, I might have to change something there...
yes,
Blight made a temporary patch for it (waiting 250ms before destroying the filters ... or something like this - he can explain it better)