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:
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:
* 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:
* s/filter/plugin/
* add $(GST_LIBS) to all plugins
* move Makefile.am things around to a mostly standard layout
* remove HTTP flags/libs from elements since http element moved
Original commit message from CVS:
fixes for make distcheck
does GST_ELEMENT_IS_COTHREAD_STOPPING still exist ?
and if so, how should it be found by the bytestream test ?
Original commit message from CVS:
fixes to make distcheck work
changed registry out of date to warning to allow tests to continue regardless (any better suggestions much appreciated)
Original commit message from CVS:
- added playondemand plugin by Leif Morgan Johnson <lmjohns3@eos.ncsu.edu>
- some fixes to int2float
- aplied a patch from wrobell <wrobell@ite.pl> that is a first attempt at
making automake 1.5 happy (gst now requires automake1.5). It's still not
perfect but it builds.
- Made the schedulers plugable. The default scheduler now lives inside a
plugin.
- Added a new mpeg1/2 parser/demuxer.
- Fixed some compiler warnings in the core libs.
- substantial work to GstThread (hopefully less race conditions). simplified
the code in GstThread a bit. A state change can now also happen in the
thread context.
- reworked the state semantics of a bin. it'll now automatically get the
highest state of its children.
- the autoplugger now nests the threads so that a state change failure of
one thread doesn't make its upstream thread lock.
- GstQueue refuses to go to PLAYING if the sinkpad is not connected. This
way the queue will not wedge in the _get lock.
- GstQueue unlocks its mutexes when going to PAUSED.
- make sure that when all elements in a bin/thread go to PAUSED, the bin
is set to PAUSED too.
- make a parent bin wait for its children to PAUSE before ending the
iteration with FALSE (EOS)
- Some changes to GstPlay to deal with EOS.
- aplied the latest patch from Zeenix to gstrtp.
end result: GstPlay doesn't crash on EOS and the pipeline is now shut down
properly.
Original commit message from CVS:
Lots of modifications to the plugin system.
- Added a GstPluginfeature object that serves as a base class for all
plugin contents.
- changed the plugin API, everyhting is now added with
gst_plugin_add_feature
- typefactories are named now so that they can be located easily and filled
in at plugin load.
- mime types like "video/raw image/raw" are gone for now.
- lots of plugin updates (style and API changes)
- tested with an without registry.
- updates to various tools.
- added a little testsuite to test/show how you can load plugins (4 modes)
Test this one, Almost everything has changed :-)
Original commit message from CVS:
The first wave of docs updates
Added a little more comments about the API usage in the api docs.
Some fixes for the capsnego testsuite.
Original commit message from CVS:
More work on capsnego proxying. It should be OK now.
Added another testcase enum that shows various capsnego algorithms.
Warn about pads that try to set a capability incompatible with their
padtemplate.
Implemented refcounting and copy_on_write for caps/props.
Original commit message from CVS:
More work on capsnego, mostly proxying
Added another testsuite for capsnego
Added caps to vorbisdec, mp3parse, mp1videoparse
Redid the queue proxy handling a bit.
Original commit message from CVS:
Reworked the capsnegotiation function
audiosink now uses capsnego to set its parameters
mpg123/ac3dec use capsnego instead of metadata
Added the beginnings of a testsuite for capsnego.
Original commit message from CVS:
Updated test to have a comment explaining its purpose (very important this,
especially for regression tests), and to actually test what I meant it to.
Original commit message from CVS:
Added a testsuite. This currently only has one test, which replicates a
problem just submitted to the list.
I hope noone disagrees that we need a testsuite. Also, hopefully we all
think that a tiny testsuite which is easy to add tests to is much better
than a huge project to create a complete testsuite, which never gets
started because its too big and scary.
I suggest that tests get created whenever someone has a spare moment, or
whenever a bug is reported (to replicate the problem, and thus be sure that
when fixed it stays fixed), and before making a change to a piece of code
to ensure that it remains working.
If we all add little tests occasionally, then we'll have a good useful
testsuite before we know it. All you need to do is make a
