> 1. I've read somewhere (but I can't find it again to ref it, sorry) that > kernel drivers should not > encode data, to avoid over complicating them. Is this still true? I'd say the decompression should be handled by the driver as this isn't something generic. Converting one format into another should not be done by the driver, althrouth in that case some applications might fail because the hardware supports yuv data only. > 3. xawtv determines that my video card supports data in various formats: > > This is xawtv-3.36, running on Linux/i686 (2.4.1) > image format list for port 39 > 0x32595559 (YUY2) packed > 0x32315659 (YV12) planar > 0x30323449 (I420) planar > 0x59565955 (UYVY) packed > Xv: using port 39 for hw scaling > > The driver spits out YUV 4:2:2 interleaved format or YUV 4:2:0 Planar > format. Outputing raw YUV 4:2:2 format with no > the video card quite happily displays images (although they are a bit > blue baised). YUV4:2:0 doesn't work > at all for me, yet! xawtv uses the 4:2:2 (packed) format only for display using Xv. It is easy to handle and tends to be supported by nearly any piece of hardware (both grabber and video card) out there. YUV 4:2:0 (planar) is used for jpeg compression. "streamer -o /tmp/x.jpeg" should use that for example (add -d to see some debug output). > 4. If the solution to (3) is encoding the data to stop the image being > too blue, where should the encoding be done - > in the driver, or the application? Huh? The hardware has no controls to adjust bright/contrast/hue/... ? Gerd -- Man muß die Software wacker hüten weil in der Welt die Hacker wüten
