madVR - high quality video renderer (GPU assisted)

[nevcairiel]

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 :p
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 :p

[andybkma]

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/cc93331/n/madVR_-_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]

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.

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.

maybe madshi could request multithreading implementation for libav/ffmpeg VC-1 decoding, I guess his word might have more impact than mine :p
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.

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/cc93331/n/madVR_-_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?

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]

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]

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]

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)?

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]

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]

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]

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 :)

:thanks:

[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?
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.

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.

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...

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]

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]

and the iGPU only powers my secondary screen.

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

[madshi]

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]

You mean you can use iGPU and ATI/nVidia GPU together ?!! :eek:
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.

[Plutotype]

I've disabled the VC-1 decoder because I consider the Microsoft VC-1 decoder superior to libav/ffmpeg and Intel at the moment. If (and when) that changes, I will modify the default settings accordingly. My h264/MPEG2 decoder implementations should compare well to any other (free) h264/MPEG2 decoders out there, and they seem to be stable now, too, so that's why I enabled them by default. madVR has a rather low merit, though, so madVR's internal decoders shouldn't force themselves upon you. You can still easily prefer external decoders over madVR's internal ones, even if they are enabled.


Just a hint - noticed, if you enable the madVR internal decoders and let ffdshow as preffered external video decoder ( you want to use ffdshow ), the CPU usage doubles. So it looks like the internal decoders are still on, inspite of the fact they should be blocked by the ffdshow video decoder, if ffdshow video decoder is set to prefer in the external filter list. Could you pls test this?

[Plutotype]

Hi madshi,

As I have reported A/V sync issues ( I hate them ) yesterday, my doubts were only about A/V issues which I experienced when I was seeking in the timeline. Today, I did some tests with madVR internal decoders and ffdshow 3949 and compared their behaviour when seeking in the timeline. Better said, I was focusing on lipsync, when I jumped to a different point in the movie and then watched the A/V sync:

ffdshow video 3949:
MPEG2 - no A/V issues ( libavcodec )
VC-1 - occasional A/V issues ( libavcodec ), but no A/V issues with wmv9
H.264 - no A/V issues ( libavcodec )

madVR 0.71 internal decoders:
MPEG2 - no A/V issues ( libavcodec )
VC-1 - no A/V issues ( libavcodec )
H.264 - no A/V issues ( libavcodec )

So at my setup, only decoding VC-1 by ffdshow libavcodec causes occasional lipsync issues when seeking in the timeline. Nevcairiel always said its the most problematic video format ( timestamps workaround ). Maybe you can add some point too.

[leeperry]

Yes, and it should all look correct now.
goodness!
However, there's a freeze problem with the madVR 0.71 and PotPlayer. Am working on that
Oh, I've hardly ever encountered freezes between mVR and PotPlayer :confused:

Lemme know if you want me to whine about anything on the official korean forum.

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.
OK, neato! the only 2 things I would currently need in mVR are:
-proper colors in PC range RGB32(just like in 0.67)
-a way to get automatic PC range YV12(w/ proper colors of course), either through an "assume PC range for YCbCr" or "remember last YCbCr levels range".

The former in order to be able to use ddcc() in ffdshow, and the latter for when I'm out of CPU power(because ConvertToRGB32() can't be MT'ed :().

And that's pretty much it! for various reasons, such as:
-I don't want to wait 3 secs for a 96MB LUT file to be loaded before each and every video(it takes forever, even from a PC8500 ramdisk :o)
-ddcc() does exactly what I need, and looks totally amazing, no need to reinvent the wheel really
-I'm not interested in becoming a beta-tester for yCMS, when ddcc() does all I need brilliantly
-you recently said that you would allow custom PS scripts at some point, so I could always use the AVS script someday in the future who knows maybe :p

My only issues w/ using ddcc() CUDA in ffdshow are that:
-ConvertToRGB32 can't be MT'ed, and it's a CPU hog...tritical said he might consider creating a CUDA way to convert YV12>RGB32, but that seems to annoy him quite a bit.
-ffdshow is like a ghost train, and when you change the Avisynth scripting on the fly, the coder who added the Avisynth filter to ffdshow("Leak") cuts the plugins threads in a very dirty way and that crashes the CUDA drivers completely(which instantly locks up the computer). He also recently told me that he didn't care whatsoever...gotta love GPL software :o

The solution to both problems is to get a faster CPU, and run ddcc() in software mode...then I will finally be able to do anything gamut-related I want in ffdshow, without stutter due to high CPU load, LUT loading waiting time or GPU drivers crashes :)

Colorimetry is not your priority, and I don't mean to annoy you even further w/ stuff you don't care about. I know a perfectly working solution to my problems, all I need is shelling out a few hundred bucks to get a blazing fast i7 rig. I've got plenty of spare cash to do so, but I really hate to buy high-tech equipment that'll be losing 70% of its original value over a 12 months span...so I'll wait another 6/12 months for those second hand Sandy's to show up on the used market. Until then I'll keep using ddcc() CUDA and make damn sure to never switch gamuts on the fly, and use mVR in PC range YV12 when I really don't have enough CPU horse power to go RGB32.

I promise to never talk about "gamut" or "SMPTE-C" in this thread anymore, otherwise you can fine me 10€ per occurrence :D

[Plutotype]

Hi madshi again,

when using internal decoders and playing MPEG2 video, OSD via CTRL+J shows @ "every frame repeat" numbers like 41.67s or 41.57 etc. The playback is smooth.

Im asking because when playing VC-1 or h.264 videos, I get at the same stat numbers like 1, 2 or more hours.

Thanks

[azaze1]

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. In any case, the Microsoft VC-1 decoder is clearly faster on my dual core CPU.

Is this the 'Microsoft DTV-DVD Video Decoder' in the external filters? If not, how can I ensure the decoder you're referring to is used for VC-1 content? More importantly, is there a way to make sure it's used for VC-1 and NOT h264 should I choose to use madVR's h264 decoder....

[jmone]

FYI the "delay playback start..." option in V0.71 causes video playback to stall in MC16

[andybkma]

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?

Yes, I have tried different splitters, decoders (Win decoders vs 3rd party), renderers, players, different video formats, different hard drives, even different laptops. All lead to the same conclusion, it only occurs with madVR and even when I lower the scaling algorithms.

That was the first thing I noticed when I moved to Win7 from XP this month, that video playback with madVR was not nearly as smooth. But like I mentioned before, it's just something to live with....

[azaze1]

I gave madVR's internal h264 decoder a shot today. It performs noticeably better than ffdshow's software decoder. I'd be interested in using it being it's software based, and thus has no decoding artifacts that plague external dxva and HAM decoding... multithreading is a bonus.

I did have a crash instantly while watching particular movies, so I'd like to provide logs, but I never see any...

QUESTION: Do I need to register the debug filter alongside madVR.ax or must I unregister madvr.ax first, and then register the debug? Where will the log be located?

Thanks,

[ryrynz]

all I need is shelling out a few hundred bucks to get a blazing fast i7 rig. I've got plenty of spare cash to do so, but I really hate to buy high-tech equipment that'll be losing 70% of its original value over a 12 months span...so I'll wait another 6/12 months for those second hand Sandy's to show up on the used market.

So your going to wait up to a year to save (at a rough guess as your 70% is pretty inaccurate) a couple of hundred bucks and prevent yourself for having a solution to your issue today even though you more than enough money to do so? I thought you were a smart guy leeperry! I just upgraded my Core 2 Quad system to an i7 and the increase in performance even at the same core frequency is great (gotta love Hyper-threading for Avisynth) I sold off my C2Q parts for almost as much as I bought the i7 920 for. If money isn't for the things you want when you want them, what is it for? Do it Lee, do it for yourself! No need to go for the fastest i7 money can buy just get a 2600K and overclock the beejesus out of it. You'll still be able to sell it off years down the track at 40-50 odd percent of what you paid, the longer you want the less your current gear is worth too. When you desire something THAT is the time to get it, more time waiting is less time being satisfied and life is too short to continue being dissatisfied.

Madshi,
I've enabled MPEG2 decoding with MadVR and found when opening a VOB from any of my DVD rips the audio ends up being out of sync and after seeking the video speeds up and stutters.
I'm using Lav splitter/audio 0.30 and I'm having no issues with playback when switched to ffdshow for decoding.
BTW thanks for the continued and prompt development! I'm looking forward to seeing improved scaling algorithms in the future, hopefully by the time 1.0 rolls around *fingers crossed* :)
Your doing an awesome job it's much appreciated.

[Wile-E-Coyote]

QUESTION: Do I need to register the debug filter alongside madVR.ax or must I unregister madvr.ax first, and then register the debug? Where will the log be located?

Thanks,

Once madvr is installed, just double click on the "register debug mode" and launch your video until the problem appears. The log file will be on your desktop. Once you're done debugging double click the "register debug mode" again to deactivate debug mode.

[Blight]

madshi:

Oh, I didn't check this with "use dx11 path", cause my development PC is XP. Does this also occur with the dx9 path?

No, this looks like the exact bug that caused crashes in 0.69 that you fixed in 0.70, but only occurs in the DX11 path is used.


3. If 'auto exclusive mode' is enabled, switching between 'windowed on monitor 1' to 'fullscreen on monitor 2' causes the exclusive mode image to take longer and longer to reappear (the screen stays black for up to 13 seconds after 10-15 switches).


I can't reproduce that here. Is that with the dx11 path again? Does the same thing happen with the dx9 path?

This happens in the DX9 path, I couldn't test the DX11 path, as it's not stable for this operation.


My 'stop function causes the OSD to remain on-screen until a play command is issued.


What OSD remains on-screen? Yours or mine? If yours: Did you draw is with a timeout value? Or did you (try to) clear it with a separate API call?

My OSD (ControlBar/pop-up OSD). I try to clear it with a separate API call, I'm not using timeouts at all.


* fixed: madVR caused "File Source Async" to never be destroyed

I was about to report that MadVR keeps the playing file handle locked, preventing the file from being erased. I haven't had time to test 0.71, hopefully it's fixed already :)

[Blight]

Madshi:
Here's the log (http://t.inmatrix.com/madVR_blank.rar) file you requested where creating a window (before even showing it) causes MadVR to lose exclusive mode for a second. Are you checking the window handle for visibility and position? If you're just checking position and hooking the window create function, you're going to get false positives.

I just did a very quick initial test and 0.71 partially breaks the OSD. If I pause playback, no OSD is displayed. If I press play again, the 'pause' OSD appears briefly before switching to a 'play' OSD.

P.S.
I prefer posting here (rather than eMail) as it allows other users (and users of ZP) to see the development process and maybe add some input.

[cyberbeing]

when using the refresh rate changer and "delay playback start" is enabled, videos opened paused (after refresh rate change).:( i'll have a look.

Once you find and fix this bug, maybe you should make it an optional feature. ;)
I'm actually beginning to like videos opening paused, since it gives me a chance to enter fullscreen before starting playback. Though the better solution would be fixing the MPC-HC "Launch files in fullscreen" option to work with madVR.

[Neeto]

Once you find and fix this bug, maybe you should make it an optional feature. ;)
I'm actually beginning to like videos opening paused, since it gives me a chance to enter fullscreen before starting playback. Though the better solution would be fixing the MPC-HC "Launch files in fullscreen" option to work with madVR.

You can use the command line option on MPC-HC to open in full screen.
I use mpc-hc.exe /fullscreen /play /close file

[Xaurus]

Hmm? I don't have any problem with the "Launch files in fullscreen" option in mpc-hc, it works like it should.

[cyberbeing]

Hmm? I don't have any problem with the "Launch files in fullscreen" option in mpc-hc, it works like it should.

It only works when not using the madVR refresh rate changer, which I guess means this is another bug...

Edit: Or not, it seems to be working now after I removed the /fullscreen which I just added to File Types. I think I just misunderstood what the option was supposed to do. It only works when opening something from Explorer, not the the Playlist. In that case, a start playback paused option would still be useful, but less needed.

You can use the command line option on MPC-HC to open in full screen.
I use mpc-hc.exe /fullscreen /play /close file
This seems to workaround the bug, since MPC-HC enters fullscreen before the refresh rate change. Opening videos via command line doesn't seem very practical, but I can just add the command line option to File Types. Edit: See above update.

[cyberbeing]

On another note, madshi could you make ISubRender subtitles get scaled with with the selected madVR luma/chroma resizers? If you set maximum texture size of 1280x720 and then playback fullscreen at 1920x1080, subtitles are very blurry. Do you even have control over that, or is it MPC-HC doing the blurry subtitle resizing with a lower texture size?

Why don't I just use 1920x1080 or Desktop as my maximum texture size? Performance reasons. On this computer, playback of higher bitrate 1080p 10bit h264 results in dropped/delayed frames with a subtitles max texture size of 1920x1080 and two or more lines (or complex subs) on screen, while using a max texture size of 1280x720 is always fine. Having the subtitles resized by madVR from lower texture sizes would work nicely at reducing the blur, since I use Spline36 for luma upscaling.

[leeperry]

That was the first thing I noticed when I moved to Win7 from XP this month, that video playback with madVR was not nearly as smooth.
Now, that doesn't sound too reassuring...in a 24Hz multiple and all? TBH, mVR is so dead smooth on XPSP3 for me that I'm in really no hurry to reinvent the wheel. Besides, I can't seem to be able to find a W7-compatible software firewall that would match my requirements, duh.

The only real improvement for me could be the support of HPET, that in combination w/ Fidelizer (http://www.windowsxlive.net/fidelizer) would allow me to lower the OS timer granularity much lower than on XP. This would make everyone happy: Reclock, mVR and my audio apps...XP is really not meant for realtime use, even when using the ACPI timer.

I sold off my C2Q parts for almost as much as I bought the i7 920 for. If money isn't for the things you want when you want them, what is it for? Do it Lee
Yeah, I've seen a second hand i7 920 for pretty cheap, but it's using a now obsolete 1366 socket...so if I get it, I won't be able to upgrade to a 2700K later on :(

Intel will be switching sockets within a few months again: http://www.legitreviews.com/news/11106/

Being a computer geek is a risky business, and zillions of them will be selling their 2700K for dead cheap shortly...I can wait :D

[cyberbeing]

madshi, there appears to be a very slight inaccuracy in your 10-bit to 32/64-bit to 8-bit conversion using 10-bit input from the madVR internal decoder (either that or x264 has an issue with 8-bit to 10-bit conversion). This is with calibration disabled. Took a screenshot of 8-bit & 10-bit in fullscreen (Catmull-Rom chroma) and measured screenshots with Photoshop's Color Sampler (11 by 11 average).

8-bit input w/ madVR on left, 10-bit input w/ madVR on right
(R-G-B)
0-0-0 -> 1-0-1
32-32-32 -> 33-32-33
127-127-127 -> 128-127-128
0-0-127 -> 1-0-128
0-127-127 -> 1-127-129
0-127-0 -> 0-127-1
...and so on.

AVS HD 709 (http://www.avsforum.com/avs-vb/showthread.php?t=948496) mp4 test pattern 3-Color Steps.mp4 (http://www.mediafire.com/?rj42sb90v9absx2) re-encoded as 10-bit 4:2:0 lossless (http://www.mediafire.com/?n7aznrunyq8ki5p).

[ryrynz]

Intel will be switching sockets within a few months again: http://www.legitreviews.com/news/11106/


I know, but we're in a world where everything is upgraded at such a rapid pace. As far as I'm concerned something is only obsolete when it doesn't do what you want :)

Being a computer geek is a risky business, and zillions of them will be selling their 2700K for dead cheap shortly...I can wait :D

Time consuming business and also fun at that, don't wait too long.

[yesgrey]

madshi, there appears to be a very slight inaccuracy in your 10-bit to 8-bit conversion
Did you disable dithering? Some fluctuations are due to dithering, so do not perform any values checking with it enabled.

[nevcairiel]

On another note, madshi could you make ISubRender subtitles get scaled with with the selected madVR luma/chroma resizers? If you set maximum texture size of 1280x720 and then playback fullscreen at 1920x1080, subtitles are very blurry. Do you even have control over that, or is it MPC-HC doing the blurry subtitle resizing with a lower texture size?

I don't think this is really possible. The subs need to be painted on the screen after scaling. What if my subs are rendered at 1920x1080, are they supposed to be scaled down to fit my 1280x720 video image? madVR does not know at what size the subtitles are rendered at.

All madVR does is tell MPC-HC to draw the subs onto the (otherwise finished) image. MPC-HC does all the subtitle scaling. It may be possible to actually get MPC-HC to do a bit sharper upscaling, instead of the extremely blurry version it has now - but its not something that madVR can influence.

If i were to change MPC-HC to do sharper scaling, i'm sure some people would complain because they like blurry, so i guess it would need a UI option, too... meh.

[cyberbeing]

Did you disable dithering? Some fluctuations are due to dithering, so do not perform any values checking with it enabled.

Yes, I measured both with dithering enabled and dithering disabled before I made my previous post. The problem was actually much more obvious (looking a 16-bit color values in Photoshop instead of 8-bit) with dithering disabled since the values were more stable and even. I also measured FFDShow 10-bit -> 8-bit YV12 output which didn't exhibit the issue, so this seem to be something unique madVR is doing with 10-bit input.

@nevcairiel
Thanks for the info, I was somewhat suspecting it was a MPC-HC issue. It really depends on the subtitles in question, some are almost acceptable with 1280x720 tex size @ 1920x1080 others I need to strain my eyes to read because they almost unreadable blurry. The main cause seems to be when a subtitle line has a \blur or \be already applied to it... That could mean it's a bug with how MPC-HC scales blur and blur-edge, but I don't really know. Anyway, this is no longer a madVR topic it seems.

[ForceX]

You may want to ask JanWillem32 since he is working on updating MPC-HC's subtitle renderer now.

[Volfield]

Is the Intel 3150 is supported? I have "creating Direct3D device failed (8876086c)" error when trying play movie.

[rahzel]

I'm playing around with the luma scaling options and I'm kind of confused. I have 1080p and 720p versions of the same clip and my display's native resolution is 1360x768, so madVR has to scale both videos right? And would I be right in assuming that madVR would apply luma upscaling to the 720p video and luma downscaling to the 1080p video? If so, this is what confuses me... tweaking the luma upscale option seems to have no affect on the 720p video -- changing the luma downscale option, however, does affect the 720p video. With luma downscaling set to bilinear, the 720p video looks noticeably softer than the 1080p video, but with luma downscaling set to bicubic, the 720p video is almost indistinguishable from the 1080p video.

I was hoping that I could leave luma downscaling to bilinear because bicubic downscaling makes 1080p video unplayable on my machine (but it's fine for 720p).

[madshi]

Just a hint - noticed, if you enable the madVR internal decoders and let ffdshow as preffered external video decoder ( you want to use ffdshow ), the CPU usage doubles. So it looks like the internal decoders are still on, inspite of the fact they should be blocked by the ffdshow video decoder, if ffdshow video decoder is set to prefer in the external filter list. Could you pls test this?
Just tested that, can't reproduce it. Doesn't make any sense, either, cause when ffdshow decodes, madVR isn't even getting the video bitstream, so the madVR internal decoder doesn't have any feed to work on.

ffdshow video 3949:
MPEG2 - no A/V issues ( libavcodec )
VC-1 - occasional A/V issues ( libavcodec ), but no A/V issues with wmv9
H.264 - no A/V issues ( libavcodec )

madVR 0.71 internal decoders:
MPEG2 - no A/V issues ( libavcodec )
VC-1 - no A/V issues ( libavcodec )
H.264 - no A/V issues ( libavcodec )
Looks goo to me... :)

Oh, I've hardly ever encountered freezes between mVR and PotPlayer :confused:

Lemme know if you want me to whine about anything on the official korean forum.
Not needed, already fixed in my sources.

OK, neato! the only 2 things I would currently need in mVR are:
-proper colors in PC range RGB32(just like in 0.67)
-a way to get automatic PC range YV12(w/ proper colors of course), either through an "assume PC range for YCbCr" or "remember last YCbCr levels range".
In the next build you'll be able to create an empty file named "force full range input" in the madVR folder, which will make madVR always auto select full range input. You can still change input range via keyboard shortcut, of course. Before you ask: No similar hacks coming for gamut, though.

when using internal decoders and playing MPEG2 video, OSD via CTRL+J shows @ "every frame repeat" numbers like 41.67s or 41.57 etc. The playback is smooth.

Im asking because...
Maybe I missed something, but where is your question?

Is this the 'Microsoft DTV-DVD Video Decoder' in the external filters?
No, in XP it's named "WMVideo Decoder DMO". Don't recall right now what the name is in win7.

If not, how can I ensure the decoder you're referring to is used for VC-1 content?
By setting it to "preferred" in the MPC-HC external filter list.

More importantly, is there a way to make sure it's used for VC-1 and NOT h264 should I choose to use madVR's h264 decoder....
The WMVideo Decoder DMO only decodes VC-1, not h264, so there's no conflict.

FYI the "delay playback start..." option in V0.71 causes video playback to stall in MC16
Works just fine here. Can anybody else reproduce the problem?

Yes, I have tried different splitters, decoders (Win decoders vs 3rd party), renderers, players, different video formats, different hard drives, even different laptops. All lead to the same conclusion, it only occurs with madVR and even when I lower the scaling algorithms.

That was the first thing I noticed when I moved to Win7 from XP this month, that video playback with madVR was not nearly as smooth. But like I mentioned before, it's just something to live with....
I'm confused. Originally you reported a problem only during playback *START*. Now you're saying video playback is generally not as smooth??

I did have a crash instantly while watching particular movies, so I'd like to provide logs, but I never see any...
If you have crashes, logs don't help as much. In that case a sample with which I can reproduce the crash would help MUCH more.

I've enabled MPEG2 decoding with MadVR and found when opening a VOB from any of my DVD rips the audio ends up being out of sync and after seeking the video speeds up and stutters.
I'm using Lav splitter/audio 0.30 and I'm having no issues with playback when switched to ffdshow for decoding.
Which madVR version did you use? v0.70 contains an improvement for MPEG2 which might already have fixed this (if you tested with an older madVR build).

Once you find and fix this bug, maybe you should make it an optional feature. ;)
I'm actually beginning to like videos opening paused, since it gives me a chance to enter fullscreen before starting playback.
I don't consider an option "make media player start paused". Such features should be provided by the media player, not by madVR.

On another note, madshi could you make ISubRender subtitles get scaled with with the selected madVR luma/chroma resizers?
All madVR does is tell MPC-HC to draw the subs onto the (otherwise finished) image. MPC-HC does all the subtitle scaling.
Yep. madVR doesn't do *anything*. All the work is done by MPC-HC. So there's nothing I can do to improve subtitle quality.

madshi, there appears to be a very slight inaccuracy in your 10-bit to 32/64-bit to 8-bit conversion using 10-bit input from the madVR internal decoder (either that or x264 has an issue with 8-bit to 10-bit conversion).
I've double checked. The raw unprocessed YCbCr output of the h264 decoder is:

8 bit black, Y: 16, Cb: 128, Cr: 128
8 bit white: Y: 235, Cb: 128, Cr: 128
10 bit black, Y: 64, Cb: 514, Cr: 514
10 bit white: Y: 943, Cb: 514, Cr: 514

Now let's check what the BT.709 specification says:

Black level, 8bit: 16, 10bit: 64
Achromatic, 8bit: 128, 10bit: 512
Nominal peak, 8bit: 235, 10bit: 940

Seems to me the 8bit -> 10bit conversion you've done is broken.

Is the Intel 3150 is supported? I have "creating Direct3D device failed (8876086c)" error when trying play movie.
madVR needs PixelShader 3.0 hardware support. Seems the Intel 3150 can't do that.

I'm playing around with the luma scaling options and I'm kind of confused. I have 1080p and 720p versions of the same clip and my display's native resolution is 1360x768, so madVR has to scale both videos right? And would I be right in assuming that madVR would apply luma upscaling to the 720p video and luma downscaling to the 1080p video? If so, this is what confuses me... tweaking the luma upscale option seems to have no affect on the 720p video -- changing the luma downscale option, however, does affect the 720p video. With luma downscaling set to bilinear, the 720p video looks noticeably softer than the 1080p video, but with luma downscaling set to bicubic, the 720p video is almost indistinguishable from the 1080p video.
What does the madVR OSD (Ctrl+J) say about source resolution and target rectangle when playing your 720p video?

[pankov]

madshi, guys,
I need to rotate some video files (digital camera / smartphone) but I couldn't do it when I use madVR. With EVR everything is working as expected in MPC-HC.
So the question is did I do something wrong or the rotation (at least in the Z axis) is something that the renderer must support / do?
I mainly use ZoomPlayer but it doesn't have such feature so I'm using MPC-HC for it but it didn't work there too so I'm lost now.
madshi,
if it happens to be a feature of the renderer do you plan on adding it?

[leeperry]

In the next build you'll be able to create an empty file named "force full range input" in the madVR folder, which will make madVR always auto select full range input. You can still change input range via keyboard shortcut, of course.
OK, great! I don't think I'll be only one enjoying full range video. I'm looking forward a fully PotP-compatible mVR build then :)

Before you ask: No similar hacks coming for gamut, though.

No worries, really! I completely overlooked that RGB32 support in mVR would allow me to use rgb3dlut() again, and when using YUY2 LUT's it basically does the RGB conversion for free(God knows using what miracle :confused:), and tritical's yv12toyuy2() allows me to specify the YV12>YUY2 bicubic interpolation coeff, so together w/ mVR's own scaler settings and rgb3dlut() bicubic scaling settings that really enables me to perfectly finetune the sharpness of the picture. Your 0.33/0.33 advise looks amazing in yv12toyuy2(), and so does 1.0/0.0 in rgb3dlut(): I can't believe how crispy(but not oversharpened) the PQ currently looks on my rig. The last problem w/ yv12toyuy2() was that it's mod4 only, but Gavino wrote an automatic script that adds black borders in order to become mod4....I've put all my LUT's on a ramdisk, and presto! automatic ffdshow profiles based on resolution/frame rate and filename tags, perfect sharpness/smoothness and 3DLUT based corrections on the get go...I couldn't be happier http://forum-images.hardware.fr/images/perso/ayuluna.gif

[joe42]

Subtitles work fine with MPC-HC (1.5.2.3456), even with madVR v0.71 set as the renderer. However, as soon as I add madVR to the external filters list (so that madVR can do video decoding), set it to "prefer", and restart MPC-HC, the subtitles disappear and the MPC-HC subtitle menu is disabled (greyed out). If I set the madVR external filter from "prefer" to "set merit" and restart MPC-HC, subtitles are working again but madVR can no longer do decoding. Switching madVR external filter back to "prefer" and restarting MPC-HC again disables subtitles. All repeatable.

Am I doing something wrong, or is this a bug in madVR or MPC-HC?