最近要搞一个直播服务,车机本身是个前后双路的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能正常播放,效果后续优化。