vertical sync

“Device” – isn’t that a funny word? I’m not a native English speaker so I don’t know but I get the feeling that engineers are sometimes running out of imagination and sometimes they (or I should really say “we” as I’m as guilty as the next guy) associate along very convoluted paths. Anyway…

The graphics “device” is a piece of software that represents the graphics output unit of the PC. It is in effect a COM object that obeys all the intricate and very mathematical rules of COM programming. It’s today used for pretty much everything you write or draw on the display. In MPC-HC the graphics device sometimes needs to be “reset”, meaning that memory needs to be reallocated due to a new video pixel format or some other reason.

If a COM object like the graphics device is created on one thread and naively destroyed or reset (reallocation of memory) on another, a dangling pointer to the object may remain on the thread of creation. This may cause all kinds of strange behavior. The safest thing (and the recommended thing according to Microsoft docs [1][2]) is therefore to create, reset and destroy the graphics device object on one and the same thread. This is not done in MPC-HC today and my plan is to fix that.

Another funny thing is that the exclusive mode full-screen will keep rendering through ALT+TAB and clicking on other windows, unlike other exclusive mode full-screen applications. The thing with exclusive mode is exactly that an application in this mode is supposed to have exclusive access to the driver without passing through any window manager and without sharing the device with any other application that may bother it. I may need to edit this post later if I find that this is a feature, not a bug. But that will be then.

My plan is to make it possible to toggle between windowed mode and exclusive mode (aka D3D) full-screen while streaming. This worked in my old player so at least it is feasible. But as always, time is scarce so don’t start holding your breath just yet.

Links

[1] IDirect3DDevice9::Reset

[2] Creating a Device (Direct3D 9)

I have just joined as a beta-tester of Voddler, the “Spotify for movies”. It is currently beta-tested in Sweden (only). Unfortunately I don’t have any good news to report yet as I can not get the client up and running at all. It seems to be very sensitive to router settings, firewalls etc. Even disabling every millimeter of protection, and enabling UPNP in the router as per the user guide, I can’t get it to pass the initial test. I’m not alone having these problems it seems.

I do like the idea that the client is built on open source but of course I’m missing a Linux client. The client is still a bit clunky. You can’t use the mouse for instance. That is not a big deal for an HTPC that you control with a remote. It is a bit inconvenient on the desktop though.

I’m sure they (or I) will figure it out eventually. The concept is totally right. I’m a happy subscriber to Spotify Premium and wouldn’t hesitate to shell out a similar amount to get access to a stable stream of good movies.

Unfortunately my small switch broke so there is no easy way currently for me to connect to the Internet directly, without a router. And I will still want to use the program through a router in the end as I want all my computers on the same network. But before that I guess I need a new switch for some unprotected troubleshooting. I did sign up as a beta-tester after all.

Links

[1] www.voddler.com

Time to write some code.

Christmas is a blessing in many ways, not the least because I chose to take four days of vacation to catch up with some hobby projects and some horse riding after a hectic fall work-wise. As seen from an earlier post I built a new HTPC and also took time to do some changes in the GothSync code. I was perhaps procrastinating a bit since I was afraid that I had been struck by amnesia and that I would have to learn everything all over again. I haven’t looked much into the code since my summer vacation. Starting from scratch would have been a little bit like going to the gym after half a year of sedentary life: it would have hurt! Luckily some synapses remained intact and it wasn’t too hard to catch up and do what I had planned to do a long time.

I added the Sync Renderer (I will probably drop the “Goth” part for brevity and because it seems to give associations to the kind of music that my teenage son is listening to) as an optional renderer to the regular build of MPC-HC. This means that all the other renderers are intact. When I started experimenting I took a shortcut and hacked away on two of the existing renderers, effectively destroying the original renderers. They are now restored.

The Sync Renderer is now added as the last option in the increasingly long list of available renderers. Once it is selected, further synchronization options can be selected from the Synchronization options page. For more documentation, see the Get started page (may be slightly out of date when I write this).

The new version has been committed into the trunk (main development branch) of MPC-HC at SourceForge. Executables are available through the Download page.

Please give any feedback either as a comment here or on this thread at Doom9’s. Report bugs on the SourceForge bug tracker. (A comment on Doom9’s thread would be useful even if you submit a formal bug report. I haven’t got used to visiting the bug tracker regularly yet since I just recently added my code to MPC-HC trunk.)

I guess I was barking up the wrong tree in the previous post. I’ve learnt that S1 sleep is indeed supposed to leave the CPU and the fans on. I was most likely using S3 on my previous HTPC, not S1 as I initially thought. I thought it must have been S1 since S3 takes so long to resume from on the new HTPC. But the error is not always where you are looking.

As i mentioned i also have a problem with the power supply. The symptom is that it takes several attempts to start the computer. But on one lucky occasion it started on the first attempt. At that particular occasion it only took a few seconds to get back to the login screen from S3 (as opposed to over a minute in most cases). So potentially it wakes up as fast as my old HTPC, just not everytime.

My hypothesis is thus as follows: The failed start attempts corrupt the state in the memory which makes the computer revert to the state stored on HD (I think one of the features of S3 is that it stores the state both on the HD and in the memory). Resuming from HD is more time consuming than resuming from memory obviously.

So what initially looked like two different problems was probably only one. Still waiting for that new PSU…

It’s Christmas day. The family dinner was on Christmas Eve so it has been a very peaceful day with time to put together the stack of stuff depicted in this post. I purchased a copy of Windows 7 Home Edition to the stack for a complete new HTPC. Here are a few snapshots of the assembly:

Life is like an empty box…	Who comes up with these ridiculous names? “Memory lover!”. That doesn’t sound like a motherboard for real men. Well, the specs looked right.
It’s so fun to put things together so I often do it twice. Having fastened the motherboard with all 9 screws I realized that the fan backplate needed to go under the board (”backplate” should have rung a bell). I decided to install the fan with the motherboard out of the cabinet. It was easy enough.	The fan fit into the cabinet with a 5 mm margin. I will not install any cabinet fans to start with. Hopefully the CPU fan will keep the air moving fast enough. I’m a bit worried about the GPU as the GPU heat sink and the CPU fan are on opposite sides of the graphics PCB. I need to keep an eye on the GPU temp for a while.
Most of the stuff fit in. I didn’t want to install the digital TV tuner as its slot was next to the slot of the graphics board and it would have covered the GPU heat sink. There are a lot of empty slots further away but of the wrong kind. This I think is an example of poor design as many high-end graphics boards actually require two slots, whether for a big fan or for a heat sink.	My home burnt Windows DVD seems to work (I always use the Linux application Brasero to burn my DVDs including ISO images).
I agree, I guess…	The SilverStone cabinet gives good value and looks for the money. The Blu-ray/DVD drive lid doesn’t work perfectly but maybe it just needs to be broke in a bit.

There were some glitches:

• You still can’t buy stuff from Microsoft through a Swedish site. Clicking “Köp nu” (Buy now) on the Swedish Microsoft site takes you to the US site where you are required to enter a state (but no country) in your address. After some confusion I found the UK on-line store where I was finally able to purchase a copy of the home edition of Windows 7. I’ll spare you the obvious comparison with the ease of getting Linux.
• There was no way of telling from the mother board documentation which way to connect + and – from the power led and the HD led. I got the HD led right – and the power led wrong.
• The default sleep mode (S1) leaves the CPU fan on (and maybe some other things as well). What kind of sleep is that? I’ve seen this behavior on some older computers I’ve had too, but not with boards from ASUS. The next motherboard will probably be an ASUS again. Or else I should avoid Corsair power supplies.
• The power-on button often requires multiple pushes for the computer to wake up. The board gets powered up for a fraction of a second at the failed attempts but then dies again. I will try to find out if there is a pattern.
• The lid over the optical drive doesn’t open as it should. It gets slightly stuck in a semi-closed position. This seems to be a result of a bad fit.

Having upgraded my ATI driver the MPC-HC Gothsync got its monitors mixed up. Powerstrip started to report the refresh rate of the monitor on which the MPC-HC window was not playing. This in turn messed up the sync algorithms.

After some troubleshooting I realized that my primary monitor was changed of some reason. Either as a result of the upgrade or (more probable) caused by the guy behind the keyboard. For the monitor detection code to work, the primary monitor needs to be the monitor with the lowest number in the Windows display properties dialog (see the image to the right). You can still have your Windows toolbar on the other (secondary) monitor and consider it the primary monitor for all practical purposes.

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.

When working on the new algorithm I detected a couple of bugs that I realized also affected the older algorithm. Having merged back the fixes to the old version it worked much better. I have been testing it for a while and haven’t so far found any big issues. Only on XP and only on two different hardwares so stuff might still turn up. The latest version (9016) can be downloaded from the download page