Mike Frisch (mfrisch@xxxxxxxxxx): > > When you say using a regular video card with TV-out, do you mean > > just running X at 720x[480,576] and drawing frames full-screen? > > Yes. > > > If you draw an interlaced frame to the screen in this manner, you > > have no way of knowing what order the fields will be shown. Not > > only that, if you don't know the clock the card is using to output > > the fields, if you don't draw the next frame in time it could loop > > between the two current fields (motion jumping back in time!). > > If I run Ogle or Xine on a 720x576 screen, why is this a concern to > me? If you are watching a DVD from video source which has interlaced frames (for example, a DVD of music videos or the DVD set of Friends, etc), you can either have the application display the frames without processing them or have the application 'deinterlace'. Ogle has no deinterlacing code (yet), so you can try it out on a DVD from video source to see the effects I describe above. If you deinterlace, say it's an NTSC DVD, you have two choices: deinterlace to 29.97fps or to 59.94fps. If you go to 29.97fps, you lose out on the smoothness of video, and in both cases you will judder (the judder being worse for the 59.94fps case). An excellent article describing judder effects is here: http://www.microsoft.com/hwdev/archive/TVBROADCAST/TempRate.asp My page on refresh sync is here: http://www.dumbterm.net/graphics/refresh/ > > Not only that, but you have no control over how the hardware scaling > > might affect your image. If you blit an interlaced frame at 640x480 > > for example, if the hardware decides to do a filtered scale to > > 720x480 for output to TV, you may see image data bleed into the > > other field. Ugh. > > I would leave this to the application. I'm not sure what you mean. You mean the application should always display progressive frames? That sucks but it would work, except you'll get judder unless the refresh issue is handled. -- Billy Biggs vektor@xxxxxxxxxxxx
