madVR - high quality video renderer (GPU assisted)

[sat4all]

Originally Posted by madshi

Does the media player still react to mouse and keyboard events? Then a debug log may help. If not, a freeze report might help.

After uninstall/reinstall kodi i can't reproduce anymore.
Thanks alot for your precious time.
Btw i've decided to jump for kodi + mpc-hcfr.x64 as external player instead of dsplayer. Madvr x64 is a huge boost, cropped 1080p to uhd was impossible for me without ticking "use 10bit chroma/image buffer instead of 16bit" but thankfully, with x64 chain i can do it without ticking a single thing in trade quality for performance.

[Kevin Gilmore]

MadShi,

Please advise: wondering about cpu-load<PCI-e bus load from the renderer through MadVR

or weather any A-situational processing occurs that you/we know of where lots of CPU-GPU copy-back or
CPU post processing occurs.. that may or may not load the pci-bus moreso than otherwise.

Basically, is it a viable or good idea? Particularly @ higher desktop class MadVR options/settings...
Thunderbolt 3/usbC laptop now to.. tap the e-desktop gpu for its video decoders package/8k video output, etc..

The 8k teli could process the video signal [120/240-etc interpolation] from there.

https://www.techpowerup.com/reviews/...caling/22.html
[gtx980] Fairly recent pci-article if somehow relevant
a) This is of course presuming intermediary dock, decode/recode or Laptop-Thunderbolt III chipset are not ever an issue-they do not ever throttle.
1a) Though of course there could be slight delay/input lag like this e-gpu rep mentions here.

but I'd like your take on how MadVR coterminates with the CPU or loads the PCI-ebus through some of its settings..
If you'd care to provide a thoughtful answer I'll probably go for it and report what I find when new GPUs' are out..
Thanks MadShi

[aufkrawall]

madVR shouldn't copy back anything via PCIe, only LAV should do this with DXVA2 copyback mode.

[baii]

I thought it was said that pcie speed may make a difference for really extreme nnedi3 ?

Sent from my SM-T700 using Tapatalk

[Kevin Gilmore]

Aufkrawall, Baii, thanks for responding.
Are there any overt or outstanding bus-hogs in typical MadVR use? Or is running MadVR at full-tilt quite
manageable like any/many other a program on a somewhat lesser bus?

Under some active MadVR capabilities, must the CPU liaise multiple, or compounding data,
or bi-directional communication (I guess this would be post processing -- which heavily loads PCI-bus)? Than say, a typical Video-game render pipeline will have to, or requires?

..Absolutely no idea weather the GPU-Z-bus sensor is accurate though.
If the bus ceiling were met the result is a minimum fps drop, or microstutter?

This would be a good thing to know if we do not already have an idea

[kasper93]

When NNEDI3 quadruple is in use, OSD reports that luma is downscale with Bicubic150 AR instead of SSIM AR. Any reason for that?

[raymondjpg]

Is there a way to change the active device in madVR settings?

[ryrynz]

Originally Posted by kasper93

When NNEDI3 quadruple is in use, OSD reports that luma is downscale with Bicubic150 AR instead of SSIM AR. Any reason for that?

I found when I upgraded to. 9 after. 8 it defaulted to bicubic when I had SSIM detailed set in .8 what with it being deprecated and all. I actually tested quadrupling with SSIM the night before and the osd was correct for me so perhaps just change your Luma Scaler to something that's not SSIM and back again and that might fix it.

[Telion]

Originally Posted by madshi

I was able to reproduce the leak pretty reliably, and now it's gone for me. If the problem is still there for you I need some more information. Ideally I'd need to be able to reproduce it somehow. If that doesn't work out, can you please check if the problem is really 100% not there for you with v0.90.3, while it's definitely there with v0.90.9 (just to be safe). And then please create a debug log with v0.90.9 which captures the leak.

http://hugefiles.net/4eeyrwm5p5xz
I've found out that if I stop the playback before closing the file or opening another, the leak is never there (and it is so in both v0.90.4 and v0.90.9 builds). But if I do this while playing or on pause - sometimes it leaks, sometimes not. It seems to be completely random - I haven't been able to identify any pattern or dependencies. Also, the "stop" case doesn't depend on the presence of "DontRenderAfterStop" file.
So I created two debug logs - one with stop&close case (so no leak) and the other with immediate close after playback started (and with a leak of course). I have a rather slow rig, so maybe that matters and it is some sort of race condition. But definitely there were no such problem with v0.90.3 and before.

[baii]

Originally Posted by Kevin Gilmore

Aufkrawall, Baii, thanks for responding.
Are there any overt or outstanding bus-hogs in typical MadVR use? Or is/are the MadVR protocol quite manageable like any/many other a program on a somewhat lesser bus?

This would be a good things to know anyway, if we do not already have an idea

Never heard anyone having problem with pcie bandwidth. The nnedi3 thing was a artificial copying benchmark or w.e and never had been seen in normal use.
And if you are interested in egpu, techinferno is the go to place. They may have more knowledge on scalling or actual madvr use on egpu.
I don't think there would be much problem if it reorganized as native card.

Sent from my SM-T700 using Tapatalk

[Ver Greeneyes]

Originally Posted by Ver Greeneyes

Okay, I applied a quick dirty fix to the collink source. I'll see if it works, then post to the ArgyllCMS mailing list or something (my fix is very ugly, but also very simple, so it shouldn't be hard for Graeme to address if my fix works).

My hack was super slow, so I had to improve the code a lot, but now it works (at least on a low quality 3DLUT)! Would still be interested in a file format specification for madVR 3DLUTs while I have this code paged in

[huhn]

did you used/tried "input encoding TV RGB range 16-235 (clip WTW)?

[Ver Greeneyes]

Originally Posted by huhn

did you used/tried "input encoding TV RGB range 16-235 (clip WTW)?

... Oh wow, I missed that completely. I was looking for a separate option, and it's misaligned in the help file for some reason. Okay, well, at least you've saved me from an awkward exchange on the mailing list!

[nevcairiel]

Originally Posted by Ver Greeneyes

My hack was super slow, so I had to improve the code a lot, but now it works (at least on a low quality 3DLUT)! Would still be interested in a file format specification for madVR 3DLUTs while I have this code paged in

Its documented here:
https://sourceforge.net/projects/thr3dlut/files/doc/

[Manni]

I re-installed Crimson (16.1.1 hotfix) last night to do some testing with the 3DClub DisplayPort 1.2 to HDMI 2.0 adapter on my HD7870, and unfortunately it's a no go as the levels are wrong and there is no way to set the pixel format, so I don't recommend it unless you only use MadVR. I had the wrong levels in PDVD and was unable to get them right.

However, I took the opportunity to do more tests with Crimson and the native HDMI 1.4 out, and I found two things:

1) I tested 3D and while it works fine in 1080p, when the desktop is set to 2160p MadVR doesn't set the desktop to 1080p when playing 3D, so I only get a crash from MPC-BE. My understanding was that it was supposed to switch to 1080p automatically, then back to 2160p after playback?

2) I found that if I set the pixel format to YCB 4:4:4 in Crimson I get the correct levels for MadVR (set to 0-255) and with PowerDVD, both in 2D and 3D. I checked the chroma multiburst test, and I get very good results there too. I couldn't see any obvious downside from a PQ point of view, so I was wondering if any of you could think of one? I haven't tried an Autocal with Calman or the JVC Software yet in that setting, but I don't see why it wouldn't work. The only potential downside would be an unnecessary colourspace conversion, but as the JVC converts to YCB even when fed RGB in order to process color/tint before reconverting to RGB internally, I think I end up with the same number of conversions. MadVR's RGB is converted to YCB 4:4:4 by the GPU, then YCB into the PJ is converted to RGB internally. When I set the GPU to RGB, it's converted to YCB byt the PJ, then reconverted to RGB. So in both cases, we have three conversions after the YCB 4:2:0 from the bluray to RGB for MadVR internal processing.
3) I'm also thinking forward and believe that HDR content will have to be sent in YCB when we have HDR support in the GPU/Driver/API and it's sent to the HDR display, either by MadVr when/if it supports HDR, or by PowerDVD as soon as their UHD Bluray version is out.

So can anyone think of any downside in using YCB 4:4:4 to a JVC projector set to HDMI standard (16-235) anyway. Otherwise I think I might stick to it, as it will allow me to keep Crimson and use the 3D support in MadVR/LAV.

Cheers!

[madshi]

Originally Posted by KoD

It happens with 1080p videos, displayed at less than 1920 x 1080 resolution, as long as the resolution of the vobsub or the sup is also large (1920 x 1080). The subtitle renderer is xysubfilter 3.1.0.746 (the latest, as far as I know). Happens both in 32 and 64 bit.

Here's another sample [38 Mb], a mux directly from a BluRay, with only the video and the PGS subs.

Thanks. Reset my XySubFilter settings to default, now I can reproduce it.

Originally Posted by baii

A little comparison for those interested in hardware, I recently acquired 980ti and a full unlocked fury(think furyx). They fury(x) is slightly faster(about 1ms render time, avg ~14 vs ~15ms) for one of my 1080i60 clip upscale to 4k with following setting.

Interesting that they're so close!

Originally Posted by Kevin Gilmore

Please advise: wondering about cpu-load<PCI-e bus load from the renderer through MadVR

or weather any A-situational processing occurs that you/we know of where lots of CPU-GPU copy-back or
CPU post processing occurs.. that may or may not load the pci-bus moreso than otherwise.

Could be caused by doing copyback (using any hardware assisted video decoding other than native DXVA), or maybe by using a shared GPU where rendering is performed on one GPU and output by another (e.g. NVidia Optimus or similar).

Originally Posted by kasper93

When NNEDI3 quadruple is in use, OSD reports that luma is downscale with Bicubic150 AR instead of SSIM AR. Any reason for that?

Originally Posted by ryrynz

I found when I upgraded to. 9 after. 8 it defaulted to bicubic when I had SSIM detailed set in .8 what with it being deprecated and all. I actually tested quadrupling with SSIM the night before and the osd was correct for me so perhaps just change your Luma Scaler to something that's not SSIM and back again and that might fix it.

You may have to reselect SSIM when updating your madVR version because the SSIM internal names changed when I removed the "detailed" vs "clean" option. If that is not the problem, then could you please show a screenshot with the Ctrl+J OSD turned on?

Originally Posted by raymondjpg

Is there a way to change the active device in madVR settings?

The active device is the monitor the madVR video window is placed on. You can change it by moving the media player window to another monitor. Other than that I don't understand why it would make sense to try to use a different device (= monitor) than the one the window is rendered on?

Originally Posted by Telion

http://hugefiles.net/4eeyrwm5p5xz
I've found out that if I stop the playback before closing the file or opening another, the leak is never there (and it is so in both v0.90.4 and v0.90.9 builds). But if I do this while playing or on pause - sometimes it leaks, sometimes not. It seems to be completely random - I haven't been able to identify any pattern or dependencies. Also, the "stop" case doesn't depend on the presence of "DontRenderAfterStop" file.
So I created two debug logs - one with stop&close case (so no leak) and the other with immediate close after playback started (and with a leak of course). I have a rather slow rig, so maybe that matters and it is some sort of race condition. But definitely there were no such problem with v0.90.3 and before.

That file host sucks big time. I've tried to download the file 3 times. It claims the file was downloaded in some fancy browser page, but it's nowhere on my PC. Found no way to actually successfully download your file.

Could you olease use mediafire or another decent file host? Thanks.

[madshi]

Originally Posted by Manni

1) I tested 3D and while it works fine in 1080p, when the desktop is set to 2160p MadVR doesn't set the desktop to 1080p when playing 3D, so I only get a crash from MPC-BE. My understanding was that it was supposed to switch to 1080p automatically, then back to 2160p after playback?

Yes, it's supposed to do that. Which madVR version did you test with? I did a related change in v0.90.9, I think. Does it work in v0.90.8?

[k4rma]

Originally Posted by madshi

Is this a new problem with 0.90.9? If so, please try to find out which exact madVR version introduced it. You can download old versions from here:

http://www.videohelp.com/software/ma...sions#download

I cant seem to be able to take a screenshot that matches what im seeing, but i can tell now that the stuttering is because the rendering stats hit the roof (ie. 60-80ms) when in full screen. However my CPU doesnt appear to be taxed that much...strange.

I did try to look using some older versions but the problems keeps reoccurring, so perhaps its not MadVR. Can only think its either Intel drivers (im using HD5000), LAV 0.67 or MPC-HC (1.7.10).

[madshi]

Originally Posted by k4rma

I cant seem to be able to take a screenshot that matches what im seeing, but i can tell now that the stuttering is because the rendering stats hit the roof (ie. 60-80ms) when in full screen. However my CPU doesnt appear to be taxed that much...strange.

I did try to look using some older versions but the problems keeps reoccurring, so perhaps its not MadVR. Can only think its either Intel drivers (im using HD5000), LAV 0.67 or MPC-HC (1.7.10).

Attaching stuff to this forum doesn't work, takes ages to get it approved. Please upload somewhere else.

[Manni]

Originally Posted by madshi

Yes, it's supposed to do that. Which madVR version did you test with? I did a related change in v0.90.9, I think. Does it work in v0.90.8?

I used the latest 0.90.9, but I tried an earlier version with Catalyst last week and it didn't work either, so I waited to be able to test with Crimson before reporting, as Catalyst doesn't work properly with 3D anyway.

Just to be sure, can you tell me which options in MadVR have to be enabled for this automatic switch to happen? I don't use the auto display mode feature of MadVR as it's MyMovies which handles this in my set-up, but my understanding when we last discussed this was that it wasn't necessary.

Here are the options I set: 3D to auto in device property, and enable 3D stereo in rendering / stereo 3D.

I have a separate profile for 3D, which is enabled, so I have specific scaling/rendering etc options for 3D, in case it matters.