“深入浅出”系列之音视频开发：（5）流媒体详解

一、流

首先说一下流的概念，在编程中，流（Stream）是一种用来顺序传输数据的抽象，数据可以是输入的（如从键盘、文件或网络读取）或者是输出的（如打印到屏幕或写入文件）。C语言中的流是通过标准库实现的。

流的分类

1.标准输出流（stdin）

用于接收用户输入，类似键盘输入这种，默认缓冲方式为行缓冲，即当检测到换行符或缓冲区满时会提交数据。

2.标准输入流（stdout）：

用于输出到屏幕，默认缓冲方式也为行缓冲。

3.标准错误流（stderr）：

用于输出错误信息，一般采取立即输出的方式。

setvbuf函数用于控制流的缓冲区行为。

函数原型：

int setvbuf(FILE *stream, char *buf, int mode, size_t size);

stream：指向需要设置缓冲区的流（stdin，stdout）

buf：指向缓冲区的指针。

mode：表示缓冲方式，值为0表示全缓冲（只有缓冲区填满才会输出）；值为1表示行缓冲（当遇到换行符或缓冲区满时输出）；值为2表示无缓冲（数据直接输出）。

size：表示缓冲区大小。

返回值：如果返回0表示函数调用成功，缓冲区设置成功。反之，函数调用失败。

案例：

这里提供了ctfshow pwn入门的第19题的ida反编译出的伪代码（c）：

int __cdecl main(int argc, const char **argv, const char **envp)
{char buf; // [rsp+10h] [rbp-30h]unsigned __int64 v5; // [rsp+38h] [rbp-8h]v5 = __readfsqword(0x28u);setvbuf(_bss_start, 0LL, 2, 0LL);setvbuf(stdin, 0LL, 1, 0LL);puts(s);puts(asc_BF0);puts(asc_C70);puts(asc_D00);puts(asc_D90);puts(asc_E18);puts(asc_EB0);puts("    * *************************************                           ");puts(aClassifyCtfsho);puts("    * Type  : Linux_Security_Mechanisms                               ");puts("    * Site  : https://ctf.show/                                       ");puts("    * Hint  : Turn off output, how to get flag? ");puts("    * *************************************                           ");if ( fork() ){wait(0LL);sleep(3u);printf("flag is not here!");}else{puts("give you a shell! now you need to get flag!");fclose(_bss_start);read(0, &buf, 0x20uLL);system(&buf);}return 0;
}

关注其中的setvbuf函数：

1. setvbuf(_bss_start, 0LL, 2, 0LL)：
_bss_start：这是一个程序链接脚本中定义的符号，是由编译器或链接器在构建程序的过程中生成的符号之一。它通常用来标识程序的 BSS（Block Started by Symbol）段的起始地址，在这里_bss_start被用作一个文件流的指针，类似stdout的输出流。

（tips：bss段用于存储未初始化的全局变量和静态变，这些变量在程序运行时会被自动初始化为0。）

0LL（第一个）：参数为NULL，表示使用默认的缓冲区。

2：设置_bss_start流为无缓冲模式，数据会直接写入目标，不i经过缓冲。

0LL（第二个）：参数为0，因为这里是无缓冲模式，所以忽略缓冲区大小的作用。

2.setvbuf(stdin, 0LL, 1, 0LL)：
stdin：设置标准输入流的缓冲行为。

0LL（第一个）：参数为NULL，表示使用默认的缓冲区。

1：标准输入流采用行缓冲模式，只有检测到换行符或缓冲区满时才会处理输入。

0LL（第二个）：参数为0，配合行缓冲模式会禁用行缓冲，将流改为非缓冲模式。

实际达成效果为：标准输入流的数据不会被存储到缓冲区中，而是直接读取每一个字符，每次输入都会立刻触发读取操作，适用于需要实时交互的场景。

二、流媒体

1 概述

流媒体（streaming media）技术，是指将一连串的多媒体数据压缩后，以流的方式在网络中分段经过互联网发送数据，在互联网上即时传输影音，以供用户观赏的一种技术。多媒体数据不断由流媒体提供商发送到客户端，而客户不需要将整个多媒体数据下载到本地，就可以开始播放的多媒体。

在流媒体技术出现之前，人们必须要先下载多媒体内容到本地计算机，等待完整的多媒体内容下载完成之后，才能够欣赏多媒体的内容。流媒体技术的出现，使人们只需经过几秒或十几秒的启动延时即可欣赏媒体内容，而无需再等待媒体内容完全下载完成了。

流媒体技术使得数据包可以像流水一样发送，如果不使用此技术，用户就必须先下载整个媒体文件，而后才能使用多媒体数据。通过流媒体技术，可将现场或预存于服务器上的影音传送至观看者端，当影音数据传送至观看者的计算机后，即可立即通过特定的播放软件欣赏影音数据。

流媒体实际指的是一种新的媒体传送方式，有声音流、视频流、文本流、图像流、动画流等，而非一种新的媒体。传统的视频监控、IPTV，以及这几年兴起的视频直播、网络授课都属于流媒体的范畴，从广义上来讲，视频通话，视频会议也属于流媒体。

2 流媒体（技术）的特征

流媒体包括声音流、视频流、文本流、图像流、动画流等，在时间上连续的媒体数据。

流媒体技术具有以下几个特征：

①具有较强的实时性和交互性；通过利用流媒体技术，用户侧的媒体启动时间大幅度缩短，用户不必像以往那样“等到所有媒体内容都下载完成后上才能浏览”，而是经过一段启动延时后，立即就能欣赏媒体内容；

②与传统的媒体传输方式相比，流媒体技术对客户端（用户计算机）的缓存容量要求大大降低，Internet 是以包传输为基础进行的异步传输，因此数据会被分解成许多包进行传输，由于每个数据包可能选择不同的路由（进行传输），所以这些数据包到达客户端（用户计算机）的时间延迟就会不同，因此在客户端就需要缓存系统来消减延迟和抖动的影响，以及保证接收到数据包的传输顺序的准确性。与传统的（完整）媒体传输方式相比，在流媒体文件的播放过程中，由于不再需要把所有的文件都放入缓存系统，因此对缓存容量的要求是很低的。

3 流式传输

流媒体技术的特征就是流式传输，它使得流媒体数据可以像流水一样传输。

流式传输主要包括两种实现方式：顺序流式传输（progressive streaming）和实时流式传输（real time streaming）。需要根据具体需求决定采用哪种方式进行流式传输，下面就对这两种传输方式进行简单介绍。

3.1 顺序流式传输

在顺序流式传输模式下，用户在观看在线媒体的同时，也在下载文件。在这个过程中，用户只能观看已经下载完成的媒体内容，而不能直接观看未下载的部分。因此，用户会在一段延时后，才能看到服务器传送过来的媒体内容。由于标准的HTTP服务器就可以发送这种形式的媒体文件，因此流式传输也经常被称为HTTP流式传输。

由于顺序流式传输能够较好地保证节目的播放质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。

顺序流式传输的文件存放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。

所以顺序流式传输主要提现了流媒体的基本功能：无需下载完整的媒体文件，即可欣赏媒体内容。

3.2 实时流式传输

使用实时流式传输时，必须要保证与流媒体对应的带宽，以使媒体内容可以被用户实时观看到。用户在观看过程中，可以任意观看当前媒体内容之前或后面的内容。但是在这种传输方式中，如果网络状况不理想，会导致收到的图像质量比较差。

实时流式传输需要特定的服务器（如Windows Media Server），这些服务器可以对媒体进行更多的控制，所以系统设置、管理比标准HTTP服务器更加复杂。

实时流式传输还需要特殊的网络协议，如RTSP(realtime streaming protocol)或MMS(microsoft media server)。防火墙有时会对这些协议进行屏蔽，导致用户看不到不实时内容。

所以实时流式传输”更强度的是媒体传输的“实时性”，因此目前流行的视频直播行业，应属于“实时流式传输”功能的应用。

4 流媒体传输的网络协议

流媒体传输一般采用HTTP/TCP(RTCP)协议来传输控制信息，而用UDP(RTP)协议来传输实时媒体数据（TCP开销相对较大，所以不太适合传输实时数据）。

4.1 RTP

RTP（Real-time Transport Protocol，实时传输协议）通常用于实时数据的传输工作（一般使用UDP来传送数据）。

当应用程序开始一个RTP会话时，将开启两个端口：一个给RTP，一个给RTCP。RTP本身并不能为“按顺序传输数据包”提供可靠的传输送制，也不提供流量控制和拥塞控制服务，而是依赖RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分来实现的。

4.2 RTCP

RTCP（Real-time Transport Control Protocol，实时传输控制协议）在RTP传输实时数据时，提供流量控制和拥塞控制服务。在RTP会话期间各参与者会周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTP和RTCP配合使用，能通过有效的反馈和最小的开销，使传输效率最佳化，因此特别适合在互联网上传输实时数据。

4.3 RTSP

RTSP（Real Time Streaming Protocol，实时流协议）定义了一对多模式下如何有效地通过IP网络传送多媒体数据。

RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP(RTP)协议完成数据传输，如下图4.3-1（RTSP在网络体系结构中的位置）所示。

5 流媒体系统组成

①编码工具：用于创建、捕捉和编辑多媒体数据，形成流媒体格式；
②流媒体数据；
③服务器：存放和控制流媒体的数据；
④网络：适合多媒体传输协议（甚至是实时传输协议）的网络；
⑤播放器：客户端通过播放器浏览流媒体文件。

以上五个部分有些是服务器需要的，有些是客户端需要的，而且不同的流媒体标准和不同公司的解决方案中，会在有些内容上有所不同。

6 流媒体技术涉及到的关键技术

流媒体技术不是一个单一的技术，它是网络技术与视音频技术的有机结合。

实现流媒体技术，需要解决流媒体的制作、发布、传输和播放等方面的问题，这些问题的解决需要利用到视音频技术和网络技术。下面具体讨论一下流媒体的这几个问题。

6.1 流媒体的制作

只有适合流媒体传输的流媒体格式文件才能在互联网上传输。因为一般的多媒体格式文件体积很大，因此在网络上传输时需要花费较长的时间，如果遇到网络繁忙等情况，还会造成传输中断。另外，一般格式的媒体文件也不能通过流媒体传输协议进行传输。

因此，需要先对待传输的文件进行预处理，将文件压缩成流媒体格式文件。此处主要包括两个要点：一是选用适当的压缩算法进行压缩，确保生成的文件体积较小；二是需要向文件中添加流式信息。

6.2 流媒体的传输

流媒体的传输需要合适的传输协议，在Internet上进行的文件传输大部分都建立在TCP协议的基础上，也有一些是通过FTP进行传输，但采用这些传输协议都不能满足流媒体的实时传输要求。

随着流媒体技术的深入研究，比较成熟的流媒体传输一般都是采用建立在UDP协议上的RTP/RTSP等实时传输协议。

为何要在UDP而不在TCP上进行实时数据的传输呢？因为两者在数据传输的速度和可靠性方面有很大的区别。TCP协议中包含了专门的数据传送校验机制，当数据接收方收到数据后，会自动向发送方发出确认信息，发送方在接收到该确认信息后，才会继续传送数据，否则将一直处于等待状态；而UDP协议则不同，UDP协议本身并不做任何数据传输校验。由此可以看出：TCP协议注重传输质量，而UDP协议则注重传输速度。因此，对于那些对传输质量要求不是很高，而对传输速度有很高要求的流媒体文件来说，采用UDP协议传输更为合适。

用户通过Web浏览器播放流媒体时，主要的交互过程如下：

用户选择流媒体服务后，Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来；
Web浏览器启动A/V Helper程序，使用HTTP从Web服务器检索相关参数，然后对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型，或与A/V检索相关的服务器地址；
A/V Helper程序及A/V服务器运行RTSP协议，以交换A/V传输所需的控制信息。与CD播放机或VCRs所提供的功能类似，RTSP提供了控制播放、快进、快倒、暂停及录制等命令的方法；
A/V服务器使用RTP/UDP协议，将A/V数据传输给A/V客户程序（一般可认为客户程序等同于A/V Helper程序）；
当A/V数据抵达客户端时，A/V客户程序即可播放A/V数据了。
需要说明的是，在流媒体传输过程中，使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系，是为了能够把服务器的输出重定向到一个不同于运行A/V Helper程序所在客户端的目的地址。实现流式传输一般都需要专用服务器和播放器。

6.3 流媒体数据在客户端的缓存

在流媒体传输和播放过程中，客户端的缓存技术能够确保视音频数据正确、连续地播放。

6.3.1 纠正数据包顺序的缓存技术

因为Interent是以包为单位进行异步传输的，因此多媒体数据在传输中要被分解成许多包，由于网络传输的不稳定性，各个包选择的路由可能不同，所以到达客户端的时间次序就可能发生改变，甚至出现丢包的现象。因此，必须采用缓存技术来纠正数据包到达次序混乱的情况，利用缓存技术对到达的数据包进行正确排序，从而使视音频数据能正确地播放。

从技术角度来讲，纠正数据包顺序的缓存技术，属于流媒体传输过程接收侧的功能，主要目的是保证视音频内容可以正确地播放。

6.3.2 播放缓冲区

流媒体技术需要在客户端的计算机上创建一个缓冲区，在播放前预先下载一段多媒体数据作为缓冲，在网络实际传输速度小于媒体播放所需的速度时，播放程序就会取用一小段缓冲区内预先存储的数据，这样就可以避免播放内容的中断，保证了视频播放品质。

在流媒体传输模式下，缓存中存储的是某一段时间内的数据，数据在缓存中存放的时间是暂时的，缓存中的数据也是动态的、不断更新的，流媒体在播放时不断读取缓存中的数据，播放完成后该数据就会被立即清除，新的数据又将存入到缓存中。因此，在播放流媒体文件时并不需要占用太大的缓存空间。

从技术角度来讲，播放缓冲区技术，属于客户端播放器的功能，主要目的是（在不太损失实时性的前提下）保证视音频内容可以连续地播放。

6.4 流媒体的播放

流媒体只能在支持对应的流媒体格式的播放器（浏览器）中正常播放。

7 流媒体服务器

流媒体服务器是流媒体应用的核心系统，主要包括流媒体的编码、转码、分发、存储等功能，是向用户提供视频服务的关键平台。

从播放模式方面来看，流媒体服务器的主要包括以下两种模式：

以流式协议（RTP/RTSP、MMS、RTMP等）将视频文件传输到客户端，供用户在线观看，即“点播模式”；
从视频采集、压缩软件接收实时视频流，再以流式协议直播给客户端，即“直播模式”。
流媒体应用的主要性能取决于媒体服务器的性能和服务质量。因此，流媒体服务器既是流媒体应用系统的基础，也是最主要的组成部分。

8 流媒体与传统媒体

流媒体与传统媒体相比，区别如下：

欣赏媒体内容的即时性：因为视音频文件（特别是视频文件）容量一般都很大，受到网络带宽的限制，下载一个视音频文件可能需要几分钟甚至几小时，因此导致传输媒体的欣赏时延很大；而通过利用流媒体技术，多媒体文件一边被下载一边被播放，用户可以即时地欣赏到多媒体内容了（即点即看）。此外，目前流行的视频直播相关行业，也是流媒体技术非常重要的应用场景。
对客户端的存储容量要求：传统媒体需要下载完整的媒体文件，而媒体文件的容量一般都很大，所以需要占用客户端较大的存储空间；而通过利用流媒体技术，不需要占用客户端太大的缓存容量，也可以欣赏到媒体内容了。

9 流媒体技术的应用前景

互联网的迅猛发展和普及，为流媒体业务的发展提供了强大的市场动力，流媒体行业正在蓬勃发展。流媒体技术（及流媒体直播技术）广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、实时视频会议等互联网信息服务的方方面面。不难看出，在未来，流媒体技术的应用将会为网络信息交流带来革命性的变化，也将对人们的工作和生活产生深远的影响。

流媒体文件格式是支持采用流式传输及播放的媒体格式。常用格式有：

RA：实时声音；

RM：实时视频或音频的实时媒体；

RT：实时文本；

RP：实时图像；

SMII.：同步的多重数据类型综合设计文件；

SWF：real flash和shockwavc flash动面文件；

RPM: HTMI。文件的插件；

RAM：流媒体的源文件，是包含RA、RM、SMIIJ文件地址（URL地址）的文本文件；

CSF：一种类似媒体容器的文件格式，可以将非常多的媒体格式包含在其中，而不仅仅限于音、视频。quicktime，mov，asf，wmv，wma，avi，mpeg，mpg，dat，mts； aam多媒体教学课件格式，可将authorware生成的文件压缩为aam和aas流式文件播放。

流媒体特征

(1)内容主要是时间上连续的媒体数据(音频、视频、动画、多媒体等)。

(2)内容可以不经过转换就采用流式传输技术传输。

(3)具有较强的实时性，交互性。

(4)启动延时大幅度缩短，缩短了用户的等待时间；用户不用等到所有内容都下载到硬盘上才能开始浏览，在经过一段启动延时后就能开始观看。

(5)对系统缓存容量的要求大大降低。

Internet是以包传输为基础进行的异步传输，数据被分解成许多包进行传输，由于每个包可能选择不同的路由，所以到达用户计算机的时间延迟就会不同，而在客户端就需要缓存系统来弥补延迟和抖动的影响以及保证数据包传输的顺序。在流媒体文件的播放过程中，由于不再需要把所有的文件都下载到缓存，因此对缓存的要求很低。

流式传输方式

流媒体最主要的技术特征就是流式传输，它使得数据可以像流水一样传输。

流式传输是指通过网络传送媒体(音频、视频等)技术的总称。实现流式传输主要有两种方式：顺序流式传输( progressive streaming)和实时流式传输( real time streaming)。采用哪种方式依赖于具体需求，下面就对这两种方式进行简要的介绍。

顺序流式传输

顺序流式传输是顺序下载，用户在观看在线媒体的同时下载文件，在这一过程中，用户只能观看下载完的部分，而不能直接观看未下载部分。也就是说，用户总是在一段延时后才能看到服务器传送过来的信息。由于标准的HTTP服务器就可以发送这种形式的文件，它经常被称为HTTP流式传输。

由于顺序流式传输能够较好地保证节目播放的质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。

顺序流式文件是放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如：讲座、演说与演示。它也不支持现场广播。

实时流式传输

实时流式传输必须保证匹配连接带宽，使媒体可以被实时观看到。在观看过程中用户可以任意观看媒体前面或后面的内容，但在这种传输方式中，如果网络传输状况不理想，则收到的图像质量就会比较差实时流式传输需要特定服务器，如 Quick Time Streaming Server、 Realserver或 Windows Media server。这些服务器允许对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如：RTSP（realtime streaming protocol）或MMS（microsoft media server）。在有防火墙时，有时会对这些协议进行屏闭，导致用户不能看到一些地点的实时内容，实时流式传输总是实时传送，因此特别适合现场事件。

流媒体传输的网络协议

TCP需要较多的开销，故不太适合传输实时数据；流式传输一般采用HTTP/TCP(RTCP)来传输控制信息，而用RTP/UDP(RTP)来传输实时声音数据。

实时传输协议RTP

实时传输协议RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步；RTP通常使用UDP来传送数据；当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务；通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。

实时传输控制协议RTCP

实时传输控制协议RTCP和RTP一起提供流量控制和拥塞控制服务；在RTP会话期间各参与者周期性地传送RTCP包；RTCP包中含有已发送的数据包的数量、丢失的数据包数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特适合传送网上的实时数据。

实时流协议RTSP

实时流协议RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据；RTSE在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输；HTTP与RTSP相比，HTTP传送HTML超链接文档，而RTSP传送的是多媒体数据；HTTP请求由客户机发出，服务器做出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。点对点的手机可视通话，必须在手机终端实现RTSP。

文件格式

在运用流媒体技术时，音视频文件要采用相应的格式，不同格式的文件需要用不同的播放器软件来播放。采用流媒体技术的音视频文件主要有以下几种：

①微软的ASF（advanced stream format）。这类文件的扩展名是．asf和.wmv，与它对应的播放器是微软公司的Media Player。用户可以将图形、声音和动画数据组合成一个ASF格式的文件，也可以将其他格式的视频和音频转换为ASF格式，而且用户还可以通过声卡和视频捕获卡将诸如麦克风、录像机等外设的数据保存为ASF格式。

②RealNetworks公司的ReaIMedia。它包括RealAudio、RealVideo和RealFlash三类文件，其中RealAudio用来传输接近CD音质的音频数据，RealVideo用来传输不间断的视频数据，RealFlash则是ReaINetworks公司与Macromedia公司联合推出的一种高压缩比的动画格式，这类文件的扩展名是.rm、.ra、.rmvb，文件对应的播放器是ReaIPlayer。

③苹果公司的QuickTime。这类文件扩展名通常是.mov，它所对应的播放器是QuickTime。

此外，MPEG、AVI、DVI、SWF等都是适用于流媒体技术的文件格式。

系统组成

流媒体系统包括以下5个方面的内容：

(1)编码工具：用于创建、捕捉和编辑多媒体数据，形成流媒体格式。

(2)流媒体数据。

(3)服务器：存放和控制流媒体的数据。

(4)网络：适合多媒体传输协议甚至是实时传输协议的网络。

(5)播放器：供客户端浏览流媒体文件。

这5个部分有些是服务器端需要的，有些是客户端需要的，而且不同的流媒体标准和不同公司的解决方案会在某些方面有所不同。

关键技术

流媒体技术不是一种单一的技术，它是网络技术及视/音频技术的有机结合。在网络上实现流媒体技术，需要解决流媒体的制作、发布、传输及播放等方面的问题，而这些问题则需要利用视音频技术及网络技术来解决，具体如下：

（1）流媒体制作技术方面解决的问题

在网上进行流媒体传输，所传输的文件必须制作成适合流媒体传输的流媒体格式文件。因为通常格式存储的多媒体文件容量十分大，若要在现有的窄带网络上传输则需要花费十分长的时间，若遇网络繁忙，还将造成传输中断。另外，通常格式的流媒体也不能按流媒体传输协议进行传输。因此，对需要进行流媒体格式传输的文件应进行预处理，将文件压缩生成流媒体格式文件。这里应注意两点：一是选用适当的压缩算法进行压缩，这样生成的文件容量较小；二是需要向文件中添加流式信息。

（2）流媒体传输方面需解决的问题

流媒体的传输需要合适的传输协议，在internet上的文件传输大部分都是建立在tcp协议的基础上，也有一些是以ftp传输协议的方式进行传输，但采用这些传输协议都不能实现实时方式的传输。随着流媒体技术的深入研究，实时传输协议。

为何要在udp协议而不在tcp协议上进行实时数据的传输呢？这是因为udp和tcp协议在实现数据传输时的可靠性有很大的区别。tcp协议中包含了专门的数据传送校验机制，当数据接受方收到数据后，将自动向发送方发出确认信息，发送方在接收到确认信息后才继续传送数据，否则将一直处于等待状态。而udp协议则不同，udp协议本身并不能做任何校验。由此可以看出，tcp协议注重传输质量，而udp协议则注重传输速度。因此，对于对传输质量要求不是很高，而对传输速度则有很高的要求的视音频流媒体文件来说，采用udp协议则更合适。

（3）流媒体的传输过程中需要缓存的支持

因为interent是以包为单位进行异步传输的，因此多媒体数据在传输中要被分解成许多包，由于网络传输的不稳定性，各个包选择的路由不同，所以到达客户端的时间次序可能发生改变，甚至产生丢包的现象。为此，必须采用缓存技术来纠正由于数据到达次序发生改变而产生的混乱状况，利用缓存对到达的数据包进行正确排序，从而使视音频数据能连续正确地播放。缓存中存储的是某一段时间内的数据，数据在缓存中存放的时间是暂时的，缓存中的数据也是动态的，不断更新的。流媒体在播放时不断读取缓存中的数据进行播放，播放完后该数据便被立即清除，新的数据将存入到缓存中。因此，在播放流媒体文件时并不需占用太大的缓存空间。

（4）流媒体播放方面需解决的问题

流媒体播放需要浏览器的支持．通常情况下，浏览器是采用mime来识别各种不同的简单文件格式，所有的web浏览器都是基于http协议，而http协议都内建有mime．所以web浏览器能够通过http协议中内建的mime来标记web上众多的多媒体文件格式，包括各种流媒体格式。

技术应用

互联网的迅猛发展和普及为流媒体业务发展提供了强大市场动力，流媒体业务正变得日益流行。流媒体技术广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、实时视频会议等互联网信息服务的方方面面。流媒体技术的应用将为网络信息交流带来革命性的变化，对人们的工作和生活将产生深远的影响。

延伸阅读

流媒体技术是指将一连串的媒体数据压缩后，以流的方式在网络中分段传送，是一种网络媒体数据实时传输技术。流媒体包含声音流、视频流、文本流、图像流、动画流等。

流媒体最主要的技术特征就是流式传输，实现流式传输主要有两种方式：顺序流式传输和实时流式传输。

顺序流式传输的特征是顺序下载，用户在观看在线媒体的同时下载文件。在这一过程中，用户只能观看下载完的部分，而不能直接观看未下载部分。也就是说，用户总是在一段延时后才能看到服务器传送过来的信息。由于标准的HTTP服务器就可以发送这种形式的文件，它也被称为HTTP流式传输。由于顺序流式传输能够较好地保证节目播放的质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。

实时流式传输必须保证匹配连接带宽，使媒体可以被实时观看到。在观看过程中用户可以任意观看媒体前面或后面的内容，但在这种传输方式中，如果网络传输状况不理想，则收到的图像质量就会比较差。实时流式传输需要特定服务器。这些服务器会在媒体发送时进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议。在有防火墙时，有时会对这些协议进行屏闭，导致用户不能看到一些地点的实时内容。实时流式传输总是实时传送，因此特别适合现场事件。

流媒体技术广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、实时视频会议等互联网信息服务的方方面面。

WebRTC是一种开源的实时通信技术，允许在浏览器间进行音视频和数据的直接传输，无需额外插件。其关键组件包括GetUserMedia()、RTCPeerConnection()和RTCDataChannel()。相比于WebSocket，WebRTC专为高质量、低延迟的音视频通信设计，使用UDP协议，并且在建立连接后可实现端到端通信，降低了服务器负载。
摘要由CSDN通过智能技术生成
1、流媒体(Streaming Media)指在数据网络上按时间先后次序传输和播放的连续音/视频数据流。

2、流媒体数据流具有三个特点：连续性(Continuous) 、实时性(Real - time) 、时序性，即其数据流具有严格的前后时序关系。

3、根据上述分类，常见的流媒体的应用主要有：视频点播(VOD)、视频广播、视频监视、视频会议、远程教学、交互式游戏等。

前端技术点：websocket、webrtc

学习webrtc：
1、WebRTC，网页即时通讯（英语：Web Real-Time Communication），是直接在 Web 浏览器内驱动实时通信（语音、视频和任意数据）方法的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准，并于 2011 年标准化。谷歌开源的一款产品。且这个技术可以使很多不同的应用，如视频会议、文件传输、聊天和桌面共享等都不需要额外的插件。
2、

WebRTC 是免费的吗
WebRTC 是完全开源免费的，其使用 RTP 协议来传输音视频，并支持 Chrome、Mozilla、Opera、Microsoft Edge、安卓浏览器等浏览器。

为何使用 WebRTC
首先 WebRTC 是完全开源免费的，其次是由于对于用户所需要的只是一个支持的浏览器。

WebRTC 中的主要构建模块
简单介绍一下 WebRTC 所提供的 API。

GetUserMedia(): 用于获取用户的摄像头以及麦克风。

RTCPeerConnection(): 用于帮助在端到端连接之间建立音视频通信，这个 API 负责管理编解码以及 NAT 穿透等一系列任务。

RTCDataChannel(): 在 peerconnection 之间分享数据。

GetStats(): 获取 WebRTC 会话。

为何如今这项技术越来越火
它是开源免费的。

它的表现远比普通的服务-客户端模式应用要好，尤其是在耗时方面。

不需要额外的服务器转发，可以直接在用户之间端到端连接。

Web Socket 和 WebRTC 的区别
设计初衷不同
WebSocket 是一个用于浏览器通信的双向机制。浏览器通信有主要两种传输信道：HTTP 和 WebSockets。

HTTP 主要用于获取网页内容，文字或图片等，是一种客户服务类型协议，其中浏览器是客户端，而网页服务器是服务端。

而对于 WebSocket 而言，浏览器通过一个 WebSocket 连接到网页服务器，与 HTTP 相同也是一个客户服务类型协议。但是 HTTP 是一个单向的信道，而 WebSocket 是双向的，意味着服务器和客户端之间的连接可以一直保持到两者主动断开。

WebSocket 主要用于实时网页应用和聊天应用等，而在这上面 WebRTC 相较于 WebSocket 的优势在于：

WebRTC 是为高质量音视频实时通信设计的；

WebRTC 提供的浏览器端到端通信远比 WebSocket 提供的服务延迟更低。

实现上的区别
WebRTC 使用 UDP 协议，而 WebSocket 使用 TCP 协议；

WebRTC 可以同时提供高质量且低延迟的推流。

WebRTC 其实也使用了 WebSocket
WebRTC 其实也使用了 WebSocket，不过是用于搭建 WebRTC的信令机制，但是在连接建立结束后，由于 WebRTC 是端到端连接，因此也不再需要额外服务器。

一、流媒体技术是什么？

流媒体是指通过互联网连续传输的音频和视频数据的播放技术。与传统的下载并播放不同，流媒体在传输数据时不需要下载整个文件，用户可以几乎无延迟地观看或收听内容。

流媒体技术支持实时或点播内容的传输，对于追求即时信息获取和高效内容消费的现代用户需求来说至关重要。

二、流媒体技术的工作原理

为了理解流媒体服务的运作，我们需要深入了解其背后的基本工作原理。

（一）数据压缩与编解码

数据压缩: 流媒体技术首先将大型媒体文件通过编解码器（codec）进行压缩，减少所需传输的数据量。

编解码器: 编解码器是流媒体技术的重要组成部分，它负责编码和解码媒体流，使媒体文件能够被压缩传输并在用户端解压。

（二）传输协议

协议作用: 流媒体内容通过特定的传输协议进行传输，这些协议定义了如何以数据包的形式在网络中发送和接收数据。

主要协议: 流媒体常见的传输协议包括实时流协议（RTSP）、实时消息传输协议（RTMP）、以及HTTP实时流协议（HLS）等。

（三）数据流的分段传输

分段: 流媒体通过将数据分成一段段进行传输，这允许客户端在下载完每个小片段后立即开始播放，而不必等待整个文件下载完毕。

缓冲: 虽然流媒体的目标是减少缓冲时间，但系统通常会预加载一小部分数据以防止播放时出现中断。

（四）客户端的播放与交互

播放器软件: 流媒体内容在用户设备上通过内置或第三方播放器软件进行播放。这些播放器软件解析传入的数据流，并将其转换为音频和视频信号。

用户交互: 用户可以与流媒体内容进行交互，包括暂停、快进、后退等，而播放器会相应地调整数据流的下载和解码。

三、流媒体服务的种类

在数字化时代，流媒体服务是信息消费的重要来源。根据内容的提供方式和用户的需求，流媒体服务可分为两大主要种类。

（一）直播流媒体服务

定义: 直播流媒体，即Live Streaming，指的是将实时发生的事件传输到观众端的技术。

应用场景: 直播服务广泛应用于在线教育、游戏直播、体育赛事、音乐会等现场事件的实时传播。

技术特点: 直播服务涉及到对信号的快速捕捉、编码、传输和解码，对网络带宽和延迟具有较高的要求。

（二）点播流媒体服务

定义: 点播流媒体，即Video on Demand (VoD)，是一种视频内容按需提供的服务，用户可以随时选择观看。

特色服务: 点播平台如Netflix、Amazon Prime Video和YouTube提供海量的电影、电视剧集和其他视频内容。

用户控制: 点播服务允许用户控制播放进度，如暂停、快进、后退等操作，提供个性化的观看体验。

四、流媒体服务的优势

流媒体技术相比于传统的视频播放方式，拥有一系列不可比拟的优势，极大地丰富了用户的媒体体验。

（一）即时性与访问速度

快速访问: 用户无需完全下载就能播放内容，大大节约了等待时间。

实时性: 对于直播服务而言，观众能够即时观看远端发生的事件，感受与现场同步的体验。

（二）跨平台和多设备兼容性

多设备观看: 用户可以在智能手机、平板、电脑甚至智能电视上观看同一流媒体内容。

账户同步: 多数流媒体服务都支持账户信息和播放历史的云端同步，用户在不同设备上的观看体验无缝衔接。

（三）个性化体验与互动性

定制推荐: 许多流媒体平台提供根据用户过往观看行为定制的内容推荐。

社交互动: 一些直播平台支持观众与主播实时互动，比如通过评论、礼物打赏等方式，增加了观看的社交性。

通过上述的分析，我们可以看到流媒体技术已经在多个层面改变了我们获取、观看和互动媒体内容的方式。对于用户而言，流媒体服务提供了极大的便捷性和个性化选择，而对于内容提供者和平台而言，流媒体则代表着与受众建立更为直接关系的新机遇。随着技术的进步和网络基础设施的改善，流媒体服务将继续在全球范围内扩大影响力，推动媒体和娱乐行业的创新发展。

视频监控
2.1 传统解决方案的现状和挑战
视频监控是流媒体技术传统的应用场景，在政府、企业以及现在逐渐流行的个人消费市场有着广泛的应用。特别是近几年来，国内各大城市逐步推进平安城市项目进程，在安防、交通等领域，视频监控市场规模愈发壮大。而且随着室内家居摄像头、车载记录仪的普及，视频监控可以说在人们的生活中无处不在。

传统的视频监控解决方案主要建立在基于 LAN 的网络、服务器、录像机和摄像机的基础之上。这些高度复杂的解决方案具有很高的施工和维护成本，因为传统基础设施价格高昂，并且需要时间来规划、实施和维护。传统的视频监控解决方案也不好扩容维护，对于用户而言，也不友好，操作使用局限在局域网中，已经难以适合新时代的发展。

2.2 发展趋势
由于一些互联网企业的入局，视频监控行业也在经历一系列的变局，譬如小米摄像头、360水滴摄像头的流行，也鞭策着传统的视频监控行业相关企业的变革(譬如海康威视推出的萤石云平台)，虽然目前这些变革多数还局限于个人消费市场，但从长远来看，视频监控上云，是未来发展的大趋势。

基于云的视频监控解决方案由于其高质量、可靠性、安全性、便捷性以及较低的部署和维护成本而越来越受到人们的青睐。

预计未来视频监控，将像目前流行的网络直播一样方便，用户安装好摄像头后，接入网络即可视频上云。使用者在浏览器或APP即可查看所有摄像头的实时监控以及历史录像，通过APP或绑定的手机号码，可以实时接收摄像头发送的事件通知(譬如入侵事件)。

2.3 技术难点
由于历史原因，传统的视频监控行业技术栈多采用私有协议SDK、onvif/rtsp等协议栈。这些协议目前对浏览器而言都不友好，在以前IE浏览器还流行的时期，可以通过ocx插件的方式来对接这些协议，但是随着IE的没落以及目前流行的chrome、火狐浏览器对原生插件的愈加不友好，通过插件的方式来实现访问监控视频的方式将愈发困难。如果要在chrome、火狐浏览器上访问监控视频，目前有以下几种方案可行：

rtmp
目前主流的chrome和火狐浏览器都还支持flash插件，所以目前在浏览器上还可以通过rtmp方式来访问监控视频。但是由于随着html5的普及以及flash的停止更新，预计可预见的未来，rtmp技术将随着flash一起行将就木(谷歌宣布chrom浏览器2020年12月将不再支持flash player)。

http-flv
http-flv直播的方式是一种比较新颖的方式,该技术基于html5,可以通过无插件的方式实现视频直播，而且由于rtmp负载可以平滑的转换成http-flv协议,所以正在逐渐取代rtmp成为新的直播技术标准，目前各大直播网站(譬如斗鱼直播，bilibili等)也陆续从rtmp切换成该技术。但是由于浏览器的限制，不能同时打开过多(chrome限制6个)的同域名下的直播窗口，所以该技术也不太适合多路同时打开(譬如9宫格视频)的视频监控领域。而且由于Adobe的不作为，flv容器格式停止了更新，对H265的支持遥遥无期。

ws-flv
ws-flv直播技术基本与http-flv一致，无非是传输介质换成了websocket协议，除了解除了http-flv不能同时打开过多同域名下的直播窗口的限制，其他技术特性、参数基本与http-flv一致。目前看，ws-flv既适合视频监控(可以同时打开多路监控视频)也适合视频直播行业，是rtmp很高的升级替代方案。

webrtc
webrtc是谷歌主导的视频通话技术标准，目前各大主流浏览器都兼容该标准。通过该技术，用户可以在浏览器上实现无插件的视频通话，该技术也可以用于实现低延时的视频直播。目前业界也有很多基于webrtc的应用和产品，但是很多局限于视频聊天等低延时交互式场景，在视频监控领域，目前还尚未流行。而且该技术栈目前还在持续更新，技术难点太多，要与视频监控领域融合还需时日。

hls
hls协议是苹果公司主导的技术标准，该技术标准兼容性最佳。不仅桌面浏览器，包括手机浏览器甚至是手机QQ、手机微信都支持该直播协议。但是该协议延时比较大，不太适合视频监控等对延时要求很敏感的行业。不过最近苹果公司新推出低延时hls直播标准，预计hls标准将抢占更大的市场份额。

以上直播技术标准目前都不完全契合视频监控行业的需求，如果要达到比较好的用户体验，通常以上技术混合使用。

3、视频直播
3.1 视频直播的现状和挑战
视频直播是近几年才兴起的产业，特别是随着游戏直播、手机直播的流行，视频直播已经司空见惯，进入了每个人的视野。随着阿里、腾讯等云平台的入局，OBS，SRS等优秀软件的开源，视频加速CDN技术的成熟，打赏、广告等商业模式的落地，目前视频直播产业链已经非常成熟，业界也诞生了斗鱼、虎牙、映客、花椒等知名直播平台。

目前而言，这些直播平台使用的技术栈基本都是rtmp,但是由于flash技术即将被淘汰，所以直播行业也将迎来一些变局以及挑战。现在，基本上所有的直播平台，在web端，都已经或正在往http-flv方案转型。由于flv与rtmp同出一门(都是Adobe公司产品)，负载格式一致，方案升级改造平滑可靠，http-flv替代rtmp具有天然的优势，相信将来http-flv能很好的挑起rtmp的大梁。

3.2 发展趋势
视频直播目前从内容上来讲，涵盖了游戏、美女、户外、娱乐、体育等直播；从设备上来讲，涵盖了PC、手机、web、电视等客户端，市场上也诞生了斗鱼这样的头部企业。从目前来看，视频直播行业市场格局已经比较稳固，进入了平稳发展期。

从技术上来讲，直播行业也将迎来一些变革。一是rtmp技术随着flash的一起淘汰，web端rtmp播放器将成为历史。二是随着webrtc的强势流行，直播技术栈可能与webrtc融合。三是苹果主导的低延时hls的推出，可能最终有大一统之势。

不过近期来看，http-flv是rtmp的最佳替代方案，但是和rtmp一样，也有不支持H265的短板，而且移动端浏览器对此支持并不完善，所以该方案在将来有大概率会被其他方案替代。

3.3 技术难点
直播行业相对视频监控行业来说，商业化程度更高，更面向于普通消费者，用户规模更大，产业链也更加成熟。但是由于利益格局的划分、巨头间标准制定的角力，目前直播的技术标准和用户体验是割裂的。

在桌面web端，之前直播技术由Adobe旗下的flash/rtmp技术主导，不过由于Adobe的不作为，以及谷歌苹果等公司的抵制，flash已经进入死亡倒计时。目前来看，http-flv已经接手rtmp的大旗，成为了新的事实上的桌面web端直播标准。但是http-flv由于其不支持H265的短板(Adobe官方可能永远也不会支持H265)，其地位也并不稳固，现在也有公司正在尝试使用webrtc进行视频直播，但是由于该技术跨界太大，其技术栈又太庞杂，整个上下游产业链也并不完善，目前在直播界，还未看见大规模采用该直播技术的方案实施。

在手机APP端，由于播放技术自己可以主导，也由于历史沿革原因，目前一般沿用rtmp技术方案(需要指出的是微信小程序也支持rtmp播放器)，用户体验比较好，延时一般3秒或以下。

在移动web端，可采用的直播方案更少，目前基本只能采用苹果公司主导的hls方案，但是由于hls的技术特性，延时非常大(一般5秒以上，最大可达10秒以上)，其观看体验跟手机APP、桌面web端是严重割裂的。

通过我们上述的分析看出，目前直播技术方案，在每种端都不一样，用户体验也差距巨大，目前并没有一种多平台支持、令人满意的通用解决方案。目前要实现一个完善的直播产品，最少要采用包括rtmp/http-flv/hls这3种技术方案，而且这三种技术方案目前也并不能让人满意(rtmp/http-flv不支持H265,hls延时高)。

4、我们的解决方案以及优势
目前我们的流媒体服务框架支持rtsp/rtmp推流客户端，rtsp/rtmp/http-flv/ws-flv/hls播放客户端，并且可以无缝把rtsp/rtmp推流转换成上述4种播放协议，同时我们也支持mp4录制存档，必要的时候也可以从mp4文件加载成直播流。

除了上述功能之外，我们还支持拉流rtsp/rtmp代理成rtsp/rtmp/http-flv/ws-flv/hls，也支持把直播rtsp/rtmp流推送到其他的服务器。

另外，我们还提供丰富的http api 以及 http hook api，通过这些api，我们可以与其他业务服务器一起，打造丰富的业务逻辑。

我们的流媒体框架支持linux、macos、ios、android、windows全平台，既可以作为商用的流媒体服务器，也可以移植到嵌入式设备中，作为基础流媒体服务组件。

代码采用C++11标准打造，避免使用裸指针，稳定可靠，采用epoll多路复用、线程池、异步网络IO模式开发，并发性能优越，已经经受住了长期的高并发验证考验。同时针对及时推流的特征，做了特别的优化，可以减少视频打开延时、提高画面打开成功率，让用户获取画面秒开，延时极低的体验。

概述
本文介绍了视频编码原理、H264编码格式、RTP/RTSP/SDP，适合新手入门，从视频编码到rtsp实时流传输，帮助新手理解。

1、视频编码
是指压缩编码。在计算机的世界中，一切都是0 和1 组成的，音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0 和1 的重复数据，因此可以通过一定的算法来压缩这些0和1 的数据。特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。

那么，未经编码的原始音视频，数据量至底有多大？以一个分辨率1920×1280，帧率30 的视频为例：共：1920×1280=2,073,600（Pixels 像素），每个像素点是24bit；也就是：每幅图片2073600×24=49766400 bit，8 bit（位）=1 byte（字节）；所以：49766400bit=6220800byte≈6.22MB。这是一幅1920×1280 图片的原始大小（6.22MB），再乘以帧率30。也就是说：每秒视频的大小是186.6MB，每分钟大约是11GB，一部90 分钟的电影，约是1000GB。

1.1 组织
音视频编解码的国际标准

ITU（国际电信联盟）

ISO/IEC

JVT（Joint Video Team，视频联合工作组）

1）ITU 提出了H.261、H.262、H.263、H.263+、H.263++，这些统称为H.26X 系列，主要应用于实时视频通信领域，如会议电视、可视电话等；

2）ISO/IEC 提出了MPEG1、MPEG2、MPEG4、MPEG7、MPEG21，统称为MPEG系列。

3）ITU 和ISO/IEC 一开始是各自捣鼓，后来，两边成立了一个联合小组，名叫JVT（JointVideo Team，视频联合工作组）。

1.2 视频编码原理
原始视频压缩的目的是去除冗余信息，可以去除的冗余包括：

空间冗余：图像相邻像素之间有较强的相关性

时间冗余：视频序列的相邻图像之间内容相似

编码冗余：不同像素值出现的概率不同

视觉冗余：人的视觉系统对某些细节不敏感

知识冗余：规律性的结构可由先验知识和背景知识得到

视频编码技术优先消除的目标，就是空间冗余和时间冗余。

数据压缩是怎么分类的？

无损压缩（Lossless）：

压缩前、解压缩后图像完全一致X=X'，压缩比低(2:1~3:1)。典型格式例如：Winzip，JPEG-LS。

有损压缩（Lossy）：

压缩前解压缩后图像不一致X≠X'，压缩比高(10:1~20:1)，利用人的视觉系统的特性。典型格式例如：MPEG-2，H.264/AVC，AVS。

形象的比喻就是把每帧都作为一张图片，采用JPEG 的编码格式对图片进行压缩，这种编码只考虑了一张图片内的冗余信息压缩，如图1，绿色的部分就是当前待编码的区域，灰色就是尚未编码的区域，绿色区域可以根据已经编码的部分进行预测（绿色的左边，下边，左下等）。

编码就是为了压缩。要实现压缩，就要设计各种算法，将视频数据中的冗余信息去除。

举个例子：如果一幅图（1920×1080 分辨率），全是红色的，我有没有必要说2073600次[255,0,0]？我只要说一次[255,0,0]，然后再说2073599 次“同上”。

但是帧和帧之间因为时间的相关性，后续开发出了一些比较高级的编码器可以采用帧间编码，简单点说就是通过搜索算法选定了帧上的某些区域，然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式，通过下面两个图2 连续帧我们可以看到，滑雪的同学是向前位移的，但实际上是雪景在向后位移，P 帧通过参考帧（I 或其他P 帧）就可以进行编码了，编码之后的大小非常小，压缩比非常高。

如果一段1 分钟的视频，有十几秒画面是不动的，或者，有80%的图像面积，整个过程都是不变（不动）的。那么，是不是这块存储开销，就可以节约掉了？

运动估计和补偿

我们来通过一个例子看一下。

这有两个帧：

人在动，背景是没有动的。第一帧是I 帧，第二帧是P 帧。两个帧之间的差值，就是如下：

也就是说，图中的部分像素，进行了移动。移动轨迹如下：

这个，就是运动估计和补偿。

视频编码过程如下：

2、色彩空间
这里我们只讲常用到的两种色彩空间。

1）RGB：RGB 的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B 三种基础色，可以混合出所有的颜色。

2）YUV：这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV 两种色度，形成现在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量；

U：蓝色通道与亮度的差值；

V：红色通道与亮度的差值。

如下图，可以看到Y、V、U 3 个分量的效果差值：

采用YUV 有什么优势呢？

人眼对亮度敏感，对色度不敏感，因此减少部分UV 的数据量，人眼却无法感知出来，这样可以通过压缩UV 的分辨率，在不影响观感的前提下，减小视频的体积。

视频通信系统之所以要采用YUV，而不是RGB，主要是因为RGB 信号不利于压缩。

主流的采样方式有三种

1）YUV4:4:4；YCbcr

2）YUV4:2:2；

3）YUV4:2:0

如何理解帧和场图像？一帧图像包括两场——顶场，底场：

逐行与隔行图像

逐行图像是指：一帧图像的两场在同一时间得到，ttop=tbot。

隔行图像是指：一帧图像的两场在不同时间得到， ttop≠tbot。

3、H264
3.1 基本概念
IPB 帧

I 帧：帧内编码帧(intra picture)，采用帧内压缩去掉空间冗余信息。

P 帧：前向预测编码帧(predictive-frame)，采用帧间编码（前向运动估计），同时利用空间和时间上的相关性。简单来说，采用运动补偿(motion compensation)算法来去掉冗余信息。参考前面的I 帧或者P 帧。

B 帧：双向预测内插编码帧(bi-directional interpolated prediction frame)，既考虑源图像序列前面的已编码帧，又顾及源图像序列后面的已编码帧之间的冗余信息，来压缩传输数据量的编码图像，也称为双向编码帧。参考前面一个的I 帧或者P 帧及其后面的一个P 帧。

IDR 帧(关键帧)：在编码解码中为了方便，将GOP 中首个I 帧要和其他I 帧区别开，把第一个I 帧叫IDR，这样方便控制编码和解码流程，所以IDR 帧一定是I 帧，但I 帧不一定是IDR 帧；IDR 帧的作用是立刻刷新,使错误不致传播,从IDR 帧开始算新的序列开始编码。I 帧有被跨帧参考的可能,IDR 不会。I 帧不用参考任何帧，但是之后的P 帧和B 帧是有可能参考这个I 帧之前的帧的

PTS 和DTS

DTS(Decoding Time Stamp)是标识读入内存中bit 流在什么时候开始送入解码器中进行解码。也就是解码顺序的时间戳。

PTS(Presentation Time Stamp)用于度量解码后的视频帧什么时候被显示出来。在没有B 帧的情况下，DTS 和PTS 的输出顺序是一样的，一旦存在B 帧，PTS 和DTS 则会不同。也就是显示顺序的时间戳。

GOP：即Group of picture(图像组)，指两个I 帧之间的距离，Reference(参考周期)指两个P 帧之间的距离。一个I 帧所占用的字节数大于一个P 帧，一个P 帧所占用的字节数大于一个B 帧。所以在码率不变的前提下，GOP 值越大，P、B 帧的数量会越多，平均每个I、P、B 帧所占用的字节数就越多，也就更容易获取较好的图像质量；Reference 越大，B 帧的数量越多，同理也更容易获得较好的图像质量。

简而言之：

字节大小：I > P > B

解码顺序：I -> P -> B

“块（Block）”与“宏块（MacroBlock）”

如果总是按照像素来算，数据量会比较大，所以，一般都是把图像切割为不同的“块（Block）”或“宏块（MacroBlock）”，对它们进行计算。一个宏块一般为16 像素×16 像素。

3.2 H264结构
H264 压缩方式

H264 采用的核心算法是帧内压缩和帧间压缩，帧内压缩是生成I 帧的算法，帧间压缩是生成B 帧和P 帧的算法。

VCL 层是对核心算法引擎、块、宏块及片的语法级别的定义，负责有效表示视频数据的内容，最终输出编码完的数据SODB；

NAL 层定义了片级以上的语法级别（如序列参数集参数集和图像参数集，针对网络传输，后面会描述到），负责以网络所要求的恰当方式去格式化数据并提供头信息，以保证数据适合各种信道和存储介质上的传输。NAL 层将SODB 打包成RBSP 然后加上NAL 头组成一个NALU 单元，具体NAL 单元的组成也会在后面详细描述。

SODB: 数据比特串，是编码后的原始数据；

RBSP: 原始字节序列载荷，是在原始编码数据后面添加了结尾比特，一个bit“1”和若干个比特“0”，用于字节对齐

NALU 的起始码为0x000001 或0x00000001（起始码包括两种：3 字节(0x000001)和4 字节(0x00000001)，起始码用来分割NALU

仿校验字节（0x03）：

H264 规定，当检测到0x000000 时，也可以表示当前NALU 的结束。那这样就会产生一个问题，就是如果在NALU 的内部，出现了0x000001 或0x000000时该怎么办？在RBSP 基础上填加了仿校验字节（0x03）它的原因是：需要填加每组NALU 之前的开始码StartCodePrefix,如果该NALU 对应的slice为一帧的开始则用4 位字节表示，0x00000001,否则用3 位字节表示0x000001.为了使NALU 主体中不包括与开始码相冲突的，在编码时，每遇到两个字节连续为0，就插入一个字节的0x03。解码时将0x03 去掉。也称为脱壳操作。

想要完成准确无误视频的解码，除了需要VCL 层编码出来的视频帧数据，同时还需要传输序列参数集和图像参数集等等，所以RBSP 不单纯只保存I/B/P 帧的数据编码信息，还有其他信息也可能出现在里面。SPS、PPS、IDR 和SLICE 是NAL 单元某一类型的数据。

NAL 单元是作为实际视频数据传输的基本单元，NALU 头是用来标识后面RBSP 是什么类型的数据，同时记录RBSP 数据是否会被其他帧参考以及网络传输是否有错误

NAL 头

NAL 单元的头部是由forbidden_bit(1bit)，nal_reference_bit(2bits)（优先级），nal_unit_type(5bits)（类型）三个部分组成的，组成如图所示：

1、F(forbiden):禁止位，占用NAL 头的第一个位，当禁止位值为1 时表示语法错误；

2、NRI:参考级别，占用NAL 头的第二到第三个位；值越大，该NAL 越重要。

3、Type:Nal 单元数据类型，也就是标识该NAL 单元的数据类型是哪种，占用NAL 头的第四到第8 个位；

NAL 分为VCL 和非VCL 的NAL 单元。在图中有介绍（图表中DIR 应该为IDR），其中SPS、SEI、PPS 等非VCL 的NAL 参数对解码和显示视频都是很有用的。

参数集（Parameter sets），参数集是携带解码参数的NAL 单元，参数集对于正确解码是非常重要的，在一个有损耗的传输场景中，传输过程中比特列或包可能丢失或损坏，在这种网络环境下，参数集可以通过高质量的服务来发送，比如向前纠错机制或优先级机制。Parameter sets 与其之外的句法元素之间的关系如下图所示：

非VCL 的NAL 数据类型：

1）、SPS（序列参数集）：SPS 对如标识符、帧数以及参考帧数目、解码图像尺寸和帧场模式等解码参数进行标识记录。

2）、PPS（图像参数集）：PPS 对如熵编码类型、有效参考图像的数目和初始化等解码参数进行标志记录。

3）、SEI(补充增强信息)：这部分参数可作为H264 的比特流数据而被传输，每一个SEI信息被封装成一个NAL 单元。SEI 对于解码器来说可能是有用的，但是对于基本的解码过程来说，并不是必须的。

序列参数集（sps）NAL 单元必须在传送所有以此参数集为参考的其他NAL 单元之前传送，不过允许这些NAL 单元中间出现重复的序列参数集NAL 单元。所谓重复的详细解释为：序列参数集NAL 单元都有其专门的标识，如果两个序列参数集NAL 单元的标识相同，就可以认为后一个只不过是前一个的拷贝，而非新的序列参数集。

图像参数集（pps）NAL 单元必须在所有以此参数集为参考的其他NAL 单元之前传送，不过允许这些NAL 单元中间出现重复的图像参数集NAL 单元，这一点与上述的序列参数集NAL 单元是相同

VCL 的NAL 数据类型

1）、头信息块，包括宏块类型，量化参数，运动矢量。这些信息是最重要的，因为离开他们，被的数据块种的码元都无法使用。该数据分块称为A 类数据分块。

2）、帧内编码信息数据块，称为B 类数据分块。它包含帧内编码宏块类型，帧内编码系数。对应的slice 来说，B 类数据分块的可用性依赖于A 类数据分块。和帧间编码信息数据块不通的是，帧内编码信息能防止进一步的偏差，因此比帧间编码信息更重要。

3）、帧间编码信息数据块，称为C 类数据分块。它包含帧间编码宏块类型，帧间编码系数。它通常是slice 种最大的一部分。帧间编码信息数据块是不重要的一部分。它所包含的信息并不提供编解码器之间的同步。C 类数据分块的可用性也依赖于A 类数据分块，但于B类数据分块无关。

以上三种数据块每种分割被单独的存放在一个NAL 单元中，因此可以被单独传输。

H264 的NAL 单元与片，宏之间的联系

1 帧（一幅图像） = 1~N 个片（slice） //也可以说1 到多个片为一个片组

1 个片= 1~N 个宏块（Marcroblock）

1 个宏块= 16X16 的YUV 数据（原始视频采集数据）

同时有几点需要说明一下，这样能便于理解NAL 单元：

（1）、如果不采用FMO（灵活宏块排序）机制，则一幅图像只有一个片组；

（2）、如果不使用多个片，则一个片组只有一个片；

（3）、如果不采用DP（数据分割）机制，则一个片就是一个NALU，一个NALU 也就是一个片。否则，一个片的组成需要由三个NALU 组成，也就是上面说到的A、B、C 类数据块。

下图是H264视频文件结构，每个NALU用起始码隔开：

4、视频文件格式、视频封装格式
视频格式那么多，MP4/RMVB/MKV/AVI 等，这些视频格式与编码压缩标准mpeg4，H.264.H.265 等有什么关系？下面通过引入下面三个概念来介绍视频压缩知识。分别是：

视频文件格式（简称：文件格式），

视频封装格式（简称：视频格式），

视频编码方式（简称：视频编码）

一，视频文件格式（简称：文件格式）：

我们知道Windows 系统中的文件名都有后缀，例如1.doc，2.wps，3.psd 等等。Windows 设置后缀名的目的是让系统中的应用程序来识别并关联这些文件，让相应的文件由相应的应用程序打开。例如你双击1.doc 文件，它会知道让Microsoft Office 去打开，而不会用Photoshop 去打开这个文件。所以常见的视频文件格式如1.avi，2.mpg 这些都叫做视频的文件格式，它由你电脑上安装的视频播放器关联。

二，视频封装格式（简称：视频格式）：

AVI，MPEG，VOB 是一种视频封装格式，相当于一种储存视频信息的容器。它是由相应的公司开发出来的。我们可以在自己的电脑上看到的1.avi，2.mpg，3.vob 这些视频文件格式的后缀名即采用相应的视频封装格式的名称。以下集中介绍几种封装格式：