2008/11/6 Hans de Goede <[EMAIL PROTECTED]>: > Ilyes Gouta wrote: >> >> Hi, >> >>>>>>> 9. JPEG decompression >>>>> >>>>> Already implemented >>>> >>>> Is it standard? I mean the processing. Maybe we can have some comments >>>> from Willem. >>> >>> It can handle both standard JPEG's (with and without a quantization >>> table, >>> if its missing it will use the default one) and special custom JPEG >>> formats >>> (currently only Pixart JPEG). >> >> Very cool. What standard did you base your code upon? Any references? >> > > I've used the (BSD licensed) tinyjpeg code as a base and added additional > error checking and support for the Pixart JPEG format. > > I've choosen tinyjpeg, instead of using libjpeg as I wanted a small > embeddable jpeg lib as I need to make changes to the JPEG decompression to > accomodate cams which send out non standard JPEG formats. > >>>> How do intend to do it? By maintaining a list of capabilities for >>>> every device? How about extending V4L2 do have this information from >>>> the drivers? >>> >>> This is something which has to be decided upon, most likely we will add >>> an >>> "is webcam" flag to the v4l2 capabilities bitfield, and then if this flag >>> is >>> set, check for a autowhitebalance v4l2 control, if the cam does not have >>> that we activate software autowhitebalance (and add a fake >>> autowhitebalance >>> control to control that, default on). >>> >>> For cams which have awb, but where it cannot be turned of, we will still >>> add >>> an autowhitebalance v4l2 control to the driver to signal this, this >>> control >>> will then be readonly and always read awb on. >>> >>> Atleast that is what was discussed at the Linux Plumbers Conference end >>> September, and that is the way forward IMHO, feedback on this much >>> appreciated. >> >> I still want to see how libv4l will be embedded properly in the >> capture flow, i.e between the final application and the kernel and >> capture device. Using hacks like LD_PRELOAD isn't a long term >> solution. > > The v4l2 lib API mimicks the raw /dev/video open, so applications can easily > be patched to directly use libv4l2, just replace open with v4l2_open, etc. > > A joined effort between distro's to patch all FOSS v4l applications is > underway here, patches welcome! : > http://linuxtv.org/v4lwiki/index.php/Libv4l_Progress
Is there any current effort in trying to get all programs that interpret the v4l2 spec wrongly regarding the TRY / SET FMT to correct their behaviour? Regards, Erik > > Regards, > > Hans > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ M560x-driver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
