I have worked with the direct show suite on windows and I would like to build a similar system for linux (it would do exactly what you describe; as soon as the user put a shared lib in a directory, then any program could use that codec). I don't know exactly what it should look like but here are my thoughts... I think we should have a directory under /usr/lib/ called codecs, and then two further directories for audio and video. So if you wanted to know exactly what codecs were in the system you could just browse those directories and look at the shared objectslibs in them. This would allow another directory for other codecs as well for mixed media or perhaps just general data compression. Now you need to devise a system where a program can simply scan the directories and see what input format something gets and what output format it can put out. Then it becomes a relatively straight-forward case of using input the lib accepts and hooking its output to the input of another lib (so you could perhaps compress raw YUV video to mpeg2, then make an AVI out of it). I am used to a c++ interface for all of this (Direct show, direct x)(and no matter what we decide, I will end up wrapping it in c++) but most of the video stuff and audio stuff written thus far for linux is in c. It would be ugly to do this in c (I think) but perhaps it should be that way so we don't force people to use c++ if they are not comfortable with it. I think a simply text file should be in each directory (/usr/lib/codecs/[video,audio]) that should describe what each shared object is capable of, and there should be a way that the object can output the correct information for registration. So basically you copy the .so to the directory and run another program that registers that object file into the text. That text file would need to say what formats the object can take, perhaps a vendor id (so we could have multiple objects that compress to the same format, some GNU, some not), and what formats it can output. Perhaps it should also have an object id so you request an object from the object file and that object is capable of doing the compression. That way the same object file could host multiple objects (sorry if this is beginning to sound like COM). You need to text file so programs don't have to load each object in order to see what it is capable of, if that was the case your memory usage would go through the roof (each object could be fairly large, and I don't think you can unlink an object once you have asked the linker to link it into your running program). So we provide a generic library interface that wraps all of the dlopen's and such, but it is SUPER short. You would use our interface to get the object, call the objects initialization function (to load any further shared objects that it needs to load) and then you should be ready. I don't know exactly what interface we would need further, but I guarantee there are people on this list who are familiar with the different compression formats who would know. I think a generic pre-compress (where we set up all the state information like what formats and what quality we want, etc), then a compress, then an end-compress should do the trick. Decompression should work similar, and be similarly as simple. The key (in my opinion) is to provide the absolute minimum interface, and keep it really simple (hence the text file, etc.). Chris
