最近要搞一个直播服务，车机本身是个前后双路的Dvr，前路1080P 25fps,后路720P 50fps，现在要连接手机app预览实时画面，且支持前后摄像头画面切换。
如果要做直播，这个分辨率和帧率是非常艰难的，必须降低，经过考量之后先设定为480P 25fps，编码码率为512k看看效果再做优化。
研究了一段时间的live555，里面有很多demo可以参考，但是我这个需求和里面demo的效果有比较大的差异
因为要做实时直播，必须是实时的摄像头数据，所以没法用rtspServe播放视频文件的方式来实现，。
换一个思路可以在rtspServe里面自己去打开摄像头获取数据，移植x264进行编解码再直播，但是因为Dvr占据了两个摄像头进行录像，无法腾出来，所以其他用户无权再开启摄像头。
rtspServe需要摄像头数据只能从Dvr获取，如此则需要一套进程间通信机制，而且要能承载大数据量的通信。可以考虑用有名管道或者共享内存。
基于此模式，我又有两个不同的直播编码方式，
方式一 独立编码直播流
rtspServe只从Dvr获取YUV原始数据，自己采用X264对每一帧进行编码，然后推流。
优点:
1、独立性，可以独立于Dvr的数据，自己单独设置编码参数，同时直播过程可控性强，比如遇到网络阻塞可以自由丢原始数据帧。
2、灵活性，直播服务器自由控制。
缺点:
1、YUV原始数据很大，通信压力大。
2、需要使用x264进行软编码，软编码时效未知。
方案二、采用录像编码数据分流
Dvr是一直在编码录像的，但是是一段一段的录制，可以从Dvr编好的数据流在保存文件的同事开一个分支共享给直播
优点：
1、失效高，录像编码采用硬件编码的，一直用来录像编码，已经经过长期的验证。
2、共享数据量小，共享数据是编码好的相比于YUV原始数据会小很多。
缺点：
1、编码的各项参数必须是和录像一样的，没法独立调节。
2、直播过程受录像影响，比如开始录像停止录像，意味着编码数据的开关。
以上两个方案个人更倾向于第一个，但是我最担心的就是x264的软编码时效是否能跟上，于是单独先移植了x264弄了个demo验证，果然x264乱编码的时效性太低了，码率设置在200k也没法跟上这么大分辨率这么高帧率的数据编码，一秒钟的视频数据需要编码两三秒，所以只能走第二个方案。
走方案二需要解决的只剩下rtspServer了，我需要实现一个自己的rtspServer，从管道获取编码数据然后推流
参考live555里面的testProgs
我们需要实现自己的几个文件类
1、实现自己的FrameSource：
FrameSource主要完成从哪里获取数据流(文件或者其他地方)，怎么获取数据流等。
2、实现自己的MediaSubsession
这个类主要是根据自己的source数据类型，建立不同的RTPSink和FrameSource
3、实现自己的rtspServer主函数
可以参考testOnDemandRTSPServer实现，把不要的各种类型的rtsp删除掉(mp3、mp4、wav、vob)，只保留自己的。
经过几天的倒腾测试基本把rtspServer的通路打通了，app能正常播放，效果后续优化。
