Chris Nuernberger wrote: > On Monday 13 May 2002 06:58 pm, you wrote: > >>>I think we should have a directory under /usr/lib/ called codecs, and >>>then >> >>Why do you care where it is ? We have LD_LIBRARY_PATH > > I want the codecs to be self-registering; > I also want easy install and removal, thus I want them all in the same > directory.
Yes, but make the directory run-time configurable... > The plan was to have them all register themselves by inserting data into a > textfile in their current directory, wherever that may be. This data has: > vendorID > objectName > format[s]Input > format[s]Output Preferably more than that. You would probably want input-output format pairs (as not all codecs support the same outputs for a given input). Secondly, you should probably also have a "cost" measure (I was thinking of using the average no. of CPU clocks relative to some reference codec). Finally, a "quality" measure, possibly a PSNR measurement - to give an indication of how good the codec is. This makes it possible to have a number of codecs - a fast but poor quality codec for real-time applications, and a really good, slow codec for off-line compression. To maintain all of this, I was thinking of having an core library that built and maintained the registry (possibly also benchmarked quality and cost). The core would also be responsible for hooking together codec chains for a given input, output, and cost measure... A bit of extra effort, but well worth it. The nicest codec interface I have used is that of rte (http://zapping.sf.net/). Flexible, configurable, and really easty to use. Also, the push/pull mechanism makes it possible to make relatively cheap buffers for decoding ahead, and, can also interface very nicely to v4l2's buffering system. > Then a program could, given an arbitrary stream and its format, see what > other formats it could convert that initial stream to (or more complicated > but still possible) find if, through a chain of three or four codecs, it > could end up with the desired result (remember that a codec could also > simply be image format conversion or scaling). Chris As I said above, use a core library, that given an input, output, and cost requirement, builds the desired codec chain, rather than duplicating this functionality in each program. As you may notice, I have thought long and hard about this - I have just never had the time to sit down and do it. I also haven't managed to think of effective ways to handle file sources and sinks (audio, video and time information). If you want any help working on this, send me some mail, and I will help where needed. -justin _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
