<!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 packet lost when
Live555MediaServer s</title></head><body>
<blockquote type="cite" cite><font face="Arial" size="-1">I captured
with Wireshark and there is a difference between the 2 streaming
methodes, the Qvidium seems to allow more time before to
send the next frame and the frame is composed of many UDP packet when
Live555 try to gather perfectly the packets during the time and I
guess it is stressing too much the DTE-3114 to treat this bandwidth on
the fly.</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Then, I
would like to know if it is possible to change the way to send packet
on the network to try to make my test bench
working.</font></blockquote>
<div><br></div>
<div>Yes, perhaps - although I'm a bit surprised that our server is
behaving in the way that you describe, so I suggest that you first try
to investigate some more why this is happening.</div>
<div><br></div>
<div>The code that determines the time gap between successive groups
of 188-byte Transport Stream 'packets' that make up a network packet
is in "liveMedia/MPEG2TransportStreamFramer.cpp", line 147:
The calcuation of "fDurationInMicroseconds". This
calculation is a running estimate, based on the PCR timestamps seen in
the Transport Stream data.</div>
<div><br></div>
<div>The value of "fDurationInMicroseconds" is then used by
the RTP streaming code ("MultiFramedRTPSink") to figure out
how long to wait before sending each outgoing network packet.</div>
<div><br></div>
<div>So, if you wanted to change the time gaps between successive
network packets, you would do so by (somehow) changing the calculation
of "fDurationInMicroseconds" in the
"MPEG2TransportStreamFramer" class. But, as I noted
above, I suggest that - before diving in to chage this code - you
first try to figure out why the current code is producing the behavior
that you're seeing. Perhaps there's something strange about your
data's PCR timestamps that is causing this??</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><br>
Ross Finlayson<br>
Live Networks, Inc.<br>
http://www.live555.com/</div>
</body>
</html>