>Greetings, > >On Friday 22 February 2002 23:24, Mark McClelland wrote: >> Randy.Dunlap wrote: >> >There was a lot of discussion about 1.5 years back that most of >> >the video decompression and format conversion stuff should be >> >done in userspace, and that maybe a video conversion library >> >should be supplied to make it easier on apps. >> > >> >Isn't that still desirable? >> >> Desirable yes, but it's not really feasible yet. We would need a >> user-space framework that everyone agrees to use. Apps would request a >> format conversion from a master library, which would dynamically load a >> format-specific slave library to do the conversion. That would keep the >> master library small, yet infinitely extensible. No need to recompile >> apps either. > >There are additional problems; for example, the Philips decompressor >routines need information on the exact command that was sent to the cam in >order to initialize the decompressor properly. Pulling the decompressor >into user space would require extra hooks/ioctl()s for the user programs to >acquire this information. In other words: one big mess. I agree upon the >colour conversion stuff, but I draw the line at this low-level, >device-specific stuff.
I don't think this is a problem. Your compressed datas doesn't have to be alone, You can have an associated descriptor that can contains additional informations specific to the codec. Basically, your kernel API may says what native formats it supports, and for each of them, an additional info block can be defined in the API and returned when starting or stopping the capture process. Either that or include the information needed by the decompressor as part of the compressed data, (between "frames" with a couple of tags for example). Of course, I beleive that don't fit in the _existing_ API, oh well... ;) >Besides, whether its done in kernel or user space makes little difference: >it's still a lot of CPU cycles. But it's kernel cycles, and that's bad. Also, it makes it difficult to add MMX/3DNow/Altivec/whatever optimisations to the decoding process, or have "smart" decoders that can either output RGB or YUV with best optimisations for each or route the compressed output to a HW decompressor, etc... >Although.... before the pre-emptive stuff >made it into the kernel, if my decompressor routines take, say 200ms, does >that mean that no other process gets a slice until my read()/mmap() >function returns? I was under de impression it didn't matter (my system >seemed responsive as always even when the decompressor was chewing away) Preemptive kernel isn't here to help bloat the kernel :) Ben. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
