mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2025-02-23 14:36:24 +00:00
Code Issues 1 Projects Releases Wiki Activity

cpureport: remove bogus docs

Browse source
This commit is contained in:
Zaheer Abbas Merali 2010-07-24 22:39:54 +01:00
parent 961ab6d4b2
commit c00cd43e8b
1 changed files with 0 additions and 44 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
gst/debugutils/cpureport.c
View file

@ -17,50 +17,6 @@
* Boston, MA 02111-1307, USA. * 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>
*/
#ifdef HAVE_CONFIG_H #ifdef HAVE_CONFIG_H
#include "config.h" #include "config.h"
#endif #endif