On Sunday 07 January 2001 16:23, you wrote: > Linux Kernel 2.2.18 > XFree86 4.0.2 w/ nVidia's binary driver (I'm loading the v4l module) > BTTV 0.7.52 (compiles/works fine w/ 2.2.18 after fixing up > kcompat24.h) XawTV 3.28 > Since Xvideo HW scaling works fine for applications such as xine I > guess that something is wrong on the v4l side of things. But since I > know very little about the mechanisms involved, I'd greatly > appreciate it if you could tell me what's going on. Xawtv, more or less, just does a call to XvPutVideo if you use xv. (the xvideo test program with --port nn as well) If your capture card does a max of 768x576 (or whatever the NTSC equiv is) then scaling that to fit the full screen is down to the XF4 driver(s). v4l (the xf4 module) uses xv's offscreen surfaces to display the video - BUT only if the driver for capture card says it can do a YUYV XvPacked overlay. (No reason it can't be hacked to support more though) After a call to VIDIOCSPICT to set yuv it calls VIDIOCGPICT to see if if YUV is returned. If that fails it falls back to rgb. (some drivers, like the dc10+ driver can do yuv but currently cgpict always returns an RGB value breaking the v4l module, very easy to fix though, dunno about your cards driver though - that's one place to check) v4l will call into the nvidia driver to allocate a surface and then use the offset of that surface to tell the capture driver (with VIDIOCSFBUF) Then it does a call to display the overlay which is where the nvidia driver should stretch the video. So I'd guess that either the v4l code doesn't think your capture card / graphics card can do a yuv2 XvPacked surface (which may simply be a bug) or there's a bug in nvidia offscreen surfaces or perhaps they don't even exist (a few (a lot?) of X4 drivers simply don't have offscreen surfaces yet) -- Michael.
