madVR - high quality video renderer (GPU assisted)

[KeyserSoze17]

@madshi - I'm developing a madvr player for Meedios in C#. Things are going well, but I got hung for a long time trying to test the imadvrtextosd interface. I was tying to send "Play" and "Pause" through the interface, but nothing ever seemed to happen. However, it seems if I send any other text through the interface, it works fine. Is this intended? Doesn't matter, now that I know, i can work around it. Are there any other interface items that have similar characteristics?

Thanks by the way for the time you've spent developing madvr.

[MokrySedeS]

The look should be very similar to playing back at 24Hz.My current display doesn't support this unfortunately, that's why I'm interested.

convertfps(your_new_framerate)If I understood this correctly, madVR would work like this:
AA1BBCC2DDEE3FFGG4HHII5JJKK6LL...
where only the numbers represent frames that are blended. Letters represent untouched frames.
convertfps makes every frame unique.

[alizard]

Madshi, I'm still getting improper levels with 85.4. I get proper levels on some files that I didn't get with 85.3, but levels with 85.2 have been correct for all files I've tested.

[hannes69]

So some testing with 0.85.4
Testing proper colors and performance with scaling and decoding in a comparison between evr custom and madvr. Some very strange results, it´s up to you madshi for interpretation, I say only "strange"....

Test 1: video 1080p (color clipping pattern from AVS) presented on 720p projector, evr set to bicubic 75 scaling, madVR set to softcubic 70 chroma scaling and bicubic 75 luma downscaling. Tested in each renderer software/copyback/native decoding with lav video. CPU load averaged from 4 cores running on 800MHz to get higher load values for higher precision in calculating load.

Result:

EVR+soft: GPU 22 CPU 27
EVR+copyback: GPU 25 CPU 17
EVR+native: GPU 27 CPU 12
mad+soft: GPU 78 CPU 40
mad+copyback: GPU 65 CPU 40
mad+native: GPU 93 CPU 10

Colors in each scenario the same and right.


Test 2: same as Test 1, now with DXVA luma downscaling:

mad+soft: GPU: 27 CPU 29
mad+copyback: GPU 48 CPU 35
mad+native: GPU 56 CPU 23

Colors in each scenario the same and wrong (in the color clipping pattern R, G, B show flashing bars up to 251).
Furthermore render and present queues get empty when using copyback or native decoding.

Test 3: video 720p on projector 720p (no scaling)

evr+soft: GPU 22 CPU 33
evr+copyback: GPU 13 CPU 17
evr+native: GPU 13 CPU 13
mad+soft: GPU 37 CPU 41
mad+copyback: GPU 36 CPU 28
mad+native: GPU 32 CPU 12

Colors all the same and right.


"strange" results in the sense of partial implausible results.

hannes69.

[mark0077]

Audio clock deviation comes into play, too. I'd suggest to lower the interpolation framerate down until you get no more dropped frames. I guess it's probably somewhere between 60.001 and 59.940.

Hi madshi, you're right, lowering the interpolation rate down to 59.990fps even, I get no dropped frames in a 2 hour movie. That leads me to ask, should the "display" rate at the top of the madVR OSD not be used for tweaking such things.

Even though the clock deviation figure is about 0.004%, I thought the display rate would even out over time and that the "display" figure shown could be used as a sort of average. I'm just worried that lowering the interpolation rate down to any particular figure, means I'm getting no dropped frames, but getting repeated frames which I guess aren't very easy to determine and display by madVR. I guess this is why interpolating to 59.94hz, I was seeing no frame drops in madVR OSD but was seeing a few skips / jumps per movie which I assume were frame repeats.

I enabled reclocks vsync for the first time in a long while to see could it prevent frame drops at my original interpolation rate of 60.001 fps but it wasn't.

[Xaurus]

I enabled reclocks vsync for the first time in a long while to see could it prevent frame drops at my original interpolation rate of 60.001 fps but it wasn't.
I was told that madvr has its own vsync and therefore it should be disabled in reclock... works for mysetup, in any case.

[madshi]

External DXVA device enabled:
http://www.mediafire.com/?54skt8lruuijmr3

Disabled:
http://www.mediafire.com/?wooaar2u30w1978

Hope it helps. :)
Oh man. There are weird gaps in the log. Often 20ms or so nothing happens at all. I don't really know what's going on there. Looks really weird. I guess the only way to fix this will be to get a 4K capable NVidia GPU and test it here... :(

Build 34860 fixes this problem with EVR, but the "DisplayLessThan16" script(written by Seb.26) that turns every <16 pixel to green shows that as much as EVR applies it onto the black bars, mVR does not
I don't think there's any good reason to apply custom pixel shaders on black bars which are totally outside the active video area. Doing that would just eat performance with no real benefit.

madVR does all its math on the active video rectangle. Only in the very last processing step, when the final 8bit RGB output is generated, madVR places the video rectangle on the right position in the output image. Running the post-scaling shaders on the whole output image, including added black borders, would be possible, but it would require several changes to the madVR rendering pipeline. And as I said, I don't see any benefit worth the development effort or worth the performance loss.

would you be so kind as to confirm that PotP 1.5.34860 really does apply post- and pre-scaling scripts as advertized? There doesn't seem to be any way for an end-user to check for this
You can test that yourself, e.g. by using this test image:

http://madshi.net/small.png

If you run a sharpening script on this test image *before* scaling, and then scale it up to screen size, you'll get monstrouos ringing artifacts. If you apply sharpening *after* scaling, the look will be totally different with only minor ringing artifacts.

Starting from 0.85.2 until the current release of 0.85.4, image upscaling doesn't work for me when it is set to DXVA. The on-screen display says

I'm on Windows 7 64-bit and a Radeon HD 5670 video card.

Playback works fine as long as the window is smaller than the video's resolution. If I make it larger by expanding the window or going fullscreen, the video stops displaying but the audio is still playing in the background. The video resumes its animation as soon as I make the window smaller again.

Here's the log:

http://bayfiles.com/file/wrCD/vGiZJx/madVR_-_log_2012-12-18_mpc-hc.zip

I didn't notice it until now since I was using Jinc 3AR for upscaling, I only got to check DXVA again recently. >_<;;
Hmmmmm... I'm not sure what's going on here. DXVA2 reports "Access Violation" when I try to do the scaling, but I don't see why DXVA2 would do that. The parameters I feed to DXVA2 look alright to me. Are you using the latest GPU drivers? Maybe updating them would help?

When I got this card, it came with a DVI-to-VGA adapter and since I don't keep peripheral boxes, I hooked it up to the DVI output on the videocard not to lose it. It seems that was the source of the problem!
After I removed it and installed the new driver, indeed the card started sending what it was meant to (16-235) via HDMI, I could hardly believe it!
I immediately verified it, now on the destop I do see different shades of black between 0-16, and of course I do have to set madVR to 0-255 to have proper levels for video playback as well.
In other words, the issue is solved! [the driver is correctly compressing 0-255 to 16-235 my TV expects]

It's crazy that what I thought to be a screenshot issue with madVR turned out to be a totally different one in fact my system had.
So thank you very much to both of you for helping me understand there was something wrong and how it was meant to work!
While it doesn't change anything for movies, it sure does for everything else :D
I'm glad to hear you got this sorted out. Please note, however, that when the GPU converts 0-255 to 16-235 (which is currently does for you) it might introduce some banding. But that depends on the GPU, driver version etc. So you might want to double check that video playback still has the same quality.

I just did the cms calibration using madvr ycms as my pj (jvc rs15) has no cms control. I have to say cie diagram is just perfect after that. It is just awsome how easy it is to get this done. Thanks for your work.
My only complain is that i have nothing else to tweak with this perfect picture. I just have to watch movie and enjoy. :-D
Glad to hear that!

I compared it to Lanczos 3 AR some time ago and and it's not as good as that either, lines are jagged and a little broken up in comparison on my anime content so I couldn't recommend it for anyone concerned with quality.
Ah, that's interesting to hear! It's probably still the best GPU algorithm, though (better than AMD and NVidia).

There's still a slight pixel shift with DXVA enabled, is that okay/expected?
It's not expected, but there's probably nothing I can do about it.

Same pause issue with 85.4 log at http://www.sendspace.com/file/oo390s
Hmmmm... According to the log, both LAV Video Decoder and ffdshow Video Decoder were in the graph. Does that make any sense to you? The cause of the problem is a timing problem. This is the order of things happening in your case:

(1) madVR is created, and creates its window on the default monitor, which is monitor 1 in your case.
(2) The media player connects the pins.
(3) One of the decoders asks madVR for a Direct3D Device. So madVR has to create a Direct3D device at this time already.
(4) After the pins are connected, the media player makes the madVR window a child of the media player window, which practically moves the madVR window to the 2nd monitor.
(5) Since the monitor has changed, madVR has to destroy the Direct3D Device and recreate a new one.

Step (5) is complicated and in this specific case results in playback being paused. Fixing this won't be easy. The main problem is that the media player first connects the pins and only afterwards sets up the madVR window. The correct order would be the other way round. That would fix the problem.

This problem didn't occur in older madVR builds because older builds didn't support step (3). This step is required for DXVA decoding. However, the decoder didn't really seem to do DXVA decoding in your case? Not sure why it then asked madVR for a Direct3D device.

I tried uninstalling then installing with no change but had to change first line of the batch files to get them to work
@cd /d "%~dp0"
Thanks, have added that switch to the install/uninstall.bat files.

Thanks for adding the file tags, esp matrix but this will require me to change 100's of file names. In a future version could there be 2 text field's in settings that users can set to use for 601 and 709 when the bitstream doesn't have the info? I've lived with wrong color matrix for years and it never bugged me until I found out how much of a difference there is and can tell most of the time when it's wrong.
You want *all* unknown files to be treated as 601? Or 709? That doesn't make much sense to me. Not every unknown file has the same matrix, does it? Isn't it much better to let madVR guess the correct matrix based on the resolution? And for those files where that fails, you can use file tags.

@madshi - I'm developing a madvr player for Meedios in C#. Things are going well, but I got hung for a long time trying to test the imadvrtextosd interface. I was tying to send "Play" and "Pause" through the interface, but nothing ever seemed to happen. However, it seems if I send any other text through the interface, it works fine. Is this intended? Doesn't matter, now that I know, i can work around it. Are there any other interface items that have similar characteristics?
I'm sorry that you lost time because of this. madVR currently blocks "Play" and "Pause" (and "Pause" in a few different languages). The simple reason for that is that MPC-HC always shows this message when playback is started or paused, and it screws up the internal MPC-HC subtitle renderer when using madVR. Basically, without blocking the "Pause" message, in the moment when you pause a movie, any subtitles would disappear.

The subtitle problem will soon be solved by using a better subtitle renderer. Then I can remove the "Pause"/"Play" blocking.

I don't think there are any other similar hidden surprises in the madVR interfaces. At least nothing comes to mind right now.

Madshi, I'm still getting improper levels with 85.4. I get proper levels on some files that I didn't get with 85.3, but levels with 85.2 have been correct for all files I've tested.
A few questions:

(1) Do you get improper levels only when using any sort of DXVA (decoding, deinterlacing, scaling)? Or do you also get it when no DXVA is involved at all?
(2) Do you get improper levels only for SD content? Or only for HD content? Or does is vary?

Could you upload a sample of one such file where you get improper levels?

Test 2: same as Test 1, now with DXVA luma downscaling:

mad+soft: GPU: 27 CPU 29
mad+copyback: GPU 48 CPU 35
mad+native: GPU 56 CPU 23

Colors in each scenario the same and wrong (in the color clipping pattern R, G, B show flashing bars up to 251).
Furthermore render and present queues get empty when using copyback or native decoding.
So basically there are now only 2 situations:

(1) When using DXVA scaling, colors are wrong.
(2) When not using DXVA scaling, colors are correct.

No difference anymore between DXVA decoding and software decoding, correct?

Can I have a log file from DXVA scaling, please? And maybe you could upload the test video you got the wrong colors with? Thanks!

I was told that madvr has its own vsync and therefore it should be disabled in reclock...
That's correct.

[ajp_anton]

madVR asks DXVA2 to take the original YCbCr 4:2:0 video frames and convert them to RGB and scale them to the target resolution.
[...]
YCbCr -> RGB color conversion is still performed by madVR.Aren't these two different things?

[leeperry]

I don't think there's any good reason to apply custom pixel shaders on black bars which are totally outside the active video area. Doing that would just eat performance with no real benefit.
Well, IIRC each pixel in Crysis 2 goes through at least a thousand PS scripts and they don't seem too power hungry with EVR either.....but OK, I realize that it's done in a very sloppy way with EVR and I would agree that there's prolly no actual benefit to processing the black bars anyway.


You can test that yourself, e.g. by using this test image:

http://madshi.net/small.png
Goodie, I didn't think of that one! I can confirm that all is well with PotP 1.5.34860 then http://forum-images.hardware.fr/images/perso/ramada.gif

madVR v0.85.4 released

* removed old tagging solution
That'd be really great if the current tags convention could stay as is coz I plan on burning some pesky files and renaming them won't be an option.

:thanks:

[madshi]

That'd be really great if the current tags convention could stay as is coz I plan on burning some pesky files and renaming them won't be an option.
I've no plans to change it again.

Aren't these two different things?
No, hehe. madVR analyzes the color decoding matrix used by the GPU and inverts the GPU's YCbCr -> RGB conversion, so that madVR can apply its own color decoding matrix.

[aufkrawall]

It still doesn't work well on an AMD E-350 with DXVA.
In windowed mode there are lots of dropped frames and in FSE playback shows extreme stuttering/hiccups.

Logs:
http://www.mediafire.com/?s2pn59cg77ypcxd

Crazy AMD drivers (again)? :D

[hannes69]

So basically there are now only 2 situations:

(1) When using DXVA scaling, colors are wrong.
(2) When not using DXVA scaling, colors are correct.

No difference anymore between DXVA decoding and software decoding, correct?

Can I have a log file from DXVA scaling, please? And maybe you could upload the test video you got the wrong colors with? Thanks!

Yes, no more difference between DXVA native / DXVA copyback / software decoding.

Concerning the numbers given by my test: I thought that GPU-load(software) < GPU-load(copyback) < GPU-load(native) should be the expected values and vice versa for CPU load, obviously not the case.

Here the test pattern I used and a debug log:
http://www22.zippyshare.com/v/19080758/file.html

[aufkrawall]

Does display mode change not work for DVDs?
fps are 29.97 but madVR doesn't change to a 59.94Hz custom resolution.
It does work for locally stored container files. :confused:

Edit: Huh, it works if I directly open the vob files but it doesn't if DVD is opened as a whole/video started via DVD menu.

[nevcairiel]

The DVD Navigator is a bit dumb and always claims all DVDs are 25 fps, i believe, and once it figures out that this is not the case, its too late for madVR to change (it only changes once at the start)

[aufkrawall]

Hm, I don't get it.
madVR's OSD clearly shows 29.97fps before I enter FSE with display mode change.

[turbojet]

Hmmmm... According to the log, both LAV Video Decoder and ffdshow Video Decoder were in the graph. Does that make any sense to you? The cause of the problem is a timing problem. This is the order of things happening in your case:

(1) madVR is created, and creates its window on the default monitor, which is monitor 1 in your case.
(2) The media player connects the pins.
(3) One of the decoders asks madVR for a Direct3D Device. So madVR has to create a Direct3D device at this time already.
(4) After the pins are connected, the media player makes the madVR window a child of the media player window, which practically moves the madVR window to the 2nd monitor.
(5) Since the monitor has changed, madVR has to destroy the Direct3D Device and recreate a new one.

Step (5) is complicated and in this specific case results in playback being paused. Fixing this won't be easy. The main problem is that the media player first connects the pins and only afterwards sets up the madVR window. The correct order would be the other way round. That would fix the problem.

This problem didn't occur in older madVR builds because older builds didn't support step (3). This step is required for DXVA decoding. However, the decoder didn't really seem to do DXVA decoding in your case? Not sure why it then asked madVR for a Direct3D device.

It's setup so lav decodes with cuvid or quicksync (computer dependent) then the raw video goes through ffdshow for f3kdb and spline144resize. You are correct there's no dxva. I tried using just LAV or just ffdshow or just mpc and all paused on extended display. So it seems to be an issue way beyond the obscure setups I have here.

Thanks, have added that switch to the install/uninstall.bat files.

Your welcome, it allows cd to change drive. I use non-admin accounts and windows is on C: but madvr is on F: so without /d admin would be looking for C:\madvr even though it was called from F:

You want *all* unknown files to be treated as 601? Or 709? That doesn't make much sense to me. Not every unknown file has the same matrix, does it? Isn't it much better to let madVR guess the correct matrix based on the resolution? And for those files where that fails, you can use file tags.

Nope, first use bitstream if it exists. Second use file tags like matrix= and what is in these text input boxes. I would set it up as *dvd* would use 601 and *bd*|*hd*|*bluray* would use 709. This is how I've labeled almost all of my files until recently been leaving them off but also been setting bitstream. Lastly, go by resolution. I have tons of stuff done at 852 and 960 widths that came from bd or hdtv but madvr sets it to 601 because its below 1050 px wide. Speaking of 1024x576 is there any advantage over 720x576 (16:9 sar/par) other than 1:1 pixels? I haven't seen a player in years that doesn't handle non-square sar/par but haven't seen a whole lot of players either.

[DragonQ]

It's my understanding that to retain as much quality as possible, you should not change the resolution when encoding (if you can help it). So PAL SD rips should be 720x576 or 704x576. Obviously this gets expanded as per the SAR/PAR on playback.

[gonca]

@madshi
Merry Christmas and thanks for a great renderer

[ser_renely]

The DVD Navigator is a bit dumb and always claims all DVDs are 25 fps, i believe, and once it figures out that this is not the case, its too late for madVR to change (it only changes once at the start)

Ahhh, this makes sense. I was losing my mind for a while

[ajp_anton]

I have tons of stuff done at 852 and 960 widths that came from bd or hdtv but madvr sets it to 601 because its below 1050 px wide.If you want things done correctly, your encodes shuld have the correct flags and madVR won't have to guess anything.

[alizard]

It only occurs with DXVA scaling. All other scaling methods and external DXVA de-interlacing and decoding provide proper levels with 85.3 and 85.4.

Here is a sample: http://www.filedropper.com/sample_7

Edit: Ok, now that is strange. The original sample on my computer doesn't play with proper levels, but plays correctly after downloading it off of File Dropper. Also, If I email the sample to myself as an attachment it plays with proper levels. The original copy will only play correctly with 85.2, but if I parse the file through Gmail, File Dropper, or Mkvmerge the file will play with proper levels with 85.4. What kind of voodoo nonsense is going on here?

Edit: I just tried taking a snapshot of the original sample with incorrect levels and the Jpeg even shows the picture with the proper levels. Toggling the output and source levels doesn't fix the problem either. I can't seem to be able to find a way to show you what the original sample levels look like on my TV without them being corrected by whatever means I try to upload to you.

[AndreaMG]

The DVD Navigator is a bit dumb and always claims all DVDs are 25 fps, i believe, and once it figures out that this is not the case, its too late for madVR to change (it only changes once at the start)
For me dvds play at the correct refresh rate if I use MPCHC "autochange fulsceen monitor mode" and not MadVR internal one, though MadVR continues to show 25fps...

[AndreaMG]

MPCHC "autochange fulscreen monitor mode" for me works also perfectly (i.e. switches to the appropriate refresh rate) with SVP (frame interpolator) while MadVR built in switcher at the moment not.

[crotecun]

Hmmmmm... I'm not sure what's going on here. DXVA2 reports "Access Violation" when I try to do the scaling, but I don't see why DXVA2 would do that. The parameters I feed to DXVA2 look alright to me. Are you using the latest GPU drivers? Maybe updating them would help?



I did some testing about this today, here are my results:

1.) Using the latest GPU drivers
I downloaded the latest drivers for my Radeon HD 5670 from the AMD support website. I did a custom install and only installed the drivers, without the Catalyst control center. Even if the drivers were the latest (12.10), playback with DXVA for image upscaling still doesn't work.

I installed all the other software with the driver package except the Catalyst control center. Same result as above.

2.) Using the latest GPU drivers + Catalyst control center
I rolled back to the previous driver. Afterwards I reinstalled using the express option which installs everything in the package. Playback with DXVA for image upscaling now works.

3.) Uninstalling the GPU drivers + Catalyst control center
I tested if I could still play videos with madvr's DXVA even without the latest AMD catalyst.

It turns out that I can! When I re-ran the setup and had it uninstall the software like the Catalyst control center and its included driver, I can still play videos upscaled on MPC-HC with madvr and DXVA as image upscaling algorithm.

My theory here is that installing Catalyst control center unlocks something that would allow madvr to do image upscaling via DXVA.

---

Another test for me is determining how I could get the same quality as before.

In one of my previous posts I mentioned how madvr dxva playback actually looks sharper without the Catalyst control center, than how it looks like when Catalyst control center is installed but with all the video color and quality settings disabled.

It turns out that the "Edge-enhancement" setting in the Catalyst control center video quality panel is responsible for what DXVA2's upscaling looks like.

If it's unchecked, the video output looks similar to bilinear.
If it's checked, the video output looks similar to a Lanczos AR upscale.


My theory here is that the AMD video card driver obtained from windows update has the Edge-enhancement setting enabled, and only that setting: it doesn't seem that any of the other Catalyst video color and quality settings are enabled.

That said, I suggest that when disabling the Catalyst video post-processing options that the Edge-enhancement setting should be left enabled since it seems it's the option that activates Radeon's upscaling algorithms. Otherwise it'll do bilinear by default like Nvidia cards do.

Speaking of which, perhaps there's an option to enable for Nvidia cards to tweak how the Geforce GPUs do upscaling? Hopefully I could find out too when I get my hands on a computer with an Nvidia card.

[madshi]

It still doesn't work well on an AMD E-350 with DXVA.
In windowed mode there are lots of dropped frames and in FSE playback shows extreme stuttering/hiccups.

Logs:
http://www.mediafire.com/?s2pn59cg77ypcxd

Crazy AMD drivers (again)? :D
Hmmm... Rendering takes a lot of time in this log. The E-350 seems to be *really* slow. What happens if you play the same clip in EVR-Custom, with "Full Floating-Point processing" turned on? Does it still run totally smooth?

Does display mode change not work for DVDs?
fps are 29.97 but madVR doesn't change to a 59.94Hz custom resolution.
It does work for locally stored container files. :confused:

Edit: Huh, it works if I directly open the vob files but it doesn't if DVD is opened as a whole/video started via DVD menu.
A log file might help.

It's setup so lav decodes with cuvid or quicksync (computer dependent) then the raw video goes through ffdshow for f3kdb and spline144resize. You are correct there's no dxva. I tried using just LAV or just ffdshow or just mpc and all paused on extended display. So it seems to be an issue way beyond the obscure setups I have here.
Well, there are 3 possible parties to blame here. The media player doesn't do the initialization in a particularly good order. The decoders are asking madVR for a D3D device, although DXVA decoding is disabled, and madVR's D3D device recreation results in playback being paused. Maybe a fix should be done for all 3. However, I can't seem to be able to reproduce the problem on my PC, so it's hard for me to fix madVR's side of things...

Second use file tags like matrix= and what is in these text input boxes. I would set it up as *dvd* would use 601 and *bd*|*hd*|*bluray* would use 709.
Ah, so you want to be able to use custom tags, so to say? Like "bluray=709" or something like that? I'm sorry, but I don't think that this would be used by a lot of people, so I won't put this on my to do list for now. The tagging is a bonus feature, anyway, so I don't really want to complicate the settings dialog for this.

Speaking of 1024x576 is there any advantage over 720x576 (16:9 sar/par) other than 1:1 pixels?
Which context are we talking about here? Encoding? Playback? I've no idea what you mean. If you're talking about encoding, that's not a topic that belongs into this thread. I've no personal experience with encoding and I can't tell you whether encoding to 1024x576 makes sense or not. I can only say that such files exist and are usually PAL. Also some decoders might correct aspect ratio before sending the data to madVR.

My theory here is that installing Catalyst control center unlocks something that would allow madvr to do image upscaling via DXVA.
That kind of makes sense, but it's really bad, of course.

It turns out that the "Edge-enhancement" setting in the Catalyst control center video quality panel is responsible for what DXVA2's upscaling looks like.

If it's unchecked, the video output looks similar to bilinear.
If it's checked, the video output looks similar to a Lanczos AR upscale.


My theory here is that the AMD video card driver obtained from windows update has the Edge-enhancement setting enabled, and only that setting: it doesn't seem that any of the other Catalyst video color and quality settings are enabled.

That said, I suggest that when disabling the Catalyst video post-processing options that the Edge-enhancement setting should be left enabled since it seems it's the option that activates Radeon's upscaling algorithms. Otherwise it'll do bilinear by default like Nvidia cards do.
Interesting. Although I think on my PC I was getting that Lanczos like stuff even with Edge-Enhancement turned off. Not 100% sure right now, though.

Speaking of which, perhaps there's an option to enable for Nvidia cards to tweak how the Geforce GPUs do upscaling?
I don't know. Generally, I don't really recommend using DXVA scaling for ATI and NVidia users. But the option is there, if you want to use it. And of course I'm interested in fixing bugs, if any more show up.

It only occurs with DXVA scaling. All other scaling methods and external DXVA de-interlacing and decoding provide proper levels with 85.3 and 85.4.

Here is a sample: http://www.filedropper.com/sample_7

Edit: Ok, now that is strange. The original sample on my computer doesn't play with proper levels, but plays correctly after downloading it off of File Dropper. Also, If I email the sample to myself as an attachment it plays with proper levels. The original copy will only play correctly with 85.2, but if I parse the file through Gmail, File Dropper, or Mkvmerge the file will play with proper levels with 85.4. What kind of voodoo nonsense is going on here?

Edit: I just tried taking a snapshot of the original sample with incorrect levels and the Jpeg even shows the picture with the proper levels. Toggling the output and source levels doesn't fix the problem either. I can't seem to be able to find a way to show you what the original sample levels look like on my TV without them being corrected by whatever means I try to upload to you.
This sounds really weird. Toggling output and source levels does change the image, though, or does it not? What happens if you rename your original sample? Does it then play with the correct levels? I've no idea what's happening there, to be honest...

Of course your sample plays just fine on my win7 x64 PC with a Radeon 7770. I hate it if I can't reproduce a problem... :(

Yes, no more difference between DXVA native / DXVA copyback / software decoding.

Concerning the numbers given by my test: I thought that GPU-load(software) < GPU-load(copyback) < GPU-load(native) should be the expected values and vice versa for CPU load, obviously not the case.

Here the test pattern I used and a debug log:
http://www22.zippyshare.com/v/19080758/file.html
Unfortunately I can't reproduce the problem on my PC. But I found one interesting thing. Your log contains this:

AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 32, yFactor: 1.00000018, yOffset: 0.00001520, range: 16.00001805..235.00005700
YCbCr -> RGB decoding matrix used by GPU:
1.00000018 0.00000000 1.73250120
1.00000018 -0.21350089 -0.51525045
1.00000018 2.11633475 0.00000000

If I play your sample on my PC, I'm getting this instead:

AnalyzeGpuNv12ToRgb(VideoProcessBlt): +, bitdepth: 32, yFactor: 1.00000024, yOffset: 0.00000380, range: 16.00000760..235.00005955
YCbCr -> RGB decoding matrix used by GPU:
1.00000024 0.00000008 1.54000108
1.00000024 -0.18300063 -0.45800027
1.00000024 1.81400121 0.00000008

The matrix detected on my PC almost matches the generally recommended decoding matrix for BT.709, see here:

http://software.intel.com/sites/products/documentation/hpc/ipp/ippi/ippi_ch6/functn_YCbCr420ToBGR_709HDTV.html

And BT.709 is also exactly what I told DXVA to use. The matrix detected on your PC doesn't match any matrix I know. Which makes me wonder what the GPU drivers are doing on your PC. Seems to be something really weird. At least they're definitely not doing what madVR asked them to do (namely using BT.709).

@alizard and @hannes69, you both seem to have more or less the same issue. I'm wondering whether there might still be some variables we haven't identified yet which would cause the problem. Maybe it only occurs if you move the media player to another monitor, or if you enter fullscreen mode, or if you change refresh rate while the video is playing, or if you open the Catalyst Control Center while the video is playing or something funny like that. Any thoughts on that? The problem for me is that I simply can't reproduce the problem on my PC, so I don't really know what to do about it...

[hannes69]

And BT.709 is also exactly what I told DXVA to use. The matrix detected on your PC doesn't match any matrix I know. Which makes me wonder what the GPU drivers are doing on your PC. Seems to be something really weird. At least they're definitely not doing what madVR asked them to do (namely using BT.709).

Hmmm... If GPU driver is the culprit that means a problem because AMD stopped driver development for cards <= HD4000 series and I am already using the latest driver. Obviously the wrong matrix delivers wrong colors, it´s not just the wrong level, green actually is less saturated than red and blue. Strange behaviour, using a unknown matrix.

Maybe it only occurs if you move the media player to another monitor, or if you enter fullscreen mode, or if you change refresh rate while the video is playing, or if you open the Catalyst Control Center while the video is playing

Tried all of your suggested possibilities, behaviour always the same.
I appreciate your effort and I test what I can test... ;)
I personally watch mostly native resolution so no scaling is needed, and when I need scaling I use other methods than DXVA2. So not that bad for me. It helped me that DXVA native decoding now produces right colors, I prefer native decoding because it lowers CPU and GPU load vs. copyback or software decoding (what is absolutely nice but in my opinion not explainable why that is the case, but my tests delivered that, GPU is in all cases running with identic clocks...).
But of course I think that an option that is offered by a software should work as intended. And I´ll give the support if I can do like log files or testing some scenarios.
hannes69.

Edit: I don´t know if that helps: I tested now behaviour with a vob file (madVR says: matrix BT601, EBU/PAL primaries). So in this case upscaling from PAL. The debug log reveals the same unknown matrix (absolutely the same numbers) like the last one by using DXVA downscaling.

[vaporizer]

my problem with 'start 720p video, windowed -> fullscreen -> windowed -> move to other monitor' with dxva-native - crash
is gone with 0.85.4 !

[madshi]

@hannes69, I guess I can try to double check with an HD3850, which I still have collecting dust here somewhere. Both alizard and you have a 4xxx AMD, so there is a chance it's generation dependent.

[aufkrawall]

Hmmm... Rendering takes a lot of time in this log. The E-350 seems to be *really* slow. What happens if you play the same clip in EVR-Custom, with "Full Floating-Point processing" turned on? Does it still run totally smooth?

Will test this soon.


A log file might help.

http://www.mediafire.com/?3xduws4v48gmjn4

[madshi]

@aufkrawall, I get a "The file you requested has been blocked for a violation of our Terms of Service" complaint when trying to download your log.

[Motenai Yoda]

That said, I suggest that when disabling the Catalyst video post-processing options that the Edge-enhancement setting should be left enabled since it seems it's the option that activates Radeon's upscaling algorithms. Otherwise it'll do bilinear by default like Nvidia cards do.
ee simply apply a sharpen that makes his bilinear scaling to looks like lanczos or bicubic. It's only an unsharpmask, nothing more.

[aufkrawall]

@aufkrawall, I get a "The file you requested has been blocked for a violation of our Terms of Service" complaint when trying to download your log.
Silly Mediafire. :(

At least I can download it now without being logged in to Mediafire:
http://www.mediafire.com/?8wta3wudvmfto2x

[madshi]

Silly Mediafire. :(

At least I can download it now without being logged in to Mediafire:
http://www.mediafire.com/?8wta3wudvmfto2x
The refresh rate changer doesn't seem to become active at all. Are you sure it is enabled?

[aufkrawall]

The refresh rate changer doesn't seem to become active at all. Are you sure it is enabled?
Yep, 100% sure. It works for other files. ;)

[madshi]

Ah, I see. It's a timing problem again, due to the decoder asking for a Direct3D device very early. The framerate information coming from upstream is first zero. Only about 300ms after madVR was created the framerate information is set to the correct value. This should be solvable.

[ajp_anton]

The refresh rate changer doesn't seem to become active at all. Are you sure it is enabled?Shuldn't you put all settings into the log file so you don't have to ask? =)

[secvensor]

When the cursor is on Time Line in Exclusive mode, HotKey sound control in a player do not work.

[turbojet]

If you want things done correctly, your encodes shuld have the correct flags and madVR won't have to guess anything.

I'm aware of this and practice it now but it isn't possible in all encoders, xvid for example.

Well, there are 3 possible parties to blame here. The media player doesn't do the initialization in a particularly good order. The decoders are asking madVR for a D3D device, although DXVA decoding is disabled, and madVR's D3D device recreation results in playback being paused. Maybe a fix should be done for all 3. However, I can't seem to be able to reproduce the problem on my PC, so it's hard for me to fix madVR's side of things...

edit: Latest mpc-hc plays without pausing so maybe it's a problem with mpc-be, have you tried using this player? mpc-be 1596 (http://www.mediafire.com/?bf3cl1cfwaoc7) works. 1618 and 1686 (http://aleksoid.voserver.net/MPC-BE/) do not.

Ah, so you want to be able to use custom tags, so to say? Like "bluray=709" or something like that? I'm sorry, but I don't think that this would be used by a lot of people, so I won't put this on my to do list for now. The tagging is a bonus feature, anyway, so I don't really want to complicate the settings dialog for this.

I don't mean adding bluray=709 to the file name if that's what you mean. I'm talking about taking advantage of having the source in filename, which frankly should be a very reliable way to set the color matrix no matter what the resolution. But I guess I'll have to try to write my own program to add matrix= to all these files.

Which context are we talking about here? Encoding? Playback? I've no idea what you mean. If you're talking about encoding, that's not a topic that belongs into this thread. I've no personal experience with encoding and I can't tell you whether encoding to 1024x576 makes sense or not. I can only say that such files exist and are usually PAL. Also some decoders might correct aspect ratio before sending the data to madVR.

The exact advantage in encoding isn't relevant but if there's no advantage it is because you are choosing to use this obscure way of encoding to determine color matrix rather than using 720. Sure they exist but do think they are more common than 721-1050 pixels wide encoded from hd sources? If no, then why not use 720 or give us the option? It would all but eliminate the need for custom tags in my situation.

With 85.4 dxva2 resizing is a lot less of a load then when it was first introduced, a bit less than bicubic. Can madvr change the settings of edge enhancement and noise reduction? nvidia and intel allows application control in it's control panel. Reason for this is the control panel settings affect more things, such as html5 video, and some may want to use different settings on in different programs.

[alizard]

Renaming the file doesn't help either. Toggling the source and output levels does change the picture, but not to the correct levels. It just makes blacks slightly less grey.

Both my 85.2 and 85.4 log files yield the same faulty matrix values that hannes69 has. What is strange is that there is no level problem when playing the file with 85.2, so logic would dictate that the problem must lie elsewhere.

Here is my 85.2 log file: http://www.filedropper.com/madvr-log852

Here is my 85.4 log file: http://www.filedropper.com/madvr-log854

Edit: I checked to see if it would play correctly on my primary monitor and I still get the same problem that I get when playing it on my secondary monitor.

[leeperry]

why not use 720 or give us the option? It would all but eliminate the need for custom tags in my situation.
Personally I've got a good bunch of 960x540 movies that are 1/4 HD encodes requiring 709 matrix & gamut so I agree that an extra option to choose the SD/HD limit ourselves would be really great. These days, there will be far more x>720 movies being HD encodes than upscaled PAL DVD's IMO.

But we can tag them now and for the files that have already been burned we can roll the matrix with a hotkey so it's not such a big deal, I've seen worse :D

I also agree that anything that says ".bluray." in the filename should use 709 matrix/gamut and ".pal." 601/EBU but no big deal again as this is kinda debatable I guess.

[Niyawa]

Hey madshi. Thanks for madVR, it's the best renderer out there.

I wanted to ask a quick question. In page 817 you said something about madVR not really do well with 24p@60Hz, and that's exactly what ReClock sets the video at. Is it safe to use ReClock with madVR or I better just deal with 23.976 content in my 60Hz screen alone? I already removed it from my guide to be safe, but depending on your answer, I might put it back again.

[bugmen0t]

@Niyawa
The problem isn't about ReClock, it's about framerate of the movie and displayrate of the monitor not beeing an integer multiple. madVR can't do a proper pulldown for now, but madshi said he will fix that somewhere in the future. So yes, it's safe to use ReClock, but in won't fix the problem.

[toniash]

¿Someone has tried MADVR with usb2hdmi devices?

[Niyawa]

@Niyawa
The problem isn't about ReClock, it's about framerate of the movie and displayrate of the monitor not beeing an integer multiple. madVR can't do a proper pulldown for now, but madshi said he will fix that somewhere in the future. So yes, it's safe to use ReClock, but in won't fix the problem.
So basically, even if I use ReClock + madVR, it won't make any difference to the pulldown. I was a little confused about this because madVR OSD was telling me that with ReClock the repeated frames average was only in 2-3 hours. Without it it comes back to 15 seconds.

Well, it's still useful for 25p > 24p but dunno if that works too. Thanks anyway.

[AndreaMG]

@Madshi,

I don't know if you can/want answer to this, but is bugging me: recently you talked about 3D support into MadVR, this means that we will be able to actually play 3D blu-ray discs with the combination MPCHC+MadVR+LAV+AnydvdHD+NVIDIA 3D Vision?

Thanks :)

[sneaker_ger]

You would still need an MVC decoder, which currently neither LAV nor madVR provide.

[bugmen0t]

@Niyawa
ReClock correcting the timings and madVR doing a proper pulldown are two different things. ReClock works fine, doing what it should do. madVR was made for high quality playback and pulldown is only a compromise and therefore madshi/mathias/matze/karl heinz otto/the programmer formerly known as madshi :D left handling that for later versions.

[Niyawa]

I see, thanks for the help bug, much appreciated.

[madshi]

Shuldn't you put all settings into the log file so you don't have to ask? =)
I guess that would make sense. Have added that to my to do list.

When the cursor is on Time Line in Exclusive mode, HotKey sound control in a player do not work.
You mean the mouse cursor? Do no media player hotkeys work in that situation at all? Or does just this one hotkey stop working? This specific sound control hotkey is a media player defined hotkey, correct? Or is it from some external software?

edit: Latest mpc-hc plays without pausing so maybe it's a problem with mpc-be, have you tried using this player? mpc-be 1596 (http://www.mediafire.com/?bf3cl1cfwaoc7) works. 1618 and 1686 (http://aleksoid.voserver.net/MPC-BE/) do not.
That's interesting. I'm not sure why it only occurs with some revisions.

The exact advantage in encoding isn't relevant but if there's no advantage it is because you are choosing to use this obscure way of encoding to determine color matrix rather than using 720. Sure they exist but do think they are more common than 721-1050 pixels wide encoded from hd sources?
I don't really know. When I wrote that code I think I asked what values I should use a long time ago in this thread, and the answer I got was what madVR does now. Of course nothing is set in stone. If the general consensus is to detect > 720 as HD now, I'm willing to consider that. However, the consensus was different when I started writing madVR. I'm not sure if the situation has changed. So why would it be different now than it was when I asked the last time? So I'll need more than 2 people confirming that madVR's behaviour should be changed. Otherwise I'm in danger of changing now, and then someone else will cry about all his PAL files being misdetected as HD by the latest madVR build.

If no, then why not [...] give us the option?
Because every added option makes the settings dialog more difficult. I don't want to end up with an ffdshow like settings dialog with 3 billion different settings. Do you know why ffdshow has a settings dialog like that? Because there was no one saying "no" when users asked for all kinds of funny options.

With 85.4 dxva2 resizing is a lot less of a load then when it was first introduced, a bit less than bicubic. Can madvr change the settings of edge enhancement and noise reduction? nvidia and intel allows application control in it's control panel. Reason for this is the control panel settings affect more things, such as html5 video, and some may want to use different settings on in different programs.
Yes, madVR could ask DXVA to do edge enhancement and noise reduction with specific values. But I'm not sure how many users would actually want to use this. Also, I'm not sure if it's a good idea to add edge enhancement and noise reduction sliders to the settings dialog when they only work with DXVA scaling - which I don't really recommend to use for ATI and NVidia users, anyway!

Personally I've got a good bunch of 960x540 movies that are 1/4 HD encodes requiring 709 matrix & gamut so I agree that an extra option to choose the SD/HD limit ourselves would be really great. These days, there will be far more x>720 movies being HD encodes than upscaled PAL DVD's IMO.
Shouldn't the encoders these days know that they should store the needed matrix and primaries into the bitstream?

I don't know if you can/want answer to this, but is bugging me: recently you talked about 3D support into MadVR, this means that we will be able to actually play 3D blu-ray discs with the combination MPCHC+MadVR+LAV+AnydvdHD+NVIDIA 3D Vision?
I don't really like to comment too much about future features. What I can say is that I'm not going to do any extra work to support NVidia's propriaraty 3D shutter glasses etc, if that's what you mean with "NVidia 3D Vision".

Renaming the file doesn't help either. Toggling the source and output levels does change the picture, but not to the correct levels. It just makes blacks slightly less grey.

Both my 85.2 and 85.4 log files yield the same faulty matrix values that hannes69 has. What is strange is that there is no level problem when playing the file with 85.2, so logic would dictate that the problem must lie elsewhere.

Here is my 85.2 log file: http://www.filedropper.com/madvr-log852

Here is my 85.4 log file: http://www.filedropper.com/madvr-log854

Edit: I checked to see if it would play correctly on my primary monitor and I still get the same problem that I get when playing it on my secondary monitor.
Ok, I've compared v0.85.2 and v0.85.4 sources and found one thing that changed which could eventually cause this. Here's a test build:

http://madshi.net/madVR854colorTest2.rar

Does this fix the issue? @hannes69, could you please test this build, too?

(Edit: Updated test build.)

[aufkrawall]

I've tested the E-350 with full floating point processing: It fails hard, terrible frame drops.
So, it's too slow?