madVR - high quality video renderer (GPU assisted)

[djsolidsnake86]

another important suggestion: madvr don't scale correctly mpeg files (i see those video a little squared)

[namaiki]

^^ Seems to support the idea that something in the chain doesn't like video of width that isn't cleanly divisible by 16. http://forum.doom9.org/showthread.php?p=1399112#post1399112

^ Depends where the aspect ratio is being set.

[Jong]

yeah, 25fps needs to die...w/o Reclock doing its job bye bye 24fps.I do agree with you, just because that's the speed of movie and we have to accept that.

But actually I'm quite fond of 50hz together with Reclock.

First, 25p is smoother. 24fps is so slow that extra 4% does make a difference. Doesn't matter if you are displaying the same frame 2 times or three times or 4 times you still only have 24 real frames per second.

Secondly, with Reclock, 50Hz is a reasonable playback speed for all media - no need for constantly changing screen refresh rates.

- true 25p, of course
- 24p sped up to 25p, as on PAL DVD (yes, I agree it's not perfect, but some of us at least are used to it!)
- 29.97fps sped up to 30fps and displayed with a regular 2:2:1 cadence. Not perfect, but not so very different from 3:2 pulldown and pretty acceptable for most "video" content (for me, typically movie extras and a few chat shows!)

But yeah, movies are 24p, so that is the way of the future. Hopefully, future TVs will resync a lot faster. :(

[namaiki]

By the way, random, but Forceware 195.62 doesn't seem to like MadVR 0.12

[leeperry]

25p is smoother.
yes, most definitely! but then the audio is 4.2% too fast(25/24), or you need to resort to timestretch and everything sounds awful and garbled...movies are shot in 24fps, until ppl like James Cameron manage to push for 48fps that's the only way...except if you like chipmunks that is :p

[Jong]

yes, most definitely! but then the audio is 4.2% too fast(25/24), or you need to resort to timestretch and everything sounds awful and garbled...movies are shot in 24fps, until ppl like James Cameron manage to push for 48fps that's the only way...except if you like chipmunks that is :pYes, as I said 24p is the future, but not because it is better... because like it or not that is the standard.

[namaiki]

How about just 60Hz, for that is close enough for 29.970 and for 23.976, we have 60/2.5-> 24Hz (or is there something big I'm missing with this one).

[Jong]

Because 3:2 pulldown needed for 23.976@59.94Hz or 24@60Hz is really not smooth.

Some in NTSC-land do not notice it, like many in PAL-land do not notice the pitch change in PAL speedup (without a back to back comparison), but it is nasty. Smooth playback (at least as smooth as 24p can get... as good as in the cinema) requires the refresh rate to be a whole multiple of the frame rate.

[namaiki]

edit: don't worry. I can notice when 29.970/30fps is off, but I can't notice when 23.976/24fps is off as it's slower(or probably because it's always off for me ;P). Besides, my screen's pretty much stuck at 60Hz anyways.

[starla]

Yes, as I said 24p is the future, but not because it is better... because like it or not that is the standard.

PAL 25/50 is standard as well and it wont ever go a way since it is used in (all) European countries for tv broadcasts.

[leeperry]

24p is the future, but not because it is better... because like it or not that is the standard.
24p is the long past, the present and most likely the future indeed http://forum-images.hardware.fr/images/perso/anti.gif

some ppl push for 48fps more than 4K, let's hope it'll get somewhere: http://gadgets.boingboing.net/2008/04/15/red-scarlet-3k-camco.html
my screen's pretty much stuck at 60Hz anyways.
a quick tearing test will tell you if your display internally converts to 60Hz.

[namaiki]

a quick tearing test will tell you if your display internally converts to 60Hz.
The input is 60Hz as well. :D

[Jong]

PAL 25/50 is standard as well and it wont ever go a way since it is used in (all) European countries for tv broadcasts.Yes, true. We should have said we were talking about movies. However, US Drama and even much "PAL" TV Drama is originally made at movie frame rate ie. 24p.

[ajp_anton]

Green bar at the top + chroma chifted: (500kB)
http://www.multiupload.com/AOR2BYG2O8
Seems to happen on all videos with height=360.

Green bar to the right: (5.5MB)
http://www.multiupload.com/89XRJLP0V6
This is supposed to be 852x480. madVR adds some green to reach 864, other renderers seem to just upscale it there. Don't know what the DAR really is, it's downloaded from Youtube.

[namaiki]

I can't seem to reproduce the first one (or it is happening, but I don't notice): http://img46.imageshack.us/img46/6199/77806973.png

The second crashes my CoreAVC.

edit: The above issues occur with MPC-HC's internal filters. No crashes.

[ajp_anton]

This (http://img214.imageshack.us/img214/7114/madvr.png) is what I get on the first one, using MPC-HC's internal filters.
BTW I'm getting "GetDIB failed, hr = 80004005" when I try to take screenshots with MPC-HC.

[namaiki]

ajp_anton: press '1' and then press Alt + Print Screen and problem essentially solved.

[JaylumX]

Please click thumb for full image

http://img225.imageshack.us/img225/6966/serenitya.th.jpg (http://img225.imageshack.us/i/serenitya.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

I get this using MadVR renderer with MPC-HC internal H.264/VC-1 filters. I don't get this problem with ffdshow. I would use ffdshow to decode this content but performance with vc-1 encoded movie using Libavcodec and wmv9 is extremley poor and stuttery. As you can see i would like MadVR working with MPC-HC internal filter or better still someone help me sort out the poor vc-1 decoding performance of ffdshow.

NB: Just to add, the poor vc-1 performance i am refering to is when hardware acceleration is disabled (dxva_off) because MadVR automatically disables dxva forcing ffdshow to use software rendering. H.264 software rendering is just as fast as if i had dxva on so i see no reason why vc-1 software perfromance is so poor

Using Windows 7 with Catalyst 10.4 on HD5870 with lastest build of ffdshow (ffdshow_rev3444_20100518) and MPC-HC (mpc-homecinema.1.3.1896.0.x86). This problem was present when i had my Nvidia Geforce 260

Help me please

Any help will be appreciated

Cheers

[Thunderbolt8]

I get this using MadVR renderer with MPC-HC internal H.264/VC-1 filters. I don't get this problem with ffdshow. I would use ffdshow to decode this content but performance with vc-1 encoded movie using Libavcodec and wmv9 is extremley poor and stuttery. As you can see i would like MadVR working with MPC-HC internal filter or better still someone help me sort out the poor vc-1 decoding performance of ffdshow.I've already requested for multithreading for vc-1 to be imbedded in ffmpeg 2 years ago, but unfortunately nothing happend until now :/

[namaiki]

I've already requested for multithreading for vc-1 to be imbedded in ffmpeg 2 years ago, but unfortunately nothing happend until now :/

Is there like a 'test' build available anywhere?

[Thunderbolt8]

afaik no one ever worked on this at all. only avc multithreading has been done.

[namaiki]

Have you tried the Microsoft DTV-DVD Video decoder? (I would think it supports VC-1) Please test without DXVA if you have any VC-1 content.

[Thunderbolt8]

which one is that and wherer can I find it?
I've only tried the WMVideo decoder DMO, but that one apparently cannot do multithreading either. people told that it only looks like both cores are used in task manager.

[namaiki]

That one's on Windows 7. I forgot to ask.

[Thunderbolt8]

only got xp, sorry.

[fastplayer]

I get this using MadVR renderer with MPC-HC internal H.264/VC-1 filters.
How to use: (http://forum.doom9.org/showthread.php?p=1271417#post1271417)
(2) madVR only accepts "YV12" and nothing else. So make sure that the decoder you're using actually outputs YV12, or else madVR will not work. I've intentionally limited madVR in this way because outputting YV12 is simply the best quality option.

[namaiki]

^How do you force or make sure that MPC-HC's internal filters are outputting YV12? In filter properties, it is reported that it is outputting YV12.

[fastplayer]

^You can't unless I totally missed something.
AFAIK, it's only YUY2 resp. NV12 for DXVA.

In filter properties, it is reported that it is outputting YV12.
Probably, just reporting what the renderer accepts. MPC is just forcing YUY2 on madVR.

madshi, can you comment on this? What is happening in the background in MPC when using a non-YV12 color space?

[JaylumX]

How to use: (http://forum.doom9.org/showthread.php?p=1271417#post1271417)

Reclock reports the video stream as yv12

EDIT: Also if ffdshow vc-1 decoder is not miltithreaded and is the cause of its poor performance how come mpc-hc internal vc-1 filter runs a lot better? I thought it was based on the same libraries as ffdshow

[namaiki]

Did you try the Microsoft DTV-DVD Video decoder? Just add it as preferred in 'external filters.

madshi, can you comment on this? What is happening in the background in MPC when using a non-YV12 color space?

From what I have tested (fed it RGB32 only), MadVR simply does not load, and VMR7(windowed) loads instead.

[JaylumX]

Did you try the Microsoft DTV-DVD Video decoder? Just add it as preferred in 'external filters.



From what I have tested (fed it RGB32 only), MadVR simply does not load, and VMR7(windowed) loads instead.

I set the microsoft decoder to prefered but it is ignoring the vc-1 content and reverting to the wmvdecoder which is blank and doesn't playback (doesn't decode vc-1 in a ts container). Does the microsft decoder support vc-1?

[namaiki]

I don't know. :p

I thought it might do VC-1 since it does MPEG-2 and H.264, but it seems that it doesn't.

[namaiki]

In ffdshow video decoder configuration, try set number of deciding threads to 2 or so, under 'Decoder options.' I don't know what it affects, but it might be worth a try if you haven't looked there.

[JaylumX]

In ffdshow video decoder configuration, try set number of deciding threads to 2 or so, under 'Decoder options.' I don't know what it affects, but it might be worth a try if you haven't looked there.

It is already set to 4

[TinTime]

Please click thumb for full image

http://img225.imageshack.us/img225/6966/serenitya.th.jpg (http://img225.imageshack.us/i/serenitya.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

I get this using MadVR renderer with MPC-HC internal H.264/VC-1 filters. I don't get this problem with ffdshow. I would use ffdshow to decode this content but performance with vc-1 encoded movie using Libavcodec and wmv9 is extremley poor and stuttery. As you can see i would like MadVR working with MPC-HC internal filter or better still someone help me sort out the poor vc-1 decoding performance of ffdshow.

NB: Just to add, the poor vc-1 performance i am refering to is when hardware acceleration is disabled (dxva_off) because MadVR automatically disables dxva forcing ffdshow to use software rendering. H.264 software rendering is just as fast as if i had dxva on so i see no reason why vc-1 software perfromance is so poor

Using Windows 7 with Catalyst 10.4 on HD5870 with lastest build of ffdshow (ffdshow_rev3444_20100518) and MPC-HC (mpc-homecinema.1.3.1896.0.x86). This problem was present when i had my Nvidia Geforce 260

Help me please

Any help will be appreciated

Cheers

This seems to be a problem with the latest MPC-HC VC-1 filter. The 1.3.1249.0 standalone filters from sourceforge work fine with madVR, but the latest standalone filters (or MPC-HC itself) don't.

[JaylumX]

This seems to be a problem with the latest MPC-HC VC-1 filter. The 1.3.1249.0 standalone filters from sourceforge work fine with madVR, but the latest standalone filters (or MPC-HC itself) don't.

It bloody worked :eek: Your sir are a gentleman and a scholar. Thank you for that excellent piece of lateral thinking :D

Much abbliged :cool:

You rock

[janos666]

Is there any estimation about the exclusive mode with DeepColor support?
I am thinking about to change my l220x to an U2410. It would be nice if madVR could output 10 bit/color signal and may be I could do a real Rec709 -> sRGB or x^2.2 gamma correction with 3DLUT, without loosing too much color gradient. (It results in very blocky dark scenes with 8 bit/color output). It could be a nice benefit. (And if it still fails with 10 bit/color, at least I could use the real, undithered 10 bit output with linear color gradients...)
But I am not sure if it would be a great business for me until I can use these features. So, I am curious if it could happen in some months or it can take a half year or more...

JaylumX - I would recommend to use the latest FFDShow SVN build from sourceforge and disable any internal filter in MPC-HC. (Expect TS demuxer because the latest haali filter do not want to read the DTSHD-MA track from .m2ts files for me - not even it's 1.5Mb/s DTS core. The latest MPC-HC can do it well - expect it fails to read the track names...)

[yesgrey]

may be I could do a real Rec709 -> sRGB or x^2.2 gamma correction with 3DLUT, without loosing too much color gradient. (It results in very blocky dark scenes with 8 bit/color output).
I already have found the source of the problem. It's not an output bitdepth limitation. Soon we would discuss this in the new thread I will create soon. Unfortunately, some last minute details forced me to delay it a little more...

[BeNooL]

I already have found the source of the problem. It's not an output bitdepth limitation. Soon we would discuss this in the new thread I will create soon. Unfortunately, some last minute details forced me to delay it a little more...

Very interesting! Keep us updated when the thread is created :thanks:

[madshi]

I'm having problems with some wmv files. Found a small one that won't play:
http://www.multiupload.com/PFEET9HBGS
Using MPC-HC with internal decoder.
Green bar at the top + chroma chifted: (500kB)
http://www.multiupload.com/AOR2BYG2O8
Seems to happen on all videos with height=360.

Green bar to the right: (5.5MB)
http://www.multiupload.com/89XRJLP0V6
This is supposed to be 852x480. madVR adds some green to reach 864, other renderers seem to just upscale it there. Don't know what the DAR really is, it's downloaded from Youtube.
Thanks, will have a look at that.

I have intel G45 video card, which support non power of 2 texture, But madVr report: "graphics card only supports power of 2 textures".
Are you sure that the G45 does support non-power-of-2 textures? Because madVR only complains about that if the GPU reports that it doesn't support that feature.

General
Complete name : C:\Users\Andy\Desktop\Nuova cartella\doll.wmv
Format : Windows Media
File size : 10.3 MiB
Duration : 2mn 21s
Overall bit rate : 612 Kbps
Maximum Overall bit rate : 1 024 Kbps
Encoded date : UTC 1970-01-01 00:00:00.000

Video
ID : 1
Format : WMV2
Codec ID : WMV2
Codec ID/Info : Windows Media Video 8
Description of the codec : wmv2
Duration : 2mn 21s
Bit rate : 354 Kbps
Width : 638 pixels
Height : 274 pixels
Display aspect ratio : 2.35:1
Frame rate : 23.976 fps
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.085
Stream size : 5.96 MiB (58%)

this is the mediainfo of the wmv file that don't work with madvr (with evrsync yes)
you are right, other wmv files work correctly!
another important suggestion: madvr don't scale correctly mpeg files (i see those video a little squared)
I need samples.

^How do you force or make sure that MPC-HC's internal filters are outputting YV12? In filter properties, it is reported that it is outputting YV12.
There's nothing you need to do. If the decoder supports YV12 at all, it will automatically be used, when using madVR, because madVR only accepts YV12 and nothing else.

Is there any estimation about the exclusive mode with DeepColor support?
I don't give version estimates.

It results in very blocky dark scenes with 8 bit/color output.
madVR does not produce any blocking in dark scenes. I think there's a bug in the current cr3dlut version which may cause such problems in specific situations. But it's not caused by the output bitdepth being limited to 8bit. madVR could output 5bit and there would still be zero blocking/banding, thanks to the dithering used by madVR. However, the lower the bitdepth, the higher the dithering noise is. The *only* benefit of using 10bit output (when using madVR) would be less dithering noise.

[mark0077]

madshi, I posted a bug over at the main mpc-hc thread but have found madVR is the only renderer that I can reproduce with.

Its when I launch movies with mpc-hc, and change refresh rate when the movie is starting, manually or by vbs script from reclock, mpc-hc will crash soon afterwards. Is madVR not competent in this area, ie does it not do whatever evr-cp is doing when refresh rate / screen resolution changes, to rebuild.... whatever needs to be rebuilt... forgive my ignorance. I can reproduce the mpc-hc crash only with madVR.

Thanks. Happily using madVR the last few weeks with no other problems really only for this and the fact of the macrovision failures, where I need to switch back to evr-cp.

[djsolidsnake86]

madshi here there is the link for the mpeg file
http://web.tiscali.it/djsolidsnake86/1.mpg (look pixellated)

[janos666]

madVR does not produce any blocking in dark scenes. I think there's a bug in the current cr3dlut version which may cause such problems in specific situations. But it's not caused by the output bitdepth being limited to 8bit.

I didn't want to imply that this is your software's fault. I already experienced this "feature limitation" with crd3lut before I started to use your video renderer.
The bitdepth limitation was yesgrey's guess when I tried to draw his attention about this problem.
And I hoped that even if 8 bit with dithering should be enough to do a Rec709->sRGB gamma correction with negligible quality loss, this bug could be bypassed with higher bitdepth (when there is room for some wastage).

I already have found the source of the problem.

Great news. I am happily waiting. :)

[madshi]

madshi here there is the link for the mpeg file
http://web.tiscali.it/djsolidsnake86/1.mpg (look pixellated)
Thanks, will have a look at that.

I didn't want to imply that this is your software's fault. I already experienced this "feature limitation" with crd3lut before I started to use your video renderer.
The bitdepth limitation was yesgrey's guess when I tried to draw his attention about this problem.
And I hoped that even if 8 bit with dithering should be enough to do a Rec709->sRGB gamma correction with negligible quality loss, this bug could be bypassed with higher bitdepth (when there is room for some wastage).
Higher bitdepth wouldn't have made any difference, I believe. AFAIK, it was a simple bug in cr3dlut which will be fixed in the next version.

[madshi]

Its when I launch movies with mpc-hc, and change refresh rate when the movie is starting, manually or by vbs script from reclock, mpc-hc will crash soon afterwards. Is madVR not competent in this area, ie does it not do whatever evr-cp is doing when refresh rate / screen resolution changes, to rebuild.... whatever needs to be rebuilt... forgive my ignorance. I can reproduce the mpc-hc crash only with madVR.
I'll see if I can reproduce the problem here. My LCD computer monitor can only handle one refresh rate, though, I think, so it might be difficult...

[mark0077]

I'll see if I can reproduce the problem here. My LCD computer monitor can only handle one refresh rate, though, I think, so it might be difficult...

Thanks. Perhaps you could learn from the mpc code that's used when the graph needs rebuilding in cases like this.

[yesgrey]

The bitdepth limitation was yesgrey's guess when I tried to draw his attention about this problem.
Yes, I said that, but I was referring the bit depth of the sources, not the bit depth of the output, though my guess was wrong.

[janos666]

One more question: Do you plan to release x64 builds?
There are 64-bit builds of MPC-HC and FFDShow, so we could use them if you do so...

[Neeto]

The 220 may be fast enough for current madVR processing. But there's one thing to keep in mind: madVR only has basic processing capabilities right now. There's a very high probability that future madVR versions will add new processing options which will require much more processing power. Because of that my recommendation for a new GPU is this:

Get the fastest GPU you can afford and which fits your thermal/space/noise requirements. The faster, the better. That is, if you want to prepare for potential future madVR algorithms.

In that case I'll most likely I get a GT 240 512MB 128-Bit DDR5, 550/3400MHz.

Is 512MB enough?

Any hint on these "potential future madVR algorithms"?

Thanks, Neeto

[namaiki]

Is 512MB enough?


256MB, is *just* enough for MadVR @ 1920x1080 and Aero. However 256MB is not large enough for CoreAVC's CUDA thing and MadVR and Aero all together.

I dumped CoreAVC.