Menu
▾
▴
Re: [Openquicktime-devel] New OpenQuicktime code layout
|
From: Nicholas H. <nj...@ec...> - 2002-03-13 20:58:10
|
I think having a simple codec-lib is an excellent idea Yann! Thanks! I will get to work :) Having multiple codecs in one library depends upon using a quicktime_load_all_codecs() method...(or symbolic links) is this bad ? - does opening lots of libraries/modules use up lots of RAM ? The data structures themselves don't use up too much space... and it doesn't actually allocate memory for things like buffers until a track uses it. It also solves the codec listing problem... it may be something we just have to live with. nj. (I can't decide what my name is ;) >I don't think this is a good idea to add codecs in the core ... even if they >are very simple ... : the core is used in some other project using their own >codecs mechanism (gstreamer for example) >If you're new codec API can handle multiple fourcc into a single lib, I >suggest the creation of a simple codec-lib containing all the simple codec >you want (for example, all the RGB24, RGB32, YUV420, YUV422, ... could be >put into a single lib ...) > >Don't worry for the Windows version, I've created a simple winconfig.h file >that contain all the settings defined by all the automagic unix scripting >tools. ;) > >----- Original Message ----- >From: "Nicholas Humfrey" <nj...@ec...> >To: <ope...@li...> >Sent: Wednesday, March 13, 2002 9:06 PM >Subject: Re: [Openquicktime-devel] New OpenQuicktime code layout > > >> Hi Antoine, >> >> Thanks for the fixes - I'm not sure what I was doing with that dlerror >thing ?! >> And it does seem that Linux doesn't like the configure files I >> generate in Darwin - I had to do ./bootstrap on my Linux box as >> well.... >> >> >> I was in the middle of making changes to the Mp3 codec so that there >> doesn't need to be two copies of all the code - the codec will >> register both of its codes and hopefully a symbolic link will be >> enough for the loader to find it.... >> >> This is also supposed to be a generic solution so that plug-ins can >> support multiple codecs - Xanim and such... >> >> Unless you think it is a bad idea - I am going to have a couple of >> the simple (single source file) codecs loaded internally. It seems >> stupid to have separate when they are so small - but they will be >> loaded into the codec table in the same way as external codecs... the >> internal versions won't be used unless it can't find an external >> version... >> >> I have finished stripping out/cleaning up the codec support - so the >> callbacks are no longer stored multiple times in multiple locations - >> I will try to get it in CVS tonight... >> >> >> I have also added additional information about the codecs - Name, >> version, author, API version etc... and added functions to the >> OpenQuicktime API so that you can list the available codecs... >> >> >> I am just about to change the plug-in locating system (again!) so >> that only looks in the installation directory and directories listed >> in a environment variable (OQT_PLUGIN_DIR ?). This will make >> loading/listing of all codecs possible - but hopefully won't make it >> any less flexible - I'm not sure how/if this will effect the Windows >> version... Yann? >> >> >> Thanks, >> >> >> nick. >> >> >> >Hi, >> >I've downloaded the latest CVS code, but had to make some minor >> >modifications in order to get it compile back on Unix/Linux platforms: >> > >> > - audio/mp3 Makefile => generats _two_ codecs, .mp3 and _ms (there was >> >a bug in the first release of Makefile.am of the new layout, and then >> >one codec was disabled, I put back the way it was before, but with the >bug >> >corrected) >> > >> > - player and encoder now have their own Makefile.am, they are built and >> >installed automatically by the toplevel Makefile (but oqtplayer is built >> >only if the configure script can find sdl-config) >> > >> > - there was some dlerror mistake in plugin.c (should only be used if >> >dlopen/dlsym/dlclose return NULL, it seems invalid to try dlerror()!=NULL > > >to check for an error) >> > >> >It's now working fine on my computer and I have put these modifications >> >back in the CVS... However, I may have broken some things (and I had to >> >./bootstrap the code, maybee using older version of >> >libttol/automake/autoconf)! >> > >> > >> >>I have been working on the Uncompressed and IMA4 codecs. >> >> >> >>Should I be trying to implement them as internal codecs ? >> >>- or was the plan to make all Codecs external - in which case there >> >>seems to be a lot of dead code there... ? >> > >> >The idea was to have one minimal Quicktime library, and many little >> >external codecs, one for each format/fourcc. >> >QT4Linux did not have plug-in support, so all was implemented in the core >> >library as internal codecs and we have this as a legacy => get rid of >this >> >code if you can! >> > >> > >> >I also have the 3ivx Delta 3.5 codec modified so that it works with this >> >new version (and slightly modified plug-in interface)... >> > >> >- >> >Antoine >> >> >> -- >> Nicholas Humfrey >> >> Undergraduate, BSc Computer Science >> University of Southampton, UK >> nj...@ec... >> http://www.ecs.soton.ac.uk/~njh399/ >> >> _______________________________________________ >> Openquicktime-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openquicktime-devel >> > > >_______________________________________________ >Openquicktime-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openquicktime-devel -- Nicholas Humfrey Undergraduate, BSc Computer Science University of Southampton, UK nj...@ec... http://www.ecs.soton.ac.uk/~njh399/ |
