[gst-devel] What I want out of a "Status Table"

Jeffrey C. Ollie jeff at ollie.clive.ia.us
Fri Feb 11 12:43:30 CET 2005

What kinds of information to gather:

1) Element/plug-in name.
2) Short, one-line description.
3) Longer, more meaningful description.
4) Pads:
	a) Listing of all pads.
	b) Capabilities.
	c) Description.
5) External library dependencies:
	a) Name of library.
	b) Link to "home page", not just where the source tarball can
	   be downloaded.
	c) Version numbers that are compatible (where known).
6) Properties:
	a) Name.
	b) Description.
	c) Read/write or read only?
	d) Type (float, integer, string, etc.)
	e) Valid values.
7) Signals.
7) Platform availability (all platforms, Mac OS X only, anything but
Windows, etc.)
8) CVS module/branch/revision number (or whatever) that indicates the
version of the plug-in that is being referred to.

What this information would be used for:

1) Learning about the plug-ins that are available so that gstreamer apps
can be developed.

2) Learning about plug-ins that are not available on the current system
so that appropriate dependencies can be installed and plug-in can be
made available.

Ideally, this information would be available both to gstreamer-based
apps (gst-inspect, totem, etc.) and on a web page.  Also, the
information should _not_ be limited to the plug-ins that have been
compiled on (or installed on) a particular system because part of the
point (and where the current gst-inspect fails) is learning about plug-
ins that are available in the gstreamer source but have not been


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20050211/c4a9f2c3/attachment.pgp>

More information about the gstreamer-devel mailing list