Thinking about this a bit more. A YUV frame is Y= 720x576 U=720x576/2 V=720x576/2
Which comes to the same as a complete 16bit frame. So there is no gain for 16bits for a complete frame. However the Xv/YUV code does scaling in hardware so if you are displaying a 360x288 movie then the YUV update is half of that whereas to display it in the framebuffer you would still have to update the whole 720x576 frame. Add to this the extra overhead of decoding the yuv data in software there would not be any gain from attempting to do this. Additionally the YUV/Xv updates are synced to the vertical retrace to avoid tearing which is not the case for the normal X updates. John > -----Original Message----- > From: Wilhelm Eger [mailto:[EMAIL PROTECTED] > Sent: 14 December 2005 15:38 > To: [EMAIL PROTECTED]; Discussion list for development of the > IVTV driver > Subject: Re: [ivtv-devel] xdriver 16 bit > > John Harvey wrote: > > No.8 bit is theoretically possible but i have no real > > desire to implement it. > > That's clear. > > > There shouldn't be any problem with xine performance > > using Xv. And the Xv playback would not be affected by > > running the xdriver in 16 bit anyway. > > Ok, that's good to know. > > > What are the performance problems you are having and > > on what sort of machine playing what sort of video > > (size, format etc.) > > I have no performance problems at all, but my machine is a bit slow > (800Mhz Athlon). So I'm looking for any way to optimize my setting. > > By the way, I succeeded in compiling the driver on xorg 7.0.0-r3 > (gentoo) and it runs quite well. > > Wilhelm _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
