【音视频系统】技术串烧
1.扫盲
1.1 IPC和NVR的区别
IPC是IP Camera，即网络摄像头。
NVR是Network Video Record，即网络视频录像机，就是支持保存回放监控录像的服务器。更通用一点，就是拉流客户端。
传统数据流：
IPC（拍摄） → 网络传输 → NVR（存储/管理） → 用户（查看/回放）
随着家用摄像头的兴起，云存储逐渐流行，家用一般不会单独弄一个存储服务器，而是由厂家提供租用式的云服务：
IPC + SD卡 + 云服务
随着AI的兴起，AI也逐渐加入到摄像头的基本功能中：
IPC + SD卡 + 云服务+AI
1.2 IPC基础
- 国内主流IPC厂家：海康，大华，宇视等。
- IPC对外的数据流有主流和子流之分。主流画质高，用于保存。子流画质低，用于预览。
1.3 音视频系统应用架构
有两种：
- C/S架构：传统架构，需要安装特定的客户端软件。
- B/S架构：更轻便和流行的架构，在网页中完成一切视频操作，技术更新。
所有音视频技术都是围绕应用架构展开设计的，应用为王。
2. 流媒体编码与容器格式
编码，就是压缩。
容器是为了更好的传输和存储。
2.1 视频编码
2.1.1 H264
我们讲H264，不能从算法的角度去讲，因为我们程序员不是专业搞算法的，我们要说具体实现。我们先看H264是对视频是怎么分解的（图片原创，使用请标注出处）：
可以看出它的基本思想是模块分解，分层处理，和编程思维一样，所以说编程思维是通用的思维。
2.2 音频编码
2.2.1 G711a/u
2.2.2 Opus
2.2.3 AMR
2.3 流媒体容器
流媒体容器是高效传输h264裸流时的一层包装。高效传输是它的产生原因和根本目标。
2.3.1 flv容器
2.3.2 TS容器
2.3.3 mp4容器
2.3.4 hls容器
基于http。
现代需求：
- 支持跳播：好解决，视频分段
- 支持缓冲：好解决，视频分段
- 根据网络状态自动调整视频质量：存储多种质量的视频段，按需加载。
示意图来自网络：
所有下面的技术都有对应的开源库，我们只需要懂原理，会用即可。
2.3.5 webm容器
2.4 存储容器
媒体存储容器是高效保存h264裸流时的一层包装。高效保存是它的产生原因和根本目标。
3. 协议
整体把握：
音视频协议的载荷就两种：媒体数据和控制命令。在此之上的技术都是为了把载荷更快更好的传递过去。
3.1 ONVIF协议
ONVIF协议就是网络摄像头控制协议。
3.1.1 架构
架构图：
先学习一下什么是Web Service：
- Web Service：根据我的理解，Web Service和它的名字一样，是一套网络服务标准规范，通过这个协议，网络上的节点可以发现服务，调用服务，就是这么简单。SOAP是调用协议（SOAP=XML+HTTP/STMP+RPC），WSDL是接口头文件。和互联网的微服务架构基本上是一个东西。每个技术都各司其职，都只负责解决一个层级的问题。
- Onvif协议：理解什么是Web Services
可能有的人会问了，为什么用Web Service，为什么不用RESTful API，直接用Get/Post+Json也好啊，为什么搞这么复杂？我也有这个疑问，看看AI怎么说：
总的来说，就是Web Service更专业，优点大于缺点。特定场景下，不是RESTful API不行，而是Web Service更好。
3.1.2 协议规范：一手资料
学习协议最好要有一手资料，二手资料水平层次不齐，就像是犹抱琵琶半遮面一样，学得云里雾里。
- Onvif Specifications：官方定义的网络摄像头服务接口，就是接口文档，按照接口文档去调用对应的接口，控制摄像头，我们的目的就达到了。
下面是官方的图：
实际上就这么多接口而已。接口定义文件，官方也给写好了，直接拿来生成代码，就可以用了，很简单吧?有人说不对啊，怎么wsdl在浏览器里看起来是一个页面？其实这是浏览器渲染的效果，右键查看网页源代码，就可以看到，其实网页是一个wsdl文件，而不是html文件。
3.1.3 实操
大致架构已经清楚，但是没有动手实操过，等于是半懂不懂。下面是实操的教程：
强调两点：
- gsoap生成代码过程分两步：用wsdlh，先根据wsdl生成头文件；再用soapcpp2，将头文件生成cpp文件。
- 总体编程逻辑：ws服务发现->获取服务地址->获取能力->获取子服务地址->调用->结束
3.2. GB28181
3.2.1 最新版本
GB/T 28181-2016已被废止，新的标准GB/T 28181-2022于2023年7月1日正式实施。新国标全文下载地址：
既是标准又是教程，建议全文阅读。
3.3 推流协议
3.3.1 SRT协议
3.4 推拉流协议
3.4.1 RTSP/RTCP/RTP协议簇
应用：摄像头拉流，WebRTC。
特点：
| 协议 | 传输方式 |
|---|---|
| RTP | UDP |
| RTCP | UDP |
| RTSP | TCP |
多个端口，两种传输方式。这是经典模式，每一路流两个端口，再加上RTSP流需要一个端口。实际上一般不用这种模式。参考以下文章：
如文章中所说，一般使用的是RTP over RTSP（TCP交错模式），也就是只有一个端口为554的tcp连接，上面承载三个协议：RTP+RTCP+RTSP，用通道号分隔数据。当然这么做也有缺点，可以咨询AI获取详细信息。在使用 ffmpeg 或 ffplay 时，可以通过 -rtsp_transport tcp（交错模式） 或 -rtsp_transport udp（普通模式） 参数来强制指定使用哪种模式。
3.4.2 RTMP
应用：互联网直播。
特点：使用单个TCP连接，负载多个通道数据，连接简单，资源消耗少。
3.4.3 SRT
应用：新一代安全直播传输协议。
特点：基于UDP，安全。
3.5 会话管理协议
3.5.1 SIP协议
基于文本的灵活的会话控制协议，抽象出SIP ID解耦底层IP端口，一般用来实现互联网语音通话。需要专门的SIP服务器支持，可以用来实现类似微信语音通话一样的效果。
4.开发框架和工具
4.1 WebRTC
4.2 FFmpeg
4.3 流媒体服务器
4.3.1 ZLMediaKit
基于C++的开源流媒体服务器，国产。
4.3.2 SRS
基于C++的开源流媒体服务器，国产。
4.3.3 EasyDarwin
基于Go的RTSP 流媒体服务器，功能稍弱，适合学习和测试，国产。
4.3.4 Monibuca
基于Go的开源流媒体服务器，国产。
4.3.5 RED5
基于Java的老牌流媒体服务器，技术比较老，性能一般，非国产。
4.3.6 Media MTX
基于go，应该是老外写的。
5. 调试工具
http调试工具：charles
6.编程概念
- Sink：在视频处理中，Sink（接收器） 是一个至关重要的概念。简单来说，你可以把它理解为媒体数据流的“终点站”或“消费者”，负责接收处理完毕的视频数据，并将其输出到最终的目的地。输入对应的是”Source“。
7.实际应用
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
3
0- 0
已为社区贡献7条内容
所有评论(0)