基于live555实现的RTSPServer对底层进行性能优化的方法_live555源码分析respserver优化-CSDN博客

在博客《EasyIPCamera高性能摄像机RTSP服务器RTSPServer解决方案》我介绍了基于live555实现的一套RTSPServer功能组件，当时开发者经过几个月的调试，已经将底层的性能调试到了一个业界非常优秀的程度，主要优化的几点：

发送优化
调度优化

发送优化方面，主要就是调整live555的缓冲区大小和每次发送的数据大小，众所周知，流媒体发送的是各种大小的音视频数据，而这些数据大的几百k，小的就几个字节，如果每一个零散的数据都要走一遍发送循环，对于live555这种单线程的架构来说，性能吃紧，所以，我们做了几点调整：


RTPInterface.cpp

129行:
increaseSendBufferTo(envir(), fGS->socketNum(), 512*1024);

//数据累积发送，不再单独发送
//注释掉332行，修改为以下:
//if (!sendDataOverTCP(socketNum, framingHeader, 4, False)) break;
//if (!sendDataOverTCP(socketNum, packet, packetSize, True)) break;

    struct iovec iov[2];
    iov[0].iov_base = framingHeader;
    iov[0].iov_len = 4;
    iov[1].iov_base = packet;
    iov[1].iov_len = packetSize;
    writev(socketNum, iov, 2);

在调度方面的优化


402 行
//当前的数据缓冲区如果没有发送完成，就继续发送，不再走一遍live555的eventloop流程，提高效率！

#if 0
    // We have more frames left to send.  Figure out when the next frame
    // is due to start playing, then make sure that we wait this long before
    // sending the next packet.
    struct timeval timeNow;
    gettimeofday(&timeNow, NULL);
    int secsDiff = fNextSendTime.tv_sec - timeNow.tv_sec;
    int64_t uSecondsToGo = secsDiff*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec);
    if (uSecondsToGo < 0 || secsDiff < 0) { // sanity check: Make sure that the time-to-delay is non-negative:
      uSecondsToGo = 0;
    }

    if (uSecondsToGo > 0)
        printf("uSecondsToGo: %d\n", uSecondsToGo);

    // Delay this amount of time:
    nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this);
#else
    sendNext(this);
#endif

这样几点修改，大大提升了live555在网络数据发送方面的性能，使得在海思3516A这样的板子上，高清视频能提升到4路4M高清视频的发送，且很稳定（当然，网络一定要保证，大部分走wifi的测试都到不了这个效果）！

关于EasyIPCamera

EasyIPCamera是一套非常稳定、易用、支持多种平台（包括Windows/Linux 32&64，Android，ARM hisiv100/hisiv200/hisiv400等平台）的RTSP Server组件，适用于IPCamera、内网RTSP服务等小型RTSP流媒体服务器，接口调用非常简单成熟，无需关注RTSPServer中关于客户端监听接入、音视频多路复用、RTSP具体流程、RTP打包与发送等相关问题，支持多种音视频格式，再也不用像调用live555 RTSPServer那样处理整个RTSP OPTIONS/DESCRIBE/SETUP/PLAY/RTP/RTCP的复杂流程和担心内存释放的问题了！