|author||Zaheer Abbas Merali <firstname.lastname@example.org>||2010-07-24 21:39:54 (GMT)|
|committer||Zaheer Abbas Merali <email@example.com>||2010-07-24 21:39:54 (GMT)|
|commit||c00cd43e8bc1ec6f87e82f81c7cbd84426b73056 (patch) (side-by-side diff)|
cpureport: remove bogus docs
1 files changed, 0 insertions, 44 deletions
diff --git a/gst/debugutils/cpureport.c b/gst/debugutils/cpureport.c
index 460d467..a528769 100644
@@ -17,50 +17,6 @@
* Boston, MA 02111-1307, USA.
- * SECTION:element-progressreport
- * The progressreport element can be put into a pipeline to report progress,
- * which is done by doing upstream duration and position queries in regular
- * (real-time) intervals. Both the interval and the prefered query format
- * can be specified via the #GstCpuReport:update-freq and the
- * #GstCpuReport:format property.
- * Element messages containing a "progress" structure are posted on the bus
- * whenever progress has been queried (since gst-plugins-good 0.10.6 only).
- * Since the element was originally designed for debugging purposes, it will
- * by default also print information about the current progress to the
- * terminal. This can be prevented by setting the #GstCpuReport:silent
- * property to %TRUE.
- * This element is most useful in transcoding pipelines or other situations
- * where just querying the pipeline might not lead to the wanted result. For
- * progress in TIME format, the element is best placed in a 'raw stream'
- * section of the pipeline (or after any demuxers/decoders/parsers).
- * Three more things should be pointed out: firstly, the element will only
- * query progress when data flow happens. If data flow is stalled for some
- * reason, no progress messages will be posted. Secondly, there are other
- * elements (like qtdemux, for example) that may also post "progress" element
- * messages on the bus. Applications should check the source of any element
- * messages they receive, if needed. Finally, applications should not take
- * action on receiving notification of progress being 100%, they should only
- * take action when they receive an EOS message (since the progress reported
- * is in reference to an internal point of a pipeline and not the pipeline as
- * a whole).
- * <refsect2>
- * <title>Example launch line</title>
- * |[
- * gst-launch -m filesrc location=foo.ogg ! decodebin ! progressreport update-freq=1 ! audioconvert ! audioresample ! autoaudiosink
- * ]| This shows a progress query where a duration is available.
- * |[
- * gst-launch -m audiotestsrc ! progressreport update-freq=1 ! audioconvert ! autoaudiosink
- * ]| This shows a progress query where no duration is available.
- * </refsect2>