Original commit message from CVS:
- Added first attempt at general caching mechanism (GstTimeCache renamed
to GstCache)
- Some more clocking checks and updates (waiting on GST_CLOCK_TIME_NONE
returns immediatly instead of blocking forever)
- Moved clock get/set functions to element class instead of instance.
- Added cache methods on elements.
- Renamed GST_PROPS_BOOL_TYPE to GST_PROPS_BOOLEAN_TYPE to make it more
consistent with gst_props_get/set_boolean and GST_PROPS_BOOLEAN.
- Give short stats about plugins in gst-inspect.
Original commit message from CVS:
if you can't write to the registry (ie it is root-owned and you are user) and it
is out of date, just ignore it; plugin state will get written to the user reg
Original commit message from CVS:
* add gerror to gstplugin.c -- not fully propagated to periphery apis
* fix recursive dir creation in the xml registry
* comment identity props
* fix dependency resolution in lib loading
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:
* added a get_perms_func to gstxmlregistry that will set _WRITABLE and _READABLE
as appropriate
* added an object property for location so that we can do some cleanup and initialization
Original commit message from CVS:
* GST_PLUGIN_PATH gets split into the user registry
* some debugging output in registry rebuilding
* don't go into =build, =inst, etc
* i really don't know what the current idiom is for the plugin test suites, disabling for now
still pending issues: what to do when other plugin paths are passed on the command
line for existing registries. if the existing registries were built against those
paths, the time checks work, but if not they will need to be rebuilt. i have a feeling
they should be rebuilt in any case, but it's a tricky issue.
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.
