madVR - high quality video renderer (GPU assisted)

[Razoola]

Originally Posted by madshi

Sounds weird. If you think it worthwhile, maybe you could try to reproduce the problem? You could do it like this: (1) Downgrade to v0.50. (2) Change any of the settings and "apply" to make sure that the settings.bin is created by v0.50. (3) Change the settings to what you had before upgrading to v0.51. (4) Re-Upgrade to v0.51. Does the problem occur again?

How about frame drops etc? Can you comment on whether the new rendering path is now better/identical/worse compared to v0.49? Thanks!

I tried to reproduce the situation with the method you suggested but it did not happen again.

Yes the new 051 exclusive mode is as smooth as 049, the frame repeat issues I had are gone. As far as proformance goes I never had any issues with 049 so I can't really report anything on that front.

One thing I have noticed with 051 is coming in and out of full screen does not feel as smooth as 049.

[Qaq]

Thanks for new version.
Win7 x86, ATI 5450 (512Mb, DDR3). Tried 0.51 with 720p/24 video.
For me results look almost the same as with 0.50. CPU usage little bit less now, but still 4-5 times more than with 0.49. Funny, RAM usage now looks big too. In FS mode it's still bit stuttering and in windowed mode playback is smooth. OSD keeps the same values if I switch between FS and W modes. Decoder queue is about 7-8/8, no drops. Went back to 0.49 to watch the movie. BTW, I'd like to diagnose more, but didn't find any manual (how to make logs, etc).

[6233638]

Originally Posted by madshi

Why is that? Chroma is stored as Cb and Cr. 4:2:2 simply throws away half of the Cb and Cr values. I don't see why that should affect green less than red?

Green is the Y channel, isn't it? Or is that just a photography thing where "luminance" is always the green histogram, and sensors are RGGB.

Green is perhaps not completely untouched but the difference is clear. 192 red, 160 green, 255 blue.

4:4:4 PC mode:

4:2:2 Cinema mode:


(not sure why the font looks weird in the photos it's fine on the screen)

Originally Posted by madshi

Most HDMI chips don't really support 1080p120 yet. Not enough bandwidth. You can do 1080p24 3D or you can do 1080i60 3D, but not 1080p60 3D. Except side-by-side, of course, cause that doesn't consume more bandwidth than 2D.

Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.

[nevcairiel]

Originally Posted by 6233638

Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.

The spec is fine, its the hardware implementation thats just too slow and cannot handle the full bandwidth.

Originally Posted by fastplayer

Just in case you're wondering where that part is hidden inside of MPC-HC:
FGManager.cpp, line 2205-2210.

@madshi
I took the liberty of fixing this for you, also marking madVR compatible with the sub renderer in the Output configuration GUI (in r3025)

[6233638]

Originally Posted by nevcairiel

The spec is fine, its the hardware implementation thats just too slow and cannot handle the full bandwidth.

The HDMI 1.4 spec doesn't make 1080p60 in 3D a standard option. There should have been a HDMI 1.5 spec with 3D's introduction to make it a requirement.

[ajp_anton]

When paused, and you move the mouse up and down very fast between showing the seekbar and not showing it, occasionally it will get stuck at either showing it or not. If it doesn't show, it will still be there (you can seek by clicking where the seekbar should be). This gets reset when you seek or play (update the movie image).

[Plutotype]

Originally Posted by madshi

Please double check if you really have v0.51. Sometimes the browser doesn't really download a new version but gives you an older zip from the browser cache. I guess that you're still running v0.50? Just a guess, though.

Im definately on 0.51.
Regarding seeking in paused mode - maybe Nevcairel can help - it happens only with VC-1 videos. H.264/MPEG2 are ok. Additionally, when paused and skipping in the timeline the frames are corrupted:
http://img816.imageshack.us/f/paused1.png/
http://img405.imageshack.us/f/paused2.png/
http://img713.imageshack.us/f/paused3.png/

The second issue is, mentioned by anton too - in fullscreen exclusive mode the seekbar does not show always when video is paused and you move over it with the mouse.

[yesgrey]

Originally Posted by madshi

Why is that? Chroma is stored as Cb and Cr. 4:2:2 simply throws away half of the Cb and Cr values. I don't see why that should affect green less than red?

For BT.709:
R = 1.0*Y + 1.5748*Cr
G = 1.0*Y - 0.1873*Cb - 0.4681*Cr
B = 1.0*Y + 1.8556Cb

If you analyse the above functions carefully, you will see that Cb and Cr have a small influence on Green, but a big one on R and B. So, It's natural that green has more resolution, because the Y resolution is kept intact for every pixel.

[ajp_anton]

Is the decoder supposed to pass the color matrix to the renderer? Tested madVR, EVR and Haali, plus exporting RGB from ffdshow.
ffdshow apparently used the correct matrix, but Haali was the only renderer that correctly used the 601 matrix on a HD test video. (edit: nevermind, see later post)

[Andy o]

Originally Posted by 6233638

Green is the Y channel, isn't it? Or is that just a photography thing where "luminance" is always the green histogram, and sensors are RGGB.

I'm pretty sure this depends on the camera, I've had Canons which offer both luminance and RGB histograms, and luminance is not the same as green channel.

4:4:4 PC mode:

4:2:2 Cinema mode:


(not sure why the font looks weird in the photos it's fine on the screen)

Which screen is that? I think my Pioneer Kuro does the same with PC and video modes.

Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.

I think madshi meant 1080/120p or 1080/60p 3D. Regular 1080/60p is not a problem, I think all 1080p HDTVs can do it.

[fiver]

Got a new Envy 17 3D, madvr does not work with Radeon 6850. Custom EVR pres works fine.

Tested with madvr .50, and .51.

Tested with last offical release of MPC-HC and xhmikosr build from the other day (SVN 3021)

Issue: When loading any media type, MPC-HC hangs indefinitely on a black screen.

This laptop has switchable graphics, when I switch to the onboard intel GPU madvr works fine.

Let me know whatever you need for debugging, consider me your servant.

[pankov]

madshi,
I'm very impressed with the way v0.51 works - CPU usage is OK and it's smooth as butter with the few short clips I tested.

I'm going to watch a couple of episodes now just to check a longer time performance

[SamuriHL]

Tested on my AMD machine. Working great! I haven't had a chance to test on my nVidia box which is where the CPU usage was high last night. It'll probably be tomorrow before I can do that.

[6233638]

Originally Posted by Andy o

I'm pretty sure this depends on the camera, I've had Canons which offer both luminance and RGB histograms, and luminance is not the same as green channel.

It was on all the Canons I've ever used. (just slightly more detailed due to the larger scale)

Originally Posted by Andy o

Which screen is that? I think my Pioneer Kuro does the same with PC and video modes.

Sony HX909. I could be mistaken but I don't think the Kuros offered 4:4:4 at all. Been too long since I had one to be sure though. (liked the black level, disliked everything else)

[ajp_anton]

Also, about the red OSD and green having a higher res...
I'd imagine the OSD being rendered in RGB, where there is no resolution difference between different colors. Right?

[Andy o]

Yeah, but the difference is in the screens. My NEC LCD shows the red letters as clear as anything else, but the Kuro looks like the photo the guy above showed.

[SamuriHL]

I don't think we really get a vote, but, hypothetically if we did, I'd vote for green. I can't read the red very easily on my SXRD screen.

[mrcorbo]

I did a search, but didn't see this problem listed before, so I wanted to report the following behavior.

I have MPC-HC's "auto-change fullscreen monitor mode" enabled. If I toggle the player between fullscreen and windowed, which also causes a monitor resolution change, It immediately locks the player. The video area is black and you can see where mpc-hc was able to draw some of the window elements before it hung.

This happened with both the old and new exclusive renderer with and without desktop composition turned off and even with exclusive fullscreen mode turned off. Is there any way that this can be fixed? I like this renderer enough that I'd probably choose to disable the fullsceen mode switch before I stopped using MadVR, but it would be nice to not have to choose.

Edit:My apologies. I forgot to include my system details:

Windows 7 x64, ATI HD 6970 (Cat 11.4preview), MPC-HC revision 3016

[Andy o]

I still get higher CPU usage. It's difficult to tell if it's less than before, but the difference is that most of the higher usage before was on one core. Here it seems the difference is spread out to two cores. The dip in the middle is where I switched from new to old exclusive.



Here's my previous graph for comparison:

[ajp_anton]

Originally Posted by ajp_anton

Is the decoder supposed to pass the color matrix to the renderer? Tested madVR, EVR and Haali, plus exporting RGB from ffdshow.
ffdshow apparently used the correct matrix, but Haali was the only renderer that correctly used the 601 matrix on a HD test video.

Did some more testing. So it's a 720p video encoded at both 601 and 709, with flags set correctly.

ffdshow is the only one that can convert these to RGB correctly, every renderer fails.
EVR and madVR assumes the clip is 709, probably because of the resolution. Don't know if it can be manually changed.
Haali and "video renderer" assumes the clip is 601. Yes, Haali is set to "auto". Don't know about VR's settings.

edit: I also did a 0-255 range test, and again ffdshow is the only one that didn't fail.
edit2: So adding to the original question "Is the decoder supposed to pass the color matrix to the renderer?", what about the fullrange flag? ffdshow was used as the decoder for all tests.