流媒体技术知识梳理整合

        流媒体技术

1.流媒体技术基础知识

1.1 流媒体技术简介

流媒体，又叫流式媒体，是具备边传边播特点的一种多媒体，如音频、视频或多媒体文件。

流媒体技术是将采集到的连续非串流格式的视频和音频编码压缩（目的：减少对带宽的消耗）成串流格式（目的：提高音视频应用的质量）放到网站服务器上，传送到网络上，用户通过客户端播放器搜索自己想看的节目实现一边下载一边观看，而不再需要全部下载之后才能观看的网络传输技术。“流”媒体的流是指其传输方式采用流式传输方式，此传输方式实现边传边播的优势，是流媒体技术的关键（具体1.2讲解）。流媒体的出现极大地方便了人们的工作和生活,下面举个例子来深入体会一下。

比如远程教育，在地球的另一端，某大学的课堂上，某个教授正在兴致盎然地传授一门我们喜欢的课程，想听？太远！放弃？可惜！没关系，网络技术和流媒体技术的结合满足了我们的愿望。在网络上找到该在线课程，课程很长，但没关系，只管点击播放，教授的身影很快出现在屏幕上，课程一边播放一边下载，虽然远在天涯，却如亲临现场！除了远程教育，流媒体在视频点播、网络电台、网络视频等方面也有着广泛的应用。

简而言之，流媒体是指将视音频文件经过压缩处理后, 放在网络服务器上, 在Internet中使用流式传输技术分段传送, 客户端计算机仅需将起始几秒的数据先下载到本地的缓冲区中就可以开始播放,后面收到的数据会源源不断输入到缓冲区, 可实现即时收听和收看。流媒体应用的一个最大的好处是用户不需要花费很长时间将多媒体数据全部下载到本地后才能播放, 这样节省了下载时间和存储空间, 使延时大大减少，下图为流媒体技术基本原理图。。

 

 

  1.2 流式传输方式

流式传输的定义很广泛，现在主要指通过网络传送媒体（如视频、音频等）的技术总称。其特定含义为通过INTERNET将影视节目传送到PC机。

1、 流式传输的方式

     实现流式传输有两种方法：顺序流式传输（progressive streaming）和实时流式传输（Realtime streaming）。

1)、顺序流式传输（progressive streaming）

     顺序流式传输是顺序下载，在下载文件的同时用户可观看再线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，顺序流式传输不象实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于该文件在播放前观看的部分是无损下载的，这种方法保证电影播放的最终质量。这意味着用户在观看前，必须经历延迟，对较慢的连接尤其如此。

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

2）、实时流式传输（Realtime streaming）

     实时流式传输总是实时传送，特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。理论上，实时流一经播放就可不停止，但实际上，可能发生周期暂停。

实时流式传输必须配匹连接带宽，这意味着在以调制解调器速度连接时图象质量较差。而且，由于出错丢失的信息被忽略掉，网络拥挤或出现问题时，视频质量很差。如欲保证视频质量，顺序流式传输也许更好。实时流式传输需要特定服务器，如QuickTime Streaming Server、RealServer与Windows Media Server。这些服务器允许你对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如：RTSP (Realtime Streaming Protocol：实时流协议)或MMS (Microsoft Media Server微软多媒体服务)（协议后续讲解）。这些协议在有防火墙时有时会出现问题，导致用户不能看到一些地点的实时内容。

2、流式传输原理

流式传输的实现需要合适的传输协议。由于TCP需要较多的开销，故不太适合传输实时数据。在流式传输的实现方案中，一般采用HTTP/TCP来传输控制信息 ，而用RTP/UDP来传输实时音视频数据。

流式传输的过程一般是这样的：终端用户选择某一流媒体服务后，Web浏览器与WEB服务器之间使用HTTP/TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来，然后客户机上的WEB浏览器启动A/V Hepler程序，使用HTTP从WEB服务器检索相关参数并对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型或与A/V检索相关的服务器地址等。A/V Helper 程序及A/V服务器运行实时流控制协议RTSP，实现A/V传输所需要控制信息的交换；RTSP提供了操纵播放、快进、快退、暂停及录制等命令的方法。A/V服务器使用RTP/UDP协议，将A/V数据传输给A/V客户端程序，一旦A/V数据抵达客户端，A/V数据即可播放输出。

 

1.3 流媒体系统的构成

通常，组成一个完整的流媒体系统包括以下5个部分：

（1）一种用于创建、捕捉和编辑多媒体数据，形成流媒体格式 的编码工具（编码器）。

（2）流媒体数据。

（3）一个存放和控制流媒体数据的服务器。

（4）一个适合多媒体传输协议甚至是实时传输协议的网络。

（5）一个供客户端浏览流媒体文件的播放器。

 

图1.1流媒体系统结构图

以上五个部分有些是网站需要的，有些是客户端需要的。值得指出的是不同流媒体标准和不同公司的解决方案，可能会在某些方面表现不同。其用到的技术、协议、软件等详细内容后续讲解。其中流媒体服务器是整个系统架构的可核心，下面1.4详细介绍流媒体服务器。

1.4流媒体服务器

具体的媒体服务器系统可以由带视音频硬件接口的计算机和运行其上的软件共同完成。

（1）媒体服务器硬件平台

    视频服务器的工作模式是当服务器响应客户的视频流后，从存储系统读入一部分视频数据到对应于这个视频流的特定的缓存中，然后此缓存中的内容送入网络接口发送到客户。当一个新的客户请求视频服务时，服务器根据系统资源的使用情况，决定是否响应此请求。系统的资源包括存储I/O的带宽、网络带宽、内存大小和CPU的使用率。其中视频流要具有同步性要求，即需要一恒定速率播放，否则引起画面抖动；同时，视频流包含的多种信号也需要保持同步，如画面配音和口型相一致等。此外，由于视频信号数据量极大，以及信号的存放方式等均直接影响服务器的交互服务，因此，多媒体服务器的系统资源，即上述的存储I/O带宽、网络带宽、内存大小、CPU主频等，均要适应传输相应媒体的各种要求。

（2）流媒体服务器的软件平台

   媒体服务器的软件平台，包括媒体内容制作，发行与内容管理模块，用户管理模块，视频服务器。媒体内容制作涉及信息采集、处理、传输；发行模块负责将节目提交到网页，或将视频流地址邮寄给用户；内容管理模块主要完成视频存储、查询；节目不多时可使用文件系统，当节目量大，就必须编制数据库管理系统。用户管理模块包括用户登记和授权；视频服务器负责将内容通过直播或点播等方式播放。对范围广、用户多的播放，可在不同区域的中心（如中国华东上海、华北北京、华中武汉等）建立相应的分发中心，协同完成播放。此外，对商业站点，还应包括计费系统等。网络视频播放的结构如下图1.2。

 

图1.2网络视频播放的结构

其中包括以下服务：

1）任务（会话）服务(Session Service)

    建立和维持客户和服务器之间的通信通道；为特定的客户设备管理一系列的服务器资源；每一个客户设备只分配一个任务。

2）内容服务(Content Service)

 

图1.3 内容服务

其操作过程如下：

⑴、 为当前的一个或多个视频主题查询内容；
⑵、 内容服务返回一个与所需要的视频内容相关联的"assetcookie"；
⑶、 客户把"assetcookie"交给流服务,准备视频内容"流化"
⑷、 流服务用节目解析器解析出"assetcookie"；
⑸、 流服务定位MDS中所关联的节目内容；
⑹、 流服务指引"视频泵""流出"节目内容到客户端。

3）流服务（StreamService）

流服务指引"视频泵"（VideoPump）以实时流的形式分发数据（MPEG-1或MPEG-2传输流）到客户端；同"视频泵"一起执行VCR控制功能（暂停、继续、快进、快退）；客户端通过媒体网络（MediaNet）以流（MediaNetStream）的形式接收BLOB数据；-BLOB（BinaryLargeOBject）二进制大对象，如bitmap（位图）、imagestills（静止画面）及客户需要下载供本地访问的一些存储在VS中的数据，以可靠方式传输（通过MN），而实时视频流的传输往往被认为是不可靠的。

图1.4 流服务

4）MDS服务：媒体数据存储服务（MediaDataStoreService-MDS）

     进行文件管理（创建、存储、修改、删除）及目录管理功能；当"视 频泵"(videopump)要"播"一个视频文件时，它先给MDS目录服务器（MDSDirectoryServer）发一个消息打开文件，然后从该目录服务器得到这个文件的磁盘布局数据；由于影像文件都很大，视频服务器采用RAID（Redundant Arrays of Inexpensive Disks）存储影像文件；所有用来存储影像节目文件的磁盘称作一个卷（volume）,每个卷都有一个TOC（table of contents），存储卷里面的文件及它们在磁盘阵列的位置，TOC的大小决定了一个卷能存储文件的个数；AStripe是卷上所有磁盘同样大小的一块存储空间；Striping是把一个文件分散成片（块）存储在不同的磁盘上，可以减少单块盘的访问次数和时间，以利于并发流的处理；存储节目时，先存tableofcontents（如文件的大小、创建的时间、在磁盘阵列中的位置等），然后横跨磁盘连续地存储，每一块盘上存一个stripe，当写完第一个RAID后，继续下一个RAID，当写到最后一个RAID的最后一块硬盘时，又从第一个RAID写起。当最后一个stripe没写满时，会留下空的小块，下次写盘时，又从下一个RAID开始写盘；因为采用RAID存储机制，当硬盘出现故障，不影响视频服务器正常运行，数据不会丢失。视频服务器还支持"热插拔"（hot－swap）磁盘。

5）文件（节目）上传和下载（FTPService）

     视频服务器提供远程访问MDS的能力，即mdsftp。远程客户计算机 运行FTP即可上传和下载视频服务器中的MDS文件（影像节目文件）。

 

图1.5文件（节目）上传与下载

 视频服务器还提供远程两台视频服务器之间上传和下载MDS文件（影 像节目文件）的能力，这特别适合分布式大规模VOD系统的实现。

6）RTSP服务

     RTSP（RealTimeStreamingProtocol）服务处理客户与服务器之间的通信任务；接收客户基于RTSP协议的请求；把请求映射为适当的基于媒体网络（MN）的视频服务器呼叫；执行呼叫到合适的视频服务器进程；转发视频服务器应答并返回给客户。

 

图1.6 RTSP服务

1.5流媒体的制作播放流程

下面图1.7和1.8形象的表示出流媒体系统各部分之间的职能以及流媒体数据的制作播放流程。

 

图1.7流媒体的制作播放流程

解释：主要的流媒体软件厂商

 

 

 

图1.8基于RTSP的流媒体的制作播放流程

1.6流媒体传输协议

1.流媒体协议架构

 

2.协议简介：

详细一点可直接看：

http://blog.csdn.net/ithzhang/article/details/38346557 

（1）SDP：会话描述协议（Session Description protrol）

会话描述协议是服务器端生成的描述媒体文件的编码信息以及所在服务器的链接等信息。客户端通过它来配置播放软件的设置，如音视频解码器，接受音视频数据的端口等。

会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。

SDP 文本信息包括：

1. 会话名称和意图；

2. 会话持续时间；

3. 构成会话的媒体；

4. 有关接收媒体的信息（地址等）。

5. 协议结构

SDP 信息是文本信息，采用 UTF-8 编 码中的 ISO 10646 字符集。SDP 会话描述如下：（标注 * 符号的表示可选字段）：
v = （协议版本）
o = （所有者/创建者和会话标识符）
s = （会话名称）
i = * （会话信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （电话号码）
c = * （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b = * （带宽信息）

一个或更多时间描述（如下所示）：
z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）
0个或多个媒体描述（如下所示）

时间描述
t = （会话活动时间）
r = * （0或多次重复次数）

媒体描述
m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）
k = * （加密密钥）

a = * （0 个或多个会话属性行）

例子：

使用live555作为流媒体服务器，VLC播放器点播流媒体 a.264。

 

 

m行又称媒体行，描述了发送方所支持的媒体类型等信息，需要详细说明下。

    m=audio 3458  RTP/AVP  0   96   97   

    第一个参数audio为媒体名称：表明支持音频类型。

    第二个参数3488为端口号，表明UE在本地端口为3458上发送音频流。

    第三个参数RTP/AVP为传输协议，表示基于UDP的RTP协议。

    第四到七个参数为所支持的四种净荷类型编号。

    a=rtpmap:0   PCMU

    a=rtpmap:96  G726-32/8000

    a=rtpmap:97  AMR-WB

    a行为媒体的属性行，以属性的名称：属性值的方式表示。

   格式为：a=rtpmap:<净荷类型><编码名称>

   净荷类型0固定分配给了PCMU，

   净荷类型96对应的编码方案为G.726,为动态分配的。

   净荷类型97对应的编码方式为自适应多速率宽带编码（AMR-WB），为动态分配的。           

对于视频: m=video 3400 RTP/AVP 98  99

   第一个参数video为媒体名称：表明支持视频类型。

   第二个参数3400为端口号，表明UE在本地端口为3400上发送视频流。

   第三个参数RTP/AVP为传输协议,表示RTP over UDP。

   第四、五参数给出了两种净荷类型编号

   a=rtpmap:98  MPV

   a=rtpmap:99  H.261

   净荷类型98对应的编码方案为MPV,为动态分配的。

   净荷类型97对应的编码方式为H.261，为动态分配的。

（2）RTSP：实时流协议（real Time Streaming protocol）

网址：http://www.cnblogs.com/lidabo/p/4160153.html

RTSP是一个多媒体播放控制协议，是一种基于文本的应用层协议，在语法及一些消息参数等方面，RTSP协议与HTTP协议类似，默认使用554或8554端口，用来使用户在播放从因特网下载的实时数据时能够进行控制，如：播放、暂停、快进、快退、停止等；即控制实时数据的传输。RTSP 仅仅是使媒体播放器能控制多媒体流的传送。也就是说，RTSP只用于控制媒体流的传输。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于转送媒体流数据。媒体数据的传送可通过RTP/RTCP（下面介绍）等协议来完成。

基本的RTSP操作过程：

首先，客户端连接到流服务器并发送一个OPTIONS命令查询服务器提供的方法收到服务器的回应后，发送DESCRIBE命令查询某个媒体文件的SDP信息。流服务器通过一个SDP描述来进行回应，回应信息包括流数量、媒体类型等信息。客户端分析该SDP描述，并为会话中的每一个流发送一个SETUP命令，SETUP命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个PLAY命令，服务器就开始传送媒体流数据。在播放过程中客户端还可以向服务器发送PAUSE等其他命令控制流的播放。通信完毕，客户端可发送TERADOWN命令来结束流媒体会话。

RTSP协议消息有两种，一种是请求消息(request),一是回应消息(response)，两种消息的格式不同。

上为请求格式，下为响应格式：

 

（1）其中URL是请求的地址，有两种：

一般是rtsp://192.168.0.1(你的服务器的地址)/视频流的名字

如果地址有域名类似格式rtsp://computing.cuc.edu.cn/Angel.mp3

（2）RTSP版本一般为RTSP/1.0。

（3）状态码表示对应消息的执行结果。部分状态码与文本解释对应列表如下：

   状态码       文本解释                   含义

  “200”         OK                     执行成功

  “400”         Bad Request            错误请求

  “404”        Not Found               未找到

  “500”        Internal Server Error   服务器内部错误

下面是简易的交互过程。

 

下面是通过wireshark抓包获得的完整客户端与服务器进行的RTSP交互。蓝色字体标识解释方法的作用，黑色字体表示客户端请求，红色字体表示服务器回应。

OPTION, 目的是得到服务器提供的可用方法：

OPTIONS rtsp://10.34.3.80/D:/a.264 RTSP/1.0

CSeq: 2

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

 

RTSP/1.0 200 OK

CSeq: 2

Date: Tue, Jul 22 2014 02:41:21 GMT

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

 

详细解释：

客户端使用OPTION来查询服务器提供的方法。服务器会在public字段给出自己提供方法集合。从上面的抓包中可以看到此服务器提供了OPTIONS、DESCRIBE、 SETUP、 TEARDOWN、 PLAY,、PAUSE,、GET_PARAMETER、SET_PARAMETER等方法。

    OPTIONS方法并不是必须的。客户端可以绕过OPTIONS，直接向服务器发送其他消息。

CSeq字段表示请求的序号。客户端的每一个请求都会被赋值一个序号。每个请求消息也会对应一个同样序号的回应消息。

     OPTIONS消息可以在任何时间发送。有的客户端会定时向服务器发送OPTION消息。而服务器也可以通过是否定时收到OPTIONS消息来判断客户端是否在线。但并不是所有客户端和服务器都这样做。

   User Agent

   该域用于用户标识.不同公司或是不同的客户端。不同客户端发出的消息中的这个域的内容都不大相同。有时会指明客户端的版本号、型号等等。

     上面的对话中该字段指明采用VLC作为客户端，并给出版本号和使用LIVE555库的版本。

 

DESCRIBE，为了得到会话描述信息(SDP)：

 

DESCRIBE rtsp://10.34.3.80/D:/a.264 RTSP/1.0

CSeq: 3

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Accept: application/sdp

RTSP/1.0 200 OK

CSeq: 3

Date: Tue, Jul 22 2014 02:41:21 GMT

Content-Base: rtsp://10.34.3.80/D:/a.264/

Content-Type: application/sdp

Content-Length: 494

v=0

o=- 1405995833260880 1 IN IP4 10.34.3.80

s=H.264 Video, streamed by the LIVE555 Media Server

i=D:/a.264

t=0 0

a=tool:LIVE555 Streaming Media v2014.07.04

a=type:broadcast

a=control:*

a=range:npt=0-

a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server

a=x-qt-text-inf:D:/a.264

m=video 0 RTP/AVP 96

c=IN IP4 0.0.0.0

b=AS:500

a=rtpmap:96 H264/90000

a=fmtp:96 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHpWoLQSZ,aM48gA==

a=control:track1

 

详细解释：DESCRIBE消息是由客户端发送到服务器端，用于客户端得到请求链接中指定的媒体文件的相关描述，一般是SDP信息。SDP（Session Description Protocol）包含了会话的描述、媒体编码类型、媒体的码率等信息。对于流媒体服务而言，以下几个域是在SDP中一定要包含的。

“a=control:”

“a=range:”

“a=rtpmap:”

“a=fmtp:”

     当一个录像中即包含音频又包含视频时，会有多个上述结构。每个媒体描述以m开始。具体的SDP介绍看上面的SDP协议介绍。

 

SETUP，客户端提醒服务器建立会话,并确定传输模式：

 

SETUP rtsp://10.34.3.80/D:/a.264/track1 RTSP/1.0

CSeq: 4

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Transport: RTP/AVP;unicast;client_port=60094-60095

RTSP/1.0 200 OK

CSeq: 4

Date: Tue, Jul 22 2014 02:41:25 GMT

Transport: RTP/AVP;unicast;destination=10.34.3.80;source=10.34.3.80;client_port=60094-60095;server_port=6970-6971

Session: 54DAFD56;timeout=65

详细解释：

SETUP消息用于确定转输机制，建立RTSP会话。客户端也可以在建立RTSP后再次发出一个SETUP请求为正在播放的媒体流改变传输参数，服务器可能同意这些参数。若不同意，会回应 "455 Method Not Valid In This State"。

     Request 中的Transport头字段指定了客户端可接受的数据传输参数；

     Response中的Transport 头字段包含了由服务器确认后的传输参数。

如果该请求不包含SessionID，则服务器会产生一个SessionID。

从上面的SETUP会话中可以看到RTP端口用偶数表示，RTCP对于tcp端口相邻的奇数端口。

 

 

PLAY，客户端发送播放请求：

 

PLAY rtsp://10.34.3.80/D:/a.264/ RTSP/1.0

CSeq: 5

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Session: 54DAFD56

Range: npt=0.000-

 

RTSP/1.0 200 OK

CSeq: 5

Date: Tue, Jul 22 2014 02:41:25 GMT

Range: npt=0.000-

Session: 54DAFD56

RTP-Info: url=rtsp://10.34.3.80/D:/a.264/track1;seq=10244;rtptime=2423329550

详细解释：

    PLAY方法通知服务器按照SETUP中指定的机制开始传送数据。服务器会从PLAY消息指定范围的开始时间开始传送数据，直到该范围结束。服务器可能会将PLAY请求放到队列中，后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行。

     Range指定了播放开始的时间。如果在这个指定时间后收到消息，那么播放立即开始。

不含Range头的PLAY请求也是合法的，此时将从媒体流开始位置播放，直到媒体流被暂停。如果媒体流通过PAUSE暂停，媒体流传输将在暂停点继续传输。如果媒体流正在播放，那么该PLAY请求将不起作用。客户端可以利用此来测试服务器是否存活。

 

GET_PARAMETER请求检查URL指定的演示与媒体的参数值.

 

GET_PARAMETER rtsp://10.34.3.80/D:/a.264/ RTSP/1.0

CSeq: 6

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Session: 54DAFD56

RTSP/1.0 200 OK

CSeq: 6

Date: Tue, Jul 22 2014 02:41:25 GMT

Session: 54DAFD56

Content-Length: 10

 

详细解释：GET_PARAMETER`请求检查RUL指定的演示与媒体的参数值. 没有实体时, `GET_PARAMETER`也许能用来测试用户与服务器的连通情

 

TEARDOWN，客户端发起关闭请求：

 

TEARDOWN rtsp://10.34.3.80/D:/a.264/ RTSP/1.0

CSeq: 7

User-Agent: LibVLC/2.0.7 (LIVE555 Streaming Media v2012.12.18)

Session: 54DAFD56

RTSP/1.0 200 OK

CSeq: 7

Date: Wed, Jul 30 2014 07:13:35 GMT

 

详细解释：TEARDOWN请求终止了给定URL的媒体流传输，并释放了与该媒体流相关的资源。

 

    可以发现RTSP协议的格式与http协议很类似，都是基于文本的协议，语法也基本相同。但是它们并不相同，有以下主要差别：

   首先，方法名称不同。RTSP新增了DESCRIBE、SETUP、PLAY等方法。

   其次，HTTP协议是无状态的协议，方法之间的发送并无明显的次序关系。而RTSP是有状态的协议，各方法存在次序关系。

   再者，HTTP协议可以以内带载荷数据的方式传送数据，如网页数据。而RTSP仅仅提供流播放的控制，并不传送流媒体数据。流媒体数据可以通过RTP/RTCP的方式传送。

（3）RTP：实时传输协议（Real-Time Transport Protocol）

RTP是针对多媒体数据流的实时传输协议。通常建立在UDP协议之上，也可以建立在TCP协议之上。有人将其归为应用层协议，也有人将其归为传输层协议，这都是可以的。RTP协议提供了时间戳和序列号。发送端在采样时设置时间戳，接收端收到后，会按照时间戳依次播放。RTP本身只保证实时数据的传输，并不能为按顺序传送的数据包提供可靠的传送机制，也不提供流量和拥塞控制，它依靠RTCP来提供这些服务。

 

版本号（V）:0-1  2b 用来标识使用的RTP版本。

填充位（P）:2  1b 如果该位被置为1，则RTP包的尾部会跟附加的填充字节。

扩展位（X）：3 1b 如果该位被置为1，则RTP包的尾部会跟附加扩展帧头。

CSRC计数器（CC）: 4-7 4b 固定头部后跟着的CSRC数目。

标记位（M）: 8 1b 该位的解释由配置文档解释。

载荷类型（PT）:9-15 7b标识RTP载荷的类型。

序列号（SN）: 16- 31 16b发送方在发送完每一个RTP包后会将该域 的值加1，接收方可以通过检测序列号来判断是否出现RTP丢包现象。注意：序列号的初始值是随机的。

时间戳：32 32b 该包中第一个字节的采样时刻。时间戳有一个初始值，随着时间的流逝而不断增加。即使此时没有包被发出，时间戳也会不段增加。时间戳是实现去除抖动和实现同步必不可少的。

SSRC:同步源标识符： 32b  RTP包的来源，在同一个RTP会话中不能 有两个相同的SSRC值。该字段是根据一定的算法随机生成。

CSRC List:贡献源列表 0-15个，每项32b 用来标识对一个RTP混合器产生的新包有贡献的所有RTP包的源。

（4）RTCP：实时控制协议（（Real-Time Control Protocol）

    RTCP通常与RTP配合使用，用以管理传输质量在当前进程之间的交换信息。在RTP会话期间，各参与者周期性的传送RTCP包，RTCP包中包含已发送数据包的数量、丢失的数据包的数量等统计资料。服务器可以利用这些信息动态的改变传输速率，甚至改变有效载荷的类型。RTP和RTCP配合使用，可以有效且以最小的开销达到最佳传输效率，非常适合传送实时流。

    RTSP通常使用RTP协议来传送实时流，RTP一般使用偶数端口，而RTCP使用相邻的奇数端口，即RTP端口号+1。

     在RTCP通信控制中，RTCP协议的功能是通过不同类型的RTCP包来实现的。RTCP也是基于UDP包来传送的，主要有五种类型的封包：

    1.SR：发送端报告，由发送RTP数据报的应用程序或中端发出的。

    2.RR：接收端报告，由接受但不发送RTP数据报的应用程序或中端发出。

    3.SDES: 源描述，传递与会话成员有关的标识信息的载体，如用户名、邮件、电话等。

   4.BYE: 通知离开，通知回话中的其他成员将退出会话。

   5.APP: 由应用程序自己定义，作为RTCP协议的扩展。

 

 

版本（V）：同RTP包头部

    填充(P) ：同RTP包头部。

    接收报告计数器（RC）:5b 该SR包中接收的报告块的数目。

    包类型（PT）： 8bit SR包类型为200

    长度（length）：SR包以32bit为1单位的长度减1

    同步源（SSRC）：SR包发送的同步源标识符。与对应RTP包中的SSRC一样。

    NTP时间戳（Network Time Protocol）:SR包发送时的绝对时间。用于同步不同的流。

    RTP时间戳：与NTP时间戳对应，与RTP包中的时间戳具有相同的初始值。

    Send’s Packet count：从开始发包到产生这个SR包的这段时间内发送者发送的有效数据的总字节数，不包括头部和填充，发送者改变SSRC时，该域要清零。

    同步源n的SSRC标识符：该报告中包含的是从该源接收到的包的统计信息。

    丢失率：表明从上一个SR或RR包发出依来从同步源n发送的RTP包的丢失率。

    累计丢失数据：从开始接受SSRC_n的包到发送SR这个时间段内SSRC_n发送的RTP丢失的总数目。

    收到的扩展最大序列号：从SSRC_n收到的从RTP数据包中的最大序列号。

    接收抖动（Interarrival jitter）：RTP数据包接收时间的统计方差估计。

    上次SR时间戳（Last SR）：取最近从SSRC_n收到的SR包中的NTP时间戳中的中间32bit。如果还未收到SR包，则为0。

上次依赖SR延迟（Delay since Last SR）：从上次SSRC_n收到SR包到发送本包的延迟。

音视频同步:传送的音频和视频流位于两个不同的RTP会话中，每个RTP包均有自己的时间戳，同时RTCP包中的NPT字段（Network Protocol Time）保存的绝对时间可以用来将音视频映射到同一时间轴上，从而实现音视频同步。

另外还有一些流媒体传输协：RTMP/RTMPS、mms、HLS（还列举吗？）

可看这：http://blog.csdn.net/tttyd/article/details/12032357

3.RTP、RTCP及RTSP三者的关系

 

1.7主要的流媒体播放方式

按照传输方式分：单播、组播、广播、点播、P2P等

（1）什么是单播？

客户机和服务器建立单独的通信信道，服务器发送的每个数据报每次只能传送给一个客户机，即主机与客户端之间“一对一”的通讯模式，网络中的交换机与路由器对数据只进行转发不进行复制。现在网络浏览全部都是采用IP单播协议。

 

1.9流媒体单播传输示意图

（2）什么是组播？

IP组播技术构建一种具有组播能力的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包，而不是多个；所有发出请求的客户端共享同一信息包，信息可以发送到任意地址的客户机。即主机与客户端之间“一对一组”的通讯方式，也就是加入一个组的客户端可以接受到此组内的所有数据，网络中的交换机和路由器只向有需求者复制并转发其所需要的数据。客户端可以向路由器请求加入或退出某个组，网络中的路由器和交换机有选择的复制并传输数据，但组播需要网络的支持。

 

1.10流媒体组播传输示意图

（3）什么是广播？

广播是指将数据包的一个拷贝发送给网络上的每个用户，用户是被动接收的，即主机与客户端之间“一对所有”的通讯方式，网络对其中每一台主机发出的信号都进行无条件复制并转发，所有主机都可以接收到所有消息（不管你是否需要），当网络内数据包达到一定数量时就会形成网络风暴，整个网络就肢瘫痪。有线电视网就是典型的广播型网络，目前流媒体技术中已很少应用广播，一般都通过组播或单播来实现媒体数据的分。

 

1.11流媒体广播传输示意图

（4）什么是点播？

点播是指客户机主动连接服务器的连接方式。点播方式，用户可以开始、停止、后退、快进或暂停流，每个客户端占用一路带宽，同时流媒体服务端维护一个客户链接。这要求提供流媒体点播的服务器有富裕的带宽出口，下图是基于RTSP的点播原理图。

 

1.12基于RTSP视频点播原理图。

5.什么是P2P播放？

P2P播放时基P2P于P2P技术的流媒体播放方式之一。P2P(peer to peer)也称为对等网络技术，简单的说，是用户不经过中继设备直接交换数据或服务的技术。在使用时候，每一个客户终端既是客户机又是服务器。你在从别人那里下载需要播放的那一片段的同时，你也在给另一个人提供下载另一个片段。因此在线人数越多，播放反而更流畅。

 

1.13   P2P直传模式示意图

6.什么是直播？

流媒体直播主要是以流式协议（RTP/RTSP、MMS、RTMP等）将视频文件传输到客户端，供用户在线观看；也可从视频采集、压缩软件接收实时视频流，再以流式协议直播给客户端。
现在大多数在线观看软件都属于流媒体直播，手机流媒体直播有个易直播，软件很小，占用内存很小，不会影响手机运行速度，用手机录制后上传到客户端，同时分享到第三方平台，对方即可实时观看直播，进行交流，方便快捷省流量。

 

1.8协议源码

1、http://blog.csdn.net/lvwx369/article/details/41484905

2、http://blog.csdn.net/xiejiashu/article/details/41380593

http://www.csdn.net/tag/rtsp%E5%8D%8F%E8%AE%AE/download

1.8常见的几种高清编码方式和文件封装格式

随着高清技术的逐渐普及，越来越多的节目都采用高清设备来制作。目前，像Avid、Sony、Panasonic、Thomson等主流厂家都有各自系列的高清设备，它们所采用的编码方式和文件的封装格式则各有不同。目前几种主流的高清编码方式有：由ITU-T和ISO/IEC联合开发的H.264/AVC/ MPEG-4标准、由苹果公司开发的ProRes 422、由JPEG组织负责制定的JPEG 2000，以及由Avid公司开发的DNxHD等；主流的文件封装格式有TS、AVI、MKV、MOV等。下面就这几种主流的高清编码方式和文件封装格式做一个介绍。

一、编码方式

 

1. H.264 / AVC / MPEG-4

    H.264与MPEG-2格式和其他之前的格式相比，压缩效率更高。H.264标准由国际电信联盟电信标准化部门（ITU-T）和国际标准化组织/国际电工委员会（ISO/IEC）共同研究发布，因此H.264有两个名称，一个是沿用ITU-T组织的H.26×名称，叫“H.264”；另一个则是AVC（Advanced Video Coding高级视频编码），这个标准也被归为MPEG-4的第10部分。

 

 

 

 

二、常用的几种文件封装格式

 

 

1.8.1常见的网络流媒体文件格式

 

2.视频的采集模块

3.LIVE555服务器

   LIVE555是为流媒体提供解决方案的跨平台C++开源项目。

3.1各库简要介绍

    LIVE555下包含LiveMedia、UsageEnvironment、BasicUsageEnvironment、GroupSock库，MediaServer简单服务器程序以及其他多个测试demo。

    LiveMedia库：包含一系列处理不同编码格式和封装格式的类，基类是Medium。

    UsageEnvironment库：环境类，用于错误信息的输出。LIVE555中多数类中均包含此类对象指针。其内部包含TaskSchedule抽象类的指针，该类用于任务调度，因此所有包含UsageEnvironment指针的类均可将自己加入到调度中。

    BasicUsageEnvironment库：包含具体环境类和具体TaskScheduler类。UsageEnvironment用于对错误信息的处理，BasicUsageEnvironment类用于以控制台方式输出错误信息。因此想要以其他方式输出错误信息的类，可以从UsageEnvironment派生。BasicTaskSchedule类继承自TaskScheduler抽象类，用以定义具体的调度策略。任何基于LIVE555的应用程序均需要定义自己的BasicEnvironment和TaskScheduler库。如果创建窗口应用程序，在重定义TaskScheduler时，需要与图形环境自己的事件处理框架集成。BasicTaskSheduler使用select模型实现事件的获取和处理。如果想使用更高效的IOCP模型，可以定义自己的BasicTaskScheduler类。BasicTaskScheduler内部有一个循环，循环读取队列中的消息并处理。整个基于BasicTaskScheduler的程序只有一个线程驱动。

    GroupSock库：对各种socket操作的封装，用于收发数据。主要面向组播，但也可以进行单播的收发数据，仅支持UDP，不支持TCP。

MediaServer 服务器程序：该程序使用BasicUsageEnvironment库实现，因此是一个控制台程序。任务调度类是BasicTaskScheduler类，因此使用Select模型且仅有一个线程在循环处理各种事件。后期如果有时间会实现基于IOCP的MediaServer服务器程序。

3.2 涉及到的基本概念

1. Souce、Sink

    Souce ：翻译为源、源头。表示数据的提供者，比如通过RTP读取数据，通过文件读取数据或者从内存读取数据，这些均可以作为Souce。

    Sink：翻译为水槽。表示数据的流向、消费者。比如写文件、显示到屏幕等。

    Filter：翻译为过滤器。在数据流从Souce流到Sink的过程中可以设置Filter，用于过滤或做进一步加工。

    在整个LiveMedia中，数据都是从Souce，经过一个或多个Filter，最终流向Sink。在服务器中数据流是从文件或设备流向网络，而在客户端数据流是从网络流向文件或屏幕。

    MediaSouce是所有Souce的基类，MediaSink是所有Sink的基类。

    从类数量和代码规模可以看到，LiveMedia类是整个LIVE555的核心，其内部包含数十个操作具体编码和封装格式的类。LiveMedia定义的各种Souce均是从文件读取，如果想实现从设备获得实时流的传输，可以定义自己的Souce。

2.  ClientSession

对于每一个连接到服务器的客户端，服务器会为其创建一个ClientSession对象，保存该客户端的socket、ip地址等。同时在该客户端中定义了各种响应函数用以处理和回应客户端的各种请求。新版（2014.7.4）的LIVE555增加了ClientConnection类。用于处理一些与正常播放无关的命令。如命令未找到、命令不支持或媒体文件未找到等。在ClientConnection处理DESCRIBE命令时会创建ClientSession对象，其他命令在ClientSession中处理。

3.  MediaSession、MediaSubsession、Track

    LIVE555使用MediaSession管理一个包含音视频的媒体文件，每个MediaSession使用文件名唯一标识。

    使用SubSession管理MediaSession中的一个音频流或视频流。为行文方便我们称音频或视频均为一个媒体文件中的媒体流。因此一个MediaSession可以有多个MediaSubsession，一个管理音频流一个管理视频流。

    在介绍RTSP协议时，客户端在给服务器发送DESCRIBE查询某个文件的SDP信息时，服务器会给客户端返回该媒体文件所包含的多个媒体流信息。并为每个媒体流分配一个TrackID。如视频流分配为Track1，音频流分配为Track2。此后客户端必须在URL指定要为那个Track发送SETUP命令。

    因此我们可以认为MediaSubsession代表Server端媒体文件的一个Track，也即对应一个媒体流。MediaSession代表Server端一个媒体文件。对于既包含音频又包含视频的媒体文件，MediaSession内包含两个MediaSubsession。

    但MediaSession和MediaSubsession仅代表静态信息，若多个客户端请求同一个文件，服务器仅会创建一个MediaSession。各个客户端公用。为了区分各个MediaSession的状态又定义了StreamState类，用来管理每个媒体流的状态。在MediaSubsession中完成了Souce和Sink连接。Souce对指针象会被设置进sink。在Sink需要数据时，可以通过调用Souce的GetNextFrame来获得。

    LIVE555中大量使用简单工厂模式，每个子类均有一个CreateNew静态成员。该子类的构造函数被设置为Protected，因此在外部不能直接通过new来构造。同时，每个类的构造函数的参数中均有一个指向UsageEnvironment的指针，从而可以输出错误信息和将自己加入调度。

4. HashTable

    LIVE555内部实现了一个简单哈希表类BasicHashTable。在LIVE555中，有很多地方需要用到该哈希表类。如：媒体文件名与MediaSession的映射，SessionID与ClientSession的映射，UserName和Password的映射等。

 

流媒体知识网址

1.1 mfc小列子：

wenku.baidu.com/link?url=2N8iuFPnVX2_npRb8_CW11tB9pFuU-uHIZNZENpduf5Zq0chI2uLXhiofNtxNqNL4LYKi4H8qGo5q15zBX0zQUL3d79jvbJC7KoAy8mc2M7

1.2流媒体客户端的传送原理：

http://blog.csdn.net/jianren994/article/details/8133395

http://www.cnblogs.com/kaleidoscope/p/4016455.html

1.3基于RTSP的流媒体播放器制作过程（2）

www.2cto.com/kf/201604/497125.html

1.4 live555介绍

http://baike.baidu.com/view/3495912.htm?fromTaglist#1

http://blog.csdn.net/wishfly/article/details/51900391

//详细介绍 值得学习

http://blog.csdn.net/ithzhang/article/details/37988815

其中视频文件要放在mediaserver目录下。

重要：live555源码分析---- DESCRIBE命令处理。。。。。

http://blog.csdn.net/gavinr/article/details/7026497

MFC调用vlc动态库libvlc.dll实现简单播放器（vlc2.0.0）

http://blog.csdn.net/yigebing52/article/details/9319349

live555峰哥的私房菜(一)---整体上对最简单RtspServer的介绍

http://blog.csdn.net/a7281080/article/details/7726953

 

 

直播：

http://www.cnblogs.com/mlj318/archive/2013/01/25/2873143.html

 

Opencv安装与配置(xp+vs2010+opencv2.4.9)

http://opencv.org/downloads.html

http://wenku.baidu.com/link?url=jVCmg_Q2dfwWqdjDWXW9byaaabampChuNKQ215Cb2KzuAHcOHuY5PR-00NXU4D6GiaxsVYvHH3PNEn5X1qMK8OM7ay_h2A9hUkRBsA94Yp_

 

入门

http://blog.csdn.net/huang9012/article/details/21811129

 

【live555】从UsageEnvironment说到doEventLoop中的SingleStep

 

http://blog.csdn.net/commshare/article/details/18893395

 余工推荐：

1.5视频直播技术详解之现代播放器原理：

http://geek.csdn.net/news/detail/107162

1.6协议介绍：

http://blog.csdn.net/tttyd/article/details/12032357

1.7 抛开flash，自己开发实现C++ RTMP直播流播放器

http://www.cnblogs.com/haibindev/p/3466094.html