madVR - high quality video renderer (GPU assisted)

[dansrfe]

I'm not sure when it was introduced but I'm guessing one of the v0.82.x versions.

New bug:

Display changer set to change display mode in fullscreen and return display mode back to original when media player is taken out of fullscreen mode.


File is fulscreened to exclusive mode and then taken out of fullscreen back to windowed mode via alt+enter. This causes the player to freeze completely and minimize, maximize, and close buttons to disappear. I then have to forcefully end mpc-hc.exe.

[Pat357]

Mad,
Thanks for the new build.
It seems much more stable now, but somehow I managed it to cause 2x MPC-HC to freeze.:o

Somehow the ctrl+alt+shift+break didn't create anything : did you somehow disable this ?:p
Anyway, I could reproduce the problem and created a report using "MadTraceProcess" + normal debug log.

http://www.mediafire.com/?7vz4loaf0ba6ue2

Oh, I forgot to tell when it happened : it was after going through a directory with clips ; after I succesfully went through a bunch of files, sudenly MPC-HC freezes when MadVR in in FSE.
It is infact the same as before : upon opening the next file, I got a black screen with the small blue circle in it. (windows standard).
Everything was locked after the "black" FSE frame.

[madshi]

Quick question if you have time: When using "delay playback until render queue is full", in my setup for example using a render queue of 24, is this feature designed to get to X-24 / 24 (with X being anything), or fully 23or24-24 / 24?
It's supposed to wait until the render queue is full (24/24). The "X-24 / 24" is the collected information between two OSD update intervals. The render queue can't be "X-24", it can only have one value at one time. The first moment it reaches 24/24, playback starts.

File is fulscreened to exclusive mode and then taken out of fullscreen back to windowed mode via alt+enter. This causes the player to freeze completely and minimize, maximize, and close buttons to disappear. I then have to forcefully end mpc-hc.exe.
I can't do anything without a freeze report. Please try to create one. If the key combo doesn't work, please try the madTraceProcess tool.

It seems much more stable now, but somehow I managed it to cause 2x MPC-HC to freeze.:o

Somehow the ctrl+alt+shift+break didn't create anything : did you somehow disable this ?:p
I'm wondering about that, too! But if you press the key combo during normal non-frozen playback, it works just fine for me. So it seems to be alright. Don't know why it sometimes doesn't work.

Anyway, I could reproduce the problem and created a report using "MadTraceProcess" + normal debug log.

http://www.mediafire.com/?7vz4loaf0ba6ue2

Oh, I forgot to tell when it happened : it was after going through a directory with clips ; after I succesfully went through a bunch of files, sudenly MPC-HC freezes when MadVR in in FSE.
It is infact the same as before : upon opening the next file, I got a black screen with the small blue circle in it. (windows standard).
Everything was locked after the "black" FSE frame.
Oh man. This is the MPC-HC problem once again! I see you're using build 4130. That should contain the Aleksoid fix. But the main thread is once again trying to create a D3D device while madVR is freeing its own... :(

[dansrfe]

Freeze Report for frozen mpc on exit of fullscreen to windowed mode.

http://pastie.org/private/lvuystqjfd2bwin8iogq

[madshi]

@dansrfe, that's MPC-HC's fault, it's once again trying to create a Direct3D device in the main thread while madVR is in the process of resetting its own. You could try a newer MPC-HC build (4128 or up). It was supposed to fix this problem, but according to Pat357's freeze report, the fix doesn't fully work yet. So it's possible another fix in MPC-HC is needed. In any case not madVR's fault, as far as I can say.

[Pat357]

Mad,

I think I have an idea of what went wrong in my case.
The display-changer needs to check the source filter (and maybe more checks) to determine the correct FPS to set the display.

For normal video/film files, this is no problem, but :
what does happen when there is no Directx source splitter ?

In my case, the file that caused the freezing from MPC-HC was an .M4A file.
MPC-HC showed no filters, no splitter, no audio decoder because the file was handled by Quicktime (via MFT I guess).
GraphStudioNext can also not detect any graph when trying to connect to "remote graph".


Another reason, although it would really be st.p..d, is that MadVR was in FSE before I switched to the "audio file.
Now you can not put MPC in full screen when playing audio (full screen is grayed out), but we already had FSE from the previous file
and it obviously will stay in FSE when switching to the next file (the .m4a audio).
Maybe MPC doesn't like FSE when playing audio without seeing any graph ??

I've a strong feeling that the freeze is related to MAdVR FSE and/or no normal DX graph.
The freeze doesn't happen with an AC3 file (handled by LAV).

I'm almost sure the same freezes will also happen if :

1.MadVR is in FSE in MPC

2.Playing audio through things like BASS-audio, .... which show no filters in the filter menu.



For the next build, I have a few wishes :

1. A key combination like ctrl+alt+shift+.... for unconditionally leaving FSE (would many thing make easier in case of problems)

2. Always obeying the interlaced/IVTC frame-based flags from the decoder by default : in case these are wrong, you can still set "force deinterlacing"
or "treat as progressive" in the decoder (in LAV-video and other decoders like Mainconcept, ).
Also Madvr can be set to "force deinterlace"/IVTC" on/off.
Even if the container or headers from the stream say something else, my experience is that the "repeat frame" flags from the decoder are very often correct.

3. Have a look at the freeze/crash report creation with ctrl+alt+shift+break. It's a very handy tool, but it I can't make it work in v0.82.4....
I've used it in previous versions, so it has worked before for me.

4. Supporting more format's for decoding : you have the whole FFmpeg lib at hand and you only support 3 format's ?
This way it's almost impossible to limit yourself to the build in decoders. It's a pittty you don't support more format's at this time.
Any plans to add more format's in the future ? It would be nice to just have a splitter and Madvr in your graph (less filters = usually less problems.. )
Of course first things first, so I can wait for the additional format's :-)

[madshi]

@Pat357, the freeze is not related to the display changer, as far as I can see. Your freeze report clearly shows that madVR is almost completely shut down, just the Direct3D object is not freed yet (it's in the process of being freed). The real issue is that MPC-HC is trying to create a new Direct3D object while madVR's Direct3D object is not fully freed yet. I thought Aleksoid had fixed that, but seemingly not, or at least not in all cases. It is possible, though, that your freeze is a different situation, and maybe it's a different part of MPC-HC now which tries to create a Direct3D object. E.g. maybe you have MPC-HC setup so that it draws some fancy graphics when you play an audio only file? To be honest, I've no idea if MPC-HC can even do that. Anyway, do you see any reason why MPC-HC should draw something when you play that .M4A file?

[dansrfe]

Freeze problem solved in the latest MPC-HC for me.

madshi,

I was wondering if it might be a good idea to implement some sort of user prioritized scaling algorithm fallback mechanism? Basically when the render queue starts to fall below a certain fraction of the user specified GPU queue size (or that it simply starts queuing a dangerously low number of frames) for which the present queue doesn't queue enough frames and then frames start getting dropped.

The main reason why this might be useful is for when the resizer is asked to go from a relatively high resolution to a much greater resolution or vis versa.

[xiulet]

Originally Posted by xiulet:
exclusive mode change only works when i pause de video and when i do it from right menu playing video.
i discover that this problem happens if USE D3D11 FOR PRESENTATION is activated, when not, exclusive change works correctly.

Originally Posted by mashi:
Can you explain in more detail how it does not work right now? What happens exactly? Does your computer explode? Or maybe something else? Please describe as detailed as possible. If you have a freeze -> please create a freeze report and send it to me. If you have a crash -> please send the crash report to me. If it's neither a freeze nor a crash, maybe a debug log could help.
sorry for the poor information(like my english) , seems that now with 0.82.4 it work ok or more less, if it freeze again i try to send you a MadTraceProcess trail,(I was unaware of this utility) how you say may be is a mpc-hc problem.

great program and better person you are, thanks a lot. :)

[mark0077]

It's supposed to wait until the render queue is full (24/24). The "X-24 / 24" is the collected information between two OSD update intervals. The render queue can't be "X-24", it can only have one value at one time. The first moment it reaches 24/24, playback starts.

Hi madshi, yeah that makes sense, thanks for the explanation. I guess in the situation where the decoder queue is set higher than the render queue, after the render queue is 100% full and madVR starts playback, the decoder queue can still be filling up and using alot of cpu. This seems to be whats causing stuttering at the start of playback for me with some clips where I only have software decoders and cpu intensive activities going on.

I'm sure its the least important thing, but would it be worth making this delay playback functionality, also delay until the other queues are full, just to be sure cpu usage can be reduced as much as possible before playback begins?

[kasper93]

(a) You can distribute a "yourMediaPlayer.pdb" file with your media player (the pdb file must be in the same folder as the exe file). madVR will then automatically read the pdb file and extract the necessary information. You can configure MSVC++ to create a pdb file even in release mode. Of course the pdb files are rather large, which is not so nice for distribution.

My MPC-HC builds with .pdb file included. http://dl.dropbox.com/u/16282309/MPC-HC/pdb/index.html I hope you find them useful for freeze reports :)

[703]

I guess I could add an option to force specific matrix and primaries for *all* videos. I could add this without touching the settings dialog by simply allowing you to "store" forced matrix and primary settings through shortcut keys + [F2].

Making such a setting available only for SD content, but not for HD content, would be much more complicated, though. For that I'd have to add options to the settings dialog, which IMHO would make things much harder to understand. And most people wouldn't use/need this functionality. So I don't really like that idea.

Fair enough, an option for all videos would be great, that basically overrides the best guess logic.


And I guess these don't have the proper matrix/primaries stored anywhere? How do you know then which the proper matrix/primaries are?

Let's say there were such an option as you're asking for: It would result in that you'd get incorrect matrix/primaries for all original MPEG2 PAL and NTSC DVDs. Does that really make sense!?

The matrix is stored in the container, but not necessary the stream. i.e. http://scenerules.irc.gs/n.html?id=2012_SDTVx264r.nfo

I can't be certain of the primaries, but I did an A <-> B comparison of SD and HD of the same programme sample and it looks like the SD was left in BT.709 (leaving MadVR to do the Gamut conversion made the color a bit different to the HD encode)

Just a thought!

[nevcairiel]

The matrix is stored in the container, but not necessary the stream. i.e. http://scenerules.irc.gs/n.html?id=2012_SDTVx264r.nfo

Discussion of content of such sources is not allowed on Doom9.

For the record however, the NFO clearly states that you shall specify the colormatrix in the x264 command line to match the source, which would cause it to write that information into the bitstream where a decoder or madVR can read it from.

[703]

Discussion of content of such sources is not allowed on Doom9.
.

Absolutely, I am simply using it as an example from an encoding practice point of view only, nothing about how content is acquired (I have no interest in that).

[madshi]

For the next build, I have a few wishes :

1. A key combination like ctrl+alt+shift+.... for unconditionally leaving FSE (would many thing make easier in case of problems)
Ctrl+Alt+Shift+Break already does that. It creates a freeze report *and* disables FSE mode. Of course if the process is already frozen, there's a certain chance no key combo will work, anymore.

2. Always obeying the interlaced/IVTC frame-based flags from the decoder by default : in case these are wrong, you can still set "force deinterlacing"
or "treat as progressive" in the decoder (in LAV-video and other decoders like Mainconcept, ).
Also Madvr can be set to "force deinterlace"/IVTC" on/off.
Even if the container or headers from the stream say something else, my experience is that the "repeat frame" flags from the decoder are very often correct.
I'm not sure exactly what you mean. In what way do your wishes differ from what madVR is currently doing/offering? Do you have problems with madVR's IVTC algorithm not working correctly?

3. Have a look at the freeze/crash report creation with ctrl+alt+shift+break. It's a very handy tool, but it I can't make it work in v0.82.4....
I've used it in previous versions, so it has worked before for me.
Does it not work even if you press that key combo while MPC-HC is *not* frozen? It works for me in that situation.

4. Supporting more format's for decoding : you have the whole FFmpeg lib at hand and you only support 3 format's ?
This way it's almost impossible to limit yourself to the build in decoders. It's a pittty you don't support more format's at this time.
Any plans to add more format's in the future ? It would be nice to just have a splitter and Madvr in your graph (less filters = usually less problems.. )
Of course first things first, so I can wait for the additional format's :-)
The problem with that is that I have some in depth knowledge about MPEG2, VC-1 and h264, but I don't have *any* knowledge about any other video bitstream layouts. madVR does a number of special tricks with MPEG2, VC-1 and h264, for which I need to understand how the bitstream layout works. If I were to add other video formats, too, I'd either have to learn all their bitstream specialties, or I'd have to dumb down their integration into madVR. I don't like either of these choices. Furthermore supporting more video formats would likely also increase the number of bug reports I'd get etc. I don't know what will happen in the future, maybe I will add support for the other video formats supported by ffmpeg, but I definitely will not do that anytime soon. I think those 3 formats I'm currently supporting are by far the most important, so it's quite possible madVR will stay limited to these (and maybe h265 once it ready for use).

Freeze problem solved in the latest MPC-HC for me.
Good to hear. So Pat357's freeze must have a somewhat different cause.

I was wondering if it might be a good idea to implement some sort of user prioritized scaling algorithm fallback mechanism? Basically when the render queue starts to fall below a certain fraction of the user specified GPU queue size (or that it simply starts queuing a dangerously low number of frames) for which the present queue doesn't queue enough frames and then frames start getting dropped.

The main reason why this might be useful is for when the resizer is asked to go from a relatively high resolution to a much greater resolution or vis versa.
Something like this might come in some (far away) future version, but not anytime soon. Too much other stuff to do first.

sorry for the poor information(like my english) , seems that now with 0.82.4 it work ok or more less, if it freeze again i try to send you a MadTraceProcess trail,(I was unaware of this utility) how you say may be is a mpc-hc problem.
Good to hear.

I'm sure its the least important thing, but would it be worth making this delay playback functionality, also delay until the other queues are full, just to be sure cpu usage can be reduced as much as possible before playback begins?
Hmmmm, I guess that makes sense. Will add it to my to do list. Wow, you're using really big queue sizes!!

My MPC-HC builds with .pdb file included. http://dl.dropbox.com/u/16282309/MPC-HC/pdb/index.html I hope you find them useful for freeze reports :)
Great - thanks!

Fair enough, an option for all videos would be great, that basically overrides the best guess logic.
Ok, will add that to my to do list.

The matrix is stored in the container, but not necessary the stream.
Then you could try to convince the splitter dev to add support for that. nevcairiel seems to be reluctant about this, though.

@Pat357, could you please reproduce the freeze with kasper93's debug MPC-HC build? (Make sure you don't delete the pdb file.) A freeze report with that MPC-HC build might help figuring out why exactly MPC-HC is trying to create a D3D device. Thx.

[nevcairiel]

Then you could try to convince the splitter dev to add support for that. nevcairiel seems to be reluctant about this, though.

Not so much reluctant, just not sure its worth it. For one, i don't even know which containers can hold such information. MKV cannot. I suppose MP4 might hide a atom for this somewhere in its bowels, but so far i couldn't find it.

If someone can find a file that really contains such information, i can try to look into it, but otherwise, i have nothing to go on.

[madshi]

Yeah, without a sample it doesn't make sense to look into it any further. So, 703, here's your chance...

[aufkrawall]

You're really putting great efforts into your renderer, madshi. Thanks for this, depending on the situation, its result looks much better than others. :thanks:

Since it isn't under GPL, do you have any future plans with it? ;)

[madshi]

Since it isn't under GPL, do you have any future plans with it? ;)
What do you mean?

[cyberbeing]

Freeze displaying a vertically stretched video frame when entering Fullscreen from Desktop (windowed).
http://www.mediafire.com/?i2b9vffj15uop98
Note: Generating the freeze report with CTRL+SHIFT+ALT+BREAK kicked madVR back to Desktop (windowed) in a paused, unfrozen state.
I don't believe Fullscreen (exclusive) ever had a chance to kick in before the freeze happened.

[madshi]

Freeze displaying a vertically stretched video frame when entering Fullscreen from Desktop (windowed).
http://www.mediafire.com/?i2b9vffj15uop98
Note: Generating the freeze report with CTRL+SHIFT+ALT+BREAK kicked madVR back to Desktop (windowed) in a paused, unfrozen state.
I don't believe Fullscreen (exclusive) ever had a chance to kick in before the freeze happened.
This doesn't really look like a real freeze. Was MPC-HC totally unresponsive, with no reaction to your mouse and keyboard input? I rather guess this is a case of MPC-HC being ok, but madVR maybe failing to render? If so, a freeze report won't help. A debug log might. Can you reproduce the problem at will? Does it occur only with a specific video file or with all video files? Is there any way for me to reproduce it on my PC?

[aufkrawall]

What do you mean?
Once it reaches plenty feature-completeness, maybe some companies could get interested in using it in their own solutions.
Please don't sell it or keep it free. :thanks:

Just some weird kind of musing... :p

[dansrfe]

Once it reaches plenty feature-completeness, maybe some companies could get interested in using it in their own solutions.
Please don't sell it or keep it free. :thanks:

Just some weird kind of musing... :p

I'm sure 'some companies' would be interested madVR from a while back. There's not a renderer with this efficiency in the consumer market. I can't speak for the professional/enterprise video software market since I don't know but if I were to venture a guess then I'm sure they are as well.

[cyberbeing]

This doesn't really look like a real freeze. Was MPC-HC totally unresponsive, with no reaction to your mouse and keyboard input? I rather guess this is a case of MPC-HC being ok, but madVR maybe failing to render? If so, a freeze report won't help. A debug log might. Can you reproduce the problem at will? Does it occur only with a specific video file or with all video files? Is there any way for me to reproduce it on my PC?

MPC-HC was totally unresponsive to mouse and keyboard (didn't try alt-tabbing but I now suspect that may have fixed it, since the freeze report did), but the process wasn't being detected as hung by Windows as far I can tell. It does feel like madVR failed to render, considering it hung with the image stretched to fullscreen (1680x1050) before being corrected to 16:9. If it matters, I also have madVR set to instantly enter fullscreen exclusive rather than wait 3 seconds, yet madVR hung while still in fullscreen windowed mode, half-way through resizing.

I'm unable to reproduce the problem at will, it doesn't appear linked to any particular video, and I've not discovered any easy way to reproduce the issue. I've seen this happen before, but it's rare, maybe once a month or less... I'll try running madVR debug constantly for awhile, and hope I get lucky enough to catch it sometime soon.

[xv]

I noticed that there are some color problems with YCgCo matrix. The difference is not huge and often not noticeable if you don´t know how it should look like.
Could you please look into that? I can provide an YCgCo example if you tell me what source I should encode.

[mark0077]

Hi madshi, I got a freeze today in mpc-hc 4130 + madVR v0.82.4

Maybe its the same problem as you have mentioned to Aleksoid in the mpc thread, maybe not. Its attached below incase its useful. It seemed fairly random. I had mpc-hc in windowed mode and had seeked through a vob from a DVD about 30 seconds earlier to find a particular scene. The scene played for about 30 seconds as I say but then the video image froze on one frame, mpc-hc was responding to mouse clicks and audio was continuing to play fine so I seeked again and mpc-hc froze up completely then and blue Windows 7 icon started spinning so I took the report below.

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

[Pat357]

Ctrl+Alt+Shift+Break already does that. It creates a freeze report *and* disables FSE mode. Of course if the process is already frozen, there's a certain chance no key combo will work, anymore.
If I understood you correct from before, the key-handling and some other stuff run in a separate thread, .. is this correct ?
Maybe you could, not sure if it's possible, run his in a complete separate process ?
Of course this would require some data to be changed out between the processes, but at least the separate process could create the report with the latest data has it received from the now "frozen" process.
I'm not sure exactly what you mean. In what way do your wishes differ from what madVR is currently doing/offering? Do you have problems with madVR's IVTC algorithm not working correctly?
If I set "force deinterlacing" in LAV-video, the decoder will send these "frame based" flags to ask the renderer to almost
"unconditionally" deinterlace to whole stream without questions asked. (EVR will "obey" these flags)
This doesn't seem to work that way ATM with MadVR.
The other options in Lav-video like "agressive deinterlacing" and "thread as progressive" (never deinterlace) seem also not to work as intented with Madvr.
Does it not work even if you press that key combo while MPC-HC is *not* frozen? It works for me in that situation.
It works perfect under normal conditions, but than we don't need it :p
Good to hear. So Pat357's freeze must have a somewhat different cause.
It's everytime I try to open a M4A file while MadVR is in FSE mode.
Like I said before, normally you can't switch MPC in full screen when playing audio... I think it has (maybe indirectly) to do with this.
Something along : "if I (MPC-HC) am in full screen mode, I have to create a new D3Ddevice..."
Following the MPC logic, "it must be a video file, because I can't be in "full screen" with audio files.... "
@Pat357, could you please reproduce the freeze with kasper93's debug MPC-HC build? (Make sure you don't delete the pdb file.) A freeze report with that MPC-HC build might help figuring out why exactly MPC-HC is trying to create a D3D device. Thx.
Done.
See http://www.mediafire.com/?v88ii8owp1oqppx

[kerman]

I have on madVR on display properties "TV levels" (16-235) when conecting to my tv to avoid conversions and scaling and to match source native levels.

Now, Im looking to be safe avoiding any conversion. Should I select on AMD CCC on Pixel Format, output to Limited RGB or Full RGB?

[robpdotcom]

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

In FSE > toggle video/film mode > madVR changes refresh rate > freeze

Freeze report:
http://www.mediafire.com/?r3pjxkdpmt6rfe4

One thing I noticed: When in FSE, after the freeze, CTRL+ALT+SHIFT+T still changes refresh rate, but nothing else seems to respond.

[QBhd]

I have on madVR on display properties "TV levels" (16-235) when conecting to my tv to avoid conversions and scaling and to match source native levels.

Now, Im looking to be safe avoiding any conversion. Should I select on AMD CCC on Pixel Format, output to Limited RGB or Full RGB?

Everything up to madVR in your playback chain should be set to "TV Levels"/"Limited" (16-235)... then madVR should be set to "PC Levels"/"Full" (0-255), your GPU should be set to this also, as well as your TV for best results. From what I understand, doing level conversion on the GPU is not something that should be done.

However, if your TV does not support 0-255 then you only need to change madVR's levels to 16-235, NOT your GPU's levels (these should always stay on "PC Levels"/"Full")

QB

[dansrfe]

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

In FSE > toggle video/film mode > madVR changes refresh rate > freeze

Freeze report:
http://www.mediafire.com/?r3pjxkdpmt6rfe4

One thing I noticed: When in FSE, after the freeze, CTRL+ALT+SHIFT+T still changes refresh rate, but nothing else seems to respond.

I don't think the display changer is supposed to change the refresh rate in video mode since it takes the video to either 50p or 60p and since 60Hz is the standard desktop refresh rate there is nothing else for the display changer to change to.

[madshi]

Once it reaches plenty feature-completeness, maybe some companies could get interested in using it in their own solutions.
Please don't sell it or keep it free. :thanks:
I don't plan to sell it, but if someone would offer me a million bucks, I'd probably change my mind pretty fast... :D

MPC-HC was totally unresponsive to mouse and keyboard (didn't try alt-tabbing but I now suspect that may have fixed it, since the freeze report did), but the process wasn't being detected as hung by Windows as far I can tell. It does feel like madVR failed to render, considering it hung with the image stretched to fullscreen (1680x1050) before being corrected to 16:9. If it matters, I also have madVR set to instantly enter fullscreen exclusive rather than wait 3 seconds, yet madVR hung while still in fullscreen windowed mode, half-way through resizing.

I'm unable to reproduce the problem at will, it doesn't appear linked to any particular video, and I've not discovered any easy way to reproduce the issue. I've seen this happen before, but it's rare, maybe once a month or less... I'll try running madVR debug constantly for awhile, and hope I get lucky enough to catch it sometime soon.
So this is not a new bug caused by the changes in the recent versions? Unfortunately the freeze report doesn't show me anything interesting. From what I can say, madVR doesn't seem to be in any kind of deadlock situation. A log may eventually help (or maybe not), but if it's so rare the big question is whether you can really capture it in a log...

I noticed that there are some color problems with YCgCo matrix. The difference is not huge and often not noticeable if you don´t know how it should look like.
Could you please look into that? I can provide an YCgCo example if you tell me what source I should encode.
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.

Hi madshi, I got a freeze today in mpc-hc 4130 + madVR v0.82.4

Maybe its the same problem as you have mentioned to Aleksoid in the mpc thread, maybe not. Its attached below incase its useful. It seemed fairly random. I had mpc-hc in windowed mode and had seeked through a vob from a DVD about 30 seconds earlier to find a particular scene. The scene played for about 30 seconds as I say but then the video image froze on one frame, mpc-hc was responding to mouse clicks and audio was continuing to play fine so I seeked again and mpc-hc froze up completely then and blue Windows 7 icon started spinning so I took the report below.
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.

If I understood you correct from before, the key-handling and some other stuff run in a separate thread, .. is this correct ?
Maybe you could, not sure if it's possible, run his in a complete separate process ?
Hmmmm... That's a possibility. I could let madHcCtrl do the key watching.

If I set "force deinterlacing" in LAV-video, the decoder will send these "frame based" flags to ask the renderer to almost "unconditionally" deinterlace to whole stream without questions asked. (EVR will "obey" these flags)
This doesn't seem to work that way ATM with MadVR.
The other options in Lav-video like "agressive deinterlacing" and "thread as progressive" (never deinterlace) seem also not to work as intented with Madvr.
This all depends on a lot of things. madVR has different sources of information, the upstream filter (decoder) being just one of them. Some upstream filters behave different to others, some are more trustworthy than others, so just because madVR doesn't do what you thought it should, based on your LAV configuration, doesn't mean that there's necessarily anything wrong with madVR. Let's look at this one case at a time. Pick one video file where madVR doesn't behave like you would expect it to, and then we can analyze why, and whether madVR needs to change. So start with one example. Tell me the exact video specs (maybe give me a sample, even), tell me how you configured LAV, what you expect from madVR, and what madVR does instead.

It's everytime I try to open a M4A file while MadVR is in FSE mode.
Like I said before, normally you can't switch MPC in full screen when playing audio... I think it has (maybe indirectly) to do with this.
I don't think so. From your freeze report it seems as if the Direct3D9 device might not be created by MPC-HC itself, but maybe by the DirectShow graph builder interface. This could be pretty ugly. I'll see if I can find a workaround for this problem.

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

In FSE > toggle video/film mode > madVR changes refresh rate > freeze

Freeze report:
http://www.mediafire.com/?r3pjxkdpmt6rfe4
This is an MPC-HC bug. Please update to revision 4128 or newer.

[sneaker_ger]

madVR has trouble leaving FSE mode when using D3D11. The picture kinda pauses and stays fullscreen. Toggling again will make playback resume in FSE mode.

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

[madshi]

Can you define "stays fullscreen"? Need more details. Do you see the MPC-HC window title bar? Or does it still look exactly like FSE mode?

[sneaker_ger]

I see the still of the picture in fullscreen and can see the mouse cursor. No kind of OSD visible. The sound of the file continues.

[madshi]

Do you see the MPC-HC window title bar? Or does it still look exactly like FSE mode? Maybe a screenshot would help.

[sneaker_ger]

No MPC-HC bars. Just imagine having pressed "pause". That's what it looks like.

While trying to make screenshot: FRAPS didn't make any screenshot in that state. :confused: Maybe because of D3D11?

[madshi]

According to your log everything appears to work just fine. Windowed playback seems to run as normal after the exclusive -> windowed switch. Don't know why you don't see anything. Does this problem happen every time, or just once in a while? Is it a new problem? Which version introduced it?

P.S: Do you have the MPC-HC "D3D Fullscreen" option activated in the renderer options? If so, try disabling it. Does that help?

[nevcairiel]

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.

[sneaker_ger]

^this.

Don't really know if regression or not.

[madshi]

@nevcairiel, I don't think I understood your report the way I understand it now. I guess I thought that just the MPC-HC window in windowed mode would be full screen sized.

@sneaker_ger, is it 100% reproducable for you?

[sneaker_ger]

@sneaker_ger, is it 100% reproducable for you?

It appears so.

[madshi]

Does this one behave any better?

http://madshi.net/madVR824b.zip

[sneaker_ger]

No difference.

[madshi]

Oh man, I just wish I could reproduce it. How about this one?

http://madshi.net/madVR824c.zip

[kerman]

Everything up to madVR in your playback chain should be set to "TV Levels"/"Limited" (16-235)... then madVR should be set to "PC Levels"/"Full" (0-255), your GPU should be set to this also, as well as your TV for best results. From what I understand, doing level conversion on the GPU is not something that should be done.

However, if your TV does not support 0-255 then you only need to change madVR's levels to 16-235, NOT your GPU's levels (these should always stay on "PC Levels"/"Full")

QB

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.

[sneaker_ger]

Oh man, I just wish I could reproduce it. How about this one?

http://madshi.net/madVR824c.zip

Nope.

[madshi]

Next try:

http://madshi.net/madVR824e.zip

[sneaker_ger]

The FSE -> window switch is working now, but exactly every other window -> FSE switch will display the video on the former MPC-HC window dimensions (Desktop etc. stays visible).

[madshi]

So basically there's all video and no controls? What happens if you minimize and restore the window by clicking on the taskbar icon?