It is the vertical refresh rate that you are concerned about. The horizontal doesn't matter, as long as your output device can sync on it. And you want the vertical refresh as close to the ideal refresh rate as you can get. Of course the ideal refresh rate would be an integer multiple of the rate that the mpeg decoder produces mpeg frames. We assume that this is 24 per second, but I don't think that's done with an atomic clock or anything, so we assume it's 24 but it's probably a little off like every thing else.
Here is my explanation of the 72hz timing, I'm willing to adopt a better one when I hear it.
The frames come from the DVD mpeg decoder at about 24 per second. After each frame is decoded from the mpeg stream, the video card continually sends out that frame to the monitor during each refresh cycle, until the mpeg decoder has another one ready.
Whatever frame is ready when the refresh starts is the one that is sent out. The mpeg frames arrive each 1/24 sec, and if they are sent out at 1/60 sec intervals (for 60Hz refresh), the first frame will go out 3 times. Sometime during the third frame being sent out, the mpeg decoder has the second mpeg frame ready. Starting with the 4th refresh frame out of the video card, the second mpeg frame will go out 2 times until the third mpeg frame is ready, then that one goes out three times again and he pattern repeats. 3:2:3:2:3.
For the most part there is a 50% change in the duration of the frames from 2 to 3, then back to 2. If there is a lot of movement in the video in these frames the motion doesn't appear to be very smooth. My favorite test is the first two minutes of Shakespear In Love, including the 'Universal Studios' flying logo, the Mirimax logo pan across the water to the city, and the spiral pan down into the theater starting at the roof and moving down to the ground. Take note of the detail in the roof as the camera pans down. I can definitely see the difference between 60hz and 72hz here.
If the frames are sent out at 72Hz by the video card, then every 1/72 sec a frame is sent out, this is about a 3 to 1 ratio with the mpeg decoder. so frames go out 3:3:3:3... Occasionally because the timing isn't exact, one frame will go out 2 times if it's faster than 72hz or 4 times if it's slower than 72hz, instead of 3. This is because the video card output is always going to be just a little fast or slow in relation to the mpeg decoder. I don't know of any that use the same clock source that would lock them in step with each other. So there are still errors every couple seconds or so.
How often are the errors? I think the math works like this: (my own derivation, comments are welcome....)
(my 72hz vertical refresh runs at 71.989, so I use that here for an example)
perfect refresh rate = integer * mpeg decoder output
3 * 24 = 72
time in error per sec = perfect refresh rate - actual refresh rate
72.000 - 71.989 = .011
time in error per refresh = time in error per sec / actual refresh rate
.011 / 71.989 = 1.528e-4
The number of refresh frames till and error occurs is:
refresh frames per error = time of one refresh / time in error per refresh
(1 / 71.989) / (.011 / 71.989) = 1/.011 = 90
The number of seconds till and error is: refresh frames per error / actual refresh rate
90 / 71.989 = 1.25
My 72hz vertical refresh is actually running at 71.989, so the error per second is 72 - 71.989 = 0.011. Divide this by the actual vertical refresh rate to get the error per vertical refresh frame sent out to the monitor = .011/71.989. Now take the time for one vertical refresh, and divide it by the error, to see how many vertical refresh periods it takes to loose one frame, (1/71.989) / (.011/71.989) = 90. So every 90 refresh operations from the video card to the monitor, the video refresh is to slow by one frame making a series of refresh per mpeg frame of 3334333333. So the cost of the error is one mpeg frame displayed 30% longer than rest. How many seconds between errors = 90/71.989 = about 1.25 seconds. How many mpeg frames are decoded before we see an error? 24 * 1.25 sec = about 30. So one in every 30 mpeg frames is 30% longer than the rest. Better than every other one 50% longer at 60Hz.
So what is the error in refresh rate that will give you one mpeg frame in error every second? That would be 72 - 1/72 = 71.986Hz, or an error of .014Hz/sec.
So what happens if I go to 120Hz refresh. Now the error in refresh rate for 1 mpeg frame per second is 120 - 1/120 = 119.992Hz. or .008 Hz/sec. This is a much smaller number, so to preserve 1 error per second, the timing between the mpeg decoder and the video card vertical refresh rate would have to be much closer to each other.
If we use the same error in refresh rate as the 1 error per second at 72Hz had, and calculate what we get at 120Hz, then the calculation is (1 / 119.986) / (.014 / 119.986) = 1 error every 71.4 refresh frames, (note its the same frame count as it was at 72hz) or 119.986 / 71.4 = 1.68 errors per second, or 1 error per 14 mpeg frames. that's a lot more errors per second, but the error is less significant, because instead of a 33% change in the display time for the frame in error going from 3 refresh scans to 4 which is a 33% difference, we now are changing 5 refresh scans to 6, which is 20% difference.
At 240Hz, 10 refresh frames per mpeg frame, this is what we get with the same error that gave us 1 frame/sec at 72hz: (1 / 239.986) / (.014 / 239.986) = an error every 71.4 refresh frames, and there are 10 refresh frames per mpeg frame, so an error in every 7th mpeg frame, a little over 3 errors per second. But now the error is only 10% of the frame since there are 10 refresh frames per mpeg frame, so each error would be much less noticeable, although more often
Looking at the other extreme, what if the vertical refresh output was also 24hz, the same as the mpeg decoder. Not pratical but worth examination. A CRT may look like a strobe light at this speed if it would sync. Using the same timing error above, every 71.4/24 = 2.9 seconds there would be an error, but the error would be 100%, and completely loose a frame if the timing was faster or complety duplicate a frame fi the timing was slower.
In summary, as the refresh rate goes up, the error in refresh rate timing in relation to the mpeg decoder becomes more significant, making more errors per second with the same error delta in vertical refresh rate, but the result of an error in the video stream becomes less noticeable.
Ideally, the HTPC DVD player software would slightly adjust the speed of the video controller to compensate for any drift between the rate of the vertical refresh and the rate that the mpeg decoder produced frames, and keep them in lock step with no errors. Or they would use the same clock source so that they don't drift apart slightly. I suspect this is possible, but I don't know if anyone does it. I've read that faroudja may have a new box in the works with a built in dvd drive coupled to a native rate scaler, I would expect expensive equipment like this to do just that.
One thing that would be great to have is a readout from the htpc software dvd player telling the frequency that errors are occurring, This could be calculated from picking up the vertical refresh interrupt from the crt controller (or something like that) and keeping a count. Then you would know how well your player is actually working. The value could be the number of mpeg frams decoded between errors. Typical values for 60hz would be 1, for 72Hz it could be 30. It could also display the number of vertical refresh frames per mpeg frame, so 72Hz would be 3. Also a little red dot could appear in the tool bar or something on the mpeg frame that is in error. Wouldn't that be great! The calculations above aren't precise, since you can't get in there and actually measure the speed of things. An actual audit of what's going on inside would tell all. I dont know of anyone that does that either. But I'd sure like it......
Finally, once you send that perfect video stream to your display device, you need to know what your projector does with it. Many of the new digital displays have 60Hz internal timing, so sending them a nice 72hz error free signal is of no use, they will hack and whack it and just display the frames they have time for. Ideally they will sync directly to the signal you send and natively run at the speed that you are sending the video. A CRT projector or a PC CRT monitor does this very well since they are multisync and can run at any speed within their specifications. I use a 21" sony G500 PC monitor to do critical watching and play with timing issues like this, the refresh rate and horizontal/vertical resolution can go very high so I can play with different rates, then put it on a projector only when I'm happy with it.
I have an old 800x600 DLP projector, and using 'Mark Rejhon's Easy DOLA Calibration Test Pattern' as wallpaper on my pc, (thanks Mark), I could determine that I am getting a 1:1 lock between the pixels of the DLP and my pc at about 71Hz. It looses sync at 72Hz, so I think it was designed to do 70Hz, a common pc standard but not a video standard. With the scaler in the projector shut off, the phase is an exact match for 1:1 mapping of pixels, and I can get a pretty darn good looking presentation from that simple projector.