本来自己写过p2p模式的视频传输，不过都是完全手写的代码，有些地方代码不够规范。听说jrtplib写的很好，前一段时间也分析清楚了，今天拿过来做下测试。

使用jrtplib3.7.1的主要工作有两个：

一是发送接收数据需要分片和重组。开始采集双向链表，后来发现处理不够好，内存总出错(好久没研究数据结构了)。后来直接采用分配缓冲，发送数据时标志offset,接收数据 按offset直接填充，非常简单。当然接收时判断一下，有没有重复的数据。代码有时间整理一下传上来。

二是继承RTPSession，写一个响应类，在这里接收和发送。

然后，写一个对话框程序，用 DirectShow调用摄像头， 用SampleGrabber的方式抓数据，然后用libavcodec压成264;用DirectSound采集声音，用Speex压缩。先在内网测试，两台PC(或虚拟机)之间，直接向对方IP和端口发音视频，收到后解码，效果非常好。

到此为止，jprtlib表现的非常完美，另外代码质量也非常。

不过再下一步就有点问题，我用jrtplib再写服务器端，协助双方打洞。比较奇怪的是，客户端和服务器端只不过发送很少的命令字，双方反应都相当慢。看了看jrtplib代码，修改了一下socket接收发送的缓冲也不行。时间有限，没有完全看下去。估计是rtp和rtcp做协调时影响了效率。

简单地总结一下：如果使用jrtplib传送音视频媒体数据，非常理想。但如果使用它用来做服务器处理命令，效率肯定不行(当然修改其源码也能解决问题)。

也有变通的方法：可以自己写一个简单的可靠UDP，专门用来负责命令通信，用它得到对方的IP和端口后，送给jrtplib，然后jrtplib向这个IP端口发送数据就可以了。

不过，这样一样，还不如参考jrtplib源码，自己封装一个更好一些的UDP传输库。

传输音视频，因为数据量大，基本上不需要重传，只要做好丢包控制和同步就行了，所以完全可以不用jrtplib.

jrtplib主要的问题就是重组。

重组算法后面附上，虽然是测试代码，不过也稳定。