madVR - high quality video renderer (GPU assisted)

[Hypernova]

Which is interesting, as according to the sig, Hypernova has a HD2600 Pro 512mb.

I have a HD2600XT 256mb, which is a tiny bit faster, and I have no problems at all. (But I am watching 1920x1080 material at 1920x1080, so only Chroma scaling).

You are the reason why I'm still trying ;). But I do agree with yesgrey3. Like I said before, I can scale to 1080p with SoftCubic50/100 and get smooth playback. Using Lanzcos/Spline, I can't get smooth playback at 1080p. At my fullscreen resolution, however, only Bilinear will give me smooth playback. So it looks like it is the GPU speed limit and nothing else. But upload/render queue are safely above 4 at all time. So madshi still gives me some hope, and I still hold on to that :)

This last piece of result seems to crush my hope though. I tried 29.970 1080p video and it looks like my GPU can't really keep up even without any scaling (in windows mode). In this case, upload/render queue are ~ 1 and 3 respectively.

[Mike5]

I tested on Win7 RC1, x86, HD4650, Catalyst 9.4, MPC-HC, ReClock on.

Now the refresh rate is Ok (50.00XXX). A few (2-5) dropped or delayed frames only at the beginning and on seek. Playing is smooth.

Decoder queue 16/16
upload queue 5-8/8
render queue 6-8/8

BTW, what do these numbers mean ?:confused:

[Mark_A_W]

I'm sorry to inform you, but the external vsfilter is more advanced in the features it supports than the internal MPC one. As for Haali's renderer, subtitle rendering happens with MPC by using vsfilter callbacks, so Haali's renderer doesn't magically use any other subtitling code, it's still vsfilter that does the job.

Similar advice to Mark_A_W, who also somehow believes Haali's renderer has a subtitler incorporated. Just use the vsfilter.dll I've linked to in a previous post, and be done with it. No more "madVR doesn't support subtitles" nonsense, please. This is the fourth time I write about this, but some people seem to have selective blindness.


Ok, I fixed it, thanks for pointing it out.

Yes, VSfilter.dll version 2.39 works fine.

I had an older version of DirectVobSub.ax lurking in Windows32, and it was causing chaos.

So the only bug I *really* need fixed is the Screensaver/Power settings not being disabled.

With that working I can go to MadVR as my primary renderer (that means using it to watch a movie with guests present...that's when all hell usually breaks loose!).


Thanks

Mark

[Hypernova]

Could someone write a small tutorial on how to get subtitles working?

It seems to me that you have to choose madVR at output page only. I always choose madVR using External Filter page and set it to prefer, but this seem to not work with VSFiler.

On the subtitle topic, I just tried 2.39, and I still prefer MPC-HC internal subtitle renderer because I can choose to render it at high resolution. I know VSFilter is more accurate than MPC-HC's internal (and ffdshow is worse of the three), but the high resolution text still win over, as I have to do a pretty big upscaling.

So I'm still waiting for madVR subtitle support :D

[tetsuo55]

thanks Hypernova, that did the trick

[sucht]

first of all Sorry for my bad English.

secondly i love this renderer.

... but i have a little problem here, that i try to explain.

together with madVR i use *.3dlut files with color corection for my Sony HDTV (i have all the primaries for my TV).

and i used them (the same primaries for my TV) for quite some time now, in a shader code taken from this thread at -> http://www.avsforum.com/avs-vb/showthread.php?t=912720 , together with VMR9 renderer, MPC-HC on WinXP.

the player i use the whole time is MPC-HC, and i want to use madVR, basicly because it gives the best picture, but everytime i use madVR together with the(from me) created *.3dlut file there are black spots or something like that(sorry don't know how to call them) like in this picture -> http://img507.imageshack.us/img507/2933/madvrwith3dlut.png ,you can see them in the face of the women in front, over the safe on the wall and some other places in the picture.
without the *.3dlut file there are no problems at all(beside the wrong colors) -> http://img268.imageshack.us/img268/5845/madvrwithout3dlut.png .

i've also made 2 more screenshots for comparsion, were i used VMR9 together with the color corection shader code, -> http://img198.imageshack.us/img198/7422/vmr9withcolorcorrection.png , "without such black spots like in the screenshots above with madVR as renderer with *.3dlut".
and here without the color corection shader code -> http://img198.imageshack.us/img198/210/vmr9withoutcolorcorecti.png .

i use ffdshow as decoder and scaling to 1080p and Lanczos 4tap, for VMR9.
and for madVR i also use ffdshow as decoder, but without scaling to 1080p because this scaling job does madVR.
i tryed all the options within madVR's UI, but it stays the same.
the only thing is not to use the *.3dlut files, but then again i can not use the color corection :(

these are the options in my *.3dlut files
# Set input bitdepth
Input_Bit_Depth 8

# Set source video format
Input_Video_Format NTSC(or PAL_DVD, HD) YCbCr

# Set output bitdepth
Output_Bit_Depth 16

# Set display video format
Output_Video_Format NTSC(or PAL_DVD, HD) RGB_Video
Output_Primaries 9 0.648 0.332 0.195 0.636 0.149 0.060 0.302 0.322

i have the problem with, HD (blu-ray, HDDVD), SD (NTSC, PAL) and all the kinds of avi, mp4, mkv ... etc.

so my question is, am i doing something wrong?
or is it a problem with madVR or the *.3dlut creation file(cr3dlut.exe)?


again sorry for my bad english, as it's not my native language :/
and i hope the stuff i wrote can be understand.
and i'm sorry if this is not the right thread to post my problem.


ciao
thomas

[tetsuo55]

I'm sorry to inform you, but the external vsfilter is more advanced in the features it supports than the internal MPC one. As for Haali's renderer, subtitle rendering happens with MPC by using vsfilter callbacks, so Haali's renderer doesn't magically use any other subtitling code, it's still vsfilter that does the job.

Similar advice to Mark_A_W, who also somehow believes Haali's renderer has a subtitler incorporated. Just use the vsfilter.dll I've linked to in a previous post, and be done with it. No more "madVR doesn't support subtitles" nonsense, please. This is the fourth time I write about this, but some people seem to have selective blindness.
KoD what does the external filter do that the internal one does not? (they should be identical exept for the ability to work on other players)

What you're basically saying is that the internal renderer not working (correctly) with HR or MVR is a regression/bug

[Jong]

Hey guys, I don't want to throw a spanner in the works here, but take a look at these screenshots of the DVE PAL Geometry test pattern using MadVR and VMR9 (A=0.75).

VMR9 (below):

http://jong.pwp.blueyonder.co.uk/doom9/Geo_VMR9.jpg

MadVR (below):

http://jong.pwp.blueyonder.co.uk/doom9/Geo_MadVR.jpg

These scaled down images clearly do not show things clearly!! (The smearing of the circles is particularly lost in the downscaling and some extra artifacts are added to both images). Here (http://jong.pwp.blueyonder.co.uk/doom9/MadVR_001.ZIP)are the full bitmaps. You really need to look at those before commenting! :)

Some may feel the VMR9 version is slightly over-sharp. In fact you may be horrified to find I use an Edge Enhancement setting of "1". Personally a prefer the slight tightening the EE algorithm gives on its absolute minimum setting. However, this could be turned off. More significant IMO though is the real mess MadVR (default settings) makes of several areas such as the smearing on various parts of the two black circles and the variation in thickness and grey scale level of many of the grill patterns. Also the thickening of the text "720" inside the outer circle. And lastly there are some horizontal lines running across the diagonal grills on the right hand side that are quite nasty!

I will be very interested in your thoughts.

Edit: I have added a screenshot of VMR9 without EE to the zip file for completeness.

[Mark_A_W]

What settings did you use Jong?

And the input res to MadVR is 720x576? No ffdshow scaling first?

What is your output resolution? And what MadVR settings do you use.

I see no such issues, but I don't scale Luma.

[FoLLgoTT]

I will be very interested in your thoughts.

Did you read the whole thread? Of course madVR's standard SoftCubic produces soft images. Switch to Lanczos and the result turns around. ;)

[Jong]

Default settings for MadVR except 3Dlut ticked.

- PC levels
- Luma upscaling softcubic 50
- chroma resampling softcubic 100

No "trade offs"!

No ffdshow, no other scaling, MadVR gets 720x576.

As you can see from the full size bitmaps my screen res is 1920x1080.

Yes, I think this is an effect of scaling, but a major handicap for DVD.

[Jong]

Did you read the whole thread? Of course madVRs standard SoftCubic produces soft images. Switch to Lanczos and the result turns around. ;)Less of attitude please! It is not the softness I am commenting on. Read again.

Anyway I considered Madshi's default and therefore presumably recommended settings were the best place to start, regardless of other thread "comments"!

None the less, I will take a look at your suggestion and we will see.

[FoLLgoTT]

Less of attitude please! It is not the softness I am commenting on. Read again.

Sorry, I didn't want to be rude. :)

Ok, the artifacts look like half vertical resolution. Did you checked the deinterlacing settings of the decoder? The picture looks like BOB and not WEAVE.

[Jong]

No, its not half resolution. Same decoder used in both screenshots and anyway look at the finest one pixel wide grills. They are stil there.

Just checked using Lanzos4 resize and all the main problems I mention are still there. I've added a Lanczos screencap to the zip file.

[Jong]

@Madshi,

Could MadVR have a problem with 720x576? I notice the OSD says 720x480!

[tetsuo55]

did a lot more testing.

Terrible results with DVD's

Every DVD gives this error:
http://img33.imageshack.us/img33/9959/dvderror.th.png (http://img33.imageshack.us/my.php?image=dvderror.png)

Some still work though, all DVD's play audio, right click navigation works, but i get a black screen for many of my DVD's
Here is a sample:http://sharebee.com/b988c279
(You have to rightclick, go to navigate, then click on title menu)
PS i am using FFdshow


Finally the filter refresh rate is wrong when playing DVD's as shown in this screenshot:

http://img33.imageshack.us/img33/5011/incorrectframerate.th.png (http://img33.imageshack.us/my.php?image=incorrectframerate.png)

On top of all that i have an MKV that works fine with all other renderers but crashes MPC-HC completely when using MadVR
EDIT: Sample here http://sharebee.com/4351620b (due to ugly cutting the image stutters on all renderers in this sample)

[FoLLgoTT]

No, its not half resolution. Same decoder used in both screenshots and anyway look at the finest one pixel wide grills. They are stil there.

The problem is only vertical. If you look at the bursts in the left half of the picture you can see that the horizontal bursts are intact while the vertical bursts are of much lower resolution. Exactly this happens when BOB is selected.

Which decoder and player are you using?

[Egh]

Whoops one more interesting problem.

I can watch 720p with any settings easily. However, I discovered I cannot watch now 1080p downscaled to 720p with Lanc8. All other methods work fine. Even spline64 works. But when I switch to lanc8 I observe massive frame drops (and still low CPU, so it seems GPU is overloaded). Render queue is 7 or 8 / 8 with any resampler.

[Jong]

The problem is only vertical. If you look at the bursts in the left half of the picture you can see that the horizontal bursts are intact while the vertical bursts are of much lower resolution. Exactly this happens when BOB is selected.

Which decoder and player are you using?Have you looked at the full bitmaps and read the full list of problems I have mentioned. Sorry, honestly, thanks for helping to diagnose, but this is not bobbing. If it were, apart from all the problems that are nothing to do with bobbing, the finest grill pattern would disappear.

I am using Cyberlink SD decoder (PDVD7) with MPC-HC and (just to be sure!) I forced weave. With Bob, as I mention, the finest grill disappears. Actually it goes grey, rather than black or white (disapears against the background), which is surprising and may be another problem.

[madshi]

There were two or three very obvious big glitches, but it was otherwise smooth.
This is similar to Beliyaal's MPC EVR custom actually (not in exclusive fullscreen), but they were less drastic.
Not sure what you're saying: Were the glitches less drastic with madVR compared to EVR-CP, or the other way round?

And I have seen a few stutters which didn't cause the dropped frames or delayed frames numbers to change - while playing around just now.
Hmmmmm... Sometimes madVR is in "buggy state" after pausing or seeking and then stutters like crazy. Just re-seeking fixes that for me. Maybe this is what you noticed? Or was it only a slight sutter now and then? In that case it might be a bug in madVR somewhere. If so, it would be great if you could find a way for me to reproduce the problem somehow...

Just a couple of issues so far:

- Changing monitor rez during playback no longer handled gracefully (black screen, but playback continues, MPC becomes non-responsive)
- Playback of 1080/30P (1:1) with many dropped/delayed frames. Counters increment as playback continues

720 24/30P are stable, good numbers, very smooth.
How about 1080p24?

1. Could you include a brightness or gamma slider on the settings screen? Some movies are too dark, so I want to change the brightness while watching the movie. Yes, most decoders have this, but it would be great if we could adjust it for all the formats in the same place, which is the renderer.
madVR already includes the math operations to do brightness, contrast and saturation modifications, I've not had the time to implement controls for that. It's not only more comfortable to have these controls in the renderer, it's also better for quality, btw. If you let the decoder e.g. brightness modifications, that will negatively affect image quality, cause the decoder still outputs only 8bit in the end. Doing it in madVR means that it's done in 16bit with no loss in image quality.

I'm afraid version 0.10 now gives me permanent tearing with 24fps material at a reported refresh rate of 24.001Hz, with or without ReClock. The vsync interval is 41.66ms, the movie frame interval is 40.67ms. This is with both SD and HD video on a 1080p screen using an 8600GT. Previous versions of madVR were fine.
That's weird!

Was something changed with downscaling in 0.10 which could be causing the render queue to not keep up with the video. In earlier versions of madVR, downscaling seemed less intensive then upscaling since a smaller image had to be rendered. In any case, I'm suspecting this is a bug in 0.10.
I don't think this is a bug. Downscaling is actually more calculation intensive than upscaling, if source and target resolutions are near. Generally, the higher the source resolution, the more power is needed. And the higher the output resolution, the more power is needed. And downscaling eats more performance than upscaling.

Did anyone get Zoomplayer 6.0 to work without any Macrovision failure when trying to play a DVD and using Madvr 0.10?
Yes, I did. For me DVD playback works. But I'll retry with my new HTPC later. Hopefully I'll then be able to reproduce the problem.

Madshi, in fullscreen exclusive mode you can do your own OSD right? At least equivalent to the MPC one and hopefully a lot less gross!?
I can do my own OSD for things private to madVR. I can not overwrite the MPC HC OSD, though, for seeking bar etc...

when I try opening a file in ZoomPlayer, I have to wait about 10 seconds till playback starts.
Hmmmm... madVR 0.10 delays playback until it knows the display's refresh rate. That usually takes exactly 1 second. Maybe fetching the display refresh rate takes much longer on your PC for whatever reason? Not sure...

Maybe Microsoft is counting front porch, back porch and sync width lines too ?
Have a look at the official MS documentation yourself:

http://msdn.microsoft.com/en-us/library/bb172596(VS.85).aspx

It's 100% clear that porches are not supposed to be reported.

The only exception is 1024x576p60 video -> 1920x1080p60 output. Continuously tearing and dropped frames pop up about every 2 ~ 3 seconds. It is a progressive MPEG2 video content with 16.67 ms frame duration, which is the same with V-sync refresh rate in my system. The decoder queue shows "1/16". Isn't the a/v sync mechanism flexible enough for such 1:1 renderering mode?
The a/v sync mechanism should be flexible enough. But maybe your hardware is not fast enough? 60p content is 2.5x as much taxing on the hardware compared to 24p when using madVR.

Does the problem only occur with that one specific movie? Have you tried different movies with similar codec and framerate? Also trying different decoders might (or not) be interesting...

How do you apply the change of output window dimension? I am curious how it produces these new issues with the version 0.10's implemention.
"Change of output window dimension"? Not sure what you mean.

just encountered a problem, I get constantly dropped & delayed frames and a massive stuttering picture during playback with 720p 60i mpeg2 files (no matter if .ts or remuxed to .mkv), maybe because in this case vcsync invertall is 16.66ms while movie intervall is 16.68ms (upload queue 5-7/8 (but once for example also dropped to 3/8 shortly), render queue 5-8/8)
Does your decoder output 60i as 30p or as 60p? Or is there any other filter which might deinterlace the source to 60p?

With 0.10 I have big performances issues with my 8600 GTS. I need now to disable 3Dlut and turn on at least one performance option if I don't want have a horrible stutter with tons of dropped and delayed frames. I could use the top quality settings with earlier versions.

I wonder if this has to do with the fact I play move a 23.976fps movie on a 72Hz screen, maybe It will better on a 24Hz screen.
Anyone else with a 8600 having similar problems?

24p content on a 72Hz screen should be no problem.

[madshi]

v0.10 Bug Report using Zoom Player:

1. When pausing the video, the image is not updated (pause the video then drag the window off-screen and the window will be wiped black).
2. Switching the playback window between monitors doesn't update the OSD data (which may indicate that it's not being updated with the new monitor data).
3. Initial video load drops a lot of frames (even with tear-fix disabled), about 9-15 dropped.
4. Pressing Stop and then seeking, doesn't update the image (and pressing Stop doesn't show the first video frame either).
5. Pressing Pause doesn't pause the image instantly, at least 3-4 more frames are displayed.
6. I still get the occasional full on freeze (no image, GUI stops responding).
7. It takes 2-3 seconds longer than other renderers for the first video frame to show.

WinVista 32bit, NV 7600GT
Yes, I need to work on all these issues. Some of them were newly introduced in madVR 0.10. That's because I've rewritten so much. These things will soon get better again.

[madshi]

Something interesting i've found out. When you turn VSYNC and Triple Buffer on (in 3D settings,in catalyst), you get much smoother playback .
That's weird. Do you mean that Triple Buffering option for OpenGL? That cannot possibly have any effect on madVR cause madVR simply doesn't use OpenGL! The VSync option can have an effect - but only if you had it "forced off" before. All other settings should be identical, cause madVR asks the graphics card to please do use VSync.

a question on those lanczos filters, is it the higher the better (just with more GPU power needed)? if yes then why was lanczos4 chosen instead of lanczos8 for luma downscaling, shouldnt lanczos8 be better then?
IMHO Lanczos4 is a bit better than Lanczos3 in some ways (sharpness, aliasing) and worse in other ways (ringing). And IMHO Lanczos8 brings no noticeable advantages over Lanczos4, but at the same time shows more ringing. I personally dislike Lanczos8 and have only added it on request.

Have you guys tried the new dithering option in ffdshow? Madshi's test patterns look very very close to madVR. I see no real world difference.

[...]

madVR is sighly better, but I can see absolutely no real world differences and it has the advantage of being renderer agnostic. You can use it where you want as long as the renderer accepts RGB32.
Yes, ffdshow is renderer agnostic. Too bad that IMHO all the other renderers suck more or less. That's the only reason why I started working on madVR in the first place. Ok, Haali's Renderer is nice, but it's buggy and tears for me. Beliyaal's EVR-CP is smooth and works well - but it doesn't bypass the bad GPU post processing.

It should also be noted that ffdshow uses dithering now only for color space conversion. Scaling is still only done in 8bit, AFAIK. But of course it's great that ffdshow can dither now!

2) Issue with VC-1 WMV DMO decoder: 'delayed frames' and 'dropped frames' are progressing. And using MPC-HC internal VC-1 decoder everything is OK.
Weird! Can you reproduce that with multiple different movies? For me the MS VC-1 decoder has always been the best working decoder...

So it looks like it is the GPU speed limit and nothing else. But upload/render queue are safely above 4 at all time. So madshi still gives me some hope, and I still hold on to that :)
There still is some hope if you upload/render queues stay above 4. But I'm not 100% sure, anymore, right now. I might have underestimated how dropped frames could affect the render/upload queues. But anyway, only time will tell...

BTW, what do these numbers mean ?:confused:
Decoder queue: That's a system memory cache where madVR collects fully decoded frames coming from the decoder.
Upload queue: That's a GPU memory cache where fully decoded (but not processed yet) frames are stored.
Render queue: That's a GPU memory cache where fully rendered frames are stored.

These queues are meant to make sure that any time variances are evened out. E.g. if the decoder suddenly stops decoding for a couple of frames, the decoder queue can handle that without any stuttering.

The numbers in the OSD mean how far the queues are filled. The higher the numbers the better.

everytime i use madVR together with the(from me) created *.3dlut file there are black spots
Which cr3dlut version have you created the 3dlut files with? Please make sure you're using the latest version. If that doesn't help, this might be a problem yesgrey3 needs to look into. (The cr3dlut developer).

Do you get the same problems if you create a 3dlut file without any custom primaries?

[Mark_A_W]

Not sure what you're saying: Were the glitches less drastic with madVR compared to EVR-CP, or the other way round?


Hmmmmm... Sometimes madVR is in "buggy state" after pausing or seeking and then stutters like crazy. Just re-seeking fixes that for me. Maybe this is what you noticed? Or was it only a slight sutter now and then? In that case it might be a bug in madVR somewhere. If so, it would be great if you could find a way for me to reproduce the problem somehow...




MadVR has less drastic glitches than MPC-HC. This is with reclock "bypassed".


And yes, I noticed it jump without changing the OSD after seeking around and pausing - just piss farting around. It's very hard to duplicate these things...


I just watched The Forbidden Kingdom (meh..ok), and there was only one glitch, and the OSD did update (well, it had dropped and delayed when I turned it on at the end of the movie.
I had Reclock running "active" and it was seriously as smooth as silk.
The glitch could have been caused by a TV recording starting up (it was around the right time), but it was also at about the right time I seem to get a glitch anyway - 30 mins to an hour in. So hard to tell the cause.

Could be that Fullscreen Exclusive is the only real fix for these things.

More testing needed...it might just be my PC, others need to verify with full length movie testing. 5 mins here or there isn't enough, you need to watch for 2 hours.

But overall it was a raging 99% success. MadVR is already good enough for me to switch (now I have subs working).



Also...my monitor didn't turn off today. Strange. Then again, standby/powersaving is the one of 2 things that drives me nuts about Vista (the other is the explorer templates). Today my PC wouldn't go into standby at all. Yesterday it kept turning the monitor off while MadVR was running. Occasionally it fails to wake to record something.

Grr. That side of things worked better on XP.

Keep it up Madshi - eagerly awaiting the next build :)

[Jong]

.I can do my own OSD for things private to madVR. I can not overwrite the MPC HC OSD, though, for seeking bar etcOh. OK. So will MPC-HC automatically display its D3D seek bar once you use D3D mode?:confused:

[tetsuo55]

i added the mkv sample to my last post

[Mark_A_W]

Some more useless info Madshi:

I've just spent half an hour watching credits roll, looking for smoothness.

With Reclock active = perfect.


With Reclock bypassed = occasional tiny jump or judder, that does not cause the OSD dropped/delayed frames to change.

It's definitely better with Reclock running fully (reclock v-sync off however).


Also, would it be possible for MadVR to generate a log? I'd love to be able to sift through 2 hours worth of data, looking for a reason why I'm getting glitches halfway through a movie.

If it logged MadVR activity, and windows activity, I might be able to either exclude windows from the cause, or tie it to windows doing something stupid.

Obviously, Zoom Player is the only program running (apart from background tasks..like TV recording), and I have Reclock set to High CPU priority (Can MadVR have Real Time priority?).

Cheers

Mark

[madshi]

Hey guys, I don't want to throw a spanner in the works here, but take a look at these screenshots of the DVE PAL Geometry test pattern using MadVR and VMR9 (A=0.75).
Ouch, never seen anything that ugly with madVR yet! That's certainly a simple bug and not representative of how madVR usually looks like...

Could MadVR have a problem with 720x576? I notice the OSD says 720x480!
That might be a hint. I mean madVR has no problem with any resolution. But if the OSD reports something different to the real resolution, that might show where the problem may be coming from.

Could you please try different decoders? It could be a bug "catalyzed" by how the decoder behaves. They are all behaving slightly different!

Oh. OK. So will MPC-HC automatically display its D3D seek bar once you use D3D mode?:confused:
I guess MPC HC will need to know that the renderer is going fullscreen exclusive and in that moment MPC HC probably activates its fullscreen OSD. But that has really nothing to do with madVR.

Whoops one more interesting problem.

I can watch 720p with any settings easily. However, I discovered I cannot watch now 1080p downscaled to 720p with Lanc8. All other methods work fine. Even spline64 works. But when I switch to lanc8 I observe massive frame drops (and still low CPU, so it seems GPU is overloaded). Render queue is 7 or 8 / 8 with any resampler.
Yeah, sounds like GPU overload. I'll need to invest some thinking into why the render queue is still looking good even when you have stuttering all the time...

But overall it was a raging 99% success. MadVR is already good enough for me to switch (now I have subs working).
:)

Every DVD gives this error [...]
I'll try your sample, but I'm rather sure it will work for me, cause for me every DVD seems to work just fine without any problems on my current PC. Don't know why! But I'll try on another PC later...

Finally the filter refresh rate is wrong when playing DVD's
Could you please post your pin connection info (in [ code ] [ / code] blocks)?

On top of all that i have an MKV that works fine with all other renderers but crashes MPC-HC completely when using MadVR
EDIT: Sample here
That link doesn't work for me. "Page not found".

Some more useless info Madshi:

I've just spent half an hour watching credits roll, looking for smoothness.

With Reclock active = perfect.

With Reclock bypassed = occasional tiny jump or judder, that does not cause the OSD dropped/delayed frames to change.

It's definitely better with Reclock running fully (reclock v-sync off however).
Not a useless post at all. However, I'm scratching my head why you get smoother results with ReClock - and why the OSD doesn't reflect the stutter you're seeing. Stupid question: But I supposed you're sure that the stuttering is for real, right? :p

Which source/display refresh rate are we talking about?

Also, would it be possible for MadVR to generate a log? I'd love to be able to sift through 2 hours worth of data, looking for a reason why I'm getting glitches halfway through a movie.
I can compile madVR with logging activated. But it's then logging so much that it beings to stutter slightly... ;) I might have to invest some more time into only writing really useful information to a specific "end user" log file.

Obviously, Zoom Player is the only program running (apart from background tasks..like TV recording), and I have Reclock set to High CPU priority (Can MadVR have Real Time priority?).
Hmmmmm... If you set ReClock to high CPU priority, does that change the ReClock thread or the whole process? In the latter case it would affect madVR, too, of course. Maybe you could check with the sysinternal ProcessMonitor (or was it called ProcessExplorer)? That tool can show thread and process priorities, IIRC.

[tetsuo55]

Could you please post your pin connection info (in [ code ] [ / code] blocks)?
Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: YV12 720x480 (4:3) 25.00fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 518400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(720,480)
rcTarget: (0,0)-(720,480)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 480
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 518400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 d0 02 00 00 e0 01 00 00 ........Ð...à...
0010: 00 00 00 00 00 00 00 00 d0 02 00 00 e0 01 00 00 ........Ð...à...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 d0 02 00 00 ........(...Ð...
0050: e0 01 00 00 03 00 0c 00 59 56 31 32 00 e9 07 00 à.......YV12.é..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................


That link doesn't work for me. "Page not found".

fixed, here's the link again
http://sharebee.com/4351620b

[madshi]

Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: YV12 720x480 (4:3) 25.00fps
As you can see, ffdshow reports 25fps, so madVR's OSD is correct.

[mark0077]

I now also get a popup error when trying to play DVD's. I used to just get macrovision error but now an error popup appears before the macrovision error.

madshi, did you try playing DVD's that are stored on your hard drive by for example opening video_ts.ifo file in mpc-hc. This is how I test DVD's and get the macrovision error to appear.

[pie1394]

The a/v sync mechanism should be flexible enough. But maybe your hardware is not fast enough? 60p content is 2.5x as much taxing on the hardware compared to 24p when using madVR.

Does the problem only occur with that one specific movie? Have you tried different movies with similar codec and framerate? Also trying different decoders might (or not) be interesting...



It was mentioned that it worked fine before with madVR 0.8 / 0.9 and VMR9 / EVR on 8800GTS/320.


"Change of output window dimension"? Not sure what you mean.


Sorry about the confusion! I just mean the change of video output window position/size. Just feel it should not have any relation with other output frame control mechanism. Thus it cannot be imagined that black frame is produced each time madVR 0.10 gets notified to change output window parameters.


There is one annoying 1280x720 23.976fps H.264 anime video clip, which contains the horizontal scrolling text at 2:37 ~ 2:55. With EVR CP and madVR 0.9, it produces smoothy moving effect even if the video is scaled to 640x360, 1400x1050, or 1920x1080 output size at 60 Hz.

On madVR 0.10, it only gets somewhat smoothy moving effect with 1280x720 output window size. If you are interested in taking a look why madVR 0.10 does not work well with it, here is the bt link of this video. It is somehwat big -- 410MB.

.....

The playback is by MPC-HC build 1081 + CoreAVC 1.9.5.0

[noee]

Madshi:
I just tried some AVCHD in 1080/24P (9 484 Kbps) and the numbers were:

decoder queue: 16/16
upload queue: 7/8
render queue: 4/8

I get drops when the videos start, usually between 50-90.

This is w/Reclock. The video playback is smooth and does not tear, other than the very first second or two as it starts playing.

I'm going to go back to my 30P material and see if I can find out if it's just that extra Mbps or what. The HD2600XT might just be the lowest end card usable for HD 24P material, I guess we'll know more soon enough...

[yesgrey]

I have a HD2600XT 256mb, which is a tiny bit faster, and I have no problems at all. (But I am watching 1920x1080 material at 1920x1080, so only Chroma scaling).
That makes a big difference, because you don't have any luma scaling.

everytime i use madVR together with the(from me) created *.3dlut file there are black spots or something like that
Yes, I'm aware of this since the beggining of cr3dlut. The initial releases did not have this problem because I was clipping the BTB data to avoid those black spots, but recently I disabled it and now it's showing again. The only thing that it's strange is that you seem to be getting it without changing the gamma, and with me this only happened when I was using at the output a different gamma curve from the input...
I will have to look into it again.:(

[tetsuo55]

As you can see, ffdshow reports 25fps, so madVR's OSD is correct.

I reported the problem in the ffdshow thread, it might be related to some of the DVD playback issues

http://forum.doom9.org/showthread.php?p=1286954#post1286954

[pie1394]

Decoder queue: That's a system memory cache where madVR collects fully decoded frames coming from the decoder.
Upload queue: That's a GPU memory cache where fully decoded (but not processed yet) frames are stored.
Render queue: That's a GPU memory cache where fully rendered frames are stored.

These queues are meant to make sure that any time variances are evened out. E.g. if the decoder suddenly stops decoding for a couple of frames, the decoder queue can handle that without any stuttering.

The numbers in the OSD mean how far the queues are filled. The higher the numbers the better.



Except to NT4.0 kernel, I remember other NT-kernel OSes are not truly real-time. i.e. It does not guarantee something like msleep(1 ~ 10) are actually accurate. From my previous experience in doing multi-threaded playback system with Linux 2.6.x, it has the similar issue.

If the thread which controls next displayed frame is triggered by GPU's ISR each time the displayed buffer has been flipped, 3 video frame buffers are usually more than enough to provide smoothy presentation.

Large Queue Depth at the decoder and video post-processing / rendering stages often yield bad user experience on trick play actions, especially for some stream contents which are not well muxed. The better design on the resource limited embedded system often lets demuxer to control the sending sequence to video / audio decoders so that most filters in the decoding chains do not need too ridiculously many buffers in the queue. (Usually 2 ~ 3 are more than enough, 0 for the processing chain by the same thread)

Due to the fact that different thread filters often have the different CPU priorities, it makes the situation worse with too large queue depth. Some CPU time consuming threads could eat out most CPU time before other lower priority threads gain the CPU time again.

[KoD]

I thought you can override placement on per style basis :) Or maybe vsfilter is not that advanced then.


Not exactly as there are some differences between MPCHC and vsfilter renderers, apparently.
In MPCHC you can, for instance, select the texture resolution to render subs on.

Manually overriding subtitle placement should not be done, because positioning hints in the subs are no longer respected.

The only thing a subtitle creator is sure about when he designs subtitle placement, is the size of the video frame. It can't know the size of the black bars on any random viewer's screen. If the video frame is a 16:9 one, there will be no black bars when rendered on a 16:9 screen, there will be some bars on a 16:10 screen (like many laptops have), and there will be wider bars on a 4:3 screen. That's why positioning info embedded in subs is only relative to the video frame, so when you override the subs placement because you like them outside the video frame, positioning is no longer correct. You'll definitely notice this if you use ass subs or dvd subs with positioned signs.

Yes, MPCHC has the advantage of knowing what the size of the resized image is, so that's why it uses vsfilter to render the subs at that resolution instead of the video frame size.

As for what's different between the external vsfiter and the one in MPCHC: the external vsfilter (not the one from the new guliverkly2 repository, but the one from Aegisub) has a few more patches which might not have made it to MPCHC since they were being done privately for Aegisub. Aegisub is what's being used for creating ass subtitles, so the way they look in this application is the way they are meant to look on a viewer's screen. Also, I'm not sure about how things are now, but positioning by MPCHC's subtitle filter used to be different than positioning done by the external filter. Also, ther were issues with scaling anamorphic subs: in the case of anamorphic subtitles, the subs would have been created with a horizontal scale factor to account for the horizontal scaling of an anamorphic video frame; MPCHC would not realise this, since it fed vsfilter a horizontally uncompressed video frame instead of the compressed anamorphic one, and the result was horizontally compressed subs. This might have changed since then, though.

[wayland]

mpc-hc's internal vc1 decoder produces images like this when playing vc1 in m2ts files, mpc-hc also tends to crash alot when playing m2ts files with madvr, usually its fine though. the good image is using ffdshow tryout decoder

http://achumpatoxford.com/u/files/329/21e0bda0b265d095d2a7b794ad0f4898.png
http://achumpatoxford.com/u/files/329/89da2e9c9ebbf88d59543aae05d552a2.png

cant work out how to attach them as thumb sorry

[Jong]

Ouch, never seen anything that ugly with madVR yet! That's certainly a simple bug and not representative of how madVR usually looks like...


That might be a hint. I mean madVR has no problem with any resolution. But if the OSD reports something different to the real resolution, that might show where the problem may be coming from.

Could you please try different decoders? It could be a bug "catalyzed" by how the decoder behaves. They are all behaving slightly different!
The good news is it does seem to be caused by MadVR thinking it has a different resolution input! Using Nvidia Video decoder 720x576 is reported and the picture is much better (much as I would expect).

The bad news is DVD playback is clearly very tempermental and decoder dependent.

Here:

- the internal MPC video decoder just crashes MPC-HC!

- With the Cyberlink decoder is is pretty much possible to play a disc, but:

trying to bring up the menu brings up the last frame playing in the menus aspect ratio. You have to press menu again to see the actual menu.
When you try to select a still frame menu item you get the last menu frame repeated, not the still frame you selected
There are no indicators of which item on the menu is selected, whether you use the keyboard or the mouse but the items are selected correctly if you click on them.
As discussed, resolution is incorrect

- With Nvidia Video decoder

Menu items ARE highlighted
But the disc is close to un-navigable. The next chapter does not seem to do anything when selecting still frames, there is severe lag when using the keyboard to move around a menu, when a 2nd level menu is selected it does not appear, only when you start to navigate it (eg. pressing down arrow) does it appear. And once it got out of sync using the mouse and the item selected was always the previous thing I had pointed at!


I suspect this is why you are getting such inconsistent results from people for DVDs.

[Hypernova]

As a temporary work around for real watching, I decide to let ffdshow do the scaling (I just can't get that color band out of my mind, and letting ffdshow do the scaling seem to have no noticable effect on my eyes...yet). However, I can't get ffdshow to autoload madVR profile. I check "on a DirectShow filter presence" and set to madVR and it does not work. Anyone get this working?

[Thunderbolt8]

Does your decoder output 60i as 30p or as 60p? Or is there any other filter which might deinterlace the source to 60p?
I have no idea, I just use ffdshow as usual with no deinterlacing activated (as source is 720p) and im not aware that it should be outputted in another way (it also stays the same when I disable reclock). where can i check that in ffdshow settings?

[noee]

@HyperNova: At the time of profile load, FFDshow most likely does not "see" madVR in the graph.

@Madshi:
In case it helps at all or if anyone else is using AVCHD for testing....

I've found the issue. It apparently the M2TS container. I can play 1080/30P directly from the M2TS using HR and EVR in both JRMediaCenter and MPC-HC. Same graph using madVR I get tearing and many drops/delays.

Now, if I transcode the same 1080/30P M2TS to AVC (x264) inside of MKV, even at the higher bitrates (17Mbps), these files play very fine with madVR (other than the little bugs that have been reported on playback startup).

All of my 1080/24P material is already in AVC/MKV. My graph is HMS>CoreAVC195>Reclock>madVR (or other renderer).

[nuhi]

Having ffdshow output YV12 and madVR using 'softcubic100' chroma upsampling should have smoother reds then ffdshow using RGB32. Are you claiming this is not the case?

If so, maybe you should post a sample along with your configuration and hardware details.
Thanks for the tip, works great.

[mark0077]

Hi madshi,

Using madVR 0.10 on a m2ts blu-ray file I get pretty good playback in windowed mode, with a few dropped frames at the start of playback ~28. The minute I go to fullscreen mode all hell breaks loose. I was getting about 1 frame every 4 seconds when testing. This is not always reproducable. Sometimes I get perfect playback when going fullscreen. Then all of a sudden I was getting strange blocks of colors showing on screen. I managed to grab a screenshot when it was doing this. Going from windowed to fullscreen and back again is verry buggy at the moment, like some lock on the current frame isn't being created... but I am just guessing. If the initial move to fullscreen or back again seems to go ok, everything goes nicely from the non. If the initial move to fullscreen or back again goes wrong, I get the crazy colors all over the place like below... sometimes worse.

http://img98.imageshack.us/img98/8587/madvr010.th.jpg (http://img98.imageshack.us/my.php?image=madvr010.jpg)
and another. This image happened again when moving to fullscreen. It seemed like madVR began to resize only horizontally first, then began resizing vertically but got mixed up somewhere in between. You can see some parts scaled horizontally and some vertically giving black squares in each corner of the screen.
http://img220.imageshack.us/img220/3774/another.th.jpg (http://img220.imageshack.us/my.php?image=another.jpg)

I am using mpc-hc build 1111 and its own vc-1 software decoders.
My screen resolution is 1920 x 1080
The blu-ray is obviously 1920 x 1080 also @ 24hz (changed from 23.976 by reclock to 24hz).
My display refresh is 60hz.
Cpu: Core i7 920 @ 4ghz
GFX: NVidia GTX 295
Windows Vista 64bit.

[sucht]

Which cr3dlut version have you created the 3dlut files with? Please make sure you're using the latest version. If that doesn't help, this might be a problem yesgrey3 needs to look into. (The cr3dlut developer).

Do you get the same problems if you create a 3dlut file without any custom primaries?

the version i have created the *.3dlut files with is v2.1,
and the problem is not there, when i create/use a *.3dlut file without the custom Output_Primaries.

sorry again for my english :/

and thanks for your time.


ciao
thomas

[tetsuo55]

As for what's different between the external vsfiter and the one in MPCHC: the external vsfilter (not the one from the new guliverkly2 repository, but the one from Aegisub) has a few more patches which might not have made it to MPCHC since they were being done privately for Aegisub. Also, ther were issues with scaling anamorphic subs: in the case of anamorphic subtitles, the subs would have been created with a horizontal scale factor to account for the horizontal scaling of an anamorphic video frame; MPCHC would not realise this, since it fed vsfilter a horizontally uncompressed video frame instead of the compressed anamorphic one, and the result was horizontally compressed subs. This might have changed since then, though.
All patches he made have been added to SVN.

The aegisub author has completely aboned VSfilter, he is working on a new subtitle renderer.

i cannot comment on the anamorphic bug right now

[sucht]

Yes, I'm aware of this since the beggining of cr3dlut. The initial releases did not have this problem because I was clipping the BTB data to avoid those black spots, but recently I disabled it and now it's showing again. The only thing that it's strange is that you seem to be getting it without changing the gamma, and with me this only happened when I was using at the output a different gamma curve from the input...
I will have to look into it again.:(

thank you for looking into that, and also for your time doing so.

so basicaly, i can try and calibrate my display again, because i could have done a mistake?
i've used an Eye One Display LT and i think HCFR as the software.

i think i will play a bit more, maybe calibrate again and stuff like that.


thanks and ciao
Thomas

[STaRGaZeR]

Beliyaal's EVR-CP is smooth and works well - but it doesn't bypass the bad GPU post processing.

If you feed it with RGB32, the GPU can't do any post processing AFAIK.

It should also be noted that ffdshow uses dithering now only for color space conversion. Scaling is still only done in 8bit, AFAIK. But of course it's great that ffdshow can dither now!

Give it time :p BTW, it would be nice if you could redo your tests with the new dithering to show how effective it is.

[Egh]

All patches he made have been added to SVN.



Tetsuo55, can you explain how subtitle pin works? What is send there by MPCHC? Just textures with rendered subs? Who does the timing of it then?

[tetsuo55]

Tetsuo55, can you explain how subtitle pin works? What is send there by MPCHC? Just textures with rendered subs? Who does the timing of it then?
I don't know how it works exactly, but i do know that it merges a a full size image over the target image, but it only puts pixels where the subs go. (the rest is alpha transparent)

So basically if you have a 1920x1080 display the sub output will have to be 1920x1080 or be scaled to that size.

[yesgrey]

so basicaly, i can try and calibrate my display again, because i could have done a mistake?
No, it's not a problem with your calibration, it should be fine. It's a problem with the YCbCr->RGB conversion. If I don't clip after it, sometimes those black holes appear... I thought it was only a problem when changing the gamma, and that it was a natural consequence of the gamma change, but now it seems not to. Please be a little patient, I will try to look into it soon...