madVR - high quality video renderer (GPU assisted) [Archive] - Page 380

cyberbeing

2nd June 2013, 20:46

Oh lol, OK.....so basically we put my levels problem with PS scripts in the "known issues" drawer and that's it? :(

FWIW the aforementioned script (http://www.avsforum.com/t/912720/color-correction-with-a-htpc-simpler-solution-and-now-it-really-works) has always worked fine with VMR9 & EVR in MPC/PotP/KMP(using stolen code from MPC I presume) and even through this Avisynth PS script wrapper (http://forum.doom9.org/showthread.php?t=87295) in FFDshow.

Sadly the only application from this list that comes with a source code is MPC and even if I were to ask JohnAd(who wrote the gamut mapping PS script, using 3DLUT code from yesgrey) for help, he wouldn't be able to look at what mVR does either :(

I remember you saying that MPC wasn't applying PS scripts properly on BTB/WTW but quite frankly I've never seen anything wrong with test patterns so would that be possible that you'd apply PS scripts exactly as they are in MPC pretty please? Or at least provide a "MPC broken PS script implementation compatibility fix"? :o

Couldn't that script be fixed quite simply by changing the original:

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
c0 = pow(c0, 1/0.45);
c0 = mul(r2r, c0);
c0 = saturate(c0);
c0 = pow(c0, 0.45);

return c0;
}

to the following which adds a clamp for out-of-range values:

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float4 c0 = tex2D(s0, tex);
c0 = clamp(c0, 0.0, 1.0);
c0 = pow(c0, 1/0.45);
c0 = mul(r2r, c0);
c0 = saturate(c0);
c0 = pow(c0, 0.45);

return c0;
}

I know nothing about hlsl though, as this is more a common sense idea that if you don't want out-of-range BTB values processed, you should clamp it. Someone who knows better should probably verify the functionally of such a change, but does that fix your problem?

leeperry

3rd June 2013, 00:07

Couldn't that script be fixed [..] if you don't want out-of-range BTB values processed, you should clamp it. Someone who knows better should probably verify the functionally of such a change, but does that fix your problem?
Ouh, :goodpost: (always wanted to use this emoticon ^^)

That sure would explain why full range source files looked utterly washed out indeed...this quick comparison on a 16-235 rec709 test pattern looks identical(only the filesize is 1 kb smaller for some reason, dithering was disabled of course):

untouched: http://thumbnails105.imagebam.com/25794/721bfa257938607.jpg (http://www.imagebam.com/image/721bfa257938607)

clamped: http://thumbnails102.imagebam.com/25794/5fac43257938605.jpg (http://www.imagebam.com/image/5fac43257938605) unclamped: http://thumbnails105.imagebam.com/25794/dae5f8257938606.jpg (http://www.imagebam.com/image/dae5f8257938606)

Also my funky 0-255 sample looks fine now, looks like you nailed it! :thanks:

I will run more thorough tests and maybe the original PS script didn't care because as madshi said BTB/WTW were clipped by design if I understood him correctly...if madshi could please confirm that you nailed down the root problem, maybe a "compatibility mode" checkbox would still be fruitful in order to provide 100% compatibility with scripts that expect BTB/WTW to be clamped/clipped by design :)

I did send a few PM's to JohnAd but he hasn't connected to AVS in a while(his PM box must be full by now) and same goes for his company's official forum.

ryrynz

3rd June 2013, 00:41

I can't reproduce this issue on my HD4000 (win8 x64). My present queue fills perfectly fine.

Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.

karamancho

3rd June 2013, 01:16

I have a terrible lag in windowed mode but only with some videos. The OSD says their composition rate is 30.000Hz (no lag in 60.000Hz videos). Is this madvr related or is it the videos 'fault'?

Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.

conformed.
edit: it doesn't happen in the newest beta http://justgetflux.com/news/2013/05/29/beta.html

ryrynz

3rd June 2013, 01:51

edit: it doesn't happen in the newest beta[/URL]

Installed the beta, and still has the issue. Disabling or selecting movie mode doesn't change anything either, the program has to be terminated. I've mentioned this problem to the team on their website.

Madshi is it possible to block programs making changes in this way while MadVR is active? Maybe there are other programs that can affect MadVR in the same way?

madshi

3rd June 2013, 08:09

Couldn't that script be fixed quite simply by changing the original [...] to the following which adds a clamp for out-of-range values:

c0 = clamp(c0, 0.0, 1.0);
Good thinking!

Although, actually I had already suggested a very similar thing. However, my suggestion had a bug in it. I had suggested "saturate(c0)" which is the same as "clamp(c0, 0.0, 1.0)". But my mistake was that I suggested "saturate(c0)" instead of "c0 = saturate(c0)". Doh.

Found out what's causing it. It's a program called f.lux which makes the color of your computer's display adapt to the time of day. Removing this from memory the queue fills as it should.
Interesting. I remember somebody mentioning f.lux making problems before...

I have a terrible lag in windowed mode but only with some videos. The OSD says their composition rate is 30.000Hz (no lag in 60.000Hz videos). Is this madvr related or is it the videos 'fault'?
Composition rate is not really related to the video itself. It's the internal OS' Aero redraw rate. Normally it's expected to be identical to the GPU refresh rate. In your case it seems that sometimes the OS chooses a composition rate of only 30.000Hz instead of 60.000Hz, although the GPU refresh rate is probably 60.000Hz (it is, isn't it?). Don't ask my why the OS is doing that. Very stupid, IMHO.

Are you using the madVR display mode changer? Or some other display mode changer?

Madshi is it possible to block programs making changes in this way while MadVR is active? Maybe there are other programs that can affect MadVR in the same way?
For that I'd have to know what those other programs are doing to affect madVR. I don't know that. And even if I knew, madVR would not be able to stop that, unless you wanted madVR to inject a hook dll into all running processes, which would be a rather dramatic thing to do...

ryrynz

3rd June 2013, 09:03

unless you wanted madVR to inject a hook dll into all running processes, which would be a rather dramatic thing to do...

Indeed. One of the mods on the F.lux website seems to think it's a GPU driver bug. I'll wait for confirmation of that first and if that's the case I'll ask that you pass that on to your Intel contact if that's alright.

madshi

3rd June 2013, 10:55

Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.

SamuriHL

3rd June 2013, 12:32

Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.

Sweet!

Sent from my Xoom using Tapatalk HD

Boltron

3rd June 2013, 13:40

Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.

Cool.

6233638

3rd June 2013, 16:02

Good news: I think I found a way to make refresh rate switching (23Hz vs 24Hz, 59Hz vs 60Hz) work correctly in win8.Excellent news! Can’t wait to try out the fixed version. :D

karamancho

3rd June 2013, 16:36

Are you using the madVR display mode changer? Or some other display mode changer?

I'm not using any display mode changer and my display modes list in devices > display modes is empty. Should I add anything to it?

madshi

3rd June 2013, 16:41

I'm not using any display mode changer and my display modes list in devices > display modes is empty. Should I add anything to it?
You don't have to use it if you don't need it. I'm just wondering why your composition rate seemingly changes, depending on which video you're playing. You do mean the composition rate reported by the madVR OSD (Ctrl+J), right? This composition rate usually only changes if the display mode is changed. So how can it change in your case, if you don't use any refresh rate / display mode changer?

karamancho

3rd June 2013, 17:02

You do mean the composition rate reported by the madVR OSD (Ctrl+J), right?

yes

So how can it change in your case, if you don't use any refresh rate / display mode changer?

f.lux might be the problem again. I just disabled it and started a movie that was 30.000Hz and its now back to 60.000Hz.

whats more interesting, after starting f.lux again the same movies composition rate now stays 60.000 (after restarting the player of course) :confused:

mindbomb

3rd June 2013, 18:31

for dxva scaling for intel chips-
with what generation did they move from shaders to a specific scaling asic?

AndreaMG

3rd June 2013, 19:38

Here is a test with Haswell + MadVR + LAV Filters :)

http://www.anandtech.com/show/7007/intels-haswell-an-htpc-perspective

Danat

3rd June 2013, 20:00

Hi madshi. Really appreciate your work on this unique piece of software. I'm using madVR for everything I watch.
Recently I've hit the CPU limit on some 1080p video. I've figured out the exact reason and I'd like to request one small change in madVR config. On like 5 highly detailed fragments (with duration ~15 seconds each) of the entire video, I have stuttering and AV desync (100% CPU usage, decoder queue slowly becomes empty -> hiccups), then everything gets back to normal (60-70% CPU usage, full decoder queue). The bottleneck side-effects appeared even if using EVR renderer, so its the decoder/cpu speed issue. However I've noticed that madVR can pre-buffer decoded frames in advance, which can help my PC to distribute CPU load between heavy and light parts of the video, but the 32 queue size is not enough to achieve this (at least for this video),
so my question/feature request is: Can you increase the configurable CPU queue size to smth like 128 :D, so I could use all my RAM for buffering ?

I tried to hack the madVR registry config values to set 64 queue size, so I could see how that would work out for me, but that didnt work - when I ran MPC-HC the queue size became 12 instead. In case you don't want to mess up the UI with overTICKed trackbar, then perhaps can you allow manual registry config value changes outside of the UI range to be properly processed by madVR ? Or maybe some numeric box under the trackbar for "above 32" values (could be made as a trackbar value multiplier) ? ;)

My specs are:
Athlon II X2 215 ~2.7GHz; NVIDIA GeForce 8800 GTS (320 MB); 3 GB RAM
Win XP SP3; 1920x1080@72Hz
MPC-HC(v1.6.7.7091); LAV(v0.57)-Splitter/Video/Audio; madVR(v0.86.1); ReClock;

Video material:
1860x1048 @ 23.976 fps (1080p x264 Hi10p)

madVR rendering settings:
CPU queue: 32
GPU queue: 8

Setting CPU queue size to 4 doesn't help - it plays the fragment slower/longer with frequent but small frame drops and I think the video looks less stuttering because of that, but the AV desync is still there - even a bit worse than with 32 queue size.

truexfan81

3rd June 2013, 20:46

Danat

3rd June 2013, 21:02

if you have 100% cpu usage its going to drop frames no matter what settings you use, sounds like you need a faster cpu to play that videoI understand that, though while the decoder queue is being emptied the video goes smooth enough (I'm not demanding 0 frame drops lol, if that was the impression). It almost plays fine the first heavy ~7 secs fragment - only on 6-7-th seconds i see heavy stuttering and audio becomes choppy which is quite disturbing ;). Thats how I got an idea of increasing the queue size more.

I love my PC because its properly configured and works like a clock without glitches. This is the only video so far that I got unsolvable problems with (I've been watching many 1080p videos just fine) and I'd rather try out some options such as these before thinking about selling the case :(.

kiccolsd

3rd June 2013, 21:08

Anyone can help me with ringing artifact issue? I have downgraded Intel HD4000 driver to 29XX in order to use Madvr but I'm experiencing some ringing. Tried a lot of 1080p mkv's played on a 1080p LCD therefore I can exclude resize related issues.

madshi

3rd June 2013, 21:35

f.lux might be the problem again.
Argh...

for dxva scaling for intel chips-
with what generation did they move from shaders to a specific scaling asic?
I don't know if they ever used shaders.

Here is a test with Haswell + MadVR + LAV Filters :)
Nice - good to see Haswell finally gets the refresh rates right!

Can you increase the configurable CPU queue size to smth like 128 :D, so I could use all my RAM for buffering ?
Hmmmm... I'll think about it...

Anyone can help me with ringing artifact issue? I have downgraded Intel HD4000 driver to 29XX in order to use Madvr but I'm experiencing some ringing. Tried a lot of 1080p mkv's played on a 1080p LCD therefore I can exclude resize related issues.
I'm not sure I understand what you mean. Do you think that your playback chain somehow adds ringing artifacts to the movie which aren't in the original movie source? Can you show me a screenshot of the exact artifact you mean?

cyberbeing

3rd June 2013, 22:49

Nice - good to see Haswell finally gets the refresh rates right!
Not that that 23.97605 Hz really helps much when the clock deviation is so high at 0.00472% with a dropped frame every 14.84 minutes like their screenshot. The refresh rate of 23.97605 is actually very far from optimal on Ananatech's ASRock Z87E-ITX Haswell testbed in this instance, and still means using something like Reclock is required. I wish review sites like Anandtech would do more in-depth testing on the clock deviation with various hardware setups to find the best matches at standard refresh rates.

IMHO, the optimal setup is one which madVR reports drop/repeat every 3-7+ days when not using Reclock (or similar) with default GPU refresh rate settings. Matching the refresh rate to clock deviance is pretty much the only way to achieve perfect sync without degrading quality in some way, but unfortunately many GPU drivers are too inflexible to lock in fine-tuned refresh rates. This is the main thing going for using madVR with a high refresh rate multiple instead of a matching refresh rate if you seek to fine-tune refresh rate around stubborn drivers. Assuming the driver allow refresh rate timing tweaks of some kind, it becomes exponentially easier to lock in a clock deviance matched refresh rate each time you increase the refresh rate multiple.

Hmmmm... I'll think about it...

If you do implement a high CPU queue like 128, you may want to consider adding an additional slider for the Subtitle queue and/or have it match the GPU queue size instead. Setting the Subtitle queue smaller than than CPU queue I would actually expect would improve reliability in cases of CPU bottlenecks, similar to how setting the CPU queue slightly higher than the GPU queue does.

6233638

3rd June 2013, 22:58

Why is it that video cards have such a hard time outputting the exact clock that you set anyway?

nevcairiel

3rd June 2013, 23:02

Usually precision issues with the clock generators, or inflexibility issues. It may be designed for 23.9760 specifically, but that doesn't mean it can do 23.977 to compensate for audio deviation.

e-t172

3rd June 2013, 23:19

Wait. If I understand this correctly, if you use the same HDMI port for audio *and* video, they should be governed by the same clock (since, AFAIK, in HDMI audio is transferred during the blanking interval between two frames). If that's the case, why is clock deviation still an issue? Shouldn't they be perfectly in sync since it's the *same* clock? Or are we only discussing the case where audio is transported separately (e.g. analog)?

Buckster

3rd June 2013, 23:20

I did some more viewing with Smooth Motion rendering on tonight - watching snippets of films I've watched over and over again (you know those AV demo worthy parts that are worth watching over and over again :) )

what has really shocked me is how with Smooth Motion on - I'm noticing details I've never noticed before - when I say details I don't mean as in it looks sharper, or there is more detail on screen so to speak, but just that there seems to be so much more content in any shot with motion

genuinely leagues better - ok there is the odd very minor additional artefact - but perfectly acceptable

I'm not normally one for "post-processing" - but whatever Smooth Motion is doing it works for my setup - so thanks !

I'm comparing 24p from MadVR as 24p input into TV (my Panasonic plays 24p at 23.976hz which is quite unusual) - you get noticeable flicker in Windows Desktop - but no obvious flicker whilst watching films

to 60p from MadVR as a 60p input into TV

in theory the Panasonic playing 24p content with near to no processing without Smooth Vision should be the ideal setup - but with Smooth Vision on its leagues better

cyberbeing

4th June 2013, 00:23

Or are we only discussing the case where audio is transported separately (e.g. analog)?

It applies to all cases where madVR does not report drop/repeats every "1#J days". My testing with HDMI audio both PCM & Bitstream on my NVIDIA card, tells me it's not excluded. DirectShow's reference clock on the PC is a difference beast related to timing and sync compared to standalone consumer electronic devices.

I have no idea what you consider as "video clock", but the "audio clock" is what DirectShow uses as a reference clock as interpreted by the "system clock". The clock deviance shown by madVR, multiplied by and added to the video frame rate is the "real" playback rate in DirectShow before anything ever gets passed over HDMI or other output. For example, in Anandtech's screenshot with 0.00472% clock deviance, the "real" video & audio playback rate is equivalent to ~23.97715 fps, which is higher than his display refresh rate of ~23.97605 Hz.

I've found madVR's "clock deviation" + "drop/repeat every" measurements to be highly accurate on my systems, but ultimately you should trust your eyes in combination with the number of actual frame drops/repeats/glitches madVR records in the OSD stats. At a certain point, if you are unable to perceive or detect any anomalies, its good enough.

callannn

4th June 2013, 16:23

Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide (http://myanimelist.net/forum/?topicid=516729) and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.

If anyone could help that would be great!

madshi

4th June 2013, 18:46

Not that that 23.97605 Hz really helps much when the clock deviation is so high at 0.00472% with a dropped frame every 14.84 minutes like their screenshot.
Well, the article text did mention that they got an estimate of one frame drop/repeat every couple of hours, IIRC. Not sure why the screenshot doesn't match that.

If you do implement a high CPU queue like 128, you may want to consider adding an additional slider for the Subtitle queue and/or have it match the GPU queue size instead. Setting the Subtitle queue smaller than than CPU queue I would actually expect would improve reliability in cases of CPU bottlenecks, similar to how setting the CPU queue slightly higher than the GPU queue does.
Why would setting the Subtitle queue *smaller* have a similar effect compared to having the CPU queue *bigger*. Both subtitle rendering and decoding are CPU tasks. So I would expect a *bigger* subtitle queue to be benefical for reliability. Of course CPU consumption will be higher while filling the queue. But once it's filled it doesn't matter how large it is. CPU consumption should go back to the same value. So I don't see any problem with a large subtitle queue.

Wait. If I understand this correctly, if you use the same HDMI port for audio *and* video, they should be governed by the same clock (since, AFAIK, in HDMI audio is transferred during the blanking interval between two frames).
In theory this sounds right. But in real life it doesn't always seem to work that way. I'm not sure, maybe they still use different clocks somehow. But what do I know...

I did some more viewing with Smooth Motion rendering on tonight - watching snippets of films I've watched over and over again (you know those AV demo worthy parts that are worth watching over and over again :) )

what has really shocked me is how with Smooth Motion on - I'm noticing details I've never noticed before - when I say details I don't mean as in it looks sharper, or there is more detail on screen so to speak, but just that there seems to be so much more content in any shot with motion

genuinely leagues better - ok there is the odd very minor additional artefact - but perfectly acceptable

I'm not normally one for "post-processing" - but whatever Smooth Motion is doing it works for my setup - so thanks !

I'm comparing 24p from MadVR as 24p input into TV (my Panasonic plays 24p at 23.976hz which is quite unusual) - you get noticeable flicker in Windows Desktop - but no obvious flicker whilst watching films

to 60p from MadVR as a 60p input into TV

in theory the Panasonic playing 24p content with near to no processing without Smooth Vision should be the ideal setup - but with Smooth Vision on its leagues better
Good to hear. FWIW, there have been multiple Panasonic plasma owners now saying similar things. It seems that the 24Hz implementation of Panasonic plasmas is severely lacking.

Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide (http://myanimelist.net/forum/?topicid=516729) and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.
We don't have enough information to help. Without any more info all I can do is give general hints like:

(1) Make sure you disable tools/applications which might eat GPU performance. E.g. newer Firefox/Chrome/IE versions might use the GPU for rendering tasks. Or recently it has been reported that the "f.lux" and "GpuZ" tools can also result in video playback problems. So close them before watching a movie.

(2) Make sure your GPU doesn't clock down. This has happened to some users. I think some tweak tools allow to fix the clock to some specific value.

If these hints don't help, make a screenshot of the madVR OSD (Ctrl+J) in the moment when those frame drops occur. If you can't make a screenshot (FSE mode?), please at least write down the state of the queues and report them here. Then we can go from there...

madshi

4th June 2013, 18:49

madVR v0.86.2 released

http://madshi.net/madVR.zip

* fixed: refresh rate changing didn't always work correctly in Windows 8
* fixed: MPC-BE title bar didn't handle unicode characters correctly
* fixed: IVideoWindow::putBorderColor() had swapped colors (RGB -> BGR)
* fixed: #18: decoder queue sometimes exceeded limits
* fixed: #19: blank screenshots when Smooth Motion FRC is turned on
* fixed: #23: video didn't follow overlay window position when paused
* fixed: #34: smooth motion FRC was sometimes incorrectly turned on
* fixed: #35: framerate tag was not working
* fixed: #37: when no video duration was known, seekbar was not shown
* fixed: #42: memory leak with certain OSD elements
* fixed: #44: GraphStudioNext "Performance Test" Crash
* fixed: #46: xy-vsfilter: 3DLUT was not applied to frames with subtitles
* fixed: #47: xy-vsfilter: subtitles weren't rerendered after scaling change
* fixed: #48: xy-vsfilter: incorrect positioning after downscaling
* fixed: #49: xy-vsfilter: incorrect PGS subtitle positions
* fixed: #50: xy-vsfilter: smooth motion FRC caused subtitles flicker
* fixed: #51: settings dialog now mentions both ReClock and VideoClock
* fixed: #52: xy-vsfilter: incorrect ASS subtitle positions
* fixed: #55: FSE seek bar resulted in inaccurate seeking for DVDs
* fixed: #60: all kinds of artifacts with smooth motion FRC
* fixed: #62: crash when external 3dlut file with long filename was missing
* fixed: #65: film refresh rate was used with dxva decoding -> deinterlacing
* fixed: #66: Cineform decoder v210 (10-bit 4:2:2) corruption
* smooth motion FRC should be back to v0.86.0 performance levels
* increased max CPU queue size to 128 frames
* added support for DCI-P3 and BT.2020 primaries and BT.2020 matrix
* added support for "matrix=2020" and "primaries=2020|DCI" tags
* added resolution based auto detection for BT.2020 (UHD) and DCI-P3
* added explicit detection for non PS3.0 capable GPUs
* added IMadVRInfo interface which makes all sorts of info available
* added a couple workarounds for weird crashes that were reported
As you can see, the new release contains a multitude of bug fixes. Hope nothing new got broken in the process.

Please test and report whether the Smooth Motion FRC related bugs have been fixed in this build.

Btw, Smooth Motion FRC performance should hopefully be back up to v0.86.0 levels (which was faster than v0.86.1). I hope that this performance improvement didn't bring back problems. Let me know...

raul31

4th June 2013, 18:59

Hi madshi,

congratz on the new version that u hav JUST released.
Looking forward to using it very soon.
btw, i'm a newbie so i'm going to ask the following:

what i want to know is, what exact options should i choose within LAV video with regards to the following to get the possible image:
> (hardware acceleration) -> hardware decoder to use: none, nvidia cuvid, intel quicksync, DXVA2 (native), or DXVA2 (copy-back) ? & why
> RGB Output Levels: TV, PC, or UNTOUCHED ? & why
> Dithering Mode: Ordered or Random ? & why
> there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options?

i also wanted to know:
i have a 2nd gen I7 [2670] processor & 1GB nvidia GT 525m... all within a beautiful dell xps l502x (WISH i went for the model with 2GB GT 540m )
how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card?
the ONLY thing that should use the nvidia card is MadVR, but how can i exclusively make sure that the nvidia card isn't spending it's power on other decoding? i ONLY want the nvidia card for MadVR & NOTHING else, but can this setup be done where one can choose what processes what etc.

thanks madshi!!!

looking forward to your guidance.

mark0077

4th June 2013, 19:03

thanks madshi!

6233638

4th June 2013, 19:40

fixed: refresh rate changing didn't always work correctly in Windows 8This switches to 24Hz and 60Hz correctly now, but still restores to 59Hz when exiting fullscreen mode. (when previously set to 60Hz on the desktop)

I have also noticed another issue, that may not be madVR's fault.
In JRiver Media Center, if you have their display mode switcher disabled, stopping playback without exiting fullscreen view first, does not attempt to restore the display mode at all. (so stopping a 24Hz video leaves my display at 24Hz)

Seems like a good release otherwise. I appreciate the BT.2020 support being ready for when 4K content is (largely) available.

EDIT: And I'm quite sure that you are aware of it, but using a decoder queue size of 128 takes rather a long time for the image to update when switching between fullscreen and windowed modes, even with "delay playback start until render queue is full" disabled.

Asmodian

4th June 2013, 19:54

what i want to know is, what exact options should i choose within LAV video with regards to the following to get the possible image:
> (hardware acceleration) -> hardware decoder to use: none, nvidia cuvid, intel quicksync, DXVA2 (native), or DXVA2 (copy-back) ? & why
> RGB Output Levels: TV, PC, or UNTOUCHED ? & why
> Dithering Mode: Ordered or Random ? & why
> there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options?

i also wanted to know:
how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card?

I'll give some answers to keep madshi free to keep up the good work. These have been covered many times in this thread and I don't think madshi needs to keep answering. :)

(hardware acceleration):
It sounds like you want "none" to me. This is what I use as well, all the other options use the GPU. The "hardware" doing the acceleration is on the GPU.

RGB Output Levels:
Untouched, leave converting color spaces to MadVR.

Dithering Mode:
Random unless you plan to re-encode the output. Random is visually higher quality but it does not encode as well.

You can turn on Yadif in LAV for software deinterlacing, I use video mode for real interlaced video (30i in my case).

All you need to do in LAV to keep the GPU free is to use "none" for hardware acceleration and don't use any shader scripts in MPC-HC.

noee

4th June 2013, 19:57

...
I have also noticed another issue, that may not be madVR's fault.
In JRiver Media Center, if you have their display mode switcher disabled, stopping playback without exiting fullscreen view first, does not attempt to restore the display mode at all. (so stopping a 24Hz video leaves my display at 24Hz)

I see the same thing, but when I then exit jrMC, the display switches back. It's almost like MC is the holdup like it's not "releasing" madVR or madVR not picking up that playback has stopped for some reason.

I'm on Win7 Ult, however. Curious what happens when you close MC.

Danat

4th June 2013, 19:59

Thank you madshi !
Just tried out the 128 CPU queue - and yes it works just like I hoped it would ;) ! Guess I can still count on my PC for this video ;).
First 4 heavy fragments play like there never have been any stuttering on them. The 5-th fragment, which is the longest (23 secs), has some stuttering at the end (decoder queue empty). I've noticed that RAM usage per decoded frame is lower than I expected (6.5 MB) which leaves me with 1 GB free RAM, so if you ever gonna be in the mood to return to this feature, please add some more ticks after 128 (btw I like your solution with 56,64,96,128), like 192, 256. I understand that it's a bit awkward workaround for a slow CPU, but who needs RAM for smth else when watching HD movies anyway ;).

Good job on update.

6233638

4th June 2013, 20:08

I see the same thing, but when I then exit jrMC, the display switches back. It's almost like MC is the holdup like it's not "releasing" madVR or madVR not picking up that playback has stopped for some reason.

I'm on Win7 Ult, however. Curious what happens when you close MC.Ah, you're right - though I had to close Media Server as well, which is why closing Media Center alone didn't seem to work.

e-t172

4th June 2013, 20:23

I have no idea what you consider as "video clock", but the "audio clock" is what DirectShow uses as a reference clock as interpreted by the "system clock". The clock deviance shown by madVR, multiplied by and added to the video frame rate is the "real" playback rate in DirectShow before anything ever gets passed over HDMI or other output. For example, in Anandtech's screenshot with 0.00472% clock deviance, the "real" video & audio playback rate is equivalent to ~23.97715 fps, which is higher than his display refresh rate of ~23.97605 Hz.

What I mean is, the way audio over HDMI works is that audio is transferred during the blanking interval between two frames. The simplest way to make it work from the point of view of the GPU manufacturer is to make sure the number of audio samples transferred between two frames is equal to the frame duration. So, for example, if the refresh rate is 24Hz, then 2000 audio samples (assuming 48kHz sampling rate) of audio will be sent between each frame. As long as the hardware (driver, GPU, whatever) enforces that (which is very easy: just push 2000 samples between each frame, no more, no less), then everything should be fine and no clock deviation should occur, ever, because there's nothing to deviate from: there's only one clock, and it's the video clock (i.e. the clock that controls the refresh rate). Sure this one clock might not be perfectly accurate, but that doesn't matter: the device at the other end of the cable is slaved to the clock of the sending side anyway, so that's not an issue.

Contrast this with the traditional situation where you have a video output and an analog sound card output: in this case you're dealing with the video (refresh rate) clock and the audio (sample rate) clock, which won't be perfectly in sync. In other words, instead of sending 2000 audio samples during a vsync interval (assuming 24p and 48kHz), sometimes you'll send 1998 samples, or 2002 samples (or something else), in other words the two clocks will deviate from each other, and that's why you can't prevent frame drops (unless you use ReClock and/or FRC of course). If instead the video output is also taking care of sending the audio, then the issue goes away completely: one component (the GPU) has control over everything, so it just has to make sure it uses the same clock for everything and just send the correct, constant amount of samples each time. In the case of 24p and 48kHz, it just knows it has to send 2000 samples between each frame, because 48000 / 24 = 2000. That's it. It's that simple. There's no clock deviation, because the audio is now slaved to the vsync.

At least that's the theory. In practice we're still seeing clock deviation when playing both audio and video over HDMI, which, I must say, puzzles me. That would mean that GPU manufacturers are using two clocks for video and audio, which doesn't make any sense because that's actually harder than just doing the right thing and using one single clock.

ajp2k11

4th June 2013, 20:50

madshi

4th June 2013, 21:27

any idea why I get a black screen when trying to play some files? If I switch to exclusive mode it says the refresh rate is 0 Hz. Ctrl-J in windowed mode doesn't display...
If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...

ajp2k11

4th June 2013, 21:34

If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...

Thanks, but isn't it weird that I get this problem only with some files and never with others? Also, it much more common when the files are 1080p and not 720p. It's always the same files too, some files never work...ever. They work fine with EVR-CP though...

madshi

4th June 2013, 21:37

EVR has a totally different presentation logic, it doesn't depend on vsync scanline information.

Not sure why it only occurs with specific video files. Makes no sense to me, unless you're using DXVA decoding and/or DXVA deinterlacing? Try with software decoding and try with deinterlacing turned off. But really, I simply don't have enough information to do anything about this...

callannn

4th June 2013, 22:09

We don't have enough information to help. Without any more info all I can do is give general hints like:

(1) Make sure you disable tools/applications which might eat GPU performance. E.g. newer Firefox/Chrome/IE versions might use the GPU for rendering tasks. Or recently it has been reported that the "f.lux" and "GpuZ" tools can also result in video playback problems. So close them before watching a movie.

(2) Make sure your GPU doesn't clock down. This has happened to some users. I think some tweak tools allow to fix the clock to some specific value.

If these hints don't help, make a screenshot of the madVR OSD (Ctrl+J) in the moment when those frame drops occur. If you can't make a screenshot (FSE mode?), please at least write down the state of the queues and report them here. Then we can go from there...

Ah sorry, what additional info would you need? I don't have f.lux installed on my laptop anymore as it was messing with playback and giving me a huge amount of frame drops, and I never have GPU-Z open or in use in the background when watching a video. I don't actually have anything in use at all when watching videos.

I'm not actually sure how to prevent my GPU from clocking down, so if anyone could tell me I would appreciate it.

I've included this screenshot here (http://i.imgur.com/SH8wZ9T.png) taken at the end of an hour long video for you to have a look at if that is any help?

madshi

4th June 2013, 22:14

The OSD screenshot only helps if it's directly from the situation when the frame drops occur. The additional info we need is for example which queues are (near) empty when those frame drops occur.

Soukyuu

4th June 2013, 23:03

The new version works flawlessly so far, and I can now take screenshots without having to disable smooth motion, thanks!
A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime?

Hi, I seem to be having a slight problem. Usually on playback I get no dropped/delayed frames at all, but sometimes I can watch the exact same video again (that I've previously had no dropped/delayed frames) on a different day and receive a significant amount of delayed frames (usually ranging from around 70-130 I've noticed). Does anybody know why this is?

If it helps, here are my specs: Samsung NPC700G7C, 16.0GB RAM, Intel Core 17 3610QM @ 2.30GHz, GTX 675M
I'm also using Niyawa's Guide (http://myanimelist.net/forum/?topicid=516729) and use it exclusively for anime playback. I'm also using his 'highest settings' for the scaling algorithm's.

If anyone could help that would be great!
If you jump near a scene where the framedrop happens, it could be that the decoder queue doesn't fill up fast enough to not drop frames vs. having enough time if you watch the whole episode. I solved nearly all my buffering problems with LAV by just increasing the cpu queue to 64. I'm saying "problems with LAV" because on my test files I get no frame drops with haali, but I do with LAV. So it might be the same for you, I already notified nevcariel about it.

cyberbeing

4th June 2013, 23:07

So I don't see any problem with a large subtitle queue.
It's helpful to layer & stagger even different types of CPU queues in my experience. With the first/top queue in a display chain being the largest, while the ones which follow being progressively smaller but with higher CPU thread priority than the prior queues in an attempt to ensure they stay full in real-time under heavy load. The logic is that the largest fast-filling queue have enough of a buffer to prevent the slower-filling queues below from emptying below 100% full, if you temporarily become bottlenecked.

Though my main concern that I thought you'd catch on to, was cases where you need to re-request and re-alphablend your entire subtitle queue instantly because of that change you made in 0.86.2 to decrease update delay on resolution change. I already saw this as barely acceptable with a CPU queue of 24. But now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill, which could take a couple seconds if something computationally heavy is being displayed for the entire queue size. It would only be worse with slower CPUs. With a smaller queue, this effect would be minimized or eliminated. If you don't want to separate the CPU and Subtitle queues, maybe you should consider expanding the "delay playback" option to wait for subtitle queue to be completely full for "playback start", "seek", and "window resizing".

IMHO, you need to make one change or the other, otherwise user experience will suffer with large CPU queue + Subtitle queue size.

TheShadowRunner

5th June 2013, 00:15

Hi madshi,
A quick bug report (not due to this new build, as I tested with 0.86.1):
madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up.
A sample file: here (http://videoff7.free.fr/cvid_sample.avi).
In the exact same graph, replacing madvr by the VMRs or EVR solves the issue.
Unrelatedly, now on to test 0.86.2, thanks for this new build!

Edit: same bug with 0.86.2.

digitech

5th June 2013, 00:25

Madshi,

any idea why I get a black screen when trying to play some files? If I switch to exclusive mode it says the refresh rate is 0 Hz. Ctrl-J in windowed mode doesn't display...

I've had this problem for a long time, think it might have appeared when switching to Win8. My laptop display is capable of 60/120Hz. Using AMD graphics and I've tried resetting all settings to default.

You've looked at a debug log once but couldn't find anything, could the 0 Hz thing be a clue?

Grateful for any help...
Just to make sure... check if you are having another instance of your same video player running in the background, it has happened to me more than once that i already was having two mpc running at the same time thinking i was able to close the first one correctly, then a blank screen appears when i accidentally open the second time the same player and left the first one running, i hope you can understand my lingo-english.