madVR - high quality video renderer (GPU assisted)

[Perenista]

The setting you need to change would be in MPC Video Decoder, or perhaps change the video decoder to LAV Video.If I try to use that one this is what I am seeing:

https://i.postimg.cc/hjN3RPhY/NEW.png

The "hardware decoder to use" is currently configured as DXVA2-native in LAV VIDEO.

Note that changing to anything else such as DXVA2-copy-back or D3D-11 will not fix the slowdown.

I was using LAV Splitter Source after was told this would re-enable the multi-angle selection which is absent in madVR.

MPC-Video Decoder default settings are presented this way:

https://i.postimg.cc/Xvp8N6M6/DEF.png

Disabling these options will not make any difference. Which one I should leave unchecked? If the answer is "don't change anything", then it's not there I should look for answers.

[Asmodian]

You need to enable it for HEVC, that file is HEVC. Check the HEVC box under Codecs for HW.

Your active decoder is "avcodec". This is the software decoder, so hardware decoding (DXVA2) is not working if you see that.

[Perenista]

You need to enable it for HEVC, that file is HEVC. Check the HEVC box under Codecs for HW.

Your active decoder is "avcodec". This is the software decoder, so hardware decoding (DXVA2) is not working if you see that.Even if I do this here:

https://i.postimg.cc/KYGCNnGf/XX1.png

This is what I get:

https://i.postimg.cc/65CSxHTz/XXXXXXXXXXXX1.png

Same dropped frames, same slowdown. And as you can see enabling HEVC in the "Codecs for HW" from LAV VIDEO still shows ACTIVE DECODER: AVCODEC.

Enabling anything from "codecs for HW" won't change anything here.

Note: Enhanced Video Renderer plays that same file 100% FINE. Using MPC-BE. So this is madVR's fault.

[huhn]

what version of lav video is that?

because you only activated HEVC not HEVC 10 bit even through your screen clears says that the file is p010 so 10 bit.
and what hardware is even used?

do i have to ask if you changed the other settings there too?

[ryrynz]

Enabling anything from "codecs for HW" won't change anything here.

Note: Enhanced Video Renderer plays that same file 100% FINE. Using MPC-BE. So this is madVR's fault.

OK for starters you say "enabling anything" yet show a picture without everything enabled saying "even if I enable these" so that's ambiguous as to what you actually tried.

And secondly blaming madvr for it dropping frames due to either poor setup or because of limited hardware resources is not "madVR's fault" it's yours.

[Perenista]

OK for starters you say "enabling anything" yet show a picture without everything enabled saying "even if I enable these" so that's ambiguous as to what you actually tried.

And secondly blaming madvr for it dropping frames due to either poor setup or because of limited hardware resources is not "madVR's fault" it's yours.LAV Video Decoder shows the following options:

Hardware acceleration:

Hardware decoder to use:
* None
* DXVA2 (copy-back)
* DXVA2 Native ---------------- OK
* D3D11
* NVIDIA CUVID (old)
* Intel QuickSync (old)

Resolutions: SD - HD - UHD (4K)

Codecs for HW:
* H.264
* HEVC
* VC-1
* MPEG-2
* HEVC10
* VP9
* AV1
* H.264 MVC

What I am telling you is that I tried enabling all those codecs for HW and also all "resolutions" (HD, SD, UHD), and under "Hardware decoder" I already tried switching between DXVA2 (copy-back), DXVA2 (native), etc.

None of this matters because ALL those options won't fix my particular issue. I didn't get the point of enabling HEVC10 and leaving all the rest disabled.

I get that madVR has been optimized for quality, so using a shitty setup won't cut it.

If you don't mind my opinion, I think there should be an option under this project to prevent people like me from stop using madVR until a new hardware is purchased and resorting to EVR custom presenter or players like VLC to be able to watch these more demanding videos.

Even PowerDVD's last version can play this same file fine.

I was instructed here to try changing a few of madVR settings such as:

RENDERING - WINDOWED MODE - PRESENT SEVERAL FRAMES IN ADVANCE

Only changing a few of those madVR internal settings isn't going to reduce the frame dropping substantially.

You see, I had problems with two specific videos, one that is a lot less demanding in terms of CPU/GPU yet had interlaced stuff (read my previous posts) and another which is in 4K resolution and happens to have multiple audio/subtitle tracks (don't know if this matters in terms of slowing things down), however it's in theory not so heavy as to cause a severe slowdown in my current build which is lacking a GPU.

When I used a 1080p@60 Hz monitor with my old R7 265 GPU I was able to play anything, even 60 GB UHD/4K lossless rips... which are of course unplayable now using shitty onboard video from a 2013 CPU = I7 4770.

This 9 GB file isn't that demanding. What is demanding a lot of resources is madVR.

This is the point I am trying to make: if madVR were a game, let's say GTA 6, it would be forcing me to get a hardware that could play it at the max settings, because it was meant to be played like that, not only at 720/1080p using integrated graphics. (note: you can play a few modern games using iGPU from recent processors and under the lowest resolutions/settings possible, provided you have at least 16 GB of RAM - there are Youtube videos showing those. In such cases I believe both CPU/GPU are almost at 100%).

Meaning at the same time madVR can play at lower settings it is also enforcing that your hardware can run at better ones.

All other forms of running such game (which I mentioned: EVR and other players) would allow me to run whatever I want even in such build.

madVR on the other hand is not. I get the argument it has been optimized for quality, while others for speed. No problem with that. Still, how about leaving inside it a way to at least let builds like mine run, for the time being?

Not sure if this defeats the whole idea...

[el Filou]

The GPU is an Intel HD 4600 which doesn't support any HEVC decoding so indeed enabling DXVA native won't help.

I agree that madVR has been developed with at least discrete GPUs in mind.
It can work with more powerful iGPUs (and with higher memory bandwidth) which have started to appear in recent products but that low-end Intel from 8 years ago won't cut it for 4K I think.

I can play Blu-ray remuxes no problem with my 4690K with a discrete Radeon 7870, so I don't think the i7-4770 here is the problem, it's the memory bandwidth: the file is decoded in software, so in system memory, then it's copied to a GPU texture to be processed by madVR, so again in system memory.
I know that some apps can use something called "zero copy" with iGPUs (Chrome does if I'm not mistaken) to directly render in GPU textures, but obviously madVR doesn't as it's decoder-independent.

Running at 1080p fullscreen with "scale chroma separately" would allow madVR to only do luma downscaling and avoid chroma upscaling, but apparently you've already tried that.

I don't see a solution. (Edit: maybe use DXVA scaling, as Intel GPUs have dedicated logic blocks for that IIRC, but madVR can do that only when using DXVA native decoding, so no luck. I would try to use another renderer like MPC VR)

[Perenista]

I don't see a solution.A GPU makes all the difference, I thought this was the case only for games. Not really. If you try to play a more complex video with a higher resolution and bigger size then you will be out of luck with madVR. And not just those, as evidence by that interlaced one.

This 2013 CPU is not that bad:

https://www.reddit.com/r/intel/comments/6szevd/is_i7_4770_still_worth_getting/

But it's not enough to run such content. EVR custom from MPC-BE will play fine, or these other players, and you can clearly see how any video runs smoothly because seeking is also fast, I can easily rewind/fast forward in MPC-BE. When I tried playing a bigger (70 GB in fact) version of this file (note the pastebin one was a reencode I did with DVDFab, to reduce its size to 9 GB and maintain the same 4K resolution):

https://pastebin.com/wSinm4d2

I noticed seeking froze at some random moments and the video continued, still the image remained static (note: this didn't happen with the 9 GB version). Oddly such video is running from beginning to end with no apparent slowdowns but if you decide to rewind/fast forward video playback will be halted until you close the player and restart.

Any GPU would probably fix all these problems for good, even my old (now dead) R7 265, which has been released at the same time as the CPU. And I think I made things worse by installing a 4K monitor in this setup, not sure if this made the whole system slower.

I am not suggesting madVR to be downgraded, only to have an internal option to run in such unfavorable condition, instead of enabling/disabling lots of things and realizing it didn't make a difference. I know this may reduce the video quality, however CPU/GPU usage should be half of what I am seeing now, so for the time being this "workaround" wouldn't cause this massive frame dropping, since it would mimic what these other players/EVR custom are doing.

If implementing this would be a nightmare/not feasible, I can't tell. Any GPU is expensive these days and at least until now I am seeing lots of them out of stock. When I tried buying the same R7 265 (used) I gave up because if was not worth it (and don't buy used hardware unless you want trouble). The old one died all of sudden (never had a problem before) with the former motherboard, and there was no way of fixing it (they both fried).

It's not unusual to find computer users not having a GPU these days/relying on the integrated graphics.

[DTL]

Can madVR perform scaling in linear domain instead of OETF'ed ? Same question about 4:2:0 storage and distribution format upscaling to 4:4:4 colorspace for displaying. If not - can it be added ?

[Balling]

Such problems are usually fixed by using mpv's nvdec decoder instead of using d3d11va. For example, I cannot play 8K HLG Olympics or BT.2020 (thus SDR) transfers on d3d11va, but can simply with nvdec that even includes color managment and convertion to linear since the file is bt2020-cl, not bt.2020-ncl. I have a 2080 Ti though.

d3d11va includes proccesorblt stuff to fix shimmering artifacts of 8k content on 4k, that is the main problem there imho.

[Balling]

Can madVR perform scaling in linear domain instead of OETF'ed ? Same question about 4:2:0 storage and distribution format upscaling to 4:4:4 colorspace for displaying. If not - can it be added ?

You mean to support Superwite and superblack and out-of-gamut xvYCC stuff? That requires NV30, afaik.

The problem is for 4:2:0 there is not metadata for chroma siting in HDMI.

[DTL]

"You mean to support Superwite and superblack and out-of-gamut xvYCC stuff? "

I mean: If we have source image encoding data prepared (conditioned) for digital operation in linear domain (sometime called light) so if we perform scaling in storage and distribution OETF'ed domain we got more distortions (like aliasing).
Currently (may be not in latest version) I see only option 'scale in sigmodized light' but I think it is not mean performing backward EOTF+OOTF to Linear before scaling. Also if currently output to display of madVR is also in OETF'ed domain so scaler engine must perform backward transform into target OETF (and may be OOTF) before feeding to display.

Google found the thread - https://forum.doom9.org/showthread.php?t=170769 but how to enable 'linear light scaling' . But I see option 'scale in linear light' available only for downscaling but for display we typically need upscaling. I see 'linear light' option only in 'upscaling refinement' settings group and available only in 'Super Res' option activated. So for simple Lanczos linear upscaling it is not available ?

Here is 2 different .mp4 testfiles of hyperbolic zoneplate:
https://cloud.mail.ru/public/2QN4/KvbKH7Ei4 - assumed to be conditioned in distributed rec.709 OETFed form
https://cloud.mail.ru/public/h1kR/o56qALaK5 - linearly calculated and being converted to rec.709 OETF.

I tried to use Lanczos taps=4 upscale for 2x upscale for displaying. As most close to sinc-based resamplers of available. But no combinations of options can give close to real linear light resize (simulated in Avisynth and jpsdr's TF conversion plugin). It looks for upscale with Lanczos (and may be all other kernels in 'image upscaling' group) the real linear light upscaling path is not available.

Test results:
madVR Lanczos taps 4 for moving picture dataset conditioned in OETFed domain:
https://i1.imageban.ru/out/2021/09/04/a3fde527a0c5926f59a6490ba8909ce3.png

madVR Lanczos taps 4 for moving picture dataset conditioned in linear domain and distributed in standard OETFed domain (transfer=bt.709 signaled in h.264 bitstream), SuperRes=on to enable set linear light=on
https://i7.imageban.ru/out/2021/09/04/2028ece1161641a3d380a183078657f8.png

Avisynth simulations:
correct scaling after converting back to linear
https://i1.imageban.ru/out/2021/09/04/3390b166ee5cf6b4d8560d4e8c4b72e7.png
shows very few aliasing even with low taps=4.

worse scaling - do not transform back to linear
https://i3.imageban.ru/out/2021/09/04/0f6deff3f6247031c2d9544e6f15294e.png
shows more aliasing and comparable with madVR output.

I think the same sad is also about upscaling of color difference UV from 4:2:0 to 4:4:4 but it may be later after resolving issue with scaling at least luma Y in linear light.

My 'poor-people' hardware display device Philips 40put6400 of about mid-201x also do not scales in linear and looks like scale in OETFed domain but I not sure if it correct. Unfortunately there is too low standards in the industry about this and no correct (any) signaling metadata available about what is correct domain for scaling process.

The scaling in linear was about simple in the good old time of SDTV/HDTV with close and simple enough OETF/EOTF but starts to be much more awful in the HDR systems with new and may be not easy to transform to linear and back transfer functions. But lets start at least with 'classic digital' 601/709 TFs and enabling processing path for enabling scale in linear for classic linear resamplers like Lanczos.

And also it is good to have option for selecting different scalers for H and V processing. Because most of typical broadcast and pro footages have target H scaler sinc-based and for interlaced footage target V scaler I think in most/many times is not sinc-based (may be something like Gauss or any other designed for processing pooly conditioned datasets).

[huhn]

linear light upscaling has been removed many years ago.

it was adding massive amounts of ringing while been sharper and the jinc(like lanczos sinc based) implementation was really unhappy with it anyway if i remember correctly.

sigmoidak light is still present(mix of gamma and LL).
this version is the last with LL madVR v0.89.19
https://www.videohelp.com/download/madVR08919.zip

scaler where LL is applicable are underwhelming anyway.

[DTL]

I see madshi's post at avsforum about internal processing in linear domain. So it was idea it is very easy to do scaling also where data present in linear domain. And have simple switch to users untill industry still do not set signaling metadata for auto-selection.

" jinc(like lanczos sinc based)"

jinc is completely different 2D-type scaler and expecting industry will set target interpolator for moving pictures data to jinc-type is very few probability. I think we just only at the very beginning of hard way to put a standard at least for nowdays common 1D+1D scalers. 2D image processing looks light years away from today. It is sad to see how after about 1/3 of a century of digital moving pictures and TV industry still do not have clear definition of interpolation procedures. Also no industry standards for spectrum shaping of moving pictures data so many real footages may greatly suffer from ringing being processed with natural for DSP sinc interpolator.

"scaler where LL is applicable are underwhelming anyway."

The use of LL is not interconnected with exact scaler but with source conditioning of footage. I think any typical footage may be conditioned either in (compressed) OETFed domain or in (uncompressed) LL-domain. But for correct interpolation before displaying the correct domain must be known (or may be selected automatically at some algorithm at display device side in worse case) or should be signaled in metadata and display's scaler need only select 1 of 2 posible points of procesing - in the input distribution OETFed (compressed) domain or in LL (decompressed) domain. The required OOTF correction must be applied after LL-scaling in case of LL-domain scaling.
At old times the OETF for distribution was designed as pre-correction of CRT EOTF but later was used as a form of bitspeed compression (about 1.2..1.5:1 for SDR and about 3:1 for HDR).

"this version is the last with LL madVR v0.89.19
https://www.videohelp.com/download/madVR08919.zip"

Thank you - it really works close as it should with conditioned source in linear domain:
https://i5.imageban.ru/out/2021/09/04/562c07453f476129f7593c8978204d86.png
May be small aliasing still left because of difference in EOTF treating - I read madshi uses gamma-2.2 and bt.709 close to gamma-2.4.
It is sad why this useful method was disabled/removed in newer versions. I ask to bring it back may be as 3rd option near sigmodial light. Because sigmodial light can not help here.
Now we have some practical renderer to test workflows with conditioning in LL (though it may be only supports SDR 601/709/2020 LL and no HDR HLG/PQ ?).

[chros]

Can you test NGU Sharp at high strength paired with NGU Sharp Low for chroma with that pattern?

[ryrynz]

Hope we don't get stuck on test pattern results again.. [emoji23]

[huhn]

it's just bad test pattern are worthless for such tests.

and gamma and BT 709 well i have bad news for you.
mathematically it's 2.22 but here is the point what did the studio use is it bt 1886 so 2.4 ? 2.2? no one knows for sure.

NGU and maybe all cleaver upscaler are not huge fans of linear running lines maybe it will survive this case.
but we compare it to lanczos even in the best case it is still lanczos... just move on.

[Thunderbolt8]

Ive got a question regarding power management stuff. On my laptop (optimus), in case of some movies I get dropped frames and empty queues in case of some (more demanding) movies, but it is all fine once I plug in the power chord. Is anyone able to list all the settings in question in windows 10 which could potentially be responsible for this problem? I have ticked some boxes already, but I guess theres more than just one place to look for in this case.

[ryrynz]

Your first port of call would be to just have your PC not change Windows power profiles when on the battery, that should take care of it.

[DTL]

Can you test NGU Sharp at high strength paired with NGU Sharp Low for chroma with that pattern?

NGU sharp (flom later version after 0.8) looks like also as 'typical' scaler gives less aliasing with source conditioned in OETFed domain. And looks like can not be switched for processing in linear domain.

These test movies designed as black and white because color in digital video (moving pictures) with typical storage and distribution 4:2:0 member of family still not very good. It may going from old days of BT.601 with very limited processing power but looks like still exist in latest HDR BT.2100. The source of issue is creation of sub-sampled color-difference data for 4:2:0 and 4:2:2 members of family from OETFed maxtixed R'G'B' data. And more correct way is creation from sub-sampled linear RGB data. But it require more matrixes and scalers at encoder side and significally more at decoder side. Also for best results the subsampled Y' also need to be stored and distributed to decoder. Like 4:2:0:1 for Y':U:V:Y'/2 (or 4:1:2:0 for Y':Y'/2:U:V) way and it slightly decreases 2:1 compression ratio of 4:2:0 member in compare with 4:4:4. That issue with color encoding and decoding is much harder to resolve completely but some workarounds at the decoder side and some improuvements for encoder also available. It is next question to madVR for implementing - the 4:2:0 color decoder with linear UV scaling. Currently as workaround it require restoration of half-size Y' data from the only provided to decoder full-size Y' data and this process is not very accurate. Later processing is easy enough - half-size Y'UV dematrix to half-size R'G'B' - EOTF to half-size linear RGB - 2x upscale to full-size half-band RGB - OETF to to full-size half-band R'G'B' - matrix to to full-size half-band Y'UV - combining of full-size Y' and restored full-size half-band UV to final output dematrix to R'G'B'.

Hope we don't get stuck on test pattern results again.. [emoji23]

Yes - the many (or most) of moving pictures footages are not conditioned against Gibbs ringing for sinc-based resamplers even in H-direction so universal playback software need to have lots of different scalers to use with different footages.

"mathematically it's 2.22 but here is the point what did the studio use is it bt 1886 so 2.4 ? 2.2? no one knows for sure."

Yes - different sources may use a bit different OETF for HDTV (bt.709 signaled transfer) but it still better to use attempt to linear data before scaling if it was initially conditioned in linear domain. The harmonic distortions of 1/2.0 or 1/2.4 gamma-processing is still much more significant in compare with back EOTF with a small enough error of gamma between 2.0 or 2.4.

" it is still lanczos..."

It is from linear-processing family. Completely content-independent and so can not provide content-dependent distortions. Yes - the linear processing workflow of moving picture data gives less sharp images in compare with non-linear. Or require more spatial samples to look as sharp (like 4K linear vs FullHD non-linear). But as advantage it is free from content-dependent distortions and distortions from non-linear processing (and bad/absent conditioning of sources against Gibbs ringing). Fortunately industry quickly moves to high samples count in the frame data so 8K linear processed and good conditioned frames may look from far enough comparable with 4K or FullHD non-linearly processed. Because the visual sharpness depends on viewing angle also.
Lanczos is over-weighted sinc so less sharp in compare with sinc with equal number of taps. Though as advantage it do not have edge-calculation distiortion of very hard truncated full-sinc to a taps < about 70. So it is another suggestion to madVR - add modified sinc resize a bit sharper in compare with Lanczos weighting with same number of taps and processing performance - like trapezoidal weighted sinc (see SincLin2ResizeMT in jpsdr's plugin at github as example). Pure box-weighted sinc with very few taps will expose egde-bug looking like 'ghosting'. Sharp transients duplicating at 'taps' distance with small amplitude 'ghosts'. Even with perfectly conditioned source.

[Thunderbolt8]

Your first port of call would be to just have your PC not change Windows power profiles when on the battery, that should take care of it.I have only 1 single profile in my list.

[ryrynz]

I have only 1 single profile in my list.If that's the same profile that's active when on AC and on battery then it's likely your graphics card, check your clocks to determine what's being throttled.

[el Filou]

If you try to play a more complex video with a higher resolution and bigger size then you will be out of luck with madVR. And not just those, as evidence by that interlaced one.We already explained what was happening with that interlaced one, and we gave other possible solutions (like how to get/force film mode) but you did not give feedback on them.I am not suggesting madVR to be downgraded, only to have an internal option to run in such unfavorable condition [...] this "workaround" wouldn't cause this massive frame dropping, since it would mimic what these other players/EVR custom are doing.As others already explained, EVR is built for speed over quality. It may simply not be possible for madVR to lower its quality enough so it works with this particular case of 4K video on an older iGPU. It would, in fact, need to be 'degraded' to EVR level. Why not just use EVR (or MPC VR, or whatever) instead of madVR then?It's not unusual to find computer users not having a GPU these days/relying on the integrated graphics.The problem is the HD 4600 is old and therefore doesn't have HEVC hardware decode, and the system itself is old too so has less memory bandwidth (DDR3) for the iGPU.
A current iGPU even Intel (anything from Kaby Lake) would be able to decode that 4K video in DXVA native and at the same time would have much bigger memory bandwidth, so would not suffer like that.

[clsid]

One of his screenshots showed bicubic scaling. Changing that to bilinear should reduce render time.

A "trick" to help with the bandwidth situation is to disable 10/16-bit output formats in LAV Video Decoder settings. Then it will convert 10-bit stuff to 8-bit. That costs a little CPU usage, but reduces the required bandwidth by half.

When using MPC-HC and EVR, this is actually already done automatically internally (for other reasons).

[DMU]

Then it will convert 10-bit stuff to 8-bit. That costs a little CPU usage, but reduces the required bandwidth by half.


Could you explain in more detail why an 8-bit signal in bandwidth is 2 times less than a 10-bit signal?

[nevcairiel]

Could you explain in more detail why an 8-bit signal in bandwidth is 2 times less than a 10-bit signal?

Because 8 is 2 less then 10? :D

Now for those that aren't convinced yet..
Your computer isn't particularly good at accessing individual bits from memory, thats why we have the byte - 8 bits - which can be accessed much more efficiently.

When every component of every pixel is 8 bits, thats all just fine, but what if we move to 10-bits? The answer is that we just use 2 bytes (16-bit) and leave the unused bits zero. This uses more memory, but it avoids any weird problems from needing to address individual bits, and thus is faster to process.

And thus, 10-bit uses twice as much memory as 8-bit, because its really 16-bit with 6 empty bits.

There are "packed" formats that pack like 3x10-bit into a 32-bit value, either with 2 unused bits or 2 alpha bits, to reduce the overhead, but converting the image into such a format would cost quite a bunch of CPU, and graphics cards might not understand it, and it needs to be unpacked again.
This packing is typically done with the same pixel. So if you had a 4:4:4 format, you could pack all 3 components into one 32-bit value. With subsampling, this gets more complicated, because chroma values are shared by multiple pixel. Hence why its rather uncommon to have "packed" formats for 4:2:0 chroma.

[SirSwede]

In terms of buying a new machine, what is the least I would need in it - in terms of hardware - for it to be able to nice enough upscale 540p and 720p to an LG 65CX OLED?

[ryrynz]

In terms of buying a new machine, what is the least I would need in it - in terms of hardware?

I think it would be a good idea to specify what settings and noise levels you're wanting to achieve because you could go with GeForce 1060 levels of performance as a good starting point and go anywhere up to 3080 Ti.

[tp4tissue]

Hope we don't get stuck on test pattern results again.. [emoji23]

It's worse, it's about wasting more gpu cycles on chroma. :(

[LenniePaz]

I've been having a weird problem for awhile now, and I can't figure it out. Every so often, I'll play a movie in Kodi DSPlayer, and the render times will be over 100. If I reboot Kodi and MadVR, everything goes back to normal for a few weeks. It's happened on pretty much every version of MadVR.

Sent from my SM-N975U using Tapatalk

[ryrynz]

I've been having a weird problem for awhile now

Same reply to this as the other guy, look at your clocks.
Something's being throttled.

[LenniePaz]

Same reply to this as the other guy, look at your clocks.
Something's being throttled.Clocks? I don't understand.

Sent from my SM-N975U using Tapatalk

[ryrynz]

Clocks? I don't understand.


Clock speeds. If you don't know much about computers and want to save some time you might wish to use another video renderer instead. I don't think you'll have a quick answer to this one. Might want to start with trying a different media player? When it does happen compare clock speeds and processor time to figure out what's causing the slow down.. It's not MadVR, your system has something reducing it's performance.

[LenniePaz]

It's a dedicated HTPC, and I literally have 2 programs installed on it, Kodi and MadVR. I just think it's weird that it's not a constant issue. If something was throttling the HTPC, I would think it would happen all the time. I'll run a clock speed test next time I'm in my theater room, and see if anything sticks out.

Sent from my SM-N975U using Tapatalk

[LenniePaz]

Here's the clock speed results. https://uploads.tapatalk-cdn.com/20210912/829c0b0f83babb4982fbb3e85fdd2e13.jpg

Sent from my SM-N975U using Tapatalk

[tp4tissue]

It's a dedicated HTPC, and I literally have 2 programs installed on it, Kodi and MadVR. I just think it's weird that it's not a constant issue. If something was throttling the HTPC, I would think it would happen all the time. I'll run a clock speed test next time I'm in my theater room, and see if anything sticks out.



What you can try is, go in bios, set it to fixed cpu frequency. Turn off the lower power states.

Then in Windows , set it to high performance mode. fixed 100% cpu

The cpu cycling up and down (doesn't always), but on some motherboards it introduces stutter, latency.

[huhn]

ignore the CPU for now it unlikely madVR get's into problems randomly thanks to CPU clocks.

for GPU clock use a tool like GPU-Z if the current number are correct than i have to assume your GPU is dead. these are idle number they tell us nothing.

this is sadly a relative complicated topic.

make a screen of the OSD next time this problem happen.
after that you can also check GPU-Z be sure to check the temp there too just another screen of the sensors page.

[LenniePaz]

ignore the CPU for now it unlikely madVR get's into problems randomly thanks to CPU clocks.



for GPU clock use a tool like GPU-Z if the current number are correct than i have to assume your GPU is dead. these are idle number they tell us nothing.



this is sadly a relative complicated topic.



make a screen of the OSD next time this problem happen.

after that you can also check GPU-Z be sure to check the temp there too just another screen of the sensors page.Are you saying my GPU looks dead based on the screenshot I posted using GPU-Z? I can't see how the GPU is dead. MadVR works 99.9% of the time, and if I do get some dropped frames, a reboot of Kodi and MadVR, fixes it. It won't happen again for a month or two. There's no way my CPU is running the high settings I have, so the GPU has to be working.

Sent from my SM-N975U using Tapatalk

[huhn]

the screen does not show it.

if your GPU could only reach 300 than yes there is something very wrong with it just ignore it reading GPU clocks is complicated because they can reduce them even lower than that a normal high load clock is between 1600-2000 mhz.
as said use GPU-Z while madVR is running or this is just a waste of time.

you are not using GPU-Z that's hardware monitor or similar.

[clsid]

It could just be a driver bug. Close Kodi and press Win+Ctrl+Shift+B to restart the graphics driver.

[x7007]

Does anyone have an idea if HDMI High speed cables and Ultra High speed cables are the same as long it's HDMI 2.1? or there are differences between the HDMI 2.1. for example if we compare a cable from aliexpress to club3d

HDMI 2.1 4K120Hz/8K60Hz UHD/3D Club3D Ultra High Speed CAC-1374

HDMI-compatible cable 4K 60HZ/ 120HZ HDTV High Speed 8K 60 HZ/120hz UHD HDR 48Gbps cable Ycbcr4:4:4 Converter for PS4 Projectors

and another cable from aliexpress
Vention 8K HDMI 2.1 Cable 120Hz 48Gbps Fiber Optic HDMI Cable Ultra High Speed HDR eARC for HD TV Box Projector PS4 Cable HDMI


and another cable

https://www.uptab.com/certified-ultra-high-speed-hdmi-cable-2-1-8k-hdr-earc-dolby-vision-dolby-atmos-3ft/
Compatibility:

8K 60Hz/30Hz, 4K 120Hz/60Hz/30Hz, 1440p, 1080p, 1080i, 720p, 480p, and 480i Resolutions
TrueHD Dolby™ 7.1 DTS-HD DTS-X Master Audio and Dolby™ Atmos
Transfer Rates of Up to 48 Gbps
Enhanced Audio Return Channel (eARC)
HDR - HDR10 and Dolby Vision (HDR)
Variable Refresh Rate (VRR)
Quick Frame Transport QFT)
Quick Media Switching (QMS)
Auto Low Latency Mode (ALLM)
Supports 3D Content
HDCP 2.2 Compliant
Length 3 Feet /1 Meter
Quality Construction:

100% pure oxygen-free bare copper wiring
Full Metal Shielding within connectors for durability and Interference protection
Shielding throughout Cable
HDMI connectors are 24K Gold plated

I am asking because of this

rtings.com/images/reviews/tv/articles/misc/misc-formatdataratetable-large.jpg
(rtings.com/images/reviews/tv/articles/misc/misc-formatdataratetable-large.jpg)
and because if some of the technologies are standard on all 2.1 cables or it's just for the Ultra? because it has the lowest EMI. should it be better to go for best quality on Ultra or the cable I have is the same just without a certificate? the cable works perfectly fine with all the options without any issue. but I wonder if the Ultra has the Lowest EMI because that's what I really need.

also, this 2 options

Quick Frame Transport QFT)
Quick Media Switching (QMS)

[el Filou]

All HDMI Ultra High Speed cables support the same features, the only important thing is that they're Ultra High Speed certified (i.e. bandwidth tested), ignore the rest as all the features are device-dependent (with the older High Speed cables there were ones with and without the Ethernet channel, but Ultra High Speed cables all have it).
Edit: to be clearer, there is no such thing officially as an "HDMI 2.1 cable", there are only Normal, High Speed, and Ultra High Speed certified cables, with the Normal and High Speed having with Ethernet and without Ethernet variants. The only features that are dependent on cable type are video definitions (because they're bandwidth dependent) and Ethernet channel.

@LenniePaz: check if you haven't enabled the "limit background fps" feature in NVIDA settings. If that's enabled and the media player loses focus for some reason, render times in madVR can go higher than the frame time.
This happened to me but IIRC it was more ~50 ms than 100 because the lower limit is 20 fps.

[LenniePaz]

the screen does not show it.



if your GPU could only reach 300 than yes there is something very wrong with it just ignore it reading GPU clocks is complicated because they can reduce them even lower than that a normal high load clock is between 1600-2000 mhz.

as said use GPU-Z while madVR is running or this is just a waste of time.



you are not using GPU-Z that's hardware monitor or similar.My bad, I downloaded CPU-Z, and I thought it was GPU-Z.

Sent from my SM-N975U using Tapatalk

[Perenista]

As others already explained, EVR is built for speed over quality. It may simply not be possible for madVR to lower its quality enough so it works with this particular case of 4K video on an older iGPU. It would, in fact, need to be 'degraded' to EVR level.Uh, no. The two things at least on the surface seem unrelated. Sorry if this is a noob comment, it's just that this is the first time I am reading someone confusing the two.

If it's not feasible, a nightmare for a programmer (such as adding support for dead versions, like Windows XP in 2021) it's one thing, but it's not a novel concept as you seem to suggest. I can give you a few examples:

- Let's say you have a PlayStation 1 emulator that has video plugins and can play Crash Bandicoot in 4K resolution. That's all fine and dandy... if your current build can play it.

If it's not powerful enough then you'll be forced to turn OFF certain plugins/settings and lower the resolution.

That's also how a few modern games were able to be played with the iGPU (in modern processors), they had to use the lowest resolution possible from the list. And in such scenarios you needed 16 GB of RAM at least.

A few more situations:

- Windows 10 or any other OS being able to play 16 bit games; should you buy old hardware just for that? Because the 64-bit system can't play?

I know there are valid and complex technical reasons (I once saw a video explaining that, if I am not mistaken from "Linus Tech Tips", can't find anymore) why Windows has dropped support even for 32 bit, but my point is that it makes no sense for you to act like the Youtuber "LGR" (look into this channel) and start buying decades-old stuff to play everything, when you can get DOSBox to do for you, albeit not perfectly.

My first reaction if I were using such emulator and didn't have an option to lower its quality would be to call the developers incompetent. The same for games which would insist in only using GPUs and not allowing under any condition the use of integrated graphics.

When you are playing GTA V in 720p resolution and turning off all graphic possibilities which would enhance the game... are you removing the ability to play at 4K resolution as well?

NO. So in this case no one would swallow this excuse.

You then argued this:

**************
Why not just use EVR (or MPC VR, or whatever) instead of madVR then?
**************

I tried EVR, and it played fine. Except when I also played this kind of file:

>>>>>>>>>
- MKV/lossless rip from UHD disc (+- 60 GB filesize)
>>>>>>>>>

In theory the heaviest I could try in this system. In this case this is too much for EVR, too. So there was some stuttering. Also EVR isn't too far from madVR in terms of CPU / memory / GPU usage in my CPU@i7 4770 using the onboard video (16 GB of RAM).

But... here's where things get interesting:

The VLC player, whatever they are doing internally, can play ANY KIND OF FILE without any frame dropping or stuttering in this build. That means the problem is not with the MPC-BE player, it's the decoders, LAV included.

You said VLC is playing everything in worse quality. I don't doubt that for a second, however the end result IS acceptable, at least for now.

It's not like VLC has degraded so much that makes you want to puke.

What I noticed after hitting control + alt + del was that VLC is the only one (compared to EVR/madVR) demanding less CPU/memory/GPU. It's using so little that makes me wonder what kind of magic is there.

That's what I really don't get it, whatever they seem to be using/doing, it's working for people like me. While all these decoders have been built with modern systems in mind (and I am OK with that), or old ones like this CPU... provided they use ANY VIDEO CARD.

If I put this one, which I was using until it died:
https://www.techpowerup.com/gpu-specs/radeon-r7-265.c2558

Any video would play fine using any decoder or player. This is a 2014 video card, coupled with a 2013 CPU. The reason for the stuttering you explained below:

**************************
The problem is the HD 4600 is old and therefore doesn't have HEVC hardware decode, and the system itself is old too so has less memory bandwidth (DDR3) for the iGPU.
**************************

I get that, because when the "GPU" icon isn't showed in MPC-BE that means the video is using HEVC and thus it's slower also for seeking (fast-forwarding). In layman terms, the CPU is crap because HEVC has been (slowly) introduced many years AFTER its release. Moreover, UHD/4K discs were first released in 2016.

What is annoying, to sum things up, is the fact I have to use VLC, while I prefer MPC-BE with my eyes closed. So my problem right now is that I haven't found (at least NOT YET) a decoder that mimics exactly VLC behavior and consequently stop draining so much resources from this build. This is a temporary workaround because I intend to buy new hardware very soon.

[LenniePaz]

Here's a screenshot of GPU-Z while a 4k HDR movie is playing using MadVR. I think my card is fine, from what I can tell. https://uploads.tapatalk-cdn.com/20210912/5275529b4d1feaff4c6341140c68a2f6.jpg

Sent from my SM-N975U using Tapatalk

[clsid]

File size is not what makes a file "heavy" to play. Large filesize just means it has high bitrate. But that only has a minimal effect on decoding performance. And zero effect on video renderer performance. The only thing that matters for the video renderer is resolution/bitdepth/hdr. That file is probably HDR, which means extra work needs to be done in the renderer (HDR tonemapping) if your system does not support HDR passthough (which it probably doesn't).

VLC has pretty much same decoder as MPC-BE and LAV. So that is not the issue. VLC does not do HDR tonemapping afaik, so that is why it performs better. Colors will look dull as well...

In MPC-BE do this:
1) Disable 10-bit/16-bit output in its video decoder settings. This saves bandwidth when copying data to GPU.
2) Install MPC Video Renderer and disable HDR conversion in its settings. I don't think EVR-CP in MPE-BE has an option to disable HDR tonemapping.

[LenniePaz]

Deleted

[x7007]

can anyone tell me why I have this issue with some movies, it only happens on specific SDR movies. it doesn't happen on HDR HVEC. it only started since AMD driver above 21.5.2, which means at 21.6.x and above. it works fine with the windows 10 Movies & Tv app. it only happens when I use Potplayer+Lavfilters+madvr. it starts doing an issue when seeking and after couple of seconds it stops and it plays fine. I am lost, because I need the new drivers but this weird-ass issue happens......

https://vimeo.com/603686736 (https://vimeo.com/603686736)

[huhn]

Here's a screenshot of GPU-Z while a 4k HDR movie is playing using MadVR. I think my card is fine, from what I can tell.

your GPU is fine. this was just said to make clear how wrong/useless the present information are if it would be take at face value.
a screen from the madVR OSD would now tell everything that we need to know.

BTW. this looks like copy back decoder your PCIe bandwidth get's pretty hammered.
bus interface on the graphic card tap in GPU-z use the "?" -> start render test to get proper readings for a couple of set more is not needed.
@Perenista
these are not computer games you are far off.

[Asmodian]

So my problem right now is that I haven't found (at least NOT YET) a decoder that mimics exactly VLC behavior and consequently stop draining so much resources from this build.

Did you try disabling all the 10+ bit color spaces, as suggested, in LAV?