madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by JMGNYC

However, I dont't want to set my TV to 0-255 as I have both a BD player and Cable box going through my AVR in addition to my HTPC and they want 16-235. There's no easy way to switch the TV to 0-255 just for my HTPC.

Ouch, that's painful.

Originally Posted by JMGNYC

So assuming that my TV is 16-235 here's what I've found using LAV, madVR, ATI 5570.

The Dynamic Range setting in ATI's CCC does nothing. No matter the setting there is no difference. Is this a bug or expected?

That's as expected.

Originally Posted by JMGNYC

However, ATI's Pixel Format does make a difference.

If madVR is set to 0-255:
-Pixel Format to RGB Studio I get good levels both black and white.
-Pixel Format to RGB Full I get good white levels but bluck crush which is no good.

If madVR is set to 16-235:
-Pixel Format to RGB Studio I get WTW and BTB which is no good.
-Pixel Format to RGB Full I get WTW but black levels are good.

So, my primary question is which is better:

1. madVR 0-255 with RGB Studio or
2. madVR 16-235 with RGB Full and WTW showing.

If you only care about videos looking correct, and if it doesn't matter to you whether the desktop or games look correct, then I'd recommend to set the Pixel Format to RGB Full and to set madVR to 16-235. This should produce correct results. You should *not* see WTW. Not sure why you do. Maybe your TV's brightness/contrast setting is not set correctly? But that should also affect your hardware Blu-Ray player and your Cable Box then.

Originally Posted by Mangix

After messing around with madVR for a while, I realized that it ruined the colors!

I have a Philips TV that causes many issues but one that I recently noticed was that once madVR goes into exclusive mode, the resolution turns to an HDTV resolution instead of a PC resolution and as a result, the colors get washed out.

This is not really madVR's fault, but the only big NVidia driver problem left for HTPC users. You can work around it by applying the PC levels tweak (see a few posts above).

Originally Posted by turbojet

Speaking of avisynth, is there any chance madvr supporting pre and post resize avisynth scripts?

No, because avisynth scripts run on the CPU and madVR does most of its processing on the GPU. However, I do plan to allow custom pixel shader scripts sooner or later, and it might be possible to achieve similar things to those avisynth scripts that way.

Originally Posted by ryrynz

Those months go by quickly Madshi

Yes, they do, especially if I take half a year madVR development pause...

Originally Posted by 06_taro

madshi, could you please add an option to set more specific anti-ringing conditions? For example, the resolution of my display is 1366x768, and the anti-ringing algorithm works perfect when I watch SD videos with Lanczos upscaling. But when I watch a 1280x720 video, the ringing produced by lanczos3/4 is too few to be noticeable, so I prefer not applying anti-ringing in this case to save my GPU resources(on my iGPU, when anti-ringing is enabled, the rendering time increases significantly when input resolution increases, about ~34ms for 1280x720, so frame drops for 30fps videos). This can be done by adding an option to set the resolution enlargement factor for anti-ringing condition, say, enable anti-ringing when rendering_resolution / input_resolution >= 1.5, and disable it when rendering_resolution / input_resolution < 1.5.

I have on my to do list to allow things like that, but in a more global way, for all settings. E.g. to allow you to choose totally different scaling settings for SD and HD videos etc. But I can't say right now when I'll find time to implement that...

Originally Posted by Keiyakusha

BTW I always wanted to ask but forgetting every time. If I encode 720x480 h264 video with 32:27 SAR and will play it (LAV splitter used and it is set to take SAR from stream, not DAR from container). Why madVR scales this video to 1919x1080? Looks like rounding issue somewhere...

Can I have a sample, please?

Originally Posted by turbojet

According to madvr status the queues are constantly full except for render queue which goes down 1 for a second about every 20 seconds.

And the decoder queue is full at the same time? If so, that suggests that your GPU is not fast enough to render the frames. Try setting your GPU clocks to a fixed clock. It was reported before that dynamic GPU clocking can sometimes result in problems like this. E.g. imagine the GPU driver thinks the clock doesn't need to be that high. So it clocks the GPU down. Then the render queue gets empty, and the GPU driver clocks up again. Ouch.

Originally Posted by innocenat

I am having problem deinterlacing MBAFF with LAV Filter (w/o software deinterlacing) and madVR, both latest problem. Is there anything I should set?

What problems do you have exactly? In the madVR debug OSD (Ctrl+J), is deinterlacing reported on or off? If it's off, try forcing it on by pressing Ctrl+Shift+Alt+D multiple times. Does that fix the problem?

Originally Posted by Netuser

1- I watch a lot of Vob of music videos and often old videos are 4/3 and boxed, before with ffdshow I use to use a script called LameAutoCrop which automatically crop the black border so that I can watch the clip in full screen and don't have to zoom each time. Is there anyway you can add this option ? or a way to adopt it ?

I think you should still be able to use ffdshow in the same way you used it before.

Originally Posted by Netuser

2- problem is that I can not take screenshot in MPC-HC when I use madvr i have to switch to other output option in MPC to do so. are you planning to add this option in future ?

It's on my to do list.

Originally Posted by Ver Greeneyes

I have a question with regards to the color correction built into madVR. My monitor is calibrated using an X-Rite ColorMunki Photo, using a LUT together with a v4 ICC profile. If I setup my monitor in madVR so that it's set to "this display is already calibrated", will it use the ICC profile assigned to my monitor? Or do I somehow need to convert my ICC profile to a 3DLUT file? The LUT itself should already be loaded into my GPU.

To be honest, I don't know how ICC profiles and LUTs loaded in the GPU behave with madVR. Does anybody else know?

Originally Posted by Ver Greeneyes

Oh, and should I "enable gamma processing" on the color & gamma tab? Would it do anything if it's set to the same gamma as my ICC profile (2.20)?

Enabling should do nothing if the chosen curve type and gamma value matches the values in the "calibration" tab. You can enable it to modify the gamma curve or values, if that's what you want.

Originally Posted by ajp_anton

wouldn't it be much faster to preserve the source pixels?

No, it would actually be slower, due to the way pixel shaders work.

Originally Posted by Keiyakusha

Now 692x448 with 103:86 SAR results 1920x1058 resolution, while it should be 1920x1038 (20px error seriously? Oo)

Sample, please?

Originally Posted by makakam

My HTPC (Radeon 6570) is connected to onkyo avr with hdmi and then to tv(panasonic vt30) with hdmi as well. I have been using full rgb pixel format and mpc-hc with madvr set to 16-235

Sounds correct to me.

Originally Posted by makakam

I have calibrated my tv using htpc pattern generator and greyscale ramp in it looks like the one from avs hd calibration disc when I play it in mpc-hc which is not perfectly smooth. I have noticed that when I change pixel format to ycbcr 4 2 2 the ramp in htpc pattern generator becomes smooth but thin vertical lines are still there in mpc-hc. Am I doing sth wrong or is it just impossible to have it completely smooth in mpc-hc? Thanks in advance.

Can you make screenshots? The ramps in calibration discs are often made so that there are many pixels with the same color. Such a pattern can't be perfectly smooth. Please try the madTestPatternSource "smallramp.ytp" test pattern and scale it up to fullscreen. If you get that perfectly smooth, you should be safe.

YCbCr 422 is not the ideal solution. However, there are certain receivers and certain displays which behave better with some color spaces than with others. So it's possible that your receiver or your display can't handle RGB input so well. In that case doing YCbCr 422 might be better. But I'd first try really hard to get RGB working cause it should be the best solution (except if your receiver or display is buggy).

Originally Posted by pando2

I have a question about yCMS in madVR:
How can we move to a target SMPTE-C while the concervant yCMS, the two can not be checked ??

I'm not sure what you mean. Can you clarify?

Originally Posted by Valdy

Under scaling algorithms, spline 4 taps is the best for image quality?

There is no "best". It depends on test and also on the source material. Just try which looks best to your eyes.

Originally Posted by makakam

I've read that panasonic vt30 doesn't have full 4 4 4 reproduction but it subsamples it, so the question is should I still use 4 4 4 pixel format or ycbcr 4 2 2 with madvr?

I can't really say. You'll have to try and trust your eyes.

Originally Posted by oddball

I don't know if Madshi is still working on MadVR (been a while since any updates?). But was wondering what he and others thought of this.

http://darbeevision.com/
http://www.avsforum.com/t/1410383/darbee-darblet
http://darbeevision.com/assets/documents/DarbeeVision%20Whitepaper%20with%20Tech%20Details%2020120415.pdf

From the screenshots I have to say I don't like the look too much. It has the typical "sharpened" look. I prefer Didée's new "FineSharpen" avisynth script. Looks better to my eyes.

Originally Posted by janos666

I just noticed I have a madVR - crash report.txt file on my desktop, so I thought I should send it to the developer.

Thanks, will have a look.

[madshi]

Originally Posted by Thunderbolt8

Ive been trying out the display changer on my new laptop and new tv and it has worked pretty well so far. Im using 1080p23, 1080p25, 1080p50, 1080p59.
1080p23 and 1080p59 run a bit smoother than p24 and p60 respectively. and also the automatic detection of 25 and 50 fps seems to work flawlessly, in case of some sources which are identified with a movie fps of 25.000 by madvr, the TV refresh rate is automatically set to 50fps, because they stutter all the time at 25fps while running completely smoothly at 50. others are kept at 25fps, all smooth as well.

there has only been one exception so far. had a BD movie with a movie fps of 29.97 which also needs a bit of deinterlacing which madvr doesnt recognize correcly by its automatic settings.
when I then add 1080p29, 1080p30 (or other way round) to the display changer line, then it wont run smooth in both cases. when I remember correctly, playback stutters even more with p29 even though its a tiny bit closer to 29.97fps than setting p30. p30 plays somewhat okish, but beings to drop A LOT OF frames when I activate madvr deinterlacing. but when I (let madvr) set the refresh rate to 59p or 60p instead and then activate deinterlacing, its running perfectly fine without dropping and stuttering.

so Im basically wondering why playback stutters with p29/p30, either by default or by activating deinterlacing. and why madvr unfortunately in this case seems to be unable to figure out the preferred refresh rate of p59/p60 so that I have to delete p29/p30 from the list of resolutions because otherwise I'd have to change it to p59/p60 manually for that movie.

There is very very *VERY* few content which is truely 29p/30p. Most content is really 59i/60i, which after proper deinterlacing either becomes 23p/24p (native movie content) or 59p/60p (native video content). I would suggest to remove 1080p29 and 1080p30 from the list of modes.

Originally Posted by omarank

It seems you are working on scaling algorithms these days. The anti-ringing filter option is really impressive (especially for Lanczos). I think this is the right time to make a suggestion for an optional method of chroma upscaling/ resampling. Although I don’t have a technical background in this area and my understanding of image scaling is also limited, yet I think I can suggest you a way of upscaling chroma in linear light. I am not sure if this is worth the effort, but I think I should express what I have in my mind.

If I understood correctly, the issue which prevents you from providing the option of chroma upscaling in linear light is that you need to convert Y’CbCr image to R’G’B’ before you can scale the image in linear light, and to do that conversion you need both chroma and luma information for the full resolution. That’s why you have to upscale chroma in the first step and you can’t do that in linear light. I think there is a way to deal with this issue.

I will take the example of a Blu ray content which has chroma information for 960x540 resolution and luma information for 1920x1080 resolution.

Step 1: Consider only the luma information from the content and use that to create a black-and-white image of resolution 1920x1080. Do the conversion to R’G’B’ and downscale this black-and-white image in linear light to 960x540 resolution (which is the resolution of the available chroma in the original content). Convert this downscaled image back to Y’CbCr (actually Y’ only).

Step 2: Combine the chroma information of the original content with the luma information of this downscaled (in linear light) black-and-white image to create a color image of resolution 960x540 in Y’CbCr.

Step 3: For the above color image of 960x540, do the conversion from Y’CbCr to R’G’B’ and upscale in linear light to 1920x1080 resolution. Convert this upscaled image to Y’CbCr.

Step 4: Consider only the chroma information from the above upscaled (in linear light) image and combine it with the luma information of the *original* content. In this way you will get a Y’CbCr image which has both chroma and luma information for the full resolution, and the chroma has been scaled in linear light.

Interesting idea. However, from my experiments with linear light luma upscaling I've found that for *up*scaling, using linear light doesn't seem to bring much - if any - benefit. I have some other ideas about chroma upsampling which I think would result in much more noticeable improvements, but that's will have to wait a while. Anyway, I don't think going to such lengths to upsample chroma in linear light is worth it. The possible benefit is just too low (if there at all).

Originally Posted by omarank

By the way, there is one issue with madVR which you might be aware of. MPC-HC crashes when I open any still image using madVR as a renderer. I have attached a crash report here. It looks like madVR doesn’t support viewing of still images. I was wondering if that be ever supported.

It seems to working just fine here. Which splitter/"decoder" is used on your PC to display images?

Originally Posted by vomanci

Hi, new here. One question. Do i have to calibrate my display (using Windows 7 internal calibration) for my Samsung P2250 monitor in order to get better colours ? I tried it but it seemed to me the model pictures are the same as the ones after i shoul calibrate (no noticeable differences in colour/brightnes/gamma).

I don't know anything about what the win7 internal calibration does and whether it affects madVR playback.

Originally Posted by mirkosp

Alright, I think I have an (odd?) bug report here (using 0.82.5). I'm not entirely sure it's a bug on madvr's end tbh, but oh well, here we go.
Basically, it seems that madvr will always read rgb32 from vsfilter and xyvsfilter as if it was tv range rgb32, whereas I'm quite positive it always overlays as 0-255 rgb.
As far as I know, madvr assumes pc range rgb if it isn't sure about the rgb range, which means that if it's reading it as tv range, there's something in vsfilter's output that makes madvr think it's tv range.
This is further confirmed, as if I try to send rgb32 directly from lav or ffdshow, it correctly reads it. I tried sending both 16-235 rgb and 0-255 rgb from lav, and it works correctly in both cases.
However, if there's vsfilter or xyvsfilter in between, it's going to always read it as 16-235.
As a further check I tried to have lav send 16-235 rgb data to vsfilter and then have madvr render. It turns out that the video itself is rendered correctly, but the overlayed subtitles are stretched in range and don't match the video's colours.
I have typeset the subtitles on 0-255 rgb32 in aegisub with colourpicking to make sure I got the right colours.
If I get lav to send 0-255 rgb to xyvsfilter, both video and subtitles get stretched from 16-235 to 0-255, but the colours do match.
Using evr cp or haali, I get the video displayed correctly (this is to be expected, as they always assume 0-255 rgb in input).

As I said, I doubt it's a bug with madvr, as I tested that, when reading rgb32 directly from lav, it gets it right in both tv and pc range cases. But as far as I know, if madvr isn't sure of the range, it's going to assume pc range rgb, which means it's sure vsfilter's output is 16-235, which I'd like it not to do, since I'm positive vsfilter will always overlay 0-255 even with 16-235 input (as the 16-235 rgb32 from lav -> vsfilter -> madvr test showed to me).

So we're talking about a native RGB video here? Can you send me a sample?

Originally Posted by Thunderbolt8

I havent followed all this stuff for a while, is it actually possible to watch a 3D blu-ray (iso, if needed) with madvr

Not in 3D, no.

Originally Posted by Nachbar

Hello I have a .icm profile that came with my monitor and I have implemented the values according to the guide at: http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt

Basically it says

18. Color management using yCMS is always recommended, but it is only required if you use a wide gamut display.
    This is done by selecting "calibrate this display by using yCMS" under "devices" -> [Display] -> "calibration" and
    filling out at least the "primaries / gamut measurements" table on the "yCMS" tab.
    If you do not have any suitable hardware, but you do have a proper ICC profile, you can acquire at least the XYZ values
    for red, green, blue, and white point by using an application such as ICC Profile Inspector
    - http://www.color.org/profileinspector.xalter - and double-clicking on rXYZ, gXYZ, bXYZ, and wtpt, respectively.
    Change the format from Yxy to XYZ and fill out as appropriate. Click on "save".

Does this look correct?

Also since it is already set as the color profile in the color management does madvr still require this?

To be honest, I don't really know. I'm not sure if the color profile is still "active" if you play a video with madVR. You can probably double check that by creating a dummy color profile with grossly incorrect values. That way you should be easily able to see if the profile is still active or not.

Originally Posted by yok833

Hello Guys, I have a problem and I would like to know if I am the only one or if you can help me.. I'm using the last build of MADVR but sometimes during a movie in HD (play via MPC-HC) i have a nasty sound (BZZZZ like on the old TV before they explode..) and right after the screen becomes black or/and the image is divided in 2, but the sound continues normally behind... Then the only solution is to reboot and everything works perfectly a certain time before it happen again. I have a ATI 6850 + phenom X4 925.... Any ideas?????? My config is not good enough to handle MADVR????

I'm not sure what this is. Maybe it's a hardware defect?

Originally Posted by TheMoustic

I am encountering problems when I use madVR... I have a Sapphire 4890 connected by HDMI to my Xonar HDAV 1.3, which is connected to my receiver (Onkyo TX-NR709). When I try to play 1080p/i movies (BD or mkv) with HD audio (DDTHD or DTS-HD MA/HR) in bitstream or in LPCM, the sound is cutted and cracks. If I choose EVR custom pres. as video renderer, everything works fine.

Not sure what that is, either. Have you tried different audio decoders and different audio renderers? madVR should have no direct impact on audio. madVR does not do *anything* audio related.

Originally Posted by Trib

Switched my tv from iGPU Intel HD 3000 to my 6950 for more demanding scaling algorithms and was wondering when checking with the testpatterns and when using Pixel Format from Amd CCC, Full or Limited Range RGB, the colors.ytp testpattern showed a vertical line moving horizontally using 0-255 levels and any paned bit depth.

That got fixed with using either YCbCr 4:4:4 or 4:2:2 Pixel Format from CCC with 0-255 levels and 8-bit bit depth. But was wondering if it was ok to use YCbCr rather than RGB as madshi said in front page "Ok, e.g. in ATI's control panel with some graphics cards and driver versions you can activate YCbCr output, *but* it's rather obvious that internally the data is converted to RGB first and then later back to YCbCr, which is a usually not a good idea if you care about max image quality."

So was wondering should I rather use Full Range RGB with the line or YCbCr 4:4:4 or 4:2:2 with no problems in colors.ytp for playback.

If your eyes tell you that the image looks better with YCbCr 4:4:4 then by all means use that. In theory RGB should be better, though. Do you see any difference at all when switching between "Full" and "Limited" Range RGB in the AMD CCC? Does the black/white level change? Maybe the switch is broken and AMD always outputs limited? Also try disabling all funny stuff that might impact GPU output. E.g. try disabling any ICC profiles, win7 calibration and whatever else you can find.

Originally Posted by THX-UltraII

I m using SVP frame interpolation. This is a heavy CPU usage real-time frame interpolation mode. In order to save more CPU i noticed that lowering the GPU and CPU queue saves quite some CPU power. Am I correct that I can lower them as much as possible without getting more dropped frames and pres. glitches?
EDIT: just put them on the minimum (both 4) and get not more dropped frames or pres. glitches then with the default settings (I think default was 12 and 8?)

If your playback is fine with lowered queues then that's just fine for you to use. However, higher queues should only result in higher CPU consumption while the queues are filling. As soon as all queues are full, CPU and GPU consumption should be identical to smaller queues. Maybe activating the madVR option "delay playback start until all queues are full" will make madVR work fine with higher queues, too?

Originally Posted by Mikey2

I just tried running the "Tweak" utility. I was on my 0-255 plasma and it went entirely blank.

Ouch. I feared something like this might happen. I'll modify the tweak utility to simply change the registry and require a reboot, just to be safe.

You might have been able to repair the black screen by turning the plasma off/on, or by temporarily pulling the HDMI cable. But anyway, having to do any of these things is not good, obviously.

Originally Posted by Mikey2

It now displays properly; however, I notice no difference than before. (I have madVR set to 0-255 and my TV set to the same. Blacks are grey when madVR is set to 16-235.)

The tweak is only necessary for the standard SD/HD resolutions. It's not needed if you are using custom resolutions.

Originally Posted by Mikey2

EDIT2: My Mistake, that value is missing for my Plasma. (I know you said the Tweaker was based on the current monitor; I have three monitors and it was sensing the wrong set of registry keys. I do NOT have this value on my plasma, which is the only one I care about. Should I add it?

I would recommend it, at least it shouldn't hurt.

Originally Posted by andybkma

So before you decide to remove that option please don't as us Optimus users seem still need that "Use a seperate device for presentation" option....

I wasn't planning to drop *that* option.

[sneaker_ger]

Are the replies up-to-date or did you already write them during the time the questions were posed?

[madshi]

Of course they're up-to-date. Why would I write them and then not post them months ago?

[sneaker_ger]

Well, if you were to answer immediately you'd also get more follow up questions immediately...

[leeperry]

Originally Posted by madshi

Good idea, will look into it.

Glad you like it! At my request, a friend of mine made a small app that forces the tightest NT resolution. It didn't change much on XPSP3 as I had already forced 0.97ms via its boot.ini but on Vista/W7/W8 you can force it down to 0.5ms instead of the default 1ms so it effectively provides a twice lower jitter

I can send you his small timerbooster app if you wanna try it, it hasn't gone public yet but it works wonderfully as far as I can tell.

Several ppl claim that W7 can reach less than 0.5ms when using HPET(even though it's undocumented), so it's good practice to force the value "1"(that's what fidelizer does) instead of "5000" just in case. Worst case scenario, it will be rounded to 9766 on XP and 5000 on the later OS.

Also, this value will only be forced for as long as the application requesting it will be running, so my friend had to provide a GUI-less mode so it would remain in memory as a process.

Strangely enough, Vista and W8 enable HPET by default but W7 does not(in most/all cases?) and uses an hybrid TSC+HPET mode that's utterly sloppy. I'm eagerly awaiting W7SP2 to make the big jump(there are several sub-SP1 audio related hotfixes) and I wanna do it in the most optimal conditions.

All this said, many ppl claim that fidelizer improves the SQ and everything USB related in general so forcing the same thing in madVR would only do good IMHO. m$ only force a low NT timer resolution when running multimedia apps in order to save power, which is mandatory on a laptop for instance...but they don't use the lowest one, they only go from 15.6ms to 0.9766 on XP/1ms on the later OS(when it can actually go as low as 0.5ms).

Going back to mVR, it works flawlessly on my system! The only thing I would love to see added is an "only when the movie starts" sub-option to "delay playback start until renderer queue is full" in order to allow ffdshow/avisynth/Reclock to all be synchronized and avoid the load induced judder I can see from time to time on WMV videos for instance(no GPU decoding so synchronizing everything can be a hit and miss). I believe other Reclock users would also welcome this feature.

[Keiyakusha]

madshi
Here is sample that appears as 1919x1080 resolution. This happens with any 720x480 file which have proper sar info in stream... http://www.mediafire.com/?ahmb8a2qvwa6ibx It doesn't matters what target resolution is, starting from 720p all affected (didn't tried less).

About second issue, this appears to be my mistake, I didn't noticed crop rectangle value, sorry.

[madshi]

Originally Posted by Keiyakusha

madshi
Here is sample that appears as 1919x1080 resolution. This happens with any 720x480 file which have proper sar info in stream... http://www.mediafire.com/?ahmb8a2qvwa6ibx It doesn't matters what target resolution is, starting from 720p all affected (didn't tried less).

Ok, I've checked, it's not a bug in madVR. The problem is pretty simple: The renderer reports to the media player which resolution the video file has and which is the preferred aspect ratio resolution. So madVR reports a video size of 720x480 and a preferred aspect ratio resolution of 853x480. The correct AR resolution would be 853.333333x480, but madVR has no way to pass this information to the media player, so it rounds down to 853x480. Now if you configure the media player to e.g. "touch window from inside" (MPC-HC) then the media player has to figure out which zoom factor to use on the 853x480 video. It could either use zoom factor 1920/853 or 1080/480. When using 1920/853, we would end up with a resolution of 1920x1080.422. That does not fit to the "touch window from inside" option. So MPC-HC instead goes for a zoom factor of 1080/480, which results in 1919.25x1080. The cause of all the trouble is the rounded preferred aspect ratio resolution of 853x480. There isn't really much I can do about that, I think.

P.S: Of course scaling is only performed once!

[madshi]

Originally Posted by nlnl

For this sample (PAL DVD film in 50i container)
http://dl.dropbox.com/u/43376972/Pal...nter%20OFF.mkv
Settings:
force film mode
if in doubt, activate deinterlacing,
but OSD says that deinter is off !

So deinterlacing is not on automatically?

madVR is not in doubt for this sample. The MPEG2 stream is set to "progressive_sequence = 1" and the MPEG2 spec says:

When set to '1' the coded video sequence contains only progressive frame-pictures. When progressive_sequence is set to '0' the coded video sequence may contain both frame-pictures and field-pictures, and frame-picture may be progressive or interlaced frames.

[Keiyakusha]

Originally Posted by madshi

Ok, I've checked, it's not a bug in madVR. The problem is pretty simple: The renderer reports to the media player which resolution the video file has and which is the preferred aspect ratio resolution. So madVR reports a video size of 720x480 and a preferred aspect ratio resolution of 853x480. The correct AR resolution would be 853.333333x480, but madVR has no way to pass this information to the media player, so it rounds down to 853x480. Now if you configure the media player to e.g. "touch window from inside" (MPC-HC) then the media player has to figure out which zoom factor to use on the 853x480 video. It could either use zoom factor 1920/853 or 1080/480. When using 1920/853, we would end up with a resolution of 1920x1080.422. That does not fit to the "touch window from inside" option. So MPC-HC instead goes for a zoom factor of 1080/480, which results in 1919.25x1080. The cause of all the trouble is the rounded preferred aspect ratio resolution of 853x480. There isn't really much I can do about that, I think.

P.S: Of course scaling is only performed once!

I see, so madvr always scales to the values that player requests? But in exclusive fullscreen mode maybe you can use your own more precise info?
Or what if you will report to player that frame size is 720x480 but ar is not 853x480 but something higher that divides better

[nlnl]

Originally Posted by madshi

madVR is not in doubt for this sample. The MPEG2 stream is set to "progressive_sequence = 1" and the MPEG2 spec says:

Thank you for the reply!
And please have a look at this
http://forum.doom9.org/showpost.php?p=1588430&postcount=13767

[madshi]

Originally Posted by Keiyakusha

I see, so madvr always scales to the values that player requests? But in exclusive fullscreen mode maybe you can use your own more precise info?
Or what if you will report to player that frame size is 720x480 but ar is not 853x480 but something higher that divides better

If I report something other than 853x480 then the media player will also default (with "Normal Size" zoom setting) to something other than 853x480 which would not be good.

Currently madVR reports what it should report and strictly obeys whatever size/zoom/AR wish the media player has. Of course it would be possible to detect certain situations and override/correct them. E.g. I could always correct 1919x1080 to 1920x1080. But this is something I'm not ready for at this point in time. Maybe some time in the future.

Originally Posted by nlnl

And please have a look at this

You don't really need to remind me. That post of yours is already on my to do list, as are a few others I haven't replied to yet.

[madshi]

Originally Posted by janos666

I just noticed I have a madVR - crash report.txt file on my desktop, so I thought I should send it to the developer.

I noticed the MPC-HC hanged a bit during some file openings but I thought it's the Samba file sharing server to blame.

Weird. This only makes sense to me if 2 madVR instances were open at the same time, which shouldn't really be happening. I guess you can't reproduce this, can you?

[Nevilne]

Could resolution switching logic be improved? My monitor's refresh range is 50-60, and madvr doesn't switch to 50 with 24p content, but it will switch to 50 with 40p content. (madvr options 1080p50, 1080p60)

[madshi]

Originally Posted by Nevilne

Could resolution switching logic be improved? My monitor's refresh range is 50-60, and madvr doesn't switch to 50 with 24p content, but it will switch to 50 with 40p content. (madvr options 1080p50, 1080p60)

60p seems more appropriate for 24p content. You'll get 3:2 pulldown judder, but other than that it should be perfect. With 50p you'll get much uglier motion judder. Unless you use Reclock, of course, to speed 24p up to 25p. 40p content? Never heard of that before...

[Nevilne]

Yeah, forgot to mention I use Reclock. 40p was some game movie content, just used it as example.

[madshi]

Well, I plan to modify the refresh rate changer in a future version. You'll have to wait for that. Can't give you an ETA right now.

[e-t172]

Originally Posted by madshi

To be honest, I don't know how ICC profiles and LUTs loaded in the GPU behave with madVR. Does anybody else know?

Well, LUTs loaded with SetGammaRamp (this includes ICC profile loaders) are still active when playing with madVR, including fullscreen exclusive mode. That's because, AFAIK, the translation is done at a very low hardware level just before the signal is sent to the monitor.

That's why I made a feature request ages ago to have madVR reset these tables (and restore them at the end of playback): to avoid the obvious double conversion issue when using madVR's 3DLUTs and the hardware LUTs simultaneously.

[madshi]

Ah, thanks, that makes sense. Is there something like SetGammaRamp for colors, too? Or does the GPU only support gamma manipulations via ICC profiles? How are colors managed then?

[madshi]

Originally Posted by v0lt

http://samples.mplayerhq.hu/V-codecs...ock-cram16.avi
http://samples.mplayerhq.hu/V-codecs/CRAM/worm.avi
http://samples.mplayerhq.hu/V-codecs...4.apple_ad.mov
http://samples.mplayerhq.hu/V-codecs/CVID/handss.avi
4 Day Weekend.mov
AVI Decompressor (RGB24) + madVR = artifacts
ffdshow (RGB24) + madVR = normal
AVI Decompressor (RGB24) + Color Space Converter(ARGB32) + EVR = normal

I can reproduce the problem, but I don't know how to fix it. From what I can see, it seems to me that the AVI Decompressor is responsible for the artifacts. My best guess is that the AVI Decompressor can't handle the way madVR stores frames into a queue and reuses media sample buffers. If that's really the cause of the problem then it's clearly a bug in the AVI Decompressor. But I'm not 100% sure. Don't really know what to do here...

FWIW, adding the ffdshow raw filter in between AVI Decompressor and madVR fixes the problem.