madVR - high quality video renderer (GPU assisted)

[madshi]

Great - good to hear!

[sexus]

Originally Posted by madshi

You should be able to reduce the lag a bit by reducing the size of the GPU queue, the number of "presented frames in advance", and/or maybe even by disabling the "present several frames in advance" options completely for both windowed and exclusive mode. In the end this is a lag that is "by design", though. Changing the options mentioned above should reduce the lag, but it will not totally get rid of it. The reason for that is that madVR tries to render many frames in advance, to make sure playback stays smooth even if the PC gets super busy for short periods of time during playback.

Maybe I can find a way to reduce the lag in a future madVR build, but for now I have different priorities.

disabling the "present several frames in advance" options completely for both windowed and exclusive mode has never been enabled from the getgo on my setup so thats a none issue, about the gpu queue / cpu queue and the number of presented frames in advance , what settings do you suggest? ive currenlty got gpu queue at 24 and cpu queue at 48 and prerendered frames at 8 and yes id really appreciate if you could fix this issue with a future madvr build indeed , i understand youve got more pressing issues at hand as of currently , ill gladly wait for this annoying issue to be fixed madshi thanks for your time as always

[ryrynz]

Originally Posted by sexus

what settings do you suggest? ive currenlty got gpu queue at 24 and cpu queue at 48 and prerendered frames at 8 and yes id really appreciate if you could fix this issue with a future madvr build indeed , i understand youve got more pressing issues at hand as of currently , ill gladly wait for this annoying issue to be fixed madshi thanks for your time as always

Just drop them by half for starters and keep lowering them to see what effect they have on the lag if any, personally I think your queues are higher than they likely need to be.

[dbezerra]

From Madshi:

"Strange. Can you still reproduce the problem with the new test build (see above)? Have you tried resetting the kodi specific madVR settings and to reset madVR to default settings? Which settings do you need to change to make the problem appear then? A debug log might eventually help, although I'm not sure..."


After I reported this issue here I found out that the problem only happens when:
a. NNEDI is enabled (even if no downscale is necessary)
b. I have both Kodi and MadVR set to adjust the framerate.

By disabling the adjust framerate on Kodi this problem went away, although I also lost the ability to set the proper frame rate when not using DSPlayer/MadVR. (streaming for example).

I will check your beta build just in case. But now this is a low priority issue for me.

[madshi]

Originally Posted by sexus

disabling the "present several frames in advance" options completely for both windowed and exclusive mode has never been enabled from the getgo on my setup so thats a none issue, about the gpu queue / cpu queue and the number of presented frames in advance , what settings do you suggest? ive currenlty got gpu queue at 24 and cpu queue at 48 and prerendered frames at 8 and yes id really appreciate if you could fix this issue with a future madvr build indeed , i understand youve got more pressing issues at hand as of currently , ill gladly wait for this annoying issue to be fixed madshi thanks for your time as always

The default is a GPU queue size of 8, IIRC. I'm not sure if that's what I'd recommend. Depends on whether you're using smooth motion FRC, which can always use a few frames more. In any case, as ryrynz suggested, just play with the queue sizes and with the "number of backbuffers". E.g. just try a GPU queue size of 4, and also set the "number of backbuffers" to 3. Does that reduce the lag? If so, check if you still get perfectly smooth playback. If not, increase the queue sizes a bit again. But first check if reducing these options has any effect on the lag at all.

BTW, I think the CPU queue size should have no effect on the issue, so you can keep that high.

Originally Posted by dbezerra

After I reported this issue here I found out that the problem only happens when:
a. NNEDI is enabled (even if no downscale is necessary)
b. I have both Kodi and MadVR set to adjust the framerate.

By disabling the adjust framerate on Kodi this problem went away, although I also lost the ability to set the proper frame rate when not using DSPlayer/MadVR. (streaming for example).

I will check your beta build just in case. But now this is a low priority issue for me.

Interesting. I'm not sure what's happening there, to be honest. But it's not good to have 2 different pieces of software fight over which frame rate and display mode should be used. If you use DSPlayer sometimes with and sometimes without madVR then maybe you could ask for a setting in kodi which enables framerate adjustments only when *not* using madVR?

[sexus]

oh hey , sup ryrynz , anyhow ok madshi so ive set gpu queue to 4 even thou huhn recommended against it due to it most likely breaking deinterlacing and introducing dropped frames as well did i reduce prebuffered frames to 3, ok , the OSD lag is noticeably less since aka you now have effectively 4 frames of OSD lag instead of 24 according to huhn , not sure what setting prebuffered frames would do for the OSD lag thou but i set them to 3 as recommended by you anyhow , ill now check for dropped frames , not sure how to check for broken deinterlacing thou ?

[madshi]

As long as you don't get any dropped frames, you'll probably be fine. The good news is that reducing the lag through the settings works for you. Now you just need to find the lowest queue size that plays smoothly for you.

[sexus]

well anything above 4 gpu queue size is noticable in OSD lag so , not sure what exactly to tweak then , say if i now have broken deinterlacing , which i still have no idea how to even notice or have dropped frames , and raising the queue further would fix this logically , but would introduce OSD lag that is noticeable aka anything above 4 frames of lag is noticeable on the OSD, ive tried,the best way to test this is as said, is to quickly go up and down with the volume and the OSD lag becomes very apparent, you can literally see the delay, you must already know this since youve tried

[ryrynz]

Originally Posted by sexus

oh hey , sup ryrynz , anyhow ok madshi so ive set gpu queue to 4 even thou huhn recommended against it due to it most likely breaking deinterlacing, ill now check for dropped frames , not sure how to check for broken deinterlacing thou ?

Hey there, been awhile.. Anyway, deinterlacing isn't something that's used by many people these days as most media is generally progressive content so unless your watching TV broadcasting or DVDs it's unlikely you
will need deinterlacing.

I've only ever used it a few times since madVR came out, so if you're in the same boat it isn't a deal breaker setting the GPU queue to 4.

[huhn]

Originally Posted by sexus

oh hey , sup ryrynz , anyhow ok madshi so ive set gpu queue to 4 even thou huhn recommended against it due to it most likely breaking deinterlacing and introducing dropped frames as well did i reduce prebuffered frames to 3, ok , the OSD lag is noticeably less since aka you now have effectively 4 frames of OSD lag instead of 24 according to huhn , not sure what setting prebuffered frames would do for the OSD lag thou but i set them to 3 as recommended by you anyhow , ill now check for dropped frames , not sure how to check for broken deinterlacing thou ?

just play a deinterlaced file at best a broadcast file or interlaced BD.

in my experience a GPU queue of 4 can result in issue with IVTC/decimation or deinterlacing. usually 8 doesn't create any problems at least in my experience.

you can use alt + control +shift + d to force deinterlacing on any file the GPU deinterlace has a very easy job with deinteralcing progressive frames but still better than no tests.
here an example where it doesn't work with a 4 GPU queue and 2 present 2 frames in advanced:
http://abload.de/img/worksbiuph.png

at 5 GPU queue it was stable. i added SM always on top and it was still stable.

i'm not sure about present or buffered frames in advance. but the GPU queue has clearly an effect on KODI and the OSD from madVR in other players like mpc-hc. 8 or 24 GPU queue is day night. but i don't see a reason where you clearly need more than 8 GPU queue but of course not all system are the same.

[ryrynz]

Originally Posted by huhn

but i don't see a reason where you clearly need more than 8 GPU queue but of course not all system are the same.

Personally I think many people don't have good reason to go beyond the defaults, if there was the defaults would be higher.

[sexus]

i see thanks for the elaborate explanation and showing the deinterlacing issue, it appears that i have just about 0 high demanding deinterlaced files , maybe someone could upload one for me to test this, so we can further narrow down what gpu queue and backbuffers amount is needed to get 0 delayed and 0 dropped frames

btw my flush settings are set for both window and exclusive to

flush
flush and wait(sleep)
dont flush
flush

i recon these are correct

[ryrynz]

Originally Posted by sexus

btw my flush settings are set for both window and exclusive to

flush
flush and wait(sleep)
dont flush
flush

i recon these are correct

Default is 'don't flush' after D3D presentation.

[sexus]

ok ive just corrected that, btw according to huhn we have to set the gpu queue to atleast 5 in order to have deinterlacing not break on us, he just set his queue to 8 for safe measure, i guess having deinterlacing properly working is of importance as well once we start using madvr for live tv streaming and general streaming such as youtube videos on kodi, can anyone confirm huhns setting of 5 as a minimum requirement to have deinterlacing running stable?

[huhn]

Originally Posted by sexus

i see thanks for the elaborate explanation and showing the deinterlacing issue, it appears that i have just about 0 high demanding deinterlaced files , maybe someone could upload one for me to test this, so we can further narrow down what gpu queue and backbuffers amount is needed to get 0 delayed and 0 dropped frames

btw my flush settings are set for both window and exclusive to

flush
flush and wait(sleep)
dont flush
flush

i recon these are correct

i found this by googling interlaced samples https://dl.dropboxusercontent.com/u/...IGIANIMALHD.ts

and i found a new bug in madVR time to investigate i guess.

[sexus]

a bug related to deinterlacing , dropped frames , delayed frames or OSD lag?


btw that sample screenshot for failed deinterlacing isnt showing me anything noticeable , if you could point out the issue id appreciate it , since i seem to be a noob when it comes to deinterlacing

update: sweet mother of god , ive heard about a few frames dropped every so often in a movie but this is madness im getting a ton of dropped frames and delayed frames on that sample youve linked me to, plus a weird small thin black bar at the top left of the screen thats blinking, is this supposed to be like this? , its like about 1100 dropped frames and 250 delayed and counting depending on how long i let it loop , wtf! mind you dont use reclock , so all videos use the refresh of my monitors refresh which is at 60 hz

btw changing gpu queue size doesnt affect it either , ive also noticed gpu queue size doesnt affect delayed nor dropped frames whatsoever in a sample movie , alien anthology blueray that ive played , the movie alien, i always have a one or two dropped frames every 3-5 minutes at random, ive only got 1-2 delayed frame thou and 11 dropped frames , by letting it run for 30 minutes, on gpu queue 4, i recon this is good?

it seems to be the blueray the way its been encoded itself , maybe someone could upload an acurate delay and loss test

and

heres a screenshot


and about deinterlacing issues ,oldpoem over at kodi suggested to use lavfilters for deinterlacing instead of madvrs, is this a good idea?

[huhn]

Originally Posted by sexus

a bug related to deinterlacing , dropped frames , delayed frames or OSD lag?

has something to do with a dual monitor setup where one monitor is 120 hz and the other is 60 hz.

btw that sample screenshot for failed deinterlacing isnt showing me anything noticeable , if you could point out the issue id appreciate it , since i seem to be a noob when it comes to deinterlacing

update: sweet mother of god , ive heard about a few frames dropped every so often in a movie but this is madness im getting a ton of dropped frames and delayed frames on that sample youve linked me to, plus a weird small thin black bar at the top left of the screen thats blinking, is this supposed to be like this? , its like about 1100 dropped frames and 250 delayed and counting depending on how long i let it loop , wtf! mind you dont use reclock , so all videos use the refresh of my monitors refresh which is at 60 hz

btw changing gpu queue size doesnt affect it either , ive also noticed gpu queue size doesnt affect delayed nor dropped frames whatsoever in a sample movie , alien anthology blueray that ive played , the movie alien, i always have a one or two dropped frames every 3-5 minutes at random, ive only got 1-2 delayed frame thou and 11 dropped frames , by letting it run for 30 minutes, on gpu queue 4, i recon this is good?

it seems to be the blueray the way its been encoded itself , maybe someone could upload an acurate delay and loss test

maybe your madVR settings are way to high to render 50 FPS?
the black bar in the top left is part of the video.

heres a screenshot

think about adding a link to the screen attachment may take some time.

and about deinterlacing issues ,oldpoem over at kodi suggested to use lavfilters for deinterlacing instead of madvrs, is this a good idea?

you can try it but in general this is not that good.

[madshi]

madVR v0.87.18 released

http://madshi.net/madVR.zip

* fixed: #181: "deint" tag sometimes didn't work when using profiles
* fixed: #277: DVD Navigator: external subtitles displayed incorrectly
* fixed: target rects with odd widths/heights resulted in a black border
* fixed: SettingsSetBoolean("DebugOSD") didn't take effect immediately
* DXVA scaling is done in RGB again for Intel and NVidia
* DXVA performance improvement under certain conditions
* small performance improvement when movie aspect ratio doesn't match display
* 3dlut split screen mode can now supports mouse drag & drop
* 3dlut can now be temporarily disable (and reenabled) via keyboard shortcut
* some reliability improvements to refresh rate calculation algorithm

Wasn't really planning to do this release, but a couple of bug fixes were necessary/important, and one of the calibration software companies wanted extended 3dlut split screen functionality. So here you go. No further release planned in the next 2-3 weeks.

[sexus]

Originally Posted by huhn

has something to do with a dual monitor setup where one monitor is 120 hz and the other is 60 hz.

i see

maybe your madVR settings are way to high to render 50 FPS?
the black bar in the top left is part of the video.

so it would seem , perhaps its me using NEEDI64 for chroma upscaling + image doubling set to 16 for all..hmmm..anyone can confirm this?

think about adding a link to the screen attachment may take some time.

a what? you just have to click the attachment itll autolink, its currently showing as pending approval

heres the link

http://forum.doom9.org/attachment.ph...1&d=1428496439

you can try it but in general this is not that good.

whys that so?

[Digiface]

Just installed MadVR v0.87.18. Noticed that MPC-HC (1.7.8) freezes when seeking. This only seems to happen with files that uses Haali.

Edit. Installed earlier version of MadVR and now everything's fine again, so there's certainly something fishy with this new version?