视频点播协议

㈠ 优酷网等视频网站使用的协议是什么，rtp 还是 rtsp

这个问题实在太长,不是一句两句说清楚的. 1,rtp实时传输协议,用于传输流媒体数据,基于udp. 2,rtsp实时流媒体协议,用于发起流媒体会话,交互信息,基于tcp. 3,http这个比较杂,通过http进行流化视频有很多种方法. 具体有http渐进式下载,http live streaming,http dynamic streaming.HTML5. 具体不同的平台,不同的播放器,浏览器,这个都可能有些小区别. 国内最为常见是flash+http渐进下载.adobe最近推出的HTTP dynamic streaming是后续版本. 对于iOS,则使用苹果的HLS(http live streaming)支持. HDS与HLS,很大程度上比较相似,都是通过软件将视频文件分割,然后通过索引文件,进行访问.这样的方式,减少了下载块的大小,同时可以动态更新索引文件,可以支持伪直播.例如:HLS,就是分割为h264+aac编码的ts文件,通过m3u8文件索引.客户端通过m3u8文件就可以访问视频内容. 相比之下,HTML5是最为简单的方式,不需要flash,不需要特定软件支持,但是对浏览器要求较高,而且不同的浏览器对具体的视频容器格式与编码格式不完全一致,这个还有待进一步发展. pptv之类的,还会用到p2p的方式,就是用户下载的视频,还有可能用于上传.如有错误,请指正.

㈡ 什么是流媒体播放协议

流媒体技术基础-流媒体传输协议
作者/来源：未知

实时传输协议RTP与RTCP

RTP（Real-timeTransportProtocol）是用于Internet上针对多媒体数据流的一种传输协议。RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步。RTP通常使用UDP来传送数据，但RTP也可以在TCP或ATM等其他协议之上工作。当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分。实时传输控制协议RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和拥塞控制服务。在RTP会话期间，各参与者周期性地传送RTCP包。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。

6.2.1 RTP数据传输协议

RTP提供端对端网络传输功能，适合通过组播和点播传送实时数据，如视频、音频和仿真数据。RTP没有涉及资源预订和质量保证等实时服务，RTCP扩充数据传输以允许监控数据传送，提供最小的控制和识别功能。RTP与RTCP设计成独立传输和网络层。

2.1.1 RTP固定头
RTP 头格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列号 |
-----------------------------------------------------------------------------------------------
| 时标 |
-----------------------------------------------------------------------------------------------
| 同步源标识(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用标识 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------

开始12个八进制出现在每个RTP包中，而CSRC标识列表仅出现在混合器插入时。
2.1.2 复用 RTP 连接
为使协议有效运行，复用点数目应减至最小。RTP中，复用由定义RTP连接的目的传输地址（网络地址与端口号）提供。例如，对音频和视频单独编码的远程会议，每个媒介被携带在单独RTP连接中，具有各自的目的传输地址。目标不在将音频和视频放在单一RTP连接中，而根据SSRC段载荷类型进行多路分解。使用同一SSRC ，而具有不同载荷类型的交叉包将带来几个问题：
如一种载荷类型在连接期间切换，没有办法识别新值将替换那一个旧值。
SSRC定义成用于标识单个计时和系列号空间。如媒体时钟速率不同，而要求不同系列号空间以说明那种载荷类型有丢包，交叉复用载荷类型将需要不同计时空间。
RTCP发送和接收报告可能仅描述每个SSRC的计时和系列号空间，而不携带载荷类型段。
RTP混合器不能将不兼容媒体流合并成一个流。
在一个RTP连接中携带多个媒介阻止几件事：使用不同网络路径或网络资源分配；接受媒介子集。
对每种媒介使用不同SSRC，但以相同RTP连接发送可避免前三个问题，但不能避免后两个问题。

2.1.3 对RTP头特定设置的修改
可以认为，现用RTP数据包头对RTP支持的所有应用类共同需要的功能集是完整的。然而，为维持ALF设计原则，头可通过改变或增加设置来裁剪，并仍允许设置无关监控和记录工具起作用。标记位与载荷类型段携带特定设置信息，但由于很多应用需要它们，否则要容纳它们，就要增加另外32位字，故允许分配在固定头中。包含这些段的八进制可通过设置重新定义以适应不同要求，如采用更多或更少标记位。如有标记位，既然设置无关监控器能观察包丢失模式和标记位间关系，我们就可以定位八进制中最重要的位。
其它特殊载荷格式（视频编码）所要求的信息应该携带在包的载荷部分。可出现在头，总是在载荷部分开始处，或在数据模式的保留值中指出。如特殊应用类需要独立载荷格式的附加功能，应用运行的设置应该定义附加固定段跟随在现存固定头SSRC之后。这些应用将能迅速而直接访问附加段，同时，与监控器和记录器无关设置仍能通过仅解释开始12个八进制处理RTP包。如证实附加功能是所有设置共同需要的，新版本RTP应该对固定头作出明确改变
6.2.2 RTP控制协议-- RTCP
RTCP协议将控制包周期发送给所有连接者，应用与数据包相同的分布机制。低层协议提供数据与控制包的复用，如使用单独的UDP端口号。RTCP执行下列四大功能：
主要是提供数据发布的质量反馈。是作为RTP传输协议的一部分，与其他传输协议的流和阻塞控制有关。反馈对自适应编码控制直接起作用，但IP组播经验表明，从发送者收到反馈对诊断发送错误是致关重要的。给所有参加者发送接收反馈报告允许问题观察者估计那些问题是局部的，还是全局的。诸如IP组播等发布机制使网络服务提供商类团体可能接收反馈信息，充当第三方监控者来诊断网络问题。反馈功能由RTCP发送者和接收者报告执行。
RTCP带有称作规范名字（CNAME）的RTP源持久传输层标识。如发现冲突，或程序重新启动，既然SSRC标识可改变，接收者需要CNAME跟踪参加者。接收者也需要CNAME 与相关RTP连接中给定的几个数据流联系
前两种功能要求所有参加者发送RTCP包，因此，为了RTP扩展到大规模数量，速率必须受到控制。让每个参加者给其它参加者发送控制包，就大独立观察参加者数量。该数量用语计算包发送的速率。
第四个可选功能是传送最小连接控制信息，如参加者辨识。最可能用在\"松散控制\"连接，那里参加者自由进入或离开，没有成员控制或参数协调，RTCP充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。高级连接控制协议超出本书范围。
在IP组播场合应用RTP时，前3个功能是必须的，推荐用于所有情形。RTP应用设计人员必须避免使用仅在单播模式下工作的机制，那将导致无法扩展规模。

6.2.2.1 RTCP 包格式
下面定义几个携带不同控制信息的RTCP包类型：
SR：
发送报告，当前活动发送者发送、接收统计。
RR：
接收报告，非活动发送者接收统计。
SDES：
源描述项，包括CNAME。
BYE：
表示结束。
APP：
应用特定函数。
类似于RTP数据包，每个RTCP包以固定部分开始，紧接着的是可变长结构元素，但以一个32位边界结束。包含安排要求和固定部分中长度段，使RTCP包可堆叠。不需要插入任何分隔符将多哥RTCP包连接起来形成一个RTCP组合包，以低层协议用单一包发送出去。由于需要低层协议提供提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包显式计数。
组合包中每个RTCP包可独立处理，不需要根据包组合顺序。但未了执行协议功能，强加如下约束：
接收统计（在SR或RR中）应该经常发送，只要带宽允许，因此每个周期发送的组合RTCP 包应包含报告包。
新接收者需要接收CNAME，并尽快识别源，开始联系媒介进行同步，因此每个包应该包含SDES CNAME。
出现在组合包前面的是包类型数量，其增长应该受到限制，以提高常数位数量，提高成功确认RTCP包对错误地址RTP数据包或其他无关包的概率。
因此，所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：
加密前缀（Encryption prefix）：
仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。
SR或RR：
组合包中第一个RTCP包必须总为一个报告包，方便头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。
附加RR：
如报告统计源数目超过31，在初始报告包后应该有附加RR 包。

SDES：
包含CNAME 项的SDES包必须包含在每个组合RTCP包中。如应用要求，其他源描述项可选，但受到带宽限制。
BYE或APP：
其它RTCP包类型可以任意顺序排列，除了BYE应作为最后一个包发送，包类型出现可不止一次。
建议转换器或混合器从多个源组合单个RTCP包。如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned Numbers Authority (IANA)处注册。

6.2.2.2 RTCP传输间隔
RTP设计成允许应用自动扩展，连接数可从几个到上千个。例如，音频会议中，数据流量是内在限制的，因为同一时刻只有一两个人说话；对组播，给定连接数据率仍是常数，独立于连接数，但控制流量不是内在限制的。如每个参加者以固定速率发送接收报告，控制流量将随参加者数量线性增长，因此，速率必须按比例下降。
一旦确认地址有效，如后来标记成未活动，地址的状态应仍保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。
这个规范定义了除必需的CNAME外的几个源描述项，如NAME（人名）和EMAIL（电子邮件地址）。它也为定义新特定应用RTCP包类型的途径。给附加信息分配控制带宽应引起注意，因为它将降低接收报告和CNAME发送的速率而损害协议的性能。建议分配给单个参加者用于携带附加信息的RTCP带宽不要超过20%。而且并没有有意让所有SDES项包含在每个应用中。
6.2.2.3 发送者与接收者报告
RTP接收者使用RTCP报告包提供接收质量反馈，报告包根据接收者是否是发送者而采用两种格式中的一种。除包类型代码外，发送者报告与接收者报告间唯一的差别是发送者报告包含一个20个字节发送者信息段。如某地址在发出最后或前一个报告间隔期间发送数据包，就发布SR；否则，就发出RR；SR和RR都可没有或包括多个接收报告块。发布报告不是为列在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。既然最大可有31个接收报告块嵌入在SR 或 RR包中，
丢失包累计数差别给出间隔期间丢掉的数量，而所收到扩展的最后一个系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。如两报告连续，比值应该等于丢失段部分；否则，就不等。每秒包丢失绿可通过NTP时标差除以丢失部分得到。
从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

6.2.2.4 SDES: 源描述RTCP包
SDES 包为三层结构，由头与数据块组成，数据块可以没有，也可有多个，组成项描述块所表明的源。项描述如下：
版本（V）、填充（P）、长度：
如SR包中所描述。
包类型（PT）：
8位，包含常数202，识别RTCP SDES包。
源计数（SC）：
5位，包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。
源描述项内容如下：
CNAME: 规范终端标识SDES项
CNAME标识属性如下：
如发生冲突或重启程序，由于随机分配的SSRC标识可能发生变化，需要CNAME项提供从SSRC标识到仍为常量的源标识的绑定。
象SSRC标识，CNAME标识在RTP连接的所有参加者中应是唯一的。
为了提供一套相关RTP连接中某个参加者所采用的跨多媒体工具间的绑定，CNAME应固定为那个参加者。
为方便第三方监控，CNAME应适合程序或人员定位源。
NAME：用户名称SDES项
这是用于描述源的真正的名称，如\"John Doe, Bit Recycler, Megacorp\"，可是用户想要的任意形式。对诸如会议应用，这种名称也许是参加者列表显示最适宜的形式，它将是除CNAME外发送最频繁的项目。设置可建立这样的优先级别。NAME值至少在连接期间仍希望保持为常数。它不该成为连接的所有参加者中唯一依赖。
EMAIL：电子邮件地址SDES项
邮件地址格式由RFC822规定，如\"[email protected]\"。连接期间，电子邮件仍希望保持为常数。
PHONE：电话号码SDES项
电话号码应带有加号，代替国际接入代码，如\"+1 908 555 1212\"即为美国电话号码。

LOC：用户地理位置SDES项
根据应用，此项具有不同程度的细节。对会议应用，字符串如\"Murray Hill, New Jersey\"就足够了。然而，对活动标记系统，字符串如\"Room 2A244, AT&T BL MH\"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在连接期间，除移动主机外，LOC值期望仍保留为常数。
TOOL：应用或工具名称SDES项
是一个字符串，表示产生流的应用的名称与版本，如\"videotool 1.2\"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在连接期间仍保持常数。
NOTE: 通知/状态SDES项
该项的推荐语法如下所述，但这些或其它语法可在设置中显式定义。NOTE 项旨在描述源当前状态的过渡信息，如\"on the phone, can´t talk\"，或在讲座期间用于传送谈话的题目。它应该只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，因此损害协议的性能。特殊情况下，它不应作为用户设置文件的项目，也不是自动产生。
当其为活动时，由于NOTE项对显示很重要，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，但以一个串长为零的字符串通知接收者。然而，如对小倍数的重复或约20-30 RTCP间隔也没有接收到，接收者也应该考虑NOTE项是不活跃的。
PRIV: 专用扩展SDES项
该项用于定义实验或应用特定的SDES扩展，它包括由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。
注意，前缀消耗了总长为255个八进制项的一些空间，因此，前缀应尽可能的短。这个设备和受到约束的RTCP带宽不应过载，其目的不在于满足所有应用的全部控制通讯要求。SDES PRIV前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀。这简化了应用，并提高了传输的效率。
6.2.2.5 BYE：断开RTCP包
如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，它也应该发出一个BYE包，列出它所处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟很多八进制文本，表示离开原因，如：\"camera malfunction\"或\"RTP loop detected\"。字符串具有同样的编码，如在SDES 中所描述的。如字符串填充包至下32位边界，字符串就不以空结尾；否则，BYE包以空八进制填充。
6.2.2.6 APP：定义应用的RTCP包
APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。
实时流协议RTSP

实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。

6.3 RTSP协议
实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。
6.3.1 简介
6.3.1.1 目的
实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交叉是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可靠传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。实时流协议在语法和操作上与HTTP/1.1类似，因此HTTP的扩展机制大都可加入RTSP。协议支持的操作如下：
从媒体服务器上检索媒体：
用户可通过HTTP或其它方法提交一个演示描述。如演示是组播，演示式就包含用于连续媒体的的组播地址和端口。如演示仅通过单播发送给用户，用户为了安全应提供目的地址。
媒体服务器邀请进入会议：
媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。
将媒体加到现成讲座中：
如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如HTTP/1.1中类似，RTSP请求可由代理、通道与缓存处理。

6.3.1.2 协议特点
RTSP 特性如下：
可扩展性：
新方法和参数很容易加入RTSP。
易解析：
RTSP可由标准 HTTP或MIME解吸器解析。
安全：
RTSP使用网页安全机制。
独立于传输：
RTSP可使用不可靠数据报协议（UDP）、可靠数据报协议（RDP），如要实现应用级可靠，可使用可靠流协议。
多服务器支持：
每个流可放在不同服务器上，用户端自动同不同服务器建立几个并发控制连接，媒体同步在传输层执行。
记录设备控制：
协议可控制记录和回放设备。
流控与会议开始分离：
仅要求会议初始化协议提供，或可用来创建唯一会议标识号。特殊情况下， SIP或H.323
可用来邀请服务器入会。
适合专业应用：
通过SMPTE 时标，RTSP支持帧级精度，允许远程数字编辑
演示描述中立：
协议没强加特殊演示或元文件，可传送所用格式类型；然而，演示描述至少必须包含一个RTSP URI。
代理与防火墙友好：
协议可由应用和传输层防火墙处理。防火墙需要理解SETUP方法，为UDP媒体流打开一个\"缺口\"。
HTTP友好：
此处，RTSP明智的采用HTTP观念，使现在结构都可重用。结构包括Internet 内容选择平台（PICS）。由于在大多数情况下控制连续媒体需要服务器状态， RTSP不仅仅向HTTP 添加方法。
适当的服务器控制：
如用户启动一个流，他必须也可以停止一个流。
传输协调；
实际处理连续媒体流前，用户 可协调传输方法。
性能协调：
如基本特征无效，必须有一些清理机制让用户决定那种方法没生效。这允许用户提出适合的用户界面。
6.3.1.3扩展RTSP
由于不是所有媒体服务器有着相同的功能，媒体服务器有必要支持不同请求集。RTSP 可以如下三种方式扩展，这里以改变大小排序：
以新参数扩展。如用户需要拒绝通知，而方法扩展不支持，相应标记就加入要求的段中。
加入新方法。如信息接收者不理解请求，返回501错误代码（还未实现），发送者不应再次尝试这种方法。用户可使用OPTIONS方法查询服务器支持的方法。服务器使用公共响应头列出支持的方法。
定义新版本协议，允许改变所有部分。（除了协议版本号位置）
6.3.1.4操作模式
每个演示和媒体流可用RTSP URL识别。演示组成的整个演示与媒体属性由演示描述文件定义。使用HTTP或其它途径用户可获得这个文件，它没有必要保存在媒体服务器上。
为了说明，假设演示描述描述了多个演示，其中每个演示维持了一个公共时间轴。为简化说明，且不失一般性，假定演示描述的确包含这样一个演示。演示可包含多个媒体流。除媒体参数外，网络目标地址和端口也需要决定。下面区分几种操作模式：
单播：
以用户选择的端口号将媒体发送到RTSP请求源。
组播，服务器选择地址：
媒体服务器选择组播地址和端口，这是现场直播或准点播常用的方式。
组播，用户选择地址：
如服务器加入正在进行的组播会议，组播地址、端口和密匙由会议描述给出。
6.3.1.5 RTSP状态
RTSP控制通过单独协议发送的流，与控制通道无关。例如，RTSP控制可通过TCP连接，而数据流通过UDP。因此，即使媒体服务器没有收到请求，数据也会继续发送。在连接生命期，单个媒体流可通过不同TCP连接顺序发出请求来控制。所以，服务器需要维持能联系流与RTSP请求的连接状态。RTSP中很多方法与状态无关，但下列方法在定义服务器流资源的分配与应用上起着重要的作用：
SETUP：
让服务器给流分配资源，启动RTSP连接。
PLAY与RECORD：
启动SETUP 分配流的数据传输。
PAUSE：
临时停止流，而不释放服务器资源。
TEARDOWN：
释放流的资源，RTSP连接停止。
标识状态的RTSP方法使用连接头段识别RTSP连接，为响应SETUP请求，服务器连
接产生连接标识。

6.3.1.6 与其他协议关系
RTSP在功能上与HTTP有重叠，与HTTP相互作用体现在与流内容的初始接触是通过网页的。目前的协议规范目的在于允许在网页服务器与实现RTSP媒体服务器之间存在不同传递点。例如，演示描述可通过HTTP和RTSP检索，这降低了浏览器的往返传递，也允许独立RTSP 服务器与用户不全依靠HTTP。
但是，RTSP与HTTP 的本质差别在于数据发送以不同协议进行。HTTP是不对称协议，用户发出请求，服务器作出响应。RTSP中，媒体用户和服务器都可发出请求，且其请求都是无状态的；在请求确认后很长时间内，仍可设置参数，控制媒体流。重用HTTP功能至少在两个方面有好处，即安全和代理。要求非常接近，在缓存、代理和授权上采用HTTP功能是有价值的。
当大多数实时媒体使用RTP作为传输协议时，RTSP没有绑定到RTP。RTSP假设存在演示描述格式可表示包含几个媒体流的演示的静态与临时属性。

6.3.2 协议参数

6.3.3 RTSP 信息
RTSP是基于文本的协议，采用ISO 10646 字符集，使用UTF-8编码方案。行以CRLF中断，但接收者本身可将CR和LF解释成行终止符。基于文本的协议使以自描述方式增加可选参数更容易。由于参数的数量和命令的频率出现较低，处理效率没引起注意。如仔细研究，文本协议很容易以脚本语言（如：Tcl、Visual Basic与Perl）实现研究原型。
10646字符集避免敏感字符集切换，但对应用来说不可见。RTCP也采用这种编码方案。带有重要意义位的ISO 8859-1字符表示如100001x 10xxxxxx.。RTSP信息可通过任何低层传输协议携带。
请求包括方法、方法作用于其上的对象和进一步描述方法的参数。方法也可设计为在服务器端只需要少量或不需要状态维护。当信息体包含在信息中，信息体长度有如下因素决定：
不管实体头段是否出现在信息中，不包括信息体的的响应信息总以头段后第一和空行结束。
如出现内容长度头段，其值以字节计，表示信息体长度。如未出现头段，其值为零。
服务器关闭连接。
注意：RTSP目前并不支持HTTP/1.1\"块\"传输编码，需要有内容长度头。假如返回适度演示描述长度，即使动态产生，使块传输编码没有必要，服务器也应该能决定其长度。如有实体，即使必须有内容长度，且长度没显式给出，规则可确保行为合理。
从用户到服务器端的请求信息在第一行内包括源采用的方法、源标识和所用协议版本。RTSP定义了附加状态代码，而没有定义任何HTTP代码。
6.3.4 实体
如不受请求方法或响应状态编码限制，请求和响应信息可传输实体，实体由实体头文件和试题体组成，有些响应仅包括实体头。在此，根据谁发送实体、谁接收实体，发送者和接收者可分别指用户和服务器。
实体头定义实体体可选元信息，如没有实体体，指请求标识的资源。扩展头机制允许定义附加实体头段，而不用改变协议，但这些段不能假定接收者能识别。不可识别头段应被接收者忽略，而让代理转发。
6.3.5 连接
RTSP请求可以几种不同方式传送：
1、持久传输连接，用于多个请求/响应传输。
2、每个请求/响应传输一个连接。
3、无连接模式。
传输连接类型由RTSP URI来定义。对 \"rtsp\" 方案，需要持续连接；而\"rtspu\"方案，调用RTSP 请求发送，而不用建立连接。
不象HTTP，RTSP允许媒体服务器给媒体用户发送请求。然而，这仅在持久连接时才支持，否则媒体服务器没有可靠途径到达用户，这也是请求通过防火墙从媒体服务器传到用户的唯一途径。
6.3.6 方法定义
方法记号表示资源上执行的方法，它区分大小写。新方法可在将来定义，但不能以$开头。
某些防火墙设计与其

㈢ 对于单播和点播来说，流媒体与机顶盒之间是通过什么协议来建立连接的

有线电视网络中视频节目的点播和单播，执行的都不是流媒体协议。仍然是用版MPEG协议打权包，再通过DVB-C协议调制打包之后的视频及音频信号。每一个点播或单播的节目，单独占据了一个传输信道。
电信网络中视频节目的点播和单播，在传输层执行的是TCP/IP协议，上层是不是执行流媒体协议，不是很了解。

㈣ 视频点播的实现过程

视频点抄播系统主要由片源库系统、流媒体服务系统、影柜系统、传输及交换网络、用户终端设备机顶盒+电视机或个人计算机组成。
视频点播的实现过程：当用户发出点播请求时，流媒体服务系统就会根据点播信息，将存放在片源库中的节目信息检索出来，以视频和音频流文件，通过高速传输网络传送到用户终端。
点播业务一般采用单播网络来实现，所谓单播就是利用一种协议将IP数据包从一个信息源传送到一个目的地，此时信息的接收和传递只在两个节点之间进行。IP单播中，只有一个发送方和一个接收方，同时双方具有相对固定的IP地址。IP单播传输是以太网传输中的主要使用方式，网络上绝大部分的数据都是以单播的形式传输，并且HTTP、RTSP、SMTP、FTP和Telnet都作为 TCP传输协议在网络中以单播的方式工作。单播的特点是每个终端都占用一定的带宽，当带宽占满之后，其它终端就无法连接至服务端。

㈤ 视频直播软件开发中常用的流媒体传输协议有哪些

视频直播软件系统开发，常用的流媒体传输协议有RTMP,RTSP,HLS,HTTP-FLV
RTMP:(可用于推流端和拉流端) Real Time Messaging Protocol 实时消息传输协议，RTMP协议中，视频必须是H264编码，音频必须是AAC或MP3编码，且多以flv格式封包。因为RTMP协议传输的基本是FLV格式的流文件，必须使用flash播放器才能播放.
RTSP:(用于推流端) Real-Time Stream Protocol，RTSP 实时效果非常好，适合视频聊天、视频监控等方向
HLS(用于拉流端) Http Live Streaming，由Apple公司定义的基于HTTP的流媒体实时传输协议。传输内容包括两部分：1.M3U8描述文件，2.TS媒体文件。TS媒体文件中的视频必须是H264编码，音频必须是AAC或MP3编码。数据通过HTTP协议传输。目前video.js库支持该格式文件的播放
HTTP-FLV(用于拉流端) 本协议就是http+flv,将音视频数据封装成FLV格式,然后通过http协议传输到客户端,这个协议大大方便了浏览器客户端播放直播视频流.目前flv.js库支持该格式的文件播放

㈥ 为什么国内视频网站多采用HTTP协议传输视频，而国外多使用RTMP等专门的流媒体协议

其实行业内目前是点播采用HTTP flv基本就可以搞定了，还可以加上一些私有的头验证等。
而直播的话，大部分还是采用RTMP或者私有协议，原因是延时会比较小，RTMP本身也是为了直播设计的。

㈦ 网络直播在直播时都有什么协议

视频直播有多种协议，使用rtmp协议的就是rtmp直播。直播流就是视频流，即传递的视频数据。常见的协专议有哪些？属RTMP、RTSP、HTTP协议这三个协议都属于互联网
TCP/IP
五层体系结构中应用层的协议。理论上这三种都可以用来做视频直播或点播。但通常来说，直播一般用
RTMP、RTSP。而点播用
HTTP。下面分别介绍下三者的特点。1，RTMP协议（1）是流媒体协议。（2）RTMP协议是
Adobe
的私有协议，未完全公开。（3）RTMP协议一般传输的是
flv，f4v
格式流。（4）RTMP一般在
TCP
1个通道上传输命令和数据。2，RTSP协议（1）是流媒体协议。（2）RTSP协议是共有协议，并有专门机构做维护。.（3）RTSP协议一般传输的是
ts、mp4
格式的流。（4）RTSP传输一般需要
2-3
个通道，命令和数据通道分离。3，HTTP协议（1）不是是流媒体协议。（2）HTTP协议是共有协议，并有专门机构做维护。（3）HTTP协议没有特定的传输流。（4）HTTP传输一般需要
2-3
个通道，命令和数据通道分离。

㈧ 视频实时点播系统应用层通信协议的设计

一是人机接口，也就是人在使用系统的终端时用户终端向用户提供的操作界面；二是用户终端与系统之间的应用层通信协议。 多媒体通信终端的用户对通信的全过程

㈨ 实现流媒体传输的主要协议有哪些各自的功能和任务是什么

基于Windows Media技术的流媒体系统的设计与实现

摘要：本文在简介流媒体技术及其中的Windows Media技术的基础上，结合实际简述了Windows Media服务器的安装、ASF文件的制作以及“点播单播发布点”、“广播单播发布点”、“多播广播站”的创建方法，从实践角度阐述了在网络中实现流媒体服务的技术和方法。
关键词：Windows Media 流媒体 网络视频
Windows Media-based streaming media technology, Design and Implementation

Abstract: This article profiles in streaming media technology in its Windows Media technology on the basis of the actual combined on a Windows Media server installation, ASF, as well as the proction of documents "on-demand unicast release point," "Broadcast Unicast release point," "Multicast broadcast stations," the creation of methods, and through links to web pages, etc. They may be related to the test, from the perspective of the practice described in the network to achieve streaming media services technologies and methods.
Key words: Windows Media streaming video network

1. 流媒体技术概述

流媒体简单地说就是应用流式传输技术在Internet/Intranet上传输的连续时基媒体，如：音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件，只将开始部分内容存入内存，流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。流式传输主要指通过网络传送媒体（如视频、音频）的技术总称。其特定含义为通过Internet将影视节目传送到PC机。流媒体技术是包含了采集、编码、传输、储存、解码等多项技术的综合技术。

2. Windows Media技术简介
2.1 特点

Microsoft公司推出的Windows Media技术具有方便性、先进性、集成性、低费用等特点，而且其制作、发布和播放软件与Windows NT/2000/9x集成在一起，不需要额外购买。Microsoft的流视频解决方案在Microsoft视窗平台上是免费的，制作端与播放器的视音频质量都上佳，而且易于使用。
2.2 Windows Media播放方式

Windows Media播放方式包括单播、多播、点播与广播。它们的含义如下表所示：
单播：是客户端与服务器之间的点到点连接。在客户端媒体服务器之间建立一个单独的数据通道，1台服务器送出的每个数据包只能传送给1个客户机。
多播：是通过启用多播的网络传递内容流，网络中的所有客户端共享同一流。由多播技术构建的网络，允许路由器一次将数据包复制到多个通道上。采用多播方式，媒体服务器只需要发送一个信息包，所有发出请求的客户端即可同时收到连续的数据流而无延时。多播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽，是理想的播放方式。
点播：是客户端与服务器之间的主动的连接。用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制，但这种方式由于每个客户端各自连接服务器，却会迅速用完网络带宽。
广播：指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流。例如，用户不能暂停、快进或后退该流。广播方式中数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要。此种传输方式会非常浪费网络带宽。
2.3 Windows Media视频技术组成

Windows Media视频服务器系统包括以下几个部分：Windows Media服务器组件、Windows Media工具、Windows Media Player。
2.4 Windows Media编码器

Windows Media编码器用于转换实时和存储的视频和音频内容为ASF流，然后通过Windows Media服务器在网络中传送。
2.5 Windows Media Player

Windows Media客户端软件称为Windows Media Player，由Windows Media服务器接收并播放流内容。Windows Media服务使用Windows Media Player以播放包含视频、音频、图像、URL和脚本内容的ASF流。Windows Media Player 9系列是最新版本。
2.6 Microsoft高级流格式ASF简介

Microsoft公司的Windows Media的核心是ASF（Advanced Stream Format）。 Microsoft将ASF定义为“同步媒体的统一容器文件格式”。ASF是一种数据格式，音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式，以网络数据包的形式传输，实现流式多媒体内容发布。

3. Windows Media校园流媒体系统的设计
3.1 网络结构设计

Windows Media流媒体系统包括服务器端和用户端两部分。服务器端包括Windows Media服务器、制作计算机。Windows Media服务器用于存储和发布流媒体信息。制作计算机安装视频采集卡、声卡及摄像机，用于制作流媒体文件。用户端安装Windows Media Player软件。数据传输依托校园网。
3.2 软硬件要求

3.2.1服务器

服务器硬件配置一般是PIII400以上CPU，内存在128~512M左右。操作系统Windows 2000 Server及Windows Media服务组件。
3.2.2制作计算机

制作计算机硬件配置一般是PIII400以上CPU，内存在128~512M，需要声卡、视频采集卡以及VCD或录像机。软件为Windows 98或Windows 2000 Professional，安装Windows Media编辑工具。

4. Windows Media校园流媒体系统的实现

4.1 ASF文件的制作

笔者在微机上安装了Broadway视频采集卡，并通过录像机采集了两段AVI格式的录像，分别命名为LX1.AVI和LX2.AVI。通过Windows 2000 Server自带的编码器Windows Media Encoder可以很容易地将两个AVI文件转换为ASF文件：LX1. ASF、 LX2. ASF。在F盘上建立文件夹ASF，将两个ASF文件存入（为表述方便，文中所用文件名、路径、计算机名称、IP等，皆为笔者实际实验过程所用，读者可根据自己实际环境确定这些内容）。也可用Windows Media编码器9系列存为WMV格式文件，但要求客户端播放器必须为7.0以上版本
4.2 使用“快速启动向导”创建“点播单播发布点”

在F盘上建立文件夹“asx”并设为共享，以便在后续操作中放置“.asx”通知文件。
在 Windows Media 管理器菜单框中单击“单播发布点”，出现“单播发布点”页。确保选择了“使用向导创建新的点播单播发布点”复选框，单击“点播”，然后单击“新建”， 出现“配置和发布单播点播流快速启动向导”。
在“选择一个发布点”屏幕中，选择“创建一个发布点”。在“创建一个新的发布点”屏幕中，在“别名”框中键入别名为“asf”。在“路径”框中，键入“F:\asf\”。在"查找目标 .asf 文件"屏幕，输入“F:\asf\lx1.asf”。在“选择发布方法”屏，选择“MMS协议”和“创建一个.asx文件”，然后选择 “下一步”。在“准备发布”屏幕中，选择 “完成”。
将“lx1.asx”通知文件保存到“F:\asx\”里面。在“发布完成”屏幕中，单击“测试 URL”、“测试 .asx”可以在 Windows Media Player 中传递点播单播发布点的流式化内容“lx1.asf”。