madVR - high quality video renderer (GPU assisted)

[seiyafan]

I lowered the queues back to 12/8/8, for rendering if I use anything lower than 12 there is no presentation glitch but present time would increase from 0.7 ms to 18 ms, after a while the present queue cannot fill up in time and would cause frame drop.

[tp4tissue]

Yea, and we don't even KNOW for sure that the tensor core algorithms will make it down to madvr. And even if they do, is it going to be "soon"? Possibly not. I think you could potentially get a year or two before it's even relevant. Unless madshi surprises us.


If you buy the Horse before the cart, By the time the Cart becomes available, The Horse is past its prime, has a limp, and is about to die.

WAIT for the cart, THEN buy the Horse, idealy On -Black Friday- :D

I learned this after getting pulled into the whole DX11 ready GPU debacle.

[SamuriHL]

I didn't buy any horse before the cart. I had a 1060 when I upgraded my machine and it wasn't powerful enough for my use case. I upgraded to the 2070 and absolutely love the card. (I do game occasionally when time permits, as well). And now I can crank the options I want to crank to get the picture quality I'm looking for. If tensor core support comes to madvr while I own this card, that's a bonus. :) If it doesn't, I have the raw power I need for the quality I'm looking for.

[ryrynz]

You NEED the horse before the cart when it comes to any hardware implementation through software, that's how the process works and how it needs to work.
It's a lot easier to work with hardware that actually exists.

Funny how when RTX came out people many were mocking the ray tracing and now after a few good implementations of the it and some incredible examples on youtube it's now obviously "the future"
Some people just have zero foresight and no belief in the possibility of anything not only shown the benefits of but described in detail by professionals and it's astounding to me.

[SamuriHL]

I agree to a point. But nVidia didn't launch it in the best possible light, either. Hardware wise it's fantastic if not a tad pricey. What they needed _AT LAUNCH_ was a killer demo of the tech and they didn't really deliver that aspect. I get it, hardware needs to come first, but, they had the hardware in house. They could have done what console mfg's do and partner with someone, anyone, to have a launch day killer demo. Anyway, we're long past that point, the hardware is solid, we're starting to see what the thing can really do, and I'm absolutely on edge waiting to see what this tech is going to deliver in madshi's capable hands. Tensor core AI algorithms should be pretty fun. BUT, that's making an assumption that isn't a guarantee at all....that we get them in either the free madvr or the pro madvr. So far, that's unknown. Nonetheless, I'm very happy with my RTX card....even as it stands today.

[fourbigkids]

Hi all.

I am running MPC-BE v.1.5.3 with madvr 127.0.0.1 on a Windows 10 HTPC with an Nvidia RTX 2060. The video is fed via HDMI to a pre-pro and then to a Sony TV XBR85X850F. It is also fed via a DsplayPort - HDMI adapter straight to the Display. I have madvr setup to open full screen and to change the refresh rate of the TV to match the video file.

All is working as expected on the HDMI - Pre-pro - display leg. However, with the adapter - display leg, while the desktop of my HTPC is visible, when I play a video file (irrespective of the file type) with MPC-BE, I get audio but no video on the display. Just a blank screen. The DisplayPort-HDMI adapter doesn't seem to be the problem as the same video plays and is visible using PowerDVD and MS Media Player on the adapter-display leg, just not MPC-BE and MadVR.

I have reinstalled both MPC-BE and Madvr and imported the last previously known working settings, but no luck.

Appreciate any pointers.

********* edit: madvr v0.92.17 :-)

***Issue resolved with another active 4K DisplayPort - HDMI adapter. I tried 4 and two worked. Oddly, vlc worked with all 4 adapters.

Cheers,

Allan

[elraffa]

Hi all.



I am running MPC-BE v.1.5.3 with madvr 127.0.0.1 on a Windows 10 HTPC with an Nvidia RTX 2060. The video is fed via HDMI to a pre-pro and then to a Sony TV XBR85X850F. It is also fed via a DsplayPort - HDMI adapter straight to the Display. I have madvr setup to open full screen and to change the refresh rate of the TV to match the video file.



All is working as expected on the HDMI - Pre-pro - display leg. However, with the adapter - display leg, while the desktop of my HTPC is visible, when I play a video file (irrespective of the file type) with MPC-BE, I get audio but no video on the display. Just a blank screen. The DisplayPort-HDMI adapter doesn't seem to be the problem as the same video plays and is visible using PowerDVD and MS Media Player on the adapter-display leg, just not MPC-BE and MadVR.



I have reinstalled both MPC-BE and Madvr and imported the last previously known working settings, but no luck.



Appreciate any pointers.



Cheers,



Allanwhere can I download madvr version 127.0.0.1?

Enviado desde mi Redmi Note 6 Pro mediante Tapatalk

[huhn]

You NEED the horse before the cart when it comes to any hardware implementation through software, that's how the process works and how it needs to work.
It's a lot easier to work with hardware that actually exists.

Funny how when RTX came out people many were mocking the ray tracing and now after a few good implementations of the it and some incredible examples on youtube it's now obviously "the future"
Some people just have zero foresight and no belief in the possibility of anything not only shown the benefits of but described in detail by professionals and it's astounding to me.
even now ray tracing is a joke. except a wonder in optimisation is happening it will stay a joke on all cards that are not 2080 ti or new releases. will it be a default feature sometime in the feature yes there is a high chance for that.
but if you want to use ray tracing on a 2060 get used to 1080p. they charge a huge premium for a feature that is barely used and useless in the near future and AMD just joined the price wagon.

ray tracing cores are not tensor cores just to make that clear.
@elraffa
127.0.01 doesn't exist. it's the ip address that is used to connect to your own PC.

[fourbigkids]

Whoops! That would be madvr v0.92.17. Not whatever the number in the title bar might be. Thanks for picking that up elraffa. :-)

[elraffa]

Whoops! That would be madvr v0.92.17. Not whatever the number in the title bar might be. Thanks for picking that up elraffa. :-)your welcome :-)

Enviado desde mi Redmi Note 6 Pro mediante Tapatalk

[nevcairiel]

but if you want to use ray tracing on a 2060 get used to 1080p.

If you want to game on a higher resolution then 1080p and value quality and performance, then you bought the wrong card in a 2060 anyway, and thats just a fact. :p Thats litereally the mainstream 1080p gaming GPU (and 1080p is also the mainstream resolution, all higher gaming resolutions are a single digit percentage combined on eg. Steam surveys, which for gaming is quite relevant), it'll not run maximum quality at decent framerates on higher resolutions, so bringing Ray Tracing into the mix is just intentional drama (ie. trolling).

On that note, you should checkout the improvements to DLSS they've done for "Control", the quality has drastically increased and is practically a net positive in quality from the additional graphic effects you can turn on if you're otherwise performance limited.

[huhn]

but nvidia sells it as an ray tracing card and this card can easily do high settings at 1440p but ray tracing will half the frame rate. so the question is i'm the troll here or nvidia. there are no easy to render ray tracing games and that's not the point you will even get into FPS problem on quake ray tracing it's simply to expensive for this card it can't even do 1080p60 not even a 2080 ti can do 60 HZ at 1440p.

saying a 2060 is a 1080p card is like saying a 1080 is a 1080p card and the next problem with 1080p is not about 60 hz anymore 144 hz is really cheap these days.
15% of all cards on steam are 1050 and and ~15% are 1060 but the 2060 is the main stream these days?
the 2070 sells better then the 2060.
the number of "new" 1080 and 1070 cards is as high or higher then new RTX cards.

the problem with DLSS it doesn't give that much performance and bilinear/GPU scaling plus nvidia sharpening is considered to be "better" just to be clear i'm not on that boat but it is an alternative and every card can do that with every game no special training required. the number of games where it is clearly better is just to low the card is nearly a year old and this marketing feature has little support.

[nevcairiel]

you will even get into FPS problem on quake ray tracing it's simply to expensive for this card it can't even do 1080p60 not even a 2080 ti can do 60 HZ at 1440p.


Quake RT is not really an actual relevant case, and the age has nothing to do with it. Its the only game thats 100% ray traced, which is obviously going to be far more expensive then only using it for effects that get the biggest benefit from it right now.

Modern Ray Tracing games like Control or Metro: Exodus can achieve 60 fps on 1440p on a 2080 Ti, and as developers learn to use these effects properly and effectively, the performance cost will only reduce.

PS:
You obviously didnt look into the improved DLSS as I suggested, since it did make huge strides beyond the initial version seen months/a year ago.

[MS-DOS]

Ray tracing has nothing to do with MadVR. Create a separate thread and discuss it there.

[huhn]

isn't the point of ray tracing to use 100 % of it for easy implementation. the point of quake here is that quake it self doesn't take any GPU load making it a full ray tracing benchmark and it is very impressive in this game too. while with other games you have to look out to find it and normal lighting in games still looks very good same with minecraft.
of they will have to dial down ray tracing for now because the current cards can do it fast enough.
if it stays hard extra work for game developer it will not get huge a lot of games in the near future.
if you need the most expensive GPU to get 60 HZ 1440p you name the issue here. there is no place for the others cards in ray tracing race.
PS:
You obviously didnt look into the improved DLSS as I suggested, since it did make huge strides beyond the initial version seen months/a year ago.

can't be months: https://www.youtube.com/watch?v=dADD1I1ihSQ
but i'm not on board of the anti DLSS hype train anyway and i disagree that it is even close to dead.
on metro it was disaster at release they fixed that a long long time ago. still the "mass" doesn't seem to like it. nvidia has to make sure it works on release date.

[Asmodian]

You obviously didnt look into the improved DLSS as I suggested, since it did make huge strides beyond the initial version seen months/a year ago.

I was just complaining how bad DLSS in Control looked. Better than Metro Exodus, but still not worth using. :(

I really do not like it, at least on my 55" OLED that I sit pretty close to. Much better to turn off most ray tracing effects and run 4K almost 60. :p

As always, for "future proof" madVR get the best card you can afford. Since Tensor cores come with them by default once you get to a high enough price point I just think of them as a bonus. Buying any computer hardware with only the future in mind is always a bad idea, buy what you need now or wait until you know what you will really need.

[KoKlusz]

On that note, you should checkout the improvements to DLSS they've done for "Control", the quality has drastically increased and is practically a net positive in quality from the additional graphic effects you can turn on if you're otherwise performance limited.
Weird thing about DLSS in Control is that Nvidia ditched tensor cores in favor of more traditional temporal accumulation, which at one hand improved quality and performance, but on the other reconstruction falls apart as soon as you start moving (it's especially noticeable if you disable motion blur). For me, the most appealing thing about DLSS was the fact it completely eliminated temporal artifact's, but seeing that NV seemed to give up on using neural network for reconstruction already, makes me wonder if those tensor cores are even worth anything.
If you want to game on a higher resolution then 1080p and value quality and performance, then you bought the wrong card in a 2060 anyway, and thats just a fact. :p .
I would argue that 2060 is fine for non-RTX rendering for 1440p or even higher with right compromises. The problem is it's now has a really bad value. I used to argue that it was pretty good card for it's price, but right now that completely changed after RX 5700 and 2060 Super released.

[tp4tissue]

Hi guys , which C++ runtime does madvr require. I'm getting a new error i've never seen before.

https://imgur.com/kOHyORS

New laptop, I opened a movie, and it played for a little bit, but then I closed the movie. And when I tried watching it again, this happened.

[huhn]

just install them all.

BTW. as far as i know madVR doesn't use Cpp but what was it delphi?

[tp4tissue]

just install them all.

BTW. as far as i know madVR doesn't use Cpp but what was it delphi?

I have no idea... New laptop comes with preinstalled stuff. IDK.

If I click ignore twice at that menu, the playback will start.. LOL.

But what's it saying is the issue ? I know it's madvr related, because if I switch to EVR no errors.

[ryrynz]

But what's it saying is the issue ?

install this (https://github.com/abbodi1406/vcredist/releases), if still have the error after, uninstall everything c++ related in Programs and Features and install again.

[nevcairiel]

Thats not a C++ runtime missing error anyway, the error is in the intel graphics driver. Recommend updating that directly from Intel.

[Asmodian]

I have no idea... New laptop comes with preinstalled stuff. IDK.

Do you have an Error Diffusion dithering option enabled? They require Direct Compute. I have never needed to install any pre reqs for madVR, even on new Dell laptops from work. :confused:

Your error looks like a driver crash, not part of madVR. I very much doubt it is missing or damaged runtimes used by madVR, but it might be something used by the GPU driver. You could try turning off shader caching in the GPU drivers too.. given the path name.

[Aleksoid1978]

It's a debug message from Intel drivers :)

[tp4tissue]

install this (https://github.com/abbodi1406/vcredist/releases), if still have the error after, uninstall everything c++ related in Programs and Features and install again.

Thats not a C++ runtime missing error anyway, the error is in the intel graphics driver. Recommend updating that directly from Intel.

Do you have an Error Diffusion dithering option enabled? They require Direct Compute. I have never needed to install any pre reqs for madVR, even on new Dell laptops from work. :confused:

Your error looks like a driver crash, not part of madVR. I very much doubt it is missing or damaged runtimes used by madVR, but it might be something used by the GPU driver. You could try turning off shader caching in the GPU drivers too.. given the path name.

It's a debug message from Intel drivers :)



Supr Thx guyz, all fixxed, uninstalled and reinstalled latest intel Gfx drivers.

why Dell d00 dis'.. terrible outta dabox Xperience.

Thermal throttling, wrong screen color temperature, driver problems, bloatware crashing, Dell advertisement software informing me how poor I am , and telling me I couldn't afford their more expensive product.. :scared:

[LigH]

:thanks:
Thank you for sharing your valuable experience! ... in all contained topics :sly:

[Siso]

Does anyone have weird issue with madvr in potplayer? I recall a user reported issues a couple of weeks ago, the issue I'm having is randomly delayed 2 frames. So I had to switch to mpc-be again.

[seiyafan]

I lowered the queues back to 12/8/8, for rendering if I use anything lower than 12 there is no presentation glitch but present time would increase from 0.7 ms to 18 ms, after a while the present queue cannot fill up in time and would cause frame drop.

I returned the 5700 and got a 1660 Ti. With the same settings rendering time is very close to 5700 but the present time is now only 0.1ms, there is no more presentation glitch.

[Megalith]

How does madVR's 1080p > 4K upscaling compare to a legitimate 4K release? I'm starting to suspect I wasted my time with these enormous files...

[SamuriHL]

Upscaled 1080p -> 2160p does not have HDR. So, native UHD is going to, by nature, almost always look better than even an upscaled 1080p. Having said that, depending on what settings you use, e.g. NGU sharp High or Very High for luma upscaling, it looks absolutely fantastic. Still, by and by, I prefer the native UHD when it's available.

[Stereodude]

Still, by and by, I prefer the native UHD when it's available.
Like Oblivion? :sly:

[SamuriHL]

Haven't seen that one.

[mclingo]

Hi guys, just wondering, at what point is a PCI express 2.0 slot going to be a bottleneck for MADVR with a new PCI express 4.0 card like a 5700xt, if at all?

[huhn]

it's currently not working properly.

PCIe 3.0 can barely do UHD60 and PCIe 4.0 interface is only double the speed so it shouldn't be able to do FUHD60.

so PCIe 2.0 is already a bottleneck that's where native hardware decoding comes into the mix and that doesn't care even PCIe 1.0 is a total over kill for that.

[mclingo]

so PCI express bandwidth is currently irrelevant, it makes no different whether you put a 4.0 PCI express card in 2.0, 3.0 or 4.0 slot, for MADVR?

[Klaus1189]

it's currently not working properly.

PCIe 3.0 can barely do UHD60 and PCIe 4.0 interface is only double the speed so it shouldn't be able to do FUHD60.

so PCIe 2.0 is already a bottleneck that's where native hardware decoding comes into the mix and that doesn't care even PCIe 1.0 is a total over kill for that.

I don't understand why it PCIe 3.0 or PCIe 2.0 are a bottleneck for that pupose.
HDMI 2.1 is capable of 48 GBit/s which is about 6 GByte/s -> sufficient for 8K 60fps but with DSC Video compression
PCIe 2.0 is about 8 GByte/s for 16 Lanes
PCIe 3.0 is about 15,x GByte/s for 16 Lanes -> sufficient for uncompressed 8K 60fps 10 bit 4:4:4 (11,2 GByte/s needed)
PCIe 4.0 is about 31,x GByte/s for 16 Lanes -> sufficient for uncompressed 8K 60fps 10 bit 4:4:4 (11,2 GByte/s needed)

But only if you have a Mainboard which has full 16 Lanes on the PCIe slot.
Some Mainboards use full size slot but only half of the pins is physically there. This can be an issue.
Here is a calculator of uncompressed videostream sizes per second: https://www.extron.de/product/videotools.aspx

Note:
Bit vs. Byte
Number of PCIe Lanes: 1 / 4 / 8 / 16

[huhn]

so PCI express bandwidth is currently irrelevant, it makes no different whether you put a 4.0 PCI express card in 2.0, 3.0 or 4.0 slot, for MADVR?

as long as native hardware decoding is used.
subtitles use a lot too.

I don't understand why it PCIe 3.0 or PCIe 2.0 are a bottleneck for that pupose.

because they are in real life tests. back in the days madshi created a tool to measure "copyback" speed on GPU. we got ~120 FPS with PCIe 3.0 with 1080p. the infamous AMD nnedi3 copyback bug (and they where still massively faster).
there is still the issue on how the video is encoded/stored:
https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats

The 16-bit representations described here use little-endian WORD values for each channel. The 10-bit formats also use 16 bits for each channel, with the lowest 6 bits set to zero, as shown in the following diagram.

and well subtitles i have no clue if they are compressed or not.
UHD 60 is currently as far as you can go with copyback. maybe it is the latency we don't know going over UHD 60 make huge problem.
But only if you have a Mainboard which has full 16 Lanes on the PCIe slot.
Some Mainboards use full size slot but only half of the pins is physically there. This can be an issue.

the 16x bus is directly connected to the CPU for a long time now.
the PCIe 16x slot with mechanical 8x and usually electrical 4x are usually connected to the chipset. you have to do a really good job in finding a new proper board that doesn't have a direct CPU 16x slot for many years now.

[el Filou]

I'm convinced the real bottleneck is in the system platform (RAM) and/or the software, not the bus interface itself which is way faster than any uncompressed video you could send over it. Of course it's no help if you're stuck with PCIe 2.0 (and old system platform), but I'd be very interested in a benchmark of copyback with a 5700 on X470 and X570, to see if the bottleneck is the bus or the system RAM. Has anyone done that?

I hope madshi will implement black bar detection and film mode on the GPU now that Envy is coming out, that would help it immensely not having to do copyback on there (there would still be the problem of deinterlacing with D3D11 native on the PC version, and software support like that JRiver UHD menu thing).

Edit: that talk about future-proofing and "going over UHD60" presumes that 8K is going to become common anytime soon. I don't see that happening in the near future, not on the PC anyway. I'd watch an UHD Blu-ray over a bit-starved 8K online stream.

[huhn]

i switch from PCIe 3.0 ddr3 1600 mhz to PCIe 4.0 ddr4 3200 mhz and i got worse results for copyback.

[el Filou]

That is really disappointing. :confused:

[Klaus1189]

i switch from PCIe 3.0 ddr3 1600 mhz to PCIe 4.0 ddr4 3200 mhz and i got worse results for copyback.

What DDR3 and DDR4 RAM modules did you compare?
Exact model number for tech specs. I want to compare on paper.
What mainboard did you use for each system?

[huhn]

wow wow chill.
it's an freaking zen 2 with broken navi card and the test was with agesa 1.0.0.3a. come back in a couple of month when they ironed the bugs out.

i mean the newest driver update manage to stop BSOD when playing hardware decoded videos and the driver is now only dying they are making huge steps forward!

i don't even have the card build in anymore.

[nevcairiel]

The problem with CopyBack is also that it has to copy the image twice, once from the GPU to the system, and then back from the system to the GPU. On some GPUs, the download step is also rather slow (AMD used to historically have trouble there, no clue how recent hardware changed). But it can also stress the system RAM, especially on dual-channel memory mainstream systems.

I did a quick test on my system (which isn't a good example, since it has fast quad-channel RAM and everything else high-end as well, but regardless) with a random 4K 10-bit test clip I had at hand:
With DXVAChecker and naive EVR playback testing

DXVA2-Native, ~380 FPS
DXVA2-CopyBack, ~104 FPS
Software Decoding, ~196 FPS

The native test is close to what the hardware decoder can achieve, it was at ~95% usage most of the time. CopyBack definitely takes quite a toll on 4K. Interestingly on 1080p the overhead from CopyBack is generally extremely minimal.
Interesting is also software decoding. Granted you need a CPU that can actually decode this fast, and it was decode-limited at this point, but uploading the image alone is not bottlenecking the decoder yet.

Since I could upload at 196 fps at least (and probably more), I did another test, DXVA2-CopyBack, Decode only - which means it'll only download the image from the GPU, but not re-upload it. That yielded ~232 FPS.
Clearly the doubled use from download and upload creates the real bottleneck ... somewhere. Its not entirely clear where the real bottleneck is. Clearly the software upload path in the renderer can handle more then ~104 FPS. Clearly the download path in LAV Video can as well. PCIe is full-duplex, which means it should be capable of sending and receiving at the same time. System Memory is more complex in regards to that... but my quad-channel memory should have plenty bandwidth to accomodate this here.

What I don't know is if the EVR used in this example uses a different thread for uploading the video, or if its on the same thread as LAV Video uses to deliver the image - which might explain why its slowing down so much, since it does two things on the same thread. madVR, at least, uses a seperate thread for uploading, so it wouldn't be affected by that.

[Crimson Wolf]

Like Oblivion? :sly:

Just FYI: Oblivion is fake 4k (mastered in 2K or 1080p then upscaled) (https://4kmedia.org/real-or-fake-4k/4/)

[huhn]

we can keep going on with copyback issues here:
https://forum.doom9.org/showthread.php?t=176642

[seiyafan]

In the hardware device option for copyback, is there any difference between the GPU card and the iGPU in the Intel processor?

[littleD]

The problem with CopyBack is also that it has to copy the image twice, once from the GPU to the system, and then back from the system to the GPU. On some GPUs, the download step is also rather slow (AMD used to historically have trouble there, no clue how recent hardware changed). But it can also stress the system RAM, especially on dual-channel memory mainstream systems.

I did a quick test on my system (which isn't a good example, since it has fast quad-channel RAM and everything else high-end as well, but regardless) with a random 4K 10-bit test clip I had at hand:
With DXVAChecker and naive EVR playback testing

DXVA2-Native, ~380 FPS
DXVA2-CopyBack, ~104 FPS
Software Decoding, ~196 FPS

The native test is close to what the hardware decoder can achieve, it was at ~95% usage most of the time. CopyBack definitely takes quite a toll on 4K. Interestingly on 1080p the overhead from CopyBack is generally extremely minimal.
Interesting is also software decoding. Granted you need a CPU that can actually decode this fast, and it was decode-limited at this point, but uploading the image alone is not bottlenecking the decoder yet.

Since I could upload at 196 fps at least (and probably more), I did another test, DXVA2-CopyBack, Decode only - which means it'll only download the image from the GPU, but not re-upload it. That yielded ~232 FPS.
Clearly the doubled use from download and upload creates the real bottleneck ... somewhere. Its not entirely clear where the real bottleneck is. Clearly the software upload path in the renderer can handle more then ~104 FPS. Clearly the download path in LAV Video can as well. PCIe is full-duplex, which means it should be capable of sending and receiving at the same time. System Memory is more complex in regards to that... but my quad-channel memory should have plenty bandwidth to accomodate this here.

What I don't know is if the EVR used in this example uses a different thread for uploading the video, or if its on the same thread as LAV Video uses to deliver the image - which might explain why its slowing down so much, since it does two things on the same thread. madVR, at least, uses a seperate thread for uploading, so it wouldn't be affected by that.Not sure if i add something new, but computers since like forever were designed with the data flow in one direction. To make pc games reach high fps rates, it means the pc system should have fast cpu>gpu memory transfer. Backward direction was always few times slower because there were no applications needing that. That fact starts matter in GPGPU times, even before Opencl, because general processing need to reupload data many times. Since then - the path gpu>cpu have been steadily improved but still is slower.
Ram speed has no much impact in cpu>gpu transfer since thats native for pc architecture. Upload to gpu, decode (texture/image) and render is typical for pc game. Quad channel might have advantage in software decoding whith many cpu<>ram memory transfers. So ram speed might matter in software decoding.
In Your example, alone downloading image (decode only) looks fast anyhow. Reuploading (playback) is contrary to PC design, even with fast RAM, slow speed may be hardware or software limitation (dxva design?). There are some small tools to benchmark PCIE gpu>cpu transfer.

[TechnoPeasant]

Has the latest Windows 10 update screwed the levels for anyone? I haven't touched my madVR setup in ages, the only thing that's changed is Windows 10, and now my levels are screwed and everything looks washed out.

[el Filou]

In the hardware device option for copyback, is there any difference between the GPU card and the iGPU in the Intel processor?It depends on the video decode capabilities of your iGPU and dGPU. Use the one with the broadest format support. For example you could have a modern Intel CPU that could decode HEVC and VP9 but an older - even if powerful for madVR - dGPU that cannot, or the opposite.
You can check the capabilities of each with this tool: http://bluesky23.yukishigure.com/en/DXVAChecker.html

If both GPUs have the same format support, it's best to do some playback tests comparing the CPU/GPU load with each.

[cca310]

Anybody interested in an XySubFilter bugfix for external SRT subtitles with italic text in them?

http://madshi.net/XySubFilter746SrtFix.zip

This is not tested well, and it's a totally unofficial build, so please use on your own risk. If you do decide to give it a try, let me know if the "move subtitles" option now works properly in all situations.

I've asked cyberbeing to create a new official XySubFilter build with my fix, but it'd be great if some users would test it first.

I am not too familiar with github, but would this mean that your fix was added to the official xysubfilter? https://github.com/Cyberbeing/xy-VSFilter/commit/d07c343dede075f652703dbc5fc58c698c7df4af
It says that is fixed external subtitles, but not embedded?

I still have embedded subtitles covering my video with XySubFilter 3.1.0.752. If I install your "XySubFilter746SrtFix", embedded subtitles with italics are below the video correctly.

I believe the issue is not fixed for embedded subtitles.