MKV、MP4、H.265、RTMP、RTSP、HLS、码率\码流、多码流

痛定思痛。 2023-10-16 09:52 31阅读 0赞

1、封装格式(MP4/MKV…) vs 媒体格式(H.264/FLAC/AAC…)  
MP4+MKV是你下载的视频文件最常见的种类。这些文件其实类似一个包裹，它的后缀则是包裹的包装方式。这些包裹里面，包含了视频（只有图像），音频（只有声音），字幕等。当播放器在播放的时候，首先对这个包裹进行拆包（专业术语叫做分离/splitting）,把其中的视频、音频等拿出来，再进行播放。

既然它们只是一个包裹，就意味着这个后缀不能保证里面的东西是啥，也不能保证到底有多少东西。包裹里面的每一件物品，我们称之为轨道(track)，一般有这么些：

视频(Video): 一般来都有，但是也有例外，比如mka格式的外挂音轨，其实就是没视频的mkv。注意我们说到视频的时候，是不包括声音的。  
音频(audio)：一般来都有，静音的除外。  
章节(Chapter): 蓝光原盘中自带的分段信息。如果文件带上了，那么你可以在播放器中看到带章节的效果：  
.potplayer右键画面，选项-播放-在进度条上显示书签/章节标记  
.mpc-hc 右键画面，选项-调节-在进度条显示章节标记  
字幕(Subtitles)：有些文件自带字幕（不是视频直接整合于视频的硬字幕），那么就是一起被打包在封装容器中。  
其他可能还有附件等，不一一列举。每个类型也不一定只有一条轨道，比如经常见到带多音轨的MKV。  
每个轨道，都有自己的编码格式。

视频编码格式，常见的有H.264(可以细分为8bit/10bit)，H.265(当前也有8bit/10bit之分)，RealVideo(常见于早期rm/rmvb)，VC-1(微软主导的，常见于wmv)。基本上，H.264=AVC=AVC1, H.265=HEVC。  
音频编码格式，常见的有 FLAC/ALAC/TrueHD/DTS-HD MA这四种无损，和AAC/MP3/AC3/DTS(Core)这四种有损。  
2、MKV vs MP4，主要的区别在于：  
MKV支持封装FLAC作为音频，MP4则不支持。但是MP4也可以封装无损音轨(比如说ALAC，虽然普遍认为ALAC的效率不如FLAC优秀)

MKV支持封装ASS/SSA格式的字幕，MP4则不支持。一般字幕组制作的字幕是ASS格式，所以内封字幕多见于MKV格式

MP4作为工业标准，在视频编辑软件和播放设备上的兼容性一般好于MKV。这也是vcb-s那些为移动设备优化的视频基本上选择MP4封装的原因。

除此之外，这两个格式很大程度上可以互相代替。比如它们都支持封装AVC和HEVC，包括8bit/10bit的精度。所以MP4画质不如MKV好，这种论断是非常无知的——它们完全可以封装一样的视频。

为什么会有这样的分歧，就是历史原因了。MKV是民间研发，为了代替古老的AVI，更好地支持H264，它开发和修改的灵活度使得它可以兼容flac/ass这类非工业标准的格式；而MP4则是出生豪门，作为工业标准，替代更古老的MPG，作为新一代视频/音频封装服务的。

3、视频的基础参数：分辨率，帧率、码率、比特率、采样率。  
分辨率  
视频是由连续的图像构成的。每一张图像，我们称为一帧(frame)。图像则是由像素(pixel)构成的。一张图像有多少像素，称为这个图像的分辨率。比如说1920×1080的图像，说明它是由横纵1920×1080个像素点构成。视频的分辨率就是每一帧图像的分辨率。

帧率  
一个视频，每一秒由多少图像构成，称为这个视频的帧率(frame-rate)。常见的帧率有24000/1001=23.976, 30000/1001=29.970, 60000/1001=59.940, 25.000, 50.000等等。这个数字是一秒钟内闪过的图像的数量。比如23.976，就是1001秒内，有24000张图像。视频的帧率是可以是恒定的(cfr, Const Frame-Rate)，也可以是变化的(vfr, Variable Frame-Rate)

码流/码率  
码流(Data Rate)是指视频文件在单位时间内使用的数据流量，也叫码率或码流率，通俗一点的理解就是取样率,是视频编码中画面质量控制中最重要的部分，一般我们用的单位是kb/s或者Mb/s。一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内取样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。

单位一般是Kbps(Kbit/s)或者Mbps(Mbit/s)。注意1B(Byte)=8b(bit)。所以一个24分钟，900MB的视频：  
体积：900MB = 900MByte = 7200Mbit  
时间：24min = 1440s  
码率：7200/1440 = 5000 Kbps = 5Mbps

当视频文件的时间基本相同的时候（比如现在一集大概是24分钟），码率和体积基本上是等价的，都是用来描述视频大小的参数。长度分辨率都相同的文件，体积不同，实际上就是码率不同。

码率也可以解读为单位时间内，用来记录视频的数据总量。码率越高的视频，意味着用来记录视频的数据量越多，潜在的解读就是视频可以拥有更好的质量。（注意，仅仅是潜在，后文我们会分析为什么高码率不一定等于高画质）

比特率  
比特率是指每秒传送的比特(bit)数。单位为bps(Bit Per Second)，比特率越高，传送的数据越大。在视频领域,比特率常翻译为码率 !!!

比特率表示经过编码（压缩）后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；如果比特率越少则情况刚好相反。

采样率  
采样率（也称为采样速度或者采样频率）定义了每秒从连续信号中提取并组成离散信号的采样个数，它用赫兹（Hz）来表示。  
采样率是指将模拟信号转换成数字信号时的采样频率，也就是单位时间内采样多少点。一个采样点数据有多少个比特。比特率是指每秒传送的比特(bit)数。单位为 bps(Bit Per Second)，比特率越高，传送的数据越大，音质越好.比特率 =采样率 x 采用位数 x声道数.

举例：  
采样率类似于动态影像的帧数，比如电影的采样率是24赫兹，PAL制式的采样率是25赫兹，NTSC制式的采样率是30赫兹。当我们把采样到的一个个静止画面再以采样率同样的速度回放时，看到的就是连续的画面。

同样的道理，把以44.1kHZ采样率记录的CD以同样的速率播放时，就能听到连续的声音。显然，这个采样率越高，听到的声音和看到的图像就越连贯。当然，人的听觉和视觉器官能分辨的采样率是有限的，基本上高于44.1kHZ采样的声音，绝大部分人已经觉察不到其中的分别了。

而声音的位数就相当于画面的颜色数，表示每个取样的数据量，当然数据量越大，回放的声音越准确，不至于把开水壶的叫声和火车的鸣笛混淆。同样的道理，对于画面来说就是更清晰和准确，不至于把血和西红柿酱混淆。不过受人的器官的机能限制，16位的声音和24位的画面基本已经是普通人类的极限了，更高位数就只能靠仪器才能分辨出来了。比如电话就是3kHZ取样的7位声音，而CD是44.1kHZ取样的16位声音，所以CD就比电话更清楚。

当你理解了以上这两个概念，比特率就很容易理解了。以电话为例，每秒3000次取样，每个取样是7比特，那么电话的比特率是21000。 而CD是每秒 44100次取样，两个声道，每个取样是13位PCM编码，所以CD的比特率是44100213=1146600，也就是说CD每秒的数据量大约是 144KB，而一张CD的容量是74分等于4440秒，就是639360KB＝640MB。

4、多码流  
转码是视频转码技术将视频信号从一种格式转换成另一种格式。它具有两个面向不同领域的重要功能。首先是在传统设备和新兴设备之间实现通信。  
例如，许多现有的视频会议系统是基于旧的视频编码标准H.263而建立，而最新的视频会议系统采用了H.264基线规范。因此，实时视频转码技术是实现两者之间通信的必不可少因素。

多码流技术是通过在编码过程中同时产生多种不同码流及分辨率的流媒体数据，根据用户实际网络带宽条件为之自动分配相对最佳解码画质的解决方案。在实际网络直播应用中，由于位于不同网络位置的访问者所在网络环境存在差异，而仅以某种固定码流分辨率进行网络直播流媒体传送往往会导致网速较高的用户看到的画质仍不够清晰，网速较低的用户解码时间过长而使得画面不够流畅，为解决二者的矛盾使访问者浏览到尽可能看到兼顾清晰和流畅的直播内容，采用多码流技术成为了一个最简单最有效的办法。

5、RTMP \\ RTSP \\ HLS  
5.1、RTMP  
RTMP——Real Time Messaging Protocol（实时消息传输协议），是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。

传输  
RTMP在TCP/IP五层体系结构中应用层，基于TCP协议，能够为数据的传输提供可靠保障，因此数据在网络上传输不会出现丢包的情况。不过这种可靠的保障也会造成一些问题，也就是说前面的数据包没有交付到目的地，后面的数据也无法进行传输。幸运的是，目前的网络带宽基本上可以满足RTMP协议传输普通质量视频的要求。

特点  
RTMP视频播放的特点：

1、RTMP协议是采用实时的流式传输，所以不会缓存文件到客户端，所以想下载RTMP协议下的视频是比较难的；

2、 视频流可以随便拖动，既可以从任意时间点向服务器发送请求进行播放，并不需要视频有关键帧。相比而言，HTTP协议下视频需要有关键帧才可以随意拖动。

3、 RTMP协议支持点播/回放（通俗点将就是支持把flv,f4v,mp4文件放在RTMP服务器，客户端可以直接播放），直播（边录制视频边播放）。

4、 市场支持度

Adobe支持得很好，RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器（摄像头之类）都支持RTMP输出。

Flash对RTMP支持得非常好。所以在浏览器中很容易播放

5、 适合长时间播放：

因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流。

6、 延迟与质量：

RTMP保证了视频的传输质量，但是其传输延迟相对较高，传输效率相对较低。

比起YY的UDP私有协议，RTMP算延迟大的（延迟在1-3秒），

比起HTTP流的延时（一般在10秒以上）RTMP算低延时。

一般的直播应用，只要不是电话对话的那种要求，RTMP延迟是可以接受的。

在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，

7、 有累积延迟：

RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。

所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；

待网络状况好了，就一起发给客户端。

这个的对策就是，当客户端的缓冲区很大，就断开重连。

适用场景  
语音通话、网络直播 推流、拉流 等

变种  
RTMP变种：

1)RTMP工作在TCP之上，默认使用端口1935；

2)RTMPE在RTMP的基础上增加了加密功能；

3)RTMPT封装在HTTP请求之上，可穿透防火墙；

4)RTMPS类似RTMPT，增加了TLS/SSL的安全功能；

协议内容  
RTMP 一般采用flv，f4v作为封装格式，H.264作为视频编码格式，AAC作为音频编码格式。

RTMP传输的数据的基本单元为Message，但是实际上传输的最小单元是Chunk（消息块），因为RTMP协议为了提升传输速度，在传输数据的时候，会把Message拆分开来，形成更小的Chunk块。

消息（Message）的结构

消息的结构  
Message结构分析  
![3c872d4f7b40494f9fcbaa436e6ac60a.png][]

1.Message Type：它是一个消息类型的ID，通过该ID接收方可以判断接收到的数据的类型，从而做相应的处理。Message Type ID在1-7的消息用于协议控制，这些消息一般是RTMP协议自身管理要使用的消息，用户一般情况下无需操作其中的数据。Message Type ID为8，9的消息分别用于传输音频和视频数据。Message Type ID为15-20的消息用于发送AMF编码的命令，负责用户与服务器之间的交互，比如播放，暂停等。

2.Playload Length： 消息负载的长度，即音视频相关信息的的数据长度，4个字节

3.TimeStamp：时间戳，3个字节。

4.Stream ID：消息的唯一标识。拆分消息成Chunk时添加该ID，从而在还原时根据该ID识别Chunk属于哪个消息。

5.Message Body：消息体，承载了音视频等信息。  
**消息块（Chunk）**![0f623098059441ae85d1d5367e3eaeea.png][]

通过上图可以看出，消息块在结构上与与消息类似，有Header和Body。

1.Basic Header：基本的头部信息，在头部信息里面包含了chunk stream ID（流通道Id，用来标识指定的通道）和chunk type（chunk的类型）。

2.Message Header：消息的头部信息，包含了要发送的实际信息（可能是完整的，也可能是一部分）的描述信息。Message Header的格式和长度取决于Basic Header的chunk type。

3.Extended TimeStamp：扩展时间戳。

4.Chunk Data：块数据。

RTMP在传输数据的时候，发送端会把需要传输的媒体数据封装成消息，然后把消息拆分成消息块，再一个一个进行传输。接收端收到消息块后，根据Message Stream ID重新将消息块进行组装、组合成消息，再解除该消息的封装处理就可以还原出媒体数据。由此可以看出，RTMP收发数据是以Chunk为单位，而不是以Message为单位。需要注意的是，RTMP发送Chunk必须是一个一个发送，后面的Chunk必须等前面的Chunk发送完成。

5.2、RTSP  
RTSP(Real Time Streaming Protocol)

RTSP （Real-Time Stream Protocol）由Real Networks 和 Netscape共同提出的，基于文本的多媒体播放控制协议。

传输  
RTSP 在TCP/IP五层体系结构中应用层，基于TCP、UDP协议。实际上公网环境下大量的UDP包，容易被防火墙block住，相对靠谱的模式，是rtsp over http tunnel。

流数据本身的传输不是RTSP的任务。大多数RTSP服务器使用实时传输协议（RTP）和实时传输控制协议（RTCP）结合媒体流传输。

虽然在某些方面与HTTP类似，RTSP定义了控制多媒体播放控制顺序。虽然HTTP是无状态的，但RTSP具有状态; 当需要跟踪并发会话时使用标识符。像HTTP一样，RTSP使用TCP来维护端到端连接，而大多数RTSP控制消息由客户端发送到服务器，一些命令沿着另一个方向（即从服务器到客户端）传播。一般需要2-3个通道，命令和数据通道分离

特点  
1、RTSP提供一 种可扩展的框架，使能够提供可控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据输出和存贮的文件。

2、 rtsp对流媒体提供了诸如暂停，快进等控制，相当于流媒体服务器的远程控制。

3、 市场支持度：

该视频流技术实现复杂，而且对浏览器很挑剔，且flash插件播不了

4、 延迟与质量：

实时效果非常好，在网络环境比较稳定的情况下，传输效率是比较高的。

适用场景  
RTSP实时效果非常好，适合视频聊天，视频监控等方向。

协议内容  
RTSP可传输TS，MP4格式流

简单的RTSP消息交互过程

C表示RTSP客户端,S表示RTSP服务端

第一步：查询服务器端可用方法

C->S OPTION request //询问S有哪些方法可用

S->C OPTION response //S回应信息的public头字段中包括提供的所有可用方法

第二步：得到媒体描述信息

C->S DESCRIBE request //要求得到S提供的媒体描述信息

S->C DESCRIBE response //S回应媒体描述信息，一般是sdp信息

第三步：建立RTSP会话，告诉服务器客户端用于接收媒体数据的端口。

C->S SETUP request //通过Transport头字段列出可接受的传输选项，请求S建立会话

S->C SETUP response //S建立会话，通过Transport头字段返回选择的具体转输选项，并返回建立的Session ID;

第四步：请求开始传送数据，客户端发送一个播放命令(PLAY)，服务器就开始在UDP上传送媒体流（RTP包）到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。

C->S PLAY request //C请求S开始发送数据

S->C PLAY response //S回应该请求的信息

第五步： 数据传送播放中

S->C 发送流媒体数据 // 通过RTP协议传送数据

第六步：关闭会话，退出

C->S EARDOWN request //C请求关闭会话

S->C TEARDOWN response //S回应该请求

上述的过程只是标准的、友好的rtsp流程，但实际的需求中并不一定按此过程。 其中第三和第四步是必需的！第一步，只要服务器和客户端约定好有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则我们也不需要通过rtsp中的describe请求来完成。

5.3、 HLS  
HLS （ HTTP Live Streaming）苹果公司提出的流媒体协议，直接把流媒体切片成一段段，信息保存到m3u列表文件中，可以将不同速率的版本切成相应的片；

HLS视频流传输是将整个视频流分成一个个小切片，通过HTTP文件来下载——先下载，后观看。

传输  
基于Http的流媒体网络传输协议

特点  
HLS 几乎可随处播放。 几个大平台 web、mobile、tv 基本都有免费的HLS 播放器支持。

HLS 是苹果推出的流媒体协议，在 iOS 平台上可以获得天然的支持，采用系统提供的 AVPlayer 就能直接播放

HLS 相对简单。 它使用了普遍且已经存储的视频格式(MP4 或 TS，伴随着 H.264 和 AAC 等编解码器), 另外附加了一个丑陋但人类可读的文本格式(m3u8).

HLS通过 HTTP 工作。 不需要跑特殊的服务(不像老旧校风派的 RTMP 协议或者新潮的 WebRTC 协议). HLS 可以方便的透过防火墙或者代理服务器，而且可以很方便的利用 CDN 进行分发加速，并且客户端实现起来也很方便。

使用短时长的分片文件来播放，客户端可以平滑的切换码率，以适应不同带宽条件下的播放。

HLS 视频流协议也存在较为致命的缺陷，那就是网络延时太高。

用户观看视频实际上是下载这些小的视频切片，每次只下载一些，苹果官方建议是请求到3个片之后才开始播放，若是直播，时延将超10秒，所以比较适合于点播。因此HLS视频的切片一般建议10s，时间间隔太短就切容易造成碎片化太严重不方便数据存储和处理，太长容易造成时延加重。

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

通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。  
HLS 基于短连接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 需要不断地与服务器建立连接，TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。

适用场景  
不适合直播，适合视频点播。

协议内容  
HLS 协议基于 HTTP，而一个提供 HLS 的服务器需要做两件事：

编码： 以 H.264 格式对图像进行编码，以 MP3 或者 HE-AAC 对声音进行编码，最终打包到 MPEG-2 TS（Transport Stream）容器之中；  
分割： 把编码好的 TS 文件等长切分成后缀为 ts 的小文件，并生成一个 .m3u8 的纯文本索引文件

HLS 把整个流分成一个个小的基于 HTTP 的文件来下载，每次只下载一些。HLS 协议由三部分组成：HTTP、M3U8、TS。这三部分中，HTTP 是传输协议，M3U8 是索引文件，TS 是音视频的媒体信息。

HLS的index文件就是m3u8的文件，先下载一级index file（master\_playlist.m3u8），它里面记录了二级索引文件的地址（Alternate-A、Alternate-B、Alternate-C）的地址，然后客户端再去下载二级索引文件，二级索引文件中又记录了TS文件的下载地址，这样客户端就可以按顺序下载TS视频文件并连续播放。

可以简单的认为二级 m3u8 就是包含多个 ts 文件的播放列表。播放器按顺序逐个播放，全部放完再请求一下 m3u8 文件，获得包含最新 ts 文件的播放列表继续播，周而复始。整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成，m3u8 必须动态更新，ts 可以走 CDN。

HLS的架构分为三部分：Server，CDN，Client 。即服务器、分发组件和客户端。架构图如下：  
![12c71ab294f44949bc195b4d1900dad7.png][]

### 总结： ###

理论上RTSP 、RTMP、 HLS都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HLS。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。![80b04b9e4f8b49438808fda295e88fd0.png][]

[3c872d4f7b40494f9fcbaa436e6ac60a.png]: https://img-blog.csdnimg.cn/3c872d4f7b40494f9fcbaa436e6ac60a.png
[0f623098059441ae85d1d5367e3eaeea.png]: https://img-blog.csdnimg.cn/0f623098059441ae85d1d5367e3eaeea.png
[12c71ab294f44949bc195b4d1900dad7.png]: https://img-blog.csdnimg.cn/12c71ab294f44949bc195b4d1900dad7.png
[80b04b9e4f8b49438808fda295e88fd0.png]: https://img-blog.csdnimg.cn/80b04b9e4f8b49438808fda295e88fd0.png