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:
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
Original commit message from CVS:
commit to make gstreamer follow the gtk function/macro naming conventions:
GstPadTemplate <-> gst_pad_template <-> GST_PAD_TEMPLATE
and the same for *factory and typefind.
Original commit message from CVS:
* new parser that uses flex and bison
- doesn't do dynamic pipelines yet...
* added GErrors to the gst_parse_launch[v] api
* added --gst-mask-help command line option
* fixed -o option for gst-launch
* GstElement api change:
- gst_element_get_pad
- gst_element_get_request_pad, gst_element_get_static_pad
- gst_element_get_compatible_pad
- gst_element_get_compatible_static_pad, gst_element_get_compatible_request_pad
- gst_element_[dis]connect -> gst_element_[dis]connect_pads
- gst_element_[dis]connect_elements -> gst_element_[dis]connect
* manual update
* example, tool, and doc updates for the api changes
- no more plugin docs in the core docs, plugins require a more
extensive doc system
Original commit message from CVS:
* removal of //-style comments
* don't link plugins to core libs -- the versioning is done internally to the plugins with the plugin_info struct,
and symbol resolution is lazy, so we can always know if a plugin can be loaded by the plugin_info data. in theory.
Original commit message from CVS:
* add two apis:
* gst_element_connect_elements_many (elem1, elem2, ...)
- calls gst_element_connect_elements() in order
- should be called gst_element_connect_many, but we need to rename gst_element_connect_elements first
- simplifies common-case code
* gst_bin_add_many (bin, elem1, ...)
- calls gst_bin_add on all of the elems
- again, simplifying common code
Original commit message from CVS:
miscellaneous fixes, added gst_pad_unset_sched() api.
although I unref the old pipeline and the cothread context gets freed in dynamic-pipeline.c,
I still get segfaults.
Original commit message from CVS:
I've removed autoplug from build and dist since it seems to need Gnome and
we agreed not to have that in the core.
Can someone take a look at it ? I couldn't get it to work anyway ;)
It should probably either be rewritten without gnome or moved to another
module
Original commit message from CVS:
added a slightly new twist in dynamic-pipeline.c: I actually iterate the first pipeline.
this causes a segfault (at least on my machine, i've been having link issues today though).
if a scheduler wizard (ahem) could take at glance at this, i'd be eternally grateful :-)
