Original commit message from CVS:
* fix refcounting tests so that they compile and run, but they fail currently:
gst leaks obscene amounts of memory ;)
* fix plugin loading test so that it only refers to plugins within the gstreamer/
tree
* store gst plugin paths in the registry
* is GST_REGISTRY is set, only use the user registry with the PLUGIN_PATH explictly
specified by the user
* all tests should pass now except refcounting
Original commit message from CVS:
Check to see if the registry is out of date, and if so try to rebuild it.
WIERD THING: trying to run gst-register using system() fails. Apparently child processes
can't link to libs parent processes use? It's wierd, and it could be a libtool issue.
That's probably just as well, it would be better just to use -register's code from within
core and not rely on another binary.
Original commit message from CVS:
Totally rewritten registry handling.
- move the registry save/load code into a gstregistry subclass, this
will make it possible to use other registries (flat file, web based,
RDBMS type, etc..)
- a simple GMarkup xml registry is implemented
- use standard statically linked plugins for core elements.
- GstPlugin has a very well defined set of functions now
A little bytestream hack..
Added more info to -inspect.
Some more debugging info for clocking.
Small cleanups
I use ./gst-register --gst-plugin-path=/opt/src/sourceforge/gst-plugins/gst-libs:/opt/src/sourceforge/gst-plugins/
to register core and gst-plugins now.
Original commit message from CVS:
registry handling changes
read up on it in docs/random/thomasvs/registry if interested
net effect should be transparent; ie. it will keep on working, but will
be more flexible than before. Testing with garnome seems to work now.
Should probably be rewritten completely, together with plugin loading, but
only after we spec it out ;) It's a bit messy.
