优化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是单线程工作模式),建议使用list或者queue 实现一个无锁内存池即可。
高码率视频数据传输的优化点
对高清高码率的视频画面,每一帧的视频数据就会比较大,这个数值往往会超出live555内部默认的内存处理大小,因为对于live555的优化,主要就是集中在内存缓冲大小的扩大,以及避免内存数据拷贝。以下为根据实际开发和测试所总结出来的有效的优化点:
- 扩展帧解析buffer大小,即BANK_SIZE,默认值为150k,根据传输的H264数据帧大小,至少设置为300k。否则超出大小,可能会被Live555抛弃。
- 增加OutPacketBuffer::maxSize大小,同样为了容纳超大帧数据,否则可能会导致数据丢失。
- 在RTPInterface中,增加socket发送缓冲区大小,即increaseSendBufferTo函数的参数值
- 对MultiFramedRTPSink::sendPacketIfNecessary中,可以直接调用sendNext尝试组建RTP报文发送数据包,这样修改的优点是已读取的数据会被尽快发送出去,不过也多占用一些线程时间。
- 对于应用程序将数据从自己的线程传递给Live555的时候,应该尽量减少内存拷贝,最好是通过内存池的形式,以避免拷贝内存阻塞Live555事件循环
- 另外live555是基于文件的直播流服务器,如果是修改为实时流直播则可以对基层读取数据逻辑进行优化。
参考文章链接: