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:
A rather large patch:
- changed the API for the padtemplates:
- remove the factories (array of pointers) for the padtemplates,
properties and caps. The static array was a nice idea but converting
all the property values to a gpointer was not a good idea.
float properties were not possible, and casting a gint to a pointer
is not very portable. The new API just uses the _padtemplate_new,
_caps_new and _props_new functions to create the templates.
This has the added benefit that the API is now uniform for static
and dynamic templates and that the code can be made cleaner.
- lots of cleanups in the way the capabilities are constructed (va_list)
- lots of updates for all the plugins (new API)
- docs updates (new API)
- removed the videoraw docs.
Original commit message from CVS:
Lots of updates to the plugins for caps negotiation.
Added YUY2 output to the win32 dlls.
Added a colorspace converter in gstplay
Original commit message from CVS:
More doc updates
Manual additions: xml/load save of custom XML, debugging, request pads
added a signal to the example plugin
fixed a bug in mp3parse (ifdef 1)
Original commit message from CVS:
This is a megapatch with the following changes:
- moved the gchar *name to GstObject, removed the ones in GstElement and
GstPad.
- moved the parent handling completely into GstObject. This cause *all* of
the plugins to fail (except those that used gst_pad_get_parent)
- rearanged the XML save handling.
- GstObject now has a class function save/restore_thyself.
- GstObject has a generic method gst_object_save_thyself, this makes it
possible to fire a signal wehever a new object is loaded. This is needed
so we can add XML save hooks.
- GstXML API has changed slightly. You now have to create a GstXML object
first before you can actually load something. This makes it possible to
attach a signal to GstXML whenever an object is loaded. I'm not sure we
will keep this interface.
- GstObject can now print the path_string without knowing about the GstPad and
GstElement types.
- Added gst_bin_get_by_name_recurse_up to lookup an element in the current
element hierarchy.
- added XML namespaces to the saved pipelines the namespace is:
http://gstreamer.net/gst-core/1.0/
namespaces are needed to distinguish user generated XML from the core XML.
Note that the plugins still contain a macro GST_OBJECT_PARENT that will be
replaced with gst_pad_get_parent shortly.
Original commit message from CVS:
Docs updates
Added XML load from memory functionality
Undid the videosink patch, something else is wrong now on my machine:
no MMX acceleration :-(
Original commit message from CVS:
Updated the manual and the docs.
Removed the esdsink in gst/elements/ we have a real one not in the
plugins dir.
Added more APIs to query the plugins, types and caps. more fields now
have a getter and a setter. This is needed to make gstreamer wrapper
fiendly.
Added gst_element_disconnect beacuse we also have a gst_element_connect
Original commit message from CVS:
Changed the GstPadFactory and added the GstPadTemplate.
The GstPadFactory is an easy way to define a pad with capabilities.
The GstPadFactory is converted into a GstPadTemplate. The template is
used to create new pads and to expose the possible pads used in an
element to the plugin system.
updated mp3parse, mpg123, cdparanoia to the new API.
Rerun gstreamer-register because the XML definition has changed.
Original commit message from CVS:
Documentation updates. All standard library objects and standard
elements are documented. Modified some of the elements to more
accuratly report about their arguments so the documentation builds
more reasonable output.
Added aviencoder and jpegencoder elements (not working yet)
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
