作为一名音视频产品经理，需要对相关音视频基础技术知识有所了解，因为在教育音视频中，每个环节都会涉及到很多相关的基础知识。本文就教育直播业务的音视频技术框架以及直播流程拆分进行解读，希望对你有所帮助。

作为一名在音视频SaaS教育直播行业从业近3年的产品经理，本文将结合个人理解与实际工作经验给大家讲解——作为一名音视频产品经理，应该需要知道的音视频基础技术知识；本文结构大致如下三个方面：

一、教育直播业务的音视频技术框架

关于直播业务中涉及到的音视频技术框架，整体流程框架大差不差，熟悉如抖音、快手、B站此类C端直播平台，亦或是直播SaaS厂商提供的直播产品，如百家云、保利威、微赞等等；这里我以我们公司教育直播业务梳理如下基础框架：

从业务表现层来看，直播整体流程主要表现在主播端采集音视频后，在观众端进行播放观看（部分业务还涉及观众上麦）；从技术框架简单来看即为：

主讲端上采集、处理、编码、封装-》推流-》流媒体服务器处理/信令服务器处理-》拉流与音视频解码与播放

基于以上流程，我们即可拆分来看每个环节会具体做哪些事情，以及我们产品经理在实际需求设计中每个环节我们应当注意的事项，并附上实际需求案例辅助说明。

二、直播流程拆分解读

1. 端上音视频采集、处理、编码、封装

音视频，顾名思义即为音频+画面的统称，端上采集、处理、编码、封装时同样以2个方面进行。

第一方面，关于音频的采集、处理、编码、封装，主要是将声音的模拟信号数字化的一个过程（也叫模数转化，A/D转换）。

如上图所示，基于采集到的音频声波图，我们取时间轴上特定的时间间隔T作为样本周期，标记无数个点（取样点越密越精准），这一步叫采样；而后将每一个采样点的纵向幅度量化，便能得到量化的模拟信号（可以理解为坐标值）。

因为计算机只能识别01的二进制字节序列，量化的模拟信号，我们无法进行直接传输，需要将样本值（十进制）进行编码，即转化成二进制字节序列，如序号2中的样本值3转化为011，即可在数字信号图中得到对应信号图；实际应用中，往往还会使用其他编码算法做进一步压缩，这里我们不做过深讨论，知晓原理即可；大家也可基于如下内容要点自行查找相关内容。

第二方面，关于图像的采集过程，主要由摄像头等设备拍摄得到原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。在图像采集阶段，涉及的主要技术参数包括：图像传输格式、图像格式、传输通道、分辨率以及采样率。

MPEG-4/H.264等编解码算法的工作机制基本都是混合编码，主要处理模块包括：预测、变换、量化和熵编码等。

• 预测：通过帧内预测和帧间预测降低视频图像的空间冗余和时间冗余。
• 变换：通过从时域到频域的变换，去除相邻数据之间的相关性，即去除空间冗余。
• 量化：通过用更粗糙的数据表示精细的数据来降低编码的数据量，或者通过去除人眼不敏感的信息来降低编码数据量。
• 扫描：将二维变换量化数据重新组织成一维的数据序列。
• 熵编码：根据待编码数据的概率特性减少编码冗余。

通常在这流程环节，产品层面涉及的业务需求主要围绕在声音与画面的处理，如常见的需求有美颜、滤镜、虚拟背景、音频降噪等等；熟悉此流程可帮助我们在整理此类需求时，理解技术上的处理时机，降低我们与研发的沟通成本；（不熟悉的同学可能会误认为美颜效果处理是流媒体服务端研发处理，造成需求评审会上的尴尬场面）

2. 推流

推流：将直播的内容推送至服务器的过程。即指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。可以简单理解为音视频编码封装之后需上传到流媒体服务器，类似快递打包好之后要推到物流点。

常用的流传输协议有WebRTC、RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。

而CDN的作用在于推出去的流媒体要给各个地理位置的观众看。从而解决用户访问网络资源慢的问题。

3. 流媒体服务器处理/信令服务器处理

流媒体服务器能够在一定的主机配置条件和网络带宽条件下提供流畅的、高并发的视频播出能力；流媒体服务器要做的事情包括：数据分发（CDN）、实时转码、内容检测等等；

随着技术的发展，流媒体服务器的技术和产品也一直在不断的发展和演进，视频播出技术发展的趋势包括：

1）高清视频为主（1080p、4K），高码率播出（>2Mbps）；

2）H264依然是主要视频编码格式，VP9/H265在有些应用中也开始采用；

3）视频传输更多的采用http协议，Flash播放器逐步被淘汰；

4）采用WebRTC、Websocket协议进行视频播出的应用越来越多。

5）双向视频应用越来越多，在在线教学、会议直播等直播应用中成为标配。

信令服务器承担着消息传输和交换的工作，简单来说前端/客户端向流媒体服务端传输消息，或者流媒体服务端向前端/客户端传输消息，都是依靠的信令；比如用户创建房间，加入房间，退出房间等，确定何时初始化、关闭和修改通话；类似前端与后端以接口进行数据请求与返回，而前端/客户端与流媒体服务端以信令形式；

通常在这流程环节，产品层面要理解流媒体服务器工作原理与信令服务器工作原理的好处在于，如底层服务商有多家时，可能需考虑多CDN切换或者海外服务的海外CDN切换功能；

另外对于信令服务器的理解更为重要，因涉及客户端与流媒体服务端之间的数据交互，某些更深入的场景业务在此理解基础上更易推进，如企业直播场景中的打赏功能，端上可直接以广播信令形式广播至全直播间成员；如教育场景中的画笔笔迹，老师端上以信令文件传输至服务端后再处理传出至学生端。

4、拉流与音视频解码与播放

拉流是指服务器已有直播内容，根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据，进行拉取的过程；拉流端的核心处理在播放器端的解码和渲染，因音视频再推流至流媒体服务器之前已被编码和封装，如需在端上直接播放是行不通的，故需进行解码和渲染处理，处理之后即可通过播放器对音视频文件进行播放。

上述内容即为整个直播业务涉及的基础技术流程，当然还有部分特殊业务流程，如观众连麦/嘉宾连麦PK，其实原理类似，也是基于观众/嘉宾采集音视频数据后进行处理编码封装后传输推流，流媒体服务端处理后以合流或多路流形式台下观众拉流（具体看产品形态与成本评估）。

三、整体总结

作为一名音视频行业的产品经理，因音视频技术涉及技术语言与复杂方案较多，了解整体的业务流程结构是有必要的；对于内部需求评审而言，可以快速定位需求相关方（前端/流媒体端/后端）组会与任务落实；对于外部沟通评估需求而言，快速给予客户解决方案以及分析需求，也能更好体现自身专业性。

以上为我个人从业直播行业的一些经验分享以及收集的相关资料解读，欢迎大家探讨与纠正~