In which ways would this be better/different to gstreamer? http://www.gstreamer.net/ On Mon, 2002-05-13 at 14:09, Chris Nuernberger wrote: > 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 > > > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list >
