<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Correct. This is also what I found. The queue2 buffering
granularity is defined by the size of the buffers it receives. The
high watermark may be reached by 100 small or 2 big buffers.</p>
<p>However, I think a better approach would be to split up buffers.
In case of simple HTTP transfers, this is easy - just wrap
GstAdapter in an element, and let it produce equally-sized
buffers. This fixed size should initially be some default (4096
byte for example). Once the bitrate is known, uridecodebin could
recalculate this size to be based on said bitrate, so that these
output buffers represent the same playtime.</p>
<p><br>
</p>
<p>As for souphttpsrc's maximum block size, if the idea above is
implemented, then its block size can actually be set to a high
value, which can be somewhat beneficial for CPU usage (because
then souphttp does not push data downstream as often). The idea
above would generally make buffering more robust I think.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2016-09-27 12:30, Jonathan Miles
wrote:<br>
</div>
<blockquote
cite="mid:VI1PR0501MB2350FD44A9F56E130920A99CFACC0@VI1PR0501MB2350.eurprd05.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>After doing some investigating I've discovered that, as well
as the poor estimate of the buffer size, souphttpsrc can make
matters worse. </p>
<p><br>
</p>
<p>souphttpsrc increases its blocksize to receive as much data
as possible from the server in a single transfer (see <span>gstsouphttpsrc.c::</span><span>gst_soup_http_src_check_update_blocksize()). </span><span
style="font-size: 12pt;">This </span><span style="font-size:
12pt;">sets the size of the buffers souphttpsrc </span><span
style="font-size: 12pt;">sends to queue2. As blocksize </span><span
style="font-size: 12pt;">approaches the queue2 buffer size,
you have fewer buffers in the queue. In the worst case there
is only one large buffer in the queue so it toggles between
empty and full.</span></p>
<p><br>
</p>
<p>Should uridecodebin be coordinating soupthttpsrc's maximum
blocksize to match queue2's buffer size?</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
color="#000000" face="Calibri, sans-serif"><b>From:</b>
gstreamer-devel
<a class="moz-txt-link-rfc2396E" href="mailto:gstreamer-devel-bounces@lists.freedesktop.org"><gstreamer-devel-bounces@lists.freedesktop.org></a> on
behalf of Carlos Rafael Giani <a class="moz-txt-link-rfc2396E" href="mailto:dv@pseudoterminal.org"><dv@pseudoterminal.org></a><br>
<b>Sent:</b> 05 September 2016 09:36:59<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<b>Subject:</b> Re: Audio dropouts that disappear when queue2
logging is enabled</font>
<div> </div>
</div>
<div>Yes, it is. This was just a test to confirm my suspicions.<br>
<br>
The fundamental problem here is that uridecodebin tries to
calculate a buffer size based on the bitrate, but does this only
once. Also, I guess the initial buffer size here of 352827 bytes
might be a tad too low as well. And keep in mind that
downstream's behavior also influences the buffering progress. If
you see buffering percentage reverting back to somewhere around
0-5% sometimes, then this is because downstream just consumed
data and emptied the queue. In some extreme cases, this can lead
to pipelines that reach the PLAYING state, only for their queue2
element to suddenly get emptied again, dropping back to PAUSED
state.<br>
<br>
I posted a proof-of-concept patch here: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugzilla.gnome.org/show_bug.cgi?id=762125">
https://bugzilla.gnome.org/show_bug.cgi?id=762125</a> though
it is somewhat outdated now (I have ideas for better solutions
for the documented problems).<br>
<br>
<div class="moz-cite-prefix">On 2016-09-04 20:13, Jonathan Miles
wrote:<br>
</div>
<blockquote
cite="mid:VI1PR0501MB235009FDEDA4F80B81AE78B9FAE70@VI1PR0501MB2350.eurprd05.prod.outlook.com"
type="cite">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>That stops the rebuffering, and souphttpsrc is getting a
change to refill the buffer before queue2 is drained.</p>
<p><br>
</p>
<p>Once the pipeline is into its stride:</p>
<p><br>
</p>
<div>0:03:09.196031856 12635 0x284d50 INFO
queue2
gstqueue2.c:2447:gst_queue2_locked_dequeue:<queue2-0>
cur_level.bytes=3892256</div>
<div>0:03:09.198157856 12635 0x3f58c0 INFO
queue2
gstqueue2.c:2328:gst_queue2_locked_enqueue:<queue2-0>
cur_level.bytes=4840136</div>
<div>0:03:09.244743939 12635 0x3f58c0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1640:gst_soup_http_src_read_buffer:<source>
Read 977352 bytes from http input</div>
<div>0:03:09.246352481 12635 0x3f58c0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1744:gst_soup_http_src_create:<source>
Returning 0 ok</div>
<br>
<p>Isn't 4MB a bit over the top <span style="font-size:
12pt;">for a 16/44.1 FLAC file?</span></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
color="#000000" face="Calibri, sans-serif"><b>From:</b>
gstreamer-devel
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:gstreamer-devel-bounces@lists.freedesktop.org">
<gstreamer-devel-bounces@lists.freedesktop.org></a>
on behalf of Carlos Rafael Giani
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:dv@pseudoterminal.org"><dv@pseudoterminal.org></a><br>
<b>Sent:</b> 03 September 2016 16:17:43<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:gstreamer-devel@lists.freedesktop.org">
gstreamer-devel@lists.freedesktop.org</a><br>
<b>Subject:</b> Re: Audio dropouts that disappear when
queue2 logging is enabled</font>
<div> </div>
</div>
<div>How is the pipeline behavior with this? gst-launch-1.0
uridecodebin uri=<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="http://10.0.1.120:50002/m/NDLNA/396487.flac">"http://10.0.1.120:50002/m/NDLNA/396487.flac"</a>
buffer-size=4000000 buffer-duration=0 ! audioconvert !
audioresample ! autoaudiosink<br>
<br>
<div class="moz-cite-prefix">On 2016-09-03 11:53, Jonathan
Miles wrote:<br>
</div>
<blockquote
cite="mid:VI1PR0501MB235063CDA4BC23616E1DB144FAE40@VI1PR0501MB2350.eurprd05.prod.outlook.com"
type="cite">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Thanks for your help.</p>
<p><br>
</p>
<p>Here's the pipeline image: <a moz-do-not-send="true"
href="http://imgur.com/a/WV5DF" class="OWAAutoLink"
id="LPlnk191881">http://imgur.com/a/WV5DF</a></p>
<p><span style="font-size: 12pt;">For the sake of
completeness, here's the the drop-out
(PLAYING->PAUSED): </span><a
moz-do-not-send="true"
href="http://imgur.com/a/dBnhq" class="OWAAutoLink"
id="LPlnk649215" style="font-size: 12pt;">http://imgur.com/a/dBnhq</a><br>
</p>
<p><span style="font-size: 12pt;">And restart
(PAUSED->PLAYING): <a moz-do-not-send="true"
href="http://imgur.com/a/IqMoU"
class="OWAAutoLink" id="LPlnk837712">http://imgur.com/a/IqMoU</a></span></p>
<p><br>
</p>
<p>Assuming I'm looking at the right part of
uridecodebin, here's the queue size set-up:</p>
<p><br>
</p>
<div>0:00:03.801279251 786 0x28af50 DEBUG
uridecodebin
gsturidecodebin.c:1110:decoded_pad_event_probe:<decodebin0:src_0>
found bitrate 0 </div>
<div>0:00:03.892754459 786 0x28af50 DEBUG
uridecodebin
gsturidecodebin.c:1110:decoded_pad_event_probe:<decodebin0:src_0>
found bitrate 1411429</div>
<div>0:00:03.899845626 786 0x28af50 DEBUG
uridecodebin
gsturidecodebin.c:1065:configure_stream_buffering:<uridecodebin0>
overall bitrate 1411429</div>
<div>0:00:03.915355626 786 0x28af50 DEBUG
uridecodebin
gsturidecodebin.c:1077:configure_stream_buffering:<uridecodebin0>
queue buffering time 0:00:02.000000000</div>
<div>0:00:03.917613084 786 0x28af50 DEBUG
uridecodebin
gsturidecodebin.c:1080:configure_stream_buffering:<uridecodebin0>
corresponds to buffer size 352857</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000" face="Calibri,
sans-serif"><b>From:</b> gstreamer-devel
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:gstreamer-devel-bounces@lists.freedesktop.org">
<gstreamer-devel-bounces@lists.freedesktop.org></a> on behalf of
Carlos Rafael Giani
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dv@pseudoterminal.org">
<dv@pseudoterminal.org></a><br>
<b>Sent:</b> 02 September 2016 19:29:58<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:gstreamer-devel@lists.freedesktop.org">
gstreamer-devel@lists.freedesktop.org</a><br>
<b>Subject:</b> Re: Audio dropouts that disappear when
queue2 logging is enabled</font>
<div> </div>
</div>
<div>Can you also produce a dot dump? Just run the
gst-launch line with the GST_DEBUG_DUMP_DOT_DIR
environment variable set to "." or "/tmp/". In that
directory, GStreamer will then generate a bunch of .dot
files. Pick the one with "PAUSED_PLAYING" in its
filename, convert it to PNG with the dot tool (dot -Tpng
-o dot-dump.png <filename.dot>), and put it on
Imgur.<br>
<br>
It is possible that the maximum internal queue2 size is
too small. I've had this problem with FLAC before. The
two most common reasons for this (which I've observed)
were: (1) queue2 figured out a size that is too low
because it looked at the incoming data rate, which just
happened to be low at this moment (2) uridecodebin got a
bogus bitrate from the FLAC parser that is way too low
(can happen with FLACs that start with silence), so it
calculates a small size based on that.<br>
<br>
<div class="moz-cite-prefix">On 2016-09-02 17:05,
Jonathan Miles wrote:<br>
</div>
<blockquote
cite="mid:VI1PR0501MB235052587BA3C6568C43EC59FAE50@VI1PR0501MB2350.eurprd05.prod.outlook.com"
type="cite">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<div>Here's the info from the identity element:</div>
<div><br>
</div>
<div>/GstPipeline:pipeline0/GstIdentity:identity0:
last-message = chain ******* (identity0:sink)
(18432 bytes, dts: none, pts: 0:00:51.408979591,
duration: 0:00:00.104489796, offset: -1,
offset_end: -1, flags: 00000000 ) 0xb4180df8</div>
<div>/GstPipeline:pipeline0/GstIdentity:identity0:
last-message = chain ******* (identity0:sink)
(18432 bytes, dts: none, pts: 0:00:51.513469387,
duration: 0:00:00.104489796, offset: -1,
offset_end: -1, flags: 00000000 ) 0xb4f2ec10</div>
<div>Buffering, setting pipeline to PAUSED ...</div>
<div>Done buffering, setting pipeline to PLAYING ...</div>
<div>/GstPipeline:pipeline0/GstIdentity:identity0:
last-message = chain ******* (identity0:sink)
(18432 bytes, dts: none, pts: 0:00:51.617959183,
duration: 0:00:00.104489796, offset: -1,
offset_end: -1, flags: 00000000 ) 0xb4f12200</div>
<div>/GstPipeline:pipeline0/GstIdentity:identity0:
last-message = chain ******* (identity0:sink)
(18432 bytes, dts: none, pts: 0:00:51.722448979,
duration: 0:00:00.104489796, offset: -1,
offset_end: -1, flags: 00000000 ) 0xb4f2e990</div>
<div>/GstPipeline:pipeline0/GstIdentity:identity0:
last-message = chain ******* (identity0:sink)
(18432 bytes, dts: none, pts: 0:00:51.826938775,
duration: 0:00:00.104489796, offset: -1,
offset_end: -1, flags: 00000000 ) 0xb43d18f0</div>
<br>
</div>
<hr style="display:inline-block;width:98%"
tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000"
face="Calibri, sans-serif"><b>From:</b>
gstreamer-devel
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:gstreamer-devel-bounces@lists.freedesktop.org">
<gstreamer-devel-bounces@lists.freedesktop.org></a> on behalf of
Carlos Rafael Giani
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:dv@pseudoterminal.org">
<dv@pseudoterminal.org></a><br>
<b>Sent:</b> 02 September 2016 15:55:25<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:gstreamer-devel@lists.freedesktop.org">
gstreamer-devel@lists.freedesktop.org</a><br>
<b>Subject:</b> Re: Audio dropouts that disappear
when queue2 logging is enabled</font>
<div> </div>
</div>
<div>
<p>It is possible that downstream consumes the
entire buffered data in one go. Try this:</p>
<p><br>
</p>
<p>gst-launch-1.0 -v uridecodebin uri=<a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="http://10.0.1.120:50002/m/NDLNA/396487.flac">"http://10.0.1.120:50002/m/NDLNA/396487.flac"</a>
! identity silent=false ! audioconvert !
audioresample ! autoaudiosink<br>
</p>
<p><br>
</p>
<p>Then you'll get lines from the identity element
which tell you about the size of the passing
buffers. Paste a few of those lines here.<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2016-09-02 16:39,
Jonathan Miles wrote:<br>
</div>
<blockquote
cite="mid:VI1PR0501MB2350A64C9A6A1AF017BB68BFFAE50@VI1PR0501MB2350.eurprd05.prod.outlook.com"
type="cite">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Tweaking the logging, I'm seeing the
following dance between queue2 and
souphttpsrc:</p>
<p><br>
</p>
<div>Done buffering, setting pipeline to PLAYING
...</div>
<div>0:00:20.721441002 3095 0x286150 INFO
queue2
gstqueue2.c:2447:gst_queue2_locked_dequeue:<queue2-0>
cur_level.bytes=0</div>
<div>0:00:20.721910210 3095 0x286150 INFO
queue2
gstqueue2.c:1070:gst_queue2_get_buffering_message:<queue2-0>
Going to post buffering: 0%</div>
<div>0:00:20.723109877 3095 0x3f6ac0 INFO
queue2
gstqueue2.c:2328:gst_queue2_locked_enqueue:<queue2-0>
cur_level.bytes=886192</div>
<div>buffering... 0%</div>
<div>Buffering, setting pipeline to PAUSED ...</div>
<div>0:00:20.731298335 3095 0x3f6ac0 INFO
queue2
gstqueue2.c:1070:gst_queue2_get_buffering_message:<queue2-0>
Going to post buffering: 100%</div>
<div>0:00:20.795157794 3095 0x3f6ac0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1640:gst_soup_http_src_read_buffer:<source>
Read 947616 bytes from http input</div>
<div>0:00:20.797286460 3095 0x3f6ac0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1744:gst_soup_http_src_create:<source>
Returning 0 ok</div>
<div>buffering... 100%</div>
<div>Done buffering, setting pipeline to PLAYING
...</div>
<div>0:00:26.157894003 3095 0x286150 INFO
queue2
gstqueue2.c:2447:gst_queue2_locked_dequeue:<queue2-0>
cur_level.bytes=0</div>
<div>0:00:26.158368253 3095 0x286150 INFO
queue2
gstqueue2.c:1070:gst_queue2_get_buffering_message:<queue2-0>
Going to post buffering: 0%</div>
<div>0:00:26.159438128 3095 0x3f6ac0 INFO
queue2
gstqueue2.c:2328:gst_queue2_locked_enqueue:<queue2-0>
cur_level.bytes=947616</div>
<div>buffering... 0%</div>
<div>Buffering, setting pipeline to PAUSED ...</div>
<div>0:00:26.165946669 3095 0x3f6ac0 INFO
queue2
gstqueue2.c:1070:gst_queue2_get_buffering_message:<queue2-0>
Going to post buffering: 100%</div>
<div>0:00:26.230684461 3095 0x3f6ac0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1640:gst_soup_http_src_read_buffer:<source>
Read 947896 bytes from http input</div>
<div>0:00:26.232809503 3095 0x3f6ac0 DEBUG
souphttpsrc
gstsouphttpsrc.c:1744:gst_soup_http_src_create:<source>
Returning 0 ok</div>
<div>buffering... 100%</div>
<div>Done buffering, setting pipeline to PLAYING
...</div>
<p><br>
</p>
<p>It looks like queue2 is sending the
"buffering 0%" message before souphttpsrc has
had a chance to re-fill the queue.</p>
<p><br>
</p>
<p>Some more info on my set-up</p>
<p><br>
</p>
<p> - Building from git master</p>
<p> - Crossed compiled for ARM</p>
<p> - Running on an ARM AM335x (like a Beagle
Bone)</p>
<p> - Linux 3.8.11 - no kernel pre-emption
enabled</p>
</div>
<hr style="display:inline-block;width:98%"
tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000"
face="Calibri, sans-serif"><b>From:</b>
gstreamer-devel
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:gstreamer-devel-bounces@lists.freedesktop.org">
<gstreamer-devel-bounces@lists.freedesktop.org></a> on behalf of
Jonathan Miles <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:jonathan.miles@cambridgeaudio.com">
<jonathan.miles@cambridgeaudio.com></a><br>
<b>Sent:</b> 02 September 2016 11:57:55<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:gstreamer-devel@lists.freedesktop.org">
gstreamer-devel@lists.freedesktop.org</a><br>
<b>Subject:</b> Audio dropouts that disappear
when queue2 logging is enabled</font>
<div> </div>
</div>
<div>
<div id="divtagdefaultwrapper"
style="font-size:12pt; color:#000000;
background-color:#FFFFFF;
font-family:Calibri,Arial,Helvetica,sans-serif">
<div>While playing a FLAC file from a Synology
NAS, I'm getting audio dropouts as a result
of re-buffering:</div>
<div><br>
</div>
<div>
<div>~ # gst-launch-1.0 playbin uri=<a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="http://10.0.1.120:50002/m/NDLNA/396487.flac">"http://10.0.1.120:50002/m/NDLNA/396487.flac"</a></div>
<div>Setting pipeline to PAUSED ...</div>
<div>Pipeline is PREROLLING ...</div>
<div>WARNING: from element
/GstPlayBin:playbin0/GstPlaySink:playsink:
No volume control found</div>
<div>Additional debug info:</div>
<div>/home/jonathanm/build/v010-a/build-glibc-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gstreamer1.0-plugins-base/git-r0/git/gst/playback/gstplaysink.c(2857):
gen_audio_chain ():
/GstPlayBin:playbin0/GstPlaySink:playsink:</div>
<div>Volume/mute is not available</div>
<div>Redistribute latency...</div>
<div>Pipeline is PREROLLED ...</div>
<div>Setting pipeline to PLAYING ...</div>
<div>New clock: GstAudioSinkClock</div>
<div>Buffering, setting pipeline to PAUSED
...</div>
<div>Done buffering, setting pipeline to
PLAYING ...</div>
<div>Buffering, setting pipeline to PAUSED
...</div>
<div>Done buffering, setting pipeline to
PLAYING ...</div>
<div><br>
</div>
If I enable queue2 debugging
(GST_DEBUG="queue2:5"), the audio drop-outs
disappear, as the pipeline doesn't get set
to PAUSED, although it looks like the
rebuffering is still happening:</div>
<div><br>
</div>
<div>
<div>0:00:32.967181462 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:842:apply_buffer:<queue2-0>
position updated to 0:00:00.000000000</div>
<div>0:00:32.967705879 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:740:update_time_level:<queue2-0>
sink 0:00:00.000000000, src
0:00:00.000000000</div>
<div>0:00:32.968154921 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:1221:update_out_rates:<queue2-0>
rates: period 5.950074, out 1048576</div>
<div>0:00:32.968559296 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:1239:update_out_rates:<queue2-0>
rates: out 266973.567011, time
0:00:00.000000000</div>
<div>0:00:32.969009754 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:1199:update_in_rates:<queue2-0>
rates: in 1361330.412743, time
0:00:00.000000000</div>
<div>0:00:32.969451212 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:1004:get_buffering_level:<queue2-0>
buffering 0, level 0</div>
<div>0:00:32.969777004 1648 0x2cfb50
DEBUG queue2
gstqueue2.c:1122:update_buffering:<queue2-0>
buffering 0 percent</div>
<div>0:00:32.972558504 1648 0x4408c0
DEBUG queue2
gstqueue2.c:842:apply_buffer:<queue2-0>
position updated to 0:00:00.000000000</div>
<div>0:00:32.973054296 1648 0x4408c0
DEBUG queue2
gstqueue2.c:740:update_time_level:<queue2-0>
sink 0:00:00.000000000, src
0:00:00.000000000</div>
<div>0:00:32.973499504 1648 0x4408c0
DEBUG queue2
gstqueue2.c:1199:update_in_rates:<queue2-0>
rates: in 1361330.412743, time
0:00:00.779502162</div>
<div>0:00:32.973981379 1648 0x4408c0
DEBUG queue2
gstqueue2.c:1199:update_in_rates:<queue2-0>
rates: in 1361330.412743, time
0:00:00.779502162</div>
<div>0:00:32.974428254 1648 0x4408c0
DEBUG queue2
gstqueue2.c:1004:get_buffering_level:<queue2-0>
buffering 1, level 1000000</div>
<div>0:00:32.974764921 1648 0x4408c0
DEBUG queue2
gstqueue2.c:1116:update_buffering:<queue2-0>
buffering 100 percent</div>
<div>0:00:32.975315546 1648 0x4408c0
DEBUG queue2
gstqueue2.c:1070:gst_queue2_get_buffering_message:<queue2-0>
Going to post buffering: 100%</div>
<div>Done buffering, setting pipeline to
PLAYING ...</div>
<br>
</div>
<div>Anyone got any ideas as to what might be
going here?</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Jonathan</div>
</div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey
Place, London SE1 4BB, UK Reg No. 2953313 This
e-mail is confidential and for the addressee
only. Please refer to
<a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer"
target="_blank">
Disclaimer</a> for important notices. </div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey
Place, London SE1 4BB, UK Reg No. 2953313 This
e-mail is confidential and for the addressee only.
Please refer to
<a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer"
target="_blank">
Disclaimer</a> for important notices. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey Place,
London SE1 4BB, UK Reg No. 2953313 This e-mail is
confidential and for the addressee only. Please refer
to
<a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer"
target="_blank">
Disclaimer</a> for important notices. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey Place, London
SE1 4BB, UK Reg No. 2953313 This e-mail is confidential
and for the addressee only. Please refer to
<a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer"
target="_blank">
Disclaimer</a> for important notices. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey Place, London SE1
4BB, UK Reg No. 2953313 This e-mail is confidential and for
the addressee only. Please refer to
<a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer"
target="_blank">
Disclaimer</a> for important notices. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>
<br>
Audio Partnership PLC, Gallery Court, Hankey Place, London SE1
4BB, UK Reg No. 2953313
This e-mail is confidential and for the addressee only. Please
refer to <a moz-do-not-send="true"
href="https://www.cambridgeaudio.com/disclaimer" target="_blank">Disclaimer</a>
for important notices. <br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>