vertical sync

Since my last merge with the trunk, the GothSync branch won’t link any more. This is one of those annoying hiccups that usually takes a couple of hours (and some serendipitous luck) to resolve. I have decided that it’s too much of a hassle to keep an increasingly diverging branch updated with what happens on the trunk and have therefore decided to instead add my renderer to the trunk as an additional renderer instead of trying to replace the existing ones. That way there will unfortunately be one more bewildering option under the Output options tab but people for whom the existing renderers work well can continue to use them.

This will take some restructuring of the code and therefore some time. See you on the other side of the re-factoring! Hopefully…

In my opinion the two main curses of HTPCs are tearing and judder (T&J). Any rational person would probably choose a €80 DVD player from the nearest discount store instead of an HTPC that can easily be ten times as expensive and ten times as fickle. But then again, some people actually prefer a fickle Jaguar before a reliable Volkswagen. When it comes to watching digital movies, I’m one of those.

My additions to the MPC-HC are intended to address the T&J problem as described elsewhere on this blog. MPC-HC has a lot of bells and whistles and some let you trade one feature for another. If you for instance use a lot of GPU cycles on executing pixel shader code to execute fancy filters, you will most likely get T&J or at least T, as there may not be enough time to execute all the rendering and shader code between two frames.

Even disabling pixel shaders, there is still some time-consuming code to be executed if you wish; there are a bunch of different resizers. Resizers perform filtering when enlarging a frame to avoid blockiness. I ran some experiments with different types of resizers with my graphics board to decide how much sync offset that was required to avoid tearing with each resizer. Sync offset basically decides how much time you have to execute the resizer code. This is what I found out:

The Present at nearest vsync sync option was used in MPC-HC Gothsync patch 9018. No other shaders were activated. Non-exclusive mode full-screen was used to resize from 720 x 416 to 1280 x 720. The graphics board used was an ATI 3450 with ATI Catalyst 9.9 driver for XP.

Displaying the full on-screen statistics display requires an additional 2 ms or so of sync offset (drawing time).

These numbers will most likely vary between boards but do clearly indicate that there is a trade-off between tearing and resizer complexity. I think a bilinear resizer is a good compromise between speed and image quality but then again, a display refresh cycle of 20 ms (50 Hz) is long enough to execute even the most time consuming resizer (15 ms).

I’m quite happy with my development environment. A 1920 by 1200 Samsung display for a good view into Visual Studio 2008 and a Philips HDTV as a second display. The TV synchronizes to anything from 47 something Hz to 60 Hz and much there in between. It is for instance easy to test a small mismatch in rate by setting the refresh rate to 49.95 Hz and play 25/50 fps material.

I have now merged all the new stuff from the trunk (main line of MPC-HC development) into my branch. Also, I believe a lot of my own bugs are fixed. Frame-stepping seems to work and I haven’t had any hangings lately.

I still need to do more testing with respect to stability and I hope you guys out there can continue helping out (thanks!). All those threads and timings in the code are tricky. Some people actually say that the DirectShow library is Microsoft’s most difficult library to master. Maybe, maybe not. At least it’s not entirely straight-forward. Having said that, I still think it’s a very elegant library.

As I said earlier, I stripped the existing renderers of all sync code when starting to implement mine. Now I’m considering putting some of it back again, like the GPU flushes that seem to solve some problems for some people. Then again, I don’t think MPC-HC should provide a fix for every driver bug that’s out there. Instead I believe we should learn to avoid hardware that doesn’t stay clear of tearing and other artifacts. Evidently there are some good hardware and good drivers out there too. I for instance seem to have been lucky with all my various NVidia and ATI/AMD boards. My empathy for some of you guys would perhaps have been better, had I been less lucky, but so it goes.

Download the new version from the download page.