Live555性能优化实践

网上很多文章提到了Live555的单线程任务调度模式，在用作RTSP服务时，导致了在并发量较多或者磁盘性能不佳时会导致性能较差，并发数受限。笔者通过在做基于海思3531编码器和解码器的过程当中（提供基于2路H264+1路AAC的TS流编码（输入为RTSP TS流)和RTSP流媒体解码播放)，有以下2点收获，特分享给有需要的同仁。

优化1：同步读取数据源修改为异步读取数据源， FramedSource的子类的doGetNextFrame函数中不要阻塞等待数据源， 在无数据时可以重新增加一个定时器任务，延时再读取数据。在无数据时增加一个等待任务：

void MyFramedSource :: doGetNextFrame ( )
{
    if (无数据可读 ) { //延时3000微妙（3毫秒)再次读取数据
     envir ( ). taskScheduler ( ). scheduleDelayedTask ( 3000, (TaskFunc * )DelayReadFrame, this ) ;
      return ;
    }
    .....省略其他正常逻辑
}

static void MyFramedSource :: DelayReadFrame (FramedSource *sourc )
{
     source - >doGetNextFrame ( ) ;
}

优化2： 定时器的内存分配管理可以通过内存池来管理，重复利用。而不需要重复分配和释放。可以想象一下，一个30帧每秒的H264视频+40多帧每秒的AAC音频，定时器的内存分配和释放的次数是70次每秒。完整代码我就不贴了，摘录一段关键代码，从已分配内存上new一个定时器类的对象我附在下面代码中，可参考代码中的注释：

TaskToken BasicTaskScheduler0 :: scheduleDelayedTask ( int64_t microseconds,
                         TaskFunc * proc,
                          void * clientData ) {
  if (microseconds < 0 ) microseconds = 0 ;
  DelayInterval timeToDelay ( ( long ) (microseconds / 1000000 ), ( long ) (microseconds % 1000000 ) ) ;
  //从内存池fPool中分配一块内存
  void *alarmMemory = fPool. malloc ( sizeof (AlarmHandler ) ) ;
 
//从已分配内存上，构造一个AlarmHandler定时器处理对象
  AlarmHandler * alarmHandler = new (alarmMemory ) AlarmHandler (proc, clientData, timeToDelay ) ;
  fDelayQueue - >addEntry (alarmHandler ) ;

  return ( void * ) (alarmHandler - >token ( ) ) ;
}

在Live555中，凡是分配定时器的地方，用上述代码替换，凡是delete AlarmHandler对象的地方，调用fPool.free(alarmHandler )即可回收内存再使用。fPool用一个无锁的队列即可（Live555是单线程工作模式）， 当然如果用STL的deque双端队列效率更高。

转自：http://www.mworkbox.com/wp/work/614.html