[madshi]

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

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.

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

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

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by cyberbeing

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.

Originally Posted by karamancho

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

No.

Originally Posted by ryrynz

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.