網上很多文章提到了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();
}
 

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());
}