[mythtv] Proposal for vsync.c rewrite

[Daniel Thor Kristjansson]

This sounds like a much better method. The A/V Sync is confusing when
you are trying to just deal with video display. It interacts differently
with the display code with each sync method, this makes it difficult to
make any improvements since you have to do them multiple times and the
testing is difficult because you need two sets of nvidia drivers. I
realize the nvidia driver problem won't change, but hopefully fewer
rounds of testing will be needed with a shared codebase for A/V Sync.

One thing I'm interested in is the ability to double the framerate
by displaying each XvMC surface twice. This will let us display
individual fields at separate times with XvMC. Right now we are
decoding both fields but only displaying one of them in the 1080i
mode. I could hack this on later, but if you are doing a rewrite
anyway it might be something to keep in mind if you aren't already.

-- Daniel

]I'd like to move the entire job of video frame sync to a set of new
]classes.  A factory method will choose the best available subclass from
]the following list:
]  nVidia device polling
]  SGI OpenGL extension
]  DRI
]  /dev/rtc - VTAVSync has this code
]  usleep
]  usleep with busy wait (ReduceJitter).
]
]The first three are preferable since they actually sync us to the
]vertical retrace.  /dev/rtc is available only on Linux, and the last 2
]methods are important as a fallback.  There may be other methods
]available on other platforms.
]
]The A/V Sync methods are then simplified to compute & provide an
]adjustment factor to the frame sync methods.  In fact, at this point
]OldAVSync and ExAVSync become so similar it may be worth merging them.
]
]Thoughts?
]
]-Doug
]