madVR - high quality video renderer (GPU assisted)

[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.
:thanks:
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]

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)

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.

http://photos.smugmug.com/photos/1250024521_psBN6-O.png

Here's my previous graph for comparison:

http://photos.smugmug.com/photos/1248453864_YkuAv-O.png

[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.

[pankov]

Guys, I do agree that green will be more visible (it's human nature) but I don't find this a plus. Personally while testing a new version I usually watch a few movies with the OSD on all the time and I really like the way the red one is not very intrusive. I'm not sure I'll be able to do it with a green one.
But that's only my personal opinion on the matter.

leaving this aside I'm sad to report that the CPU issue is not solved ... or at least not in all cases.
I did the following test:
I've matched my two displays' configs as close as possible (both at 1920x1080@50Hz 'cause my LCD Monitor doesn't support 24p) and used a 24 (23.976) fps source decoded with CoreAVC in software mode.
I've done the tests multiple times on both monitors and the result is that on my LCD monitor (no matter if it's primary or not in windows) I get normal CPU usage <10% with both new and old rendering paths but on my projector I get ~30-35% CPU usage with the new and <10% with the old rendering.
Here are two log files from each monitor hopefully showing the difference between the two monitors using the new path.
http://www.mediafire.com/?yxkb8b33th8ykud

with v0.50 it's high cpu usage on both monitors, so I guess, madshi you'll have to do some more magic to bring it to the old CPU levels.

I'm not sure if it's relevant but I thought I should mention it
after closing the player I get a ~5 second spike in CPU usage by NvXDSync.exe but this happens both with new and old rendering paths so I doubt it's relevant at all.

[Mark_A_W]

I'm a bit lost as to why there is such concern over a small increase in CPU usage? And it's really hard to tell with 4 cores (and then I have hyperthreading on top, so 8 bloody graphs...)

I mean, if playback is smooth (and that's all that matters), what's the issue exactly?


If you are now borderline with a weak system....get a proper computer ;) Leave madshi to work on stuff that matters!

[Hprd]

Ok first off i have to say that this is one excellent renderer, and have used it for quite a while (since sometime in 2009) and have had bearly any issues with it (especially since fs exclusive was added).

That said there's a somewhat annoying issue with this version, with the higher back-buffer que's. The problem comes with trying to watch videos at 1080/24hz or 1080/30hz, as lower ques (2,4 etc.) drop frames.

If i turn it up to at least 12 (16 is what i set it to though) (as 10 still dropped some frames on one video) the clock deviation just goes up and up, and leads to repeated frames several times a second... THis can be remedied (on some videos...) by playing another video without subtitles (as it seems that really sets it off) and the clock eventually settles down or perhaps (i didn't try this, but after several minutes it didn't really change at all) just waiting for it to go down might work as well.

So basically i can achieve, with most videos (after some messing around with it) perfect playback at 24/30hz. Another problem is that i'd want to leave the que set that high (as most videos i'd want to watch in fullscreen seem to be ok, after messing about anyhow) but some other videos (refresh rate didn't really matter, although i didn't test this that thoroughly) don't seem to like it at all, and jump up to a difference of -5% deviation, which makes it really nasty. (they were videos without subtitles, playing another video then without sound and the same frame rate, just higher resolution, has no trouble at all. So it might be related to that somehow [the sound], then again i don't really know what i'm talking about, lol...).

Simply then changing the que to 2 and restarting the video results in perfect playback once again (which was literally the only way to fix the repeated frame issues on these videos)... and at 48/60hz no dropped frames, (as this is a 1920x1200 monitor and doesn't support 24/30 at that resolution, so if i watch a 4:3 video, i use those resolutions). Turning aero off or on (with madvr) didn't do anything either. I'm using the default scaling (soft cubic 100, lanzcos4 x2) and 3dlut as well. Not sure if that has anything to do with it though (maybe putting less intense settings would fix it, but i wouldn't want to do that, as i like the look of those scalers best, plus it wouldn't fix the problem anyhow, as i think this computer is capable enough, it's just madvr that perhaps needs some work it seems tbh ;)).

Also of note i can't compare the old rendering path, as it says "exclusive mode failed" with the lower refresh rates, 24/30hz (48hz is fine) (reguardless of resolution) (v.50 is exactly the same, on any resolutin/refresh rate, as setting the que to 4 on v.51: dropped frames here and there on 1080/24/30hz which led to "dropped" audio as well).

So i was wondering of course if this is something that can be fixed/improved somehow (less initial, sometimes permanent, clock deviation/repeated frames on higher que numbers).

And i should say my computer is: Win 7 64 bit, Geforce 275 267.17 (quadro drivers, not the newest, but i'm waiting for a whql release of the 270 series for them), core i7 920 @3.76 ghz, 6 gigs of ram, etc.

Running mph-hc 3008 (as i'm not sure what a newer version would do, this is new enough to support the proper madvr subtitle rendering so...?) Reclock for wasapi audio (latest version) ffdshow for video (latest version, 3814) Haali media splitter (latest version), for um, splitting...

[BeNooL]

On my lowend-ish ATI 4550 new rendering path in madVR 0.51 gives a 15-20% GPU usage boost causing a jump from 70-75% to 95-100% GPU usage. Using Catalyst 11.2 by the way.

[Astrophizz]

Another argument for green text (and might explain what looks like a difference in color resolution?) is that the human eye is more sensitive to green than red (especially in low light conditions). Blue might also work fine but I'm not sure what causes blue to look like that in 6233638's picture unless his assessment is correct. Perception of red in low light might also be why color blind users might find the red text difficult to read. See http://hyperphysics.phy-astr.gsu.edu/hbase/vision/rodcone.html and other similar text. Anyways it's not a big deal to me, especially when there might be other more significant features pending.

[Grmpf]

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?

I think its done *before* madVR does its magic to scale&colorconversion because if i choose 1.333 aspect ratio for my ISCO lens (basicly i stretch the image from 1080 lines to 1440 lines and cut away the top/bottom 180 lines to get rid of the black bars - after wards my lens does strech the image again) the top lines of OSD are of the screen, this sugests that the OSD rendering is done first (in 4:2:0 i guess).

It would solve both "problems" if it would be done later (after scaling/etc.) - the typo would be clear even the red one (if done in RGB) and it would be inside the output picture area (if you use a ISCO).

[Hypernova]

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

This has been discussed a few times already. Short answer is don't use it if it doesn't work for you. madVR know nothing about changing monitor while the video is already loaded.

[leeperry]

0.51 has been working like a charm for me on XPSP3 so far :cool:

Another argument for green text (and might explain what looks like a difference in color resolution?) is that the human eye is more sensitive to green than red
HR's OSD's green, and it's very easy to read: http://thumbnails19.imagebam.com/4453/208dad44521156.gif (http://www.imagebam.com/image/208dad44521156)

[pirlouy]

I'm a bit lost as to why there is such concern over a small increase in CPU usage? And it's really hard to tell with 4 cores (and then I have hyperthreading on top, so 8 bloody graphs...)

I mean, if playback is smooth (and that's all that matters), what's the issue exactly?


If you are now borderline with a weak system....get a proper computer ;) Leave madshi to work on stuff that matters!
I think you're wrong. Madshi wants to know what could affect CPU more than it should. If someone reports a CPU problem (thanks to this old computer), it will help Madshi...

ps: it seems all works well for me with 0.51; but I've never really followed CPU graph, or madVR OSD so I'm not really useful in this case.

[Gleb Egorych]

:( That's the first negative report about v0.51. How do your queues behave like with v0.51 when you get drops with CoreAVC soft mode with 60fps? Have you tried increasing the number of pre-rendered frames?
Backbuffer and render queue are pretty stable at 4-4/4 and 3-4/4 correspondingly. Decoder queue floats from 6-8 to 7-8 but the problem, I guess, in upload and render queues. Dropped frames occur when upload and render queue go to 5-8 and 6-8.

Described behaiviour is present for default number of pre-rendered frames and up to 12. No drops and stable queues with CoreAVC software mode I have only with 14 and 16 pre-rendered frames. Note that 0.50 is prefect and it uses 4 (I guess) pre-rendered frames.

[underzone]

0.51 has been working like a charm for me on XPSP3 so far :cool:


HR's OSD's green, and it's very easy to read: http://thumbnails19.imagebam.com/4453/208dad44521156.gif (http://www.imagebam.com/image/208dad44521156)

Wow it IS a lot easier to read! I am suprised...

[Andy o]

OK so I just tested average core usage between new rendering paths on 0.51 and 0.50, and it does look like .51 lowers it visibly. First half is .051 and after the dip, it's 0.50.

http://photos.smugmug.com/photos/1250539249_iaWLc-O.png

http://photos.smugmug.com/photos/1250539219_nzqai-O.png

[jmone]

I now get dropped frames in V0.51 with x264 1080/50p material when the refresh rate of the screen is not 50hz (eg 60hz). I see the Backbuffer and Present Queue drop to 0 at which point frames are dropped. This did not happen with previous verions. I raised the queues to 12 but this did not help. Apart from this it all looks good to me.

[fps]

Regarding the CPU usage graphs. I wouldn't read too much out of the windows task manager graphs.
Especially in multi core systems it often shows missleading stats. For example the graph might show a cpu usage of 50%, when in reality a thread just runs on 1 core which is maxed out at 100%.
To get some realistic stats you should use Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) and look at the threads tab of the player.

I don't have 0.50 on my computer any more, does anybody still have a link? Via google I just found 0.51 ;).

[Andy o]

They're not misleading, they're (presumably?) averaged, and you can choose to show per-core or all cores averaged.

For example the graph might show a cpu usage of 50%, when in reality a thread just runs on 1 core which is maxed out at 100%.
In this scenario, it's even worse, cause you're already maxing out one core. So the "misleading" part is that you're seeing better than it actually is. But again, you can choose to show each core.

[jmone]

I'm also dropping frames with x264 BR 60i material in a TS container when FFDSHOW has deinterlacing set (YADIF). Turn Deinterlacing off and it is all fine....

EDIT - I drop frames on Interlaced Material if FFDSHOW Deinterlacing when using YADIF with "Double Framerate" check. If I uncheck "double framerate" then all is fine.

[nevcairiel]

They're not misleading, they're (presumably?) averaged, and you can choose to show per-core or all cores averaged.


In this scenario, it's even worse, cause you're already maxing out one core. So the "misleading" part is that you're seeing better than it actually is. But again, you can choose to show each core.

Its not "averaged", the windows scheduler is just funny that way, it does not limit a thread to one CPU - when it yields the process, it is not guaranteed to run on that CPU again, rather it'll most likely resume on another CPU - that makes the graphs look like this, because it actually switches CPUs (and no thread runs 100% of the time, all threads sleep/yield at some point)

Change the processor affinity of your player in the task manager to only one or two CPUs, and you'll see that only those show up as having any load, and if you're just tryign to figure out how much CPU one specific thread is using, that'll give you graphs of that. ;)

But yes, its better to use smarter tools.

(CPU of course refers to individual Cores as well)

[fps]

They're not misleading, they're (presumably?) averaged, and you can choose to show per-core or all cores averaged.
In this scenario, it's even worse, cause you're already maxing out one core. So the "misleading" part is that you're seeing better than it actually is. But again, you can choose to show each core.
I gave that example because imho it's pretty misleading to show 50% consumption (and yes I had the task manager set to per core and not all cores averaged) when in reality it is 100% because everything runs on one core.
Looking at just the task manager graph you wouldn't be able to tell that the cpu is fully used to capacity.

Another advantage of process explorer is you can actually see how much cpu madVR alone consumes. This should make it much easier to compare the differences between versions.

[Andy o]

Its not "averaged", the windows scheduler is just funny that way, it does not limit a thread to one CPU - when it yields the process, it is not guaranteed to run on that CPU again, rather it'll most likely resume on another CPU - that makes the graphs look like this, because it actually switches CPUs (and no thread runs 100% of the time, all threads sleep/yield at some point)
I meant when you have a multicore CPU and you choose the "One Graph, All CPUs" option the graph is averaged for all cores, isn't it that way?

But yeah, I know the threads don't use one core exclusively, but that doesn't take from what we're trying to find out here, which is higher overall CPU consumption. If the thread switches to another core, it will still show in the graph for that other core.

and if you're just tryign to figure out how much CPU one specific thread is usingI think the relevant issue here is overall CPU consumption. Usually you don't force the player to use only one specific core via affinity, so however the player consumes CPU without it being limited to a specific core is more relevant. Or maybe I'm missing something?

But yes, its better to use smarter tools.[/quote]

Right of course, but I was going for a ballpark visualization only, didn't think it warranted more specific stats than that simple tool provides.

[ryrynz]

I don't have 0.50 on my computer any more, does anybody still have a link? Via google I just found 0.51 ;).

Old madVR versions (http://www.videohelp.com/tools/madVR/old-versions#download)

[fps]

Thanks!

[madshi]

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

One thing I have noticed with 051 is coming in and out of full screen does not feel as smooth as 049.
That's somewhat as expected since the v0.49 didn't pre-render (or more accurately "pre-present") more than 1 frame. v0.51 now pre-presents 4 frames by default, so changing from exclusive to windowed is now always delayed by 4 frames. However, changing from windowed to exclusive mode should be unaffected.

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.
Really? 4-5 times more? It seems to be only slightly more for most other people. Can you please double check you're really using v0.51? Thanks.

Which refresh rate do you have and which movie framerate? Is it a 1:1 match?

Green is the Y channel, isn't it?
Huh? Not sure what you mean. Y is luma (brightness). It's part of all green, red and blue.

I took the liberty of fixing this for you, also marking madVR compatible with the sub renderer in the Output configuration GUI (in r3025)
Great - thanks a lot! :)

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).
Ok, will check this out.

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/
Corrupted frames can't be caused by madVR. madVR has nothing to do with video decoding. Which splitter and decoder are you using for VC-1? Have you tried a different splitter and/or decoder?

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)
The decoder *can* pass the color matrix to the renderer, but I don't think any decoder currently does that. Also I'm not sure if any renderer makes use of that information, if a decoder passes it on. I plan to look into this problem in a future madVR version.

I also did a 0-255 range test
The big problem with the fullrange flag is that many many many many many broadcasts here in Europe have this flags set although the content is actually encoded in 16-235. So basically if you have a h264 file with the fullrange flag set, the flag is set wrong in 99.9% of all cases. As a result many decoders and renderers simply ignore this flag. Content which is *really* 0-255 is just much rarer than incorrectly flagged 16-235 content. eac3to for examples always deletes the fullrange flag - unless you explicitly tell it not to.

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.
Have you tried updating your GPU drivers? If that doesn't help, please create a debug log for me. It works like this: (1) rename "madVR.ax" to "madVR [release].ax". (2) rename "madVR [debug].ax" to "madVR.ax". (3) reproduce the problem. (4) Zip and upload the file "madVR - log.txt" which you'll find on your desktop.

I don't think we really get a vote, but, hypothetically if we did, I'd vote for green.
Seems the majority is for green?

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.
Tested on my AMD machine. Working great!
:)

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.
If you run into trouble, please try to avoid switching monitors or even resolutions/refresh rates. Make sure the monitors are already set to the correct resolution and refresh rate. Then move MPC-HC to the target monitor *before* loading the video file. If you do that, there should be no problems.

I'll find a better solution to this in a future madVR version.

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.
Which refresh rate do you have and which movie framerate? Is it a 1:1 match?

I did the following test:
I've matched my two displays' configs as close as possible (both at 1920x1080@50Hz 'cause my LCD Monitor doesn't support 24p) and used a 24 (23.976) fps source decoded with CoreAVC in software mode.
I've done the tests multiple times on both monitors and the result is that on my LCD monitor (no matter if it's primary or not in windows) I get normal CPU usage <10% with both new and old rendering paths but on my projector I get ~30-35% CPU usage with the new and <10% with the old rendering.
Weird!!!

What happens if you play a video with 1:1 refresh rate <-> movie framerate match?

I'm a bit lost as to why there is such concern over a small increase in CPU usage?
Well, if madVR would really need more CPU then that's just the way it would be. But I don't really see *why* madVR consumes more CPU now. It shouldn't (at least not when refresh rate and movie framerate match). So it appears to be a bug and I don't want to waste CPU resources if I don't have to. A few percent CPU usage can make the difference between smooth and non-smooth on older hardware.

That said there's a somewhat annoying issue with this version, with the higher back-buffer que's. The problem comes with trying to watch videos at 1080/24hz or 1080/30hz, as lower ques (2,4 etc.) drop frames.

If i turn it up to at least 12 (16 is what i set it to though) (as 10 still dropped some frames on one video) the clock deviation just goes up and up, and leads to repeated frames several times a second... THis can be remedied (on some videos...) by playing another video without subtitles (as it seems that really sets it off) and the clock eventually settles down or perhaps (i didn't try this, but after several minutes it didn't really change at all) just waiting for it to go down might work as well.

So basically i can achieve, with most videos (after some messing around with it) perfect playback at 24/30hz. Another problem is that i'd want to leave the que set that high (as most videos i'd want to watch in fullscreen seem to be ok, after messing about anyhow) but some other videos (refresh rate didn't really matter, although i didn't test this that thoroughly) don't seem to like it at all, and jump up to a difference of -5% deviation, which makes it really nasty. (they were videos without subtitles, playing another video then without sound and the same frame rate, just higher resolution, has no trouble at all. So it might be related to that somehow [the sound], then again i don't really know what i'm talking about, lol...).
I don't really understand. The clock deviation shouldn't have anything to do with the queue size. Furthermore the clock deviation is just a measurement done for your information, nothing more. madVR doesn't actually *use* the clock deviation measurement anywhere.

On my lowend-ish ATI 4550 new rendering path in madVR 0.51 gives a 15-20% GPU usage boost causing a jump from 70-75% to 95-100% GPU usage. Using Catalyst 11.2 by the way.
Is that bad or good? Do you get dropped frames now that you didn't get before? What is your refresh rate and your movie frame rate?

I think its done *before* madVR does its magic to scale&colorconversion
No, the OSD is drawn pretty much last, in RGB.

Backbuffer and render queue are pretty stable at 4-4/4 and 3-4/4 correspondingly. Decoder queue floats from 6-8 to 7-8 but the problem, I guess, in upload and render queues. Dropped frames occur when upload and render queue go to 5-8 and 6-8.

Described behaiviour is present for default number of pre-rendered frames and up to 12. No drops and stable queues with CoreAVC software mode I have only with 14 and 16 pre-rendered frames. Note that 0.50 is prefect and it uses 4 (I guess) pre-rendered frames.
Hmmmm... How does v0.51 compare to v0.49 for you? I understand you liked v0.50 best, but there were serious problems in v0.50 and it did some things wrong.

I now get dropped frames in V0.51 with x264 1080/50p material when the refresh rate of the screen is not 50hz (eg 60hz). I see the Backbuffer and Present Queue drop to 0 at which point frames are dropped. This did not happen with previous verions. I raised the queues to 12 but this did not help. Apart from this it all looks good to me.
Does your screen not support 50Hz?

I'm also dropping frames with x264 BR 60i material in a TS container when FFDSHOW has deinterlacing set (YADIF). Turn Deinterlacing off and it is all fine....

EDIT - I drop frames on Interlaced Material if FFDSHOW Deinterlacing when using YADIF with "Double Framerate" check. If I uncheck "double framerate" then all is fine.
Did v0.49 work perfectly with "double framerate" checked?

[SamuriHL]

Yea, like I said, I don't know that we necessarily get a vote in the color of the text, but, if you're open to changing it, I think the majority of us prefer green. I always use green on black for my command line stuff cause it's pretty easy to see. It's not a very important thing, really, but, it'd make it easier for some of us to see it on our setup. If you're willing to change it, great. :)

[Andy o]

madshi, I'm playing 23.976 content (blu-ray rip) at 23.976 (23) Hz with an ATI 5770.

[Qaq]

Really? 4-5 times more?
Note, it was 720p video. With 049 CPU usage is ~12% and with 05* it reaches 60%. Like I said above, 051 has a bit less CPU usage than 050. I have AMD X2 +6000. Probably, my low-end ATI 5450 is the bottleneck.
Can you please double check you're really using v0.51?
I remember that new feature with framebuffers (tried to change from 4 to 6,8 without luck). So no doubts here, it was 051.
Which refresh rate do you have and which movie framerate? Is it a 1:1 match?
I always do it 1:1 matched. It was 23,976 - source and display.

[pouyoux]

First I'd like to thanks Madshi for its work, everything is working fine here (with 0.51).

Otherwise I've a question, I've seen on a webpage ( http://www.hd-plex.com/blog/tag/madvr/ ), that HDMI bandwitdth is still a concern and so madvr computation is "limited" to 16bits precision though it could be done using floating point.

I'd like to know how it's handled in madvr :
1- HDMI 1.0 has a sufficient bandwith to handle 16 bits precision, and madvr doesn't have any gain of the added bandwith provided by upcoming HDMI versions (1.2, 1.3, 1.4)
2- Madvr does an auto calibration of the precision it can handle depending the HDMI version used and thus depending the available bandwidth
3- other choice ? :)

[nevcairiel]

Whatever you read, its inaccurate. madVR always dithers its output down to 8bpp, mostly because it has to convert it to RGB anyway, then there is little to gain from higher bit-depths, and because the typical HTPC will not easily output 10-bit or more. It has nothing to do with HDMI bandwidth.

That whole article reads kinda funny...
It claims NV12 is a special NVIDIA color space *rolls eyes*

[pouyoux]

Yea, like I said, I don't know that we necessarily get a vote in the color of the text, but, if you're open to changing it, I think the majority of us prefer green.

would it take long to add an option in madvr where you choose the color of the text (red, green, blue) ? so everybody can choose the color that suits best its need/preference.

[ajp_anton]

An idea for the debug build...

You could include a "Enable or disable debug.bat" that changes between the following two "modes":
Normal mode: normal build is "madVR.ax", debug build is "madVR [Debug is disabled].ax".
Debug mode: normal build is "madVR [Debug is enabled].ax", debug build is "madVR.ax".

[renq]

An idea for the debug build...

You could include a "Enable or disable debug.bat" that changes between the following two "modes":
Normal mode: normal build is "madVR.ax", debug build is "madVR [Debug is disabled].ax".
Debug mode: normal build is "madVR [Debug is enabled].ax", debug build is "madVR.ax".

There is madVR [debug].ax:cool:

[ajp_anton]

There is madVR [debug].ax:cool:...which you now have to manually rename to a name that already exists, so you have to first rename that file to something else, and then reverse this process when going back. And without these instructions, some people may not know how to use that debug build.
A .bat file that is simply called "Enable or disable debug" is easier to understand and to use, and the filenames "Debug is enabled" or "... disabled" directly tells you which "mode" is being used.

[Plutotype]

Corrupted frames can't be caused by madVR. madVR has nothing to do with video decoding. Which splitter and decoder are you using for VC-1? Have you tried a different splitter and/or decoder?


You are correct, its a issue with LAVsplitter, will post on relevant thread. MPC-HC splitter works correctly when seeking in paused mode.
EDIT: Apologize, Its not an issue with LAVsplitter - using libavcodec for VC-1 decoding instead of wmv9 in ffdshow solved the issue.

[ikarad]

2 questions:
1) In windowed mode fraps display 24 fps like the number of frame per second of my movie. In exclusive full screen mode, fraps display 96 fps (refresh rate of my CRT). Is-it normal?
Movie is at 24 fps or 96 fps in exclusive mode?

2)I use for chroma upscaling, luma upscaling and luma downscaling, Softcubic with softness = 100, Is it good?
What are the best parameters?
http://img4.hostingpics.net/thumbs/mini_287074moi.jpg (http://www.hostingpics.net/viewer.php?id=287074moi.jpg)

3) There are some parameters in rendering options and I don't know how configure them. If anybody could explain the aim of each option, thanks a lot.
http://img4.hostingpics.net/thumbs/mini_514393moi.jpg (http://www.hostingpics.net/viewer.php?id=514393moi.jpg)

[Hprd]

Well i'm not really sure how to describe it then. It's just that i noticed when i have the que set to a high number (like 16) the clock deviation can be way off (-5%) and that resulted in massive frame repeats (lower than 1 second), as compared with the que set to a lower number the deviation was small (would go down to something like -.00+ etc.) and would have very smooth playback, 20-30+ seconds to a minute or two before frame repeats.

Maybe i should upload part of this clip or something to see if you can recreate my issues? Unless it's just my system or something (and with whatever updates to madvr/newer drivers on here, it will solve itself).

Ok, I see that some of the statistics can carry over from fullscreen when it's switched to windowed mode, so i took some screen grabs. This should show exactly what i'm talking about. (the dropped frames are the results of going from windowed to fullscreen fyi.)

que set to 2: http://img685.imageshack.us/img685/9307/26017811.png

16: http://img845.imageshack.us/img845/1438/11747971.png

[fairchild]

2 questions:
2)I use for chroma upscaling, luma upscaling and luma downscaling, Softcubic with softness = 100, Is it good?
What are the best parameters?
http://img4.hostingpics.net/thumbs/mini_287074moi.jpg (http://www.hostingpics.net/viewer.php?id=287074moi.jpg)

It's usually personal preference what scalers to use. Chroma at softcubic 100 is good. The luma upscale/downscale try using Bicubic75, Spline3, Lanczos4 (from lowest to most sharpening left to right); the default is lanczos 4 last I checked which has strong sharpening. I like using softcubic 100 for chroma, and bicubic75 for luma upscale/downscale.

[ikarad]

It's usually personal preference what scalers to use. Chroma at softcubic 100 is good. The luma upscale/downscale try using Bicubic75, Spline3, Lanczos4 (from lowest to most sharpening left to right); the default is lanczos 4 last I checked which has strong sharpening. I like using softcubic 100 for chroma, and bicubic75 for luma upscale/downscale.

Thanks. I use softcubic at 100 because it is the only that doens't have red (only green).

Why do you use bicubic 75 instead of softcubic for luma upscale/downscale?

[nevcairiel]

Some people just like sharper images rather then soft images. Like said before, its alot personal preference.

[ikarad]

Some people just like sharper images rather then soft images. Like said before, its alot personal preference.

Thanks. Then, what are the differences between softcubic and bicubic for example?
The problem is that I don't know the differences and the only option that I see to decide are the good or the bad consequences indicated in madvr (red or green). Then It's why that I use softcubic 100 because it's the only option which has not red.

Softcubic 100 provide sharper or soft image?

But if anybody could explain. Thanks.

[nevcairiel]

Its called Softcubic.

I suggest to simply try some of the algorithms and see how it looks to you. Try on some more extreme examples, when only doing chroma scaling on a movie thats 1080p anyway, you won't see much differences - but try downscaling some file by alot, or upscaling a very low resolution, thats where you see the big differences.

The most common setup is that people use a "soft" scaler for Chroma (like Softcubic), and more sharp scalers for Luma (like Lanczos or Spline)

[ikarad]

The most common setup is that people use a "soft" scaler for Chroma (like Softcubic), and more sharp scalers for Luma (like Lanczos or Spline)

Why soft for chroma and sharp for luma?