Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th April 2009, 23:33   #201  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Quote:
Quote:
Originally Posted by ice25 View Post
CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.
Too bad, I had hoped that was fixed. Can't properly test it cause I don't have a secondary display at the moment. So I guess the fix will have to wait a while...
@Madshi: bit late but better than never

fix reports
a) overall CPU consumption is reduced on primary and I think for SD content at least the difference between HR and madVR is negligible.
b). madVR properly reports that 10bit buffers are not available and engages 8bit buffers, and weirdly enough, no crashes or silent quits after than, video plays as normal

bug confirmation reports

1.
although the CPU consumption is down in total, still secondary monitor maxes one of the cores.
Interesting enough, now with OSD I can tell that avrg present wait is actually about 3 times lower on the secondary monitor
Still one of the cores is on maximum.
As for the rest of parameters, I cannot see any substantial difference in times for any of the other parameters on two monitors. I even used ctrl+j twice, but all the numbers are nearly same whilst CPU usage is dramatically different.

2. Monitor refresh rate is not updated if you move to a different monitor. I think btw Beliyaal fixed that issue with EVRCP at some point, but that code is not in SVN yet (may be mistaken)
important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate). Note that your code is the best so far when moving the window to a different monitor, as other renderers may have a small pause or blank screen displayed for a while when you move a window. Moving window with madVR is same as moving any normal application.

Last edited by Egh; 12th April 2009 at 23:35.
Egh is offline   Reply With Quote
Old 12th April 2009, 23:45   #202  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 525
Quote:
Originally Posted by egh
important: retested the issue, madVR uses refresh rate not as of PRIMARY monitor per se, but the rate of the monitor the mpchc window was started on!!! (in simpler words, if I start mpchc on the secondary monitor it will use its refresh rate).
fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.
noee is online now   Reply With Quote
Old 12th April 2009, 23:53   #203  |  Link
DeepBeepMeep
Registered User
 
Join Date: Jun 2006
Posts: 133
Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.

Many thanks
DeepBeepMeep is offline   Reply With Quote
Old 13th April 2009, 00:07   #204  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
I've tryed to overclock my card to see the benefits.
Clock description: Core / Shader / Memory

Standard clocks
540 / 1188 / 700
Name:  GF8600GT_540_1188_700.png
Views: 2548
Size:  51.5 KB

Overclock Core and Shader
595 / 1404 / 700
Name:  GF8600GT_594_1404_700.png
Views: 2547
Size:  51.9 KB

Overclock All
595 / 1404 / 918
Name:  GF8600GT_594_1404_918.png
Views: 2556
Size:  92.6 KB

Overclocking only the Core and Shader clocks gives a ~4% performance increase, if I also overclock the memory it gives a ~9% performance increase.
So, with madVR, the performance increase with my card was directly proportional to the clocks increase.
yesgrey is offline   Reply With Quote
Old 13th April 2009, 00:52   #205  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Quote:
Originally Posted by noee View Post
fwiw, this is not the case on my setup. If I start the player (MPC-HC) on my secondary (LG37@24Hz), madVR picks up the refresh of 60Hz, which is what my primary runs.
Nope here. Although it seems you have TV screen? I just run dualview with two monitors. It seems it always picks the refresh rate of the monitor it starts on. And i don't mean madVR per se, what I mean is the main MPCHC window. I.E. even if I start an empty window on one monitor, then move to another and drop a video into it, it detects the refresh rate of the original monitor.
Egh is offline   Reply With Quote
Old 13th April 2009, 00:54   #206  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Quote:
Originally Posted by DeepBeepMeep View Post
Would it be possible to propose another means like an option to turn on / off stats since CTRL J is usually a keyboard shorcut reserved by most players.

Many thanks
I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard
Egh is offline   Reply With Quote
Old 13th April 2009, 01:02   #207  |  Link
DeepBeepMeep
Registered User
 
Join Date: Jun 2006
Posts: 133
Quote:
Originally Posted by Egh View Post
I think it is standard shortcut used by MPCHC, and it works in many other renderers, VMR9 and EVRCP, for instance. Even cycling through different stat views has been already employed by Beliyaal in his MPCHC branch. So it is more de-facto standard
The trouble is that under Zoom Player, CTRL-J creates some navigation window...

Anyway, I don't mind keeping CTRLJ as long as there is another way to display the stats.
DeepBeepMeep is offline   Reply With Quote
Old 13th April 2009, 01:27   #208  |  Link
vucloutr
Registered User
 
vucloutr's Avatar
 
Join Date: Nov 2008
Posts: 64
Hi, here some feedback.

System:
WinServer2008 x64 - MPC HC special build - latest Nvidia drivers - latest DirectX drivers
8800GTS512 (G92) - 19" LCD 1280x1024 @72Hz over DVI

720p,h264,23.976fps,3Mbit/s encodes displayed at fullscreen (no stretch)

CoreAVC w/o CUDA / MPC HC's internal decoder / DivX H.264 Decoder :
display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
avrg present wait ~11ms
those times are pretty stable and don't vary much from decoder to decoder.

CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.

- framerate sometimes doesn't oszillate at all
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
- avrg present wait shows large negativ values immediately after pressing CTRL+J then it normalizes

I'm afraid I can't tell something more distinct because it all seems so random.

Last edited by vucloutr; 13th April 2009 at 01:43.
vucloutr is offline   Reply With Quote
Old 13th April 2009, 02:21   #209  |  Link
rica
Registered User
 
Join Date: Mar 2008
Posts: 2,021
Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.

Avi/wav File Source > MadVR

What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption????

Last edited by rica; 13th April 2009 at 02:43.
rica is offline   Reply With Quote
Old 13th April 2009, 03:39   #210  |  Link
Adub
Fighting spam with a fish
 
Adub's Avatar
 
Join Date: Sep 2005
Posts: 2,685
I could kiss you!

Madshi you rock with all of the contributions you produce in this community! Thank you so much!
__________________
FAQs:Bond's AVC/H.264 FAQ
Site:Adubvideo
Adub is offline   Reply With Quote
Old 13th April 2009, 04:16   #211  |  Link
Mutiny32
stuff and things
 
Join Date: Apr 2009
Location: Lee's Summit, MO USA
Posts: 1
Great renderer, it will be even better when you can make it output 0-255 and output smoother video. But those are pretty trivial, as other things can handle that sort of thing. You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI. My TV has all kinds of controls to handle and enhance colors and black levels to the room lighting (Philips 42pfl7422d/37), so it doesn't matter much.

I do have one request though, can you compile this for 64-bit windows? I'm going to be installing a newer build soon and Microsoft is really pushing the 64-bit thing, especially after Apple started with the whole Snow Leopard 64-bit schtick. It's seeming more and more that 64-bit will be the norm and I'm not sure of its capabilities in handling 32-bit programs; it's not like I can just do an 'apt-get install ia32-libs' or anything, that would make too much sense.

Keep up the great work!
Mutiny32 is offline   Reply With Quote
Old 13th April 2009, 04:22   #212  |  Link
Egh
Registered User
 
Join Date: Jun 2005
Posts: 630
Well x64 version will be required in the future, as only x64 codecs may work with x64 mpchc and x64 decoders. Though here I haven't found any particular video yet which would consume substantially different amount of CPU% on x64 compared to x86. Maybe when lots of additional post-processing is involved, decoding itself doesn't load CPU differently.

Though recalling how much time required to persuade Haali to do x64 version )) He resisted for more than a year before finally surrendering :P
Egh is offline   Reply With Quote
Old 13th April 2009, 05:14   #213  |  Link
Snowknight26
Registered User
 
Join Date: Aug 2007
Posts: 1,380
Assuming hes writing this in Delphi, it will be a while before even the possibility ofa 64-bit version of this or any other of madshi's programs.
Snowknight26 is offline   Reply With Quote
Old 13th April 2009, 08:14   #214  |  Link
FoLLgoTT
And so it begins...
 
FoLLgoTT's Avatar
 
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
Excellent renderer! For such fine piece of software I was waiting for!

I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.

I will be really happy when DVD works with madVR.

Last edited by FoLLgoTT; 13th April 2009 at 08:16.
FoLLgoTT is offline   Reply With Quote
Old 13th April 2009, 09:49   #215  |  Link
FoLLgoTT
And so it begins...
 
FoLLgoTT's Avatar
 
Join Date: Nov 2005
Location: Hannover, Germany
Posts: 64
@madshi
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.


ffdshow:


madVR with resampling:


madVR without resampling:



The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.

ffdshow:


madVR with resampling:


Is this a bug or just a side effect of your upsampling algorithm?

Last edited by FoLLgoTT; 13th April 2009 at 09:51.
FoLLgoTT is offline   Reply With Quote
Old 13th April 2009, 11:11   #216  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,417
I wonder if anyone tried to create LUT's w/ custom primaries coordinates, coz I'm getting strange results...even the stock LUT's are way too dark, but yesgrey is on the case

Last edited by leeperry; 13th April 2009 at 11:26.
leeperry is offline   Reply With Quote
Old 13th April 2009, 11:23   #217  |  Link
VHT
Registered User
 
Join Date: Dec 2008
Posts: 25
Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
VHT is offline   Reply With Quote
Old 13th April 2009, 11:58   #218  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 8,917
Quote:
Originally Posted by leeperry View Post
that'd be fun if you could put 3 or 4 digits after the coma for the VSYNC interval.
Not needed. The VSync interval is just calculated by doing "1000 / display refresh rate" and the display refresh rate is displayed with enough digits. So you can calculate the VSync interval yourself. But please note that the display refresh rate is not 100% perfect. So take those additional digits with a grain of salt!

Quote:
Originally Posted by buletti View Post
Could that be the cause of the high CPU load? The copy operation from RAM into VRAM is done by the CPU and is a rather slow operation AFAIR.
Well, the data has to be transported to the GPU somehow. All the other renderers must do that, too, sooner or later. Actually if you feed other renderers with RGB data or even with upscaled data, you have to send more data from RAM to GPU than madVR does! So I still don't see why madVR should consume more CPU.

Quote:
Originally Posted by Snowknight26 View Post
Can anything be done about an error that says "graphics card only supports power of 2 textures?" Happens with my GM45.
Unfortunately there's not so much I can about that. The error message means that your GM45 only supports textures which follow strict resolution patterns. Basically textures on your graphics card must have a width and height of one of the following numbers: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096. Now madVR needs textures in the resolution of the source (e.g. 720x480 for NTSC-DVD) and in the resolution of the display (e.g. 1920x1080). Your GM45 seemingly does not support textures in such "odd" resolutions. Probably it would be possible to use the next higher supported resolution like e.g. 2048x2048, but that would make texture addressing in my shaders a lot more complicated. So I'd rather not support that. I fear the GM45 would be too slow, anyway...

Quote:
Originally Posted by vucloutr View Post
display 72.0xxxxHz
movie 23.976 fps
frame queue pretty much always 16/16
movie resolution 1280,720
target rectangle 0,152,1280,872
vsync interval 13.90ms
movie frame interval 41.71ms
avrg gpu rendering time ~3ms
max rendering time is ~4ms
These are extremely good numbers. Of course it helps that you have 1:1 display and don't need to scale.

Quote:
Originally Posted by vucloutr View Post
CoreAVC w/ CUDA same as above but:
max rendering time -> update textures goes from normal ~2ms up to 12-15ms then down to normal, then again up, etc. happens every now and then.
with some 1080p high bitrate material it goes even higher resulting in strong stuttering. some other material works without any flaws.
Interesting!

Quote:
Originally Posted by vucloutr View Post
- time behind display x.xxxx.Hz in brackets stays fixed (0s/1s/2s) or counts sometimes
If the time counter goes up a lot that helps exactness of the display refresh rate calculation. The time counter restarts from 0s, if madVR ran into any kind of trouble interpreting the VSync data.

Quote:
Originally Posted by vucloutr View Post
- I noticed that a display refresh rate slightly below 3*23.976Hz (CVT reduced blanking for example) causes stuttering. While a refresh rate slightly above 3*23.976Hz results in smooth playback. Unfortunately I can't test this for 75Hz becaused i can't get more then 75.01xxHz which is not enough as it seems.
That problem should be solved in a future version of madVR. Might take a while, though...

Quote:
Originally Posted by vucloutr View Post
- display refresh rate detection works sometimes, if 0.0000Hz is displayed window minimize->restore is a workaround
Do you really have to minimize/restore? The display refresh rate detection should be able to recover automatically. It retries measurements every second.

Quote:
Originally Posted by rica View Post
Strange;
when i opened DGAVCNV avs file with GraphStudio, CPU utilization decreased to 25 to 35 % level.

Avi/wav File Source > MadVR

What is interesting here is MPC-HC is using the same filter chain as well but with a 50-75 % Cpu consumption????
Weird!!

Quote:
Originally Posted by Mutiny32 View Post
You say that you can't output to YCbCr444 with our video cards, or at least easily. Actually, I'm running Win 7 with the WDDM 1.1 driver and the default control panel has a specific page that has a simple dropdown box to switch between RGB and YCbCr444 output over HDMI.
Yeah, but how do you know what the driver does internally? E.g. with ATI cards even if you do select YCbCr output, BTB and WTW are clipped, which is a strong indicator that the graphics card internally does YCbCr (video) -> RGB (PC) -> YCbCr (video), which I consider bad.

Quote:
Originally Posted by Mutiny32 View Post
I do have one request though, can you compile this for 64-bit windows?
I've already replied to this question a few posts before.

Quote:
Originally Posted by FoLLgoTT View Post
I have only one small suggestion. It would be great, if the number of lobes/taps of Lanczos could be chosen like in ffdshow. I know that many people will claim that ringing becomes visible, but this is only true with test patterns and not with low pass filtered movies, because ringing only occurs near the band limit. The advantage of 8 or 10 taps is a much better frequency response and visible less aliasing.
Ok, will add 8 tap Lanczos. But in my tests it didn't look any better than 4 tap Lanczos. Actually it looked worse to me, because it was not any sharper and only ever so slightly less aliased, but had very noticeable double ringing!

Quote:
Originally Posted by leeperry View Post
...even the stock LUT's are way too dark, but yesgrey is on the case
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?

Quote:
Originally Posted by VHT View Post
Hi! I've got a problem connecting madVR with ffdshow for post-processing. Using 32-bit vista MPC-HC Beliyaal build (preferred renderer madVR) + CoreAVC without CUDA. I've got raw video in ffdshow on all supported mode and output for YV12 is marked.
There's a switch somewhere in ffdshow to allow or forbid to connect to "unknown" filters.
madshi is offline   Reply With Quote
Old 13th April 2009, 12:06   #219  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 8,917
Quote:
Originally Posted by FoLLgoTT View Post
I compared the chroma upsampling a bit and I noticed that madVR's frequency response is noticeably lower than ffdshow's (HQ upscaling and Lanczos resize to 1920x1080). In both cases I used Lanczos4 for resizing.
These are pretty interesting tests - thanks! Are these test pattern (legally) available somewhere for download?

Quote:
Originally Posted by FoLLgoTT View Post
If you look at the middle of the Siemens star you'll see that the lines are not fully resolved. Without the resampling option in madVR the resolution stays almost the same, but aliasing occurs.
Which madVR resampling option do you mean?

Quote:
Originally Posted by FoLLgoTT View Post
The problem is even more visible at the burst pattern. The amplitude of the chroma signal begins to fall at 1MHz.

Is this a bug or just a side effect of your upsampling algorithm?
I've optimized my chroma upsampling algorithm in such a way that it gets rid of all the nasty aliasing. That may result in a hit on frequency response. Of course that's not nice. But we have to set our priorities right: Do you want higher frequency response and live with ugly jaggies? Or do you want smooth jaggies and can live with a lower frequency response?

Please check out the chroma upsampling screenshots in the 2nd post of this thread. Don't you agree that madVR's chroma upsampling looks *a lot* better than ffdshow's HQ chroma upsampling in those screenshots? I guess I could offer "nearest neighbor" chroma upsampling. That would probably produce a perfect frequency response. And it would result in the most ugly chroma upsampling quality possible...

But seriously, I could allow different chroma upsampling algorithms (e.g. Bicubic and Lanczos) to be selected in addition to the currently used very soft resampler (which is SoftCubic100). So you could find your own compromise between jaggies and frequency response. Would you consider that useful?

Can you see the "missing" frequency response in any real life pictures?
madshi is offline   Reply With Quote
Old 13th April 2009, 12:19   #220  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,417
Quote:
Originally Posted by madshi View Post
You mean the default LUTs created by madVR are too dark? Or are they only too dark if you activate custom primaries?
well..I output PC range off ffdshow and my displays all have PC range(so no levels conversion needed)

that's my RGB32HQ picture :
http://www.image-load.eu/out.php/i157521_rgb32hq.png

now w/ ddcc doing the gamut conversion(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157519_ddcc.png

and that's w/ a 16bit LUT from yesgrey's app in t3dlut() :
http://www.image-load.eu/out.php/i157520_lut.png

so that 16bit LUT is way too dark, and my .ini settings appear to be OK...even yesgrey agrees.

and I'm getting opposite results when I put this LUT in madVR

that's w/ ddcc(8bit LUT created in ddcc) in HR :
http://www.image-load.eu/out.php/i157518_hr.png

this is the stock HD LUT in madVR :
http://www.imagebam.com/image/43c8ae32526309

and this is my custom 16bit LUT :
http://www.imagebam.com/image/c716bb32526310

I know ddcc "works" coz it matches what the PS script outputs(slightly better of course)...

I think you may wanna give the option to the user to choose untouched levels or TV>PC conversion, and then make 2 LUT's :
SD: REC.601 (untouched levels OR levels expansion from TV to PC)
HD: REC.709 (untouched levels OR levels expansion from TV to PC)

but anyway, the CMS is pretty broken right now I think, waiting for yesgrey's feedback

Last edited by leeperry; 13th April 2009 at 12:27.
leeperry is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.