gst/debug/progressreport.c: Some more docs.
authorTim-Philipp Müller <tim@centricular.net>
Thu, 8 Feb 2007 11:09:15 +0000 (11:09 +0000)
committerTim-Philipp Müller <tim@centricular.net>
Thu, 8 Feb 2007 11:09:15 +0000 (11:09 +0000)
Original commit message from CVS:
* gst/debug/progressreport.c:
Some more docs.

ChangeLog
gst/debug/progressreport.c

index 913b499..ed97179 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2007-02-08  Tim-Philipp Müller  <tim at centricular dot net>
+
+       * gst/debug/progressreport.c:
+         Some more docs.
+
 2007-02-07  Tim-Philipp Müller  <tim at centricular dot net>
 
        * docs/plugins/inspect/plugin-rtp.xml:
index 0c59b1f..2650a23 100644 (file)
  * progress in TIME format, the element is best placed in a 'raw stream'
  * section of the pipeline (or after any demuxers/decoders/parsers).
  * </para>
+ * <para>
+ * 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).
+ * </para>
  * <title>Example launch line</title>
  * <para>
  * <programlisting>