技术背景
在介绍GB28181设备接入模块和轻量级RTSP服务之前,我们需要先搞清楚,二者的使用场景和技术设计的差别:
首先是GB28181设备接入模块:
为什么要设计GB28181设备接入模块?GB28181接入SDK,实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。Android终端除支持常规的音视频数据接入外,还可以支持移动设备位置(MobilePosition)订阅和通知、语音广播和语音对讲、云台控制和预置位查询等。
其次是轻量级RTSP服务模块:
为什么要设计轻量级RTSP服务?轻量级RTSP服务解决的核心痛点:避免用户单独部署RTSP或者RTMP服务,实现本地的音视频数据(如摄像头|屏幕、麦克风),编码后,汇聚到内置RTSP服务,对外提供可供拉流的RTSP URL,轻量级RTSP服务,适用于内网环境下,对并发要求不高的场景,视频编码支持H.264/H.265,音频对外输出AAC/PCMA,支持RTSP鉴权、单播、组播模式,考虑到单个服务承载能力,支持同时创建多个RTSP服务,并支持获取当前RTSP服务会话连接数。
轻量级RTSP服务的设计,更像Android平台扮演了IPC的角色。
大家有没有这么个感觉,如果GB28181设备接入模块和轻量级RTSP服务模块,二者合二为一的话,是不是更像一个支持国标接入的网络摄像机?
是的,就是如此!
所以,我们在设计Android平台GB28181设备接入模块和轻量级RTSP服务模块的时候,有几个需要注意的地方:
视频编码:
大家都知道,GB/T28181-2016协议规范里面,并没有描述GB28181对H.265的支持策略,如果H.265数据上去,国标平台侧大概率是需要转成H.264输出,一方面徒增时延,另一方面,转换后的数据,可能会导致时间戳偏差等各种问题。所以,如果考虑到二者同时启动,建议视频编码选择H.264。
视频编码,我们有支持Native MediaCodec的底层编码模型,简单来说,支持如下:
- 软编码(分平均码率和VBR可变码率编码)
- 特定机型硬编码(分上层MediaCodec调用和Native Mediacodec硬编码(H264/HEVC,5.0+))
音频编码:
音频编码分为AAC编码和G.711 A律编码,由于GB平台大多默认传G.711 A律编码,所以这就需要国标设备接入端,如果同时支持轻量级RTSP服务的话,相对容易一些。
总结
其他,如果需要同时推RTMP或者实时录像、实时快照、实时音量调节等操作,Android平台天生支持,感兴趣的开发者可以酌情考虑。