From: Billy Biggs To: Christian Fredrik Kalager Schaller Cc: Bcc: Subject: Re: Multimedia article Reply-To: In-Reply-To: <1008503345.1399.3.camel@localhost.localdomain>; from Uraeus@linuxrising.org on Sun, Dec 16, 2001 at 12:49:04PM +0100 Christian Fredrik Kalager Schaller (Uraeus@linuxrising.org): > Christian: Billy, you develop Movietime in order to push the > boundaries in video playback under Linux to see what needs improving > in things like GStreamer, the kernel and X in order for Linux to be > able to deliver perfect video playback. What can you tell us about the > problem you have discovered with vertical refresh under X? Video sequences are produced for a specific playback framerate. At rates of 24fps and higher, frame display durations approach monitor refresh rates. For fluid motion, each frame in a video sequence must be displayed for the same number of screen refreshes. This is often impossible. Consider playback of a 24fps movie on a 60hz display. The optimal strategy is to display frames in a 2-3-2-3 refresh pattern, which appears as objectionable judder at such a low refresh rate (identical to film->ntsc conversions, the 'credits staggering up the screen' effect). Similarly, a deinterlaced NTSC stream at 59.94fps jumps badly on a monitor run at 72hz or 75hz. A great article by Dave Marsh on these issues is here: http://www.microsoft.com/hwdev/archive/TVBROADCAST/TempRate.asp The XF86VidMode extension gives us some ability to switch the monitor refresh to provide a better match for the video signal. The difficulty is then trying to keep playback in sync. Some possible techniques are: 1. Adapt the monitor's clock dynamically. Dave Marsh suggests that applications could monitor the clock drift and adapt the display's refresh rate. 2. Sync the video to the output refresh. For DVD watching this option is very reasonable, especially if you own a projector that can do both 60hz for TV and 72hz for film. 3. Create temporally interpolated frames. Motion-vector interpolation is expensive, but becoming more viable. Each technique above requires accurate information about the display's refresh frequency, and timestamps on when the retrace occurs. It's unclear how to best provide a clean API to this in X. Unfortunately, achieving useable accuracy will likely require kernel drivers, maybe as part of DRI? This is where discussion is required. My graphics page: http://www.dumbterm.net/graphics -- Billy Biggs vektor@dumbterm.net