2022年使用最多的流媒体协议和技术规范

们将回顾一些最常用的流协议: RTMP、 RTSP、 WebRTC、 HLS、 SRT 和 CMAF

我们将了解以下流协议，以便:

RTMP
RTSP
WebRTC
HLS
SRT
CMAF

RTMP 实时消息协议

RTMP 流媒体协议是 Macromedia 开发的一种基于 TCP 的技术，用于在 Flash 播放器和服务器之间通过互联网进行音频、视频和数据的流媒体传输。Macromedia 于2005年12月3日被竞争对手 Adobe 收购，但随着 Flash 在2020年逐步淘汰，它的使用越来越少地与面向观众的内容交付有关，而更多地是通过支持 RTMP 的编码器将实时流摄入到平台中。

流协议技术规范

音频编解码器: AAC，AAC-LC，HE-AAC + v1 & v2，MP3，Speex
视频编解码器: H. 264，VP8，VP6，Sorenson Spark，Screen Video v1 & v2
播放兼容性:不再得到广泛支持了限于 Flash 播放器，AdobeAIR，RTMP 兼容的播放器不再被 iOS、 Android、大多数浏览器和大多数嵌入式播放器所接受
优点: 低延迟和最小缓冲
缺点: 没有针对经验质量或可伸缩性进行优化
等待时间: 5秒

RTMP 变化

RTMP: 普通的基于 TCP 的协议
RTMPS: 使用安全的 SSL 连接来最小化基于云的流的风险
RTMPE: 使用 Adobe 的专有安全加密，并且是比 RTMPS 更轻量级的加密层
RTMPT: 用 HTTP 封装以绕过防火墙和公司流量过滤
RTMFP: 使用 UDP 代替 TCP

RTSP 实时流协议

RTSP 建立并控制单个或多个时间同步的连续媒体流，如音频和视频。RTSP 本身通常不提供连续的流，尽管可以将连续的媒体流与控制流交织在一起。换句话说，RTSP 充当多媒体服务器的“网络远程控制”。

由于大多数 IP 摄像头仍然支持 RTSP，它仍然是监控和闭路电视系统中使用的标准。

RTSP 技术规格

音频编解码器: AAC，AAC-LC，HE-AAC + v1 & v2，MP3，Speex，Opus，Vorbis
视频编解码: H. 265(预览) ，H. 264，VP9，VP8
播放兼容性:不被广泛支持，很少用于播放(Quicktime Player 和其他 RTSP/rTP 兼容播放器，VideoLAN VLC media Player，3gpp 兼容移动设备)
优点: 低延迟和无处不在的 IP 摄像头
缺点: 没有针对经验质量和可伸缩性进行优化
延迟2秒

RTSP 变化

整个 RTP 堆栈
实时控制协议
RTSP 通常被称为 RTSP

网络实时通信

WebRTC 代表 Web 实时通信，它是一个非常令人兴奋的、强大的、具有高度破坏性的尖端技术和流协议。

它与 HTML5兼容，你可以使用它直接在浏览器和设备之间添加实时媒体通信。另外，你可以做到这一点，而不需要在浏览器中安装任何必备的插件。它正逐渐得到所有主要的现代浏览器供应商的支持，包括 Safari、 Google Chrome、 Firefox、 Opera 和其他浏览器。

感谢 WebRTC 视频流技术，您可以直接将实时视频嵌入到基于浏览器的解决方案中，为您的受众创建一个迷人的互动流体验，而不用担心延迟。

流协议特性

超低延迟视频流-延迟是0.5秒
与平台和设备无关
先进的语音和视频质量
加密语音和视频
很容易缩放
适应网络条件
数据通道

优点

简单，基于浏览器的贡献
对等点直接打开彼此之间的连接
低延迟并支持500毫秒交付的交互性
可以在某些用例中端到端使用

缺点

不是广播质量流的最佳选择，因为某些特性支持接近实时的传输

HLS (HTTP Live Streaming)

HLS 是一种基于 HTTP 的自适应协议，用于将视频和音频数据/内容从媒体服务器传输到终端用户的设备。

合肥光源于2009年由苹果公司创建。苹果发布 HLS 的时间与传奇设备 iPhone3差不多。早期的 iPhone3有直播播放问题，苹果希望通过 HLS 解决这个问题。

Features of HLS Video Streaming Protocol

字幕
快进和倒带
音频和视频交替播放
F备用方案
定时元数据
插入广告
内容保护

HLS Technical Specifications

音频编解码器: AAC-LC，HE-AAC + v1 & v2，xHE-AAC，无损苹果，FLAC
视频编解码器: H. 265，H. 264
播放兼容性: 它是为 iOS 设备创建的，然而，现在所有的 Google Chrome 浏览器，Android，Linux，Microsoft 和 macOS 设备; 一些机顶盒，智能电视和其他播放器支持 HLS，因为它是一个通用协议
优点: 支持自适应比特率、可靠性和广泛支持
缺点: 视频质量和观众体验优先于延迟
延迟: HLS 允许我们有5-20秒的延迟，但是低延迟的 HLS 扩展现在已经被合并为 HLS 的一个特性集，承诺提供2秒以下的延迟

安全可靠的传输

SRT 是一种开源技术，用于在不可预测的公共网络上进行可靠且低延迟的流媒体传输。它直接与 RTMP 和 RTSP 竞争，作为第一英里的解决方案，但仍被采用作为编码器，解码器和播放器添加支持。SRT 在2020年的一个互动用例被证明是第一个虚拟 NFL 草案ーー确保高质量的流媒体和在任何有互联网连接的地方的操作灵活性。

SRT 优点

专有协议的开源替代方案
高质量低延迟
设计用于在不可预测的公共网络上进行现场视频传输
解释了数据包丢失和抖动

SRT 限制

不受所有编码器的本机支持
作为新技术仍在被采用
没有广泛的播放支持

CMAF 通用媒体应用格式

CMAF 是一种简化基于 HTTP 的流媒体交付的新格式。它是一个新兴的标准，有助于降低成本和复杂性，并提供大约3-5秒的延迟流。CMAF 可用于 DASH 或 HLS。

由于 RTMP 的地位不断下降，其他基于 HTTP (超文本传输协议)的自适性串流技术也应运而生。但是，不同的流标准需要不同的文件容器。例如，当 MPEG-DASH 使用。MP4集装箱，HLS 流交付在。其格式。

因此，每个想要接触更多观众的广播公司都必须对同一个视频文件进行两次编码和存储，因为加密创建了完全不同的文件组。

这两个版本的同一个视频流应提前或立即进行。这两个过程都需要额外的存储和处理成本。

苹果和微软建议移动图片专家组创建一个新的统一标准，称为通用媒体应用格式(CMAF) ，以降低在线视频传输的复杂性。

CMAF优势

削减成本
最小化工作流复杂性
减少延迟

锋网按：本文作者蒋海兵，趣拍产品总监，直播行业老兵。

移动直播行业的火热会在很长一段时间内持续，通过和各行业的整合，从而成为具有无限可能性的行业。主要有以下三个原因：

第一，移动直播的UGC生产模式比PC端的直播更明显，人人都有设备，随时随地开播，完全顺应了互联网时代的开放性原则，能刺激更多人去创造和传播优质内容。

第二，网络带宽和速度在逐渐提高，网络成本在逐渐下降，为移动直播提供一个极佳的发展环境。文字、声音、视频、游戏等都会在移动直播中呈现，创造出更加丰富的用户体验。直播可以以SDK的形式接入到自己的应用中，比如，教育领域中的课后辅导完全可以以直播的形式开展业务、电商也可借助直播让用户挑选商品，促进销售。

第三，一个与VR/AR技术相结合的移动直播为整个行业的未来提供了新的发展空间。VR/AR直播能够让用户身临其境，带动主播与观众更贴近真实的互动，大大提高平台的用户参与度。

当下，有技术实力和流量优势的互联网从业者都不愿错过直播这个风口，如何快速搭建一个直播系统成了大家关心的问题，我想和大家分享下我的经验。我从事于一家直播产品开发商，我们的产品为了快速赶上市场，使用了云服务提供商的直播SDK。

从业者都知道，一个完整直播产品应该包含以下环节：推流端（采集、前处理、编码、推流）、服务端处理（转码、录制、截图、鉴黄）、播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。下面我就一一讲述下直播SDK在各个环节所做的工作。

一、移动直播推流端需要做哪些工作？

直播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。

1、采集

移动直播SDK通过手机摄像头和麦克风直接采集音视频数据。其中，视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。采集到的原始音视频的体积是非常大的，需要经过压缩技术处理来提高传输效率。

2、前处理

在这个环节主要处理美颜、水印、模糊等效果。美颜功能几乎是直播的标配功能。我们调研中发现太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。

美颜实际上是通过算法去识别图像中的皮肤部分，对皮肤区域进行色值调整。通过颜色对比找到皮肤区域，可以进行色值调整、添加白色图层或调整透明度等来达到美白效果。在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持iOS和Android，支持自己写算法实现自己最理想的效果。GPUImage内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了。

3、编码

为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积，现在比较常用的视频编码是H.264。在音频方面，比较常用的是AAC编码格式，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。

相较于之前的H.264，2012年诞生的H.265编解码标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。像阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。

H264和H265个模块技术差异：

另外，硬件编码已经成为移动直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在iOS平台上硬件编码的兼容性比较好，可以直接采用，但在Android平台上，Media Codec编码器针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。

4、推流

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于移动直播这种实时性要求非常高的场景，RTMP也成为移动直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能非常有保障。当然，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

二、服务端处理需要做哪些工作？

要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。

1、截图、录制、水印

像阿里云等云服务商都提供了实时转码技术，将用户推流码率较高（比如720P）实时转化成较低清晰度（比如360P）的流以适应播放端的需求。如果要自己搭建实时转码系统，这个成本是极高的，一台8核设备只能实时转10路流，如果一个正常的直播平台有1000路流，就需要100台设备，加上后期的运维成本，一般公司就吃不消了。

2、鉴黄

2016年4月14日，文化部查出了斗鱼、虎牙、YY、熊猫TV、六间房、9158等涉嫌提供含宣扬淫秽、暴力、教唆犯罪的网络直播平台，被列入查处名单。政府介入管制有利于直播行业打造健康的生态，进入良性发展。这也意味着为了安全直播产品鉴黄成了必需环节，使用技术手段去鉴黄是移动直播平台必然采用的方案。

市面上提供鉴黄服务的方案主要有两种：

第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值。典型的企业有阿里（绿网）、图谱科技，他们目前都支持直接传入视频，经过服务端分析返回结果。通常由业务系统接入鉴黄服务，根据鉴黄结果对直播流进行控制，如切断直播流、封禁账号等。

第二种是和CDN结合，直接对直播流进行分析，识别结果分为色情、疑似色情、性感和正常，业务系统根据识别结果直接控制直播流。典型的企业是Viscovery，这套方案的优点是实时性保证比较好，缺点是必须部署到CDN或自己的机房，使用成本相对高一些。

还有一种一站式直播解决方案提供商，他们的做法是，用户只需在控制台对鉴黄服务进行配置就可以针对每个应用、每一路直播流进行实时审核。在控制台中，云服务商实时将鉴黄结果返回，用户可以直接查看色情直播和违规界面的截图，同时可以对直播流进行控制，切断问题直播流。该服务商还提供了短信、邮件和站内信功能，避免漏掉任何一个非法视频，给平台造成损失，我们就使用了这种方式。

三、播放器端需要做哪些工作？

在播放器端如何做到秒开，直播过程中保证画面和声音清晰度的同时，稳定、流程、无卡顿的直播流量，这些工作都需要播放器端配合服务端来做优化，做到精确调度。

1、拉流

拉流实际是推流的逆过程。首先通过播放端获取码流，标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议，开源软件和开源库都支持的比较好，如开源的librtmp库，播放端只要支持flashPlayer的就能非常简单的播放RTMP直播，直播延迟一般在1–3秒。

HLS是苹果提出的基于HTTP的流媒体传输协议，HTML5可以直接打开播放，通过微信、QQ等软件分享出去，用户也可以直接观看直播，可以说移动直播app，HLS拉流协议是必须支持的，缺点是延迟通常大于10秒。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议，也不用担心被Adobe的专利绑架，直播延迟同样可以做到1–3秒。

各拉流协议的差异：

我们使用的云服务的直播拉流技术提供了以上三种格式，满足不同业务场景的需求，如对即时性要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放；对于有回放或跨平台需求的，推荐使用HLS。当然，三种协议是可以同时使用的，分别用到自己的场景就可以了。

2、解码和渲染

拉流获取封装的视频数据后，必须通过解码器解码、渲染后才能在播放器上播放。它是编码的逆过程，是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩，所以在提取后的原始数据，并非原始采样数据，存在一定的信息丢失。因此，在视频体积最小的情况下通过各种编码参数保留最好的原始画面，成为了各视频公司的核心机密。

考虑对高清的支持，解码肯定还是要选择硬解码的。前面介绍过，iOS系统由于硬件比较单一、比较封闭，支持的比较好，Android系统由于平台差异非常大，编解码要完全兼容各平台还需要很多工作要做。

四、移动直播中的交互系统

移动直播中最常见的交互有聊天室（弹幕）、点赞、打赏和礼物等，交互系统涉及消息的实时性和互动性，在技术实现上大多是使用IM的功能来实现的。对于在线人数比较多的房间，弹幕消息量是非常大，主播与用户其实都看不过来，为了缓解服务器压力，在产品策略需要做一些必要的优化。

1、聊天室

移动直播中的弹幕交互是用户和主播互动的主要方式，实际上就是IM中的聊天室功能。聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。

2、礼物系统

礼物系统更是绝大多数移动直播平台的标配了，它是这些平台主要的收入来源。送礼物的形式也增强了用户和主播之间的互动交流，也是主播依赖平台的最主要原因。

礼物的收发在技术实现上也是用聊天室接口做的，通常采用IM中的自定义消息实现，当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。

以上就是我们在使用了第三方SDK服务后总结出来的直播产品经验，希望能帮助到创业者和从业者们。

境部署

1、配置、安装 Nginx；

# ./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.pid --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.39 --with-zlib=/usr/local/src/zlib-1.2.11 --with-openssl=/usr/local/openssl/
# make
# make install
# /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf  //启动Ngnix
# netstat -ano | grep 80

2、扩展 Nginx-rtmp-module

C++音视频开发学习资料：点击领取→音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

# ./configure --add-module=/usr/local/src/nginx-rtmp-module-master --with-openssl=/usr/local/openssl/
# make
# make install
# vim /usr/local/ngnix/conf/ngnix.conf
include /usr/localcinx-rtmp-module-master/testinx.conf;
# vim /usr/localcinx-rtmp-module-master/testinx.conf
rtmp {
    server {
        listen 1935;

        application myapp {
            live on;

            #record keyframes;
            #record_path /tmp;
            #record_max_size 128K;
            #record_interval 30s;
            #record_suffix .this.is.flv;

            #on_publish http://localhost:8080/publish;
            #on_play http://localhost:8080/play;
            #on_record_done http://localhost:8080/record_done;
        }

            application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 10s;     #每个视频切片的时长。
            hls_playlist_length 60s;  #总共可以回看的事件，这里设置的是1分钟。
            #hls_continuous on; #连续模式。
            #hls_cleanup on;    #对多余的切片进行删除。
            #hls_nested on;     #嵌套模式。
        }
    }
}

http {
    server {
        listen      8080;

        location /stat {
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            root /usr/local/src/nginx-rtmp-module-master/;
        }

        location /control {
            rtmp_control all;
        }

        location /rtmp-publisher {
            root /usr/local/src/nginx-rtmp-module-master/test;
        }

            location /hls {
            #server hls fragments
            types{
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            #alias /tmp/app;
            root /tmp;
            expires -1;
        }

        location / {
            root /usr/local/src/nginx-rtmp-module-master/test/rtmp-publisher;
        }
    }
}
# /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
# netstat -ltn  #查看端口的监听情况

3、安装 ffmpeg

# ./configure --prefix=/usr/local/ffmpeg
# make
# make install