Android 摄像头 rtmp 推流

SRS在安防领域的应用

1. SRS简介

SRS是一个开源的流媒体协议，可以将摄像机的视频流数据推送到SRS服务端，播放端可以从SRS实时拉取视频流数据。

2. SRS支持的协议

SRS支持的协议包含两部分：输入协议和输出协议

说明：左边输入协议，右边输出协议

 

2.1 浏览器无插件播放方案

RTMP最流行的直播协议，PayLoad负载类型为FLV，由于Flash被谷歌禁用，很多浏览器就不得不寻找无插件播放。现在也经常会将摄像头的RTSP视频流经FFMpeg转为RTMP推流到SRS，SRS会将RTMP视频转为各种协议输出，如HTTP-FLV、HLS、WebRTC等等。

 

• HLS：苹果的切片协议，就是将每个视频包数据一段一段的发送，浏览器需要下载完成一个完整的切片才能播放，严格上说并不能是一个流媒体协议，只能是一个文件传输协议
• HTTP-FLV：目前流行的一个协议，利用了HTTP Chunked特性，HTTP Body数据类型就是FLV（即PayLoad类型），与RTMP的负载类型差不多，浏览器接收到数据之后使用flv.js这个库重新组装数据，即可实时播放。但是它不是一个满足W3C标准的流媒体协议，而且实际使用中延时相对WebRtc较高，和RTMP差不多效果。且播放时间长的话音视频同步会出现问题，有待解决改善。另外手机端IOS不支持。推送到RTMP格式数据可以直接在播放端拉取HTTP-FLV数据，具体详见SRS的说明文档。
• WebRTC：是当前最火的流媒体协议。优点对前端的开发者比较方便，只需要几行代码就可以实现图像采集渲染编解码。缺点是底层技术栈难度较大。延时低，基于UDP

2.2 安防中的协议

1. RTSP：PayLoad负载类型为RTP，主要在内网中使用，实际上每个摄像头都可以理解成是一个RTSP的Server端，如果你要看视频的话就需要主动到摄像头那里拉流，摄像头自己是不会主动推流给你；所以处在公网的浏览器是不能获取到内网的视频的。
2. GB-28181协议：国标协议，是公安一所联合几个摄像头厂家定制的协议 ，目的是为了解决RTSP存在的问题（外网不能访问内网的摄像头数据），该协议能够主动注册，且向外推流的协议，最早的2011版是基于UDP，后来公网中丢包比较严重，后来又做了一个基于TCP的补充协议。打包方式是RTP+PS。

说明：PS打包适用本地存储和局域网传输，TS打包适用网络数据传输。

3. SRS使用场景

3.1 常见使用场景

• 视频直播，主播使用OBS推流到SRS，转封装成HTTP-FLV流或者是苹果的HLS。SRS一般不做转码，如果有需要做转码可以通过OBS或者FFmpeg，如原来经常会将摄像头的RTSP流转为RTMP流到SRS，每个浏览器或者桌面客户端程序可以直接拉取RTMP视频流数据进行播放。
• WebRTC通话，WebRTC可以点对点，也可用于多人通话，视频会议等。低延时场景。
• 安防监控领域：可以使用FFmpeg拉取RTSP视频流再转为RTMP推送到SRS，也可以直接使用GB-28181协议直接推流，客户端使用WebRTC播放
• 广电领域，使用SRT协议推流。

3.2 安防端场景

 

设备端：摄像头和NVR等设备

边缘端：一般会配置一个视频网关，负责拉流并转推到云端，同时也支持一些控制指令和边缘存储等

云端：指挥调度系统，SRS的功能是用于视频流的转发。

实时：对于视频网关来说，接收一帧转发一帧，中间不需要进行一些sleep处理

回放：实际就是读取文件推流，读文件的速度很快，不进行sleep控制就会疯狂推送，压榨完你的CPU，接收端播放也很快，所以需要sleep，如帧率是25的视频，两帧之间间隔就是40ms，所以每一帧之间要延时了40毫秒，再推送下一帧。

回放控制业务：

• 快进：常规的修改是sleep缩小时间，如二倍数修改为20ms，4倍数10ms，8倍数5ms，但是这样并不可行，

• 带宽限制，速度增加，同一时间传输的视频数据量也会成倍增大，即相应的码率成倍增加，所以如果这种模式快进带宽是一个限制。如1080p正常播是4M，如果按这种方式播放的话：2倍数码率对应着8M，4倍数码率就对应着16M，8倍数就对应着32M，对带宽消耗很大
• CPU性能，主要是视频编码能力也要成倍增加，而软件编解码很耗资源，另外对于客户端的CPU压力也很大，即需要解码的视频流也变大。

比较好的解决是使用抽帧的方式：隔一定的时间间隔就将一些帧丢掉，这里需要注意不能把I帧丢掉，其保留了一个完整的图像数据，后面的P帧需要依赖I帧解码。所以一般都会有一个根据速率和带宽和I帧间隔的算法，如二倍速是我们把时间间隔减半（增加一些带宽和CPU的消耗），四倍数时只发送I帧，8倍速时就每两个I帧发送1个I帧数据，16倍数时就每隔4个I帧发送一个。

• 慢放：发送时间间隔加长即可
• Seek:t：拖拽
• 云台控制：对延时要求较高，现阶段一般采用WebRtc协议进行控制。延时一般一秒可满足需求
• 暂停：SRS有一个机制如果5秒接收不到数据，就会认为流断开了，会触发unpublish事件

3.3 常见问题

1. 导致延时的几个因素
   a. 硬件设备
   b. 编解码
   c. 网络传输：
   包括应用层（HLS、RTMP、Http-Flv等）以及传输层（TCP（网络不好的情况下会重传导致延时卡顿）和UDP）
   缓存： 服务端有一个GOP参数，该参数的设置是为了缩短首屏时间，如果不在乎首屏的等待时间可以将GOP缓存关闭也会减少延时。另一个是播放端也会有缓存，缓存的目的是为了用户体验避免卡顿。
   d. 性能优化
   合并读写，该功能实际是为了减少IO的读写操作，开启后就不会收到一帧转发一帧而是收到几帧数据之后一次性的转发，即只调用一次系统IO，这样也会导致延时，如果不在乎这个并发数就可以将这个功能关掉，可以降低延时。
    
2. Onvif/RTSP不支持
   Onvif：设备支持不健全
   RTSP：内网协议外网不能访问
3. 不支持H265？
   SRS支持H265，但是浏览器不支持