[Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114

[Lambert Marc]

I just tried to modify the fDurationInMicroseconds but it doesn't work.
Actually, It seems the task sends packet through "sendPacketIfNecessary" as soon as the packet is prepared when I would like to wait for 3 or 4 packets ready before to send them on the network.
I tried to find a way to skip to send data but when I do that, it seems also than the packet is lost...
 
It looks like the output buffer gathers frames and when there are enough frames to do a packet the RTP packet is done and sent, could I let prepare many packets and wait for few to effectively send them ?
 
 

________________________________

De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de BONNEAU Guy
Envoyé : dimanche 11 juillet 2010 05:51
À : LIVE555 Streaming Media - development & use
Objet : Re: [Live-devel] RTP packet lost when Live555MediaServerstreamsforward Dektec DTE3114



This  problem seems to be very similar to one I have had about 1 year ago while trying to stream a Mpeg2 TS with the live555 library with a very high datarate. Unfortunately I do not remember all the details but I eventually pinpointed the problem to the scheduler of Windows. (My testing application was Windows based). If a remember  the library would compute a delay to callback a routine to schedule a new RTP packet to be sent over the network. I believe that was done through a select or sleep() function. The computing of the delay was well done by the library. But the timer resolution of Windows is 15 or 10 ms by default and the requested delay in my case was much lower given the requested bitrate from the Mpeg2 TS stream. The jitter of the packets over the network was terrible and the library much of the time was trying to catch-up from the misbehavior of the Windows Timer default resolution of 15 ms by bursting the RTP packets over the network.

 

I solved that problem by using the TimeBeginPeriod(1) to change the Windows period of the timer to 1 ms. The callback function would then wakeup much faster and the jitter of the packets went down to an acceptable level.

 

Guy Bonneau

 

 

Just to complet my explaination, please find the 2 IO Graphs Qvidium vs Live555 rtp streaming.

 

Regards

 

________________________________

De : Lambert Marc 
Envoyé : vendredi 9 juillet 2010 15:35
À : 'live-devel at lists.live555.com'
Objet : RTP packet lost when Live555MediaServer streams forward Dektec DTE3114

Hello,

 

First of all, I'm certainly not the first to say that but thank you for this very nice software.

I use live555MediaServer in the context of my job and I compilled it with the option "RTSP_ALLOW_CLIENT_DESTINATION_SETTING" to make me able to control the server from a device connected on the network and to stream forward an IPtoTS modulator (DTE-3114 from Dektec) providing a DVB-C signal to a TV.

My client is working well and everything is working perfectly with VLC but...

When I replace VLC by the DTE-3114, the outgoing signal is not good with many RTP packet loss.

Then, I tryed to change many parameters on each sides but nothing is fixing that.

 

I also used the DTE-3114 with the QVidium file streamer (it doesn't have the rtsp server, just the rtp streamer) and, in that case, I succeed to stream perfectly until 25Mbps...

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.

 

Thank's in advance

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100712/ad308b41/attachment-0001.html>