madVR - high quality video renderer (GPU assisted)

[sneaker_ger]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by sneaker_ger

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.

Originally Posted by sneaker_ger

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.

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

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.

Originally Posted by nevcairiel

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.

Originally Posted by ryrynz

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]

Originally Posted by madshi

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:


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]

Originally Posted by madshi

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]

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

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.

[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

[madshi]

Originally Posted by oddball

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.

Originally Posted by oddball

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.

Originally Posted by oddball

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.

Originally Posted by oddball

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.

Originally Posted by nevcairiel

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.

Originally Posted by nevcairiel

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.

Originally Posted by nevcairiel

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.

Originally Posted by nevcairiel

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]

Originally Posted by sneaker_ger

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.

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.

Originally Posted by JarrettH

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.

Originally Posted by HitomiKun

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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.