vertical sync

I cleaned up the GothPlayer code and built both a 32-bit and a 64-bit version (they can be downloaded through the GothPlayer download page). If nothing else, it’s a nice test rig for filters and renderers. And TV looks much better with GothPlayer than with the TerraTec media player that came with the TV card (there you have some serious judder).

I’m slowly reading up on, and testing Windows 7 and Media Foundation. It seems that GothPlayer doesn’t behave at all the same on Windows 7 as on Windows XP. The merit system from XP doesn’t work and even if I manually add ffdshow decoders to the graph before rendering a media file, they don’t end up in the running graph. To add insult to injury, neither my debug console code nor graphedt seem to work under Windows 7. The console doesn’t turn up at all and graphedt doesn’t find the graph from the running GothPlayer. It’s like somebody would have anticipated all my moves to understand what’s happening and made sure none of them would work. Another Microsoft trick to force me to an upgrade that ultimately will add very little to my movie watching experience I’m afraid. And Spotify has stopped working on Ubuntu after a recent “upgrade” so that’s not an option either.

I have still not decided which way to go with further development. It’s fun to code but I need a goal too. The question is what the “unique selling point” of yet another player would be. MPC-HC has a lot of nice features but some of the code is just too time consuming to understand and debug (for me at least, not being a professional programmer). I think I should probably spend some more time evaluating the “competition” first.

A messy update.

It’s been a four-day Easter weekend in Sweden. There’s been time to go running, riding, to clean the house and to play around with some new stuff. I decided to give Voddler a second chance after the epic failure to even connect to their server when I first tried it (see Voddler woes). Also, a friend hinted about XBMC, a media center software that was the basis of the early Voddler clients (they have recently migrated to Adobe Air for their video streaming instead) so I thought I should give that piece of software a spin as well. Said and done.

The Voddler web site strongly recommended an update of the graphics drivers. I was a bit hesitant since the last update resulted in total blackness that was only repaired after I replaced the graphics board (see this post).

This time I was a bit more lucky but the upgrade wasn’t entirely uneventful. My resolutions, display order and desktop configuration were all messed up after the upgrade (see screen-shot). It seems that it would take just about the same effort to keep the settings as to change them but I may be wrong.

Back to Voddler and XBMC. I will write more about both later but initially I was quite impressed with XBMC. It has a very slick user interface that on my XP starts in exclusive mode full-screen meaning that tearing is not a problem. It seems to play formats such as VC-1 and AVCHD with its built in decoders. And it ran equally well on Windows XP as on Linux (Ubuntu 8.04) which is very impressive. Looking under the hood I even found a sync algorithm that is equivalent to Sync video to display in MPC-HC, with or without resampling of the sound. (I will probably hang on to the GothSync code just a little while more though. Synchronizing the display to the video is after all the optimal kind of sync – whenever the hardware supports it.)

This time Voddler actually connected to the server immediately. Maybe they have changed the protocol or something. After my last attempt there were hundreds of frustrated users like me on the Voddler forum not being able to get through. I was even able to play a movie with decent resolution and without glitches. In windowed mode that is. As soon as I set it to full-screen it started to judder in a very unpleasant way. I couldn’t find any settings that might affect it. I will run some tests on the Windows 7 machine later to see if the same issue is present there too. Unfortunately tomorrow is a work day so the play will have to wait a while.

I need a break from MPC-HC. If you’ve read some of my earlier posts you probably understand why. The full-screen toggling code kind of works but there are a couple of open DXVA-related bugs that I just can’t find. I suspect that there is something that I don’t understand about the DXVA2 support code and the DXVA decoder. The decoder grabs a whole bunch of interfaces to the DirectX device that I don’t know how to release. Having looked at the same part of the code for so many hours, a break is the only way to get a pair of fresh eyes and a somewhat fresher brain.

So I decided to see if I could still compile my old GothPlayer. Lo and behold: I set the correct references to the base classes, migrated to Visual Studio 2008 and it all worked again. I even found a bug in the full-screen toggling code that has probably been there for ages. The new version (including source code) is available through the GothPlayer download page.

I also recently learned that the tearing problem is really solved by Aero in Windows 7. Since there is a fair chance that people will soon enough migrate to Windows 7 from XP on their HTPCs (I did already), I don’t really see the point in putting too much effort into getting EVR to work on XP. The VMR9-based SyncVMR9 renderer that I use in GothPlayer works well enough for me and provides DXVA1 on XP.

SyncVMR9 is a stand-alone DirectShow filter with many of the VMR9 interfaces exposed and with one special interface, ISyncVMR9, for controlling the renderer. I’ll try to clean up the interface to a bare minimum and then see if it is possible to do the same trick (COM aggregation) with EVR for Windows 7. That way the synchonizing renderers could be used in any player that agrees to manage the renderer according to the protocol that comes with the custom interface.

There is a test version of MPC-HC available through the download page.

This test version is only intended to work under the following circumstances:

• EVR Sync
• Reinitialize when changing display: Checked
• Use worker thread to construct the filter graph: Unchecked

It has the following features and peculiarities:

• You can toggle between windowed mode and exclusive mode (D3D) full-screen without restart.
• Does not work with DXVA.
• If something other than Current is selected as full-screen display, then the DirectX device is created for that display meaning that there may be sync issues (judder) in windowed mode.
• Multi-screen on W7 doesn’t work 100%. I suspect driver issues though. I get random pixels coming on and off like noise with certain resolutions.

There is probably a ton of other problems that I would love to have feedback on. I’m not entirely sure if this is the right approach for full-screen toggling. I still haven’t been able to hunt down the last references that hold the DirectX device. Even if things seem to work on my XP machine, I’m not satisfied with having outstanding references.

This is one of the most time-consuming debugging sessions I’ve been doing so far. Partly because I have not written all the code myself and there are few or no comments and partly because COM reference counting is hard, period. Enough whining.

Microsoft humor.

I have tracked down my problem to the IDirect3DDeviceManager9::ResetDevice method. When calling it with a new DirectX device as a parameter, it decrements the reference count of the old DirectX device by one and increments the reference count of the new one by four! The balance of the references to the old device are later released on one of 21 (!) active threads when renegotiating formats or something like that. The unreleased “zombie device” causes problems when exiting exclusive mode full-screen since it still has exclusive access to the full-screen. When the new device tries to present something it causes a lost device. This baffled me quite a bit in the beginning because it looked like I got a lost windowed device but I’m pretty certain that it was the old full-screen device that was lost before it was properly released (I don’t even know if one can lose a windowed device).

Ideally I need to find where the last few references are released and see to it that that piece of code is called from the thread on which the device was once created. The hunt goes on…

I got my image back with an old 6600GT card. Noisy but works fine. That’s the good thing.

The bad thing is that the behavior of my app can not be explained by a driver bug. It is perfectly repeatable with an NVidia card. It appears both in debug builds and in release builds which means that it is probably not just a spurious memory allocation problem or something like that. I have to get used to the thought that it might be a real programmer mistake, as tough as that is.

Just to keep the perspective, I have to remind myself that everything I write about are problems of the industrialized world and therefore – really – not problems at all. But I think it is fair to say that I’ve never had a problem-free upgrade of an ATI driver – ever.

I decided to upgrade the driver on my development machine. The bug I’m chasing might, I say just might, be a driver bug. It appears when going from exclusive mode full-screen to windowed mode, but only the first time, and only when using the second monitor. Everything works fine the second time I toggle between exclusive mode full-screen and windowed mode on the second monitor and it always works on the primary monitor.

Anyway, after upgrade, the computer went totally black. I have a spare NVidia board in the closet and I think this might just be a good time to bring it out and give it a spin. All my NVidia upgrades have been painless as far as I can remember.

When I first started working on the Sync Renderer solution a few years back (at that time in my own player) I pretty much started from scratch in every respect. I had not written a professional line of code in maybe 17 years. And i had no knowledge at all about the Windows environment or DirectShow or DirectX. I struggled for many weeks with some (afterwards) pretty obvious things.

I’m feeling a bit of a deja-vu all over again (as Yogi Berra is said to have said – if you can’t find anybody else to attribute a quote to, you can always suggest Mr Berra). I would very much like to simplify things but I have for instance realized that a child window in MFC can not be a top-most window and can therefore not be used for exclusive mode full-screen. Took me a few ours to realize that. So there was a need for that other specific and seemingly superfluous full-screen window after all.

Bloated frameworks like MFC are maybe good for experienced programmers but they mostly add complexity for the weekend programmer. In this case for instance one has to find a way to code around the built-in behavior of MFC. So it goes.

I’m from time to time on the verge of scrapping my whole MPC-HC effort in favor of my own MFC-free and about 100 times simpler player. But then I hear this inner voice which urges me to give it just another try. The same voice that I kept hearing a few years back. So I’ll give it one more weekend. And then we will see…

The toggling between windowed and exclusive mode full-screen turned out to be more time-consuming than I thought from the beginning. There is now some code on my ftp site. It took me a while to realize that one can not (I believe) reset a DirectX device and change monitor at the same time when switching to exclusive mode full-screen. Windowed mode works fine. I have not seen this documented anywhere but it’s a strong hypothesis backed up with some empirical work (= frustrating debugging). The other road-block was the fact that the MPC-HC built in DXVA decoder doesn’t seem to react well to device resets. If you check the Reinitialize when changing display option and move the window from one screen to the next while playing e.g. something coded in VC-1, then the video window turns black on the new screen (with EVR Sync and EVR Custom at least).

The D3D Fullscreen option now means that when exclusive mode full-screen will be used when toggling into full-screen. The player will not start in full-screen though unless you tick Launch files in fullscreen on the Fullscreen Options page.

The code on the ftp site is not finished. It needs the following amendments:

• Recovery from lost device. Now it seems that the exclusive mode full-screen window behaves as it should, i.e. you lose the device if the window loses key-board focus. Now, if you lose focus, it’s lost forever (or you might get some sort of zombie full-screen window that isn’t to be trusted.
• DXVA support is not stable. The toggling works fine for ffdshow and the internal filters when not in DXVA mode.
• It only works with EVR Sync right now.
• It requires that the option Use worker thread to construct the filter graph is unchecked.

There are probably other bugs but it’s a start.

I have finally managed to toggle between windowed and full-screen mode in MPC-HC using Sync Renderer! This may not sound like news at all but it’s not just any old full-screen, it is exclusive mode full-screen. Once fully implemented and debugged this should make it much more convenient to use exclusive mode (aka D3D mode) full-screen in MPC-HC.

In my experience, the exclusive mode full-screen GUI support destroys the tear-free nature of the exclusive mode full-screen. This means that it is hard to manage for instance subtitles in exclusive mode. The possibility to toggle between windowed and exclusive mode full-screen means that you can use the full GUI in windowed mode for your settings before going into tear-free full-screen. The best of two worlds!

There is still plenty of coding left before this can be released as I need to combine the new behavior for the Sync Renderer with the old behaviors of the other custom renderers (I don’t dare to touch them yet). An initial test is shown in the picture below. I’m using a sync offset of about 4 ms together with bicubic interpolation and a shader (gray-scale) without any tearing.

A gray full-screen without tearing.