（零）音视频技术基础知识

2020-12-23 09:57:20 浏览数 (1)

前言

耽误了很久，一直想写音视频开发的教程，一方面，音视频的发展正在向各个行业扩展，从教育的远程授课，交通的人脸识别，医疗的远程就医等，音视频方向已经占据一个相当重要的位置，而音视频真正入门的文章又少之甚少，一个刚毕业小白可能很难切入理解,因为音视频中涉及大量理论知识,而代码的书写需要结合这些理论,所以搞懂音视频,编解码等理论知识至关重要。另一方面，公司的业务也在逐渐向音视频靠拢，我需要先将积累的知识点重新梳理后分享给其他同学。

整个过程可能会花费较长时间，为了防止大家理解过于空洞，我会将demo上传到Github，供大家对照学习。 在代码实现上，我更多会以iOS开发为着重点。

如果喜欢,请点赞。支持转载,转载请附原文链接.

教程概述

整个教程在我目前的规划里面大概分为几块：

  • 交叉编译
  • 音频体系
  • iOS音频开发
  • 视频体系
  • iOS视频开发
  • 直播、短视频及其他实际应用

音视频基础知识体系

在教程开始之前，我们先了解音视频技术的基础知识，当然我更多的是讲解有那些知识体系以及如何使用，而不会去详细讲解知识体系的细节或理论基础，例如我会讲解压缩数据原理，但是不会讲解I帧，P帧，B帧具体的编码。简而言之，我们将站在巨人肩膀上，而不会去探究巨人是怎样形成的。

1、封装格式

封装格式也称多媒体容器，它只是为多媒体编码提供了一个“外壳”，也就是将所有的处理好的视频、音频或字幕都包装到一个文件容器内呈现给观众，这个包装的过程就叫封装。

常见音视频的封装格式.png

Tips：封装格式不影响视频画质。它只负责把内部的视频轨和音频轨集成在一起，只起到一个文件夹（或者压缩包）的作用，并没有对视频轨和音频轨造成影响。

2、视频编码技术

  • 视频编码就是指通过特定的压缩技术，将某个视频格式的文件转换成另 一种视频格式文件的方式。
  • 视频传输中的编码标准 1.国际电联的H.264 2.国际标准化组织运动图像专家 组的MPEG系列标准 3.微软公司的WMV 4.Apple公司的 QuickTime 5.google力推的WebM格式
  • 常见视频编码格式

常见视频编码格式.png

3、音频编码技术

音频编码的主要作用是将音频采样数据（PCM等）压缩成为音频码流，从而降低音频的数据量,偏于存储和传输。 描述一段PCM数据一般需要以下几个概念：

  • 采样率：记录声音时每秒的采样个数，它用赫兹(Hz)来表示。
  • 量化格式（采样精度）：指记录声音的动态范围，它以位(Bit)为单位。
  • 声道数：通道的数目
  • 比特率：每秒传输的数据量。公式如下：比特率 = 采样率 × 采样深度 × 通道数

常见音频编码格式有：

常见音频编码格式.png

4、流媒体协议技术

流媒体协议是用于传输音视频的协议，包括RTP、RTCP、RTSP、RTMP、HLS等，本文只介绍技术，其中常用的是RTMP协议。

  • RTP(Real-time Transport Protocol)实时传输协议 RTP是用于Internet上针对多媒体数据流的一种传输协议。建立在UDP协议上的。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议）、视频会议。和一键通（Push to Talk）系统（配合H.323或SIP），使它成为了IP电话产业的技术基础。
  • RTCP(Real-time Transport Control Protocol)实时传输控制协议 RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。 通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。
  • RTSP（Real Time Streaming Protocol）实时流协议 RTSP是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如暂停，快进等控制，但它本身并不传输数据，RTSP的作用相当于流媒体服务器的远程控制。服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。 RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信 息，如数据编码/解码算法、网络地址、媒体流的内容等。 虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个 RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。
  • RTMP(Real Time Messaging Protocol)实时消息传输协议 RTMP（Real Time Messaging Protocol）是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种： （1）工作在TCP之上的明文协议，使用端口1935； （2）RTMPT封装在HTTP请求之中，可穿越防火墙； （3）RTMPS类似RTMPT，但使用的是HTTPS连接。

RTMP视频播放的特点： （1）RTMP协议是采用实时的流式传输，所以不会缓存文件到客户端，这种特性说明用户想下载RTMP协议下的视频是比较难的； （2）视频流可以随便拖动，既可以从任意时间点向服务器发送请求进行播放，并不需要视频有关键帧。相比而言，HTTP协议下视频需要有关键帧才可以随意拖动。 （3）RTMP协议支持点播/回放（通俗点将就是支持把flv,f4v,mp4文件放在RTMP服务器，客户端可以直接播放），直播（边录制视频边播放）。

  • HLS (HTTP Live Streaming) HTTP Live Streaming(HLS)是苹果公司实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用于iOS系统。HLS点播是分段HTTP点播，不同在于它的分段非常小。要实现HLS点播，重点在于对媒体文件分段，目前有不少开源工具可以使用。 相对于常见的流媒体直播协议，HLS直播最大的不同在于，直播客户端获取到的并不是一个完整的数据流，HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。

总结 RTSP协议 （1）是流媒体协议。 （2）RTSP协议是共有协议，并有专门机构做维护。. （3）RTSP协议一般传输的是 ts、mp4 格式的流。 （4）RTSP传输一般需要 2-3 个通道，命令和数据通道分离。 （5）常用于安防监控领域

RTMP协议 （1）是流媒体协议。 （2）RTMP协议是 Adobe 的私有协议，未完全公开。 （3）RTMP协议一般传输的是 flv，f4v 格式流。 （4）RTMP一般在 TCP 1个通道上传输命令和数据 （5）通用，浏览器直接可以看，可支持百万，千万人同时在线看

HLS协议 （1）是流媒体协议。 （2）苹果公司开放标准 （3）可以穿过任何允许HTTP数据通过的防火墙或者代理服务器 （4）IOS上支持完美。Android3.0开始支持。PC/flash上现在也有各种as插件支持

5、音视频原理

  • 采集 通过系统API获取物理摄像头采集到的视频数据与麦克风采集到的音频数据。采集的原始数据类型音频数据为PCM，视频数据为YUV或RGB。
  • 处理 音频和视频原始数据本质都是一大段数据，系统将其包装进自定义的结构体中，以回调函数形式提供，在我们的项目中需求做一系列特殊处理，如: 视频的旋转、缩放、滤镜、美颜、裁剪等； 音频的单声道降噪、消除回声、静音等。
  • 编码 原始数据自定义处理后就可以进行传输，像直播这样的功能就是把采集好的视频数据发送给服务器，以在网页端供所有粉丝观看，而传输由于本身就是基于网络环境，庞大的原始数据就必须压缩后才能带走，可以理解为我们搬家要将物品都打包到行李箱这样理解。
  • 传输 编码后的音视频数据通常以RTMP协议进行传输，这是一种专门用于传输音视频的协议，因为各种各样的视频数据格式无法统一，所以需要有一个标准作为传输的规则，协议就起到这样的作。
  • 解码 服务端接收到编码数据后，对其解码成原始数据，因为编码的数据直接送给物理硬件的设备是不能直接播放的，只有解码为原始数据才能使用。
  • 音视频同步 解码后的每帧音视频中都含有最开始录制时候设置的时间戳，我们需要根据时间戳将它们正确的播放出来，但是在网络传输中可能会丢失一些数据，或者是延时获取，这时我们就需要一定的策略去实现音视频的同步，大体分为几种策略:缓存一定视频数据，视频追音频等。

业务剖析

音视频在互联网行业的需求实际上简单归纳为互逆过程的两个部分：推流和拉流。

  • 推流：将手机采集到的视频数据传给后台播放端进行展示，播放端可以是windows、linux、web端，即手机充当采集的功能，将手机摄像头采集到视频和麦克风采集到的音频合成编码后传给对应平台的播放端。

推流.jpeg

  • 拉流：将播放端传来的视频数据在手机上播放，推流的逆过程，即将windows、linux、web端传来的视频数据进行解码后传给对应音视频硬件，最终将视频渲染在手机界面上播放。

拉流.jpeg

如果喜欢，请帮忙点赞。支持转载，转载请附原文链接。

http 图像处理 云点播 云直播

0 人点赞