硬件和软件环境是这样的：DM8168+linux，解码器是DM8168自带的视频来源：ipc通过live555做的的rtspsever发送过来的其他测试：通过VLC在pc连4路1080P没有问题，都挺流畅的；用之前一个项目中自己实现的RTSPclient连同样的1080p4路到6路都没有问题（只是那个占用内存太多了，才打算用live555重写）
live555rtspclient客户端大概如下：修改openRTSP，，使支持多个实例支持多个RTSPClient，其中env用的是同一个，也就是只有一个EventLoop，即单线程的；存在问题如下：当连3路1080P视频显示很流畅，帧率25，每1秒为周期的到来：0x67(sps)…0x68(pps)…0x65(IDR)…data；但连4路或4路以上1080P时，视频变得非常卡，发现sps和pps还是同期性的到来，但0x65却变得非常少，感觉应该是丢了。
————————————————————————————————————————————————————————
解决进度：
2015.06.09
今天看到这样一句话：
//playCommon.cpp/*NOTE: If you want to develop your own RTSP client application (or embed RTSP client functionality into your own application),then we don't recommend using this code as a model, because it is too complex (with many options).Instead, we recommend using the "testRTSPClient" application code as a model.*/
难道testRTSPClient比openRTSP性能高，但细想一下又不是那回事，流程都是一样的，只是配置项不一样；但总算还是有点希望的，抽点时间把testRTSPClient改一下应该不是什么难事。。
参考博文：
2015.06.08
对，一路到3路1080P都没有问题，只是4路或4路以上就不行了。还有昨天测试，尝试把socket缓冲区加大到10M测试发现在前大约1分钟里，视频流流畅，sps,pps,idr周期性的到来；但之后idr开始丢失，视频开始卡；猜测是10M的socket接收缓冲区满了之后，由于处理不过来导致新接收数据把之前的数据冲掉了，导致了视频花屏。感觉还是处理不过的原因，也不知道是程序写哪有问题。。。
2015.06.07
测试发现不加解码，只取流（也就只启动Live555取流）同样存在问题，一到4路或超过4路1080P，0x65（idr包）就急剧的减少，与sps、pps出现的不成比例；占用的cpu为（53%、58%、60%69%），并且一直在这之间徘徊。
想想我的影子，我会在你身后给你一个拥抱;
