View Full Version : madVR - high quality video renderer (GPU assisted)
Grmpf
3rd January 2011, 09:07
I'm a bit confused by this statement. Isn't a madVR reported refresh rate of 95.90409 a perfect match for 23.976 video? You can't get any more perfect then that, yet it still reports frame repeats every few minutes. Is this being caused by clock deviation alone? If so, what could I do to fix it without using Reclock?
Hello cyberbeing, take a look into this website (autotranslated from german) (http://translate.google.de/translate?hl=de&sl=de&tl=en&u=http%3A%2F%2Fwww.d65.de%2Fwiki%2FHTPC_Bildfrequenz_Optimierung), there is a script (phyton, from the author of eventghost) to download and used together with a movie + using dts/ac pakets (passthrough) to get a count of pakets lost/repeated and calculate the best matching refreshrate for your graphicscard (works only with powerstrip useable cards - ati 5xxx i think will work) by adjusting front/back porches/etc. to get a much better matching result than just setting your refreshrate inside your driver to a multiple of 23.976hz...
madvr
3rd January 2011, 14:04
Grabbed a 200px square with top-left corner (400,100) in all 3 pics, labeled correctly. Contrasted it so that a 5.3bit dithered peon like myself can see the difference between images.
http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6t.jpg (http://www.pixelz.fr/d/c/8/7e326143681f143e96d54752860f6.png)
It looks like SmoothL actually under-dithers. Zooming in, it also seems to use sort of a diamond dithering pattern. Maybe its the noise generated from madvr's dithering thats bothering you?
... I think the smoothL one looks better than the madVr one. Whether it would make much difference in an actual movie, I don't know.
But I dont suppose the smoothL coder is going to donate his code to madshi...
leeperry
3rd January 2011, 15:13
I think the smoothL one looks better than the madVr one.
Even Stevie Wonder can see that SmoothL is "smoother", but madshi might say that it overdithers and "blurs" vital informations...time will tell.
BTW, I can confirm that my lockups w/ CoreAVC CUDA seem to be over...it was most likely due to my overclocking, as increasing the MCH voltage one notch seems to have straightened things out.
gliderzone
3rd January 2011, 15:25
Hi,
I have a minor bug to report, as well as a question, as follows.
1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)
2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...? I like the card since it's passively cooled (no fan), but I have noticed some issues that might be related to the card cannot handle the load when using madVR. I would like to get this confirmed, and if the card is to weak for madVR, what would you recommend as a replacement...? ATI or nVidia, is there maybe some passively cooled card powerful enough?
madvr
3rd January 2011, 15:32
2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...? I like the card since it's passively cooled (no fan), but I have noticed some issues that might be related to the card cannot handle the load when using madVR. I would like to get this confirmed, and if the card is to weak for madVR, what would you recommend as a replacement...? ATI or nVidia, is there maybe some passively cooled card powerful enough?
I too had a HD4550 before my current card. It was fine unless I set everything to Lanczos - -which you wouldnt anyway... You may find it gets a bit too hot though and needs a fan placing against it! Just keep an eye on its temp in CCC.
pie1394
3rd January 2011, 15:36
On my 20" Samsung 203B TN monitor, it shows the same result just like what scoz saw.
madVR dithering is smoother and less obvious visual banding regardless which brightness area. But madVR dithering is a little bit noisier at some places than smoothL dithering.
I guess I will not see any difference between them except to the sharpness on my 42" PDP TV from 2.8 meter away.
leeperry
3rd January 2011, 17:09
ok, fair enough! It boils down to your display and how its internal dithering is implemented, as expected.
and I wasn't trolling when I said that many LCD panels were 6bit: http://www.widescreengamingforum.com/forum/viewtopic.php?p=121750
All 20" and 19"s with TN panel are 6bit, just like all 22"s with TN panel.
reason why it's so handy to be able to finetune your media player dithering, in order to output the subjectively nicest picture to the end-user IMHO http://forum.slysoft.com/images/smilies/agreed.gif
robpdotcom
3rd January 2011, 17:37
1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)
I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.
Press CTRL-J to bring up the OSD, it will say there if you are in windowed or exclusive mode.
madshi
3rd January 2011, 17:40
Personally, Iīve never encountered any of this. I have absolutely no delay at all, when I press "edit madVR settings" either for the first time or about a dozen times in a row and close the dialog afterwards. To be sure about that, I just tried to open/close the dialog about a 100 times, and as fast as I am able to click on it. The dialog opens and can be closed instantly without any delay.
Yeah, it's the same for me. I can't reproduce any problems.
It's happening again...
Log 1: I've opened a mkv file and after playing start I've picked MPC-HC's window title bar and moved the window quickly in several circle movements (clockwise and counter-clockwise). Then, I've right clicked on the window for opening the properties dialog and when clicking the edit settings button the error message appeared.
I had another problem with madVR, a very annoying one. Whenever I opened it to watch any movie its response was very sluggish. Sometimes I had to wait several seconds just when trying to move the player's window, or when right clicking for the properties dialog. I've decided to try a clean install, so I uninstalled it and deleted madVR dir, and reinstalled it. Now it seems to be better, but sometimes the sluggish still happens. Log 2 was made with the sluggish in action. Any clues why this happens? With any other renderer it works fine, this only happens with madVR.
I'm using Win7 x64, MPC-HC v1.4.2808, and ffdshow 3712 (happens with other decoders too).
Edit: I also have a ~2 seconds delay between clicking the edit settings button and the dialog showing up. I can live with that, but would be happier without it... ;)
The logs don't help much with any problems related to opening the settings dialog, because the settings dialog itself doesn't log anything (it's even a different process).
From the log I can see that there's a 2 second delay everytime madVR starts up. But the delay doesn't seem to be caused by madVR. I just see a 2 second gap in the log with no explanation where it could be coming from.
Yeah I meant 0.36 sorry. In windowed mode it is totally fine, the issue is only from fullscreen exlusive. Although when going into fullscreen exclusive and back to windowed, the windowed mode is also messed up.
Im unsure how to run windowed mode in fullscreen without activating exclusive , to test that.
Edit: Just checked with ZoomPlayer, issue is the exact same, fine in windowed or with crossfire disabled, but when enabled in fullscreen exlusive, a jittery mess. Also figured out how to get into fullscreen without exclusive mode, and it is also fine, just like windowed.
I would guess the current multi threaded exclusive mode rendering confuses the crossfire logic, so you simply can't use it for now. Might be fixed by a future madVR version. You can disable the exclusive mode in the madVR settings dialog.
Choosing an algorithm that matches chroma resolution to luma resolution well to avoid colour bleeding, and choosing an algorithm that does not desaturate chroma should be your main priority.
You're forgetting to mention that it's also very important to choose an algorithm which works around chroma aliasing.
I've also noticed a problem where madVR Exclusive Mode seems to be hanging MPC-HC in the taskbar when I right-click (which reverts to Windowed) and close MPC-HC when in fullscreen, if I don't have the 'wait 3 seconds' setting enabled. Is there anyway to fix this without using that '3 second' option?
I'm well aware that disabling the "3 second" option can make problems. Originally this option didn't even exist and they was always a 3 second delay. I've implemented the option on request. Maybe I should add a warning like "use on your own risk".
I think the bug where madVR gets out of sync if you leave the video paused for an extended period of time still exists as well. I've seen this happen occasionally on both computers.
Can anybody confirm this? I've not seen it on my PC, I think. If anybody can reproduce this, a log would be helpful.
I'll be really glad if you look into it.
Ok, will do.
alright, Kazuya has been kind enough to encode a 16-235 black>white gradient in YV12 h264...available here: Banding_720p.rec709.mkv (http://www.mediafire.com/?to56a070x43dskn)
Why didn't you simply use the madTestPatternSource shipping with madVR? :)
2)-the default dithering strength(50) in SmoothL provides smoother gradients than the default dithering in mVR...call if oversmoothing if you like, but it does look "smoother" and does provide a more enjoyable PQ IME(and others). Besides LaTo claims that it doesn't deband per se, it only smooths the TV>PC conversion.
Ok, from what I can see, LaTo uses Floyd Steinberg dithering, or some variation of it. madVR uses random dithering. With low bitdepths (e.g. 1 bit), Floyd Steinberg looks noticeably better. But the higher the bitdepth, the lower the advantage. With 8bit, the difference is almost not noticeable to the naked eye, without zooming in. When zooming in, you'll notice that madVR adds random noise, while Floyd Steinberg has a more geometrical dithering pattern.
I would offer a Floyd Steinberg or similar dithering algorithm in madVR if it was technically possible, but the pixel shader architecture doesn't really allow it.
There's one thing to note, though: The best solution is always to maintain the highest possible bitdepth throughout the whole processing chain and do the dithering step only at the very end. So ideally it should be something like this:
(1) 8bit YCbCr 4:2:0 source
(2) convert to 16bit+ YCbCr 4:4:4
(3) convert to 16bit+ RGB
(4) scale in 16bit+
(5) adjust gamma and levels (video -> PC) in 16bit+
(6) correct color in 16bit+
(7) adjust brightness, contrast, saturation, hue etc in 16bit+
(8) dither down to final output bitdepth
This is exactly what madVR is doing. However, with SmoothL the situation is different. You have the following processing chain, I would guess?
(1) 8bit YCbCr 4:2:0 source
(2) convert to 8bit YCbCr 4:4:4
(3) convert to 8bit RGB
(4) scale in 8bit
(5) correct color in 8bit
(6) SmoothL 8bit input, internally higher bitdepth, output dithered 8bit
(7) adjust brightness, contrast, saturation, hue etc in 8bit
Can you see the problem? All the steps are done in 8bit, so you're summing up rounding errors in every step. Just imagine you change brightness or contrast after SmoothL, and the whole nicely dithered SmoothL output will be damaged again. Or if you feed the SmoothL output into a 3dlut, the 3dlut output will need to be dithered once more. Or if you scale the SmoothL within madVR, again the output needs to be dithered. And adding two dithering operations on top of each other isn't the best solution.
I still would enjoy the ability to tweak the dithering strength in mVR if any possible, I hope this will be considered.
I don't think the strength has anything to do with it. It's Floyd Steinberg vs. random dithering. They look slightly different. My personal opinion is that the difference is very small, though. I'm not even sure which one is "better". As you've seen the opinions in this thread vary.
Using MPC-HC (tried several versions) and the Cyberlink Video Decoder results in a green video.
It doesn't seem to happen on my PC with the Cyberlink Decoder version I've installed and with one MPEG2 MKV I've tried. Does it happen for you with *every* MPEG2 video? Or just with some?
1) full screen exclusive is much slower than windowed mode. I have to turn it off to avoid stuttering. I thought FSE should provide better performance. Rendering times go from ~30-35 to ~45 ms and that causes stuttering on 1080p 24Hz (23.971xxx Hz reported by CRTL+J) TV.
Try replacing all "flush & wait" settings with "flush" only. Does that help?
2) 1 frame repeat is listed as every couple of minutes. If I use ReClock it improves to more than 4 hours, but that introduces regular stutter every few seconds. ReClock is green, madVR CTRL+J shows good values, but this phantom stutter appears and I have no idea what causes it. I have to remove ReClock but then get the 1 frame repeat every 3-4 minutes. Any ideas why the regular hiccup occurs.
Not sure why you get problems with ReClock. Try cleaning up the Reclock timing database. That has helped some people in the past.
1. In Windows 7 Control Panel, "Appearance and Personalization", "Display", "Make it easier to read what's on your screen", there are three options. "Smaller", "Medium" and "Larger". If using "Larger", madVR will not switch to fullscreen exclusive mode. Selecting "Smaller" or "Medium" is OK, but not when using "Larger". I'm using "Larger" on my 50" TV (1920x1080) and it took a while before I found out this :-)
Ok, I'll see if I can reproduce that.
2. I have an ATI 4550 (512MB) in my HTPC. Will this graphic card be powerful enough to run madVR...?
It should be powerful enough if you're satisfied with maybe not being able to use the latest and most consuming algorithms etc.
leeperry
3rd January 2011, 18:15
Why didn't you simply use the madTestPatternSource shipping with madVR? :)
I wanted to test as much as possible as in real world conditions...going through CoreAVC CUDA and all.
With 8bit, the difference is almost not noticeable to the naked eye, without zooming in.
The diff is truly a night and day on my CRT(plugged in 30bit VGA), of course I would guess that this would change -for the worse- on a 6bit LCD. I haven't tried on my Darkchip3 DLP(12bit processing) yet, but I'd expect the same very visible improvement. It's sad that those cheapo LCD panels seem to dumb things down, like all those terribly blurry "Cleartype" fonts in Vista/7...this looks horrid on CRT/DLP :(
I would offer a Floyd Steinberg or similar dithering algorithm in madVR if it was technically possible, but the pixel shader architecture doesn't really allow it.
Oh yah, choosing the dither algorithm/strength would be really sweet! possibly using a built-in quick calibration helper...like a "which one looks better? 1/2/3" a few times, to choose the noise pattern and strength http://forum-images.hardware.fr/images/perso/neuf.gif
There's one thing to note, though: The best solution is always to maintain the highest possible bitdepth throughout the whole processing chain and do the dithering step only at the very end.[..]
Can you see the problem? All the steps are done in 8bit, so you're summing up rounding errors in every step. Just imagine you change brightness or contrast after SmoothL, and the whole nicely dithered SmoothL output will be damaged again. Or if you feed the SmoothL output into a 3dlut, the 3dlut output will need to be dithered once more. Or if you scale the SmoothL within madVR, again the output needs to be dithered. And adding two dithering operations on top of each other isn't the best solution.
Yes, you're entirely right...but the SmoothL/mVR gradients are really a night and day on my CRT...post-processing sharpening and so on SmoothL's output provides a much more natural looking picture. I fully understand that dithering should only be used at the very last stage, but you can see that this is not the case in the 48bit ProTools mixer: http://akmedia.digidesign.com/support/docs/48_Bit_Mixer_26688.pdf
http://www.pixelz.fr/1/f/1/e73fac6b827cc3b34ced921a07352.pnghttp://www.pixelz.fr/2/5/5/458244106ec3ddac658a19d36f841.png
All processing is done in 48bit, then dithered to 24bit, and sent to the TDM mixer "as is", then processed in 48bit again etc etc...there's so many values that the dithering "artifacts" hardly matter as I understand it.
Surely, SmoothL provides a very impressive PQ through LSF :eek:
You can see in my dither.rar (http://www.mediafire.com/download.php?mov7dj5pais1wa2) file that mVR's dithering is hardly visible on top of SmoothL's, but still makes up for a nice improvement :cool:
SmoothL: http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093t.jpg (http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png) / SmoothL+mVR: http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528ft.jpg (http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528f.png)
I don't think the strength has anything to do with it. It's Floyd Steinberg vs. random dithering. They look slightly different. My personal opinion is that the difference is very small, though
Did you try on CRT/DLP? HD movies are still mastered on CRT for a good reason IMHO. LCD is up to no good for proper video mastering/visualization..this CRT will remain the industry standard for many more years to come: http://www.sony.co.uk/biz/product/bvm/bvm-a14f5m/
This monitor is intended for the most critical picture evaluation in the high-end production and post-production environments.
Snowknight26
3rd January 2011, 19:03
JPGs for comparison. Tsk, tsk.
leeperry
3rd January 2011, 19:17
Not sure what you're referring to, but my comparisons are PNG:
http://www.pixelz.fr/6/8/f/474b5bf1d4bc40f5b71c9da491093.png
http://www.pixelz.fr/a/3/d/2cb115434ca8a69482516b826528f.png
madshi
3rd January 2011, 19:44
Oh yah, choosing the dither algorithm/strength would be really sweet! possibly using a built-in quick calibration helper...
Read again what I wrote. I think you missed half of what I said.
I fully understand that dithering should only be used at the very last stage, but you can see that this is not the case in the 48bit ProTools mixer
The noise floor on a 16bit audio track is so low that it's almost not audible. With 24bit audio the noise floor is 264x lower. So if dithering is applied multiple times it's not such a big problem at 264x lower than audible levels. Video 8bit processing is a whole different beast. I would say that video dithering noise with 8bit video is more noticeable than audio dithering noise with 16bit audio. So you can't really compare one thing to the other.
HD movies are still mastered on CRT for a good reason IMHO. LCD is up to no good for proper video mastering/visualization..this CRT will remain the industry standard for many more years to come
Your information is out of date, I think. According to my information, many studios are using a combination of CRTs, LCDs and plasma displays for mastering these days. LCDs are useful because they show compression artifacts much clearer than CRTs.
leeperry
3rd January 2011, 20:32
Read again what I wrote. I think you missed half of what I said.
Well, you said that it wouldn't be easily doable..which is too bad, maybe you'll find a way to overcome those limitations someday..that's all I meant.
The noise floor on a 16bit audio track is so low that it's almost not audible. With 24bit audio the noise floor is 264x lower. So if dithering is applied multiple times it's not such a big problem at 264x lower than audible levels. Video 8bit processing is a whole different beast. I would say that video dithering noise with 8bit video is more noticeable than audio dithering noise with 16bit audio. So you can't really compare one thing to the other.
Indeed, but it's usually interesting to compare audio and video dithering...and even though SmoothL works in 32fp internally and then dithers back later on, the PQ improvement on a CRT is *very* real...I hope you'll check out my test patterns on something else than a LCD someday.
16-235 SMPTE-C(the smallest gamut) might very well not contain as much genuine data as we'd think....less than 0-255 xvYCC(twice bigger than SMPTE-C) by a long shot.
Your information is out of date, I think. According to my information, many studios are using a combination of CRTs, LCDs and plasma displays for mastering these days. LCDs are useful because they show compression artifacts much clearer than CRTs.
Well, that's what the french ISF CEO and what the industry insiders are saying...surely LCD is improving, but most(if not all) BD's are still mastered on a SMPTE-C CRT..it's rather obvious when playing around w/ LUT's in mVR on a perfectly calibrated D65/2.4 projector. And even the best LCD's only output 1000:1 native CR apparently, good luck w/ that.
Anyway, I've made my point and you've said that Pixel Shaders couldn't output the same kind of dither as SmoothL uses, case closed http://forum-images.hardware.fr/images/perso/the%20bloodhound%20gang.gif
robpdotcom
3rd January 2011, 22:13
I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.
FWIW, this also happens with "Medium" text if I use 1280x720 resolution.
mark0077
3rd January 2011, 22:55
madshi, using your latest build 0.36, with "enable automatic fullscreen exclusive mode" enabled, and the two sub options to "show seek bar" and "delay switch to exclusive mode by 3 seconds" disabled. When in fullscreen exclusive mode, if I move the mouse down to the bottom of the screen, madvr goes out of exclusive mode, and of course soon afterwards goes back into it.
Is this a madvr bug or a mpc-hc bug? Its like as if the mpc-hc seekbar is still being selected / hovered over when I move the mouse down to the bottom of the screen.
yesgrey
4th January 2011, 00:06
From the log I can see that there's a 2 second delay everytime madVR starts up. But the delay doesn't seem to be caused by madVR. I just see a 2 second gap in the log with no explanation where it could be coming from.
Ok. I will try to see if I find where it comes from, but since this only happens with madVR it would be more likely to be its responsibility... with all the other renderers the response is immediate, but with madVR there is always some kind of delay. Sometimes is barely noticeable, but other times it completely stalls the media player for several seconds... I've quit completely using ZoomPlayer because it's even worse than with mpc-hc, and I really liked using ZP...
If it wasn't for its quality and for being the only option for using the 3DLUTs I would consider not using it, unfortunately that's not an option for me, so I've decided to accept its humours... but I would be a lot happier if we could solve this. ;)
madshi
4th January 2011, 00:22
madshi, using your latest build 0.36, with "enable automatic fullscreen exclusive mode" enabled, and the two sub options to "show seek bar" and "delay switch to exclusive mode by 3 seconds" disabled. When in fullscreen exclusive mode, if I move the mouse down to the bottom of the screen, madvr goes out of exclusive mode, and of course soon afterwards goes back into it.
Is this a madvr bug or a mpc-hc bug? Its like as if the mpc-hc seekbar is still being selected / hovered over when I move the mouse down to the bottom of the screen.
This is actually as intended. MPC HC doesn't know whether madVR is in exclusive mode or not. So it always tries to show its own seekbar. Whenver it does, madVR has to exit exclusive mode to make the MPC HC seekbar visible. Nothing wrong with that. As intended.
When you enable madVR's own seekbar, madVR hacks into the mouse messages to make MPC HC think that the mouse would never go lower than the middle of the screen. This way madVR manages to stop MPC HC from showing its own seekbar. madVR does this only if the madVR seekbar is enabled, though. Why would you want to have *both* the MPC HC *and* the madVR seekbar disabled? Doesn't make too much sense to me.
Ok. I will try to see if I find where it comes from, but since this only happens with madVR it would be more likely to be its responsibility... with all the other renderers the response is immediate, but with madVR there is always some kind of delay.
Well, from the logs I can't see anything. It doesn't appear to be madVR's fault. But who knows, the logs don't always tell everything. It's before the network initialization, in case you are tempted to ask, so the net init is definitely not at fault in your case.
mark0077
4th January 2011, 00:58
Thanks madshi, well I want one taskbar, either the mpc one or the madvr one. It doesn't matter to me.
Unfortunately
1) The madvr one doesn't work.... I primarily am watching blu-rays with multi m2ts files involved so some sort of workaround would be needed here between madvr and software players to allow its seekbar to work correctly.
and
2) I had set madvr to go to exclusive mode immediatly so of course when I attempt to use the mpc seekbar, as you described madvr will immediatly go back to exclusive mode.
I guess I'll have to reenable the madvr seekbar and just not use it until some potential workaround comes along in the future for multi m2ts blu-rays.
pankov
4th January 2011, 01:17
mark,
why don't you enable the 3 seconds delay?
As far as I know this delay is used only when going from Fullscreen windowed to Fullscreen exclusive. If you go from window to fullscreen it will go directly in Exclusive mode. It's the same when you start the playback directly in fullscreen. So in most cases you get immediate Exlusive mode, only when it's needed you get delay.
On both of my PCs (either NVidia or AMD video card) I have the problem that the mouse is automatically moved to the center of the screen when I go out of Exclusive mode and if I don't enable the 3 seconds delay I'll never be able to use the popup menu, but I guess you don't have such a problem.
mark0077
4th January 2011, 01:26
Well even with the 3 second delay, madvr seems to lose fullscreen exclusive mode when I hover down over the mpc menu (expected), but then immediately madVR is going into fullscreen exclusive, its not waiting 3 seconds, ie its not giving me a chance to use mpc-hcs seekbar. I have restarted mpc-hc after making this change but still no 3 second delay.
The time I went into the settings dialog however I got a "madVR instance didn't reply properly" message, first time I have seen it....
Yes I also have the problem where the right click on the screen when in exclusive mode, and when the 3 seconds delay isn't used, I can never use the right click menu. Can madVR listen for right clicks and always have some sort of delay even when the option for the delay is disabled? I suppose madVR could listen for right click events, not pass them onto mpc-hc (is this possible?), come out of exclusive mode, then send a right click event to mpc-hc. That way madvr comes out of exclusive mode AND the menu appears with one only right click as the user would expect.
iSunrise
4th January 2011, 01:31
Some more feedback for 0.36.
Can anybody confirm this? I've not seen it on my PC, I think. If anybody can reproduce this, a log would be helpful.
I could not reproduce it.
I woke up today and opened PotPlayer (internal source and decoding filters enabled, using haali, but no ffdshow) and played back a 1080p trailer (MOV, H264) and I paused it. After breakfast I came back (about 1 hour later) and clicked on play again. The trailer was still perfectly in-sync. A little bit later I did the same with an .AVI (XVID) and a .FLV (H264) and paused them for about 20 minutes and unpaused them. Both were perfectly in-sync, too.
This sounds to me like it may rather be MPC HC or ffdshow specific or itīs the source encoding that is at fault here. Thereīs always some encodings that are just awfully done.
hdboy
4th January 2011, 03:15
I'm curious: with version 0.35+, why does the screen flash so many times when opening and closing a video with MPC? With 0.34 it was a 2-3 times; now it's like 6.
I'm using FSE.
gliderzone
4th January 2011, 11:11
I use the "Larger" text setting as well, and it seems that madVR doesn't enter FSE mode (the madVR seek bar doesn't work and you don't get the "Exclusive" message), but it does.
Press CTRL-J to bring up the OSD, it will say there if you are in windowed or exclusive mode.
Thanks for your comment, I have checked the OSD but in my system, madVR never switches to FSE when using "Larger" text. I'm running Windows 7 in 1920x1080. Tried with both KMPlayer and MPC HC...
dansrfe
4th January 2011, 14:55
I'm using madVR v3.6 on Windows 7 x64 with the latest MPC-HC MSVC 2010 and latest ffdshow and I get substantial frame dropping if I pause a video and play it back again after more than 1-2 minutes. The only way to stop the frame dropping is to restart the file.
*Touche*
4th January 2011, 15:09
Try replacing all "flush & wait" settings with "flush" only. Does that help?
Flush & wait (sleep) was only on "after last render step". Changing it to flush didn't help. I've tried changing all to flush, but it was worse. The best performance by far is with all set to "flush & wait (loop)", but it's still a bit slower than windowed mode with default settings.
Not sure why you get problems with ReClock. Try cleaning up the Reclock timing database. That has helped some people in the past.
I've tried cleaning the database several times, but it didn't help. It's strange how everything is reported to be perfect, but the strange skipping comes up in a regular interval.
rmp459
4th January 2011, 15:37
I am coming to you friends here @ madVR because my question is mostly but not entirely related to using madVR as my renderer, however I am stumped and no one elsewhere seems to be able to point me in a new direction.
I just reformatted... Starting again one more time.
My issues is that I am trying to run in windowed mode w/ aero off and w/ reclock in mpc-hc, but no matter what I do or change... 1080p content has a tearing issue ~ 30-50 pixels from the bottoms of the screen whether I am just windowed or fullscreen windowed. This also only occurs when my HDTV is set to 23/24hz... which is unfortunately my goal... (hdtv does not support a 48 hz rate... i didnt really expect it to.)
When I go to 60hz or fullscreen exclusive, the tearing is gone, but in fsX, my rendering times are very high.
My other option which seems to work relatively well, was to leave aero on and have a script run each time a file launches to turn off the windows desktop manager services in order to "reset" the aero composition rate and get it to match each file. This works well, but last time i tried it, it felt like the clocks were wandering a bit w/ audio vs video and there is still an occasional stutter in the playback... (which i could live with if the sync looked right to me)
Ideally I want to get this tear gone, but no matter what I set the vsync in reclock to, it is in the same spot...it doesnt occur the entire time things are playing... just at intense scenes of a movie... panning... credits... it comes and goes..
anyone have any idea? could I also find a way to use reclock with fsX and turn off vsync in reclock but let it adjust the clocks for perfect match ?
thanks for any help... im losing my mind.. this is weeks now...
Im starting to think im never going to find a perfect solution... regardless of how much time i put into this...
(I am running mpc-hc as my player ffdshow for audio and subtitles. I have tried both the internal 264 decoder w/ mpc-hc and the one that is in ffdshow... both produce the same result w/ 1080 content @ 23/24hz)
mark0077
4th January 2011, 15:38
I've tried cleaning the database several times, but it didn't help. It's strange how everything is reported to be perfect, but the strange skipping comes up in a regular interval.
Well it may not be the same issue but I had very similar strange effects as you describe a few weeks back. My problem was madVR was detecting my displays refresh correctly, reclock was not. Reclock was detecting it as 24 when it was actually 23.976 or the other way around.
Just check what reclock detects as your display refresh rate vs madVR's stats because even the nvidia control panel I have found to show incorrect refresh rate recently. madVR was the only 1 of the 3 to be correct 100% of the time.
*Touche*
4th January 2011, 17:22
Well it may not be the same issue but I had very similar strange effects as you describe a few weeks back. My problem was madVR was detecting my displays refresh correctly, reclock was not. Reclock was detecting it as 24 when it was actually 23.976 or the other way around.
Just check what reclock detects as your display refresh rate vs madVR's stats because even the nvidia control panel I have found to show incorrect refresh rate recently. madVR was the only 1 of the 3 to be correct 100% of the time.
I've checked and ReClock reads the refresh rate correctly. One repeated frame every few minutes w/o ReClock is tolerable, but it would be nice if I could figure out where's the problem.
Unfortunately, it's my friends laptop+TV, so my testing time is limited and his patience too :)
mark0077
4th January 2011, 17:49
Well the only other two things I can think of are the fact that madVR reads the framerate of the video from the decoder which can be inaccurate if filters inbetween are changing its speed? Is this a possibility?
Otherwise, perhaps you could make sure reclock's vsync is off and let madVR's do the sync work? I hope you can figure it out.
*Touche*
4th January 2011, 18:21
As I've said, everything is reported properly, stats are great, values are great...it just doesn't work right :)
I've tried with turning ReClock's vsync control off too, no change.
iSunrise
4th January 2011, 19:09
I'm using madVR v3.6 on Windows 7 x64 with the latest MPC-HC MSVC 2010 and latest ffdshow and I get substantial frame dropping if I pause a video and play it back again after more than 1-2 minutes. The only way to stop the frame dropping is to restart the file.
I cannot reproduce this with Vista x64, with either using PotPlayer (no ffdshow) or MPC-HC and ffdshow. Neither the OSD nor the movie itself shows dropped frames (apart from the expected dropped frames because of a not perfectly in-sync display, that is).
Are you using reclock? If yes, does it also happen when reclock is disabled in your chain?
Razoola
4th January 2011, 19:09
I am coming to you friends here @ madVR because my question is mostly but not entirely related to using madVR as my renderer, however I am stumped and no one elsewhere seems to be able to point me in a new direction.
I just reformatted... Starting again one more time.
My issues is that I am trying to run in windowed mode w/ aero off and w/ reclock in mpc-hc, but no matter what I do or change... 1080p content has a tearing issue ~ 30-50 pixels from the bottoms of the screen whether I am just windowed or fullscreen windowed. This also only occurs when my HDTV is set to 23/24hz... which is unfortunately my goal... (hdtv does not support a 48 hz rate... i didnt really expect it to.)
When I go to 60hz or fullscreen exclusive, the tearing is gone, but in fsX, my rendering times are very high.
My other option which seems to work relatively well, was to leave aero on and have a script run each time a file launches to turn off the windows desktop manager services in order to "reset" the aero composition rate and get it to match each file. This works well, but last time i tried it, it felt like the clocks were wandering a bit w/ audio vs video and there is still an occasional stutter in the playback... (which i could live with if the sync looked right to me)
Ideally I want to get this tear gone, but no matter what I set the vsync in reclock to, it is in the same spot...it doesnt occur the entire time things are playing... just at intense scenes of a movie... panning... credits... it comes and goes..
anyone have any idea? could I also find a way to use reclock with fsX and turn off vsync in reclock but let it adjust the clocks for perfect match ?
thanks for any help... im losing my mind.. this is weeks now...
Im starting to think im never going to find a perfect solution... regardless of how much time i put into this...
(I am running mpc-hc as my player ffdshow for audio and subtitles. I have tried both the internal 264 decoder w/ mpc-hc and the one that is in ffdshow... both produce the same result w/ 1080 content @ 23/24hz)
I take it you have a nividia card? If so you are in the same situation as me currently. I can tell you the tearing you see is caused by the nvidia driver version you are using. I have to go back to 258.96 to remove that tear at the bottom of the screen in fs windowed mode. I have not yet tried the just released beta drivers from nvidia though to see if this is fixed.
rmp459
4th January 2011, 20:32
I take it you have a nividia card? If so you are in the same situation as me currently. I can tell you the tearing you see is caused by the nvidia driver version you are using. I have to go back to 258.96 to remove that tear at the bottom of the screen in fs windowed mode. I have not yet tried the just released beta drivers from nvidia though to see if this is fixed.
I do indeed. I have tried this with both my GTX 470 and my GT 220...
I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.
Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?
DigitalLF
5th January 2011, 00:19
MadShi: 0.36 is really stable for me... and i have ONLY tested this version with default settings on my setup... but 0.34, 0.33 was never stable for me... but i did not change anything in settings on any of versions ... all default. (0.34, 0.33, 0.34, 0.35, 0.36)
Plutotype
5th January 2011, 01:51
Hi all,
Im not sure if this will be ffdshow related bug, but I have a problem with correct show/hide timing on subtitles using ffdshow 3712. This problem occurs only with VC-1 video streams. The subtitles loaded via ffdshow simply flicker/blink when they show or hide at playback.
- MPC HC latest build
- madvr, outputting YV12 via ffdshow
- subtitles are external in srt format loaded via ffdshow
- win7 64bit, all filters 32bit including reclock 1.8.7.3
I have done tests on several videos ( m2ts format with mostly HD audio tracks ) and H.264/AVC and MPEG-2 videos are ok regarding this issue - subtitles play without any blinking. In FFDshow I have wmv9 as VC-1 decoder enabled.
This problem will be probably attached to the mpc-hc splitter because when I activate Haali, the problem disappears. Haali does not "see" some HD audio streams, so I can not use this splitter generally.
So the question is, what causes the blinking subtitles. Splitter, decoder or maybe madvr renderer?
Thanks
Plutotype
rmp459
5th January 2011, 01:56
I do indeed. I have tried this with both my GTX 470 and my GT 220...
I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.
Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?
To follow up. No more tearing at the bottom of the screen in windowed full screen mod with the new nvidia beta drivers.
However, i still get delayed video compared to audio when i go full screen. Same result In windowed or exclusive. Anyone have his happen before? And this doesnt uhappen with evr cus.
pie1394
5th January 2011, 02:03
I do indeed. I have tried this with both my GTX 470 and my GT 220...
I'm not using nvidia surround so im going to see what the deal is with drivers as well and see if I can fix this... if not its gonna be fsX for me i think...
I also see the beta drivers that were release today. I guess i will be giving them a shot when I get home... and if that fails... ill try 258.96 i guess... from the notes im not going to be losing much since i dont run SLI or play fallout new vegas haha.
Also, Does anyone here run SLI'd Nvidia cards? any issues with MadVR?
My setup is Win7 x64 & GTX260+ & Forceware 260.99...
To prevent the tearing issue for FILM type contents with madVR, the FSX mode is the only solution at p24 output signal. With p60 output signal at Window mode, it is less obvious, but still exists just at the place you mentioned. I remembered it was observed on my TV before.
Before madshi finishes the madVR embedded auto refresh rate changer for ver0.3x, I think Aero-off + MPC-HC auto refresh rate changer + madVR ver0.26 at FSX mode is the only most convenient solution to prevent tearing with various frame rate contents.
ps: My PDP TV supports 23.976, 24, 50, 59.94, 60 fps modes at 1920x1080 ...
dansrfe
5th January 2011, 02:09
I cannot reproduce this with Vista x64, with either using PotPlayer (no ffdshow) or MPC-HC and ffdshow. Neither the OSD nor the movie itself shows dropped frames (apart from the expected dropped frames because of a not perfectly in-sync display, that is).
Are you using reclock? If yes, does it also happen when reclock is disabled in your chain?
I'm not using reclock at all. I think Windows 7 x64 might react a little differently.
rmp459
5th January 2011, 02:27
My setup is Win7 x64 & GTX260+ & Forceware 260.99...
To prevent the tearing issue for FILM type contents with madVR, the FSX mode is the only solution at p24 output signal. With p60 output signal at Window mode, it is less obvious, but still exists just at the place you mentioned. I remembered it was observed on my TV before.
Before madshi finishes the madVR embedded auto refresh rate changer for ver0.3x, I think Aero-off + MPC-HC auto refresh rate changer + madVR ver0.26 at FSX mode is the only most convenient solution to prevent tearing with various frame rate contents.
ps: My PDP TV supports 23.976, 24, 50, 59.94, 60 fps modes at 1920x1080 ...
The new 265 beta drivers fixed the tear for me, but with mad vr my video comes in noticeably behind my audio and it gets even worse at full screen. This happens in both fsx and fsw.
I just spent a good 20 mins testing with evr custom and other stock renderers and i dont really have the problem at all. Its so frustrating. Over 100 hours into this and a dozen reformats and im still having problems show up.
*Touche*
5th January 2011, 11:01
To follow up. No more tearing at the bottom of the screen in windowed full screen mod with the new nvidia beta drivers.
However, i still get delayed video compared to audio when i go full screen. Same result In windowed or exclusive. Anyone have his happen before? And this doesnt uhappen with evr cus.
Interesting. I've noticed a slight delay in video on my friends setup, a laptop with Nvidia 210M. It is very small, but it's there. I found it very strange because I would have expected the sound to be little delayed since it was going via hdmi from the laptop to TV and then via optical to the receiver, but never for it to be early.
Don't know the exact version of drivers, but they were downloaded from the official site two weeks ago. Do you know what version doesn't have this problem?
Mark_A_W
5th January 2011, 12:24
Just fix delays with ffdshow - just add the ffdshow video decoder in the path and tweak the delay in "Queue & misc".
Delays are nothing to worry about, just fix it.
Mark_A_W
5th January 2011, 12:28
Oh, and some feedback:
I've had nothing but trouble with the last few versions (running fullscreen windowed, as exclusive won't work on an interlaced res). I'd even reverted to v0.18.
But 0.36 is rock solid. It "feels smooth" again. I'm using the default flush settings.
Thanks madshi!
rmp459
5th January 2011, 13:28
Interesting. I've noticed a slight delay in video on my friends setup, a laptop with Nvidia 210M. It is very small, but it's there. I found it very strange because I would have expected the sound to be little delayed since it was going via hdmi from the laptop to TV and then via optical to the receiver, but never for it to be early.
Don't know the exact version of drivers, but they were downloaded from the official site two weeks ago. Do you know what version doesn't have this problem?
No idea which version this didnt occur on... I too run HDMI to my TV and coax spdif to my AVR...
Also its the same that the delay is EXTREMELY small, but with 1080 content i still see the difference between EVR and MadVR... its like the audio/video sync wanders in the XXms range and the sound comes in just before the lips move...
Id love to use fullscreen exclusive if I could, but I get rendering times over 40-50ms regardless of which GPU i use (have a 470 and a gt 220) and the render queue drops... some flush changes seemed to help a bit but I couldnt iron it out with the audio at the same time... guess i just have bad luck.
worst part about it is how perfect it works on my 5 year old laptop w/ a NVS 140m gpu.
Just fix delays with ffdshow - just add the ffdshow video decoder in the path and tweak the delay in "Queue & misc".
Delays are nothing to worry about, just fix it.
I would, but it doesnt seem to be the same with 720 vs 1080 content and it seems to wander... some scenes seem decent... others seem off up to 100ms or so.
I've tried two different sound devices and the same result... there has to be something common that im missing... tried different audio and video decoders... Seems to vanish when I use EVR instead of madvr tho... which makes me 99% sure its something with how i have the renderer working... i just dont know what i could have possibly screwed up with this happened across like 3 fresh installs.
yesgrey
5th January 2011, 23:22
Ok. I will try to see if I find where it comes from
Well, from the logs I can't see anything. It doesn't appear to be madVR's fault. But who knows, the logs don't always tell everything. It's before the network initialization, in case you are tempted to ask, so the net init is definitely not at fault in your case.
It seems to be related with the Release version. The Debug version rarely stalls, but the release version is very bad. Would it be a compiler bug? Could you try different optimization settings or a different compiler?
dansrfe
6th January 2011, 04:39
Still having a stutter/frame drops on return from pause after 5 mins or so. No way to fix it but restart the file. Don't know what to do :(
EDIT: Never mind, I just switched to Exclusive mode and everything is smoooooooth. :)
On a side note, what exactly is the down side to using exclusive mode besides all the gui related stuff?
Razoola
6th January 2011, 09:52
Id love to use fullscreen exclusive if I could, but I get rendering times over 40-50ms regardless of which GPU i use (have a 470 and a gt 220) and the render queue drops... some flush changes seemed to help a bit but I couldnt iron it out with the audio at the same time... guess i just have bad luck.
Don't worry, you are not alone with the poor rendering times in full screen exclusive mode, I have the same issue. I have a feeling this will be fixed once madshi completes exclusive mode implementation.
Its intresting, like you I have an SLI setup (gtx 295 and gt240).
rmp459
6th January 2011, 15:33
Don't worry, you are not alone with the poor rendering times in full screen exclusive mode, I have the same issue. I have a feeling this will be fixed once madshi completes exclusive mode implementation.
Its intresting, like you I have an SLI setup (gtx 295 and gt240).
TL;DR - Solved my sound problems and sync issues and to anyone who experiences tearing with aero off using nvidia cards, please uninstall your current drivers, reboot, run driver sweeper 2.8.0 (current version) and then install the newest Nvidia drivers (GeForce/ION Release 265 BETA 266.35 January 4, 2011) They fixed some serious tearing problems.
SLI would require two of the same card and having SLI enabled? (Perhaps just a terminology mix up?)
By SLI do you just mean that you are running two cards independently?
(also, that GTX 295 has two GPUs onboard one PCB anyways, which I am sure that you know.)
Regardless,
Good news for once. I put my Xonar STX back in and used some guys "Unified Xonar Drivers" which are like Asus's sound drivers done correctly by some random guy in his free time. I had to enable test mode and then manually sign the "cmudaxp.sys" system file, but it has much lower latency and is rock solid stable so far (these cards are known to bsod on 64bit OS)
Guess I won't be selling this card... haha
After that I rigged up a config of everything using ffdshow decoders for audio and video, with madvr and reclock. But! I want to do bitstream so I am simply using reclock for an easy way to use wasapi exclusive for my sound output for the time being until I find a better way to do it. Also just letting madvr handle its own vsync.. (which results in No tearing w/ the new Nvidia Beta Drivers (GeForce/ION Release 265 BETA 266.35 January 4, 2011)) Seems to be playing back sync'd perfect w/ no major stutters or lags @ 24hz now...
Razoola
6th January 2011, 18:02
SLI would require two of the same card and having SLI enabled? (Perhaps just a terminology mix up?)
By SLI do you just mean that you are running two cards independently?
(also, that GTX 295 has two GPUs onboard one PCB anyways, which I am sure that you know.)
By SLI I was refering to the gtx295. Like you say its basically 2 gpus on one pcb (though I have the older two pcb version of the card).
Like you the latest drivers solved the tearing at the bottom of the screen in windowed mode for me also.
Plutotype
7th January 2011, 21:31
Hi all,
Im not sure if this will be ffdshow related bug, but I have a problem with correct show/hide timing on subtitles using ffdshow 3712. This problem occurs only with VC-1 video streams. The subtitles loaded via ffdshow simply flicker/blink when they show or hide at playback.
- MPC HC latest build
- madvr, outputting YV12 via ffdshow
- subtitles are external in srt format loaded via ffdshow
- win7 64bit, all filters 32bit including reclock 1.8.7.3
I have done tests on several videos ( m2ts format with mostly HD audio tracks ) and H.264/AVC and MPEG-2 videos are ok regarding this issue - subtitles play without any blinking. In FFDshow I have wmv9 as VC-1 decoder enabled.
This problem will be probably attached to the mpc-hc splitter because when I activate Haali, the problem disappears. Haali does not "see" some HD audio streams, so I can not use this splitter generally.
So the question is, what causes the blinking subtitles. Splitter, decoder or maybe madvr renderer?
Thanks
Plutotype
Just to let you all know, that after invidual communication with madshi, clsid and tetsuo55 we came to an conclusion, that the wrong timed appearing and disappearing of ffdshow subtitles in madvr setup in MPC-HC has its reason in one of the old and still non-resolved VC-1 bugs described already here:
http://c-a376e655.024-44-73746f50.cust.bredbandsbolaget.se/showthread.php?p=1236128#post1236128
The key bug is in the MPC HC m2ts splitter, not handling VC-1 correctly, producing garbled timestamps.The subtitle flickering is probably a follow up problem. Most probably the subtitle renderer is confused by the garbled timestamps.
I have tried the newcairels LAVFSplitter and although not all VC-1 videos did work well ( will report this on the thread later ), the timing of the subtitles using VC-1 videos was correct.
Pluto
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.