直播技术研究

发表于 | 更新于 | 分类于 | 阅读次数：

直播技术积累。

1. 读《在线音视频技术精要》

2. 技术细节

2.1 Rtmp协议

RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。RTMP与HTTP一样，都属于TCP/IP四层模型的应用层。

2.1.1 RTMP协议分析

2.1.1.1 一些定义

名称 定义
Payload The data contained in a packet, for example audio samples or compressed video data.
Packet A data packet consists of fixed header and payload data. Some underlying protocols may require an encapsulation of the packet to be defined.
Port 端口，默认使用1935
Transport address The combination of a network address and port that identifies a transport-level endpoint, for example an IP address and a TCP port. Packets are transmitted from a source transport address to a destination transport address.
Message stream A logical channel of communication in which messages flow.
Message stream ID Each message has an ID associated with it to identify the message stream in which it is flowing.
Chunk A fragment of a message. The messages are broken into smaller parts and interleaved before they are sent over the network. The chunks ensure timestamp-ordered end-to-end delivery of all messages, across multiple streams.
Chunk stream A logical channel of communication that allows flow of chunks in a particular direction. The chunk stream can travel from the client to the server and reverse.
Chunk stream ID Every chunk has an ID associated with it to identify the chunk stream in which it is flowing.
Multiplexing Process of making separate audio/video data into one coherent audio/video stream, making it possible to transmit several video and audio simultaneously.
DeMultiplexing Reverse process of multiplexing, in which interleaved audio and video data are assembled to form the original audio and video data.
Remote Procedure Call (RPC) A request that allows a client or a server to call a subroutine or procedure at the peer end.
Metadata 描述文件，The metadata of a movie includes the movie title, duration, date of creation, and so on.
Application Instance The instance of the application at the server with which the clients connect by sending the connect request.
Action Message Format (AMF)

2.1.1.2 RTMP Format

2.1.1.2.1 Message 和 Chunk关系

RTMP以Message为基本单位，通过把Message拆分成Chunk来进行网络发送。每个Chunk中都带有MessageID代表属于哪个Message，接受端按照这个id来将Chunk组装成Message。

  • Message 消息类型

    Chunk承载的Message不同，其Message Header也不同，不同的fmt取值可以用来区分Chunk的类型。

  • 协议控制协议

  • 用户控制协议

  • Command message

  • Chunk

2.1.1.2.2 Message format中构建Chunks的必要字段
  • Timestamp
  • Length
  • Type id
  • Message stream ID

2.1.1.3 RTMP包头

RTMP协议封包由一个包头和一个包体组成。包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,Head_Type,AMFSize,AMFType,StreamID信息,

  • 8字节的包头只纪录了时间戳,Head_Type,AMFSize,AMFType,
  • 4个字节的包头记录了时间戳,Head_Type。
  • 1个字节的包头只记录了Head_Type 。
  • 包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节.

完整的RTMP包头有12字节，由下面5个部分组成:

用途 大小(Byte) 含义
Head_Type 1 包头
TIMER 3 时间戳
AMFSize 3 数据大小
AMFType 1 数据类型
StreamID 4 流ID
2.1.1.3.1 Head_Type - 包头类型

Head_Type占用RTMP包的第一个字节，这个字节里面记录了包的类型和包的ChannelID。Head_Type字节的前两个Bit决定了包头的长度.它可以用掩码0xC0进行”与”计算，Head_Type的前两个Bit和长度对应关系：

Bits Header Length
00 12 bytes
01 8 bytes
10 4 bytes
11 1 byte
ChannelID 用途
02 Ping 和ByteRead通道
03 Invoke通道 我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的
04 Audio和Vidio通道
05 06 07 服务器保留,经观察FMS2用这些Channel也用来发送音频或视频数据
2.1.1.3.2 TiMMER - 时间戳

时间戳占用RTMP包头的第2、3、4 三个字节。RTMP时间戳可分为绝对时间戳和相对时间戳，纪录的是音视频的时间信息。相对时间戳指的是二个RTMP包之间的时间间隔，单位毫秒。而绝对时间戳指的是当前封包发送的时刻，单位也是毫秒。对于音视频的播放，时间戳非常关键，因为音视频的播放同步是由时间戳来控制的，如果你的视频出现卡顿，音视频不同步，延时越来越大，很可能就是你的时间戳不准导致的。

fms对于同一个流，发布(publish)的时间戳和播放(play)的时间戳是有区别的

  • publish时间戳

​ 采用相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个媒体包的绝对时间戳之间的差距，也就是说音视频时间戳在一个时间轴上面.单位毫秒。

  • play时间戳

​ 也是相对时间戳，时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包的绝对时间戳之间的差距, 注意这里跟上面不同的是强调“同类型的媒体包”。也就是说音视频时间戳分别采用单独的时间轴，单位毫秒。

  • flv格式文件时间戳

​ 绝对时间戳，时间戳长度3个字节。超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。flv格式文件影片总时间长度保存在onMetaData的duration属性里面，长度为8个字节，是一个double类型。

2.1.1.3.3 AMFSize - 数据大小

AMFSize占三个字节，这个长度是AMF长度，可超过RTMP包的最大长度128字节。如果超过了128字节，那么由多个后续RTMP封包组合，每个后续RTMP封包的头只占一个字节。一般就是以0xC？开头。1个字节的包头表示这个包的时间戳、数据大小、数据类型、流ID都和上一个相同ChannelID的RTMP包完全一样。

2.1.1.3.4 AMFType - 数据类型

AMFType是RTMP包里面的数据的类型，占用1个字节。例如音频包的类型为8，视频包的类型为9。下面列出的是常用的数据类型：

0×01 Chunk Size changes the chunk size for packets
0×02 Unknown
0×03 Bytes Read send every x bytes read by both sides
0×04 Ping ping is a stream control message, has subtypes
0×05 Server BW the servers downstream bw
0×06 Client BW the clients upstream bw
0×07 Unknown
0×08 Audio Data packet containing audio
0×09 Video Data packet containing video data
0x0A-0x0E Unknown
0x0F FLEX_STREAM_SEND TYPE_FLEX_STREAM_SEND
0x10 FLEX_SHARED_OBJECT TYPE_FLEX_SHARED_OBJECT
0x11 FLEX_MESSAGE TYPE_FLEX_MESSAGE
0×12 Notify an invoke which does not expect a reply
0×13 Shared Object has subtypes
0×14 Invoke like remoting call, used for stream actions too.
0×16 StreamData 这是FMS3出来后新增的数据类型,这种类型数据中包含AudioData和VideoData
2.1.1.3.5 StreamID - 流ID

占用RTMP包头的最后4个字节，是一个big-endian的int型数据。我们x86 计算机内存中数据存放都是小尾数模式：little-endian，而网络数据流一般都是大尾数模式：big-endian。 StreamID是音视频流的唯一ID, 一路流如果既有音频包又有视频包，那么这路流音频包的StreamID和他视频包的StreamID相同，但ChannelID不同。

2.1.1.3.6 封包分析

例如有一个RTMP封包的数据0300 00 00 00 01 02 1400 00 00 00 0200 07 63 6F 6E 6E 65 63 74 003F F0 00 00 00 00 00 00 08 ，，，

数据依次解析的含义

  • 03表示12字节头，channelid=3
  • 000000表示时间戳 Timer=0
  • 000102表示AMFSize=18
  • 14表示AMFType=Invoke 方法调用
  • 00 00 00 00 表示StreamID = 0

2.1.1.4 AMF数据

Rtmp包默认的最大长度为128字节,(或通过chunksize改变rtmp包最大长度), 当AMF数据超过128Byte的时候就可能有多个rtmp包组成, 如果需要解码的rtmp包太长则被TCP协议分割成多个TCP包.那么解码的时候需要先将包含rtmp包的tcp封包合并, 再把合并的数据解码, 解码后可得到AMF格式的数据, 将这些AMF数据取出来就可以对AMF数据解码了.

​ RTMP封包包括包头和AMF数据2部分，AMF数据里面可以是命令也可以是音视频数据。组成服务器和Flash客户端之间的所有数据都是用AMF格式的数据在传送,例如connect() publish()等命令. AMF数据由2部分组成： ObjType 加上ObjValue。ObjType的大小为一个字节。ObjValue的大小不固定，和ObjType相关。

2.1.2 使用过程

2.1.2.1 握手过程

2.1.2.2 Connect

2.1.2.3 Publish

2.1.2.4 Play

To start a video stream, the client sends a “createStream” invocation followed by a ping message, followed by a “play” invocation with the file name as argument. The server will then reply with a series of “onStatus” commands followed by the video data as encapsulated within RTMP messages. After a connection is established, media is sent by encapsulating the content of FLV tags into RTMP messages of type 8 and 9 for audio and video respectively.

2.1.3 疑问解答

2.1.3.1 Chunk size和GOP大小关系？

  • 从flv封装说起

FLV文件中的每种标签类型（tag type）都构成一个流。 在FLV文件中，同步在一起的音频和视频流不得超过一个。 FLV文件不能定义单个类型的多个独立流。一个FLV文件需要什么？

FLV Header + FLv script tag + FLV Video tag + FLV Audio tag

FLV Video Tag，这部分封装着图像数据，也就是H.264的数据封装在这里。H.264是由一个一个NALU组成，NALU的类型有（SPS、PPS、I帧的SLICE、非I帧的SLICE），封装H.264就是将这些NALU一个一个取出来，然后封装成Tag。需要注意的是，SPS与PPS必须封装在一个Tag中。

  • H.264码流结构

H.264 的功能分为两层，即视频编码层（VCL）和网络提取层（NAL，Network Abstraction Layer）。VCL 数据即编码处理的输出，它表示被压缩编码后的视频数据序列。在 VCL 数据传输或存储之前，这些编码的 VCL 数据，先被映射或封装进 NAL 单元中。简单的说，VCL负责数据的编码压缩，NAL负责数据的封装传输。从大到小依次为：序列、帧(I、P、B帧)、片组、片(I、P、B、SP、SI片)、NALU、宏块、亚宏块、块、像素。

拿到RBSP或SODB之后，就可以根据NALU Header中得到的NALU Type，去解析它们，重建图像。一张图片可以包含一个或多个分片(SLICE)，而每一个分片(SLICE)又会被分为了若干宏块(Macroblock)。

  • 关系

GOP中的帧———>H.264的NALU———>FLV中的Video Tag———>Rtmp Stream———>Chunk

2.1.3.2 播放器如何播放RTMP流？

我认为是“GOP中的帧———>H.264的NALU———>FLV中的Video Tag———>Rtmp Stream———>Chunk”的一个逆向过程。

2.1.3.3 RTMP协议延时从何而来？

累积误差，原因是RTMP基于TCP不会丢包。所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；待网络状况好了，就一起发给客户端。这个的对策就是，当客户端的缓冲区很大，就断开重连。

2.1.4 Demo

2.1.4.1 ffmpeg安装：

https://www.jianshu.com/p/ab469a2ffd28

2.1.4.2 ffmpeg推流：

https://blog.csdn.net/bvngh3247/article/details/80405423

1
ffmpeg -re -i /home/hjh/nginx/video.mp4 -vcodec copy -acodec copy -b:v 800k -b:a 32k -f flv rtmp://localhost:1935/videotest/test

https://www.jianshu.com/p/c141fc7881e7

2.1.4.3 nginx实现RTMP推流

参考资料

  • rtmp协议官方文档

  • red5: Red5 is an Open Source Flash Server written in Java that supports:

    • Streaming Video (FLV, F4V, MP4, 3GP)
    • Streaming Audio (MP3, F4A, M4A, AAC)
    • Recording Client Streams (FLV and AVC+AAC in FLV container)
    • Shared Objects
    • Live Stream Publishing
    • Remoting
    • Protocols: RTMP, RTMPT, RTMPS, and RTMPE

    https://github.com/Red5/red5-server-common

  • flv官方文档

  • 新一代视频压缩编码标准H.264.pdf

2.2 DCT 离散余弦变换 原理与应用讲解

JPEG是joint Photographic Experts Group(联合图像专家组)的缩写，文件后辍名为”．jpg”或”．jpeg”它是一种有损压缩。支持多种压缩级别，压缩比率通常在10：1到40：1之间，压缩比越大，品质就越低；相反地，压缩比越小，品质就越好。那么，JPEG是如何压缩的呢？靠的就是传说中的DCT(离散余弦变换)。

下图是JPEG压缩/解压缩的流程图。

2.2.1 JPEG压缩流程

2.2.1.1 以8x8的图象块为基本单位进行编码

每个图像块共64个像素。像素可以用RGB或YUV表示，需要3个byte。所以严格来说，上图3个箭头代表的数据，指的是RGB/YUV的某一个值，比如Y。

2.2.1.2 将RGB转换为亮度-色调-饱和度系统（YUV），并重新采样

YUV是什么？它也是一种很不错的图像数据表示方法，特别是在视频领域。

  • Y：指颜色的明视度、亮度、灰度值；

  • U：指色调；

  • V：指饱和度。

YUV是一个统称，其实有很多具体格式，比如YUV420, YUV444, YUV422。YUV的某些格式，和RGB比起来，其数据量要少很多。比如YUV420，每个像素需要一个Y，每4个像素需要一个U/V，因此一个8*8图像块，数据量只要8x8x3/2 = 96byte。而RGB需要8x8x3 = 192byte。少了一半的数据量。现在很多视频都是YUV420作为色域。

YUV与RGB可以互相转换。

Y=0.299R+0.587G+0.114B

U=0.148R-0.289G+0.473B

V=0.615R-0.515G-0.1B

2.2.1.3 FDCT与IDCT

一个是正变换，一个是逆变换。反正都可以称为离散余弦变换。根据8*8的二维DCT定义：

其中：0<= u, v < 8，

输入就是8x8的数据矩阵，经过计算，输出还是一个8x8的数据矩阵。其实上式可以简化为：

称G（0,0），也就是输出8x8矩阵的（0,0）坐标的值，为直流系数，其他为交流系数。之所以称它为直流系数，是因为当u, v = 0时，cos()结果都为0，所以最后结果就是输入矩阵的8x8的每个数值的和，再乘于a(u) x a(v) x 1/4 = 1/8。当然，输入数据其实是有3个的，也就是YUV，因此对每个8x8的原始图像数据，需要做3次DCT。

2.2.1.4 量化和反量化

定义：将DCT变换后的临时结果，除以各自量化步长并四舍五入后取整，得到量化系数。

为什么可以量化？！

因为经过DCT后，数据就不同了，左上方都是大数值，右下方都是小数值。比如左上方都是几十几百的，右下方附近，都是个位数，那么，大数值和小数值就可以分别量化。在术语里，左上方称为低频数据，右下方称为高频数据。

比如cos(ax)，a是常数，x是变量。那么，根据频率f = a/2π，a越大，函数的频率越高。看上方DCT公式：u,v 越大，则越在右下方对吧。当计算某个G(u, v)时，x, y是变量，u, v相当于常数，当u/v越大，则频率越高！这就是为什么右下方称为高频数据了！

JPEG系统分别规定了亮度分量和色度分量的量化表，色度分量相应的量化步长比亮度分量大。

对量化系数的处理和组织

思想：JPEG采用定长和变长相结合的编码方法。

直流系数：通常相邻8*8图象块的DC分量很接近，因此JPEG对量化后的直流分量采用无失真DPCM编码。通常JPEG要保存所需比特数和实际差值。

交流系数：经过量化后，AC分量出现较多的0。JPEG采用对0系数的行程长度编码。而对非0值，则要保存所需数和实际值。

ZIG-ZAG排序：为使连续的0个数增多，采用Z形编码。

2.2.2 应用举例

2.2.2.1 编码

某个图象的一个8*8方块的亮度值。

由于一个字节是0~255，为了减小绝对值波动，先把数值移位一下，变成-128~127。

接着，根据DCT变换公式，各种计算，获得临时结果。

根据亮度量化表量化后得到的量化系数矩阵：

获得量化结果：

可见，新的数据，很小，很多是0。正如上文所说，这么多0，完全可以用游程编码，大大缩小数据量。

2.2.2.2 解码

先游程编码恢复为：

然后，根据量化表，恢复：

再根据反离散余弦变换的公式：

结果为：

再右移127，恢复原始。

2.2.2.3 其他

JPEG压缩是有损失的，从上面的例子就看出来，输出结果并不是完全等于输入。此外，JPEG压缩比例是可以控制的，只不过图像质量会变差。比如：

  • 压缩率：10

  • 压缩率：50

2.3 HLS

2.3.1 HLS是什么

HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。 它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。

在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。

  • RTMP指Adobe的RTMP(Realtime Message Protocol)，广泛应用于低延时直播，也是编码器和服务器对接的实际标准协议，在PC（Flash）上有最佳观看体验和最佳稳定性。
  • HLS指Apple的HLS(Http Live Streaming)，本身就是Live（直播）的，不过Vod（点播）也能支持。HLS是Apple平台的标准流媒体协议，和RTMP在PC上一样支持得天衣无缝。

2.3.2 HLS主要的应用场景

  • 跨平台：PC主要的直播方案是RTMP，也有一些库能播放HLS，譬如jwplayer，基于osmf的hls插件也一大堆。所以实际上如果选一种协议能跨 PC/Android/IOS，那就是HLS。
  • IOS上苛刻的稳定性要求：IOS上最稳定的当然是HLS，稳定性不差于RTMP在PC-flash上的表现。
  • 友好的CDN分发方式：目前CDN对于RTMP也是基本协议，但是HLS分发的基础是HTTP，所以CDN的接入和分发会比RTMP更加完善。能在各种CDN之间切换，RTMP也能，只是可能需要对接测试。
  • 简单：HLS作为流媒体协议非常简单，apple支持得也很完善。Android对HLS的支持也会越来越完善。至于DASH/HDS，好像没有什么特别的理由，就像linux已经大行其道而且开放，其他的系统很难再广泛应用。

总之，SRS支持HLS主要是作为输出的分发协议，直播以RTMP+HLS分发，满总各种应用场景。点播以HLS为主。

2.4 工具

2.4.1 播放器

2.4.2 ffmpeg

https://trac.ffmpeg.org/wiki/EncodingForStreamingSites

  • 直播流截图
1
ffmpeg -probesize 32768 -i rtmp://115.28.34.157:1935/myapp/test1 -y -t 0.001 -ss 1 -f image2 -r 1 /home/rtmp.jpeg
  • 将文件当做直播送至live
1
ffmpeg -re -i localFile.mp4 -c copy -f flv rtmp://server/live/streamName
  • 将直播媒体保存至本地文件
1
ffmpeg -i rtmp://server/live/streamName -c copy dump.flv
  • 将其中一个直播流，视频改用h264压缩，音频不变，送至另外一个直播服务流
1
ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream
  • 将其中一个直播流，视频改用h264压缩，音频改用faac压缩，送至另外一个直播服务流
1
ffmpeg -i rtmp://server/live/originalStream -c:a libfaac -ar 44100 -ab 48k -c:v libx264 -vpre slow -vpre baseline -f flv rtmp://server/live/h264Stream
  • 将其中一个直播流，视频不变，音频改用faac压缩，送至另外一个直播服务流
1
ffmpeg -i rtmp://server/live/originalStream -acodec libfaac -ar 44100 -ab 48k -vcodec copy -f flv rtmp://server/live/h264_AAC_Stream
  • 将一个高清流，复制为几个不同视频清晰度的流重新发布，其中音频不变
1
ffmpeg -re -i rtmp://server/live/high_FMLE_stream -acodec copy -vcodec x264lib -s 640×360 -b 500k -vpre medium -vpre baseline rtmp://server/live/baseline_500k -acodec copy -vcodec x264lib -s 480×272 -b 300k -vpre medium -vpre baseline rtmp://server/live/baseline_300k -acodec copy -vcodec x264lib -s 320×200 -b 150k -vpre medium -vpre baseline rtmp://server/live/baseline_150k -acodec libfaac -vn -ab 48k rtmp://server/live/audio_only_AAC_48k
  • 功能一样，只是采用-x264opts选项
1
ffmpeg -re -i rtmp://server/live/high_FMLE_stream -c:a copy -c:v x264lib -s 640×360 -x264opts bitrate=500:profile=baseline:preset=slow rtmp://server/live/baseline_500k -c:a copy -c:v x264lib -s 480×272 -x264opts bitrate=300:profile=baseline:preset=slow rtmp://server/live/baseline_300k -c:a copy -c:v x264lib -s 320×200 -x264opts bitrate=150:profile=baseline:preset=slow rtmp://server/live/baseline_150k -c:a libfaac -vn -b:a 48k rtmp://server/live/audio_only_AAC_48k
  • 将当前摄像头及音频通过DSSHOW采集，视频h264、音频faac压缩后发布
1
ffmpeg -r 25 -f dshow -s 640×480 -i video=”video source name”:audio=”audio source name” -vcodec libx264 -b 600k -vpre slow -acodec libfaac -ab 128k rtmp://server/application/stream_name
  • 将一个JPG图片经过h264压缩循环输出为mp4视频
1
ffmpeg.exe -i INPUT.jpg -an -vcodec libx264 -coder 1 -flags +loop -cmp +chroma -subq 10 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -flags2 +dct8x8 -trellis 2 -partitions +parti8x8+parti4x4 -crf 24 -threads 0 -r 25 -g 25 -y OUTPUT.mp4
  • 将普通流视频改用h264压缩，音频不变，送至高清流服务(新版本FMS live=1)
1
ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv “rtmp://server/live/h264Stream live=1″

3. 寻师经典

宋利，教授，博士生导师，上海交通大学图像通信与网络工程研究所副所长，人工智能研究院、未来媒体网络协同创新中心双聘教授，中国视频用户体验联盟副秘书长及标准组组长。研究方向是媒体智能信号处理、媒体通信与计算系统，主持国家级科研项目10余项，发表学术论文200余篇，授权发明专利40项，软件著作权5项。获国家科技进步二等奖(2015)、上海市科技进步一等奖(2011)、上海市技术发明一等奖(2011)、日本大川基金研究奖(2013)、国际会议优秀论文奖(VCIP2016, WCSP2010)、国际竞赛奖(ICME 2017, 2020)、TVP腾讯云最具价值专家(2019, 2020)。担任IEEE Trans on Broadcasting特邀编委, Springer Multidimensional Systems and Signal Processing编委、是IEEE 高级会员、LiveVideoStackCon(2019,2020)上海峰会主席、中国智慧家庭产业联盟、中国超高清产业联盟、上海市超高清产业联盟、上海市物联网协会、上海市信息家电协会的技术咨询专家，领域知名公众号“媒矿工厂”创建者。更多信息参见其实验室主页：

http://medialab.sjtu.edu.cn/

-------------本文结束感谢您的阅读-------------
我知道是不会有人点的，但万一有人想不开呢？