[Gstreamer-bugs] [Bug 108268] Changed - [PATCH] -Add min threshold to queue for network streaming apps

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=108268

Changed by janzen at pixelmetrix.com.

--- shadow/108268	Thu May 29 18:36:11 2003
+++ shadow/108268.tmp.32754	Thu May 29 23:34:00 2003
@@ -97,6 +97,47 @@
 I've been running default apps with this for a while now, and I'm not
 really noticing any difference. This is good, because it means nothing
 breaks, but can you give some examples of where this has clear
 advantages over the old approach? Network streams? Something else?
 
 I'm basically in for applying this, unless someone objects.
+
+------- Additional Comments From janzen at pixelmetrix.com  2003-05-29 23:33 -------
+It's for streaming video/audio applications.
+
+If your input source is a file, DVD, etc., then it's true that the
+minimum threshold doesn't make a bit of difference, since the input
+source can fill the queue much faster than the data is needed.
+
+However, it's very useful in situations in which the input is being
+received at a more or less constant bit rate, eg. over a network via
+UDP or RTP.  In such cases it is necessary to allow the queue to fill
+to a minimum level before beginning playout, for two reasons:
+
+First, data will never be added to the queue at a perfectly constant
+rate, due to blocking (eg. multiple MPEG-2 transport stream packets in
+one UDP or RTP PDU), network jitter, scheduling latency on
+multitasking OSs, and so on.
+
+Second, data will not be removed from the queue at a constant rate
+either.  For example, when a video pipeline first begins to play, the
+gstmpeg2dec decoder (based on libmpeg2) will remove a great deal of
+data very quickly, throwing away everything until it finds the next
+MPEG-2 sequence header.  Even after that, the rate at which data is
+removed will still be quite bursty, since I-frames tend to be large
+while P- and B-frames are much smaller.
+
+Therefore, the application must try to keep the queue filled to a
+reasonable level.  If the queue ever empties completely, there will be
+unexpected delays while it refills, resulting in jerky video playback
+or in audio pops or dropouts.  (See the flashy ASCII art in the
+initial Bugzilla report.)
+
+The min-threshold-bytes attribute helps with this, since it allows the
+ queue to block the reader thread until a reasonable amount of data
+has been received.  It's only one part of the solution: the queue can
+still empty if the input rate and playout rate are different, for
+instance, as will happen if there are differences in clock speed
+between the encoder and the (GStreamer) decoder.  This needs to be
+addressed by the application, eg. using watermark-crossing signals
+from the queue to "tune" the mapping between MPEG-2 PCR values and the
+system time.  But that's another story...