Original commit message from CVS:
* implemented threadsafe property set/get system as discussed in
docs/random/wingo/threadsafe-properties
* some cleanups
* this change will cause binary incompatibilities, better rebuild them plugins
now, off to drink :-)
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:
New bytestream fileio style api has landed, along with some minor fixes:
- implement gst_bytestream_tell
- prevent buffers from being gobbled after a seek
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:
Added gst_bytestream_get_timestamp() call to get timestamp of data at
the front of the stream. If no data in stream, loads 1 byte to get a
new buffer and uses its timestamp.
Does nothing to handle readers that try to read data lengths that span
buffers with multiple timestamps.
_get_timestamp() now used when creating new buffers.
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.
Original commit message from CVS:
merged schedulers
- new file cothreads_compat.h to provide linking to desired cothreads package
- changes in basic and fast scheduler to use cothreads_compat.h
- updated Makefile to build the basic and the fast scheduler from both packages
- removed gststandardscheduler.c - it is not needed anymore
Available schedulers are now 'basic', 'standard', 'fastbasic' and 'faststandard' where the basic ones are built with old cothreads and the standard ones with the new cothreads.
Original commit message from CVS:
Fix the tests so that builds that are not --enable-plugin-builddir can register
the plugins from the uninstalled gstreamer directory. There is some small amount of voodoo
here.
Also, add gst-inspect-check to gstreamer/testsuite, where it probably belongs
