On Tue, 11 Mar 2003, Tuukka Toivonen wrote: Thanks for the response, comments in-line. > At some point it is necessary; however, you should avoid doing format > conversions in the kernel. But if you don't do it, no application will > understand the format. There's some wisdom in that, but really, the conversion devolves to how I copy the data from my buffers to the user. At what complexity does a 'conversion' trip Pavel's death penalty? How about the buffer swabbing I have to do for my MPEG data[1]? This is a similar problem, but without the clever asm. > My recommendation: in the short term, write format conversions into the > kernel driver so that applications work using the standard V4L(2) api. > Invent also new format description, so that userspace applications can get > the raw the if they understand it. Better would be a consolidated format conversion library that all projects agree to use. People with new formats could supply plugins. > ... then every application would benefit from it when they are all converted > to use gstreamer :-> Er, do you use GNOME or KDE? I find both too heavyweight and don't use either. The point of this non-sequitir is that assuming your favorite project will be the one true choice is .. naieve. This isn't meant as a slam to you or Gstreamer, but I've seen this too many times. If performing a simple translation gives me wider compatibility with existing applications then I'm all over it. If the gstreamer team wishes world-dominiation, then it is their responsibility to sell the applications on why theirs is the right solution. John [1] The raw capture's byteorder is compatible with x86's. The compressed MPEG stream coming from the iTVC15/16 engine is byteswapped. By performing the swabbing in-kernel, we can do stupid stuff like: # cat /dev/ivtv0 > /tmp/testcap.mpg
