On Tue, 11 Mar 2003, PlasmaJohn wrote: >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' If you're really _copying_ the data to user, it probably doesn't matter if you have to shuffle it slightly too. But you should avoid copying at all and capture directly to mmapped buffer. >How about the buffer swabbing I have to do for my >MPEG data[1]? This is a similar problem, but without the clever asm. Hmm, my opinion is that you shouldn't even do that but let userspace libraries do the swapping if they want. I find it little use to be able do "cat /dev/video >stream.mpg" especially since the driver probably needs to be set up first using some special tools anyway. >> My recommendation: in the short term, write format conversions into the >Better would be a consolidated format conversion library that all projects >agree to use. People with new formats could supply plugins. Yes, of course. But currently there isn't such a library that would be widespread. Gstreamer is exactly that, but it's not yet in stable Debian 8-) >> ... 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 Me too. I use neither, I prefer listen/watch my media using command line tools. Gstreamer isn't really related to either, I think the name could be better and less misleading. Only thing Gstreamer requires is Glib, it doesn't need KDE/Gnome or even Gtk. >either. The point of this non-sequitir is that assuming your favorite project >will be the one true choice is .. naieve. Well, right now it should be your favorite project too: you yourself suggested using some library where people could write plugins. Currently there isn't anything better than Gstreamer for that (or if there is, let me know!). >times. If performing a simple translation gives me wider compatibility with >existing applications then I'm all over it. Yes, it might be good in your case... but in many other cases the camera data format is so complex that it's a very bad thing to convert it in the kernel into something compatible. And there might be many conversion routines necessary, slow and good, or fast and bad. >If the gstreamer team wishes >why theirs is the right solution. I don't see gstreamer necessarily as the "right" solution--instead it appears to be the only solution at the moment. (Actually, I hope it is also the right solution, in the sense that the API is good and efficient, but I haven't get to know it yet so well that I could tell).
