Thank you, I'm going to do that and Dektec is also preparing a small log of what happening on the DTE-3114 side... Perhaps it is the way to treat the rtp packets on its side that causes the issue.
________________________________ De : [email protected] [mailto:[email protected]] De la part de BONNEAU Guy Envoyé : lundi 12 juillet 2010 17:22 À : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lostwhenLive555MediaServerstreamsforward Dektec DTE3114 You shouldn't try to modify the code of the library unless you find a bug. The library send the packets at the appropriate time following the RTP specification unless the OS timer resolution create an issue. The library does indeed call the sendPacketIfNecessary routine to send the packets. >From what I remember the library does a good job at computing the time when the Mpeg2 TS RTP packets are to be sent. I suggest you try to use the function gettimeofday() to log the time and the delay requested when nextTask() = envir().taskScheduler().scheduleDelayedTask(...) is called in function sendPacketIfNecessary() in file MultiFramedTPSink. Then log the time again with gettimeofday() in function MultiFramedRTPSink::sendNext. Then check check that you were called at the time requested by the library scheduler. If you are not then you know the problem is likely to be a timer resolution issue with the OS. This is how I was able to find my issue and find why the library was bursting the RTP packets. GB From: [email protected] [mailto:[email protected]] On Behalf Of Lambert Marc Sent: Monday, July 12, 2010 6:31 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 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 : [email protected] [mailto:[email protected]] 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 À : '[email protected]' 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
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
