View Full Version : madVR - high quality video renderer (GPU assisted)
garson
13th December 2015, 03:51
I would use 23 Hz, 50 Hz, and 59 Hz. Set smooth motion to "only if there would be motion judder without it..."
Or nothing and use smooth motion most of the time.
Personally I like using smooth motion and not using display modes, it avoids the flicker when changing display modes. If you notice smooth motion's blurring display mode changing is required but if you don't smooth motion is even better because it perfectly matches timings so you never get dropped or repeated frames during normal playback. When using standard refresh rates you need to use Reclock or similar or you still get drops/repeats. Or you can use custom refresh rates and tune the refresh rate to match the source frame rates almost exactly, this is somewhat complicated and requires trial and error.
Smooth motion is so easy. ;)
Thanks once again Asmodian.
I was using Smooth motions since it was introduced (before it I had issues on my 60Hz only monitor). Never noticed anything bad about it.
THEAST
13th December 2015, 04:47
So, after more testing, it seems crossfire does not actually work in MPC and does not help accelerating madVR's computations even if it is forcibly enabled using profiles but for some reason, even when crossfire is forcibly disabled for MPC/madVR, during video playback, the second GPU sometimes randomly switches to 3D clocks (but doesn't stay at that clock all the time, even if I am using 256 Neurons in which case my first GPU cannot keep up and heavily drops frames) and the crash I am experiencing can definitely be resolved by disabling crossfire.
Disabling ULPS does not help either (I thought maybe the second GPU goes to sleep when I pause and when I unpause, crashes madVR when trying to wake up again).
At this point in time it seems the only solution is to disable crossfire globally and enable it only when I want to play games. Fortunately this can be done without having to restart the OS. Unfortunately, with crossfire disabled, the second GPU never sleeps and stays at idle clocks which results in ~25 watts of extra power usage (yes, it matters for a student living in a foreign country).
I might give MPC 32-bit + madVR 32-bit a try later.
Asmodian
13th December 2015, 05:04
As huhn said in the previous page, no it still doesn't work (I think you just missed it :))
Oops, you are right. :o
Thanks.
So, after more testing, it seems crossfire does not actually work in MPC and does not help accelerating madVR's computations even if it is forcibly enabled using profiles but for some reason, even when crossfire is forcibly disabled for MPC/madVR, during video playback, the second GPU sometimes randomly switches to 3D clocks (but doesn't stay at that clock all the time, even if I am using 256 Neurons in which case my first GPU cannot keep up and heavily drops frames) and the crash I am experiencing can definitely be resolved by disabling crossfire.
Disabling ULPS does not help either (I thought maybe the second GPU goes to sleep when I pause and when I unpause, crashes madVR when trying to wake up again).
At this point in time it seems the only solution is to disable crossfire globally and enable it only when I want to play games. Fortunately this can be done without having to restart the OS. Unfortunately, with crossfire disabled, the second GPU never sleeps and stays at idle clocks which results in ~25 watts of extra power usage (yes, it matters for a student living in a foreign country).
I might give MPC 32-bit + madVR 32-bit a try later.
This is exactly how SLI doesn't work with madVR as well. madVR does not support dual GPUs at all and enabling SLI or crossfire only hurts performance, at best.
Aktan
13th December 2015, 05:17
can someone with an AMD card and crimson driver test deinterlacing?
in my test it looks like this driver uses NN bob or something terrible like this...
I gave up trying to find the registry to enable it and went back to 15.7.1, lol
baii
13th December 2015, 06:46
If anyone is interested, here is my experience for 1080 60i content double to 4k using nnedi on the r9 290/290x and gtx980
win 10 stock drivers
there are 2 types of 1080i content, encoded broadcast and bluray(BR)
broadcast tend to have some period that require "burst" performance, where BR is rather constant.
setting is to use nnedi 16 + super res or nnedi32 while toning down non essentials (bicubic chroma, 3dlut on, banding on low/mid, order dithering, uncheck all trade performance)
struggle = drop fame/low queue/broader-line rendering time
r9 290 stock(16 +sr)
struggle with either type
r9 290 overclock 11xx(16 +sr)
good enough for BR, struggle at some scene for broadcast, at 1200, it start overcome those scene, but not all card can get there HOT HOT HOT
r9 290x mild overclock (16+sr)
this was some time ago, but I remember both type run fine, with some real buggy scene in broadcast require higher overlock
GTX 980 mild overclock (16+sr)
playback BR fine, struggle at some scene, overall is close to 290 experience, cannot overcome those buggy scene even at 1500
GTX 980 mild overclock (32)
seem to be enough for either type.
I did not really test just 32 on the 290, will have a check now and put it up.
edit: 290 mild overlock will handle either type fine on just nnedi32.
har3inger
13th December 2015, 07:54
I have a question about the OSD/madvr scaling behavior:
Whenever you set up an image upscale that results in a final step of upscale in one dimension but downscale simultaneously in another dimension, lanczos 3 is used for the upscale. Is this because Jinc cannot be used for 1 dimensional upscaling?
http://imgur.com/UtXU4gM
TheElix
13th December 2015, 08:33
Win 10 + Madvr = Crossfire always on Unstable, Madvr always crashes (Piece of Crap)
I suggest you stay away from Windows 10+AMD Crimson Driver combination till they sort this shit out. Yes, this is true for me also. :thanks:
nlnl
13th December 2015, 09:25
Please, help:
Is there any way to force vectoradaptive deinerlacing using new AMD video drivers?
Aktan
13th December 2015, 15:09
Please, help:
Is there any way to force vectoradaptive deinerlacing using new AMD video drivers?
I tried to find the registry to do that, but couldn't and gave up (I didn't try too hard honestly). I just went back to pre Crimson.
XMonarchY
13th December 2015, 16:18
Will DirectX 12 allow the use of multi-GPU in madVR?
huhn
13th December 2015, 18:15
crossfire and sli should already work but they don't.
crossfire and SLI need both the same data in each GPU. the data madVR is using is gigantic so copying the data from one GPU to the other will cost a lot at UHD and this will not change with DX12.
chros
14th December 2015, 01:07
I have Samsung 1080p LED TV, in nvidia control panel I see following screen refresh rates:
23Hz,24Hz, 25Hz Interlaced, 29Hz Interlaced, 30Hz Interlaced, 50Hz, 59Hz, and 60Hz.
What do you suggest to put in Display Modes in madvr settings?
In addition to what Asmodian told you, first check which are closer to your actual clock values,e.g. if something way below it, then disregard it from the list, and you don't need the interlaced ones. In my case: 24p,25p,30p,60p .
If you use these resolutions then turn off smooth motion.
Sorry, I tried only a file which had black borders and this showed me a video "not in fullscreen"; how unlucky!
Then I tried another file but the TV at 720p cut some borders! (in ctrl+j: Movie Resolution=704x576 and Target Rectangle=0,0,1280,720)
Weird thing is that this same file at 1080p shows in ctrl+j: Mov Res=720x576! This is weird, right?
Eerrr ... 720x576 ? That's not 720p! :) Play e.g. a 1280*720 video.
Bandito
14th December 2015, 08:17
Do we need to use uninstall.bat before upgrading to a newer version of madVR?
ryrynz
14th December 2015, 09:41
Do we need to use uninstall.bat before upgrading to a newer version of madVR?
No. If it's already installed all you need to do is copy it over the old files.
BluesFanUK
14th December 2015, 13:01
How does the 4.4.4 test image work?
"If you want to test whether your display supports RGB in 4:2:0, 4:2:2 or 4:4:4, you can use this test image. Make sure you display it with 1:1 pixel mapping, otherwise it won't work."
huhn
14th December 2015, 14:48
open the picture unscale it and look at the numbers you can see.
madshi
14th December 2015, 15:23
I have posted in the LAV thread (http://forum.doom9.org/showthread.php?p=1746830#post1746830) an issue.
With the new madVR0.89.17 play the DVD Aliens(test dvd without the big-vobs (http://forum.videohelp.com/attachments/34047-1444852648/Aliens.7z)) with 4:3 format (menu and video), but it should be 16:9. With EVR it plays fine with 16:9 format.
Thanks, will have a look at this when I find some time.
Hi madshi, you were right, the settings are reset, both the file and the registry entries get deleted, so that's not the reason why the subtitle positioning got fixed. In fact, after doing what you asked me, I can now say with certainty that the subtitle positioning issue happens only when DXVA is used for the scaling of the luma and of the chroma. If DXVA is not used for scaling, then the subtitles are at their proper location in the image. It's as if DXVA is used for scaling, then the subtitles are kept at their original position in the frame in absolute values, which is now somewhere in the middle-left part of the image. And yes, using software decoding + DXVA scaling also shows this issue; it's not related to QuickSync.
In order to reproduce this, could you send me 2 "settings.bin" files (from the madVR folder, or if madVR doesn't have write access to that folder, it's in "HKEY_CURRENT_USER\Software\madshi\madVR\Settings"), one where subtitle positioning works and one where it doesn't work - together with a small sample?
I confirm there is an AR issue for DVD playback myself, with a DVD of my own. But this is not new, it's here since at least 0.89.15 (did not test further back).
The copyright notice is 4:3 and is displayed properly, the studio intro is also 4:3 and no issues, and then the menu appears, which is a static image, and should be displayed as 16:9, but madVR displays it as 4:3. In EVR it's 16:9. No sample from me, but I think there needs to be the two videos included as well to reproduce this, and I don't know how to cut the vobs with the intro videos in.
Sample?
I think preventing this 'edge filling' entirely will require a different algorithm, you'll need to detect edges in a somewhat more intelligent manner. Although, if you don't mind doing an extra processing pass, I did manage to get some nice results if I combine a somewhat modified Bilateral scaler it with a softened SuperRes pass, that's still highly experimental though.
There are too many changes atm in various places in madVR. It's not a good time to add experimental algo tests on top of that. Maybe later. Or when you have something near "final".
Thanks!
Love the thin edges enhancement!:thanks: On anime it makes the outlines look so sharp (I set it to maxium)! Shapen and crispen looks slightly better on very moderate amounts. On anime, 1080p BD encodes it improves more consistently a lot more than on 480p dvd rips from what I tested. Looks like it is more hard to detect edges on low resolution blurry anime. Enhance detail only makes encoding artifacts more visible.
I will use the enchantments and try to tweak when watching anime and try different quality and art animes for some time then post my experience.
Glad to hear you like it!
madshi have you found how fix the stuttering when open a file and go to fullscreen?
no one experienced this? i'm on windows 10, with 2 monitors cloned
You could try using extended instead of cloned. Cloned is difficult for madVR to handle properly. I'm not even sure if madVR is getting the scanline information from the proper monitor in that setup.
Is it me or the latest madvr versions take screenshots in 16-235 instead of 0-255? EVR cp is ok.
That probably greatly depends on the exact settings you're using. There are a million different render paths in madVR, e.g. DXVA scaling on/off etc, downscaling vs. upscaling etc. It's possible that there's a problem in some situations, but I can only fix it if I know your exact settings (e.g. upload "settings.bin"). Also a screenshot of the debug OSD (Ctrl+J) would be useful.
That is another log. Thanks!
https://drive.google.com/file/d/0B7a6LffuxvKUSjJMWU1pQ0QtR3c/view?usp=sharing
Will have to delay this once more. Sorry for taking so long.
I like the fullscreen exclusive seekbar of madvr because it only appears in fullscreen mode, but I also dislike the purple color, the font, and background (ideally I would love to only have the time and the bar without background). My question is, any chance you could add an option in the future to modify this bar via images or something like that?
Maybe in some far away future. Atm adding missing features is much more important than doing some cosmetical eye candy tweaks.
What exactly does enhance detail do?
It increases the contrast between brighter and darker pixels in image areas where there are no edges nearby. Doing so makes image detail stand out more, but it also makes noise, grain and artifacts more visible. So it's probably more useful for clean/good sources.
When using the current madVR on a 4K UHD display with high DPI say 300%, the madVR CTRL J renderer stats are too small to read.
True. Will be fixed in some future version, but not a priority atm.
v0.89.17 according to the settings SS attached
already using Ordered dithering
edit even with latest driver, its the same, cannot use the new algos, gpu usage jumps from 45% up to 100% as soon as i activate any of them. Adaptive Sharpen does not have that problem.
Something is weird there. Which media player are you using? Is it possible that you have different madVR versions installed on your PC? E.g. J.River MC comes with its own madVR version.
Also make sure your GPU settings don't force anisotropic filtering or anti-aliasing. Doing that slows down your GPU without visual benefit in madVR.
Does Madvr now, runs properly on Windows 10 TH2 + AMD GPU?
AFAIK generally yes, as long as you don't have CrossFire, but there's always the odd user who has problems, so there's no guarantee.
I think I have found a bug. I am using the last development version of MPC-HC with the last version of XYSubFilter and the last version of MadVR
The bug happens in MadVR plus XYSubFilter when displaying upscaled VobSub subtitles.
It is an anime episode, 848x480 internal resolution, MPEG4 (H264) video, softcoded VobSub subtitles.
When displaying the vid at 1x resolution the subtitles are correctly displayed at the bottom of the screen.
When the vid is at 50% resolution (in window mode) it doesn't show subtitles at all.
If the vid is upscaled, resolution 2x (window mode) or it is upscaled fullscreen at 1920x1080 the subtitles appear on the left and in the middle of the screen and the subtitles themselves are not upscaled (they appear with the same size than in the resolution 848x480).
MadVR with other subtitles filters (VSFilter and Internal MPCHC filter) display correctly the subtitles upscaled and the bottom of the screen.
The MPCHC Personalized Enhanced Video Renderer with XYSubFilter shows the subtitles correctly too.
You can see screenshots of the vid here with the subtitles. In all these screenshots I am using MPCHC, MadVR and XYSubFilter.
If you need more info, please, tell me.
http://www72.zippyshare.com/v/8bgIjJfZ/file.html
Thanks, I'll have a look at this later, when I find some time.
I have one demand/question:
Many of us are experiencing the same problem: i1d3 (or low end colorimeters) measure our display with a perfect black (accuracy problem) and the result is always a linear gamma from 0 to 100%. The reason is simple: perfect black = infinite contrast ratio but we don't have an oled tv!
As a consequence the blacks are crushed between 0 to approximately 2.5%.
The 17-18 blanking bars are always invisibles after 3dlut creation.
I tried to decrease the gamma @1.25% with videoequalizer v2.06. It works very good (17-18 became visibles again) but it's not compatible with a 3dlut and I can't use this solution.
Do you think it could be possible to create a tool in madvr to modify the gamma curve in realtime after the 3dlut?
The goal is not to make a new gamma curve but only to correct the grayscale with our eyes at very low ire because the i1d3 can't.
A 100 points gamma editor would be really amazing for us. Something like videoequalizer but in madvr, after the 3dlut...
The idea is just to lower the gamma between 0 to 5%. It would be so cool...
Maybe in a future version, but I've many other things to do first.
@madshi
Maybe the settings tool could detect if certain driver functionality (e.g. OpenCL) is missing and notify the user when enabling any options that depend on that functionality?
That might be a good idea if there is only one GPU/monitor. On my PC I have 3 different GPUs installed at the same time, though, so such a check would be pretty useless here.
I'll revisit the whole settings dialog, and its user-friendliness (or lack of) before I reach v1, but atm it's not a priority for me.
Im about to start using madvr with Jriver. Im only needing it for up to 1080p (no higher scaling) and wonder what the best settings I should be using for 1080p. I have a Sony 4k projector yet I don't want to scale to 4k as Im about to sell the projector for a new JVC which is still only 1080p. Im only using the system for ripped BDs on MKV 1:1 copy and a number of video files. Im using the Nvidia GeForce GTX 970 with 4GB ram card.
The new JVCs seem to handle 4K input relatively well, so you *may* benefit from upscaling in madVR, even though the JVC panels are only 1080p. Might at least be worth a try. I'd wait until the JVC has arrived and then simply play with the various options to see which produces the best overall result.
BTW, in case you have a CIH/CIA/CIW setup, madVR can automate all that for you, including setting automatically activating lens memories for cinemascope movies etc...
I'm using D3D11 in windowed fullscreen on Windows 10 for a few days now and so far there hasn't been a problem with playback jittering/tearing.
Either something has been fixed in the current Nvidia drivers (using 359.00) or it was the big Windows 10 November update.
Good to hear!
I get random crashes (very often) when changing from normal to fullscreen, using right click and full screen, or alt+enter. The mpc-hc + madvr crashes, but windows does not crash. I wanted to ask, why this might happen, I will post a log file, if anyone can give me a hang on how to read the log file, or how to generate it.
i get a crash 1 out of every 3 times i launch a video lol and its only when using madvr, funny thing is the crash reports always point to the nvidia driver happens with absolutely every version of the nvidia driver too.
I'll need the crash report. If you don't get a crash report file on your desktop automatically, click on the "show bug report" button, then press Ctrl+C, after that you have the bug report in your clipboard.
madshi, could you add support for either arithmetic operators, or some more measures of throughput in the profile select rules? I ask because I'm pretty sure the amount of time it takes my GPU to apply a particular filter scales linearly with the amount of pixels it has to process. So if I know it can handle a particular profile for 720p30, I'd like to use that as an upper limit, so it uses the same profile up to 1280*720*30 = 27648000 pixels per second.
In a profile select rule, I imagine this would work like (srcWidth * srcHeight * deintFps <= 27648000), or (srcPixels * deintFps <= 27648000), or (srcThroughput <= 27648000), depending on what is available. Adding support for arithmetic operators (or at least multiplication) would generalize the rule selection nicely. In my case, I'd probably combine this with (srcWidth == targetWidth or srcHeight == targetHeight) to know when I only have to worry about chroma scaling.
Makes sense, I'll add it to my to do list.
What might be preventing Fullscreen Exclusive mode from activating on my computer? I have fresh-installed MPC-HC and madVR and it doesn't help.
Windows 10 x64
MPC-HC 1.7.10
madVR 0.89.17
Edit: Madshi, I uploaded log, bug report and DxDiag information in one archive: https://yadi.sk/d/8Y5cl6AAkyp5t Also, in this instance, the player also crashed. As it happens every single time now.
The crash is when doing error diffusion. You could try updating your GPU driver, maybe that helps?
In order to find the failure to enter FSE mode, I'll need another log with the debug OSD (Ctrl+J) active while recording the log, because having the debug OSD active adds some more information to the log that I need in this case.
So i have tested the new xysubfilter and new madvr and i was almost amazed when i saw that in 2.35 movies the subtitlees now can go to the black bars outside the movie window. But it was a matter of minutes until they went back to the front of the movie while playing. Anyone knows how to fix it, i.e making the subtitles stay in the black bars??
There is a known bug that I need to work on. It also requires a new XySubFilter patch, which is why I've not fixed it yet. Will be fixed sooner or later, but might take some time...
Question, if I put "activate deinterlacing" off on MadVr, is the display reponsible for doing this stuff ?
No. An HTPC is not good with outputting interlaced images. You do need to deinterlace on your HTPC.
Hi All, I have a problem that hopefully someone can help me fix. I'm thinking I'm just missing something silly in some settings. I'm using MPC-HC Version 1.7.9 opening an analog capture device. I use ffdshow tryouts to change the output colorspace (to avoid the forced load of MPC-HC internal Deinterlacer filter on 4:2:2 color spaces) and to deinterlace the source. I use madVR Version 0.89.9 as the renderer. The problem I have is if I use ffdshow to double the frame rate for deinterlacing, madVR seems to drop all those extra frames. I see this in stats and it only happens if I double the frame rate. This problem doesn't exist with other renderers like EVR as it is a lot smoother when the frame rate is doubled. I didn't use madVR's own deinterlacing becuase it wasn't deinterlacing well. I'm guessing this is probably due to the fact that the queues are stuck at 0-1 in stats. I'm also guessing this is why madVR keeps dropping frames. The combination of ffdshow deinterlacing and madVR renderer does not have a problem if I use a MPEG2 source instead of an analog capture source probably since the queues can be filled properly then. Does anyone have an idea of what I can do to fix this?
madVR only drops frames if either the GPU is too slow or if the refresh rate it too low. Please make a screenshot of the Ctrl+J madVR menu when you get those frame drops, then maybe we can help.
Generally you should get better quality when letting madVR deinterlace. So it might make sense to try that again and post a screenshot of Ctrl+J with that setup, too.
madshi
14th December 2015, 15:24
my englishe is poor..
madVR v0.89.14---madVR v0.89.17 can not pass through the DVD .ifo file, the AR video stream couldnt be read,the scale of the images is not proportional;if the .vob files are opened directly, it can be recongnised accordingly. this problem would only occur if PAL DVD,NTSC DVD are running and functioning normally。
Can you upload a small sample for me with which I can reproduce this issue?
Does anyone know if you can do a non linier stretch with madvr?
Can you stretch a 16:9 image to scope 2.35 screen. Where the centre is correct shape but the sides slightly stretched to fill the scope ratio?
Do you *REALLY* want this?? I consider non-linear stretch very ugly. It looks ok as long as the camera doesn't move. But for any horizontal pans it looks totally psychadelic to my eyes, because the distortion becomes totally obvious in that situation.
I might add NLS in some far away future version, but it's very low priority because I consider NLS to be bad.
Lately I'm getting regular crashes with madVR. Attached is a crash report.
Don't ever attached anything to this forum, takes ages to get it approved, and sometimes it never gets approved at all. Upload somewhere else, please.
1) Progressive segmented frame, i.e. 25 progressive frames divided/segmented into 50 fields. Meaning the video ought to be weaved into 25p. Does simply "deint=Off" do it? The auto deinterlacing seems to erroneously detect the material as interlaced, as per the container tag.
Most of these are flagged correctly, so most of the time you can either force the deinterlacing completely off, or you can force madVR into film mode, if you want to be extra safe. DXVA deinterlacing (which is the default deinterlacing mode) will usually handle these "correctly", too, meaning you should get proper image quality, but DXVA deint outputs 50 frames instead of 25, so you'll have double the GPU load.
2) Progressive film stored on DVD as interlaced. Simply "deint=Off"?
Same as above for PAL DVDs. NTSC DVDs are quite different, though. Those often produce problems when playing with deinterlacing turned off. Usually forced film mode works best there. There are a couple rare field blended NTSC DVDs out there which require DXVA video mode deinterlacing, but that's really rare.
3) Pal speedup removal of 25p content or film stored as interlaced on DVD (using Reclock). I'm guessing simply "frameRate=24" or "frameRate=23.976" (which one?)
I'm not an expert on how this is done using Reclock so I can't really answer this one.
if I use deint=Film, I get several ms worth of performance hit and the OSD says "IVTC", even though, as far as I know, only the repeat flags of the DVD are being ignored. For example in Handbrake, it's "safe" to simply leave deinterlacing off and set fps to 25 when ripping progressive material DVDs. So I'm just struggling to grasp the real world difference between the tags I mentioned
For most PAL DVDs turning deinterlacing off should be fine, as mentioned above. There are a few odd DVDs out there which have wrong telecine flags. For those you need to use madVR's forced film mode to get proper progressive output.
2) In the case of progressive segmented frame material, two consecutive fields should be merged/weaved (whatever the correct term is) into a progressive frame. Again, when using "deint=Film", the OSD reads "IVTC" and 2:2 cadence - does that mean madVR is properly merging the fields? I would have thought the term "IVTC" isn't applicable in this case. At a quick glance at least, the playback appears identical whether I use deint=Film or frameRate=25 (the content within the container is progressive 25 fps).
My "definition" of IVTC is that madVR converts telecined content (progressive segmented frame material is some sort of telecined content, too) back into progressive. "2:2" means that always 2 consecutive fields are weaved together. *However*, these doesn't have to be top+bottom of the same encoded frame.
- Using madVR's auto detection on any of its settings, progressive segmented frame videos (from a Canon camcorder) are detected as interlaced and are deinterlaced instead of merging the consecutive fields into progressive frames
- Content I've verified as progressive (going frame by frame) sometimes still gets deinterlaced with madVR's auto detection, regardless of the detection setting
madVR doesn't really have a good auto-detection yet. Auto-detection simply means DXVA deinterlacing is used to do the job. DXVA deint internally auto-detects whether the content is video or film and then applies the proper algorithms. However, DXVA deint always outputs double frame rate. So it's all not ideal yet. Tagging is of course a great solution, if you're willing to invest the time.
So, summa summarum, from what I've gathered here, it doesn't hurt anything to always use deint=Film for all progressive PAL content stored in an interlaced-flagged container. I'll be using that then instead of deint=Off.
It shouldn't hurt (other than raising CPU load a bit), but if the content is cleanly stored/encoded, it also doesn't help. It does have the benefit of auto-detecting those rare PAL DVDs which have wrong flags.
How "intelligent" is the processing? Let's say, for example, if I have by accident placed a Blu-Ray rip in a folder that has the deint=Film tag, will madVR "know" what to do with the picture, i.e. to leave the source untouched (because it's native progressive)?
The quality/reliability of madVR's IVTC algorithm is pretty good. It's extremely unlikely that running it on a progressive Blu-Ray rip will do any harm. It should simply detect that the video is a 2:2 cadence and not do anything other than analyzing the frames and detecting/confirming the 2:2 cadence.
It's impossible for me to know for sure whether a source is progressive or not. For all I know, the video stream can claim it's progressive but it would still be telecined. Because of that, if forced film mode is activated, IVTC is always performed, even if the source appears to be progressive. But as mentioned above, due to the very high reliability of the madVR IVTC algorithm it's not a problem if you activate it accidently - other than raising CPU load a bit.
I managed to get a crash report from a crash mpc-hc+madvr that has happened. I thank in advance if someone could explain to me what is the problem.
I uploaded the .txt file to my dropbox account.
https://www.dropbox.com/s/0fxakdk93wepmgd/madVR%20-%20crash%20report.txt?dl=0
Another thing, I always send my crash reports to mpc-hc automatically, but the crashes only happen when using mpc-hc with madvr, so I really hope that someone can offer me a helping hand. Thanks!
The crash occurred when trying to create a D3D11 device. You could updating your GPU driver. Maybe that helps? If not, disabling error diffusion and/or NNEDI3 might be necessary to get rid of the crash.
madVR v0.89.17
[...]
* fixed: repeated frames were reported although smooth motion FRC was on
I checked thoroughly and no, all it did was reporting actual repeated frames which are just omitted from the OSD now. (But from my current understanding this is to be expected with FRC, if frame rate and display rate are essentially identical.)
Hmmmm... Just to clarify: How do you define "repeated frames"? E.g. when playing a 1fps movie on a 60Hz display, madVR is repeating frames all the time, even with smooth motion turned on. Only about 1-2 of those 60 frames will be blended/unique. This is the way smooth motion frc works, so listing such repeated frames in the Ctrl+J menu doesn't make much sense, IMHO.
Or are you saying that every time the old version reported a repeated frame, you got a visual stutter? That would be something completely different, of course!
I'm having strange issue I guess with MadVR.
I have latest MPC-HC 1.7.10, latest MadVR, Lav filders, running on XP. I have a lot of dropped frames on dark/black scenes with not much going on.
So, for example I'm watching Hobbit 720p (8GB mkv file) and everything is pretty much smooth but when movie finishes and Cast of characters scene starts there is a lot of stuttering and dropped frames.
Also, I watched movie Circle (2015) which takes place in dark room with several persons in it, not much going on there, but I got a lot of dropped frames again, movie is barely watchable.
Does anybody now what can be the issue with dark (and slow) scenes?
I can think of 2 possible reasons:
1) Do you have a 3dlut active? If so, some old GPUs may run into problems if certain areas of the 3dlut are accessed. I've had that reported by one user some years ago. But it was a *really* old GPU.
2) Maybe it's some sort of deinterlacing issue? Are you using forced film mode? Film credits are sometimes video mode and require proper deinterlacing.
I suppose with EVR this problem does not occur? Can you post a screenshot of the Ctrl+J debug menu in the moment when those frame drops occur?
madshi
Last example in http://forum.doom9.org/showthread.php?p=1271417#post1271417 contains "srcAR" value name while there's no such value name in syntax description above.
Fixed, thanks.
Could Madvr support MPV (https://mpv.io/installation/)future?
Not sure what you mean with "support"? Are you asking whether a future mpv version might allow to play videos by using madVR? If so, I think that's very unlikely because mpv doesn't use DirectShow and is multi-platform. So the whole architecture is very different from what madVR is built for.
Or are you asking whether I'd be willing to help mpv future development? If that's your question then my answer is a simple no. I don't have the time to help other projects. Furthermore madVR is supported by a lot of different media players. I can't help one of them but not the others. That wouldn't go down well with the other media player devs/companies.
Hey madshi, is there any plans to create a dedicated MadVR Video Player?
Not really. One reason is that I simply don't have the time/resources. Another reason is that doing so would annoy all those media player devs/companies that support madVR. They don't want competition from me.
I spent the past 3-4 hours troubleshooting this issue; I am positive this is an incompatibility between madVR and AMD's crossfire; I don't think using the 32-bit version of madVR/MPC-HC will fix this. Anyway, here is the results of my findings:
- MPC-HC will crash only if I pause it, switch my active window to another application, work for a few minutes, then go back to MPC-HC, go full screen (exclusive or windowed) and resume the video. If I go back to MPC-HC quickly, it doesn't crash.
- If I disable crossfire globally, it will not crash anymore.
- If I enable crossfire globally but only for applications with a profile, it will still crash. Even if I make a profile for mpc-hc64.exe and madHcCtrl.exe and disable crossfire for both, it will still crash. Based on GPU clock and utilization, crossfire is NOT disabled regardless of what I do and both GPUs are used anyway when playing videos.
- If I disable "use Direct3D 11 for presentation" and "use a separate device for presentation", video playback will hang instead of crashing; i.e. MPC works fine but refuses to resume video playback. I can use the same MPC window to re-open the file just fine, in which case it will play properly.
- If I resume playback before going full screen, MPC will not crash but I will get a black screen while audio plays fine. Both GPUs stay at idle clocks in this case.
Needless to say, I can easily blame AMD for this problem but I highly doubt they would even care or try to resolve this issue, no matter how many times I report it.
Any feedback from other people with Crossfire setups is highly appreciated.
P.S. Disabling crossfire in games seems to work correctly. I am going to report this to AMD anyway but I won't expect them to fix it any time soon, if at all.
Yeah, Crossfire has repeatedly being reported as causing problems with madVR, unfortunately.
Win 7 + Madvr = Crossfire always on but stable with no dropped frams
Win 8 + Madvr = Crossfire disabled but you have to use SXBR with no dropped frames (Best Combination)
Win 10 + Madvr = Crossfire always on Unstable, Madvr always crashes (Piece of Crap)
this was running on 2X HD7850 with Latest AMD Crimson Driver (Beta Hotfix.) All are on tested on a clean installed machine.
I suggest you stay away from Windows 10+AMD Crimson Driver combination till they sort this shit out.
Now going back to Windows 8.
Ouch, very sad to hear that.
Madshi could you add supersampling or a way to use image doubling for any videos?
Maybe at some point in the future. For now you can simply upscale a tiny bit (the smallest amount your media player supports, like 0.5% or so).
Whenever you set up an image upscale that results in a final step of upscale in one dimension but downscale simultaneously in another dimension, lanczos 3 is used for the upscale. Is this because Jinc cannot be used for 1 dimensional upscaling?
Exactly.
It's not a limitation of the Jinc algorithm itself, it's just that I haven't implemented Jinc downscaling in madVR (yet?).
Will DirectX 12 allow the use of multi-GPU in madVR?
No.
madshi
14th December 2015, 15:57
madVR v0.89.18 released
http://madshi.net/madVR.zip
* added tone mapping support for HDR content
* added gamut mapping support for HDR BT.2020/DCI-P3 content
* added support for SMPTE 2084 transfer function decoding
* added support for receiving HDR metadata from LAV Video Decoder
* added "maximum display luminance" option to display properties page
* added "HDR" profile variable
* SuperRes now supports being run after every ~2x upscaling step (again)
* improved JVC projector ip control connection reliability
The big keyword for this build is HDR. I suppose many users might not know how it works exactly, so some explanations:
1) First of all, this madVR build does *not* aim to send HDR content untouched to the display, to let a "HDR compatible" display do all the processing. Doing that might be supported by some future version (as an option). But for now what madVR does is convert the HDR content in such a way that it looks well on *any* display (new and old), regardless of whether the display officially supports HDR or not.
2) The key idea of HDR is to increase the peak white luminance, so that we can get brighter highlights, and more texture detail in bright image areas. HDR content uses 10bit (or more) instead of the usual 8bit, and it also uses an improved transfer (gamma) function, which means we also get better shadow detail at the same time.
3) HDR content is encoded using a totally different transfer ("gamma") curve. So playing HDR content with a media player and display which don't understand the new transfer function won't look good/correct. It will look totally washed out.
4) The new transfer function directly maps each pixel to a specific desired luminance value (in "nits" or cd/mē). Possible values are 0 nits up to 10,000 nits. However, videos don't have to use the full 0 - 10,000 range, they often top out at either 4,000 nits or 1,200 nits (from what I've seen).
5) UHD Blu-Ray will usually be encoded in BT.2020 color space, which is extremely wide. However, videos don't have to use the full BT.2020 space, they usually only use DCI-P3, inside of the encoded BT.2020 container.
6) Today's displays (even the best of the best) cannot really properly reproduce HDR content. E.g. many display's don't reach full DCI-P3 colors yet (let alone BT.2020), and no available display today comes even close to be able to output 10,000 nits! Which means that someone somewhere has to convert the HDR content down to something the display can handle. The consumer electronics world plans that the display will do this conversion (only new models, obviously) - and every TV manufacturer will write their own conversion algorithms because there's no standard for that! From what I've been told those conversion algorithms (at least for the first few HDR display generations) are probably not going to be very high quality.
7) madVR is able to compress both the luminance and the colors down to what your display can handle. It uses reasonably high quality algorithms for that. I might find even better algorithms in the future, but for now these algorithms should be a good starting point.
8) UHD Blu-Rays will come with an updated copy protection. So madVR will not be able to play them - unless the copy protection gets broken at some point.
If you want to test HDR playback, please update to a new LAV nightly build because only the latest LAV nightlies are able to pass some HDR metadata information to madVR!
(P.S: There's also a new "madTestPatternSource" version available with some HDR test patterns. Link see first post in this thread.)
nevcairiel
14th December 2015, 16:25
Are there any smart ideas how to properly configure a display for HDR? I could set it to its maximum brightness and measure this, and tell madVR about it.
However, the maximum brightness is far above what I find "pleasing" for SDR movies, or even the desktop/player UI, so its really not "good" to configure it to that.
Of course I could tell madVR about the brightness of my average setup, but then there is nothing to gain from HDR at all.
THEAST
14th December 2015, 16:28
Yeah, Crossfire has repeatedly being reported as causing problems with madVR, unfortunately.
So, there is no way to prevent the crashes without disabling Crossfire globally? I'm not trying to accelerate madVR's computation with crossfire, mind you, but rather, I am trying to find out why the crashes happen even though crossfire is not enabled for MPC-HC/madVR and is only enabled for applications that specifically have a profile.
mogli
14th December 2015, 16:30
Or are you saying that every time the old version reported a repeated frame, you got a visual stutter? That would be something completely different, of course!
Yes, before the current version repeated frames were reported and visual stutter occured at that very moment. Now there's only the latter.
Note that this only seems to happen when fps is almost the same as the display rate. It took me some time to remember that the interlaced NTSC DVDs (actual video, not film) will have there frames doubled by DXVA deinterlacing, therefore running 59 fps at 60 Hz. This seems to be hard for FRC. (No way around starting to use ReClock, it seems?)
Only about 1-2 of those 60 frames will be blended/unique. This is the way smooth motion frc works, so listing such repeated frames in the ctrl+j menu doesn't make much sense, imho.
madVR never did report such repeated frames, at least not for me. When viewing a 24 fps movie at 60 Hz with FRC on I never got even one repeated frame reported in any version. Or do you want to say, this was by accident, because each and every frame was unique or blended, so that there never was any actual repeated frame?
Bandito
14th December 2015, 16:39
No. If it's already installed all you need to do is copy it over the old files.
k thx
madshi
14th December 2015, 16:59
Are there any smart ideas how to properly configure a display for HDR? I could set it to its maximum brightness and measure this, and tell madVR about it.
However, the maximum brightness is far above what I find "pleasing" for SDR movies, or even the desktop/player UI, so its really not "good" to configure it to that.
Of course I could tell madVR about the brightness of my average setup, but then there is nothing to gain from HDR at all.
That's a pretty good question. I suppose once HDR content is around, many users will have the same problem. To be honest, I've no simple solution available right now. I suppose one option would be to define a peak nits level for SDR content. In that case madVR would simply render SDR videos darker. The disadvantage of that solution would be that a part of the 16-235 data range would go unused, which would be a shame. But then, I suppose dithering is good enough to handle that.
Another option would be to use different presets in the TV, but only some TVs support that, and the lack of auto switching could be quickly become annoying.
Edit: My idea above would only work for video playback, obviously, it would not do anything for desktop or player GUI. If you need a solution for that, too, maybe one option would be to misuse the GPU gamma ramps to make everything darker? That should work for desktop and media player GUI. However, GPU gamma ramps don't use dithering, I think, so it would not be a good solution for image quality.
So, there is no way to prevent the crashes without disabling Crossfire globally? I'm not trying to accelerate madVR's computation with crossfire, mind you, but rather, I am trying to find out why the crashes happen even though crossfire is not enabled for MPC-HC/madVR and is only enabled for applications that specifically have a profile.
That's a question you'd have to ask AMD. I don't think there's anything I can do.
Yes, before the current version repeated frames were reported and visual stutter occured at that very moment. Now there's only the latter.
Note that this only seems to happen when fps is almost the same as the display rate. It took me some time to remember that the interlaced NTSC DVDs (actual video, not film) will have there frames doubled by DXVA deinterlacing, therefore running 59 fps at 60 Hz. This seems to be hard for FRC. (No way around starting to use ReClock, it seems?)
madVR never did report such repeated frames, at least not for me. When viewing a 24 fps movie at 60 Hz with FRC on I never got even one repeated frame reported in any version. Or do you want to say, this was by accident, because each and every frame was unique or blended, so that there never was any actual repeated frame?
Ok, so I misunderstood your original report. I didn't think there was visual stutter. So I suppose I should revert the OSD change.
What fill state do the queues have when that stuttering occurs? How many frames are you presenting in advance? Or did you disable the "present several frames in advance" option? FWIW, it's recommended to use that option because it increases presentation reliability.
huhn
14th December 2015, 17:05
That's a pretty good question. I suppose once HDR content is around, many users will have the same problem. To be honest, I've no simple solution available right now. I suppose one option would be to define a peak nits level for SDR content. In that case madVR would simply render SDR videos darker. The disadvantage of that solution would be that a part of the 16-235 data range would go unused, which would be a shame. But then, I suppose dithering is good enough to handle that.
double HDMI connection should be possible in the near future.
switching the HDMI output on a TV doesn't sound too terrible.
and DP 1.3 to HDMI 2.0 should work with an passive adapter.
you are simply way ahead of time with that feature.
but i don't think leaving the TV at a high brightness for SDR content is a good idea. none OLED screens will lose a lot of CR this way. and local dimming has a enough of problems already without this high brightness.
Thunderbolt8
14th December 2015, 17:39
3) HDR content is encoded using a totally different transfer ("gamma") curve. So playing HDR content with a media player and display which don't understand the new transfer function won't look good/correct. It will look totally washed out.So does this mean even when using madVR for watching an UHD Blu-ray on my current plasma TV (VT60) that it will look bad/not right?
nevcairiel
14th December 2015, 18:39
So does this mean even when using madVR for watching an UHD Blu-ray on my current plasma TV (VT60) that it will look bad/not right?
No, madVR will correct that.
Note however that not all UHD Blu-rays will use HDR, in fact most will not. There may even be two releases of movies, one in HDR and one SDR.
fairchild
14th December 2015, 19:11
Thanks for new version Madshi, I have a quick question though. How do we know what to set the display peak luminance to? I have an older 1080p 32" EX400 Sony LCD and a 1080p 55" VT60 Panasonic Plasma. Both by default are set to 600 nits. Not sure how or where to find the correct setting. I know one thing is for certain, the plasma is a much higher end display which may affect this setting?
nevcairiel
14th December 2015, 19:15
Thanks for new version Madshi, I have a quick question though. How do we know what to set the display peak luminance to?
Sometimes its in the documentation, otherwise you have to measure it.
Note that documented peak luminance will always refer to 100% backlight setting, which you may not find good for general watching purposes, like myself.
James Freeman
14th December 2015, 19:17
4) The new transfer function directly maps each pixel to a specific desired luminance value (in "nits" or cd/mē). Possible values are 0 nits up to 10,000 nits. However, videos don't have to use the full 0 - 10,000 range, they often top out at either 4,000 nits or 1,200 nits (from what I've seen).
First, Thank you for this pioneer build!
Questions:
How can you really know in what range the studio mastered their movie? Seen where?
Judging by what I see with madTestPattern, how did you know what region is more important to compress and what to clip?
With 1200nit mastered content (presumably), the whole range is compressed.
With 4000nit, again practically the whole range is compressed.
Doesn't that mean that the movie will be too dark overall just so that we will be able to see the super bright parts?
TheElix
14th December 2015, 19:17
The crash is when doing error diffusion. You could try updating your GPU driver, maybe that helps?
In order to find the failure to enter FSE mode, I'll need another log with the debug OSD (Ctrl+J) active while recording the log, because having the debug OSD active adds some more information to the log that I need in this case.Madshi, thank you for your patience and for finding time to look into my problem. I have switched to Random Dithering and it seems to fix crashes. But at around the same time when it crashed previously now the video hangs up. It appears like the video goes in an endless loop of several frames while the audio keeps playing.
Here's the log with the debug OSD: https://yadi.sk/d/QDP2CRqHmDvVi Maybe you can tell why it doesn't go into FSE?
I've downloaded several test videos and tried the new HDR feature. I am currently using a professional NEC P241W monitor which is true 10 bit through DisplayPort cable and is capable of >Adobe RGB coverage and has a preset for DCI color space. I've set the maximum brightness which is 350 cd/m2 for this display and set the white point to 6500K. I used 400 cd/m2 in madVR settings. Well, it works. :) But I have horrible amount of dropped frames even though rendering is well under 10 ms. It looks like I cannot truly appreciate the difference now since I'm not getting 10 bit without FSE.
Also, you said that we may choose the maximum luminance between 0-10000 cd/m2, but the lowest I can choose now is 400 cd/m2. Is it intentional? Can we choose luminance in increments other than 100-200?
James Freeman
14th December 2015, 19:26
I think the new "display peak luminance" feature only works if your display has a static and unchangable minimum light level (MLL) of the display.
Meaning, it only truly works if you have a FALD (full-array local dimming) display.
If your display can do 4,000nits but keeps the contrast ratio at 1000:1 it simply does not differ from any other SDR TV.
OR, I might be very wrong!
..and madVR actually compress the HDR content to 1000:1 and you should turn your SDR display brightness to max (400nit) to utilize the new feature...?
I need some HDR demo clips, anyone?
Plutotype
14th December 2015, 19:31
What about Dolby Vision support in madVR? Is it something technically impossible to implement?
Thanks
madshi
14th December 2015, 19:38
Note however that not all UHD Blu-rays will use HDR, in fact most will not.
I'm not sure about that. I've some content that is mastered at 1200 nits with DCI-P3. I could imagine that something like this might be suitable for any old and new movies. So it's quite possible that all (or most) movies might get HDR transfers. But I don't really know, we'll have to wait and see...
How do we know what to set the display peak luminance to?
FWIW, there's no exact science for how these HDR -> SDR conversions work. So the numbers in the settings dialog are rough estimates. Things also depend on the ambient light level in the room and how your display is calibrated. E.g. with a front projection setup, although the luminance is much lower than e.g. 600 nits, you might still get the best image quality by setting your display to 600 or 900 nits. So my recommendation is to simply play some HDR content and let you eyes decide which nits setting in madVR looks best in your setup.
How can you really know in what range the studio mastered their movie? Seen where?
Install a nightly LAV build, then press Ctrl+J and the mastered nits level is displayed.
Judging by what I see with madTestPattern, how did you know what region is more important to compress and what to clip?
With 1200nit mastered content (presumably), the whole range is compressed.
With 4000nit, again practically the whole range is compressed.
Doesn't that mean that the movie will be too dark overall just so that we will be able to see the super bright parts?
As mentioned before, there's not an exact science to this. The content has more range than any display, so there's way around compressing it somehow somewhere. How much to compress and maybe to clip depends on the video encoding luminance and the display peak luminance. I've selected values for each combination which with real world material looked "good" to me.
I have switched to Random Dithering and it seems to fix crashes. But at around the same time when it crashed previously now the video hangs up. It appears like the video goes in an endless loop of several frames while the audio keeps playing.
Oh well. Have you tried installing a different GPU driver version? Do you have any funny GPU related software installed/running? If so, try disabling it.
Here's the log with the debug OSD: https://yadi.sk/d/QDP2CRqHmDvVi Maybe you can tell why it doesn't go into FSE?
Will look later when I'm back at my development PC.
I've downloaded several test videos and tried the new HDR feature. I am currently using a professional NEC P241W monitor which is true 10 bit through DisplayPort cable and is capable of >Adobe RGB coverage and has a preset for DCI color space. I've set the maximum brightness which is 350 cd/m2 for this display and set the white point to 6500K. I used 400 cd/m2 in madVR settings. Well, it works. :) But I have horrible amount of dropped frames even though rendering is well under 10 ms. It looks like I cannot truly appreciate the difference now since I'm not getting 10 bit without FSE.
Which queue is the first one empty? Probably the decoder queue? 4K HEVC decoding is really demanding!
Also, you said that we may choose the maximum luminance between 0-10000 cd/m2, but the lowest I can choose now is 400 cd/m2. Is it intentional?
No, 0 - 10000 is the range each pixel can have, not the range you can choose in the settings. The settings you can choose is which peak luminance your display has. If your display has a peak luminance of 0 nits then its broken because it doesn't display anything at all.
I think the new "display peak luminance" feature only works if your display has a static and unchangable minimum light level (MLL) of the display.
Meaning, it only truly works if you have a FALD (full-array local dimming) display.
If your display can do 4,000nits but keeps the contrast ratio at 1000:1 it simply does not differ from any other SDR TV.
OR, I might be very wrong!
..and madVR actually compress the HDR content to 1000:1 and you should turn your SDR display brightness to max (400nit) to utilize the new feature...?
Huh? No. Contrast got nothing to do with it. If you have a perfect black level, contrast automatically calculates to infinite, regardless of peak white luminance. And MLL got nothing to do with it, either.
What about Dolby Vision support in madVR? Is it something technically impossible to implement?
I neither have any such content nor any technical spec. Also there are no decoders available for that. But my best guess is that it might be compatible to "conventional" HDR. I don't really know, though.
James Freeman
14th December 2015, 19:59
Huh? No. Contrast got nothing to do with it. If you have a perfect black level, contrast automatically calculates to infinite, regardless of peak white luminance. And MLL got nothing to do with it, either.
Then what is the difference between 1,200 and 400 nit with 1000:1 display?
So this "peak brightness" selector only works if you have perfect blacks (stable and unchangable MLL where only the peak brightness changes, aka FALD or OLED display)??
madshi
14th December 2015, 20:05
I'm not sure why you keep trying to limit the "peak brightness selector" to specific conditions under which it might work or might not work. There is no such limit. And as I said, the display contrast got nothing to do with it.
HDR content that is mastered on e.g. a 4000 nits display should ideally be displayed on a 4000 nits display. If your display cannot do 4000 nits then madVR has to compress the highlights, otherwise the image would be much too dim overall. The difference between 1200 nits and 400 nits in the madVR "peak luminance" option is how much compression madVR applies to the luminance channel. The dimmer your display is the more compression madVR has to apply to make the image bright enough overall.
Why don't you simply download some HDR content and try different settings for that madVR option and see which works best for you? I think for most people with today's display technology, the default setting of 600 nits should work well. If the image is too dim/dull for your taste, try 400 nits. If the image is too bright, try 900 nits or higher.
James Freeman
14th December 2015, 20:12
I understand that it compresses the range, what I don't understand is whether you assume that the display has infinitely low black leve and the only thing that changes is the peak brightness level?
The only free content that is available now is a couple of seconds of Life of Pi and Exodus right?
madshi
14th December 2015, 20:20
We're talking about digital processing. madVR outputs video content with a black level value of 0 (or 16 when using TV levels). Whether or not the display has infinitely low black levels or not isn't something madVR has to worry about.
Basically what madVR does is modifying the "gamma curve" (in words that might make more sense to you), to account for the difference in peak luminance capabilities between the mastering display and your display.
James Freeman
14th December 2015, 20:26
Got it, I'm kinda' slow today.
Sorry about that.
BTW, it would by nice to bypass this feature for reference, or just to see how the image mapped across standard power curve gamma.
nevcairiel
14th December 2015, 21:20
BTW, it would by nice to bypass this feature for reference, or just to see how the image mapped across standard power curve gamma.
Just switch to EVR or something. It looks terrible, totally lifeless and dull.
har3inger
14th December 2015, 21:26
Yes, before the current version repeated frames were reported and visual stutter occured at that very moment. Now there's only the latter.
Note that this only seems to happen when fps is almost the same as the display rate. It took me some time to remember that the interlaced NTSC DVDs (actual video, not film) will have there frames doubled by DXVA deinterlacing, therefore running 59 fps at 60 Hz. This seems to be hard for FRC. (No way around starting to use ReClock, it seems?)
madVR never did report such repeated frames, at least not for me. When viewing a 24 fps movie at 60 Hz with FRC on I never got even one repeated frame reported in any version. Or do you want to say, this was by accident, because each and every frame was unique or blended, so that there never was any actual repeated frame?
Just as a test, try lowering the GPU load as much as possible (bilinear scalers, check on all the trade perf/quality options) and see if you still have stutter. Back on my old laptop, I experienced something similar, where the OSD wouldn't report any problems or glitches, but my playback would stutter and repeat frames nonstop with smooth motion on. This happens when I'm just riding the edge of the GPU's capability without dropping frames in the OSD. It's still the case with my new computer if I push things too hard.
When you're playing FRC 59 hz at 60 hz display, smooth motion has to blend pretty much every single 60 hz frame, which adds substantially more load compared to 24hz at 60 hz. Yeah, it would be much harder, plus should look much worse with so much frame ghosting. You may as well leave it off or use reclock for that. FRC works best when the display rate is at least double the source framerate.
mogli
14th December 2015, 21:34
What fill state do the queues have when that stuttering occurs? How many frames are you presenting in advance? Or did you disable the "present several frames in advance" option? FWIW, it's recommended to use that option because it increases presentation reliability.8 frames in advance; what happens is that the second number of the present queue in the OSD shortly goes up from 7 to 8 when the repeated frame occurs (both with FRC on or off), the other numbers being stable;
madshi
14th December 2015, 21:36
Hmmm... Windowed or FSE mode? Try FSE, it's usually more reliable.
TheElix
14th December 2015, 21:48
Oh well. Have you tried installing a different GPU driver version? Do you have any funny GPU related software installed/running? If so, try disabling it.I'm on latest Crimson 15.11.1 version, but will try to downgrade as much as possible.
Which queue is the first one empty? Probably the decoder queue? 4K HEVC decoding is really demanding!
The present queue is the first one. Here's the picture: https://yadi.sk/i/a1t0Pc0NmE45r
madshi
14th December 2015, 21:50
The decoder queue is almost empty, that's the bottleneck. Your decoder is too slow.
Thunderbolt8
14th December 2015, 22:26
is it possible to take screenshots which contain subtitle lines with madvr? from what I can see they arent saved with the picture.
madshi
14th December 2015, 22:30
Here's the log with the debug OSD: https://yadi.sk/d/QDP2CRqHmDvVi Maybe you can tell why it doesn't go into FSE?
Yes. The debug log reads:
D3D11 fullscreen windowed (8 bit)
covered by some windows
madVR window [madVR] {0,0,1920,1200}
covered by StrokesPlus.exe window [STROKESPLUS] {0,0,1920,1200}
So basically StrokesPlus.exe has a fullscreen window which covers the madVR rendering window. That's the reason why madVR can't go FSE.
is it possible to take screenshots which contain subtitle lines with madvr? from what I can see they arent saved with the picture.
I think there was a way, but I don't remember. Maybe someone else can help out? FWIW, screenshotting will be revisited/improved in some future version, but not very soon.
sneaker_ger
14th December 2015, 22:43
is it possible to take screenshots which contain subtitle lines with madvr? from what I can see they arent saved with the picture.
http://forum.doom9.org/showpost.php?p=1637684&postcount=19673
Aktan
15th December 2015, 03:34
madVR only drops frames if either the GPU is too slow or if the refresh rate it too low. Please make a screenshot of the Ctrl+J madVR menu when you get those frame drops, then maybe we can help.
Generally you should get better quality when letting madVR deinterlace. So it might make sense to try that again and post a screenshot of Ctrl+J with that setup, too.
I think it's more like the madVR isn't requesting the frames from the capture source. Here is the screenshot of Ctrl+J in Potplayer using the capture source: http://i.imgur.com/8KwExdw.jpg and here is the screenshot of Ctrl+J in Potplayer using a captured AVI from the same capture source: http://i.imgur.com/7anTyFl.jpg. Here are a few things I've noticed:
-Graphedit using madVR as a render shows a black screen only when directly connected to capture source. This doesn't happen playing back a file.
-Both Potsplayer and MPC-HC show the queue being pretty much empty all the time when playing a capture source.
-You are right, the deinterlacing from madVR works great (no need for ffdshow deinterlacing) ONLY if I playback an AVI of the capture source. I think this is mostly due to the queue being empty though...
-Using Graphedit and VM9 and ffdshow to set interlace flag to force DXVA deinterlacing, everything works perfectly with capture source.
I'm pretty sure it's not my GPU as I have 1080i clips that play fine with deinterlacing on. Also the fact it works fine with an AVI of the same capture source shows it's not maxing the GPU at all. I think it is a hint that madVR shows black for Graphedit with capture source but not files.
Now I do realize having a huge decoding queue would introduce input lag for gaming like in this example, but if I were to watch just analog TV (which actually doesn't exist anymore) or just say a VCR, I would still have this problem. I could also just lower the queue if I do live game.
dansrfe
15th December 2015, 04:25
Is it possible for madVR to adjust display backlight over DDC/DI based on profile rules for HDR/SDR media? That way, like calibration curves, backlight can be adjusted automatically as well.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.