madVR - high quality video renderer (GPU assisted)

[sneaker_ger]

Doesn't change the problem.
But by moving the mouse downwards I saw the controls activate, just like in full screen window mode, and ctrl+j indeed says "window mode".

[QBhd]

I understand what you say, but not sure about that expansion to 0-255 on madVR and display to be that beneficial in terms of accuracy, quality levels... etc. Well depends on the point of view. Im in the believing that everything should match to the source, with less adds, conversions, etc as possible.

If filmakers or bluray editors go 16-235, that way should be taken. Kinda like the frame interpolators on some devices. Some -uneducated on films and cinema- people think its better that soap opera, and they even may like it. Well, I know this is a much major change to the original source opossed to the 16-325 > 0-255 conversion, but it shares the same logic to be avoided. Its not if it will lokks better or worse (something subjective BTW), but the fact to modifying anything to the source as it was intended to be played back.

So, better gradation level with 0-255 over 16-235? yes, but from a "purist" point of view, better go with 0-255 when the video source be encoded that way. Just like the 48fps for smoother video; go with it when films -like The Hobbit- will be filmed and intended that way to be seen. The best reproduction is to take strictly what theres on the source, no more no less, IMHO.

Think what you want... I was just passing along info that has already been posted and discussed on these forums over and over. The defualts of madVR is "PC Levels" and should only be changed to "TV Levels" if your TV does not support "PC Levels".

QB

[Budtz]

If I set madvr to pc levels (0-255) I get correct blacks and no washed out colors. But I still get it if I use vlc. Changing the setting to full in NVidia setting thou corrects this. Will this change how madvr behaves? There are also to other settings in the NVidia control panel "dynamic contrast enhancement" and "color enhancement" which I have disabled. What do these do?

I now have lav filters NVidia drivers and madvr set on full. Is this correct?
It seems the Nvidia-setting for pc-levels or tv-levels has no bearing on PQ in madvr yes?
Also it just seems like Nvidia is trying to make PQ as bad as possible with bugs they won’t fix and strange washed out default settings.

[kalston]

I understand what you say, but not sure about that expansion to 0-255 on madVR and display to be that beneficial in terms of accuracy, quality levels... etc. Well depends on the point of view. Im in the believing that everything should match to the source, with less adds, conversions, etc as possible.

If filmakers or bluray editors go 16-235, that way should be taken. Kinda like the frame interpolators on some devices. Some -uneducated on films and cinema- people think its better that soap opera, and they even may like it. Well, I know this is a much major change to the original source opossed to the 16-325 > 0-255 conversion, but it shares the same logic to be avoided. Its not if it will lokks better or worse (something subjective BTW), but the fact to modifying anything to the source as it was intended to be played back.

So, better gradation level with 0-255 over 16-235? yes, but from a "purist" point of view, better go with 0-255 when the video source be encoded that way. Just like the 48fps for smoother video; go with it when films -like The Hobbit- will be filmed and intended that way to be seen. The best reproduction is to take strictly what theres on the source, no more no less, IMHO.

In my experience most computer displays (NOT TVs) need to be fed 0-255 by madVR otherwise the blacks are just grey (and you can see a big contrast with the black bars at the top and the bottom of the screen if it's not a 16/9 film) and overall the colours are just not good at all.

I'm comparing those colours to when I watch the same film on a TV or at the theatre.

[DragonQ]

Computer monitors almost universally need 0-255. Out of the two main TVs I use, one apparently accepts both with absolutely no difference (if you change it on the PC, nothing happens at all on the TV, not even a brief flash or blue screen like you get when changing refresh rates). The other accepts both but with 0-255 producing a noisy picture and 16-235 slightly crushing blacks and whites. :/

[mark0077]

Thanks, that's definitely a different problem. It's related to the "delay playback until render queue is full" feature. Can you reproduce it somewhat regularly? I have a thought about how I could maybe fix it, but I'm a bit afraid to do the change if we don't have a way to test if the change really helped. After all, the change could make things worse. This is one of those cases where there's not a real bug in madVR, but it's some kind of threading interaction. So a change could help, or make things worse, or not make any difference.


I tried reproducing this by seeking like crazy, when queues were completely full and also when semi-full. I can't reproduce it :( It'd be great if we had a way to put mpc-hc / madVR through some sort of stress test like put it through lots of window <-> fullscreen changes, and lots of seeks perhaps... If I find a way to reproduce consistently I'll let you know.

EDIT: Actually I reproduced a freeze, again I'm not sure if its the known mpc-hc one or something else. It happened opening a file when another one was already playing (after killing mpc-hc using task manager, it reopened and started playing the other file, so it seemed to hang on shutdown / exit of the originally playing file). Not sure if its useful but its attached below. I'll also see can I come up with a sequence of events that definitely reproduces it but I doubt it somehow.

http://www.mediafire.com/?b9taoqjkqsbz1at

[Libeluratio]

Hello madshi and everyone :)

First madshi I would like to thank you for creating such a good renderer madvr is !

I am currently experiencing dropped frames/presentation glitches while playing 23.976 mkvs.

I've tricked nvidia drivers to get 23.97622hz from my gt430 but with that I get 3-4 dropped frames per movie.

So I tried to use madvr tweaks and managed in a 2h30 movie to get 0 dropped frames/presentation glitches ! O_o :eek::p:D

For that, I had to tick:

-Disable desktop composition
-Use a separate device for presentation

and the 3 options not to use "unless you absolutely need them for glitch free playback" which are:

-run presentation in a separate thread
-limit rendering times to avoid glitches
-overshooot max frame latency


I've ticked all of these options in one time, I've not tried yet ticking only some of them.

But I would like to kknow what exactly does these options ? Because I really understand nothing and really would like to :)

Also, would modifying the number of video frames that should be presented in advance help me in getting 0 dropped frames/presentation glitches, if I disable some of the options below ?

Thank you so much for helping the French newbie I am ! :)

[xv]

How can I reproduce the problem on my PC? I guess the best way would be to have the same sample available as YCgCo and as e.g. BT.709? Then I can check whether they look perfectly identical or not.
You'll see the problem very clearly in this sample (colorbars from avisynth):
http://www.mediafire.com/?yq64u7jl2muo9bs (file is only 10KB)

[robpdotcom]

In windowed mode > toggle video/film mode > enter FSE > madVR will not change refresh rate.

I need much more details. Which kind of video file are we talking about? 50i? 60i? Which was your refresh rate when before you started playback. Did madVR switch when you toggled video/film mode in windowed mode? Then when you entered FSE mode, which refresh rate was activate and what should madVR have done? How have you configured the madVR display mode changer? Maybe a log would help...

Sorry, I should know better by now.

The file is 59i. I open files in windowed mode, and madVR is configured to change refresh rate when entering fullscreen, with the following modes: 1080p23, 1080p24, 1080p50, 1080p59, 1080p60. Automatic source type detection is enabled, automatic deinterlacing is enabled (if in doubt, deactivate deinterlacing).

The refresh rate starts at 23Hz > open a 59i file in windowed mode > enter fullscreen > madvr switches to 59Hz.

(I realize this example is probably very uncommon) Refresh rate starts at 23Hz > open a 59i file in windowed mode > switch to film mode > switch to fullscreen > switch back to windowed mode > switch to video mode > enter fullscreen > madVR does not change refresh rate (should switch to 59Hz).

I start at 59Hz, open a 59i file in windowed mode, switch to film mode > enter fullscreen > madVR does not change refresh rate (should switch to 23Hz).

For all examples above the file name does not have any tag (23p, 59i, etc).

[06_taro]

madshi, could you please make an explanation of file name token for the de-interlacing mode?

I have a file of 1280x720 at 30/1.001fps progressive. The encoder tagged the file name with "1280x720p30", and madVR (v0.82.4) automatically actives de-interlacing when playing it (OSD says "deinterlacing on [override]"), even if I uncheck "automatically active deinterlacing when needed" in the config page. As long as the file path has "p30" token, de-interlacing cannot be deactived without Ctrl+Alt+Shift+D.

With 24/1.001fps file tagged p24, this issue does not appear.

[Andy o]

try instead "30fps" and see if it fixes it? Though I don't understand either why "30p" should force deinterlacing.

[kerman]

In my experience most computer displays (NOT TVs) need to be fed 0-255 by madVR otherwise the blacks are just grey (and you can see a big contrast with the black bars at the top and the bottom of the screen if it's not a 16/9 film) and overall the colours are just not good at all.

I'm comparing those colours to when I watch the same film on a TV or at the theatre.

Agree on most what you say. PC monitors must always be fed with 0-255. But maybe they're not the best kind of display to watch movies. On a tv, capable of both 0-255 and 16-235, the source native range should be used. The least alteration of the source data, the better.

Im in the strongly believing, trying to "improve" the quality of the source by filtering/alterating/adding/modifying anything, is the wrong way to go. Noise reduction, dinamyc ranges, frame interpolators, extended color ranges... etc. You may like it better or not, thats understandable. But from a purist point of view, any trusted source is meant to be played back as it is, just taking care of the best reproduction as posible, but not altering any of it. Even if its "intended to improve quality". WRONG!

If a movie is 23.976fps, playback at that speed, dont interpolate to make it "smoother". If its grainy dont mess it up with noise reduction just becouse you think it looks better. If its B/W, dont colour it. If its mono or stereo, listen it that way. If its shot or edited on a color range, use that one.

As cinefile or enthusiast, Im just concerned on having a well calibrated setup, and get the most accurate reproduction of the source as it is, altering it the little as possible to nothing.


Computer monitors almost universally need 0-255. Out of the two main TVs I use, one apparently accepts both with absolutely no difference (if you change it on the PC, nothing happens at all on the TV, not even a brief flash or blue screen like you get when changing refresh rates). The other accepts both but with 0-255 producing a noisy picture and 16-235 slightly crushing blacks and whites. :/

A well done calibrating shoud fix those crushed black/whites.

[TheLion]

Hi madshi,

I continue to have the exact same issue. I am using JRiver Media Center (latest beta - but it has been this way all along).

When using D3D11 and in FSE mode moving the cursor to the upper end of the screen in order to open the Media Center seek bar (which would enter windowed mode) the screen freezes, the sound continues to play. After a few seconds playback continues in FSE mode.

Strange is that when pressing the right mouse button in FSE to enter the media center OSD in switches to windowed mode without a problem. That way I can access the seek bar as well.

This only happens when D3D11 is used - and is repeatable.

I had that same problem with D3D11 FSE back when i tried using it. That was the main reason i didn't use it anymore. I reported it back then and you acknowledged the problem with the remark that D3D11 is just glitchy sometimes.

It plays fine, but when you try to leave the FSE mode by double clicking the screen (or any other hotkey that toggles between full screen and window) the last rendered picture just sticks on the screen, and you see nothing else (no MPC-HC GUI or anything else).
The file seems to continue playing just fine in the background, and when you hit the hotkey again to re-enter full screen mode, the screen updates again.

Back then, for me it was a 100% reproducable case, D3D Fullscreen in MPC-HC was not ticked.
The funny fact is that right-clickign to bring up the popup menu properly leaves FSE mode, just using a hotkey to directly go back to windowed mode didn't work.

[06_taro]

try instead "30fps" and see if it fixes it? Though I don't understand either why "30p" should force deinterlacing.

Yes, I've already suggested the encoder re-tag it "30fps" to fix it. But I couldn't understand why p30/30p resulted in force deinterlacing when the file is actually 30fps progressive, and he seems don't like reporting issues, so I posted here. :rolleyes:

[kalston]

But maybe they're not the best kind of display to watch movies.

Yeah absolutely, but I guess madshi made it the default because he assumed most people would be using a monitor.

And agreed on the other points - I'm also one who believes in processing-free, bit-exact playback when possible.

[TheShadowRunner]

Hi madshi, it seems there's a bug with 4/3 Aspect ratio for certain AVI files.
A sample: http://videoff7.free.fr/madVR_AR_sample.avi
It appears stretched when played with madVR.
When played with any other renderer, it looks OK.
I'm testing with ZP, AR set to "Derived" in ZP settings, but the same flaw shows up with graphstudio.
See you,

TSR
Edit: hmm after more testing, looks like it could be a ZP bug, not sure..

[madshi]

Doesn't change the problem.
But by moving the mouse downwards I saw the controls activate, just like in full screen window mode, and ctrl+j indeed says "window mode".
Ok. I'll put this on my to do list. But I don't really know how easy that will be to fix. I might need help from the media player. Which means I might have to add something to MPC-HC and ask the other media player devs to do a similar thing. That might take a while...

I tried reproducing this by seeking like crazy, when queues were completely full and also when semi-full. I can't reproduce it :( It'd be great if we had a way to put mpc-hc / madVR through some sort of stress test like put it through lots of window <-> fullscreen changes, and lots of seeks perhaps... If I find a way to reproduce consistently I'll let you know.
Ok, thx.

EDIT: Actually I reproduced a freeze, again I'm not sure if its the known mpc-hc one or something else. It happened opening a file when another one was already playing (after killing mpc-hc using task manager, it reopened and started playing the other file, so it seemed to hang on shutdown / exit of the originally playing file). Not sure if its useful but its attached below. I'll also see can I come up with a sequence of events that definitely reproduces it but I doubt it somehow.

http://www.mediafire.com/?b9taoqjkqsbz1at
That appears to be a freeze in MPC-HC itself, totally unrelated to madVR. I'll post information to the MPC-HC thread about this. Maybe an MPC-HC devs wants to look into the problem.

I am currently experiencing dropped frames/presentation glitches while playing 23.976 mkvs.

I've tricked nvidia drivers to get 23.97622hz from my gt430 but with that I get 3-4 dropped frames per movie.

So I tried to use madvr tweaks and managed in a 2h30 movie to get 0 dropped frames/presentation glitches ! O_o :eek::p:D

For that, I had to tick:

-Disable desktop composition
-Use a separate device for presentation

and the 3 options not to use "unless you absolutely need them for glitch free playback" which are:

-run presentation in a separate thread
-limit rendering times to avoid glitches
-overshooot max frame latency

I've ticked all of these options in one time, I've not tried yet ticking only some of them.

But I would like to kknow what exactly does these options ? Because I really understand nothing and really would like to :)
These 3 options are hacks to work around NVidia driver problems. The first option presents frames in a separate thread instead of presenting them in the context of the render thread. The 2nd option avoids starting a pixel shader rendering pass when the next vsync interrupt is near. And the last option just modifies the D3D settings a bit.

If you have zero problems with these settings, and audio/video stay in sync, then I guess it's ok for you to use these settings. But I generally do recommend to use those 3 options only if absolutely necessary. So maybe you want to try tricking NVidia into using an ever so slightly higher refresh rate (e.g. 23.977hz instead of 23.97622hz). That may possibly get rid of those 3 frame drops without having to use those 3 tweak options.

Also, would modifying the number of video frames that should be presented in advance help me in getting 0 dropped frames/presentation glitches, if I disable some of the options below ?
I don't know, it depends on which reason those 3 drops have. 3 drops in a full movie isn't that much, so my best guess would be that your refresh rate is ever so slightly too low. You can't full rely on the number, only. The audio hardware clock plays a role, too, so it's possible you need to increase the refresh rate slightly to match the audio hardware clock.

You'll see the problem very clearly in this sample (colorbars from avisynth):
http://www.mediafire.com/?yq64u7jl2muo9bs (file is only 10KB)
Thanks, I'll have a look at that.

The file is 59i. I open files in windowed mode, and madVR is configured to change refresh rate when entering fullscreen, with the following modes: 1080p23, 1080p24, 1080p50, 1080p59, 1080p60. Automatic source type detection is enabled, automatic deinterlacing is enabled (if in doubt, deactivate deinterlacing).

The refresh rate starts at 23Hz > open a 59i file in windowed mode > enter fullscreen > madvr switches to 59Hz.

(I realize this example is probably very uncommon) Refresh rate starts at 23Hz > open a 59i file in windowed mode > switch to film mode > switch to fullscreen > switch back to windowed mode > switch to video mode > enter fullscreen > madVR does not change refresh rate (should switch to 59Hz).

I start at 59Hz, open a 59i file in windowed mode, switch to film mode > enter fullscreen > madVR does not change refresh rate (should switch to 23Hz).

For all examples above the file name does not have any tag (23p, 59i, etc).
Thanks. Now that's what I call a proper bug report... :) I'll look into it.

madshi, could you please make an explanation of file name token for the de-interlacing mode?

I have a file of 1280x720 at 30/1.001fps progressive. The encoder tagged the file name with "1280x720p30", and madVR (v0.82.4) automatically actives de-interlacing when playing it (OSD says "deinterlacing on [override]"), even if I uncheck "automatically active deinterlacing when needed" in the config page. As long as the file path has "p30" token, de-interlacing cannot be deactived without Ctrl+Alt+Shift+D.

With 24/1.001fps file tagged p24, this issue does not appear.
That sounds like a simple bug, should be easy for me to fix. madVR is only supposed to behave that way if the tag is p24/24p and if the source is 60i.

On a tv, capable of both 0-255 and 16-235, the source native range should be used. The least alteration of the source data, the better.

Im in the strongly believing, trying to "improve" the quality of the source by filtering/alterating/adding/modifying anything, is the wrong way to go. Noise reduction, dinamyc ranges, frame interpolators, extended color ranges... etc. You may like it better or not, thats understandable. But from a purist point of view, any trusted source is meant to be played back as it is, just taking care of the best reproduction as posible, but not altering any of it.
While I agree with the general concept of avoiding any unneeded alteration, some things you can't avoid. The source is YCbCr 4:2:0, but every display "outputs" RGB to your eyes. So chroma upsampling and YCbCr -> RGB color conversion is one thing you absolutely cannot avoid.

Furthermore, you seem to have the understanding that the source is 16-235, so it should also be displayed that way. That's not how TVs/monitors are working. You need to separate the format of the data transfer from the actual physical display. Your HTPC sends pictures to the TV, and the TV internally interprets that so that the physical LCD or plasma or whatever cells show the proper light and color intensities. Now here comes the important part: Once you've converted YCbCr to RGB, you have floating point numbers. If your HTPC were able to send floating point numbers to your TV, then it wouldn't matter at all whether black is defined to have a value of 0.0 or of 16.0/256.0 or whatever. As long as the TV knows which value the HTPC is considering to be "black", the whole image data could be treated correctly without any change in image quality.

Let's say we have a plasma display, whose pixel cells can show maybe 1000 different light intensities. The number of possible light intensities almost never will match exactly 235-16 = 219 steps. With any good TV/monitor it should be noticeably higher. So if your HTPC sends 16-235, then the plasma will show HTPC value 16 as the darkest possible light intensity and it will show 235 as the highest possible light intensity, spreading the values 17-234 somewhere in between. Of course it depends on the brightness and contrast controls in the plasma, but that's roughly how it should be. Now imagine your HTPC sends 0-255 instead. So what will happen then? If your plasma knows that 0 is supposed to be black, then it will show 0 with the darkest possible light intensity and 255 with the highest possible light intensity. If you think about it, it doesn't really matter at all whether you send 16-235 or 0-255, as long as your plasma knows what it's receiving, the image quality should be the same.

Now you might say: The source was 16-235, so we should also send 16-235 to the TV to have the lowest amount of conversion. But here you're forgetting that after YCbCr -> RGB conversion you don't have 8bit integer values, anymore. Instead you have floating point values. These floating point values need to be converted back to 8bit integer (no way around it) and whether you convert them to 0-255 or 16-235 doesn't make much difference at all. Stretching 16.0/255.0 - 235.0/255.0 to 0.0/255.0 - 255.0/255.0 in floating point is perfectly lossless.

I continue to have the exact same issue. I am using JRiver Media Center (latest beta - but it has been this way all along).

When using D3D11 and in FSE mode moving the cursor to the upper end of the screen in order to open the Media Center seek bar (which would enter windowed mode) the screen freezes, the sound continues to play. After a few seconds playback continues in FSE mode.
I'm not sure if I can fix it on my own, I might need the help of the J.River guys. I'll put this on my to do list.

Hi madshi, it seems there's a bug with 4/3 Aspect ratio for certain AVI files.
A sample: http://videoff7.free.fr/madVR_AR_sample.avi
It appears stretched when played with madVR.
When played with any other renderer, it looks OK.
I'm testing with ZP, AR set to "Derived" in ZP settings, but the same flaw shows up with graphstudio.
See you,

TSR
Edit: hmm after more testing, looks like it could be a ZP bug, not sure..
I'll have a look.

[Andy o]

Agree on most what you say. PC monitors must always be fed with 0-255. But maybe they're not the best kind of display to watch movies. On a tv, capable of both 0-255 and 16-235, the source native range should be used. The least alteration of the source data, the better.

On a tv, capable of 0-255 and 16-235, 0-255 is still recommended with madVR. If you're using a PC, 0-255 is native. Video will have to decode to that. Currently graphics cards can't pass through YCbCr, and even if they did, it would still need to upscale chroma to at least 4:2:2. (There was some speculation about them doing it with protected video path with TMT and PowerDVD for blu-ray content, but there wasn't anything definitive, just some tests which showed an ATI bug with RGB->YCbCr conversion wasn't happening in these particular cases.) You're better off just converting to RGB 0-255 to match PC output with madVR.

Unless of course you set your PC output to 0-255 and madVR to 16-235 (and your TV input), and have black crush and white clipping everything that's not video.

[TheLion]

I'm not sure if I can fix it on my own, I might need the help of the J.River guys. I'll put this on my to do list.




madshi,

your http://madshi.net/madVR824e.zip test version fixed my issue in JRiver. Now I can use D3D11 and the switch to windowed mode for displaying the OSD seek bar works flawlessly. Please consider making those changes permanent with the next revision.
Thank you!

[madshi]

Hi madshi, it seems there's a bug with 4/3 Aspect ratio for certain AVI files.
A sample: http://videoff7.free.fr/madVR_AR_sample.avi
It appears stretched when played with madVR.
When played with any other renderer, it looks OK.
I'm testing with ZP, AR set to "Derived" in ZP settings, but the same flaw shows up with graphstudio.
See you,

TSR
Edit: hmm after more testing, looks like it could be a ZP bug, not sure..
Weird. Sometimes I get one AR in ZP, sometimes another. I could reproduce the same thing with VMR9 windowed mode in ZP, so it doesn't seem to be a madVR problem.

your http://madshi.net/madVR824e.zip test version fixed my issue in JRiver. Now I can use D3D11 and the switch to windowed mode for displaying the OSD seek bar works flawlessly. Please consider making those changes permanent with the next revision.
Will do.

[kerman]

While I agree with the general concept of avoiding any unneeded alteration, some things you can't avoid. The source is YCbCr 4:2:0, but every display "outputs" RGB to your eyes. So chroma upsampling and YCbCr -> RGB color conversion is one thing you absolutely cannot avoid.

Furthermore, you seem to have the understanding that the source is 16-235, so it should also be displayed that way. That's not how TVs/monitors are working. You need to separate the format of the data transfer from the actual physical display. Your HTPC sends pictures to the TV, and the TV internally interprets that so that the physical LCD or plasma or whatever cells show the proper light and color intensities. Now here comes the important part: Once you've converted YCbCr to RGB, you have floating point numbers. If your HTPC were able to send floating point numbers to your TV, then it wouldn't matter at all whether black is defined to have a value of 0.0 or of 16.0/256.0 or whatever. As long as the TV knows which value the HTPC is considering to be "black", the whole image data could be treated correctly without any change in image quality.

Let's say we have a plasma display, whose pixel cells can show maybe 1000 different light intensities. The number of possible light intensities almost never will match exactly 235-16 = 219 steps. With any good TV/monitor it should be noticeably higher. So if your HTPC sends 16-235, then the plasma will show HTPC value 16 as the darkest possible light intensity and it will show 235 as the highest possible light intensity, spreading the values 17-234 somewhere in between. Of course it depends on the brightness and contrast controls in the plasma, but that's roughly how it should be. Now imagine your HTPC sends 0-255 instead. So what will happen then? If your plasma knows that 0 is supposed to be black, then it will show 0 with the darkest possible light intensity and 255 with the highest possible light intensity. If you think about it, it doesn't really matter at all whether you send 16-235 or 0-255, as long as your plasma knows what it's receiving, the image quality should be the same.

Now you might say: The source was 16-235, so we should also send 16-235 to the TV to have the lowest amount of conversion. But here you're forgetting that after YCbCr -> RGB conversion you don't have 8bit integer values, anymore. Instead you have floating point values. These floating point values need to be converted back to 8bit integer (no way around it) and whether you convert them to 0-255 or 16-235 doesn't make much difference at all. Stretching 16.0/255.0 - 235.0/255.0 to 0.0/255.0 - 255.0/255.0 in floating point is perfectly lossless.

My hat off for so much instructive and educational input. I got a deeper overall understanding on the whole picture now.

[sneaker_ger]

Ok. I'll put this on my to do list. But I don't really know how easy that will be to fix. I might need help from the media player. Which means I might have to add something to MPC-HC and ask the other media player devs to do a similar thing. That might take a while...

I can always use D3D9, so it's not really a problem for me.

[Pat357]

Mad,

I was tinkering about why apparently several VfW codecs don't work with Madvr : Huffyuv original vfw, Fraps original vfw, .....
The all play fine in EVR, but you'll get a stalled MPC with no image upon opening the file.

I think I found something to help you to make it work.
I almost can't believe it myself, but if I set the "color space converter" to prefer in MPC (force it), everything seems to work nicely.

This shows the Huffyuv_mt (codec HYMT) :
Without the color space converter the connection looks like :

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {CF49D4E0-1115-11CE-B03A-0020AF0BA770}
Filter: AVI Decompressor
Pin: XForm Out

- Connection media type:

Video: RGB32 1920x1080 10fps 663552kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB32 {E436EB7E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 8294400
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 663552000
dwBitErrorRate: 0
AvgTimePerFrame: 1000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 1
biBitCount: 32
biCompression: 0
biSizeImage: 8294400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 8d 27 00 00 00 00 40 42 0f 00 00 00 00 00 ..�'....@B......
0030: 28 00 00 00 80 07 00 00 38 04 00 00 01 00 20 00 (...€...8..... .
0040: 00 00 00 00 00 90 7e 00 00 00 00 00 00 00 00 00 .....�~.........
0050: 00 00 00 00 00 00 00 00 ........


With the color space converter, it looks like :

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {1643E180-90F5-11CE-97D5-00AA0055595A}
Filter: Color Space Converter
Pin: XForm Out

- Connection media type:

Video: RGB32 2048x1080 10fps 663552kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB32 {E436EB7E-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 8847360
cbFormat: 88

VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 663552000
dwBitErrorRate: 0
AvgTimePerFrame: 1000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 2048
biHeight: -1080
biPlanes: 1
biBitCount: 32
biCompression: 0
biSizeImage: 8847360
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 8d 27 00 00 00 00 40 42 0f 00 00 00 00 00 ..�'....@B......
0030: 28 00 00 00 00 08 00 00 c8 fb ff ff 01 00 20 00 (.......Èûÿÿ.. .
0040: 00 00 00 00 00 00 87 00 00 00 00 00 00 00 00 00 ......‡.........
0050: 00 00 00 00 00 00 00 00 ........


The obvious difference is :
- Without colorspace conv :
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)

and probably even more important :
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
The height should be a negative (<0) number !

In this case the color space converter "corrects" the wrong values.

I'll do more testing with other non-working VfW codecs, but I suspect this is the reason why it never worked.

Is there a way to make this work without the color space converter ?
(positive height and missing frame size info in the field "VIDEOINFOHEADER".)

PS. Do you have any idea why the color space conv. says RGB32 2048x1080, while the actual size is 1920x1080 ?

[TheShadowRunner]

Weird. Sometimes I get one AR in ZP, sometimes another. I could reproduce the same thing with VMR9 windowed mode in ZP, so it doesn't seem to be a madVR problem.

Thank you very much for looking into it.
I'm forwarding the bug to Blight, it looks likely to be a ZP bug after all.

[madshi]

I was tinkering about why apparently several VfW codecs don't work with Madvr : Huffyuv original vfw, Fraps original vfw, .....
Samples?

[Pat357]

Mad,

New reports :
I often see a red text in the left corner of my screen when switching from IVTC->VIDEO or the other way around while in FSE.
The text says something like "failed to reset D3Ddevice"

Doesn't appear to happen in windowed mode.

Because I can't remember the exact words, I made a log ;
The log says : "Render resetting Direct3D device failed (8876086c)

What I sometimes have is that after this "failed" message, the display changer doesn't set any frequencies anymore.
Until I restart the player, all content is played at the last set display freq., independent from the actual content.
Like I said, this doesn't always happen.

I created 2 logs :
- small one : when switching back to video, I get this error.
The image displayed looks like it has been pauzed, but if I go to windowed mode and/or back to FSE, the video plays again.

http://www.mediafire.com/file/c4r4wr4r8lcqn6c/madVR_log.7z

- bigger log : I went several times back and forward to switch between video/IVTC and windowed/FSE.
The same error was displayed 4 times IIRC.

http://www.mediafire.com/file/4jjnj6tt3fa13uo/madVR_log2.7z

[madshi]

@Pat357, D3D9 or D3D11?

[kerman]

For best results on interlaced material (1080/50i), is better select CoreAVC to do deinterlacing, or madVR? Should I select on CoreAVC deinterlacing on "Hardware" to let this way madVR deinterlacing it? Or isnt there any difference at all?

[madshi]

I don't know what the CoreAVC deinterlacing settings do exactly. I've mine set to "None (Weave)". You may have to manually enable deinterlacing because CoreAVC doesn't set any interlace related flags, unfortunately.

[kerman]

Yes it does...

DEINTERLACING
This specifies how interlaced material is handled by the CoreAVC decoder.

None (Weave) - Each output frame contains two fields, flagged as progressive.
Single Field - Each output frame contains one field. Only one frame is produced for each field pair.
Bob - Each output frame contains one field. Two frames are produced for each field pair.
Hardware - Each output frame contains two fields, flagged as interlaced to allow the video renderer to perform deinterlacing.
Aggressive - in addition to SEI messages and POC numbers, assume the source is interlaced if any interlaced coding tools are used (MBAFF, PAFF)

CoreAVC H.264 Video Decoder Configuration Properties Guide (http://corecodec.com/products/coreavc/guide)

[madshi]

madVR v0.82.5 released

http://madshi.net/madVR.zip

* improved D3D11 exclusive -> windowed switch slightly, still not great, though
* option "delay playback start..." now requires both GPU+CPU queues to be full
* fixed: YCgCo decoding matrix was not correct
* fixed: internal 4:4:4 decoding produced wrong colors (introduced in v0.81)
* fixed: display mode changer didn't always activate when entering fullscreen
* fixed: forcing deinterlacing + IVTC on was caused by 30p tag instead of 24p
* fixed: h264 media type parsing sometimes crashed
* fixed: crash when no filter in the chain provided frame rate information
* fixed: one thread was started per video frame (introduced in v0.82)
* maybe fixed: entering/leaving exclusive mode steals keyboard focus
FWIW, I've decided to stick to the extended version numbering scheme. Basically I'll update from e.g. v0.82.4 to v0.82.5 if the new build only contains bug reports and minor improvements. I'll go to v0.83.0 only when a bigger new feature is introduced. Using this numbering scheme gives me enough breathing room. With the old scheme, I would soon have reached v0.99, and would then have to go to v0.100 (which is kinda bad), because v1.0 is still too far away.

[mark0077]

Thanks a million madshi. The improved delay playback functionality is much appreciated! :D

[madshi]

So does it solve the problem for you?

[ryrynz]

Is there anyone that would not want to have playback delayed until the queues are filled?
The delay I have with even with Avisynth active is minimal when this is enabled, is the option worth being there now?

The improvement in 0.82.5 has fixed the laggy couple of seconds I used to have on initial playback. Nice!

Coming up to 3 years since the first version was officially released. It has come a long way, first version I used was 0.9 and I haven't looked back since.

[mark0077]

So does it solve the problem for you?

It works fantastic! Really nice improvement.

[dansrfe]

Whoa, madVR starts playback faster and without any lag in the first couple of seconds for me too. This is cool. Looks smooth as silk from the beginning :D

[aufkrawall]

Indeed, everything is smooth.
I have delayed playback enabled and delayed FSE disabled.

[Pat357]

@Pat357, D3D9 or D3D11?

always D3D9, I don't use D3D11.

[Mikey2]

Please pardon the "dumb" question, but I always assumed that I was correctly making use of madVR's IVTC functionality. However, after updating to 82.5 I do not see this new "cadence breaks" line in the OSD.

I have tried both 1080P/24 movies and 480i/30 DVD's.

I am using ReClock and I am using an NVidia 8600GT graphics card, ( I can go into more detail and post logs etc, but I fear I am missing something simple.)


Thanks much!
MikeY

PS - Reclock is playing nicely and I am not receiving any frame-drops according to the rest of the madVR OSD

[eMWu]

Could you please look into allowing PotPlayer to capture screenshots when using madVR? I asked Potplayer's dev about it and he told me to contact madvr's dev :)

[ryrynz]

This feature isn't high on his priority list, you can use windowed mode and take screenshots with the print Screen key or you can use FRAPS or MSI Afterburner for windowed/FSE captures.

[ajp_anton]

A comment about the 16-235 vs 0-255 on TVs...
You can think of it like this: The YUV components form a vector inside (and slightly beyond) the 3D space of RGB. Y goes straight through the diagonal R=G=B, and UV kind of tilt this vector sideways to form colors.
The pure grayscale 8-bit Y-vector will match perfectly with the 8-bit R=G=B, but add colors and it's not so easy anymore. It's no longer a simple 8bit->8bit conversion, it's a 24bit->24bit conversion.
So for perfectly black and white movies, keeping it as 16-235 is "better", because the resulting floating point rounded to 8-bit integers will fit perfectly, no actual rounding needed. Add colors and it's a big mess, and you're no longer guaranteed perfect matches anywhere. Might as well use 0-255 to have "slightly more" precision (10 bits would be even better).

[Pat357]

Mad,

Thx for the new version.
I did a quick check to see if I still get that error about "resetting Direct3D device failed (8876086c)" (the same as in my previous post).
I'm afraid I still get it this error message and found a way to 100% reproduce it.

file : 1.m2v - "whatever you do, deary, don't get married"

Here is what I did :
0) refresh rate is 60 Hz
1) open the m2v file in MPC-HC (file is probably 30i) -> 60Hz stays
2) go to FSE
3) go to film mode (default is video mode for me)
4) look in the upper left corner to the red error message : failed reseting Direct3D device"
5) screen looks as if someone has hit the "pause" key : there only is a static image. the refresh rate has changed to 48.
6) wait 10sec : nothing happens, static image stays
7) hit the space-bar to un-pause the video and it will continue to play.
8) press ctrl + C to close the file

Anyway, in case you added some more info to log with this version, I created a new, as short as possible, one.

http://www.mediafire.com/?6b74e5p2hgeg465

I use D3D9, not D3D11, "use separate device for presentation" is checked.
buffers : 16/12
present frames in advance : 6
delay playback till buffers are filled : yes

If you want more info, just let me know.

[ajp_anton]

About the subtitles disappearing with on-screen messages problem... looks like all issues are fixed when setting MPC-HC to "Sub pictures to buffer: 0".
Is there any downside to this setting?

[azaze1]

ever since 0.82.x I've had issues with extremely choppy playback. The screen goes black and is completely unwatchable, no audio or anything.

0.82.5 doesn't fix it for me. I've noticed it only happens when launching in full screen directly in exclusive mode.

If I launch a movie in non-full screen mode (MPC-HC latest version from today), then it plays fine, and I can even enter full screen exclusive mode from there without issue so long as the player was launched in windowed mode. The issue is when the player begins a file in full screen mode. In that case, I can switch to windowed mode by bringing up a context menu from MPC-HC and playback becomes smooth, but once I get rid of menu and player goes back to exclusive, the choppy playback comes back.

[ryrynz]

Have you tried changing your CPU and GPU queue settings? Delaying FSE by 3 seconds? Have you ticked delay playback until render queue is full?

[azaze1]

Have you tried changing your CPU and GPU queue settings? Delaying FSE by 3 seconds? Have you ticked delay playback until render queue is full?

It's severely messed up. I've paused and it's just flashing the same still screen over and over and over with black in between flashes. It's buggy, not really queuing issues.

EDIT: after 2 minutes of flashing while typing this... it's finally paused without flashing and I'm able to get into context menu to adjust madvr settings. FSE and delay playback till queue is full are both checked. I can try increasing the CPU/GPU queue settings now but I am not hopeful. This is behaving so strangely compared to 0.81.

[ryrynz]

What graphics hardware and driver version are you using? Have you tried launching files fullscreen in any other players? Might pay to make a log.

[azaze1]

What graphics hardware and driver version are you using? Have you tried launching files fullscreen in any other players? Might pay to make a log.

Radeon 6450
Corei3 2100

I don't have any other players installed. I've put 0.81 back and reset settings, everything is fine now. My gyration remote is losing it's ability to move the mouse on the Y axis so I'm having a hard time performing anything that can't be done with arrows and the enter function... so logging is too cumbersome for now.

[madshi]

Is there anyone that would not want to have playback delayed until the queues are filled?
The delay I have with even with Avisynth active is minimal when this is enabled, is the option worth being there now?
Technically, the option is a quite ugly hack. DirectShow doesn't really support a thing like that, so I hacked it in. The reason why it's an option (and not even enabled by default) is that there are some stability problems sometimes. Personally, I have it enabled, too. But until all problems are fully fixed, I can't enable it by default, let alone remove the option.

The improvement in 0.82.5 has fixed the laggy couple of seconds I used to have on initial playback. Nice!
It works fantastic! Really nice improvement.
Whoa, madVR starts playback faster and without any lag in the first couple of seconds for me too. This is cool. Looks smooth as silk from the beginning :D
Indeed, everything is smooth.
I have delayed playback enabled and delayed FSE disabled.
Glad to hear that!

Please pardon the "dumb" question, but I always assumed that I was correctly making use of madVR's IVTC functionality. However, after updating to 82.5 I do not see this new "cadence breaks" line in the OSD.
Is "deinterlacing" reported to be "on" or "off" in the OSD? Is a cadence shown at all (even "unknown"), or does the OSD say you're in video mode, maybe?

Could you please look into allowing PotPlayer to capture screenshots when using madVR? I asked Potplayer's dev about it and he told me to contact madvr's dev :)
This feature isn't high on his priority list, you can use windowed mode and take screenshots with the print Screen key or you can use FRAPS or MSI Afterburner for windowed/FSE captures.
^

It will come sooner or later, just not too soon, probably.

I did a quick check to see if I still get that error about "resetting Direct3D device failed (8876086c)" (the same as in my previous post).
I'm afraid I still get it this error message and found a way to 100% reproduce it.
Thx, I'll see if I can reproduce it here.

About the subtitles disappearing with on-screen messages problem... looks like all issues are fixed when setting MPC-HC to "Sub pictures to buffer: 0".
Is there any downside to this setting?
Good find, didn't know that. I'm not sure if there are any downsides to that setting. Maybe higher CPU consumption? I've no idea...

ever since 0.82.x I've had issues with extremely choppy playback. The screen goes black and is completely unwatchable, no audio or anything.

0.82.5 doesn't fix it for me. I've noticed it only happens when launching in full screen directly in exclusive mode.

If I launch a movie in non-full screen mode (MPC-HC latest version from today), then it plays fine, and I can even enter full screen exclusive mode from there without issue so long as the player was launched in windowed mode. The issue is when the player begins a file in full screen mode. In that case, I can switch to windowed mode by bringing up a context menu from MPC-HC and playback becomes smooth, but once I get rid of menu and player goes back to exclusive, the choppy playback comes back.
That's quite weird. Please watch the madVR OSD (Ctrl+J) to check if the display refresh rate is detected correctly right from the start? Maybe it stays at 0 all the time? Or shows an incorrect value?

Is the madVR display mode changer active? Does the problem go away if you disable it?

A debug log would probably help. I only need one from going straight to exclusive mode, with all the problems, then close the media player and send zip the log. Please don't try to "repair" the problem by opening the context menu or anything. Just log the faulty behaviour and close the media player after maybe 5 seconds of bad behaviour. That would make the log much easier for me to read. Thx.