vertical sync

Yet another patch to download here. The thread for commenting and reporting bugs remains here (Doom9′s forum).

The patch includes an update to revision 1192 of MPC-HC base and a couple of fixes that you can read about in the change log.

There is a new version of the MPC-HC GothSync tryouts player to download and test here. The thread for commenting and reporting bugs remains here (Doom9′s forum).

The new version has been cleaned up a bit as compared to the last version and the on-screen statistics display has been improved. There is also more yada-yada about how the sync works and how to do troubleshooting on the GothSync pages.

Any feedback is welcome as always.

It turns out that the audio renderer rate matching (to en external reference clock), on which one of the synchronization mathods of GothSync relies, only seems to work when the computer does the D/A conversion and works its magic on the sound card. At least one of my audio renderers does not touch the rate of any SPDIF output even though it synchronizes well when not using SPDIF output; this even though it, when queried, announces that it matches rate.

Time to dust them off.

This means that if you wish perfect video sync with the sync algorithm that relies on fine-tuning the internal clock speed of the filter graph, then you need to output analog audio from your sound card (or use e.g. Dolby Live to convert the audio back to digital). The last method may not be an alternative for the audio purists but decoders like AC3 Filter are pretty good imho if you wish to do the D/A conversion on the sound card instead of the receiver. The internal audio decoder in MPC-HC does a good job too. The only drawback is the nuisance of 3 or 4 audio cables instead of just one coaxial or optical cable between the computer and the receiver.

On my development computer, where I’ve used analog audio output all along (software always seem to work better in the development environment – for a reason), I’ve listened carefully for any clicks or other sound artifacts but have so far heard none. (My reference DVD has been Eric Clapton Unplugged at + or – 0.5% speed shifts.)

The audio drift is on the other hand so small during a normal movie that its probably unnoticeable even if you use SPDIF and don’t match rate. So chances are that you wouldn’t have noticed, had I not told you here. But I’m an honest kind of guy.

After some setbacks (as predicted, but still annoying) there is now a new version of the MPC-HC GothSync tryouts player to download and test here. A thread for commenting and reporting bugs can be found here (Doom9′s forum).

I’ve had some building issues as the base revision of MPC-HC has been stepped up to 1173 so please look out for missing decoders and the like. There is also a link to a build of the regular revision 1173 (without my patches) of MPC-HC on the GothSync page to make it easier to compare the versions when a bug is found.

Please let me know how it works!

Wozio pointed out for me in a comment to the previous post that VMR9 does not support GPU acceleration in Vista and beyond. That made me take yet another look at the EVR code in search of that magic place where to insert my few lines of code.

EVR in sync.

And I think that I found it! Now the green line and the red line on the statistics display stay roughly parallel even when showing 25 fps material on a screen tweaked to refresh at 49.95 Hz (for testing purposes). The frame lock code kicks in and slows down the video as required. I’d say that’s worth yet another Anchor Steam (but it’s not even 10 AM yet so that’ll have to wait).

Now the Pareto Principle, the 80 – 20 rule, applies as almost always. With some luck, I’ve found the basic solution. It’s an ugly and hard-coded solution but the principles seem to work. Finding the solution is usually only 20% of the work though. I still need some GUI resources, I need to do some refactoring so that VMR9 and EVR can use the same code, I need to check so that multiple monitors work, and I need to see to it that everything “just works” in general. And then there is always the odd setback. That’s the remaining 80%. On the other hand, I have 2,5 weeks of vacation left and it’s raining again.

I have been studying the EVR flavor of renderer in MPC-HC to see how to implement GothSync in it too. I have decided not to for the time being, the reasons being:

• EVR seems to be really good at playback when the display refresh rate is not an even multiple of the video frame rate. I don’t want to mess with that.
• The actual rendering code is the same for EVR and VMR9, i.e. the same shaders can be used.
• The EVR code is quite complex. It would take some time to learn the ropes, time better spent elsewhere probably.

The two remaining differences between VMR9 and EVR that I see are the mixer (where several video streams can be blended before being displayed) and perhaps the remaining life span. I haven’t seen any problems with the VMR9 mixer and VMR9 seems to be supported in Windows 7 at least so those differences don’t seem major.

I will therefore right now focus on implementing a GUI and some more intelligent on-screen statistics for GothSync in VMR9 instead.

It has been raining the whole day so I made it into a coding day (I assembled some new IKEA furniture too – an equally intellectually demanding task if you ask me).

I am thus happy to say: read more about the first released prototype version of Media Player Classic Home Cinema with frame lock features from GothPlayer here (on this blog) and here (Doom9′s forum).

I have been enjoying myself with reading the source code for the image presentation in MPC-HC in the “renderless VMR9 mode”, to which I have currently tied the “GothSync” framelock functionality. The reason is that I want to understand to which extent the GothSync functions are compatible with the existing vsync-related functions. As far as I now understand, the following is taking place in the frame presentation code in renderless VMR9 mode in revision 1165 of MPC-HC:

• Checking VSync makes the renderer wait until the beginning of the vertical blank before it calls the function that inserts a new frame into the swap chain in the video memory (the chain of frame buffers queuing up the frames to be presented).
• The frame presentation code always waits to the end of the vertical blank before it returns.
• The Alternative VSync option causes the player to create a DirectX device that will not wait for the vertical blank before “flipping” over a new image into the front buffer (which is what is seen on the screen). This means that the timing for the flip needs to be handled outside the DirectX device. According to the MPC-HC Wiki this is the recommended mode.

Logic supported by a few quick experiments show that the VSync and Accurate VSync options are entirely compatible with GothSync. In contrast, and as I suspected, the Alternative VSync produces tearing together with GothSync and should thus be avoided in this combination.

GPU flushes don’t interfere in any way with GothSync.

I still need a few more rainy days on this vacation before releasing something you can use to check my claims.

Links

[1] MPC-HC – New Renderer Settings

Keeping the time.

Adding the adjustable reference clock filter to MPC-HC was not as simple as implementing the first sync mechanism. MPC-HC has a way of “plumbing” filters that is different from the way taught by the Microsoft examples. So I did what I usually do: I found myself an example filter in MPC-HC and copied the plumbing from it.

After some experimenting and passing of pointers hither and dither (and messing up some reference counts along the way) I was able to add the SyncClock to the graph and framelock the incoming video to the display refresh rate.

There are a number of things left to do before I will release the app for testing:

• Add some new settings to the options or the menus.
• Ensure that audio and video will stay in sync. This requires that the audio renderer matches its rate to the external (to the audio renderer) reference clock.
• Fix the leaking plumbing (one or two memory leaks).
• Add some intelligent numbers to the on-screen statistics.
• Ensure that the new sync mechanisms don’t fight the existing ones. It doesn’t look that way but I need to understand the existing mechanisms better to be certain.

When everything works I have promised myself a brand new 1080-capable projector. Hopefully I will be able to enjoy the combination of a fully synchronized MPC-HC and the new projector before my vacation is over.

The first “goth” synchronized movie clip.

I have now added code for one of the synchronization mechanisms from GothPlayer to MPC-HC, the one that relies on PowerStrip to control the display timing. This is not the mechanism that will work for most users as it is a little picky about graphics boards and displays but it’s the one that is easiest to import from GothPlayer. I took the opportunity to fix a few todo items while at it. The sync now works on an arbitrary monitor recognized by PowerStrip. It works well with all my 720p monitors but doesn’t work too well on one of my displays in 1080i mode so there may be limitations to this method that in turn may depend on how PowerStrip updates the graphics board registers. The other sync mechanism that I intend to implement later doesn’t have those kinds of limitations.

The changes made so far to the code are rather non-intrusive: a handful of lines in the beginning of the frame presentation method (CVMR9AllocatorPresenter::PresentImage) and one extra class “CGenlock” to handle the actual synchronization. Later I will need to add a custom reference clock generator to support the other synchronization algorithm.

I consider this a personal milestone and worth an ice-cold Anchor Steam beer!