Hi,<br><br>I am trying to figure out the H264 throughput speed of livemedia library. As I know, the library uses durationInMicroseconds in H264FUAFragmenter::afterGettingFrame, which finally passes the value to MultiFramedRTPSink::sendPacketIfNecessary() to determine the when to send next frame.<br>
(<br> struct timeval timeNow;<br> gettimeofday(&timeNow, NULL);<br> int uSecondsToGo;<br> if (fNextSendTime.tv_sec < timeNow.tv_sec<br> || (fNextSendTime.tv_sec == timeNow.tv_sec && fNextSendTime.tv_usec < timeNow.tv_usec)) {<br>
uSecondsToGo = 0; // prevents integer underflow if too far behind<br> } else {<br> uSecondsToGo = (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec);<br> }<br><br>
// Delay this amount of time:<br> nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo,<br> (TaskFunc*)sendNext, this);<br> <br>).<br>So I adjusted the value of durationInMicroseconds from 33 ms to 1 ms to observe how fast the library can stream a file. In the experiments, I chose a small 2MB file to eliminate the impacts of the hard drive (the library reads the file in memory before streaming). The average size of h264 frames is around 20KB. openRTSP is used as the client to receive the file. <br>
When the durationInMicroseconds goes to about 1 ms, a significant packet loss is observed (from the received file size by openRTSP). <br>Now the question is what cause the packet loss. Is the UDP over network (network or Linux can not handle it) or the library itself drops the RTP packet because the CPU can not process that fast (from the above fNextSendTime, timeNow, I believe a lots of delayed task events will set uSecondsToGo=0)? <br>
If I want to stream a file very fast and reasonably reliable, what is best direction to go?<br><br>Thanks for any comments.<br><br>Tao <br>