[Live-devel] RTP packet lost when Live555MediaServer streams forward Dektec DTE3114

[Ross Finlayson]

>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.
>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.

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.

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.

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.

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??
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100710/0c9bf57f/attachment.html>