madVR - high quality video renderer (GPU assisted)

[nevcairiel]

Originally Posted by madshi

I'm telling the libav/ffmpeg VC-1 decoder to do multithreading, but I don't know if it actually is capable of doing that.

It is not.
Only very few codecs support it.

[Thunderbolt8]

well that explains why its so slow on my PC
I guess its not really usable then with madvr for many users, even though madshi plans to implement some stuff which could take advantage of using the renderer and decoder integrated in madvr. but in case more performance is needed to work smoothly, missing multithreading support of VC-1 then takes away the advantage which could be gained at another point.

maybe madshi could request multithreading implementation for libav/ffmpeg VC-1 decoding, I guess his word might have more impact than mine

[andybkma]

Originally Posted by madshi

It seems to work pretty well here. Can I have a log from when you get frame drops right after playback start?

Yes, gladly. Here is the link to the log. I started playback to two various vids a few times each. I hope this info helps and thank you very much....

http://www.filefactory.com/file/cc93...adVR_-_log.txt

[JarrettH]

I was wondering if madvr would function well with the new integrated graphics on Sandy Bridge processors? Intel HD Graphics 3000 and 2000 (differing by 12 and 6 execution units)

[madshi]

Originally Posted by cyberbeing

Sorry for the late report (I originally thought it was a fluke), but madVR 0.70 Special2 introduced a bug with "delay playback start".

Only madVR 0.70 Special2 & 0.71 have the bug. madVR 0.70 & 0.70 Special1 are fine.

When using the refresh rate changer and "delay playback start" is enabled, videos opened paused (after refresh rate change). It happens with any decoder, internal or external, so it's not the same as that other frozen screen bug which you fixed. The good news is if you unpause the video, it appears to play normally. The bad news is occasionally when you close MPC-HC in this inital paused state, madVR will hang (I've been unable to get a log of this so far).

I'll have a look.

Originally Posted by chogster

Still no joy for me using HAM with any madVR version newer than 0.57! CPU and GPU loads are average, but I'm experiencing a high rate of dropped frames running 1080p/bluray! Everything seems smooth switching over to the Cyberlink software filter, but CPU usage is obviously much higher.

Was there a significant change within madVR from version 0.58 onwards that could cause conflict with HAM?

Not sure what causes the problem exactly. Is the change exactly between 0.57 and 0.58? Maybe if you can upload a log with 0.57 and another one with 0.58 that might help me figure out what's going on.

Originally Posted by Thunderbolt8

maybe madshi could request multithreading implementation for libav/ffmpeg VC-1 decoding, I guess his word might have more impact than mine

That's not how open source code. You can "request" a feature a million times, it doesn't matter when there's no developer willing to invest his time for that. The libav/ffmpeg devs know themselves that some decoders are lacking multithreading support, and it will come eventually. Or maybe not. Nothing I could do about it.

Originally Posted by andybkma

Yes, gladly. Here is the link to the log. I started playback to two various vids a few times each. I hope this info helps and thank you very much....

http://www.filefactory.com/file/cc93...adVR_-_log.txt

Have you ever heard of zip?

Anyway, according to your log the first frame drop is after 40 seconds of playback. I don't understand. I thought you'd get frame drops right after playback start?

Originally Posted by JarrettH

I was wondering if madvr would function well with the new integrated graphics on Sandy Bridge processors? Intel HD Graphics 3000 and 2000 (differing by 12 and 6 execution units)

I've no idea. I might be able to say in a couple of weeks.

[nevcairiel]

Originally Posted by JarrettH

I was wondering if madvr would function well with the new integrated graphics on Sandy Bridge processors? Intel HD Graphics 3000 and 2000 (differing by 12 and 6 execution units)

It works ok on a HD 3000 (2600k), but speed could be better. When up/down scaling, rendering times approach around 24-30ms using SoftCubic 50 for Chroma and Lanczos3 for luma up/down.

This means, for 24/25fps content its fine, but 50/60fps content is too much for the GPU to handle.

Of course you can go down in scaling quality to get it 50/60p compatible. I really only ran this test out of curiosity, this is my Dev PC, and the iGPU only powers my secondary screen.

[andybkma]

Originally Posted by madshi

Anyway, according to your log the first frame drop is after 40 seconds of playback. I don't understand. I thought you'd get frame drops right after playback start?

No, it stutters/jutters upon playback start in Win7 while it doesn't do that in XP. Using Haali's Renderer in Win7 it doesn't do it either.

[Ifrit30]

dunno if this was mentioned yet, but madVR v0.71 seems to be buggy, I couldn't watch anything except for a few videos.
so I reverted back to version 0.69

@ madshi would you please look at it?
and thanks for your great work

[madshi]

Originally Posted by andybkma

No, it stutters/jutters upon playback start in Win7 while it doesn't do that in XP. Using Haali's Renderer in Win7 it doesn't do it either.

Do you see any indication of the stuttering at all in the madVR OSD (dropped or delayed or glitched frames)?

Originally Posted by Ifrit30

dunno if this was mentioned yet, but madVR v0.71 seems to be buggy, I couldn't watch anything except for a few videos.
so I reverted back to version 0.69

Can you define "buggy"? What happens exactly? Does your computer explode or what? Come on, without a few details your report is not of much use to me.

[Ifrit30]

Originally Posted by madshi

Can you define "buggy"? What happens exactly? Does your computer explode or what? Come on, without a few details your report is not of much use to me.

well I mean that it doesn't play correctly like only the audio is playing (the video is black) and the player (pot player) itself freezes up or some files aren't playing at all .
the previous version worked fine.

[madshi]

Originally Posted by Ifrit30

well I mean that it doesn't play correctly like only the audio is playing (the video is black) and the player (pot player) itself freezes up or some files aren't playing at all .
the previous version worked fine.

Ok, seems to be PotPlayer specific, MPC-HC works fine here. Will try to fix it in the next build.

[nuhi]

Originally Posted by agustin9

Try installing the latest directx version from here:
http://filehippo.com/download_directx/

My issue of missing OSD was either with the madVR decoder in general or the way how I use it.
I use External Filters option to set madVR as Prefer, then the OSD is missing regardless if it's enabled in MPC. Maybe a new bug or known limitation?
If I use Ffdshow or MPC Decoder then the OSD is finally there and I can see the volume.
Let me know if you have OSD and use madVR decoders, then please how do you set it if not in External Filters.

[madshi]

That's a bug in MPC-HC. If you set madVR to preferred, MPC-HC is confused and isn't aware that madVR is not only the decoder, but also the renderer. If you want to use the madVR internal decoders, block all external decoders that take preference over madVR, then MPC-HC will have no other choice left than to use the madVR internal decoders, and it won't be confused that way.

[Xaurus]

madshi,

Little is known to me about the different algorithms used in madvr. I mean, is there a theoretical "best one" or simply different preferences?
For example, I'd like to believe that the most CPU-intensive algorithm is the best one, but that may not be the case. I don't even know
how demanding the different algorithms are. Perhaps you could put some sort of rating system for us "newbies" in there? Like for example,
Bicubic 50 is 4/10 CPU intensive and 3 taps Lanczos is 7/10 CPU intensive (just examples since I have no clue). Also, are these algorithms
benefiting from multiple cores?

For someone that has virtually "no limits" on CPU power (6 cores @ 4 GHz), what would you recommend for luma up/down scaling and chroma scaling?
Also, I'm using an Nvidia 570 GTX.

[leeperry]

Hi madshi, thanks for the new builds! I will try my test patterns and see how RGB32 looks now. I see you mentioned 0-255 YV12 as well, but do we still have to manually set it to full range? If so, could you please allow mVR to remember this setting over sessions? and same goes for the gamut? so I can have mVR remember to use SMPTE-C permanently? possibly setting the .ini as read-only, so if I set it to EBU it'll go back to SMPTE-C next time I open PotPlayer? That'd kill two birds w/ one stone and make me a very happy camper. Later on, an option to set 25=EBU(for SD only) and SMPTE-C for all the rest would be super neato of course...and there would be no need for a fancy GUI, a text .ini file would be just fine

[madshi]

Originally Posted by Xaurus

Little is known to me about the different algorithms used in madvr. I mean, is there a theoretical "best one" or simply different preferences?

This question has been asked like a million times already. Please try to find it with search. Short answer: Look at the graphs in the settings dialog and trust your eyes.

Originally Posted by Xaurus

Also, are these algorithms benefiting from multiple cores?

No, they all run on the GPU, only, so it doesn't matter at all what CPU you have.

Originally Posted by leeperry

Hi madshi, thanks for the new builds! I will try my test patterns and see how RGB32 looks now. I see you mentioned 0-255 YV12 as well

Yes, and it should all look correct now. I think you will be satisfied.

However, there's a freeze problem with the madVR 0.71 and PotPlayer. Am working on that...

Originally Posted by leeperry

but do we still have to manually set it to full range? If so, could you please allow mVR to remember this setting over sessions? and same goes for the gamut?

You won't be satisfied with this, but the logic is that madVR auto detects the best matching settings, and then you can modify them if you don't like what madVR has selected. Since the correct settings can very well be totally different for every new video, it doesn't make sense to carry settings over from one session to the next. It might make sense in your specific case, but not for most other madVR users. I might add a custom hack to force madVR to always assume full range input, but that's far as I'm willing to go at this point in time. You'll have to wait for gamut rules/profiles, as I've said a dozen times in the last couple of days.

[andybkma]

Originally Posted by madshi

Do you see any indication of the stuttering at all in the madVR OSD (dropped or delayed or glitched frames)?

madshi, with the Cntrl+J OSD turned on, with "Delay playback start until render is full" unchecked, I get about 7 dropped/3 delayed frames starting and stopping the vid.

With "Delay playback until render is full" checked, I see the same exact stuttering with the vid yet the OSD is not registering them as dropped/delayed frames (shows zero). This is probably why the log I upped for you doesn't show the dropped frames because they are not registering with "Delay playback until render is full" checked. But they are quite visible to the naked eye just the same as if the "Delay playback..." option was unchecked. It just seems to me that the OSD dropped frames logging is being delayed a tad until after the initial stutter is over with the "Delay playback..." checked which is why it's showing zero.

[pirlouy]

Originally Posted by nevcairiel

and the iGPU only powers my secondary screen.

You mean you can use iGPU and ATI/nVidia GPU together ?!!
Never tried that.

[madshi]

Originally Posted by andybkma

madshi, with the Cntrl+J OSD turned on, with "Delay playback start until render is full" unchecked, I get about 7 dropped/3 delayed frames starting and stopping the vid.

With "Delay playback until render is full" checked, I see the same exact stuttering with the vid yet the OSD is not registering them as dropped/delayed frames (shows zero). This is probably why the log I upped for you doesn't show the dropped frames because they are not registering with "Delay playback until render is full" checked. But they are quite visible to the naked eye just the same as if the "Delay playback..." option was unchecked. It just seems to me that the OSD dropped frames logging is being delayed a tad until after the initial stutter is over with the "Delay playback..." checked which is why it's showing zero.

Well, the stutter you're seeing has then probably other reasons. Meaning that the "delay playback" option works just as advertized. Now if you ask me what other reasons there are, I can't say for sure. Have you tried different video clips? Does it occur with all of them or just some or just one? Have you tried different splitters and different decoders?

[nevcairiel]

Originally Posted by pirlouy

You mean you can use iGPU and ATI/nVidia GPU together ?!!
Never tried that.

On Win7 at least. All previous Windows will probably freak out about it. There are some minor glitches, but it works mostly fine on this Z68 board. With NVIDIA here at least, dunno about ATI.