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双端队列效率更高。

回复

你的邮件地址不会被公开(Your email address will not be published.) Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>