madVR - high quality video renderer (GPU assisted)

[madshi]

I got a complete crash from Potplayer (latest version) in a way that my screen was completely black. I happened when switching to or back from FSE, can't tell for sure what is was.
I couldn't even access the taskman anymore, because after ctrl+alt+del -> taskman gave me again the back screen.
The only way to recover was switching to a different user and kill the Potplayer process from there.

At the moment that the screen turned black, I pressed the magic buttons to create a crash report.
Now here it comes : there were 41 crash-reports on my desktop !
You probably need just the first one I suppose, but to make sure, I'll provide all of them.
(don't worry, all together compressed is still only 15 kB.)

MadVR 0.81 / Nvidia GTX-570 / Win7 x64 SP1 (auto-updates)
Potplayer 1.5.32007 / CPU i7-970 / NVidia driver : v290.33

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

http://www.mediafire.com/download.php?m5fmjp3a618jdpv
Hmmmm... No idea why you got so many freeze reports (they're freeze reports, not crash reports). But anyway, they're all pretty much identical. From what I can see, PotPlayer might be involved in the freeze, and unfortunately I don't have any callstack/debug information from PotPlayer. In order to get to the bottom of this freeze, the PotPlayer dev would have to ship debug information with PotPlayer, and then I'd need a new freeze report from a freeze that happened in PotPlayer with debug infos.

I'll talk to the PotPlayer dev, maybe he'll be willing to provide debug information in future versions.

Sorry, I was confused about the setting, and also about the automatic detection not fully working, as you said. Just disregard that post.
So it everything working as expected for you?

[madshi]

Here is a Ctrl+Alt+Shift+Break Freeze Report
http://www.mediafire.com/?3tcf239j4hhqa4t

Win7 SP1 x64
ATI 5750 1GB
MPC-HC

Trigger: Loading the next file in a playlist when in fullscreen exclusive mode
That's a weird one. According to the log, the media player is trying to create a Direct3D device, while madVR is trying to destroy its own Direct3D device (in a different thread). Which doesn't make any sense since only madVR is supposed to create Direct3D devices.

Edit: Your freeze report and my interpretation were just confirmed by ryrynz. We found a change in MPC-HC which is reponsible for the freeze and reported the problem to the MPC-HC thread.

Here is another madVR freeze report, this time of the issue that often causes madVR to hang when changing the subtitle stream from a paused state. (MPC-HC + Haali + vsfilter.dll):
http://www.mediafire.com/?yrsmua81psw1ycv
Hmmmm... It seems that the filter which provides the subtitle switching interface (don't know which it is, maybe vsfilter) is frozen here, pulling madVR with it into a freeze. Doesn't seem to be madVR's fault to me. However, maybe I can work around it, I'll give that a try. Please retest with the next build to confirm whether the problem is gone or not.

[madshi]

I've just had it freeze with copy to backbuffer set to flush, I have yet to have it freeze however with 'after last render step' set to flush as well.

Freeze report below.

http://www.mediafire.com/?yor8i34dirdisu4
WEIRD! This confirms cyberbeing's first freeze report (see my previous reply to cyberbeing)! It seems that MPC-HC actually tries to create a Direct3D device while madVR is still running. And that somehow freezes the whole process. So the big question is: Why would MPC-HC try to create a Direct3D device if madVR is active?

Is there any MPC-HC dev here? It would help a lot if MPC-HC could be compiled with debug information (more information about that see v0.80 release notes). Then we would maybe know why MPC-HC tries to create a Direct3D devices on its own.

[madshi]

Found a bug, if Bicubic settings are selected before Softcubic the drop down options still only show the Bicubic settings, it's not till you go to one of the other algorithms then to Softcubic that it displays properly.
Thanks, will be fixed in the next build.

[agustin9]

WEIRD! This confirms cyberbeing's first freeze report (see my previous reply to cyberbeing)! It seems that MPC-HC actually tries to create a Direct3D device while madVR is still running. And that somehow freezes the whole process. So the big question is: Why would MPC-HC try to create a Direct3D device if madVR is active?
Maybe the D3D Fullscreen MPC option?

[ryrynz]

Looks like I've found the bug lurking somewhere between builds 3608 and 3627, perhaps it's the one of the changes made in build 3619 or 3623.

I can usually duplicate this on a fresh boot, entering FSE mode with no flushing set on all options, as both Cruncher and I found the 'after copy to backbuffer' option being set to 'don't flush' affecting the chances of MPC crashing.

I'll post about this in the MPC forum also.

Maybe the D3D Fullscreen MPC option?

Nope, definitely not.

[madshi]

Looks like I've found the bug lurking somewhere between builds 3608 and 3627, perhaps it's the one of the changes made in build 3619 or 3623.

I can usually duplicate this on a fresh boot, entering FSE mode with no flushing set on all options, as both Cruncher and I found the 'after copy to backbuffer' option being set to 'don't flush' affecting the chances of MPC crashing.
Good find - looks like 3619 to me!

*Please* be exact in your description. You're talking about a crash all the time. It is NOT a crash, it's a freeze. From a developer point of view that's a totally different thing. Talking about crashes when you mean a freeze confuses me, and will likely confuse the MPC-HC devs, too.

[ryrynz]

Thanks, I was thinking about this after I saw Cruncher's post and thought it would wise to clarify it as being a freeze in my future posts.

Saw your post, removed mine, it kind of got dwarfed. :D

[madshi]

Crash report + complete log-file.

Problem : if MadVR is in FSE mode, it crashes MPC-HC (+itself ?) upon switching to the next/previous file.

I made a playlist from 2 files and let it play in FSE. The first file plays nice, but at the end when opening the second, I end up with a black screen.

Only <ctrl>+<alt>+<del> brings back some live, nothing else works, probably because of FSE.

Happens only in FSE, no problems in maxim. windowed mode.
Happens both when switching is done automatic (playlist) and manual (next file using mouse or keyb.)

Win7 SP1 / Nvidia gtx-570 / latest 295.73 drivers / CPU i7-970
LAV v0.48 / MPC-HC 4111 (also tested with PotP-> same issue)
Things already tried : driver rollback to previous known "good" version 290.36, different vers. MPC, PotPlayer,
all kind of combination for flushing modes FSE, change que-sizes,...)

Crash-report + MadVR log :

http://www.mediafire.com/?g7ty003uxo9k7vj
This is again exactly the same problem reported by cyberbeing and ryrynz. We'll need a new MPC-HC revision to have this fixed.

[madshi]

with "Present Several Frames In Advance" unchecked (I get better smoother playback this way) the Zoom Player GUI still distorts when coming out of FSE to window mode though not quite as bad as v.80.
It doesn't seem to happen on my PC, unfortunately. For me, ZP behaves identically, when coming out of FSE, regardless of whether "Present Several Frames In Advance" is activated or not. I'm testing on XP, though. Maybe that's the difference? What happens if you deactivate Aero? Does the problem still occur then?

[madshi]

May I also add the request to fix the similar problem with UT video (http://forum.doom9.org/showthread.php?t=143624) with its native decoder? It's exactly the same problem - the video plays fine with LAV decoder + madVR but the native UT decoder + madVR results in black image.
I can look into this, but I'll need a sample file with which the problem occurs.

[madshi]

Will you fix the issue with FRAPS videos not playing with FRAPS decoder in a future version?
It's still there with 81.
I've just checked. madVR is simply not receiving any video frames. The decoder doesn't seem to be sending any. I don't know why. The same problem occurs when using the Haali Renderer. So I rather think the bug is in the decoder and not in madVR. I'd suggest to use LAV Video Decoder instead. It seems to work just fine for me.

[aufkrawall]

I've just checked. madVR is simply not receiving any video frames. The decoder doesn't seem to be sending any. I don't know why. The same problem occurs when using the Haali Renderer. So I rather think the bug is in the decoder and not in madVR. I'd suggest to use LAV Video Decoder instead. It seems to work just fine for me.
Thanks for looking into this. :)
So, once more the FRAPS decoder is producing trouble... :rolleyes:

[madshi]

@cyberbeing, ryrynz and Pat357:

Aleksoid has provided an MPC-HC test build. Can you please check if the freezing problems are gone with this?

http://forum.doom9.org/showpost.php?p=1562898&postcount=19015

[madshi]

madshi
Thank you for .81!

Please have a look:
The source is NTSC film in .mkv container (DVD). Mediainfo reports that video scan type: Progressive.
Madvr is in film mode (settings).

Display does not switch to 23, but switches to 59. If mediainfo reports that Scan type: Interlaced, everething is OK.
The problem is that madVR isn't sure whether to activate deinterlacing or not and in that case it disables deinterlacing. With deinterlacing disabled, a 29p DVD should be played at 59Hz and not at 23Hz. The next madVR build will allow you to choose whether deinterlacing should be enabled in cases where madVR isn't sure.

[fairchild]

@cyberbeing, ryrynz and Pat357:

Aleksoid has provided an MPC-HC test build. Can you please check if the freezing problems are gone with this?

http://forum.doom9.org/showpost.php?p=1562898&postcount=19015

I tried this new version out and so far no freezing issues here. I would also get freezing occassionaly when I would close the file while still in FSE mode. Only time will tell if it's totally fixed as sometimes I'd get freezes when skipping through files while in FSE as well as just closing the file while in FSE.

The version that I had been using which wasn't giving me many freezes had been MPC-HC_r4090_x86 from xhmikosr

[JarrettH]

0.81 is definitely more immune to DVD menu crashes, FYI

Edit: Nevermind I see the reports

Crash 1: http://www.mediafire.com/?3ks5dvedts5uy9t

Crash 2: http://www.mediafire.com/?bo33u4fov8vy4dk

Both are after cursor starts spinning / mpc unresponsive

[mark0077]

Hi madshi, crash report below. I really don't know what triggered it, just happened out of the blue. Hope this helps.

http://www.mediafire.com/?9pnnaj1l7myd992

[andybkma]

It doesn't seem to happen on my PC, unfortunately. For me, ZP behaves identically, when coming out of FSE, regardless of whether "Present Several Frames In Advance" is activated or not. I'm testing on XP, though. Maybe that's the difference? What happens if you deactivate Aero? Does the problem still occur then?

I am on Win 7 SP1 and Aero is always deactivated (I use the Windows 7 Basic theme). The Zoom Player GUI problem only occurs for me as soon as I deselect "Present Several Frames In Advance". When it's selected then there is no GUI distortion problem when coming out of FSE. What could the difference be and how can I better provide you information? I am back on .79 for now but can do any troubleshooting you require. Cheers

[madshi]

I tried this new version out and so far no freezing issues here. I would also get freezing occassionaly when I would close the file while still in FSE mode. Only time will tell if it's totally fixed as sometimes I'd get freezes when skipping through files while in FSE as well as just closing the file while in FSE.
So, you're not sure yet whether the problem is fixed, correct?

0.81 is definitely more immune to DVD menu crashes, FYI

Edit: Nevermind I see the reports

Crash 1: http://www.mediafire.com/?3ks5dvedts5uy9t

Crash 2: http://www.mediafire.com/?bo33u4fov8vy4dk

Both are after cursor starts spinning / mpc unresponsive
These are not crashes, they're freeze reports. I've looked into them and don't see any obvious problems. If you can reproduce the problem, another freeze report together with a debug log might help.

Hi madshi, crash report below. I really don't know what triggered it, just happened out of the blue. Hope this helps.

http://www.mediafire.com/?9pnnaj1l7myd992
Hmmmm... The crash was related to the MPC-HC internal subtitle renderer somehow. I can't see the exact reason of the crash, unfortunately. Is there any way you can reproduce it? If so, does it only happen with the new MPC-HC build you're using? It seems to be the one Aleksoid has provided? At least it seems to contain MPC-HC debug information, which is quite nice.

[madshi]

I am on Win 7 SP1 and Aero is always deactivated (I use the Windows 7 Basic theme). The Zoom Player GUI problem only occurs for me as soon as I deselect "Present Several Frames In Advance". When it's selected then there is no GUI distortion problem when coming out of FSE. What could the difference be and how can I better provide you information? I am back on .79 for now but can do any troubleshooting you require. Cheers
Does the distortion repair itself? Or does it stay distorted forever? In other words: Is it just a temporary cosmetical glitch? Or is it a real usability problem?

[mark0077]

Hi madshi, the crash I had only happened once, but if I reproduce it with newer mpc-hc builds, I'll let you know.

[fairchild]

So, you're not sure yet whether the problem is fixed, correct?

My freezing was intermittent so I can't be sure until I use this new build for a bit longer. This is the reason I didn't post a freeze report. Perhaps the others who could re-create their freezes can chime in. :)

[Andy o]

So it everything working as expected for you?
I knew you said Auto wasn't fully working, but the particular "issue" I had was that I completely took backwards that "disable automatic" (to mean "enable automatic..."). So in those terms, it is working as it should.

[aufkrawall]

madshi,
is there a chance that you will implement HQ CPU based deinterlacing in future? :)

[sneaker_ger]

A sample would be great.

Do you get proper deinterlacing with VMR/EVR?

Yes, deinterlacing via EVR or LAV works fine.

Sample:
http://www.mediafire.com/?c1fz71bkig59k92

[dansrfe]

I have a 99% progressive NTSC DVD and madVR picks up "no deinterlacing" required from the upstream decoder filter. The problem is that when I full screen the video (which I've also set the display changer to invoke on) the refresh rate doesn't change. I guess madVR keeps the refresh rate at 60Hz because it sees the DVD at 29.976fps?

Here's a cut from the first vob file: http://www.mediafire.com/?r12vbq7snjvudgg

[oddball]

Sorry to post this in this thread but it is relevant to MadVR. I can't seem to get 100% smooth playback with MadVR and bistreaming audio.

It's something that's been bugging me for a while with my Nvidia card (560GTX) and Panasonic G20B plasma and it still eludes me (well in the way I want it configured that is). Usually I use ReClock and analog out to get around this issue but ideally I would like bistreaming for most audio. I found that if I used bitstreaming of audio along with decoding using LAV Video sent to MadVR renderer I get frame drops every few minutes. When looking at the default display refresh in MadVR (ctrl-j) outputting @ 23Hz setting shows 23.97104 which is obviously way off enough to cause frame drops. Funnily enough though if I use MPC-HC's inbuilt EVR Sync mode and set sync to display the green line will wander up and down a bit but I don't get any frame drops (so how is it keeping bitstream audio and video in sync with no dropped frames that MadVR doesn't? I've tried lots of different settings in MadVR but none help. Sometimes MadVR even reports no dropped frames, delayed frames or glitches but I still see them so it looks like they get 'glitched' before they even hit the renderer).

Currently I use ReClock but it's sent as analog to a low quality USB soundcard with 8 channel output (I'm considering an X-Fi to replace it) and that works fine for PAL speeddown and allows me to use MadVR without frame drops. But I would much prefer bitstreaming for MOST audio. My receiver whilst old is still good enough for me. It lacks HDMI but has 6 channel analog inputs as well as the usual SPDIF inputs.

I tried setting a custom resolution (I Googled for the settings) and managed to get the magic 23.976 or close enough to it not to worry. This resulted in 0 framedrops and MadVR read 1 dropped frame every 15+ hours and rising when bitstreaming audio. However I now had a strange mirror line at the bottom of the screen similar to how you got from video cassettes when the tracking was off.

I know the Nvidia cards are known for not outputting the correct timings on 23Hz but want to know if me setting it manually is causing the display itself to cause the line at the bottom (out of range type error which would be worrying as it could cause damage to the display perhaps?) or the card/driver. Nvidia have known about the timings issue for several years now and it does not look like a fix will ever be available.

Has anyone else tried doing the same on a different display and got perfect results (no mirror line at the bottom)?

[madshi]

I knew you said Auto wasn't fully working, but the particular "issue" I had was that I completely took backwards that "disable automatic" (to mean "enable automatic..."). So in those terms, it is working as it should.
FWIW, the next build will force deinterlacing + IVTC on for 60i sources tagged to 24Hz, regardless of what the settings say.

is there a chance that you will implement HQ CPU based deinterlacing in future? :)
You mean video mode deinterlacing (as opposed to IVTC)? I'm not sure if I will do that. Writing fast CPU code for image processing is really painful. Writing GPU pixel shaders is easier.

Yes, deinterlacing via EVR or LAV works fine.

Sample:
http://www.mediafire.com/?c1fz71bkig59k92
Ah, I see. The video bitstream says: "frame_mbs_only_flag = 1", which practically means that the whole file is progressive, no questions asked, no doubt about it. Ok, so in reality it's not progressive after all. But that's really a broken file. If madVR can't trust "frame_mbs_only_flag" then it will never be able to know if a file is progressive or not.

Furthermore the file is "bottom field first" which is an important bit of information which is not contained in the video bitstream, either. DXVA deinterlacing only works properly for this sample if you force it to "bottom field first". I'm getting the same bad deinterlacing results with "auto field order" and "top field first".

On my PC, VMR9 and EVR do not deinterlace this video file at all, at least not when using CoreAVC.

[madshi]

I have a 99% progressive NTSC DVD and madVR picks up "no deinterlacing" required from the upstream decoder filter. The problem is that when I full screen the video (which I've also set the display changer to invoke on) the refresh rate doesn't change. I guess madVR keeps the refresh rate at 60Hz because it sees the DVD at 29.976fps?

Here's a cut from the first vob file: http://www.mediafire.com/?r12vbq7snjvudgg
The next madVR build will always auto activate deinterlacing for 60i videos, unless the bitstream clearly says that the file is progressive. That will fix the problem with your sample file.

I tried setting a custom resolution (I Googled for the settings) and managed to get the magic 23.976 or close enough to it not to worry. This resulted in 0 framedrops and MadVR read 1 dropped frame every 15+ hours and rising when bitstreaming audio. However I now had a strange mirror line at the bottom of the screen similar to how you got from video cassettes when the tracking was off.
Did you use the standard HDMI 23.976 timings, or did you play around with the timing parameters to get it close to what you need? In the latter case it might be that the display just doesn't like the timing. I'd suggest trying different timing values. There are multiple ways to get to 23.976. But this really isn't madVR related, so please no long discussions about this in this thread.

[sneaker_ger]

Ah, I see. The video bitstream says: "frame_mbs_only_flag = 1", which practically means that the whole file is progressive, no questions asked, no doubt about it. Ok, so in reality it's not progressive after all. But that's really a broken file. If madVR can't trust "frame_mbs_only_flag" then it will never be able to know if a file is progressive or not.

Furthermore the file is "bottom field first" which is an important bit of information which is not contained in the video bitstream, either. DXVA deinterlacing only works properly for this sample if you force it to "bottom field first". I'm getting the same bad deinterlacing results with "auto field order" and "top field first".

On my PC, VMR9 and EVR do not deinterlace this video file at all, at least not when using CoreAVC.

Maybe I have not been clear enough:
I do not expect madVR to detect this file as interlaced, as it has indeed been encoded wrongfully in progressive mode. I do however expect it to start deinterlacing when I press "ctrl+alt+shift+d" until the OSD says "Deinterlacing: on". This is not happening. I additionally have to press "ctrl+alt+shift+f" for TFF or BFF, though strangely it will correctly be deinterlaced, even if TFF is set.

[oddball]

If someone can point me to the standard HDMI 23.976 timings I will exit this thread. Thanks. I used vporch 5, vwidth 5, 1124 and 23.976Hz for your info though (tried vporch 4 too). I did try a couple of other settings with no luck (same mirror line @ 23.978 which others have recommended from Googling around).

[dansrfe]

^ Just to make sure I've understood this correctly. pseudo-progressive (flag-based 60i content) != progressive content to the renderer, once it has passed through the decoder? I always thought that madVR wouldn't need to deinterlace on the above sample or other 99%+ progressive files since it would essentially be 23.976fps input to the renderer...

[nevcairiel]

The next madVR build will always auto activate deinterlacing for 60i videos, unless the bitstream clearly says that the file is progressive. That will fix the problem with your sample file

Ignoring per-frame flags from the decoder?
If so, that sounds like a terrible idea.

[ryrynz]

Aleksoid has provided an MPC-HC test build. Can you please check if the freezing problems are gone with this?


This build has not fixed it unfortunately.

[madshi]

Maybe I have not been clear enough:
I do not expect madVR to detect this file as interlaced, as it has indeed been encoded wrongfully in progressive mode. I do however expect it to start deinterlacing when I press "ctrl+alt+shift+d" until the OSD says "Deinterlacing: on".
Ok, then we're on the same page.

This is not happening. I additionally have to press "ctrl+alt+shift+f" for TFF or BFF, though strangely it will correctly be deinterlaced, even if TFF is set.
This is not what is happening on my PC. For me deinterlacing starts to "work" when I activate it. However, auto field detection defaults to TFF when no other information is available. So although I don't see much combing with just activating deinterlacing, playback is very non-smooth. Only by activating BFF I get proper playback. For me auto field order = TFF on this clip. Please double check.

^ Just to make sure I've understood this correctly. pseudo-progressive (flag-based 60i content) != progressive content to the renderer, once it has passed through the decoder? I always thought that madVR wouldn't need to deinterlace on the above sample or other 99%+ progressive files since it would essentially be 23.976fps input to the renderer...
Many broadcasts and also some (many?) DVDs are a mixture of soft- and hard-telecine. Which means that some frames are progressive and don't need IVTC, while other frames do need IVTC. If you know for a fact that a movie file is perfectly soft-telecined from start to finish then you can safely keep IVTC turned off. But the big question is: Do you know that for a fact? If you don't, it's safer to let madVR perform IVTC. I dare say that if the whole movie is perfectly soft-telecined, madVR's IVTC algorithm should always produce exactly the same output as leaving the frames alone. So you can consider madVR's IVTC algorithm just a watchdog in that case.

Ignoring per-frame flags from the decoder?
If so, that sounds like a terrible idea.
Why? We're only talking about 25.000 and 29.970 content here. madVR does not auto activate the deinterlacer for any other frame rates. Content with these two framerates is almost always interlaced or telecined. If I wait for an "interlaced" flagged frame from the decoder before turning deinterlacing/IVTC on, I could wait forever, letting the user see combing. E.g. this could happen quite easily with a movie which is encoded as hard-telecined frames.

Anyway, madVR let's you choose, there's an option available for that. In question is only the behaviour if madVR isn't sure if a 25.000 or 29.970 file is interlaced or not. You can tell madVR what to do in that situation. The default behaviour will be to auto activate deinterlacing/IVTC for all 25.000 and 29.970 files, unless the bitstream or the upstream filter clearly say otherwise.

I'm open for discussion about this. If you think the default behaviour should be different, then let's discuss that.

This build has not fixed it unfortunately.
Too bad, thanks for the heads up. Just to be safe that it's the same issue, can you upload a new freeze report with the Aleksoid MPC-HC build?

[HitomiKun]

The video picture freezes on display mode change when having automatic fullscreen exclusive mode enabled.

If I set <switch to matching display mode...><... when media player goes fullscreen>
and <restore original display mode...><... when media player leaves fullscreen>

the video frame always freezes when I switch to fullscreen but the audio continues. I also enabled the madVR seek bar. It does not show the seek bar while the frame is frozen. To avoid this problem I have to disable the seek bar and move my mouse down to get on window mode back through MPC seek bar.

This error should be reproducable with all files on display mode change and having automatic fullscreen exclusive mode enabled.

Please add an refresh video frame function after the display mode has changed when switching to fullscreen. Thank you ;)

[sneaker_ger]

Ok, then we're on the same page.


This is not what is happening on my PC. For me deinterlacing starts to "work" when I activate it. However, auto field detection defaults to TFF when no other information is available. So although I don't see much combing with just activating deinterlacing, playback is very non-smooth. Only by activating BFF I get proper playback. For me auto field order = TFF on this clip. Please double check.

Double checked:
http://www.abload.de/thumb/madvr_forced_deinterlhujjq.jpg (http://www.abload.de/img/madvr_forced_deinterlhujjq.jpg)

Maybe it has something to do with Catalyst 12.2?

[noee]

sneaker_ger, I'm seeing what madshi is seeing with your sample and I'm running 12.3 preview. I know you know this stuff, but have you check your CCC deint setting(s)?

[nevcairiel]

We're only talking about 25.000 and 29.970 content here. madVR does not auto activate the deinterlacer for any other frame rates. Content with these two framerates is almost always interlaced or telecined.

Maybe 29.970 content is always either interlaced or telecined, but 25.000 may as well be a fully progressive movie.
Or maybe, it was already deinterlaced by some other filter.

The file may just lack a format block, or just not be marked as progressive sequence for odd reasons, yet be fully progressive.

Anyway, I just think that by default you should stick to the same behavior as EVR, and deinterlace what you're told to deinterlace by the decoder, and not do any assumptions that might be wrong depending on the other filters in the graph or the source of the file.
EVR strictly sticks to the media type flags and the frame flags, and i don't usually see people complain.

The option is fine, LAV has the same option ("Aggressive Deinterlacing"), but it shouldn't be default on.

[oddball]

On my issue with framerate vs display Hz. I got nowhere with it unfortunately so either my TV does not like that setting or my Nvidia card/drivers has a bug with outputting pure 23.976.

Anyhow what I want to know is this. With EVR Sync set to sync to display if I CTRL-J I can see the framerate varies from one moment to the next. I am guessing that EVR Sync is actually moving the framerate up and down each second to match the output frequency of the display in this instance. Is this correct? I only say this because when I CTRL-J in MadVR it reports the display as 23.97105 and I do not see any varying framerates. Instead I just seed dropped or repeated frames (depending on if I set to 23Hz or 24Hz output). Is there no way to get MadVR to do what EVR Sync is doing? It seems that MadVR locks to the display output frequency and there is no variance? I have no idea if what I am talking about is correct or not so please feel free to chime in and correct me. I just want what EVR Sync is doing but with MadVR quality. It's easier to spot a dropped or repeated frame than it is a varying framerate (If indeed that is what EVR Sync is doing with sync to display enabled).

(ReClock obviously does the same thing on audio as EVR Sync right? It just adjusts the analog audio to match the reported display frequency resampling it before sending the the outputs).

[sneaker_ger]

sneaker_ger, I'm seeing what madshi is seeing with your sample and I'm running 12.3 preview. I know you know this stuff, but have you check your CCC deint setting(s)?

I tried automatic and vector-adaptive, with and without pull down detection. Didn't make any difference.
Also upgraded to 12.3 RC, but no change.

I don't understand why it would make a difference for the driver anyways, as I image madVR will internally decide what deinterlacing to use and then send it to the driver. It shouldn't matter for the card whether madVR detected interlacing automatically or whether it was forced to do it. :confused:

[JarrettH]

Sorry I didn't think a freezing report was much different, I made a debug this time.

Log 1 and 2 is me reproducing the same crash (Moon, NTSC DVD).

GTX 550 Ti, 285.62 WHQL, Windows 7, MPC build 4014

Debug log1: http://www.mediafire.com/?89318mydazryaoy

Debug log2: http://www.mediafire.com/?cyvbgz60crtdd1z

Log 3 and 4 is me reproducing the crash with a different title (Kill Bill Vol 2, NTSC DVD).

Debug log3: http://www.mediafire.com/?zhf1xv60zh3s115

Debug log4: http://www.mediafire.com/?gms9shqdv5jdshf

Hope you can tell me what's happening :D

[madshi]

Anyhow what I want to know is this. With EVR Sync set to sync to display if I CTRL-J I can see the framerate varies from one moment to the next. I am guessing that EVR Sync is actually moving the framerate up and down each second to match the output frequency of the display in this instance. Is this correct?
I've no idea. I've not much knowledge about EVR.

I only say this because when I CTRL-J in MadVR it reports the display as 23.97105 and I do not see any varying framerates.
Which is as it should be. The madVR "display" information shows you the display refresh rate, not the movie frame rate. The display refresh rate does not vary (much), so madVR is absolutely correct.

Instead I just seed dropped or repeated frames (depending on if I set to 23Hz or 24Hz output). Is there no way to get MadVR to do what EVR Sync is doing?
Most madVR users would kill me if I made madVR do what EVR Sync is doing. I would probably kill myself, too.

ReClock obviously does the same thing on audio as EVR Sync right?
No, not at all. EVR Sync does not "adjust" anything in the way you think it does. EVR Sync does not have any Reclock like functionality at all, as far as I know.

Maybe 29.970 content is always either interlaced or telecined, but 25.000 may as well be a fully progressive movie.
Where would 25p content come from? PAL DVD? I've been told that while many DVDs are properly encoded and flagged, some are not. Wouldn't it be better to let madVR analyze the content and deal with it properly instead of relying on the flags? FWIW, there are hardware DVD players out there which are blindly relying on flag, and there are others which instead always deinterlace/IVTC. Usually those with a high-quality chip (HQV, Gennum, ABT) always deinterlace/IVTC and ignore the flags. My thinking is that madVR should match what the best hardware players out there are doing.

Or maybe, it was already deinterlaced by some other filter.
Then the deinterlacing filter should set "WeaveOnly" in VIDEOINFOHEADER2, and madVR will not activate the deinterlacer. MS documentation says "WeaveOnly" means:

"The video stream is interlaced, and each sample contains two video fields. The fields should not be deinterlaced."

Of course it would be ideal if the deinterlacing filter could tell madVR that the stream is really progressive, instead of using "WeaveOnly". The big problem with that is that the flags are not clear about whether they're not set at all, or whether they are meant to say "progressive". Both is value 0. And some decoders (e.g. CoreAVC) set the value to 0. So the only way (that comes to my mind) for the deinterlacing filter to tell madVR not to deinterlace is to use "WeaveOnly".

Ok, the problem above only applies to PAL movies. For video content the deinterlacing filter should change the frame rate information to 50p/60p. And for NTSC movies to 24p. In all those cases madVR won't activate deinterlacing. Only 25.000 is a bit more problematic.

The file may just lack a format block, or just not be marked as progressive sequence for odd reasons, yet be fully progressive.
Correct. In the same way it could be interlaced. So what is worse: Accidently activating deinterlacing for a progressive file? Or accidently not activating deinterlacing and having the user see combing? In the first case there should be no big problem. Both DXVA deinterlacing and madVR's IVTC should be able to pass progressive content through undamaged. But in the 2nd case the user would see nasty combing.

Anyway, I just think that by default you should stick to the same behavior as EVR, and deinterlace what you're told to deinterlace by the decoder, and not do any assumptions that might be wrong depending on the other filters in the graph or the source of the file.
EVR strictly sticks to the media type flags and the frame flags, and i don't usually see people complain.
Maybe we should put this to a vote? What are all of you guys think about this? Would you rather have madVR activate deinterlacing too often? Or rather not often enough?

[sneaker_ger]

I vote for the latter. When it is off, you can easily spot it and turn it on manually, but the other way around is not that obvious, while you are loosing quality and gpu time.

[madshi]

I don't understand why it would make a difference for the driver anyways, as I image madVR will internally decide what deinterlacing to use and then send it to the driver. It shouldn't matter for the card whether madVR detected interlacing automatically or whether it was forced to do it. :confused:
I don't understand it, either. Maybe it depends on which decoder you're using? In "auto field mode" madVR tries to make use of the information coming from the decoder. There is no such information encoded in the file, however. So "auto field mode" should equal TFF (and it does in my tests). But if you have a funny decoder which set random values or something, maybe that could explain the problem. But I don't see why a decoder would do that.

Sorry I didn't think a freezing report was much different, I made a debug this time.
Debug logs alone don't help. I need a freeze report, sorry. And again, these are FREEZES and not CRASHS, unless I misunderstood you and these are really crashs? But then you should send the crash report to me.

The video picture freezes on display mode change when having automatic fullscreen exclusive mode enabled.
Please retest with the next build, once it is released.

[oddball]

Well it looks like if I want bitstreaming support I cannot use MadVR and use EVR Sync instead which is a shame or just use ReClock to adjust the audio alongside MadVR which I have always done in the past. It's bugging me having to output as analog though instead of letting the receiver do it's thing.

[sneaker_ger]

I don't understand it, either. Maybe it depends on which decoder you're using? In "auto field mode" madVR tries to make use of the information coming from the decoder. There is no such information encoded in the file, however. So "auto field mode" should equal TFF (and it does in my tests). But if you have a funny decoder which set random values or something, maybe that could explain the problem. But I don't see why a decoder would do that.

I tried both madVR's internal decoder and LAV, plus I tested LAV Splitter and Haali's splitter. No other filters in the chain.

Decided to create a log, no idea if it is of any use:
http://www.mediafire.com/?8to7gxzx2ecu0b9
1. start playing (progressively)
2. force deinterlacing via ctrl+alt+shift+d (not working)
3. force field order tff (starts working)
4. force field order bff (still working)
5. end

[FlashGordon]

Hmmmm... So the bitstream of the real movie contains the necessary information while the menu does not. That kinda makes some sense. However, I'm wondering why the "best guess" is wrong! For 720x576 the best guess should be EBU. What happens if you play the VOB file directly which contains the menu? Do you get SMPTE-C then, too? If so, please upload a small portion of the menu. Otherwise: You could try deleting all the movie VOBs and only keeping the menu VOB, together with all the other DVD helper files, and then send me that? It should be possible to dumb this down to a couple of MBs. Thanks!

Opening the intro VOB (the first thing that shows up when I open the full DVD) gives me EBU (says bitstream). The DVD Navigator isn't present when I open the individual VOBs, but it is when I open the full DVD. Maybe that has something to do with it? Either way the resolution is reported to be PAL resolution under all circumstances, so I don't know why it is using SMPTE-C primaries when the Navigator is active

Anyway, here is the menu sample: http://www.mediafire.com/?ir9b7gxfadx71v3

The intro VOB (video_TS.vob) is very short and it wasn't letting me pause it, so I left the menu VOB in there which is ~240 MB.

Here are the IVTC Samples:

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

http://www.mediafire.com/?53571v9kxh72hj9

The shorter sample in there is from a different DVD I found to exhibit some similar behavior, but the combing seems to be much rarer on this DVD compared to the Broken Blossoms ones you requested

[fairchild]

I just watched an entire blu-ray and while the video was still running I F4 to close the file as usual (during the credits) and I had a black screen freeze where the only solution is to hit CTRL+ALT+DEL and end MPC-HC.exe through the task manager. I forgot to take a log, but safe to say it's still having problems. The Blu-Ray was a MPEG2 encoded disc (Sleepy Hollow) and using that 4119 test build.