madVR - high quality video renderer (GPU assisted)

[kasper93]

Originally Posted by madshi

(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]

Originally Posted by madshi

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.

Originally Posted by madshi

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]

Originally Posted by 703

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]

Originally Posted by nevcairiel

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]

Originally Posted by Pat357

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.

Originally Posted by Pat357

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?

Originally Posted by Pat357

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.

Originally Posted by Pat357

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

Originally Posted by dansrfe

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

Good to hear. So Pat357's freeze must have a somewhat different cause.

Originally Posted by dansrfe

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.

Originally Posted by xiulet

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.

Originally Posted by mark0077

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

Originally Posted by kasper93

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!

Originally Posted by 703

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.

Originally Posted by 703

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]

Originally Posted by madshi

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.

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

[madshi]

Originally Posted by aufkrawall

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]

Originally Posted by 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.

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]

Originally Posted by madshi

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.

Just some weird kind of musing...

[dansrfe]

Originally Posted by aufkrawall

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.

Just some weird kind of musing...

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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

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]

Originally Posted by 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?

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