summaryrefslogtreecommitdiff
path: root/docs/design/part-gstelement.txt
blob: ad3951a403e9390147196ae5cd81a7ee622bf65d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
GstElement
----------

The Element is the most important object in the entire GStreamer system, as it
defines the structure of the pipeline.  Elements include sources, filters,
sinks, and containers (Bins).  They may be an intrinsic part of the core
GStreamer library, or may be loaded from a plugin.  In some cases they're even
fabricated from completely different systems (see the LADSPA plugin).  They
are generally created from a GstElementFactory, which will be covered in
another chapter, but for the intrinsic types they can be created with specific
functions.

Elements contains GstPads (also covered in another chapter), which are
subsequently used to connect the Elements together to form a pipeline capable
of passing and processing data.  They have a parent, which must be another
Element.  This allows deeply nested pipelines, and the possibility of
"black-box" meta-elements.

Name
~~~~

All elements are named, and while they should ideally be unique in any given
pipeline, they do not have to be.  The only guaranteed unique name for an
element is its complete path in the object hierarchy.  In other words, an
element's name is unique inside its parent.  (This follows from GstObject's
name explanation)

This uniqueness is guaranteed through all functions where either parentage
or name of an element is changed.


Pads
~~~~

GstPads are the property of a given GstElement.  They provide the connection
capability, with allowing arbitrary structure in the graph.  For any Element
but a source or sink, there will be at least 2 Pads owned by the Element.  
These pads are stored in a single GList within the Element.  Several counters
are kept in order to allow quicker determination of the type and properties of
a given Element.

Pads may be added to an element with _add_pad.  Retrieval is via _get_pad(),
which operates on the name of the Pad (the unique key).  This means that all
Pads owned by a given Element must have unique names.
A pointer to the GList of pads may be obtained with _iterate_pads. 

gst_element_add_pad(element,pads):
	Sets the element as the parent of the pad, then adds the pad to the
	element's list of pads, keeping the counts of total, src, and sink pads
	up to date.  Emits the "new_pad" signal with the pad as argument. 
	Fails if either the element or pad are either NULL or not what they
	claim to be.  Should fail if the pad already has a parent. Should fail
	if the pad is already owned by the element.  Should fail if there's
	already a pad by that name in the the list of pads.

pad = gst_element_get_pad(element,"padname"):
	Searches through the list of pads 


Ghost Pads
~~~~~~~~~~

More info in part-gstghostpad.txt.

State
~~~~~

An element has a state. More info in part-states.txt.