From 6bbee3202a6e6df043f3d441a2bf4dbc25aae3d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Thu, 8 Feb 2007 11:09:15 +0000 Subject: [PATCH] gst/debug/progressreport.c: Some more docs. Original commit message from CVS: * gst/debug/progressreport.c: Some more docs. --- ChangeLog | 5 +++++ gst/debug/progressreport.c | 12 ++++++++++++ 2 files changed, 17 insertions(+) diff --git a/ChangeLog b/ChangeLog index 913b499dba..ed97179567 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2007-02-08 Tim-Philipp Müller + + * gst/debug/progressreport.c: + Some more docs. + 2007-02-07 Tim-Philipp Müller * docs/plugins/inspect/plugin-rtp.xml: diff --git a/gst/debug/progressreport.c b/gst/debug/progressreport.c index 0c59b1f5f0..2650a239ca 100644 --- a/gst/debug/progressreport.c +++ b/gst/debug/progressreport.c @@ -47,6 +47,18 @@ * 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). + * * Example launch line * *