madVR - high quality video renderer (GPU assisted)

[karamancho]

A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime?

I was wondering the same ting. Are there any benefits in using smooth motion with (torrented) DVD/BR/HD rips played on a laptop display?

[mindbomb]

i notice now smooth motion (on the "only if motion judder without it" setting) doesn't turn on now if 29.97 fps on 60hz.
is that because it's close enough?

[cca]

i notice now smooth motion (on the "only if motion judder without it" setting) doesn't turn on now if 29.97 fps on 60hz.
is that because it's close enough?

You assume correctly. 60Hz is almost double of 29.97, and using ReClock or something similar will make it exactly double.

[namaiki]

From what I understand, before smooth motion was unintentionally enabled in this situation. (29.97fps vs ~60Hz)

Even if you don't use ReClock, it's probably close enough. My current computer does about 1 frame drop every 2.5 mins which I haven't noticed during watching... yet.


For the people who asked about 23.976fps material on a 60Hz screen with smooth motion, it should noticeably improve the smoothness of camera scene panning. Or at least for me, I don't bother changing to my 48Hz screen mode any more. I think it's about as smooth as you can get it without doing anything crazy like frame interpolation.

[madshi]

A question though, which material does smooth motion work with, as I don't seem to see a difference with your regular 23,97fps anime?
In theory it should "work" for any content. Is that anime content progressive or interlaced? If you deinterlace interlaced anime without forcing madVR into film mode, the output of the deinterlacer will be 59.940fps, so there's not much left for smooth motion FRC to do. Anime also isn't the best candidate for what smooth motion FRC does. FRC works best with smooth "soft" movements. Anime often has very "hard" movements. Such movements don't "blend" too well. But it should still work somewhat...

now with a queue of 128, I end up with ~80 dropped frames (i5-3570K @4.4Ghz) as the subtitle queue attempts to refill
Can you please upload a small log which shows those 80 frame drops?

A quick bug report (not due to this new build, as I tested with 0.86.1):
madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up.
A sample file: here (http://videoff7.free.fr/cvid_sample.avi).
In the exact same graph, replacing madvr by the VMRs or EVR solves the issue.
I can't find this in the bug tracker? ;)

but if PS scripts are limited to TV range in MPC by design, then how come
and I guess PS scripts applied on 0-255 source files(FRAPS for instance) will be a no-go as well
Is there a specific point to your questions? I thought the problem with your gamut PS script was solved? So why still asking weird follow up questions? Do you still have problems or not? I would have to re-study what MPC-HC's internal renderers do exactly to answer your questions, and if your questions are just about making a point, or about satisfying your curiosity, then I really have better things I can spend my time with...

I was wondering the same ting. Are there any benefits in using smooth motion with (torrented) DVD/BR/HD rips played on a laptop display?
Yes, definitely. But in order to have a real benefit, you need to make sure that for movie content you get the movies converted to proper 24fps/25fps first. If you use DXVA deinterlacing the output will be 30fps or 60fps, with baked in 3:2 pulldown judder. For interlaced movie content, forcing madVR into film mode is the only way to get smooth motion.

[cyberbeing]

Can you please upload a small log which shows those 80 frame drops?

http://www.mediafire.com/?61l9bvs640sn1v7

[madshi]

@cyberbeing,

according to the log the key problem is that the GPU render queue doesn't fill up. So it seems that the subtitle rendering somehow affects GPU rendering performance in your case. I find that a bit weird, to be honest, seeing that rendering is mostly limited by the GPU and subtitle rendering should be strictly CPU. However, looking at the log, I'm having a wild guess why this might occur:

The renderer asks the subtitle item about the "yuvMatrix". And my impression is that this simple information retrieval often blocks for a looooong time. Is it possible that asking a subtitle item about its yuvMatrix internally runs into some critical sections? And this could stop the renderer from proceeding while the subtitle thread is busy rendering subtitles?

If my guess is right, this is not a problem with the size of the subtitle/decoder queue at all. Instead it indicates a design flaw in xy-vsfilter: Asking a simple property like yuvMatrix should not need critical sections, because it's a static information field which never changes (for one subtitle frame). xy-vsfilter should be double checked to limit the use of critical sections to where it is absolutely needed. Also xy-vsfilter shouldn't use just one critical section for everything. That's a sure way to slow multi-threading down. There should be dedicated critical sections to protect specific things. That allows different threads to hold different critical sections while accessing different resources, without negatively affecting each other. Of course the whole design must be perfectly thread safe. But it is very important to also write the code in a way that doesn't slow multi-threading down to a crawl...

[LigH]

(torrented) DVD/BR/HD rips

... are no topic here (see FR6 (http://forum.doom9.org/forum-rules.htm)). Make copies of your purchased movies, but keep them for yourself (and few friends at most).

[ajp2k11]

Just to make sure... check if you are having another instance of your same video player running in the background, it has happened to me more than once that i already was having two mpc running at the same time thinking i was able to close the first one correctly, then a blank screen appears when i accidentally open the second time the same player and left the first one running, i hope you can understand my lingo-english.

Thanks for the suggestion but this happens on a freshly booted computer as well.

[ajp2k11]

EVR has a totally different presentation logic, it doesn't depend on vsync scanline information.

Not sure why it only occurs with specific video files. Makes no sense to me, unless you're using DXVA decoding and/or DXVA deinterlacing? Try with software decoding and try with deinterlacing turned off. But really, I simply don't have enough information to do anything about this...

I use software decoding already but I will try and turn off deinterlacing everywhere, thanks.

I noticed today that if I just leave the player the file can begin to play after several minutes but it's very choppy. Dropped frames are in the thousands and the render/presentation queues don't fill up only the decoder queue.

[madshi]

@ajp2k11, there's no need to try to understand frame drops. The simple reality is that the very first and most important thing madVR needs is reliable information about the vsync scanline information from the GPU. If that already fails, as it seems to in your case, then all hope is lost to get smooth playback with madVR. So don't bother looking at anything other than the refresh rate. Only when that problem is fixed (by changing GPU drivers, GPU BIOS or maybe even GPU hardware), it makes sense to look at anything else.

[Schwartz]

With 0.86.2, seeking (through an x264 encoded file in an .AVI container) seems more choppy. The seek-bar takes longer to update its position. I'm assuming it's not LAV Filter's fault since I've used the same version for a while. This isn't a gamebreaker or anything, but it is less performant than 0.86.1 was.

Also, MadVR decoders are not used in my case.

[cyberbeing]

First, a head-up once again that the name of new subtitle interface filter is XySubFilter.

XySubFilter = New Subtitle Interface (XySubFilter.dll)
xy-VSFilter = Legacy Filter (VSFilter.dll)

If you could fix madVR's changelog in the next release, and always refer to it as XySubFilter when talking about the new subtitle interface filter in the future, I would be grateful. It's rather confusing when you refer to xy-VSFilter along with new subtitle interface stuff.

@cyberbeing
...

I'll pass this along, but I'm not sure what you are talking about. Are you saying that madVR will drop frames when it hasn't yet received a response from the subtitle render about the yuvMatix? That seems like a bad design in this particular scenario, considering madVR just flushed its subtitle queue which had a known yuvMatrix, and is requesting the exact same subtitle bitmaps for a new window resolution. You shouldn't be blocking GPU rendering until after all 128 entered the GPU queue and been color corrected and alpha blended with the already known yuvMatrix.

In any case, I don't think this is what's going on here. Our own logs indicate that updating yuvMatrix is the first thing XySubFilter does within a few milliseconds of madVR's request, and we render and send new bitmaps a few milliseconds after that. madVR's logs on the other hand, show that the render queue refuses to fill with constant dropped frames until the subtitle queue is 100% full, without any indication of why madVR is refusing to render them. But to put things into perspective, we are talking about ~20-40 subtitle bitmaps per frame here for ~3500+ total bitmaps for all 128 frames.

Though as you already know, neither madVR or XySubFilter has been fully optimized for things like this yet, so we don't need to discuss it here if you don't see an immediate solution.

But it is very important to also write the code in a way that doesn't slow multi-threading down to a crawl...
I would counter this that you shouldn't design madVR's consumer in a way that it behaves sub-optimally with a single-threaded subtitle provider.

[leeperry]

why still asking weird follow up questions? Do you still have problems or not? I would have to re-study what MPC-HC's internal renderers do
OK my bad, I was under the impression that your HLSL was as fluent as your english :p

Now that Graeme Gill is working on 3DLUT's for mVR, it's only a matter of time until I'll switch back to a LUT file anyway, as he seems to finally put the concept to the full extent of what's technically possible (http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms/100_100#post_23383629) :)

I'll run more tests and will report back. :thanks:

[karamancho]

Yes, definitely. But in order to have a real benefit, you need to make sure that for movie content you get the movies converted to proper 24fps/25fps first. If you use DXVA deinterlacing the output will be 30fps or 60fps, with baked in 3:2 pulldown judder. For interlaced movie content, forcing madVR into film mode is the only way to get smooth motion.

what about 24fps progressive content? does any of this apply?

[ryrynz]

Watched a few episodes tonight, everything played back beautifully. I like how you've nailed the overlay positioning, nice one. I've mentioned this next thing a few times and I know it's not 1.0 yet.. but
When progressing to the next file in the playlist there's that flash of a smaller window, it only happens on the second file to playback all subsequent files keep with a full black screen transition.
The window flash was smaller this time (maybe something to do with a code change) considering this window appearance doesn't occur when transitioning beyond the third file I can't help but feel it's likely a simple fix.

[madshi]

With 0.86.2, seeking (through an x264 encoded file in an .AVI container) seems more choppy. The seek-bar takes longer to update its position. I'm assuming it's not LAV Filter's fault since I've used the same version for a while. This isn't a gamebreaker or anything, but it is less performant than 0.86.1 was.
I don't know which code change could have resulted in this problem. Are you sure there's really a slowdown in v0.86.2 compared to v0.86.1? If so, please create a bug tracker entry and upload a small sample with which you can reproduce the problem. Thanks.

First, a head-up once again that the name of new subtitle interface filter is XySubFilter.

XySubFilter = New Subtitle Interface (XySubFilter.dll)
xy-VSFilter = Legacy Filter (VSFilter.dll)
I'll try to remember. The names are not too intuitive to me, though, since the basic rendering code in XySubFilter is still based on the original VSFilter rendering code, and "XySubFilter" is a very generic name, which doesn't specifically contain anything point to the "new" subtitle interface, either. So basically both names would in theory work for both solutions. Anyway, I've modified the changelog and I'll try to remember in future...

Are you saying that madVR will drop frames when it hasn't yet received a response from the subtitle render about the yuvMatix? That seems like a bad design in this particular scenario, considering madVR just flushed its subtitle queue which had a known yuvMatrix, and is requesting the exact same subtitle bitmaps for a new window resolution. You shouldn't be blocking GPU rendering until after all 128 entered the GPU queue and been color corrected and alpha blended with the already known yuvMatrix.
I'm not blocking *anything*. Part of the madVR rendering code is that I'm asking XySubFilter about the yuvMatrix used for the current subtitle frame. In theory it could be different for every frame. So I'm asking the yuvMatrix again for every rendered frame. That's a very simple "tell me your yuvMatrix, please" question which the madVR rendering thread asks XySubFilter. And this question seems to get stuck inside of the XySubFilter code for a very long time. So basically XySubFilter gets stuck, and this stalls the madVR rendering thread. There's nothing I can do about this because the rendering isn't stuck in my code, but in XySubFilter, it seems. There's no good reason (at all) for XySubFilter to get stuck when I ask it about yuvMatrix. So this is very very clearly a problem with XySubFilter. No offense, but if you say that this is a problem with madVR then you clearly don't know what you're talking about, from a software development point of view.

That said, I'm not 100% sure that this (meaning XySubFilter getting stuck when I ask it about yuvMatrix) is really what is happening. It is just my best guess, based on what I could see in your log.

In any case, I don't think this is what's going on here. Our own logs indicate that updating yuvMatrix is the first thing XySubFilter does within a few milliseconds of madVR's request, and we render and send new bitmaps a few milliseconds after that. madVR's logs on the other hand, show that the render queue refuses to fill with constant dropped frames until the subtitle queue is 100% full, without any indication of why madVR is refusing to render them.
Actually, there is an indication (but no proof) that madVR is not refusing anything, but that the render queue is getting stuck because XySubFilter gets stuck when madVR asks it about yuvMatrix.

Though as you already know, neither madVR or XySubFilter has been fully optimized for things like this yet, so we don't need to discuss it here if you don't see an immediate solution.
We don't need to discuss it, but if my guess is right, fixing this in XySubFilter should be rather easy.

I would counter this that you shouldn't design madVR's consumer in a way that it behaves sub-optimally with a single-threaded subtitle provider.
I have not designed it that way. It is of no consequence to me whether the subtitle provider is single threaded or multi-threaded. But I do expect the subtitle provider to not get stuck for a long time when I ask it a simple question for which the answer is already known.

what about 24fps progressive content? does any of this apply?
No.

I've mentioned this next thing a few times and I know it's not 1.0 yet.. but
When progressing to the next file in the playlist there's that flash of a smaller window, it only happens on the second file to playback all subsequent files keep with a full black screen transition.
The window flash was smaller this time (maybe something to do with a code change) considering this window appearance doesn't occur when transitioning beyond the third file I can't help but feel it's likely a simple fix.
From what I remember, something like this had been reported months ago and I had fixed it, and it was reported to be actually fixed. Not sure if what you're experiencing is a new problem, or if the fix doesn't work for you, or if the fix and unfixed itself at some point. Right now I'm not really feeling like looking into this, though.

[madshi]

P.S: @cyberbeing, I've double checked the rendering code. It's probably either ISubRenderProvider::GetString("yuvMatrix") or ISubRenderFrame::GetOutputRect() which stalls inside of XySubFilter.

[eXtremeDevil]

I'm trying to use madVR with BSPlayer with I can't get it to work, it never shows up the video... do I need to do anything special? It works fine with MPC-HC with no extra configuration...

[madshi]

That's a question you should probably ask the BSPlayer developer(s). Most people here use different media players, so there's not much experience here that could help you...

[callannn]

pens, it could be that the decoder queue doesn't fill up fast enough to not drop frames vs. having enough time if you watch the whole episode. I solved nearly all my buffering problems with LAV by just increasing the cpu queue to 64. I'm saying "problems with LAV" because on my test files I get no frame drops with haali, but I do with LAV. So it might be the same for you, I already notified nevcariel about it.

Yes I use Lav, not haali. Would you recommend I increase my CPU queue to a higher number than default? Same with the GPU queue?

The OSD screenshot only helps if it's directly from the situation when the frame drops occur. The additional info we need is for example which queues are (near) empty when those frame drops occur.

Here is a screenshot (http://i.imgur.com/ciP3zC9.png) taken the exact moment of a delayed frame. I don't get any dropped frames during playback at all (the dropped frames in this screenshot are from initally booting the video up). As you can see none of the queues seem to drop when this occurs, so i'm stumped.

[madshi]

Delayed frames can occur during windowed playback. Of course ideally they shouldn't, but they sometimes do. If you want to avoid this, try using fullscreen exclusive mode.

[callannn]

Delayed frames can occur during windowed playback. Of course ideally they shouldn't, but they sometimes do. If you want to avoid this, try using fullscreen exclusive mode.

Ah so it's not necessarily a problem with playback, my GPU or anything, just something that happens? Is there any way to get rid of them at all?

I posted a problem I seem to have with FEM not so long ago but it seemed to have been overlooked, in that when i switch to exclusive mode my average rendering time seems to go through the roof. From my understanding when in exclusive mode the video works directly from the GPU, so you should receive much better playback, so I have no idea why it seems worse when i switch to it. I have left all exclusive mode settings as default in the madVR settings, could this be why?

I apologise for all the questions as well!

[kopija]

Hi guys,
a pair of questions:
I am sending video to my 720p plasma and am wondering whether I should set its resolution to 50 or 60hz when using smooth motion FRC?
What are advantages of using "separate device for presentation" on Intel HD3000?ž
Thanks for replies, and godspeed our video emperor Madshi!

[leeperry]

I am sending video to my 720p plasma and am wondering whether I should set its resolution to 50 or 60hz when using smooth motion FRC?
madshi said that the higher the better as FRC simulates an infinite refresh rate. So if I were you I'd try to reach as high as you can get, some displays can reach up to 72Hz(and 120Hz if 3D capable) FWIW...even a bit over 60Hz wouldn't hurt :)

[n3w813]

First, a head-up once again that the name of new subtitle interface filter is XySubFilter.

XySubFilter = New Subtitle Interface (XySubFilter.dll)
xy-VSFilter = Legacy Filter (VSFilter.dll)


* fixed: #46: xy-vsfilter: 3DLUT was not applied to frames with subtitles

So does the above issue only affect XySubFilter.dll and NOT VSFilter.dll? (If I'm not updating to 0.86.2)

[raul31]

I'll give some answers to keep madshi free to keep up the good work. These have been covered many times in this thread and I don't think madshi needs to keep answering. :)

(hardware acceleration):
It sounds like you want "none" to me. This is what I use as well, all the other options use the GPU. The "hardware" doing the acceleration is on the GPU.

RGB Output Levels:
Untouched, leave converting color spaces to MadVR.

Dithering Mode:
Random unless you plan to re-encode the output. Random is visually higher quality but it does not encode as well.

You can turn on Yadif in LAV for software deinterlacing, I use video mode for real interlaced video (30i in my case).

All you need to do in LAV to keep the GPU free is to use "none" for hardware acceleration and don't use any shader scripts in MPC-HC.

thanks a lot asmodian!
though i would have loved to hear madshi's thoughts as well as i do see him replying to new users of madvr... no matter how simple the question. a bit disappointed.

i understand what u r saying regarding LAV filters. thank u.
btw, what is "shader scripts in MPC-HC?" & how do i avoid them?

now that u have explained to me how i can get the LAV filters powered by the CPU only, how do i get madVR working with the Nvidia Gpu exclusively?
because i mean like how do i know that madvr is instead being powered by the intel integrated graphics?

thanks a lot!

[mindbomb]

question about the second smooth motion option- "or if the display refresh rate is an exact multiple of the movie refresh rate"
what is the difference between this and the always on option?
cause doesn't the second option cover every possibility?

[kasper93]

So does the above issue only affect XySubFilter.dll and NOT VSFilter.dll? (If I'm not updating to 0.86.2)

VSFilter.dll draw subtitles onto video frame before it reaches madVR. madVR doesn't even know that subtitles were drown. And sure 3DLUT is applied to whole frame (with subs). With XySubFilter.dll it works quite differently, so yes only XySubFilter.dll was affected.

I was testing XySubFilter.dll and I really like it especially for PGS subtitles. http://screenshotcomparison.com/comparison/27166/ (#3 are HD subtitles that's why quality is similar, but we can see that ISR render at wrong levels it seems)

I have issue with blinking video frame when subtitle appear and DXVA deinterlacing is enabled. Reported it already on trac. I wonder why no one spots this bug before. :confused:

[Focalom]

I got a problem after updating these today:

-Ati drivers
-MPC-HC
-Lav filters
-madVR

I guess all of the versions were from 6 months to 12 months old.

The problem is that mpc-hc won't close properly, the process i still running, preventing running new video files. I tried to search, and some people points at madVR. When I use an another renderer (EVR custom pres), the problem dissappears. Any idea?

[Danat]

question about the second smooth motion option- "or if the display refresh rate is an exact multiple of the movie refresh rate"
what is the difference between this and the always on option?
cause doesn't the second option cover every possibility?
EDIT: my answer was wrong. sorry for confusion. madshi replied to your question here (http://forum.doom9.org/showthread.php?p=1631873#post1631873)

[kiccolsd]

I'm not sure I understand what you mean. Do you think that your playback chain somehow adds ringing artifacts to the movie which aren't in the original movie source? Can you show me a screenshot of the exact artifact you mean?

At first thx for your help and you madvr.
I tried to take a screenshot but if I stop the movie seem that artifacts disappear. It's something related to motion in the frames.

I'll try to explain, imagine a panning quite fast scene, around the edge\border of a character I can see artifacts, something that similar to ringing artifacts.

Another typical scene for this issue is a panning frame with a wire mesh, the border of the mesh shows artifacts.

By the way I'm a real noob (with HQ love) and maybe is not a madvr fault but if you have some tips i'll be thankfull!!!

[truexfan81]

I got a problem after updating these today:

-Ati drivers
-MPC-HC
-Lav filters
-madVR

I guess all of the versions were from 6 months to 12 months old.

The problem is that mpc-hc won't close properly, the process i still running, preventing running new video files. I tried to search, and some people points at madVR. When I use an another renderer (EVR custom pres), the problem dissappears. Any idea?

i used to have that issue it is a mpc-hc bug, it has been fixed in the nightlies

http://nightly.mpc-hc.org/

[cyberbeing]

So does the above issue only affect XySubFilter.dll and NOT VSFilter.dll? (If I'm not updating to 0.86.2)

Yes, this was a bug in prior version of madVR with XySubFilter.dll (not yet released). This is why I asked madshi to update the changelog, since these bugs which were fixed have nothing to do with xy-VSFilter (VSFilter.dll). It looks as though the changelog in the first post of the thread wasn't updated yet.

I wonder why no one spots this bug before. :confused:
We are aware of this issue with black boxes and/or flashing between lines with bitmap subtitles (PGS/DVB/VOBSUB). I can occasionally reproduce it with progressive content as well. At this point in time we believe this is caused by a performance issue in XySubFilter which results in sending a bogus bitmap to madVR, and something on our to-do list before we move on to user testing and a beta release. Only bugs which we believe were caused by madVR were added to madshi's bug tracker, all bugs we believe are caused by XySubFilter specifically we are tracking privately internally.

So I'm asking the yuvMatrix again for every rendered frame. That's a very simple "tell me your yuvMatrix, please" question which the madVR rendering thread asks XySubFilter. And this question seems to get stuck inside of the XySubFilter code for a very long time.
Maybe were missing a bit of logging around this area, since I not seeing anything that madVR is requesting yuvMatrix for every frame. All I see is that XySubFilter updates the yuvMatrix once immediately after the resolution rectangle change, and immediately after start sending new bitmaps and positions to madVR. I do agree that XySubFilter shouldn't be getting stuck on a yuvMatrix request if that's really what's occurring, I also believe that requesting yuvMatrix for every frame is a bit overkill especially if you wanted to mimic xy-VSFilter which at this point in time doesn't support changing yuvMatrix mid-stream at all, except video user override in the settings GUI. Maybe this should be changed so its the responsibility of the subtitle provider to inform the subtitle consumer of the yuvMatrix only when something may have changed. It seems possible considering our logging, that this is what XySubFilter is already doing, but I don't really know.


Actually, there is an indication (but no proof) that madVR is not refusing anything, but that the render queue is getting stuck because XySubFilter gets stuck when madVR asks it about yuvMatrix.
Could you clarify this once more.

Theoretically if a subtitle provider only updates yuvMatrix once at the beginning of the stream and ignores all further yuvMatrix requests from the subtitle consumer, but continues to respond to RequestFrame & GetBitmap requests nominally, what is the intended behavior by madVR? Assuming our logs are accurate, XySubFilter does not seem to be stuck internally, since immediately after the resolution change and updating yuvMatrix, we start responding to all RequestFrame & GetBitmap requests.

What requirements need to be met in madVR internally before it renders subtitles from the subtitle queue?


We don't need to discuss it, but if my guess is right, fixing this in XySubFilter should be rather easy.
P.S: @cyberbeing, I've double checked the rendering code. It's probably either ISubRenderProvider::GetString("yuvMatrix") or ISubRenderFrame::GetOutputRect() which stalls inside of XySubFilter.

Okay. After I confirm with the developer what's going on I'll email you. He has not yet tested madVR 0.86.2 with this behavior change yet, so there could be an oversight somewhere. Overall, GetOutputRect sounds a bit more likely as a cause of stalling rather than yuvMatrix.

[kasper93]

Only bugs which we believe were caused by madVR were added to madshi's bug tracker, all XySubFilter bugs we are tracking privately internally.

Oh, I see. So I should not post it on bug tracker. But I did it already (http://bugs.madshi.net/view.php?id=76) so if you like you can comment and clarify that this is NOT madVR bug so madshi can close the ticket.

By the way this public repo (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/xy_sub_filter2) is the most recent?

[cyberbeing]

By the way this public repo (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/xy_sub_filter2) is the most recent?

No, we've recently only been occasionally merging changes there. The most up-to-date development commits usually end up on one of the xy_sub_filter branches of my GitHub repository (https://github.com/Cyberbeing/xy-VSFilter/branches). Just be aware that at this point in time we give no guarantees that any given commit will actually build successfully or not contain a new critical bug. Our process usually goes, commit a bunch of experimental changes and/or bug-fixes, test, commit fixes via force push which wipes out and replaces a bunch of older commits. Before you build anything, you should always do a pull and hard reset to ensure you have the latest versions of commits.

Overall neither our XySubFilter or xy-VSFilter development branches, including the one on repo.or.cz, do we consider suitable for user testing, since at any given time they could be in an unstable state of flux. As a rule of thumb, we release new binaries on GoogleCode whenever our codebase is stable without any critical issues. If we haven't released anything, it doesn't mean we are holding back changes, but rather there is a critical bug, regression, or unfinished feature which we don't want to expose end-users to. This applies to both xy-VSFilter and XySubFilter, so just keep this in mind whenever testing unreleased code.

[Delerue]

I'm using XP x64 with MPC-HC x86 last build from xhmikosr + Haali splitter + madVR last build + 9600GT @301.42 driver and getting this:

http://img.photobucket.com/albums/v256/Delerue/Basketball60fps1080p10000kbpsmkv_snapshot_0003_20130605_204340_zpsdf49171a.jpg

Any idea?

[kasper93]

@cyberbeing: Thanks, I understand what you're saying :)

[Stephen R. Savage]

The changelog mentions a "matrix=2020" and "primaries=2020" tag -- how do you set these?

[leeperry]

^ in the file or folders name.

[Stephen R. Savage]

It seems the new release of madVR tries to be too helpful and treats videos larger than 1080p as Rec.2020, leading to some pretty hilarious blown-out colors. Given that the little 4K content that's out there (YouTube stuff) and any 4K content to be launched in the near future will be Rec.709, I think autodetection for 2020 should be removed or at least an option be given to disable it.

[chros]

Guys, which Windows version do you recommend for only mpc-hc + lav + madvr playback? W7 or W8 ?
Pros vs cons? :)

Thanks!

[madshi]

Ah so it's not necessarily a problem with playback, my GPU or anything, just something that happens? Is there any way to get rid of them at all?
They should not happen, but they sometimes do. There are a multitude of possible reasons. E.g. some other process or service eating GPU or CPU resources or something like that. FSE mode is the ultimate solution to problems like this.

I posted a problem I seem to have with FEM not so long ago but it seemed to have been overlooked, in that when i switch to exclusive mode my average rendering time seems to go through the roof.
Do you also get frame drops, or is it just the render times in the OSD which change? As long as you don't get frame drops, there's nothing to worry about. The rendering times may not always be reliable, depending on which flush settings you're using. E.g. if you've disabled all "flush & wait" options in windowed mode, your windowed mode rendering times are not representative.

I am sending video to my 720p plasma and am wondering whether I should set its resolution to 50 or 60hz when using smooth motion FRC?
Usually higher is better. Usually 60Hz is what most plasmas work best in. However, every display is different. So simply try both and use what looks better to your eyes.

What are advantages of using "separate device for presentation" on Intel HD3000?
It might make playback more reliable. Or maybe not. Just check if it helps in your case or not. For most people it's helpful, or at least not harmful. However, this option doesn't work for shared Intel + AMD/NVidia setups.

though i would have loved to hear madshi's thoughts as well as i do see him replying to new users of madvr... no matter how simple the question. a bit disappointed.
Asmodian replied well, so I didn't see a need to write the same reply in other words. But maybe I can expand a little:

there are other options as well which i haven't mentioned such as deinterlacing which can be configured within LAV video... what should i choose here for the rest of the options?
Deinterlacing inside of LAV might make sense if you plan to use this all for reencoding or stuff like that. As long as we're talking about straight and simple video playback with LAV -> madVR, the default LAV settings are usually the best.

That said, some people prefer yadif deinterlacing quality over DXVA deinterlacing quality (the latter of which is used by madVR at the moment). So for sports and music concerts you could try whether you like LAV's yadif implementation better, if you feel like playing around with the options...

how am i able to configure MPC-HC so that ALL the decoding & work that needs to be performed by the LAV filters etc is done completely by the I7 processor {CPU} & not touched at all by the nvidia card?
As Asmodian said, set LAV to "None" for hardware acceleration. Otherwise just use the LAV default configuration.

btw, what is "shader scripts in MPC-HC?" & how do i avoid them?
They are disabled by default.

question about the second smooth motion option- "or if the display refresh rate is an exact multiple of the movie refresh rate"
what is the difference between this and the always on option?
cause doesn't the second option cover every possibility?
If the movie framerate matches the display refresh rate exactly, the second option turns Smooth Motion FRC off, while "always on" turns it on.

I got a problem after updating these today:

-Ati drivers
-MPC-HC
-Lav filters
-madVR

I guess all of the versions were from 6 months to 12 months old.

The problem is that mpc-hc won't close properly, the process i still running, preventing running new video files. I tried to search, and some people points at madVR. When I use an another renderer (EVR custom pres), the problem dissappears. Any idea?
Try a different MPC-HC build, ideally a very new (nightly) one.

I tried to take a screenshot but if I stop the movie seem that artifacts disappear. It's something related to motion in the frames.

I'll try to explain, imagine a panning quite fast scene, around the edge\border of a character I can see artifacts, something that similar to ringing artifacts.

Another typical scene for this issue is a panning frame with a wire mesh, the border of the mesh shows artifacts.
Does the same problem occur if you use a different video renderer (e.g. VMR9 or EVR)?

Do you have madVR's smooth motion FRC on or off? (I'm not asking you to turn it on or off, just asking how you have configured it at the moment).

Maybe were missing a bit of logging around this area, since I not seeing anything that madVR is requesting yuvMatrix for every frame. All I see is that XySubFilter updates the yuvMatrix once immediately after the resolution rectangle change, and immediately after start sending new bitmaps and positions to madVR. I do agree that XySubFilter shouldn't be getting stuck on a yuvMatrix request if that's really what's occurring, I also believe that requesting yuvMatrix for every frame is a bit overkill especially if you wanted to mimic xy-VSFilter which at this point in time doesn't support changing yuvMatrix mid-stream at all, except video user override in the settings GUI. Maybe this should be changed so its the responsibility of the subtitle provider to inform the subtitle consumer of the yuvMatrix only when something may have changed. It seems possible considering our logging, that this is what XySubFilter is already doing, but I don't really know.
The interface doesn't really allow the provider to inform the subtitle consumer of a yuvMatrix change. It's the duty of both the provider and the consumer to ask the information fields of the other party regularly. Of course we could change the interface, but I don't see a real benefit in doing that.

The key reason why I'm asking the yuvMatrix for every frame is that the user might have switched subtitle tracks. Or maybe the user is playing linked MKV files. In both situations the yuvMatrix might suddenly change. Asking the yuvMatrix for every frame shouldn't harm, as long as XySubFilter replies without delay.

Could you clarify this once more.

Theoretically if a subtitle provider only updates yuvMatrix once at the beginning of the stream and ignores all further yuvMatrix requests from the subtitle consumer, but continues to respond to RequestFrame & GetBitmap requests nominally, what is the intended behavior by madVR? Assuming our logs are accurate, XySubFilter does not seem to be stuck internally, since immediately after the resolution change and updating yuvMatrix, we start responding to all RequestFrame & GetBitmap requests.
You need to see this from a thread specific point of view. The madVR subtitle thread is calling RequestFrame. Both the madVR uploading and rendering threads are calling GetBitmap. I can see from your log that XySubFilter continues to render subtitles quite happily while the madVR rendering thread is stuck. So obviously not the whole of XySubFilter is stuck.

There rarely is such a thing as one DirectShow filter (or one software component) being completely stuck. Things like that happen on a thread-by-thread basis. It seems that calls into XySubFilter made by madVR from the context of madVR's subtitle thread work fine without stalling. However, the calls into XySubFilter made by madVR from the context of madVR's rendering thread seem to be stuck inside of XySubFilter. This is a very typical behaviour when something goes wrong with thread protection (inside of XySubFilter).

(Again, I'm not 100% sure, this is just my best guess based on what I'm seeing in the log.)

What requirements need to be met in madVR internally before it renders subtitles from the subtitle queue?
The thing is, madVR's rendering thread is already *trying* to render the subtitles. That's why it's asking XySubFilter for the yuvMatrix. In programming if a thread calls an API or a function, and if that API or function simply doesn't return, there's absolutely *nothing* you can do about it. I think (but I'm not 100% sure) that madVR asks XySubFilter for information and that XySubFilter takes a loooong time to answer. Due to the way threading works, this automatically means XySubFilter is stalling the whole madVR rendering thread (if that is what is happening).

Overall, GetOutputRect sounds a bit more likely as a cause of stalling rather than yuvMatrix.
Yes, it could be GetOutputRect, too. I can see in the log that the madVR rendering thread does nothing for a long time, then the first log line after that pause is the yuvMatrix madVR got from XySubFilter. That's why I first thought it might be the reading of the yuvMatrix which took so long. But right before reading the yuvMatrix I'm also asking XySubFilter for GetOutputRect, so it could also be that which is stalling. In theory it could also be something completely XySubFilter unrelated. But since the problem only occurs in connection with XySubFilter I think it's likely that my guess is right.

I'm using XP x64 with MPC-HC x86 last build from xhmikosr + Haali splitter + madVR last build + 9600GT @301.42 driver and getting this:

Any idea?
Looks like a decoder problem. Which decoder are you using? Try a different one (e.g. LAV Video Decoder).

It seems the new release of madVR tries to be too helpful and treats videos larger than 1080p as Rec.2020, leading to some pretty hilarious blown-out colors. Given that the little 4K content that's out there (YouTube stuff) and any 4K content to be launched in the near future will be Rec.709, I think autodetection for 2020 should be removed or at least an option be given to disable it.
You might have a point, considering what 4K content is out there today. However, I think in 5 years 99.9% of all 4K user content is likely to be BT.2020, so at some point in the future madVR should auto select BT.2020 for 4K content. But maybe it's too early for that right now.

Guys, which Windows version do you recommend for only mpc-hc + lav + madvr playback? W7 or W8 ?
Pros vs cons? :)
Win8 has a bug with setting correct refresh rates, but I've found a workaround in the latest madVR version. As a result I personally see no big difference between win7 and win8 for video playback, anymore. Just pick which you like better for other reasons...

[rahzel]

I can't handle bug reports that are spread across bug tracker and forum thread. If you want your feedback to be helpful, you have to add it to the bug tracker report you mentioned.
Hi madshi,

I finally reported this to the bug tracker (http://bugs.madshi.net/view.php?id=77). I see you've attempted to fix Ryrynz and I's issue but could not re-produce it on your Windows 8 machine. Well as I report in my bug report, it's possibly a windows 7 + HD 4000 + 9.18.10.3071 (or later) issue. I have an HD 4000 on my laptop running windows 8 and it's fine using the same driver. My desktop running Win7 64-bit SP1, however, is not. I even tried the newer driver package (15.​31.​9.​64.​3165) and I have the same issue. Still have to revert back to 9.17.10.2932.

edit: I see it's a driver bug. I saw you and Ryrynz talking about it, but I thought you were talking about something else.

[Delerue]

Looks like a decoder problem. Which decoder are you using? Try a different one (e.g. LAV Video Decoder).

I've tried with MPC-HC internal decoders, FFDShow and madVR internal decoder. Also, I've tried a lot of other videos encoded with different codecs. The same result. :( On the other hand, if I change the render to, let's say VMR 7 or 9, everything went back to normal.

LAV decoders are virtually the same used by FFDShow, right?

[madshi]

I've tried with MPC-HC internal decoders, FFDShow and madVR internal decoder. Also, I've tried a lot of other videos encoded with different codecs. The same result. :( On the other hand, if I change the render to, let's say VMR 7 or 9, everything went back to normal.
Ok, that's weird. Can you please report this to the madVR bug tracker ( http://madVR.bugs.madshi.net ) and attach a small sample to the bug entry, so that I can reproduce the problem on my PC? Thanks.

[Delerue]

Ok, that's weird. Can you please report this to the madVR bug tracker ( http://madVR.bugs.madshi.net ) and attach a small sample to the bug entry, so that I can reproduce the problem on my PC? Thanks.

Great. It's here: http://bugs.madshi.net/view.php?id=78

Thanks, man. :)

[zero9999]

i'm not entirely sure if XySubFilter or MadVR is at fault here, but subtitles seem to be rendered in full/PC range.

http://www.check2pic.ru/compare/29611/

ASS script is tagged as TV.601.

Tested on:
madVR 0.86.2
XySubFilter .425

[madshi]

i'm not entirely sure if XySubFilter or MadVR is at fault here, but subtitles seem to be rendered in full/PC range.

http://www.check2pic.ru/compare/29611/

ASS script is tagged as TV.601.

Tested on:
madVR 0.86.2
XySubFilter .425
Hmmmm... This might be a bug in madVR which happens when XySubFilter is doing the color correction. @cyberbeing, this might also explain why the colors are wrong when XySubFilter is doing the color correction internally.

@zero9999, can you please create an issue in the madVR bug tracker and upload a small video sample? Thanks...

[zero9999]

@zero9999, can you please create an issue in the madVR bug tracker and upload a small video sample? Thanks...

Bug and samples submitted (http://bugs.madshi.net/view.php?id=79). Should i also create a feature request for rendering subtitles on screenshots taken with madvr or is that part just not done, yet?