Sophie

Sophie

distrib > Mandriva > 10.0-com > i586 > by-pkgid > f0a9f2b9c81d34eadc43f527947c0b70 > files > 116

libgstreamer0.7-devel-0.7.4-2mdk.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>Pads</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="GStreamer Application Development Manual"
HREF="index.html"><LINK
REL="UP"
TITLE="Basic Concepts"
HREF="part-basic-concepts.html"><LINK
REL="PREVIOUS"
TITLE="Types of elements"
HREF="section-elements-types.html"><LINK
REL="NEXT"
TITLE="Capabilities of a pad"
HREF="section-caps.html"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
><SPAN
CLASS="application"
>GStreamer</SPAN
> Application Development Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="section-elements-types.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="section-caps.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="chapter-pads"
></A
>Chapter 5. Pads</H1
><P
>&#13;    As we have seen in <A
HREF="chapter-elements.html"
>Chapter 4</A
>, the pads are the element's
    interface to the outside world. 
  </P
><P
>&#13;    The specific type of media that the element can handle will be exposed by the pads.
    The description of this media type is done with capabilities(see
    <A
HREF="section-caps.html"
>Section 5.2</A
>)
  </P
><P
>&#13;    Pads are either source or sink pads.  The terminology is defined from the
    view of the element itself: elements accept data on their sink pads, and
    send data out on their source pads.  Sink pads are drawn on the left,
    while source pads are drawn on the right of an element.  In general,
    data flows from left to right in the graph.<A
NAME="AEN209"
HREF="#FTN.AEN209"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
>
  </P
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="section-pads-type"
>5.1. Types of pads</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="section-pads-dynamic"
>5.1.1. Dynamic pads</A
></H2
><P
> 
        Some elements might not have all of their pads when the element is
        created. This
        can happen, for example, with an MPEG system demultiplexer. The
        demultiplexer will create its pads at runtime when it detects the
        different elementary streams in the MPEG system stream.
      </P
><P
> 
        Running <SPAN
CLASS="application"
>gst-inspect mpegdemux</SPAN
> will show that
	the element has only one pad: a sink pad called 'sink'. The other pads are 
	"dormant".  You can see this in the pad template because there is
        an 'Exists: Sometimes'
	property. Depending on the type of MPEG file you play, the pads will
        be created. We
	will see that this is very important when you are going to create dynamic 
	pipelines later on in this manual.
      </P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="section-pads-request"
>5.1.2. Request pads</A
></H2
><P
> 
        An element can also have request pads. These pads are not created
        automatically but are only created on demand. This is very useful
        for multiplexers, aggregators and tee elements.
      </P
><P
> 
        The tee element, for example, has one input pad and a request padtemplate for the
	output pads. Whenever an element wants to get an output pad from the tee element, it 
	has to request the pad.
      </P
></DIV
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN209"
HREF="chapter-pads.html#AEN209"
><SPAN
CLASS="footnote"
>[1]</SPAN
></A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>&#13;        In reality, there is no objection to data flowing from a
        source pad to the sink pad of an element upstream.  Data will, however,
        always flow from a source pad of one element to the sink pad of
        another.
      </P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="section-elements-types.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="section-caps.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Types of elements</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="part-basic-concepts.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Capabilities of a pad</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>