基于live555开发嵌入式linux系统的rtsp直播服务

最近要搞一个直播服务，车机自己是个先后双路的Dvr，前路1080P 25fps,后路720P 50fps，如今要链接手机app预览实时画面，且支持先后摄像头画面切换。

若是要作直播，这个分辨率和帧率是很是艰难的，必须下降，通过考量以后先设定为480P 25fps，编码码率为512k看看效果再作优化。

研究了一段时间的live555，里面有不少demo能够参考，可是我这个需求和里面demo的效果有比较大的差别

由于要作实时直播，必须是实时的摄像头数据，因此无法用rtspServe播放视频文件的方式来实现，。

换一个思路能够在rtspServe里面本身去打开摄像头获取数据，移植x264进行编解码再直播，可是由于Dvr占据了两个摄像头进行录像，没法腾出来，因此其余用户无权再开启摄像头。

rtspServe须要摄像头数据只能从Dvr获取，如此则须要一套进程间通讯机制，并且要能承载大数据量的通讯。能够考虑用有名管道或者共享内存。

 

基于此模式，我又有两个不一样的直播编码方式，

方式一 独立编码直播流

rtspServe只从Dvr获取YUV原始数据，本身采用X264对每一帧进行编码，而后推流。

优势:

一、独立性，能够独立于Dvr的数据，本身单独设置编码参数，同时直播过程可控性强，好比遇到网络阻塞能够自由丢原始数据帧。

二、灵活性，直播服务器自由控制。

缺点:

一、YUV原始数据很大，通讯压力大。

二、须要使用x264进行软编码，软编码时效未知。

方案2、采用录像编码数据分流

Dvr是一直在编码录像的，可是是一段一段的录制，能够从Dvr编好的数据流在保存文件的同事开一个分支共享给直播

优势：

一、失效高，录像编码采用硬件编码的，一直用来录像编码，已经通过长期的验证。

二、共享数据量小，共享数据是编码好的相比于YUV原始数据会小不少。

缺点：

一、编码的各项参数必须是和录像同样的，无法独立调节。

二、直播过程受录像影响，好比开始录像中止录像，意味着编码数据的开关。

 

以上两个方案我的更倾向于第一个，可是我最担忧的就是x264的软编码时效是否能跟上，因而单独先移植了x264弄了个demo验证，果真x264乱编码的时效性过低了，码率设置在200k也无法跟上这么大分辨率这么高帧率的数据编码，一秒钟的视频数据须要编码两三秒，因此只能走第二个方案。

走方案二须要解决的只剩下rtspServer了，我须要实现一个本身的rtspServer，从管道获取编码数据而后推流

参考live555里面的testProgs

咱们须要实现本身的几个文件类

一、实现本身的FrameSource：

FrameSource主要完成从哪里获取数据流(文件或者其余地方)，怎么获取数据流等。

二、实现本身的MediaSubsession

这个类主要是根据本身的source数据类型，创建不一样的RTPSink和FrameSource

三、实现本身的rtspServer主函数

能够参考testOnDemandRTSPServer实现，把不要的各类类型的rtsp删除掉(mp三、mp四、wav、vob)，只保留本身的。

 

通过几天的倒腾测试基本把rtspServer的通路打通了，app能正常播放，效果后续优化。