mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-20 00:31:13 +00:00
a7f3844adf
Original commit message from CVS: * docs/design/draft-ghostpads.txt: * docs/design/draft-push-pull.txt: * docs/design/draft-query.txt: * docs/design/part-overview.txt: Docs updates. Added general overview doc. Added draft ghostpad replacement idea.
108 lines
3.7 KiB
Text
108 lines
3.7 KiB
Text
Ghostpads
|
|
---------
|
|
|
|
Status:
|
|
|
|
DRAFT.
|
|
|
|
|
|
Purpose:
|
|
|
|
To create compound elements that look and behave like real elements
|
|
one needs to be able to expose pads on the element that are not
|
|
implemented by the element itself but by one of its components.
|
|
|
|
ex1:
|
|
|
|
Consider an rtp receiver element. It uses 2 UDP input ports to
|
|
capture RTP and RTCP messages using UDP. These messages are
|
|
then processed by an rtpsession element, which will reorder, make
|
|
statistics, and generate the RTP and RTCP messages.
|
|
|
|
This element can be build from existing elements as shown in the
|
|
figure below.
|
|
|
|
+------------------------------------+
|
|
| rtpsrc |
|
|
| |
|
|
| +--------+ +---------+ |
|
|
| | udpsrc | | rtpsess | |
|
|
| | port1 --- ----------------
|
|
| +--------+ | | |
|
|
| +--------+ | | +---------+ |
|
|
| | udpsrc | | | | udpsink | |
|
|
| | port2 --- --- port3 | |
|
|
| +--------+ +---------+ +---------+ |
|
|
+------------------------------------+
|
|
|
|
The element has one output pad that contains the raw RTP data. This
|
|
pad will be connected to the next element that will decode the RTP
|
|
data. Since this pad is actually from the rtpsession element, there
|
|
has to be a way to expose this pad on the rtpsrc element.
|
|
|
|
|
|
Current implementation:
|
|
|
|
Version 0.8 creates a new GstGhostPad type that extends GstPad and has
|
|
a link to the real pad internally.
|
|
|
|
Any operation on a pad potentially requires to check if this pad is a
|
|
GhostPad and if so, follow the pointer to the real pad to perform the
|
|
pad operation.
|
|
|
|
|
|
Current problem:
|
|
|
|
- following the ghostpad to resolve the real pad adds code.
|
|
- operations on pads are not performed on the ghostpad but on the
|
|
real pad. This means:
|
|
- pads are not linked to a ghostpad but to the real pad. For
|
|
compound objects, the link is not really performed to the
|
|
pad of the compound element but with some internal pad.
|
|
- for state changes, it is hard to follow linked elements upstream
|
|
bacause pads enter bins to the real element.
|
|
|
|
|
|
Proposal:
|
|
|
|
- The pad still has one parent, the element that owns (has sinked) the
|
|
pad. the GST_OBJECT_PARENT() is the real parent.
|
|
|
|
- The pad receives a GList of ghostparents. Ghostparents are sorted by depth.
|
|
|
|
- When a pad is ghostparented to another element, the element is added to
|
|
the ghostparent list of the pad. The pad is added to the padlist of the
|
|
element.
|
|
|
|
- A pad cannot be ghostparented to an element that is not a parent of the
|
|
pad parent element. this ensures that all ghostpads do not skip an hierarchy.
|
|
|
|
- When a pad is removed from the parent element, it is also removed from all
|
|
the ghostparents. This is easy to do as you can follow the ghostparent list of
|
|
that pad.
|
|
|
|
- When an element is removed from another element, all the elements pads
|
|
ghostparented to parents of the element are removed as well. This is easy
|
|
to do with the sorted ghostparent list of the pad.
|
|
|
|
|
|
Consequences:
|
|
|
|
- All pads are Real pads.
|
|
- All operations are performed on the real pads. This improves performance
|
|
and code simplicity
|
|
- more checks can be done. Linking nested elements can be done sanely.
|
|
compount elements that expose usable pads must ghostpad them before they
|
|
can be linked.
|
|
- All linked pads have a common grandparent.
|
|
|
|
|
|
Issues:
|
|
|
|
- Name of ghostpad cannot be changed and is the name of the element. This could
|
|
be solved by temporarily renaming the pad when ghostpadding. This could then
|
|
again result in the element being confused about the padnames or the
|
|
element having two pads with the same name.
|
|
|
|
|
|
|