Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
4th June 2013, 18:49 | #18981 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
madVR v0.86.2 released
http://madshi.net/madVR.zip Code:
* fixed: refresh rate changing didn't always work correctly in Windows 8 * fixed: MPC-BE title bar didn't handle unicode characters correctly * fixed: IVideoWindow::putBorderColor() had swapped colors (RGB -> BGR) * fixed: #18: decoder queue sometimes exceeded limits * fixed: #19: blank screenshots when Smooth Motion FRC is turned on * fixed: #23: video didn't follow overlay window position when paused * fixed: #34: smooth motion FRC was sometimes incorrectly turned on * fixed: #35: framerate tag was not working * fixed: #37: when no video duration was known, seekbar was not shown * fixed: #42: memory leak with certain OSD elements * fixed: #44: GraphStudioNext "Performance Test" Crash * fixed: #46: xy-vsfilter: 3DLUT was not applied to frames with subtitles * fixed: #47: xy-vsfilter: subtitles weren't rerendered after scaling change * fixed: #48: xy-vsfilter: incorrect positioning after downscaling * fixed: #49: xy-vsfilter: incorrect PGS subtitle positions * fixed: #50: xy-vsfilter: smooth motion FRC caused subtitles flicker * fixed: #51: settings dialog now mentions both ReClock and VideoClock * fixed: #52: xy-vsfilter: incorrect ASS subtitle positions * fixed: #55: FSE seek bar resulted in inaccurate seeking for DVDs * fixed: #60: all kinds of artifacts with smooth motion FRC * fixed: #62: crash when external 3dlut file with long filename was missing * fixed: #65: film refresh rate was used with dxva decoding -> deinterlacing * fixed: #66: Cineform decoder v210 (10-bit 4:2:2) corruption * smooth motion FRC should be back to v0.86.0 performance levels * increased max CPU queue size to 128 frames * added support for DCI-P3 and BT.2020 primaries and BT.2020 matrix * added support for "matrix=2020" and "primaries=2020|DCI" tags * added resolution based auto detection for BT.2020 (UHD) and DCI-P3 * added explicit detection for non PS3.0 capable GPUs * added IMadVRInfo interface which makes all sorts of info available * added a couple workarounds for weird crashes that were reported Please test and report whether the Smooth Motion FRC related bugs have been fixed in this build. Btw, Smooth Motion FRC performance should hopefully be back up to v0.86.0 levels (which was faster than v0.86.1). I hope that this performance improvement didn't bring back problems. Let me know... |
4th June 2013, 18:59 | #18982 | Link |
Registered User
Join Date: Dec 2012
Posts: 5
|
lav filters/madvr!
Hi madshi,
congratz on the new version that u hav JUST released. Looking forward to using it very soon. btw, i'm a newbie so i'm going to ask the following: what i want to know is, what exact options should i choose within LAV video with regards to the following to get the possible image: > (hardware acceleration) -> hardware decoder to use: none, nvidia cuvid, intel quicksync, DXVA2 (native), or DXVA2 (copy-back) ? & why > RGB Output Levels: TV, PC, or UNTOUCHED ? & why > Dithering Mode: Ordered or Random ? & why > there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options? i also wanted to know: i have a 2nd gen I7 [2670] processor & 1GB nvidia GT 525m... all within a beautiful dell xps l502x (WISH i went for the model with 2GB GT 540m ) how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card? the ONLY thing that should use the nvidia card is MadVR, but how can i exclusively make sure that the nvidia card isn't spending it's power on other decoding? i ONLY want the nvidia card for MadVR & NOTHING else, but can this setup be done where one can choose what processes what etc. thanks madshi!!! looking forward to your guidance. |
4th June 2013, 19:40 | #18984 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
I have also noticed another issue, that may not be madVR's fault. In JRiver Media Center, if you have their display mode switcher disabled, stopping playback without exiting fullscreen view first, does not attempt to restore the display mode at all. (so stopping a 24Hz video leaves my display at 24Hz) Seems like a good release otherwise. I appreciate the BT.2020 support being ready for when 4K content is (largely) available. EDIT: And I'm quite sure that you are aware of it, but using a decoder queue size of 128 takes rather a long time for the image to update when switching between fullscreen and windowed modes, even with "delay playback start until render queue is full" disabled. Last edited by 6233638; 4th June 2013 at 19:48. |
|
4th June 2013, 19:54 | #18985 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
Quote:
(hardware acceleration): It sounds like you want "none" to me. This is what I use as well, all the other options use the GPU. The "hardware" doing the acceleration is on the GPU. RGB Output Levels: Untouched, leave converting color spaces to MadVR. Dithering Mode: Random unless you plan to re-encode the output. Random is visually higher quality but it does not encode as well. You can turn on Yadif in LAV for software deinterlacing, I use video mode for real interlaced video (30i in my case). All you need to do in LAV to keep the GPU free is to use "none" for hardware acceleration and don't use any shader scripts in MPC-HC. |
|
4th June 2013, 19:57 | #18986 | Link | |
Registered User
Join Date: Jan 2007
Posts: 530
|
Quote:
I'm on Win7 Ult, however. Curious what happens when you close MC. |
|
4th June 2013, 19:59 | #18987 | Link |
Registered User
Join Date: May 2013
Posts: 10
|
Thank you madshi !
Just tried out the 128 CPU queue - and yes it works just like I hoped it would ! Guess I can still count on my PC for this video . First 4 heavy fragments play like there never have been any stuttering on them. The 5-th fragment, which is the longest (23 secs), has some stuttering at the end (decoder queue empty). I've noticed that RAM usage per decoded frame is lower than I expected (6.5 MB) which leaves me with 1 GB free RAM, so if you ever gonna be in the mood to return to this feature, please add some more ticks after 128 (btw I like your solution with 56,64,96,128), like 192, 256. I understand that it's a bit awkward workaround for a slow CPU, but who needs RAM for smth else when watching HD movies anyway . Good job on update. |
4th June 2013, 20:08 | #18988 | Link | |
Registered User
Join Date: Apr 2009
Posts: 1,019
|
Quote:
Last edited by 6233638; 4th June 2013 at 20:17. |
|
4th June 2013, 20:23 | #18989 | Link | |
Registered User
Join Date: Jan 2008
Posts: 589
|
Quote:
Contrast this with the traditional situation where you have a video output and an analog sound card output: in this case you're dealing with the video (refresh rate) clock and the audio (sample rate) clock, which won't be perfectly in sync. In other words, instead of sending 2000 audio samples during a vsync interval (assuming 24p and 48kHz), sometimes you'll send 1998 samples, or 2002 samples (or something else), in other words the two clocks will deviate from each other, and that's why you can't prevent frame drops (unless you use ReClock and/or FRC of course). If instead the video output is also taking care of sending the audio, then the issue goes away completely: one component (the GPU) has control over everything, so it just has to make sure it uses the same clock for everything and just send the correct, constant amount of samples each time. In the case of 24p and 48kHz, it just knows it has to send 2000 samples between each frame, because 48000 / 24 = 2000. That's it. It's that simple. There's no clock deviation, because the audio is now slaved to the vsync. At least that's the theory. In practice we're still seeing clock deviation when playing both audio and video over HDMI, which, I must say, puzzles me. That would mean that GPU manufacturers are using two clocks for video and audio, which doesn't make any sense because that's actually harder than just doing the right thing and using one single clock. Last edited by e-t172; 4th June 2013 at 20:29. |
|
4th June 2013, 20:50 | #18990 | Link |
Registered User
Join Date: Jul 2011
Posts: 57
|
Black screen
Madshi,
any idea why I get a black screen when trying to play some files? If I switch to exclusive mode it says the refresh rate is 0 Hz. Ctrl-J in windowed mode doesn't display... I've had this problem for a long time, think it might have appeared when switching to Win8. My laptop display is capable of 60/120Hz. Using AMD graphics and I've tried resetting all settings to default. You've looked at a debug log once but couldn't find anything, could the 0 Hz thing be a clue? Grateful for any help... |
4th June 2013, 21:27 | #18991 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...
|
4th June 2013, 21:34 | #18992 | Link | |
Registered User
Join Date: Jul 2011
Posts: 57
|
Quote:
|
|
4th June 2013, 21:37 | #18993 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
EVR has a totally different presentation logic, it doesn't depend on vsync scanline information.
Not sure why it only occurs with specific video files. Makes no sense to me, unless you're using DXVA decoding and/or DXVA deinterlacing? Try with software decoding and try with deinterlacing turned off. But really, I simply don't have enough information to do anything about this... |
4th June 2013, 22:09 | #18994 | Link | |
Registered User
Join Date: Apr 2013
Posts: 6
|
Quote:
I'm not actually sure how to prevent my GPU from clocking down, so if anyone could tell me I would appreciate it. I've included this screenshot here taken at the end of an hour long video for you to have a look at if that is any help? |
|
4th June 2013, 23:03 | #18996 | Link | |
Registered User
Join Date: Apr 2012
Posts: 169
|
The new version works flawlessly so far, and I can now take screenshots without having to disable smooth motion, thanks!
A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime? Quote:
|
|
4th June 2013, 23:07 | #18997 | Link |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
It's helpful to layer & stagger even different types of CPU queues in my experience. With the first/top queue in a display chain being the largest, while the ones which follow being progressively smaller but with higher CPU thread priority than the prior queues in an attempt to ensure they stay full in real-time under heavy load. The logic is that the largest fast-filling queue have enough of a buffer to prevent the slower-filling queues below from emptying below 100% full, if you temporarily become bottlenecked.
Though my main concern that I thought you'd catch on to, was cases where you need to re-request and re-alphablend your entire subtitle queue instantly because of that change you made in 0.86.2 to decrease update delay on resolution change. I already saw this as barely acceptable with a CPU queue of 24. But now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill, which could take a couple seconds if something computationally heavy is being displayed for the entire queue size. It would only be worse with slower CPUs. With a smaller queue, this effect would be minimized or eliminated. If you don't want to separate the CPU and Subtitle queues, maybe you should consider expanding the "delay playback" option to wait for subtitle queue to be completely full for "playback start", "seek", and "window resizing". IMHO, you need to make one change or the other, otherwise user experience will suffer with large CPU queue + Subtitle queue size. Last edited by cyberbeing; 5th June 2013 at 08:00. |
5th June 2013, 00:15 | #18998 | Link |
Registered User
Join Date: Feb 2004
Posts: 399
|
Hi madshi,
A quick bug report (not due to this new build, as I tested with 0.86.1): madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up. A sample file: here. In the exact same graph, replacing madvr by the VMRs or EVR solves the issue. Unrelatedly, now on to test 0.86.2, thanks for this new build! Edit: same bug with 0.86.2.
__________________
XP SP3 / Geforce 8500 / Zoom Player Last edited by TheShadowRunner; 5th June 2013 at 01:07. |
5th June 2013, 00:25 | #18999 | Link | |
Registered User
Join Date: Jun 2012
Posts: 54
|
Quote:
|
|
5th June 2013, 02:08 | #19000 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
nice, for the new build!
but if PS scripts are limited to TV range in MPC by design, then how come this script meant to show any pixel being BTB even works and I guess PS scripts applied on 0-255 source files(FRAPS for instance) will be a no-go as well |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
|
|