live555经典代码分析（live555性能优化）

今天给各位分享live555经典代码分析的知识，其中也会对live555性能优化进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、在Linux环境下如何调试live555
• 2、live555 input frame data was too large是问题么
• 3、live555的性能不给力,该怎么处理

在Linux环境下如何调试live555

（1）先下载live555的源码如：live.2011.06.14a.tar.gz（2）解压源码tar -zxvf live.2011.06.14a.tar.gz（3）cd live（4）./genMakefiles linux-gdb（5）make经过以上步骤生成的live555MediaServer可以用于gdb调试，如果要使源代码中的DEBUG宏有效，还需要修改live/config.linux-gdb文件，在COMPILE_OPTS一行中添加-DDEBUG即可。

live555 input frame data was too large是问题么

看一下这个函数：

源码打印？

Boolean MediaSink::startPlaying(MediaSource source,

afterPlayingFunc* afterFunc, void* afterClientData)

{

//参数afterFunc是在播放结束时才被调用。

// Make sure we're not already being played:

if (fSource != NULL) {

envir().setResultMsg("This sink is already being played");

return False;

}

// Make sure our source is compatible:

if (!sourceIsCompatibleWithUs(source)) {

envir().setResultMsg(

"MediaSink::startPlaying(): source is not compatible!");

return False;

}

//记下一些要使用的对象

fSource = (FramedSource*) source;

fAfterFunc = afterFunc;

fAfterClientData = afterClientData;

return continuePlaying();

}

为了进一步封装（让继承类少写一些代码），搞出了一个虚函数continuePlaying()。让我们来看一下：

可以看到为了延迟包的发送，使用了delay task来执行下次打包发送任务。

sendNext()中又调用了buildAndSendPacket()函数，呵呵，又是一个圈圈。

总结一下调用过程：

最后，再说明一下包缓冲区的使用：

MultiFramedRTPSink中的帧数据和包缓冲区共用一个，只是用一些额外的变量指明缓冲区中属于包的部分以及属于帧数据的部分（包以外的数据叫做overflow data）。它有时会把overflow data以mem move的方式移到包开始的位置，有时把包的开始位置直接设置到overflow data开始的地方。那么这个缓冲的大小是怎样确定的呢？是跟据调用者指定的的一个最大的包的大小+60000算出的。这个地方把我搞胡涂了：如果一次从source获取一个帧的话，那这个缓冲应设为不小于最大的一个帧的大小才是，为何是按包的大小设置呢？可以看到，当缓冲不够时只是提示一下：

live555的性能不给力,该怎么处理

我在开发板上移植了live555MediaServer，可以实现正常的传输。但似乎性能很不高，当进行16路D1的数据传输时，系统从硬盘上读取视频文件，CPU的idle时间几乎为0，以下是我用top命令看到的系统性能：

Live555MediaServer 进程占用CPU-- 50%

用户态时间: 17%

内核态时间: 23%

idle时间： 0%

io时间 ： 50%

如此，还没运行其他应用，CPU就已经被全部占满了，显然无法工作。

各位帮帮忙，告诉我有没有改进的方法(代码最好)，或者其他的替代live555的方案(除了gstreamer)

------解决方案--------------------------------------------------------

提高硬盘IO的效率，你不妨做个测试，只是硬盘读取38M数据看看占用多少cpu。

如果确认是IO的问题，不妨尝试采用dio来提高读取的效率。

可参考 基于Linux的Socket网络编程的性能优化。 我以前就对live555的接收模块做了优化，CPU占用小30%。

关于live555经典代码分析和live555性能优化的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。