Reply to thread

Message

<blockquote data-quote="madshi" data-source="post: 778603" data-attributes="member: 114920">It can be up to 39.9ms. Theoretically playback can be fluid as long as the render time is lower than the movie frame rate. Well, unless the GPU driver drops the ball, of course, as it happens on my 9400 HTPC. The render time depends very much on the movie and display resolution and on which scaling algorithm you're using. 4-tap Lanzcos is of course much slower than 2-tap Bicubic.Yes, it must be some kind of locking problem, I guess. NVidia users are telling me that it didn't occur with very old drivers, so it seems to be a relatively new problem.I've added all sorts of &quot;tweaking options&quot; to madVR. One of them makes sure that rendering is only performed in a specific vsync scanline range. These tweaks do help reducing the problem. However, limiting the time during which rendering can be performed of course also lowers the rendering performance. And this tweak isn't 100% reliable, either. What seems to work best is to create two separate D3D devices, one for rendering and one for presentation. In Vista/Win7 D3D resources can be shared between different D3D devices. This way it seems I can work around most of the locking problem. It's not still 100% perfect, though. Some users have to combine several tweak options to get perfectly smooth playback.</blockquote>

[QUOTE="madshi, post: 778603, member: 114920"] It can be up to 39.9ms. Theoretically playback can be fluid as long as the render time is lower than the movie frame rate. Well, unless the GPU driver drops the ball, of course, as it happens on my 9400 HTPC. The render time depends very much on the movie and display resolution and on which scaling algorithm you're using. 4-tap Lanzcos is of course much slower than 2-tap Bicubic. Yes, it must be some kind of locking problem, I guess. NVidia users are telling me that it didn't occur with very old drivers, so it seems to be a relatively new problem. I've added all sorts of "tweaking options" to madVR. One of them makes sure that rendering is only performed in a specific vsync scanline range. These tweaks do help reducing the problem. However, limiting the time during which rendering can be performed of course also lowers the rendering performance. And this tweak isn't 100% reliable, either. What seems to work best is to create two separate D3D devices, one for rendering and one for presentation. In Vista/Win7 D3D resources can be shared between different D3D devices. This way it seems I can work around most of the locking problem. It's not still 100% perfect, though. Some users have to combine several tweak options to get perfectly smooth playback. [/QUOTE]

Verification