View Full Version : madVR - high quality video renderer (GPU assisted)
cyberbeing
16th November 2011, 15:57
Disabling Inverse Telecine in the NVIDIA Control Panel can result in artifacting on Telecined discs, if anything it might do full deinterlacing instead of just weaving the fields back together properly, which could result in an image degradation.
As always however, trust your eyes over anything else. :)
I'll keep my eye out for artifacts when I test telecined DVD content with a pattern that DXVA can actually detect properly.
For these 1440x1080i30 MPEG2-TS files, inverse telecine never works unless I force the DScaler mod to IVTC in software. The slowness with that NVCPL setting enabled on such files where inverse telecine is broken is a bit of a concern though. It's not something practical to enable and disable all the time even if it does benefit DVDs. madVR deinterlacing may just be a lost cause on this ancient GPU, even if it does sort-of barely work in a pinch.
iSeries
16th November 2011, 16:01
The splitter (or decoder??) is definitely producing bad timestamps. It is possible, though, that some older madVR versions handled the problem better than the latest builds. I recently did a change in this area, which may have made things worse for you. I'd like to debug that. Can you please create a log with v0.79? I know you already created one with v0.78, but it didn't contain enough information. I've added more logging to v0.79, so that should help.
Anyway, I still recommend trying to figure out where the bad timestamps are coming from. It would be better to have that problem fixed, too, instead of relying on madVR to work around it somehow.
Hi Madshi,
Before I upload another log, could the problem be a muxing problem? I have been using EasyBD - I just remuxed one using tsMuxer and hey presto, index.bdmv plays perfectly.
Still not sure why playing the m2ts directly plays smoothly whatever though?
madshi
16th November 2011, 16:05
I've noticed that using Dscalers reference idct results in a lot sharper and detailed picture while the ones in ffmpeg result in a much softer picture.
Can you please post screenshots that show this difference? Ideally also a small video sample? Thanks!
You've mentioned this before about PCIe RAM. What exactly is PCIe RAM and where is it being allocated, as it certainly doesn't seem to be going into System RAM or GPU RAM?
Microsoft mentions it here:
http://msdn.microsoft.com/en-us/library/bb172584%28v=VS.85%29.aspx
It's called "AGP memory" there, but we're using PCIe instead of AGP these days. So I've now called it "PCIe RAM". Here's a good description I found of what it exactly is:
> AGP memory is just a chunk of regular system memory
> -- the memory on the motherboard -- that's given
> special treatment. It's marked as WC (write-combining)
> by the CPU which allows for fast writes but slow reads.
> It's also mapped by the AGP GART ("Graphics Address
> Remapping Table"), which means that the video card
> can read directly from it relatively quickly. But not as
> quickly as local video memory.
> It's basically a compromise between regular system
> memory and local video memory. Because the CPU can
> write to it quickly and the GPU can read from it
> relatively quickly, it's a natural home for
> D3DUSAGE_DYNAMIC resources.
Assuming madVR is reporting GPU + PCIe RAM, is there any reason that combined number should be kept below GPU RAM capacity?
Nope. I didn't think of AGP/PCIe memory at all, when implementing that RAM consumption stuff in v0.79. I'll try to revise the logic to only count true GPU RAM usage and to disregard PCIe memory. That should help getting the madVR reported numbers nearer to what the other tools are reporting.
The only thing that counts is GPU RAM. Ok, I don't know if PCIe memory is limited, too. Maybe it is, I don't think it's specified anywhere. So we can only make sure that GPU RAM is not over used.
This also has me curious if madVR in any way confirms that 16bit/32bit FP textures are being stored properly by the GPU?
What makes you think they would not be properly stored? Never heard yet of drivers refusing the allocate the exact format I'm asking them for.
It doesn't crash now which is a success, but I still need to set all scaling to Bilinear and disable the 3DLUT for it to be usable without delayed/dropped frames on 1440x1080i30 16:9 video.
Could you add an option under Trade Quality for Performance for something like 'Use Bilinear and Shaders Only when Deinterlacing or 60fps+ framerates' to temporarily set these options when deinterlacing is active and/or just high framerate content in general? That's the only practical way I could see to keep deinterlacing enabled in madVR.
I'm planning to implement some kind of profiles some time in the future. For now I don't want to make the settings dialogs overly complicated by making some of the options only apply to this or that. What you're asking does make some sense. But next thing on your list would then be to also switch to Bilinear with native 60p content. So the proper solution will be something else, sometime in the future. For now you'll have to live with the way things are.
Another thing I note is performance is much much slower (3-6ms deint vs 0.15-0.25ms deint) if Inverse Telecine enabled in the NVCPL. Since madVR doesn't seem to support decimation like VMR (?)
Huh? DXVA2 itself does not support decimation. Neither VMR, nor EVR nor madVR can do it. Don't be confused by soft-telecined content, which decoders output untouched (weaved). Such content may look like decimated, but it's not really.
I guess everybody should disable that setting? No change in quality as far as I can tell using madVR, just slower.
It all depends on the content. With native video content, the IVTC option will do nothing but waste GPU power. With soft-telecined movie content, same. But with hard-telecined movie content, the IVTC option should definitely improve image quality. So I wouldn't turn it off.
As for queue sizes for deinterlacing
Absolute minimum: 8CPU/6GPU (below this results in massive dropped frames)
Absolute maximum: 32CPU/24GPU
Requirement 1: Inverse Telecine is disabled in NVCPL
Requirement 2: CPU Queue is at least +2 greater than GPU queue (in order to keep the CPU queue fluctuations above GPU queues)
Interesting. So you can actually use 32CPU/24GPU? That's probably with SD content, though?
madshi
16th November 2011, 16:20
Basically after upscaling to a certain resolution the queues progressively start to fill up less and less until it's at 0-2 like 400 horizontal pixels before I can hit fullscreen 1920 horizontal resolution. I'm guessing I have to get a faster GPU to fix this or is there hope in me waiting for more speed improvements in DXVA2 implementation of madVR?
This does sound like your GPU is running out of steam. There's not much hope that the madVR DXVA2 implementation is going to get any faster. It's now roughly the same speed as nevcairiel's CUVID implementation, so I don't think madVR is wasting any performance, anymore.
Also I have noticed that madVR is still not accurately detecting if the input video needs to be deinterlaced or not. I just played a 25fps PAL VOB and it showed that deinterlacing was on. I'm guessing that this has to do with incorrect flag information in the VOB.
What makes you think that 25fps PAL does not need to be deinterlaced? It all depends. Some PAL DVDs need to be "deinterlaced" (IVTCed), some don't. Depends on how they were encoded. madVR's deinterlacer gets active if the decoder says so.
Also, the gpu ram usage section in the OSD seems to be a bit off or something else is happeneing with my GPU drivers. When I fill up all the queues on a 1080p file or something large it shows 1068/512. My card is a 1GB card however I'm used to seeing it say 512MB everywhere (e.g. in the driver control panel, windows display information etc). What does this mean?
madVR reads the GPU RAM size (in your case "512") from the registry. It's the same source of information used by the OS' control panel to show the GPU RAM size. If that's wrong, it's a bug in the GPU driver installer.
The DXVA2 DDI API requires Windows Vista and a WDM display driver, however you're not calling the DDI directly, you call the Direct3D9 interfaces.
http://msdn.microsoft.com/en-us/library/windows/desktop/cc307941%28v=vs.85%29.aspx
"If the graphics drivers uses the older Windows XP Display Driver Model (XPDM), DXVA 2 API calls are converted to DXVA 1 DDI calls. "
So, while XP doesn't support DXVA2 natively, if you install the .net framework 3 or 4 (not sure which version), there will be an emulation layer in place that can convert DXVA2 API calls to DXVA1 hardware calls.
What you say makes a lot of sense and I'm sure it's true. Still, I consider that website to be incorrect. It only speaks about Vista and never mentions that any of DXVA2 would ever work on XP. The only time they mention XP is when they talk about using XP-style drivers in Vista. But then, Microsoft rarely ever mentions that EVR is now available in XP, too. So the whole MS documentation has not been updated about the availability of EVR/DXVA2 in XP.
Before I upload another log, could the problem be a muxing problem? I have been using EasyBD - I just remuxed one using tsMuxer and hey presto, index.bdmv plays perfectly.
Yes, it could. Would still like to get a log, though. And maybe a sample which shows the problem?
Still not sure why playing the m2ts directly plays smoothly whatever though?
I've no idea.
nevcairiel
16th November 2011, 16:40
So the whole MS documentation has not been updated about the availability of EVR/DXVA2 in XP.
I think its more of a mistake/unwanted side-effect then an actual feature. :)
LigH
16th November 2011, 16:41
Regarding AGP/PCIe RAM: Device memory, mapped into the CPU address space, was already available e.g. as VESA VBE Linear Framebuffer Adressing in Protected Mode under DOS... :D
cyberbeing
16th November 2011, 16:42
What makes you think they would not be properly stored? Never heard yet of drivers refusing the allocate the exact format I'm asking them for.
That if I multiply 5.9MB 1920x1080 RGB textures by the number of queues it works out almost exactly to the reported GPU RAM usage in GPU-Z... If this is actually an issue, it's always been an issue in madVR since the earliest versions, so hopefully it's just a coincidence.
Huh? DXVA2 itself does not support decimation. Neither VMR, nor EVR nor madVR can do it. Don't be confused by soft-telecined content, which decoders output untouched (weaved). Such content may look like decimated, but it's not really.
It all depends on the content. With native video content, the IVTC option will do nothing but waste GPU power. With soft-telecined movie content, same. But with hard-telecined movie content, the IVTC option should definitely improve image quality. So I wouldn't turn it off.
So when I playback back a DVD that the NVIDIA PureVideo MPEG2 decoder (http://www.nvidia.com/object/purevideo_overview.html) dynamically switches between 23.976fps display rate and 29.97fps display rate or just stable 23.976fps, it's not actually decimated but rather always soft-telecined? So basically any 30i content which DXVA deinterlacing doesn't display at 23.976 is hard-telecined? Does madVR currently support displaying 30i soft-telecined DVDs @ 23.976fps using DVXA2 deinterlacing?
I watch so little interlaced content normally. Does someone have an example of what a hard-telecine artifact would look like when not using the Inverse Telecine setting in the NVCPL with madVR deinterlacing?
Interesting. So you can actually use 32CPU/24GPU? That's probably with SD content, though?
No, that's with 1920x1080 HD content.
nevcairiel
16th November 2011, 16:47
Does madVR currently support displaying 30i soft-telecined DVDs @ 23.976fps using DVXA2 deinterlacing?
"Soft-Telecined" is just 23.976 progressive video which has some extra flags that instruct the decoder/renderer to repeat fields to actually make it 30fps, if you just ignore those flags its (nearly) perfect 23.976 content (maybe with a bit odd timestamps, but should play smoothly, at least at 24p screen refresh, at 48 or 72Hz, it might show issues)
andyvt
16th November 2011, 16:55
I think its more of a mistake/unwanted side-effect then an actual feature. :)
WPF uses the EVR to draw its forms. I'm not sure use for other purposes is officially supported (which is probably why the docs haven't been updated).
Andy o
16th November 2011, 17:03
It's not a question of easy or not. Changing this would indeed be easy. The question for me is whether it makes generally sense to deinterlace 1080i60 content if the GPU outputs 1080i60, anyway. Maybe it does make sense, maybe not. I'm not 100% sure. Any more opinions on that?
I think generally, it won't affect people either way, since you'd have to manually type in the "29i" tag on the file name to get this behavior. Particularly, it will let me do what I do with the Pioneer TV and it might help others with similar processors/TVs.
You're right, that wouldn't work. So it probably makes no sense to use either "24p" or "48i" tags, unless the content is soft-telecined. In the long run I may implement decimating, but it will be difficult to do on the GPU. I'll probably have to use CUDA or OpenCL, and unfortunately ATI doesn't offer Direct3D9 <-> OpenCL interopability, so I'm not sure if it will be possible at all. There may be a different solution to remove the 3:2 judder, without decimating. But let's talk about that later...The 24p tag would still work for 29i content if I switch to NV and CUVID decoding/deinterlacing again, so thanks anyway.
iSeries
16th November 2011, 17:25
Hi Madshi,
Here are 3 log files, 1 is playback of index.bdmv created by tsMuxer, 1 is playback of index.bdmv created by EasyBD, the other is playing m2ts directly created by EasyBD:
http://www.mediafire.com/?ufcwg42ir9h57wb
http://www.mediafire.com/?3r5tm7cj11de3zx
http://www.mediafire.com/?a6401atf29q08mm
dansrfe
16th November 2011, 17:27
The 25fps PAL VOB that I was referring to seems to be progressive to my eyes but here is the DGIndex info for the vob:
http://img204.imageshack.us/img204/7173/unledsic.png
How does madVR know whether to bob/restore an ntsc source from 29.970 to 25 or to bob/deinterlace incorrectly mastered 25 to 23.976.
PS: The minimize/speeedup problem seems to be solved now.
Anima123
16th November 2011, 17:36
Originally Posted by Anima123 View Post
Madshi, could you please add a force deinterlace option with the Ctrl+Alt+Shift D shortcut in case the source doesn't report the interlace status correctly?
Not sure what you mean? If you press Ctrl+Alt+Shift+D twice, you can force deinterlacing on. Isn't that what you want?
Yeah. Or maybe add an option "Don't respect source interlace information" to let press Ctrl+Alt+Shift+D to switch deinterlacing on or off.
madshi
16th November 2011, 17:40
So when I playback back a DVD that the NVIDIA PureVideo MPEG2 decoder (http://www.nvidia.com/object/purevideo_overview.html) dynamically switches between 23.976fps display rate and 29.97fps display rate or just stable 23.976fps, it's not actually decimated but rather always soft-telecined? So basically any 30i content which DXVA deinterlacing doesn't display at 23.976 is hard-telecined? Does madVR currently support displaying 30i soft-telecined DVDs @ 23.976fps using DVXA2 deinterlacing?
I'm sorry, but I don't really feel like explaining all this another time. Please read this thread starting with the v0.78 announcement. I've explained a lot about soft-telecining, flags, deinterlacing etc in detail somewhere already. I'll be getting headaches if I have to explain that multiple times.
How does madVR know whether to bob/restore an ntsc source from 29.970 to 25 or to bob/deinterlace incorrectly mastered 23.976 to 25 fps?
I've no idea what you mean. There is no such thing as deinterlacing 24p to 25p.
Here are 3 log files, 1 is playback of index.bdmv created by tsMuxer, 1 is playback of index.bdmv created by EasyBD, the other is playing m2ts directly created by EasyBD:
http://www.mediafire.com/?ufcwg42ir9h57wb
http://www.mediafire.com/?3r5tm7cj11de3zx
http://www.mediafire.com/?a6401atf29q08mm
Thanks, but I'm really only interested in the log with the frame drops, nothing else. Which of the 3 is it?
madshi
16th November 2011, 17:42
Yeah. Or maybe add an option "Don't respect source interlace information" to let press Ctrl+Alt+Shift+D to switch deinterlacing on or off.
In what way would such an option change anything? Ctrl+Alt+Shift+D already lets you switch deinterlacing on/off right now.
cremor
16th November 2011, 17:45
The new v0.79 allows you to specify the queue sizes you want. Please double check whether 12/8 still makes problems. If so, you can experiment with other size combinations, too. Would be interesting to hear what you find out.
I've now tested it with a decoder queue of 8, 12, 20 (auto) and 32 and couldn't reproduce the problem at all, seems like 0.79 fixed the queue bug I had :)
The render queue is always full now too, so the performance is even better than with 0.77 :)
edit:
And my deinterlacing problems are fixed too! Many thanks for 0.79! :)
iSeries
16th November 2011, 17:47
Hi,
Its http://www.mediafire.com/?3r5tm7cj11de3zx
I uploaded 3 in case you were able to see any differences in the way they were handled.
madshi
16th November 2011, 18:01
I've now tested it with a decoder queue of 8, 12, 20 (auto) and 32 and couldn't reproduce the problem at all, seems like 0.79 fixed the queue bug I had :)
The render queue is always full now too, so the performance is even better than with 0.77 :)
edit:
And my deinterlacing problems are fixed too! Many thanks for 0.79! :)
Glad to hear that!!
Hi,
Its http://www.mediafire.com/?3r5tm7cj11de3zx
I uploaded 3 in case you were able to see any differences in the way they were handled.
Thanks. I can see in the log that madVR doesn't do things as well as it could. I'll improve that in the next build. However, the fact still remains that the incoming timestamps are not good. It might make sense to not fix it for now, though, so that you can retest (and hopefully confirm) that the next madVR build will have fixed the issue.
iSeries
16th November 2011, 18:10
Many thanks for looking into this Madshi.
I have also emailed support at EasyBD with the details to ask them if there's anything they can look at (I'm not happy that the free tsMuxer plays perfectly while payware doesn't!).
joe42
16th November 2011, 18:11
This VC1 clip (from Bleak House) fails to play from MPC-HC when using the MadVR video decoder (also fails with LAV Video decoder). It plays fine with the WMVideo Decoder DMO.
http://www.mediafire.com/?njfncwonawz6pea
madshi
16th November 2011, 18:34
This VC1 clip (from Bleak House) fails to play from MPC-HC when using the MadVR video decoder (also fails with LAV Video decoder). It plays fine with the WMVideo Decoder DMO.
http://www.mediafire.com/?njfncwonawz6pea
The libav VC-1 decoder currently does not support interlaced decoding. However, the Intel software decoder (also supported by madVR) does. So switch to the Intel decoder and it will work. Or use the Microsoft decoder instead. In order to use the Intel decoder you'll need to download the Intel decoder DLL. See first page of this thread.
cyberbeing
16th November 2011, 18:36
Please read this thread starting with the v0.78 announcement. I've explained a lot about soft-telecining, flags, deinterlacing etc in detail somewhere already.
For anybody interested, below is a collection of all the relevant madshi quotes on DXVA deinterlacing since 0.78 release:
Nope. In detail this is what madVR is currently doing:
For every frame coming from the decoder, madVR checks whether the decoder reports the frame to be progressive or interlaced. If it's reported to be progressive, madVR tells DXVA2 to weave the frame and keep it untouched. If the frame is reported to be interlaced, madVR tells DXVA2 to deinterlace it in double frame rate. Now some movies are encoded with hard-telecine, others with soft-telecine, again others are a mixture of both. Depending on how the content was encoded, madVR might output double frame rate or single frame rate or a mixture of both. The same is true for VMR and EVR deinterlacing. As I explained in the v0.78 announcement post, I may improve this in a future version. For now with movie content you may get 25p or 50p, 24p or 60p, or something in between. It all depends on how the content was encoded.
There's another problem: yadif is a pure video mode deinterlacer, it's not meant to be used for movies. So it's only half of a deinterlacer solution. For movie content you need IVTC. When talking about IVTC, there are a multitude of cadences. IVTCing just NTSC's 3:2 is pretty easy. But what about PAL's 2:2? Much more difficult, because there are no duplicate fields. Then there are various Anime cadences. Then there are bad edits. Finally, broadcasts sometimes have mixed video + movie content. With such content you need to deinterlace some parts of the frame with yadif and some with IVTC. In order to make that possible, you need an automatic per pixel video vs movie type detection, which is extremely hard to get right, especially with PAL content. Deinterlacing is a very very complex and difficult topic.
Of course I don't want to stop nevcairiel from adding deinterlacing to LAV Video Decoder, I'm just wondering whether it's really worth his time, considering the complexity involved in creating a "complete" solution.
DXVA deinterlacing has the luxury of having most of these problems already covered. Ok, I'm not sure how good all of these ATI/NVidia algorithms are, but in theory they should do all what I described above, including mixed video/movie content, minus decimation, however.
madVR always performs double rate deinterlacing (so do VMR and EVR, I think). Which means that after deinterlacing you will probably get 50p, not 25p, except if the video is encoded with progressive frames, in which case you may get 25p. But considering your description I think you're getting 50p. Of course when playing 50p, slowed down to 48p by Reclock, at 24Hz, you'll get *massive* amounts of frame drops. And dropping every other frame means that madVR can only send every other frame to DXVA. This means that madVR has to switch to BOB deinterlacing, because the highest quality deinterlacing mode requires madVR to provide the current video frame, together with the 2 previous frames, one of which madVR has already dropped.
DXVA does do IVTC, kind of, but with limitations. There are 2 key problems with DXVA IVTC, from what I can see:
(1) The current VMR, EVR and madVR implementations of DXVA deinterlacing "blindly" trust the video bitstream flags. That works well for some DVDs/broadcasts, but not for all. The better solution would be to distrust the flags. This is currently not done by any renderer using DXVA, as far as I can say. I might implement that in madVR in a future version.
(2) There's no support for decimation in DXVA1/2, so the output will be 60p, not 24p. I've seen that there may be some sort of support for frame rate changes and maybe decimation in DXVA-HD, but I'm not 100% sure.
dansrfe
16th November 2011, 18:42
The quality of DXVA2 deinterlacement with madVR is very good however since my GPU cannot deinterlace and upscale at the same time should I just deinterlace with ffdshow post-processing since that seems to work well with the GPU/CPU combo that I have?
I think it's time for me to get a new GPU...the question remains...Nvidia or ATI? :)
leeperry
16th November 2011, 18:50
Do you get DXVA2 deinterlacing with EVR? Have you installed .NET 3.0?
I wouldn't know how to enable deinterlacing w/ EVR, and no I don't run .NET 3.0 either.
madshi
16th November 2011, 19:05
The quality of DXVA2 deinterlacement with madVR is very good however since my GPU cannot deinterlace and upscale at the same time should I just deinterlace with ffdshow post-processing since that seems to work well with the GPU/CPU combo that I have?
That's a viable option, if your CPU is fast enough. For video content, probably you'll lose a bit of image quality. For movie content, avisynth may even be better than DXVA, because avisynth should be able to do IVTC with decimating, which DXVA1/2 can't do.
I wouldn't know how to enable deinterlacing w/ EVR, and no I don't run .NET 3.0 either.
Basically you decode with LAV Video Decoder and switch to EVR. That's it. You don't have to "run" .NET 3.0, it just needs to be installed. But anyway, the question is whether it's worth your time, since you don't plan to use it, anyway.
Xaurus
16th November 2011, 19:16
madshi,
I am getting frame drops with 0.79 (2 so far with Inception m2ts file). I also had to re-enable "limit rendering times to avoid glitches" to remove the presentation glitches that started appearing.
I don't know what to look for in the log to identify frame drops, but both are near the end.
The debug OSD shows a frame drop in ~2 days.
In any case, the log is here (http://home.halden.net/mordor/log.zip).
leeperry
16th November 2011, 19:17
.NET 3.0, it just needs to be installed. But anyway, the question is whether it's worth your time, since you don't plan to use it
Well yeah, I don't run any software requiring having all this bloat installed...and indeed, I don't care about having the VR doing the deinterlacing either after all.
BTW, everything's cool w/ the defaults for the "queues sizes to GPU ram" stuff...should I play around w/ those? everything seems as smooth as before AFAICT :)
madshi
16th November 2011, 19:29
I am getting frame drops with 0.79 (2 so far with Inception m2ts file). I also had to re-enable "limit rendering times to avoid glitches" to remove the presentation glitches that started appearing.
In any case, the log is here (http://home.halden.net/mordor/log.zip).
Looks like a bug in madVR, will be fixed in the next build.
BTW, everything's cool w/ the defaults for the "queues sizes to GPU ram" stuff...should I play around w/ those? everything seems as smooth as before AFAICT :)
If everything is perfect, there's no reason to play around, right? :) Of course playing is fun, so you might as well try to find a difference with different queue sizes...
cyberbeing
16th November 2011, 19:52
Interesting. So you can actually use 32CPU/24GPU? That's probably with SD content, though?No, that's with 1920x1080 HD content.
I did some more testing on this.
Maxed out queues work fine will 1080p24 and 1080i30 content as long as it's not being upscaled. They also work fine when upscaling 720p to 1080p or 1440x1080 to 1920x1080.
With progressive content, the queues work fine when equal, unlike DXVA deinterlacing + madVR internal decoder where the CPU queue needs to be around 2 higher to not cause issues.
If I upscale 1920x1080p24 to 2560x1440, the maximum queue size I can set is 20CPU/20GPU before running out of memory on my GPU using madVR luma/chroma resizers + 3dlut. GPU-Z reports memory use as 506MB/512MB while madVR reports 1560MB/512MB.
I am getting frame drops with 0.79.
Looks like a bug in madVR, will be fixed in the next build.
I seem to be getting occasional delayed frames (not dropped since high refresh rate) once again in madVR with 0.79, and it also appears the delayed/dropped every XXX measure in the OSD seems to be increasing slower when used in conjunction with ReClock than previous builds. In case this is the same bug as Xaurus, I'll wait for the next build before looking into it further.
madshi
16th November 2011, 19:55
Interesting. So 512MB seems to be plenty. So: Do bigger CPU/GPU queue sizes help? Do they harm? Anyone any experience on this?
noee
16th November 2011, 20:13
In windowed mode, with SD interlaced video material, if I leave queues to default, the render queue starves and backbuffer queue is very low (0-3/6) and I get a dropped frame about every 10 seconds. If I bump GPU/CPU queues up to 14, then render queue goes to a consistent 3-5, bb queue is still low, 1-3, but it doesn't drop frames.
HD6570 (1GB), not using 3dLUT, upscaling to 1920x1080
cyberbeing
16th November 2011, 20:14
I'm still investigating to see if there are any benefits under heavy load. If my previous deinterlacing testing are any sign, there does seem to be a benefit in never having your CPU queue (including fluctuations) drop below the maximum GPU queue.
As for harm, I seem to be getting more delayed frames than usual in this build (see edit above), but that may be the same bug as Xaurus is experiencing? I'm getting the feeling that setting higher CPU queue causes an increased likelihood of delayed/dropped frames in combination with Flush&Wait settings because of increased CPU contention. It also seems like setting higher GPU queue occasionally causes an increased delay when seeking or resizing with 'Wait till render queues are full' setting is enabled or dropped/delayed frames when it's not enabled.
Hprd
16th November 2011, 20:42
Interesting. So 512MB seems to be plenty. So: Do bigger CPU/GPU queue sizes help? Do they harm? Anyone any experience on this?
Having it auto adjust is pretty bad for glitches, having it set highly is too. 8/8 for both (same as b4) is about the same as b4 (obviously). Setting it to 4 (and limit render times/render in another thread set) for both though results in very few glitches at all. This is at 48/59 hz with 12 pre-presented frames. 16 pre-presented frames + limit rendering times and 8/8 for CPU/GPU (which is what i've used on previous versions of madvr) seems better on 24/29, as there seemed to be a dropped frame or two (probably the que being too low or something?) on the other settings that worked good for 48/59.
Thunderbolt8
16th November 2011, 21:20
That is really weird. Does the black level change everytime you turn deinterlacing on/off via Ctrl+Alt+Shift+D? Does it help if you turn on the "Dynamic Range" option in the GPU "advanced video" options and set it to 16-235?its weired, but atm it doesnt do it anymore. dont ask me why (theres only a slight shift of brightness with a coloured movie (which is also present in windowed mode), but I presume that is supposed to be normal, because its not as strong as before and in case of a b&w movie, theres no shift of colour at all any more)
at least that shift used to be there in fullscreen exclusive mode. Ill report back in case it should come back :S
(I can only choose to activate or deactivate dynamic range btw., not set anything like 16-235)
I'm not sure if it's a good idea to process video in ffdshow/aviSynth, if you want to use DXVA2 deinterlacing, because usually you should deinterlace *first* and process afterwards. Sharpening should ideally be performed after deinterlacing + upscaling.but how can I know the order in which of these are performed?
in ffdshow, I can at least tell to use TFM() first via avisynth before sharpening, because I can set the order of being processed for these two. but where in this chain comes madvr scaling and dxva2 deinterlacing into play? and how could I change that order if I needed to?
jmone
16th November 2011, 22:13
FYI - Nice update. IMO madVR does a higher quality job of deinterlacing than YADIF.
jmone
16th November 2011, 22:25
In windowed mode, with SD interlaced video material, if I leave queues to default, the render queue starves and backbuffer queue is very low (0-3/6) and I get a dropped frame about every 10 seconds. If I bump GPU/CPU queues up to 14, then render queue goes to a consistent 3-5, bb queue is still low, 1-3, but it doesn't drop frames.
HD6570 (1GB), not using 3dLUT, upscaling to 1920x1080
I was seeing this as well on my nvidia cards, it seemed that the effort to decode, scale, and deinterlace was impacted keeping the queues full than with progressive HD Material (eg I see this with 1080/50i as well). Likewise I found pushing the new GPU/QPU queues up to max prevented the BB Queue to hitting 0 and hence dropping frames. I still see queues jump around alot, eg on their 1080/50i h264 (TV Series on Blu rip):
Decoder queue: 22-14/24 (stable, never moves)
Upload queue: 16-18/24 (can move around abit especially after a window resize etc)
Deinterlace queue: always moving values between say 9-13 and 10-14/24
Render queue: always moving values between say 8-11 and 10-13/24
Backbuffer queue: 7-8/8 (stable, never moves)
The increase in CPU/GPU settings seems to give enough buffer to handle the changes in the intermediate queues and keep the Backbuffer Queue Stable.
EDIT: YMMV, but on my system, just raising the GPU Queue Size from 8 to 12 was all that was needed and seems a good balance between stability and GPU Mem usage (709/1024). At this setting all queues as stable as well.
Gser
16th November 2011, 22:45
Can you please post screenshots that show this difference? Ideally also a small video sample? Thanks!
Feel free to use any MPEG2 file you have. HD preferably. You could decode the file to a lossless format using DSS2 with Dscaler's and LAV's decoder and then use Subtract to emphasize the differences.
madshi
16th November 2011, 23:10
its weired, but atm it doesnt do it anymore. dont ask me why (theres only a slight shift of brightness with a coloured movie (which is also present in windowed mode), but I presume that is supposed to be normal, because its not as strong as before and in case of a b&w movie, theres no shift of colour at all any more)
at least that shift used to be there in fullscreen exclusive mode. Ill report back in case it should come back :S
(I can only choose to activate or deactivate dynamic range btw., not set anything like 16-235)
Please don't confuse "dynamic range" with "dynamic contrast". Two very different things. Dynamic contrast should be turned off. Do you still get visible differences between deinterlacing on/off? That's not really supposed to happen. Can you post screenshots?
Feel free to use any MPEG2 file you have. HD preferably. You could decode the file to a lossless format using DSS2 with Dscaler's and LAV's decoder and then use Subtract to emphasize the differences.
So basically you're saying you're not willing to do a screenshot comparison for me?
pacemaker1000
16th November 2011, 23:18
2.7 dual core cpu and current ati 4650 and i can run MadVR for everything other than 1080 stuff
will a new nvidia card enable me to do 1080 if i enable Cuvid?
should have tried it when i had it i know but i sent it back as i got a lot of dropped frames compared to ATI. but that was before renethx pointed out that reclock wroks better with MadVR when Vsync is disabled...doh
SoBizarre
16th November 2011, 23:30
Hi,
I was wondering if there is way around a little problem I'm having. Actually it's more of an annoyance than a real problem, but it drives me mad nonetheless.
Every time I start a player, the first file I'm playing gives me correct screen refresh rate (usually ~48Hz, but incorrect composition rate (60 and sometimes 30Hz).
http://img803.imageshack.us/img803/9489/cr60.jpg
http://img818.imageshack.us/img818/8573/cr30.jpg
It's ALWAYS like that, but reopening the same file ALWAYS gives me matching rate.
http://img401.imageshack.us/img401/6710/cr48.jpg
From what I understand, exclusive mode and disabling Aero would solve the problem, but unfortunately that does not suit me (disabling and re-enabling Aero messes with some of my open programs).
So, am I stuck with opening files two times in order to watch, or is there something else that can be done?
Actually, there is one more annoyance. When in fullscreen, clicking on "minimize" will crash the player.
http://img254.imageshack.us/img254/9426/crashcc.jpg
But I've learn to live with this one, so it's not a big deal... ;)
EDIT:
I found out elsewhere solution to the last one. Check:
Preferences->General->Fixed window position when minimize
My setup:
Win 7 x64
nVidia 420M
Daum PotPlayer, Haali Media Spliter, CoreAVC, LAV Filters, ffdshow raw video filter, ReClock, madVR - all 32-bit.
madVR is handling the switching to custom resolutions 48/50Hz.
Cheers,
SB
joe42
16th November 2011, 23:41
The libav VC-1 decoder currently does not support interlaced decoding. However, the Intel software decoder (also supported by madVR) does. So switch to the Intel decoder and it will work. Or use the Microsoft decoder instead. In order to use the Intel decoder you'll need to download the Intel decoder DLL. See first page of this thread.
I installed the Intel decoder, and now the clip works fine with madVR doing the decoding.
I noticed that next to the VC-1 checkbox in madVR settings, I can choose either libav or Intel decoder. I actually still have it on libav, but the interlaced VC-1 clip still decodes properly.
Is madVR using libav for non-interlaced VC-1, and automatically choosing Intel decoder for interlaced VC-1?
dansrfe
17th November 2011, 00:12
If I play a clip in exclusive mode on monitor 1 then everything is "frozen" on monitor 2. I'm guessing that is normal behavior but just wanted to confirm since if the reverse happens I can use monitor 1 like normal.
pankov
17th November 2011, 00:17
I have the same problem but I would not call it "frozen" but rather the application on monitor 2 can't get the focus.
I can move the windows around but they can't become the active application.
Gser
17th November 2011, 00:38
So basically you're saying you're not willing to do a screenshot comparison for me?
It's rather late at night. I was hoping to get some sleep first.
PhrostByte
17th November 2011, 00:42
bug report: resuming from sleep, or switching between single-monitor and extended desktop modes (win+p in vista/7) causes madVR to become very choppy.
BatKnight
17th November 2011, 02:15
I have a problem with madVR 0.79 that doesn't happen with 0.78.
As you probably know I use MPC-HC fullscreen refresh rate changer and it has always worked.
But with 0.79, when I play a 24fps movie my LCD starts as 60Hz, then I go fullscreen and the LCD changes to 24Hz but it shows the MPC seek bar kinda out of place, I hear the audio of the movie but no image. I pause and unpause, then I can see the movie, but 2 to 3 seconds later after the movie is already playing, the LCD changes back to 60Hz even though I didn't exit the fullscreen. It should stay at 24Hz.
I go back to 0.78 and all is fine as it has always been.
Did you change anything that could have broke the MPC-HC refresh rate changer?
PS: madVR's refresh rate changer works with 0.79 and mantains the 24HZ throughout the movie. I would like to use your changer, though, if it would allow me to change the rate, only when in going fullscreen.
dansrfe
17th November 2011, 04:22
I absolutely LOVE DXVA2 deinterlacement vs. YADIF. It's like magic. I wish there was a way to deinterlace using DXVA2 in AviSynth.
mr.duck
17th November 2011, 04:39
madVR + hardware deinterlacing with 50p output is glorious
ryrynz
17th November 2011, 07:37
Have dropped the CPU and GPU queues down to 4/4 and everything is running sweet.
nx6
17th November 2011, 08:33
Hmmmm... Please create a log and uploaded it (zipped). Please try to keep it small. Which means: Start your media player, go to fullscreen mode, wait 10 seconds, close your media player. Done. Thx.
http://www.sendspace.com/file/w5r27b
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.