View Full Version : madVR - high quality video renderer (GPU assisted)
kirakami
18th December 2011, 09:46
As clsid correctly said, the GPU doesn't matter for P010/P016 support, if you're using madVR. P010/P016 is just the connection between the decoder and madVR. The GPU got nothing to do with that. If you want to know which GPU to get exactly, my advice has always been the same: Get the faster GPU you can afford and that fits your thermal requirements. Since both AMD and NVidia are soon coming out with 0.28nm GPUs, I would recommend to wait, though. Or if you can't wait, you could also consider getting a cheap GPU now and then sell it on Ebay once the new 0.28nm GPUs arrive. Then get the fastest 0.28nm GPU you can afford.
you say GPU don't matter that means,
i can output P010/P016 using madVR on my current Graphic Card Nvidia Ge-Force 4 MX440?
last time i tried madVR 0.77 it was crashing
i will try again
kirakami
18th December 2011, 10:01
tried madVR 0.79
i get this error when i use madVR on Ge-Force 4 MX440
& MPC-HC crashes only audio plays
MPC-HC- > Playback > Output > madVR
http://i41.tinypic.com/15pq1qu.jpg
THX-UltraII
18th December 2011, 10:05
THX-UltraII,
yes, that's exactly what I mean.
Depending on the player you are using you can configure it to go automatically on the secondary display on start or just when going fullscreen. With Zoom Player or MPC you can have multiple instances/installation and have one configured for "HTPC" usage (on the secondary display) while the other is your "test" environment on the primary display (monitor)
thxz. And how do I config MPC to switch to the secondary display when start playing content? Are there any disadvantages when having my projector (main display to watch content) configured as secondary display?
The second part in your reply (about multiple instances) I don t understand :o
EDIT: will it work to control my sliders in the D-Box control panel in the background if I somehow manage to give high priority above other programs or something to resond even while running in background/minimized?
sneaker_ger
18th December 2011, 10:07
you say GPU don't matter that means,
i can output P010/P016 using madVR on my current Graphic Card Nvidia Ge-Force 4 MX440?
last time i tried madVR 0.77 it was crashing
i will try again
No, he meant what he said: P010/P016 is the data that is passed from the decoder filter to madVR, it is not what madVR outputs to the monitor, so your GPU does not matter. MadVR itself cannot output more than 8 bit at the moment, and with the vast majority of monitors being limited to a mere 6 bit, that's sufficient.
Your crash has nothing to do with the P010/P016 formats.
kirakami
18th December 2011, 10:36
just thinking
it would have been great if i could output P010 using Overlay Mixer
since GPU don't really matter
let me know if its really possible :)
sneaker_ger
18th December 2011, 11:07
just thinking
it would have been great if i could output P010 using Overlay Mixer
since GPU don't really matter
let me know if its really possible :)
No, it's not possible. And believe me, it does not matter anyways. People here are perfectionists, but with displays being 6 bit, it really does not matter. People use 10 bit H.264 because the increased internal precision improves compression (same quality for less bits/better quality for same bitrate), not because they need to output 10 bit to the monitor.
italospain
18th December 2011, 11:16
madshi
Could you tell,
why madvr mpeg2 decoder outputs 720x576(480) but Dscaler outputs 704x576(480) video for SD video?
Thanks for all!
Disable do analog blanking in the dscaler options and you get 720x576
SoBizarre
18th December 2011, 11:32
People here are perfectionists
If perfectionist is synonym of anal, then yes, you are right. ;)
pankov
18th December 2011, 12:04
thxz. And how do I config MPC to switch to the secondary display when start playing content? Are there any disadvantages when having my projector (main display to watch content) configured as secondary display?
The second part in your reply (about multiple instances) I don t understand :o
EDIT: will it work to control my sliders in the D-Box control panel in the background if I somehow manage to give high priority above other programs or something to resond even while running in background/minimized?
THX-UltraII,
the idea of multiple instances is that you can have different configurations in them ... of course this is only if you need to watch content on both your monitors like I do.
About MPC's configuration - it's not my main player so you'll get better answers if ask your questions in the MPC thread. I think you'll have to look in Options -> Playback -> Fulscreen
but let's not bother madshi with all this unrelated talk any more
mr.duck
18th December 2011, 12:38
x86_64 has 16 64-bit GPR instead of 8 32-bit and 16 XMM registers instead of 8.
I see... Is that good? :P No but seriously, does it really matter or what sort of program will benefit from this?
It's not 64-bit OS being capable of running 64-bit binaries, but 64-bit OS having compatibility layer for running 32-bit executables. That layer is there for easier transition to 64-bit, not for 32-bit applications to stay forever.
Some people think, that as far as they write proprietary Windows-only software they don't need to care about portability. Well, it will be fun to watch them, when ARM netbooks with Windows 8 start to come out.
I didn't think of it that way before. But native Win32/Win64 binaries are the best. Screw portability. JAVA is the worst. Urgh.
kirakami
18th December 2011, 13:27
No, it's not possible. And believe me, it does not matter anyways. People here are perfectionists, but with displays being 6 bit, it really does not matter. People use 10 bit H.264 because the increased internal precision improves compression (same quality for less bits/better quality for same bitrate), not because they need to output 10 bit to the monitor.
but it would be awesome if P010 does becomes possible with Overlay Mixer in near future :D
ryrynz
18th December 2011, 14:08
No, it's not possible. And believe me, it does not matter anyways. People here are perfectionists, but with displays being 6 bit, it really does not matter. People use 10 bit H.264 because the increased internal precision improves compression (same quality for less bits/better quality for same bitrate), not because they need to output 10 bit to the monitor.
We do love our anime with as little banding and as few artifacts as we can get whilst maintaining a respectable size.. anyway back to MadVR, eagerly awaiting 0.80.
nlnl
18th December 2011, 15:12
Disable do analog blanking in the dscaler options and you get 720x576
Yes, it works!
Thanks!
YouArePro
18th December 2011, 17:35
can someone please help me? thanks a lot! (read my original post on pg 576)
mr.duck
18th December 2011, 19:08
can someone please help me? thanks a lot! (read my original post on pg 576)
kmplayer is the one that stole GPL code? Try using MPC-HC instead.
madshi
18th December 2011, 21:37
x86_64 has [...] 16 XMM registers instead of 8.
Yes, that's the only thing that I find attractive about going x64. Don't really know why they didn't expose all 16 registers in x86.
Installed windows 7 ultimate 32bit through boot camp on my macbook pro, but madvr 0.79 does not work on my kmplayer, it used to work in windows xp 32 bit on my macbook pro last year before changing to windows 7 now. graphic card on my macbook pro is nvidia geforce 320M. I cannot play any video files, the kmplayer will hang everytime if i play a file , I have to go to task manager and end the kmp program. Anyone can help me please? thanks a lot!
Is it a dual Intel / NVidia GPU solution? There have been reports that these make problems with madVR at the moment. My sister has such a laptop, maybe I can borrow it for a while. But I'm not sure if it can be fixed.
last time i tried madVR 0.77 it was crashing
The GeForce 440MX is not a DX9 GPU. You need a DX9 GPU, as explained in the first post of this thread.
but it would be awesome if P010 does becomes possible with Overlay Mixer in near future :D
I thought you were talking about the connection between decoder and madVR. That connection has nothing to do with the GPU. But if you actually want madVR to *output* 10bit to the display, the GPU does matter. 10bit output is on my to do list, but it doesn't have a high priority at the moment. And you need a GPU which can do it. Don't know which can and which can't.
mr.duck
18th December 2011, 21:48
I assume you will need a nvidia quadro or amd firepro for 10bit output.
madshi
18th December 2011, 21:53
madVR v0.80 released
http://madshi.net/madVR.zip
* added IVTC algo with decimation and support for 3:2, PAL and Anime cadences
* Ctrl+Alt+Shift+T switches between video (DXVA) and film (IVTC) content type
* fixed: moving media player to another monitor made DXVA deinterlacing crash
* fixed: DXVA deinterlacing produced wrong colors (only with HD videos + ATI)
* fixed: after a refresh rate change the composition rate didn't update
* fixed: calculation of consumed GPU RAM was wrong
* fixed: minimizing ZoomPlayer with playing video made some problems
* fixed: v0.79 didn't always detect external refresh rate changes
* fixed: some h264 AVI files made madVR crash, depending on the splitter
* fixed: improved internal decoder MPEG2 timestamp handling
* fixed: zooming video extremely small made madVR close the media player
* fixed: video was positioned wrong when media player cropped top/left
* fixed: a couple of small Direct3D related bugs
* fixed: a little resource leak
* improved presentation timestamp correction a bit
* improved "IMadVRExclusiveModeInfo::IsExclusiveModeActive"
* improved "IMadVRExclusiveModeControl::DisableExclusiveMode"
* added window size checks to detect to-be-expected exlusive mode failures
* added new interface "IMadVRDirect3D9Manager" for XBMC (work in progress)
* modified automatic queue sizes
* improved logging during media player shutdown
Please note that the IVTC algorithm is brand new and has a number of limitations. It seems to work pretty well in my limited tests, but more broad testing by you guys is needed to find out whether it really works well enough. Here's a list of limitations:
(1) It currently runs single threaded on the CPU. I plan to eventually move this to the GPU, but I'll need to use CUDA/OpenCL for that, and from ATI I need a driver with full OpenCL 1.2 support, which is not available yet. So it might take quite a while before I can move this to the GPU. For now it will have to run on the CPU.
(2) Although I've written SSE2 assembler, it still consumes quite a bit of CPU power. If your CPU is already on the fence with HD decoding, you probably won't be able to use madVR's IVTC algorithm with h264/VC-1 HD content. It might still work with MPEG2 content for you, since that's easier on the CPU. It should definitely work with all SD content. If your CPU is plenty fast, there's no problem, of course.
(3) Although all possible cadences should be supported in theory, I've mainly tested 3:2 and 2:2, so Anime support might need some tweaking. It does generally seem to work well enough for a first version, from my limited tests with Anime sources.
(4) For now, madVR does not even try to detect whether a video is natively interlaced or telecined. As a result, madVR defaults to DXVA deinterlacing, because DXVA deinterlacing can handle all types of content reasonably well. You have to manually switch to madVR's new IVTC algorithm by pressing Ctrl+Alt+Shift+T twice ("T" stands for content [T]ype). Default is "video mode", which is deinterlaced by using DXVA. By switching the content type to "film mode", you activate madVR's new IVTC algorithm. In the future, I'm planning to add automatic detection for the content type, so you don't have to switch manually.
(5) The current version of the IVTC algorithm always expects the whole frame to be telecined content. Video mode overlays or mixed video/film (in one frame) content is not supported at the moment.
(6) Refresh rate switching does not currently take the decimation ability of the IVTC algorithm into account, so it won't switch to 24Hz mode automatically. Sorry about that. You can work around it by tagging your files with "24p" or "23p". The refresh rate changer will be improved in a future version to take IVTC into account.
Please report any problems you have with the IVTC algorithm. But before you report, please make sure that content you have is really telecined. I've found that most PAL Animes are field blended, which is an ugly mess and can't be IVTCed at all. The only way to handle such Anime content is to use video mode deinterlacing.
underzone
18th December 2011, 21:57
Thanks!!!!!!! Downloading now...
robpdotcom
18th December 2011, 22:03
madVR v0.80 released* added IVTC algo with decimation and support for 3:2, PAL and Anime cadences
* fixed: DXVA deinterlacing produced wrong colors (only with HD videos + ATI)
* fixed: after a refresh rate change the composition rate didn't update
Awesome.
I'll be doing plenty of testing with the new IVTC algorithm.
As always, big thanks.
EDIT: It seems that forcing deinterlacing and selecting film mode works with 720p59 content?
Budtz
18th December 2011, 22:06
So does this mean Madvr is optimized to run for example 24p on 60hz and 25p on 50hz now?
And i need to switch to film-mode to do so?
Also I seem to need to switch every time madvr starts? It dosn't save my choise. (I only watch films)
madshi
18th December 2011, 22:15
So does this mean Madvr is optimized to run for example 24p on 60hz and 25p on 50hz now?
Not really. It's more the other way round: You can now play telecined movies (60i) with a 24Hz refresh rate. However, maybe 60i telecined movies may run slightly smoother even on 60Hz now, not sure.
Also I seem to need to switch every time madvr starts? It dosn't save my choise. (I only watch films)
For now you have to manually switch, every time you start a new video. I'm sorry about that. It's Sunday evening here and I have been working on this for 3-4 weeks now, and I don't have much time for madVR in the next couple of days. So I only had the option to release what I have right now, or to wait another 1-3 weeks before I release v0.80 (then with more options). So I decided it was time to finally release a first version with the new IVTC algorithm now, even though it's still missing some bits and pieces. In the future there will probably be options to enable film mode by default.
madshi
18th December 2011, 22:18
EDIT: It seems that forcing deinterlacing and selecting film mode works with 720p59 content?
Define "works". It will probably not do much, but it might also not break much. It will probably not decimate 720p59 to 720p23, if that's what you're looking for. Things like that might come in a future version. But for now I've concentrated on actual interlaced content. Testing probably makes sense only with 50i and 60i sources.
SamuriHL
18th December 2011, 22:27
For now you have to manually switch, every time you start a new video. I'm sorry about that. It's Sunday evening here and I have been working on this for 3-4 weeks now, and I don't have much time for madVR in the next couple of days. So I only had the option to release what I have right now, or to wait another 1-3 weeks before I release v0.80 (then with more options). So I decided it was time to finally release a first version with the new IVTC algorithm now, even though it's still missing some bits and pieces. In the future there will probably be options to enable film mode by default.
I appreciate not holding on to the release. Us MC17 users will most likely benefit. :) So thanks!!
kasper93
18th December 2011, 22:48
@madshi:
* fixed: zooming video extremely small made madVR close the media player
Now instead of close I get crash. :) (MPC-HC)
BTW. What do you think about using 7-zip(LZMA2) instead of zip(Deflate)? I have made little comparison:
madVR.zip = 3.88 MB || madVR.7z = 2.37 MB
libmfxsw32.zip = 3.72 MB || libmfxsw32.7z = 2.08 MB
It would save some bandwidth.
nevcairiel
18th December 2011, 23:01
BTW. What do you think about using 7-zip(LZMA2) instead of zip(Deflate)?
Windows comes with ZIP support, 7z/LZMA needs an extra application.
madshi
18th December 2011, 23:23
Now instead of close I get crash. :) (MPC-HC)
How can I reproduce this? I tried, but didn't manage to. I couldn't reproduce the MPC-HC closing with older version, either, so I tried to fix it "blind".
Budtz
18th December 2011, 23:31
Oh ok so the new algo does not have any effect on say a bluray movie. Have i got that right?
Also when i open files it now dosnt say the names anymore. It says "excluvie" in stead. This is with all files.
Thx for all the hard work:)
madshi
18th December 2011, 23:40
Oh ok so the new algo does not have any effect on say a bluray movie. Have i got that right?
Mostly. There are a few (very few) 1080i60 Blu-Rays out there, which madVR will properly IVTC to 1080p24.
Also when i open files it now dosnt say the names anymore. It says "excluvie" in stead. This is with all files.
Haven't changed anything in that regard. There can only be one message at a time, though. If the file name is shown first and the exclusive mode comes after that, the exclusive message will overwrite the file name. But that should have been the same way in all previous versions, too.
EDIT: It seems that forcing deinterlacing and selecting film mode works with 720p59 content?
Actually, it seems you were half right. I underestimated my own algorithm... :D If you force the new IVTC algorithm on for 720p60 *movie* content, the IVTC algorithm will treat it as 720i120 and deinterlace it "properly". It will detect a 6:4 cadence (you can see that in the debug OSD). So it kinda works. Funny that, didn't even intent that to work. And it shows nicely that my IVTC algorithm works with *any* cadence. What I'm not sure about is what exact refresh rate my algorithm will output in this situation. I've written decimation mainly for 3:2. So I'm not totally sure if you will get 720p60 output or 720p48 or maybe something in between. You definitely won't get 720p24 output, though.
kasper93
18th December 2011, 23:46
How can I reproduce this? I tried, but didn't manage to. I couldn't reproduce the MPC-HC closing with older version, either, so I tried to fix it "blind".
Grab top border of the MPC-HC window and slide down, it should crash. http://dl.dropbox.com/u/16282309/MPC-HC/crash.png
gav1577
19th December 2011, 00:01
madVR v0.80 released
* added new interface "IMadVRDirect3D9Manager" for XBMC (work in progress)
Nice V-nice indeed :thanks:
TheShadowRunner
19th December 2011, 00:25
Hi madshi, thanks a lot for the new build.
I experience some weirdness with the "adjust queue sizes to GPU RAM size" setting.
With the SAME file (a 1080p mov trailer), I experience the following behavior:
If "adjust queue sizes to GPU RAM size" is enabled (automatic), then madVR uses 20/12/12/3. In this case rendering is reported as 20ms and I get crazy presentation glitches.
If "adjust queue sizes to GPU RAM size" is disabled and I set both CPU queue size/GPU queue size to 8 (8/8/8/3) (=madVR 0.77 defaults), then rendering is reported as 12ms and I get 0 presentation glitches.
In other words, the automatic setting/higher queue sizes have a detrimental effect on performance. Is this normal/expected?
In other news, the bug that caused the video to catch-up uber fast after the player was restored from minimized seem fixed, thanks ;)
YouArePro
19th December 2011, 00:36
Is it a dual Intel / NVidia GPU solution? There have been reports that these make problems with madVR at the moment. My sister has such a laptop, maybe I can borrow it for a while. But I'm not sure if it can be fixed.
Yes my 13" inch 2010 model macbook pro's gpu is integrated into the cpu with shared memory. However, it used to work fine with windows XP professional 32 bit on my bootcamp before changing to windows 7 ultimate 32bit now.
Fadeout
19th December 2011, 00:57
Grab top border of the MPC-HC window and slide down, it should crash. http://dl.dropbox.com/u/16282309/MPC-HC/crash.png
That's true :)
kasper93
19th December 2011, 00:58
* fixed: calculation of consumed GPU RAM was wrong
Now it is even worse. Consumption of GPU RAM reported in madVR is too low. I don't have any problem related with it, but if someone have low mem GPU than I believe madVR will set too high queue size and it will glitch. But it is only my guess.
idle:
process explorer: 192.5MB
playback 720p in window:
madVR: 109 / 1024MB || process explorer: 510.8MB
510.8 - 192.5 = 318.3MB so if madVR reports 109MB what consuming the rest?
playback 720p in FSE:
madVR: 241 / 1024MB || process explorer: 641.7MB
I don't know how madVR counter works, maybe it supposed to be like this.
In window mode madVR reports exactly GPU Shared Memory. (but it is coincidence i think)
http://dl.dropbox.com/u/16282309/MPC-HC/madVR.gpu.ram.png
EDIT:
Two more screens:
http://dl.dropbox.com/u/16282309/mad/1080p.D.png
http://dl.dropbox.com/u/16282309/mad/1080p.png
cyberbeing
19th December 2011, 01:18
* fixed: calculation of consumed GPU RAM was wrong
It now seems to correctly show GPU RAM usage of madVR only, while ignoring global GPU RAM usage. Not a major problem as long as users are aware that madVR may run out of memory when the OSD shows GPU RAM at ~90-95% (or less if other programs using GPU RAM are open) usage rather than 100%. Either way, I'd rather have it like this, compared to the previous behavior which was wildly inaccurate.
Edit: I took to long previewing my post and I see kasper93 posted about something similar. madVR 0.80 is 'accurate' for its personal GPU RAM usage on WinXP at least, haven't tested Win7 yet.
06_taro
19th December 2011, 01:45
Maybe can be simply improved by displaying free GPU RAM ( or total GPU RAM in use ) in the same time, if someone really cares about it....
robpdotcom
19th December 2011, 02:50
Actually, it seems you were half right. I underestimated my own algorithm... :D If you force the new IVTC algorithm on for 720p60 *movie* content, the IVTC algorithm will treat it as 720i120 and deinterlace it "properly". It will detect a 6:4 cadence (you can see that in the debug OSD). So it kinda works. Funny that, didn't even intent that to work. And it shows nicely that my IVTC algorithm works with *any* cadence. What I'm not sure about is what exact refresh rate my algorithm will output in this situation. I've written decimation mainly for 3:2. So I'm not totally sure if you will get 720p60 output or 720p48 or maybe something in between. You definitely won't get 720p24 output, though.
I think you get 720p60, or something between that and 720p48. If I set the monitor to 50Hz, I get dropped frames (visible, and through the OSD) - at 59Hz, it looked fine and reported no dropped frames.
Oh well, I wasn't expecting it to work, but I was just playing around and wanted to see what would happen. But hey, isn't that what public testing is for.... to see what happens when we do something weird?:p
ryrynz
19th December 2011, 03:04
Madshi, can you tell me please, what are the determining factors in keeping the present queue full?
It always drops right down after the initial queue up and it never recovers, dropping down to 0-2 or so.
I went through all the options in previous versions, 0.80 hasn't changed anything in this area for me, thanks.
andybkma
19th December 2011, 04:45
Window 7 SP1, Zoom Player 8 Max, mVR .80
New problem with Zoom Player 8 and mVR .80 : Coming out of Fullscreen Exclusive Mode into windowed mode causes Zoom Player to act very funny. It freezes, then stutters, the borders of ZP change shape oddly, then finally plays normally again. This is a new problem I have only seen with mVR .80 and only exists with Exclusive Fullscreen mode on. No problems like this with earlier versions of mVR. Going into Exclusive Fullscreen Mode is ok, it's just coming out of it. Thanks
Mikey2
19th December 2011, 05:07
I continually drop frames regardless of the queues in .79. There are so many permutations (each option increases the test case exponentially) that I have spent hours on this, but I have tried running in seperate threads, multiple flush options, different scaling algorithms, feeding different signals from different filters, etc...Since your post I focused on having 8 frames in advance (or backbuffers with that option disabled) and no matter what I try I simply drop frames on a second-by-second basis (where .78 allows me to run SoftCubic/4-Tap Spline in fullscreen exclusive without any frame-drop.)
Well, I asked you something very specific, I didn't ask you to test all permutations. Basically, restore your v0.78 options, then set both CPU and GPU queues to 8. Leave all other settings the same. If that doesn't help then I don't know what will. Most other people seem to have no slowdown with v0.79 compared to v0.78, so I don't really know why you do. It's very weird...
I apologize for the confusion on this - I started with your specific test-case without luck and decided to go further on my testing in hopes of helping you out.
Anyway, I have great news to report, .80 solves my problems! - I cannot thank you enough!!! :D
Even though I have general computer engineering experience, my knowledge on a programatic level of this is somewhat limited. That said, my theory is that the main difference between my system and many others is that I have a very high CPU-speed and decent graphics processing power since my NVidia cards are in SLI, thus allowing me to use my favorite resize algorithms (Chroma:Softcubic-100/Luma:Spline-4tap.) However, SLI does not solve the fact that my 8600GT cards still only have a pathetic 256MB of video-ram. By all rights I should not be able to do this with that little video-memory! I noticed that in .79 the video-ram was pegged in GPU-Z. However, in .80, it is only (heh ;) ) showing 226MB of used video-ram. Perhaps the following fix had something to do with it?:
* fixed: calculation of consumed GPU RAM was wrong
Anyway, I know it sounds like I am gushing, but thank you so much for your time and your effort on this wonderful piece of software. As a software engineer myself I am especially impressed with your dedication to try to solve all of our problems, no matter how ignorant we may be on the problems at-hand. :confused:
So once again, I give you my most heartfelt Thank you! :thanks:
MikeY
Mikey2
19th December 2011, 05:14
I have further good news with version .80!
In regards to my post on RGB32 being cut-off at the bottom... (Here is a link to my post so I don't mess-up the thread with more screenshots:
RGB screen clipping problem (http://forum.doom9.org/showthread.php?p=1542383#post1542383)
)
...You responded:
Please try again with the next build, hopefully fixed.
I just tested that scenario, and sure enough, it works now!
Once again, thank you so much! :thanks:
MikeY
Andy o
19th December 2011, 07:52
Thanks madshi, did not expect this so soon!
Tanis138
19th December 2011, 07:59
Thank you madshi!
madVR 0.80 + MPCHC (Russian) = subtitles don't disappear on Play/Pause.
Now I can fully enjoy movies w/subtitles. You are my hero! :)
azaze1
19th December 2011, 08:11
Nice V-nice indeed :thanks:
+1 indeed
My wish list is getting sparse for the HTPC. MadVR in XBMC with HD audio is pretty much it. No more compromises to deal with after that's all working.
Andy o
19th December 2011, 08:16
madVR v0.80 released
(6) Refresh rate switching does not currently take the decimation ability of the IVTC algorithm into account, so it won't switch to 24Hz mode automatically. Sorry about that. You can work around it by tagging your files with "24p" or "23p". The refresh rate changer will be improved in a future version to take IVTC into account.
One thing about this, madshi. When adding "23p" or "24p" to the file name, deinterlacing gets turned off (it says "override"), so IVTC doesn't work.
dansrfe
19th December 2011, 09:18
My upload and render queues randomly decide to go down 2-4 frames each and then back up resulting in dropped frames sometimes. I have no idea what is causing this.
BeNooL
19th December 2011, 10:48
That could very well be it.
In the display manager 2nd display is at the right of primary so yes, tray area is quite close the FSE area.
I'll try what was suggested by noee and report back.
Moving taskbar to the left, I can properly see madVR's popup menu when clicking on its trayicon.
Strangely when moving taskbar back, popup menu can still be displayed. Then after a short time, we're back to previous behavior.
pankov
19th December 2011, 11:03
BeNooL,
what do you mean by "moving taskbar to the left/right"?
Isn't your taskbar at the bottom of the primary display?
Can you provide a screenshot (using Print Screen) of your desktop with madVR's popup menu visible in the configuration that's giving you trouble. (please, don't post the full resolution pic here but a thumbnail or simply resize it something sane)
You may have to configure madVR to not use Exclusive mode, but still have it fullscreen windowed mode.
G_M_C
19th December 2011, 11:07
Thx for the improvements and additions !
@ IVTC: I was under the impression that my AMD card does IVTC through DXVA when you switch 'pulldowndetection' on ? Then is does recognize 3:2 etc. and video runs smooth. Or is this something completely different ?
@I gather auto reso-switching works as intended now ?
PS on this: I use my secondary output for viewing movies. It does 23/24/50/60p. My primary PC monitor only does 60Hz. When i open a 23p movie file in MPC-HT, it starts on my primary. When i switch to full screen on my secondary, does the resoswitching work there ?
----------------------
@ kasper93
I see your decoder doesn't output NV12, a conversion from H.264 4:2:0 -> NV12 4:2:0 takes place. You can maybe try to set your decoder to output NV12 directly, so no conversion is needed anymore?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.