<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Live-devel] RTP/RTSP Streaming
Trouble</title></head><body>
<blockquote type="cite" cite><font face="Arial" size="-1">I have a
test video file to you to use. It is located at</font> <a
href="file://ftp.gcsd.harris.com/public"><font face="Arial" size="-1"
color="#0000FF"><u>ftp.gcsd.harris.com/public</u></font></a><font
face="Arial" size="-1">, filename "live555_test_stream.ts".
This is a blind FTP server, therefore it will only accept requests for
exactly that filename. Also, I believe the policy is to remove
the files nightly, so please let me know if you need me to upload the
file again for your access. Hopefully you can reproduce what
I've been seeing.</font></blockquote>
<div><br></div>
<div>The problem with this file is that its PCR timestamps show that
it is *extremely* VBR - far more than any reasonable stream should
be. Because the streaming server uses these timestamps to figure
out how to pace the outgoing stream (i.e., how much to delay after
sending each network packet), extremely VBR timestamps messes up the
streaming.</div>
<div><br></div>
<div>More specifically, here's what's happening with your test
file:</div>
<div>As shown by its last timestamp, the stream is 37.78 seconds long,
and contains 285866 188-byte Transport Packets. Therefore, on
average, each Transport Packet should last about 132 ms. In
practice, however, the stream's durations vary widely from this
average.</div>
<div><br></div>
<div>E.g., here are the first few PCR timestamps</div>
<div>packet number<x-tab> </x-tab>diff from last<x-tab>
</x-tab>PCR timestamp<x-tab> </x-tab>diff from
last<x-tab> </x-tab>duration/packet</div>
<div>============<x-tab>
</x-tab>==========<x-tab>
</x-tab>============<x-tab>
</x-tab>==========<x-tab>
</x-tab>=============</div>
<div>132<x-tab>
</x-tab><x-tab>
</x-tab>132<x-tab>
</x-tab><x-tab>
</x-tab>0.002257<x-tab>
</x-tab><x-tab>
</x-tab>0.002257<x-tab>
</x-tab><x-tab> </x-tab>17
ms</div>
<div>197<x-tab>
</x-tab><x-tab>
</x-tab>65<x-tab>
</x-tab><x-tab>
</x-tab>0.002727<x-tab>
</x-tab><x-tab>
</x-tab>0.000470<x-tab>
</x-tab><x-tab> </x-tab>7
ms<x-tab> </x-tab></div>
<div>262<x-tab>
</x-tab><x-tab>
</x-tab>65<x-tab>
</x-tab><x-tab>
</x-tab>0.003187<x-tab>
</x-tab><x-tab>
</x-tab>0.000460<x-tab>
</x-tab><x-tab> </x-tab>7
ms</div>
<div>264<x-tab>
</x-tab><x-tab>
</x-tab>2<x-tab>
</x-tab><x-tab>
</x-tab>0.024481<x-tab>
</x-tab><x-tab>
</x-tab>0.021294<x-tab>
</x-tab><x-tab>
</x-tab>10647 ms</div>
<div>302<x-tab>
</x-tab><x-tab>
</x-tab>38<x-tab>
</x-tab><x-tab>
</x-tab>0.024754<x-tab>
</x-tab><x-tab>
</x-tab>0.000273<x-tab>
</x-tab><x-tab> </x-tab>7
ms</div>
<div>322<x-tab>
</x-tab><x-tab>
</x-tab>20<x-tab>
</x-tab><x-tab>
</x-tab>0.024896<x-tab>
</x-tab><x-tab>
</x-tab>0.000142<x-tab>
</x-tab><x-tab> </x-tab>7
ms</div>
<div>326<x-tab>
</x-tab><x-tab>
</x-tab>4<x-tab>
</x-tab><x-tab>
</x-tab>0.048253<x-tab>
</x-tab><x-tab>
</x-tab>0.023357<x-tab>
</x-tab><x-tab> </x-tab>5839
ms</div>
<div>454<x-tab>
</x-tab><x-tab>
</x-tab>128<x-tab>
</x-tab><x-tab>
</x-tab>0.049158<x-tab>
</x-tab><x-tab>
</x-tab>0.000905<x-tab>
</x-tab><x-tab> </x-tab>7
ms</div>
<div><br></div>
<div>I hope you get the picture. The extremely large jumps in
PCR timestamp are messing up our streaming server's estimate of how
much time to delay after sending each network packet.</div>
<div><br></div>
<div>I don't know whether you really intended this stream to be so
extremely VBR, but our server is currently not able to properly stream
files like this.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>