> 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.
I guess I will just have to decompress into YUV 4:2:2 packed. All I have to do is work out how to convert YUV 4:2:2 interleaved into YUV 4:2:2 packed.
> 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/... ?
The hardware has controls to adjust everything and I've tried zero to 128 on everything things still come out with a shade of blue. BTW. If xawtv expects 4:2:2 (packed) and the driver is only producing 4:2:2 interleaved this is probably why? Thanks Derek
