Standard Elements of RTP
The primary standard for audio/video transport in IP networks is the Real-time Transport Protocol (RTP), along with associated profiles and payload formats. RTP was developed by the Audio/Video Transport working group of the Internet Engineering Task Force (IETF), and it has since been adopted by the International Telecommunications Union (ITU) as part of its H.323 series of recommendations, and by several other standards organizations. RTP provides a framework for the transport of real-time media and needs to be profiled for particular uses before it is complete. The RTP profile for audio and video conferences with minimal control was standardized along with RTP, and several more profiles are under development. Each profile is accompanied by several payload format specifications, each of which describes the transport of a particular media format.
The RTP Specification
RTP was published as an IETF proposed standard (RFC 1889) in January 1996,HTPU6UTPH and its revision for draft standard status is almost complete.HTPU50UTPH The first revision of ITU recommendation H.323 included a verbatim copy of the RTP specification; later revisions reference the current IETF standard.
RTP typically sits on top of UDP/IP transport, enhancing that transport with loss detection and reception quality reporting, provision for timing recovery and synchronization, payload and source identification, and marking of significant events within the media stream. Most implementations of RTP are part of an application or library that is layered above the UDP/IP sockets interface provided by the operating system. This is not the only possible design, though, and nothing in the RTP protocol requires UDP or IP. For example, some implementations layer RTP above TCP/IP, and others use RTP on non-IP networks, such as Asynchronous Transfer Mode (ATM)
networks.
There are two parts to RTP: the Tdata transfer protocolT and an associated Tcontrol protocolT. The RTP data transfer protocol manages delivery of real-time data, such as audio and video, between end systems. It defines an additional level of framing for the media payload, incorporating a sequence number for loss detection, timestamp to enable timing recovery, payload type and source identifiers, and a marker for significant events within the media stream. Also specified are rules for In the IETF standards process,HTPU8UTPH a specification undergoes a development cycle in which multiple TInternet draftsT are produced as the details of the design are worked out. When the design is complete, it is published as a Tproposed standardT RFC. A proposed standard is generally considered stable, with all known design issues worked out, and suitable for implementation. If that proposed standard proves useful, and if there are independent and interoperable implementations of each feature of that standard, it can then be advanced to Tdraft standardT status (possibly involving changes to correct any problems found in the proposed standard). Finally, after extensive experience, it may be published as a full TstandardT RFC. Advancement beyond proposed standard status is a significant hurdle that many protocols never achieve. timestamp and sequence number usage, although these rules are somewhat dependent on the profile and payload format in use, and for multiplexing multiple streams within a session. The RTP data transfer protocol is discussed further in HTUChapter 4UTH.
The RTP control protocol (RTCP) provides reception quality feedback, participant identification, and synchronization between media streams. RTCP runs alongside RTP and provides periodic reporting of this information. Although data packets are typically sent every few milliseconds, the control protocol operates on the scale of seconds. The information sent in RTCP is necessary for synchronization between media streams—for example, for lip synchronization between audio and video—and can be useful for adapting the transmission according to reception quality feedback, and for identifying the participants. The RTP control protocol is discussed
further in HTUChapter 5UTH.
RTP supports the notion of TmixersT and TtranslatorsT, middle boxes that can operate on the media as it flows between endpoints. These may be used to translate an RTP session between different lower-layer protocols—for example, bridging between participants on IPv4 and IPv6 networks, or bringing a unicast-only participant into a multicast group. They can also adapt a media stream in some way—for example, transcoding the data format to reduce the bandwidth, or mixing multiple streams together.
It is hard to place RTP in the OSI reference model. It performs many of the tasks typically assigned to a transport-layer protocol, yet it is not a complete transport in itself. RTP also performs some tasks of the session layer (spanning disparate transport connections and managing participant identification in a transport-neutral manner) and of the presentation layer (defining standard representations for media data).
RTP Profiles
It is important to be aware of the limits of the RTP protocol specification because it is deliberately incomplete in two ways. First, the standard does not specify algorithms for media playout and timing regeneration, synchronization between media streams, error concealment and correction, or congestion control. These are properly the province of the application designer, and because different applications have different needs, it would be foolish for the standard to mandate a single behavior. It does, of course, provide the necessary information for these algorithms to operate when they have been specified. Later chapters will discuss application design and the trade-offs inherent in providing these features.
Second, some details of the transport are left open to modification by profiles and payload format definitions. These include features such as the resolution of the timestamps, marking of interesting events within a media stream, and use of the payload type field. The features that can be specified by RTP profiles include the
following:
? Mapping between the payload type identifier in the RTP header and the payload format specifications (which describe how individual media codecs are to be used with RTP). Each profile will reference multiple payload formats and may indicate how particular signaling protocols (for example, SDPHTPU15UTPH) are used to describe the mapping.
? The size of the payload type identifier field in the RTP header, and the number of bits used to mark events of interest within a media stream.
? Additions to the fix ed RTP data transfer protocol header, if that header proves insufficient for a particular class of application.
? The reporting interval for the RTP control protocol—for example, to make feedback more timely at the expense of additional overhead.
? Limit ations on the RTCP packet types that are to be used, if some of the information provided is not useful to that class of applications. In addition, a profile may define extensions to RTCP to report additional information.
? Additional security mechanisms—for example, new encryption and authentication algorithms.
? Mapping of RTP and RTCP onto lower-layer transport protocols.
At the time of this writing, there is a single RTP profile: the RTP profile for audio and video conferences with minimal control. This profile was published as a proposed standard (RFC 1890) along with the RTP specification in January 1996,HTPU7UTPH and its revision for draft standard status is almost complete.HTPU49UTPH Several new profiles are under development. Those likely to be available soon include profiles specifying additional security,HTPU55UTPH as well as feedback and repair mechanisms.HTPU44UTPH
RTP Payload Formats
The final piece of the RTP framework is the payload formats, defining how particular media types are transported within RTP. Payload formats are referenced by RTP profiles, and they may also define certain properties of the RTP data transfer protocol.
The relation between an RTP payload format and profile is primarily one of namespace, although the profile may also specify some general behavior for payload formats. The namespace relates the payload type identifier in the RTP packets to the payload format specifications, allowing an application to relate the data to a particular media codec. In some cases the mapping between payload type and payload format is static; in others the mapping is dynamic via an out-of-band control protocol. For example, the RTP profile for audio and video conferences with minimal controlHTPU7UTPH defines a set of static payload type assignments, and a mechanism for mapping between a MIME type identifying a payload format, and a payload type identifier using the Session Description Protocol (SDP).
The relation between a payload format and the RTP data transfer protocol is twofold: A payload format will specify the use of certain RTP header fields, and it may define an additional payload header. The output produced by a media codec is translated into a series of RTP data packets—some parts mapping onto the RTP header, some into a payload header, and most into the payload data. The complexity of this mapping process depends on the design of the codec and on the degree of error resilience required. In some cases the mapping is simple; in others it is more complex.
At its simplest, a payload format defines only the mapping between media clock and RTP timestamp, and mandates that each frame of codec output is placed directly into an RTP packet for transport. An example of this is the payload format for G.722.1 audio.HTPU36UTPH Unfortunately, this is not sufficient in many cases because many codecs were developed without reference to the needs of a packet delivery system and need to be adapted to this environment. Others were designed for packet networks but require additional header information. In these cases the payload format specification defines an additional payload header, to be placed after the main RTP header, and
rules for generation of that header.
Many payload formats have been defined, matching the diversity of codecs that are in use today, and many more are under development. At the time of this writing, the following audio payload formats are in common use, although this is by no means an exhaustive list: G.711, G.723.1, G.726, G.728, G.729, GSM, QCELP, MP3, and DTMF.HTPU30UTPHP,HPTPU34UTPHP,HPTPU38UTPHP,HPTPU49UTPH The commonly used video payload formats include H.261, H.263, and MPEG.HTPU9UTPHP,HPTPU12UTPHP,HPTPU22UTPH
There are also payload formats that specify error correction schemes. For example, RFC 2198 defines an audio redundancy encoding scheme,HTPU10UTPH and RFC 2733 defines a generic forward error correction scheme based on parity coding.HTPU32UTPH In these payload formats there is an additional layer of indirection, the codec output is mapped onto RTP packets, and those packets themselves are mapped to produce an error-resilient transport. Error correction is discussed in more detail in HTUChapter 9UTH, Error Correction.
Optional Elements
Two optional pieces of the RTP framework are worth mentioning at this stage: header compression and multiplexing.
THeader compressionT is a means by which the overhead of the RTP and UDP/IP headers can be reduced on a per-link basis. It is used on bandwidth-constrained links—for example, cellular and dial-up links—and can reduce the 40-byte combination of RTP/UDP/IP headers to 2 bytes, at the expense of additional processing by the systems on the ends of the compressed link. Header compression is discussed further in HTUChapter 11UTH.
TMultiplexingT is the means by which multiple related RTP sessions are combined into one. Once again, the motivation is to reduce overheads, except this time the procedure operates end-to-end. Multiplexing is discussed in HTUChapter
12UTH, Multiplexing and Tunneling.
Both header compression and multiplexing can be considered to be part of the RTP framework. Unlike the profiles and payload formats, they are clearly special-purpose, optional parts of the system, and many implementations don't use either feature.
二、英文翻译:
RTP的标准元素
音频/视频在互联网协议网络的传输的主要标准是实时传输协议，以及一系列的配置文件与有效载荷模式。RTP是被互联网工程任务组的音频/视频传输协议工作小组发展起来的，并且它已经被国际电信同盟以及其他一些标准组织所接纳，作为国际电信同盟推荐的H.323系列的一部分。RTP为实时媒体传输提供了一个框架，并且需要为特殊的用途配置文件才能完成。最低掌控度的音频、视频会议的实时传输协议配置文件是结合实时传输协议标准化的，并且一些其他的协议也处于发展之中。每一个配置文件都有几个格式规范的有效载荷与之匹配，它们中的每一个都描绘了一种特殊媒介格式的传输。
RTP的说明
RTP作为IETF的一种提案标准被发布于1996年1月，它的修订草案几乎是完整的。ITU建议第一本修订草案H.323包含了RTP说明的逐字逐句的复制，后来的修订草案则是关于现行的IETF的标准。
RTP特别设立了关于用户数据协议/互联网协议传输的掌控，加强了对于传输过程中的丢失跟接收质量报告，及时回馈跟同步性的规定，有效载荷跟来源认证，并且对媒体资料流中的重要事件进行标记。RTP中的大多数安装启用是运行系统提供的在用户数据协议/互联网协议接口处的应用程序或者文库。尽管这并不是唯一可能的设计，而且RTP协议中没有任何一条要求用户数据协议或者互联网协议，例如，一些安装启用使得RTP处于用户数据协议/互联网协议之上，而且其他一些也在无互联网协议下使用RTP网络，比如一步转换模式网络。
RTP由两部份构成：数据转换协议与相关的控制协议。RTP数据转换协议致力于数据及时传送，比如终端之间的音频跟视频。它定义了一个媒体有效载荷框架的额外水平，结合了丢失侦探序列，还有时间戳用来加强及时回馈，有效载荷类型跟来源认证，并且对媒体资料流之中的重要事件进行标记。
在IETF的标准化进程中，一个说明经历了一个发展周期，在这之中，多种被作为设计的细节而产生的因特网草案被策划出来。
当设计完成的时候，它被作为一个RTC的标准提案。一个标准提案通常被认为是一个稳定的，以及被解决的众所周知的设计问题，并且适合于启用。
如果该标准提案被证明是有效的，并且是独立而且此标准的每一个特征的启用都是彼此协作的，那么它将成为宪法草案（很可能包含改正所有在进程中发现的问
题的改变）。
最后，经过大量的实践，它也许会被作为一个完全标准的RTP。标准宪法提案的基础上的提升是一个中重要的挑战，大多数的协议都不曾到达过。
时间戳跟序列的使用，尽管这些规则都是有点依赖于配置文件跟有效载荷的使用以及对于多路技术与一个季节中的多重资源流。RTP控制协议提供接收质量反馈，参与性认证，以及在媒体资源流之间的同步性。
实施控制传输协议伴随RTP一起运行并提供这种信息的定期报告，尽管每几秒钟就有一些数据被打包并特别发送，控制协议都以秒的比例运行。
用RTCP发送的信息是媒体资料流之间的同步性所必须的——比如，音频与视频之间的同步对白录音——并且根据接收适量反馈报告，它对适应传动装置与认证参与者的身份也是很有用的。RTP支持混音器与翻译器的观念，能在媒体运行的就像它在中段之间的流动一样的中间盒子。这些也许会被用来翻译不同的比较底层的协议的服务器对话——比如，互联网通信协议第六版与第四版之间的嫁接，或者带来一个单一传播，作为一个多路传播的参与者。它们也能够用某种方式参与媒体流，比如，对数据格式进行代码转换以此来减少频带宽度，或者把多种资源流混合到一起。
把RTP放到开放式系统互联网参考模型里是很困难的。它执行了大多数的特别分派给运输层协议的任务，然而它自己并不是一个完整的运输系统。RTP也执行着一些会话层的任务（扩展单独的运输联系以及致力于对中立运输习惯参与者的身份认证）以及一些代表性层级（为媒体数据定义标准代表性）
RTP配置文件
明白RTP协议说明的限制性是很重要的，因为它在两个地方的不完整性是故意造成的。
第一，对媒体有效载荷的特定算法没有标准，并且时间的重复，媒体硫之间的同步性，错误的掩盖和改正，或者拥挤控制也都没有特定的标准。这些在应用设计的领域是合适的，并且因为不同的应用有不同的需要，对一个单一的反应制定标准是非常愚蠢的。它的确这些演算的一些特性的运行提供了必要的信息。
第二，运输的一些细节可以被协议，有效载荷模式的定义所修改。这些包括一些特点，比如时间戳的解决，媒体流中有资金交易事件的标记，以及有效载荷领域的使用。能被RTP定义的特点包括以下几点：
?在RTP数据头与有效载荷模式说明之间的有效载荷类型认证者之间的绘图（这种绘图描述了单个的多媒体数字编码解码器跟RTP一起使用的方法）。每一个协议将会与多重有效载荷模式相关联并且能暗示特殊信号协议（比如：信号资料处理器）是怎样描述绘图的。
?在RTP数据头中的有效载荷认证类型参与者领域的大小，用来标记媒体流中有资金交易的事件的字节的数量。
?固定的RTP数据转换协议数据头的附加，如果那个数据头被证明对于一个特殊阶层的应用时不充分的的
?RTP控制协议的报告间隔——比如，使得反馈在附加费用的方面更具有时效性。
?如果提供的信息被证明对那一层次的应用是无效的，实时传输控制协议的限制性将会被使用。另外，一个协议也许定义了对实时传输控制协议的扩展从而报告额外的信息。
?额外的安全机制——新的机密技术与鉴定算法。
?RTP的绘制与实时传输控制协议被加入底层地运输协议。
在写这篇文章的时候，有一个为最小控制中的音频与视频会议而单独设立的RTP协议。这个协议被作为标准提案并结合RTP说明被发布于1996年1月，并且它的修订草案几乎是完整的。一些新的协议仍处于发展之中。极有可能被很快使用的包括具体指明额外安全性的配置文件同样还有反馈与汇报机制。
RTP有效载荷模式
RTP模式的最后一块是有效载荷模式，定义了特殊媒体是怎样在RTP中传输的。RTP配置文件参考了有效载荷模式，并且它们也许也定义了RTP数据传输协议的特定条款。
RTP载体模式与配置文件之间的联系主要是命名空间中的一个，尽管配置文
件也许也为有效载荷模式指定了一些常规的反应。命名空间与在RTP中对有效载荷模式说明的有效载荷类型认证有关允许一种应用让数据与特殊媒体编码解码
器相关。在一些情况下，有效载荷类型与有效载荷模式的描述是静态的；在其他一些情况下，这些描述通过外带的控制协议为媒介变为动态的。比如，在最小控制范围内的音频视频会议的RTP协议定义了一些例静态的有效载荷类型作业，一种存在于多用途互联网邮件扩展类型认证一个有效载荷模式的描述机制，以及一个使用会话描述协议的有效载荷类型认证者。
存在于一个有效载荷模式与RTP数据传输协议之间的关系具有两面性：一种有效载荷模式将会定义特殊的RTP数据头领域的使用，并且它也可能定义了以个额外的有效载荷数据头。一个媒体编码解码器解码的结果被传输到一些例的RTP 数据打包中——一些部分的描述隐射了RTP数据头，一些深入到有效载荷数据头，并且大多数深入到有效载荷数据。这种复杂的描述进程依赖于编码解码器的设计与要求的错误恢复力的程度有关。在一些情况下这种描述是简单的；在其他的一些情况下它是比较复杂的。
在它最简单的时候，一个有效载荷模式仅仅定义了媒体计时器与RTP时间戳之间的描述，并且授权每一个编码解码器产生的结果的框架被直接放置到RTP数据包中运输。一个这种类型的例子是G.722.1音频的有效载荷模式。很不幸的，这在很多情况中是不具有充分说服力的，因为许多解码器是在于没有数据包的发送系统与环境的适应性无关的情况下发展出来的。其他的虽然有在数据包网络下设计，但是需要往外的数据头信息。在这些情况下有效载荷模式说明定义了额外的有效载荷数据头，将会被放置在主要的RTP数据头与那一阶段的数据头规则之后。
许多有效载荷模式已经被定义，与现在使用的编码解码器的多样性相匹配，更多的一些处于发展之中。在写作这些文章的时候，随后的音频有效载荷模式用于常规应用，尽管这毫无疑问意味着一个彻底的名单：G.711, G.723.1，G.726, G.728, G.729, GSM, QCELP, MP3, 以及DTMF.通用的视频有效载荷模式包括H.261, H.263, 以及MPEG.
也有一些特殊定义错误改正方案的有效载荷模式。比如：RFC2188定义了一个音频冗余编码方案，RFC2733定义了一类基于同等解码的正向纠错方案。在这
些有效载荷模式中有一个额外的错误层次，这个解码器的结果是被RTP数据包描述的，并且这些数据包自己是被描述来产生一个错误恢复力的运输。
选择性因素
RTP框架的两个在这个阶段很值得被提及的选择性因素：数据头压缩与多路技术。
数据头压缩是一种方式，通过这种方式RTP与用户数据协议/互联网协议数据头的费用能够在环环相扣的基础上被减少。它被用于频带宽度趋势连接——比如，单元与拨号连接，并且能减少实时传输协议/用户数据协议/互联网协议的数据头40字节，使得它变为2个字节，并且减少系统在终端压缩连接的额外加工费用。
多路技术一些方法，通过这些方法多种互相关联的RTP会话被结合为一个。再一次的，这种推动使用来减少费用，除了运行在终端与终端的程序。
数据头压缩与多路技术都能被认为是RTP框架的一部分。不像配置文件与有效载荷模式，它们使得特殊目标，系统的选择性部分，以及许多安装启用没有特殊的目的更加清晰。
rtsp简介(ZT) Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。RTSP消息格式: RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种 消息的格式不同. 请求消息: 方法URI RTSP版本CR LF 消息头CR LF CR LF 消息体CR LF 其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如 :rtsp://192.168.20.136 RTSP版本一般都是RTSP/1.0.每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF 回应消息: RTSP版本状态码解释CR LF 消息头CR LF CR LF 消息体CR LF 其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释. 简单的rtsp交互过程: C表示rtsp客户端,S表示rtsp服务端 1.C->S:OPTION request //询问S有哪些方法可用 1.S->C:OPTION response //S回应信息中包括提供的所有可用方法 2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息 2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp 3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会 话 3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息 4.C->S:PLAY request //C请求播放 4.S->C:PLAY response //S回应该请求的信息 S->C:发送流媒体数据 5.C->S:TEARDOWN request //C请求关闭会话 5.S->C:TEARDOWN response //S回应该请求
RTP协议分析 第1章. RTP概述 1.1. RTP是什么 RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP来提供。 1.2. RTP的应用环境 RTP用于在单播或多播网络中传送实时数据。它们典型的应用场合有如下几个。 简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。 音频和视频会议。如果在一次会议中同时使用了音频和视频会议，这两种媒体将分别在不同的RTP会话中传送，每一个会话使用不同的传输地址（IP地址＋端口）。如果一个用户同时使用了两个会话，则每个会话对应的RTCP包都使用规范化名字CNAME（Canonical Name）。与会者可以根据RTCP包中的CNAME来获取相关联的音频和视频，然后根据RTCP 包中的计时信息(Network time protocol)来实现音频和视频的同步。 翻译器和混合器。翻译器和混合器都是RTP级的中继系统。翻译器用在通过IP多播不能直接到达的用户区，例如发送者和接收者之间存在防火墙。当与会者能接收的音频编码格式不一样，比如有一个与会者通过一条低速链路接入到高速会议，这时就要使用混合器。在进入音频数据格式需要变化的网络前，混合器将来自一个源或多个源的音频包进行重构，并把重构后的多个音频合并，采用另一种音频编码进行编码后，再转发这个新的RTP包。从一个混合器出来的所有数据包要用混合器作为它们的同步源（SSRC，见RTP的封装）来识别，可以通过贡献源列表（CSRC表，见RTP的封装）可以确认谈话者。 1.3. 相关概念 1.3.1. 流媒体 流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式：下载和流式传输两种方式。 下载情况下，用户需要先下载整个媒体文件到本地，然后才能播放媒体文件。在视频直播等应用场合，由于生成整个媒体文件要等直播结束，也就是用户至少要在直播结束后才能看到直播节目，所以用下载方式不能实现直播。 流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的，所以接收端收到的数据包往往有延迟和乱序（流式传输构建在UDP上）。要实现流式传输，就是要从降低延迟和恢复数据包时序入手。在发送端，为降低延迟，往往对传输数据进行预处理（降低质量和高效压缩）。在接收端为了恢复时序，采用了接收缓冲；而为了实现媒体的流畅播放，则采用了播放缓冲。
1.1音视频编解码技术 1.1.1 MPEG4 MPEG全称是Moving Pictures Experts Group，它是“动态图象专家组”的英文缩写，该专家组成立于1988年，致力于运动图像及其伴音的压缩编码标准化工作，原先他们打算开发MPEG1、MPEG2、MPEG3和MPEG4四个版本，以适用于不同带宽和数字影像质量的要求。 目前，MPEG1技术被广泛的应用于VCD，而MPEG2标准则用于广播电视和DVD等。MPEG3最初是为HDTV开发的编码和压缩标准，但由于MPEG2的出色性能表现，MPEG3只能是死于襁褓了。MPEG4于1999年初正式成为国际标准。它是一个适用于低传输速率应用的方案。与MPEG1和MPEG2相比，MPEG4更加注重多媒体系统的交互性和灵活性MPEG1、MPEG2技术当初制定时，它们定位的标准均为高层媒体表示与结构，但随着计算机软件及网络技术的快速发展，MPEG1、MPEG2技术的弊端就显示出来了：交互性及灵活性较低，压缩的多媒体文件体积过于庞大，难以实现网络的实时传播。而MPEG4技术的标准是对运动图像中的内容进行编码，其具体的编码对象就是图像中的音频和视频，术语称为“AV对象”，而连续的AV对象组合在一起又可以形成AV场景。因此，MPEG4标准就是围绕着AV对象的编码、存储、传输和组合而制定的，高效率地编码、组织、存储、传输AV 对象是MPEG4标准的基本内容。 在视频编码方面，MPEG4支持对自然和合成的视觉对象的编码。（合成的视觉对象包括2D、3D动画和人面部表情动画等）。在音频编码上，MPEG4可以在一组编码工具支持下，对语音、音乐等自然声音对象和具有回响、空间方位感的合成声音对象进行音频编码。 由于MPEG4只处理图像帧与帧之间有差异的元素，而舍弃相同的元素，因此大大减少了合成多媒体文件的体积。应用MPEG4技术的影音文件最显著特点就是压缩率高且成像清晰，一般来说，一小时的影像可以被压缩为350M左右的数据，而一部高清晰度的DVD电影, 可以压缩成两张甚至一张650M CD光碟来存储。对广大的“平民”计算机用户来说，这就意味着, 您不需要购置DVD-ROM就可以欣赏近似DVD质量的高品质影像。而且采用MPEG4编码技术的影片，对机器硬件配置的要求非常之低，300MHZ 以上CPU，64M的内存和一个8M显存的显卡就可以流畅的播放。在播放软件方面，它要求也非常宽松，你只需要安装一个500K左右的MPEG4 编码驱动后，用WINDOWS 自带的媒体播放器就可以流畅的播放了 AV对象（AVO，Audio Visual Object）是MPEG-4为支持基于内容编码而提出的重要概念。对象是指在一个场景中能够访问和操纵的实体，对象的划分可根据其独特的纹理、运动、形状、模型和高层语义为依据。在MPEG-4中所见的音视频已不再是过去MPEG-1、MPEG-2中图像帧的概念，而是一个个视听场景（AV场景），这些不同的AV场景由不同的AV对象组成。AV对象是听觉、视觉、或者视听内容的表示单元，其基本单位是原始AV对象，它可以是自然的或合成的声音、图像。原始AV对象具有高效编码、高效存储与传输以及可交互性的特性，它又可进一步组成复合AV对象。因此MPEG-4标准的基本内容就是对AV对象进行高效编码、组织、存储与传输。AV对象的提出，使多媒体通信具有高度交互及高效编码的能力，AV对象编码就是MPEG-4的核心编码技术。 MPEG-4不仅可提供高压缩率，同时也可实现更好的多媒体内容互动性及全方位的存取性，它采用开放的编码系统，可随时加入新的编码算法模块，同时也可根据不同应用需求现场配置解码器，以支持多种多媒体应用 1.1.2 H264 H.264是由ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（活动图像编码专家组）联合组建的联合视频组（JVT：joint video team）提出的一个新的数字视频编码标准，
H5视频直播扫盲 1 H5到底能不能做视频直播 当然可以， H5火了这么久，涵盖了各个方面的技术。 对于视频录制，可以使用强大的webRTC（Web Real-Time Communication）是一个支持网页浏览器进行实时语音对话或视频对话的技术，缺点是只在PC的chrome上支持较好，移动端支持不太理想。 对于视频播放，可以使用HLS(HTTP Live Streaming)协议播放直播流，ios和android都天然支持这种协议，配置简单，直接使用video标签即可。 webRTC兼容性： video标签播放hls协议视频：
1 2 3 4 2 到底什么是HLS协议 简单讲就是把整个流分成一个个小的，基于HTTP的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS协议，存放视频流元数据的文件。 每一个.m3u8文件，分别对应若干个ts文件，这些ts文件才是真正存放视频的数据，m3u8文件只是存放了一些ts文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video标签会解析这个文件，并找到对应的ts文件来播放，所以一般为了加快速度，.m3u8放在web服务器上，ts文件放在cdn上。 .m3u8文件，其实就是以UTF-8编码的m3u文件，这个文件本身不能播放，只是存放了播放信息的文本文件： 1 2 3 4 5#EXTM3U m3u文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号#EXT-X-TARGETDURATION 每个分片TS的最大的时长#EXT-X-ALLOW-CACHE是否允许cache #EXT-X-ENDLISTm3u8文件结束符
RTP协议全解（H264码流和PS流） 写在前面：RTP的解析，网上找了很多资料，但是都不全，所以我力图整理出一个比较全面的解析， 其中借鉴了很多文章，我都列在了文章最后，在此表示感谢。 互联网的发展离不开大家的无私奉献，我决定从我做起，希望大家支持。 原创不易，转载请附上链接，谢谢https://www.doczj.com/doc/5715831849.html,/chen495810242/article/details/39207305 1、RTP Header解析 图1 1) V：RTP协议的版本号，占2位，当前协议版本号为2 2) P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 3) X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头
4) CC：CSRC计数器，占4位，指示CSRC 标识符的个数 5) M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 6) PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。 7) 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。 8) 时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 9) 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 10) 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 注：基本的RTP说明并不定义任何头扩展本身，如果遇到X=1，需要特殊处理 取一段码流如下： 80 e0 00 1e 00 00 d2 f0 00 00 00 0041 9b 6b 49 €?....??....A?kI e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P. cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|? f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q?? cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ???? 其中，
RTSP协议学习笔记 目录 RTSP协议学习笔记 (1) 第一部分:RTSP协议 (2) 一、RTSP协议概述 (2) 二、RTSP协议与HTTP协议区别 (2) 三、RTSP重要术语 (3) 1.集合控制(Aggregate control ): (3) 2.实体(Entity)： (3) 3.容器文件（Container file）： (3) 4.RTSP会话(RTSP session )： (3) 四、RTSP请求消息 (3) 1.消息格式： (3) 五、RTSP回应消息 (4) 1.消息格式： (4) 六、RTSP 重要方法 (4) 1. OPTIONS: (4) 2. DESCRIBE： (5) 3. SETUP： (6) 4. PLAY： (7) 5. PAUSE： (8) 6. TEARDOWN： (8) 七、RTSP重要头字段参数 (9) 1.Accept: (9) 2.Bandwidth: (9) 3. CSeq： (9) 4. Rang： (9) 5.Session: (9) 6.Transport: (9) 八、简单的RTSP消息交互过程 (10) 1.第一步：查询服务器端可用方法 (10) 2.第二步：得到媒体描述信息 (10) 3.第三步：建立RTSP会话 (10) 4.第四步：请求开始传送数据 (10) 5.第五步：数据传送播放中 (10) 6.第六步：关闭会话，退出 (10) 第二部分:SDP协议 (11) 一、SDP协议概述 (11) 二、SDP格式 (11) 三、SDP示例 (12) 第三部分:MMS协议 (13) 一、MMS协议概述 (13)
1.1 音视频编解码技术 1.1.1 MPEG4 MPEG全称是Moving Pictures Experts Group，它是“动态图象专家组”的英文缩写，该专家组成立于1988年，致力于运动图像及其伴音的压缩编码标准化工作，原先他们打算开发MPEG1、MPEG2、MPEG3和MPEG4四个版本，以适用于不同带宽和数字影像质量的要求。 目前，MPEG1技术被广泛的应用于VCD，而MPEG2标准则用于广播电视和DVD 等。MPEG3最初是为HDTV开发的编码和压缩标准，但由于MPEG2的出色性能表现， MPEG3只能是死于襁褓了。MPEG4于1999年初正式成为国际标准。它是一个适用于低传输速率应用的方案。与MPEG1和MPEG2相比，MPEG4更加注重多媒体系统的交互性和灵活性 MPEG1、MPEG2技术当初制定时，它们定位的标准均为高层媒体表示与结构，但随着计算机软件及网络技术的快速发展，MPEG1、MPEG2技术的弊端就显示出来了：交互性及灵活性较低，压缩的多媒体文件体积过于庞大，难以实现网络的实时传播。而MPEG4技术的标准是对运动图像中的内容进行编码，其具体的编码对象就是图像中的音频和视频，术语称为“AV对象”，而连续的AV对象组合在一起又可以形成AV场景。因此，MPEG4标准就是围绕着AV对象的编码、存储、传输和组合而制定的，高效率地编码、组织、存储、传输AV对象是MPEG4标准的基本内容。 在视频编码方面，MPEG4支持对自然和合成的视觉对象的编码。（合成的视觉对象包括2D、3D动画和人面部表情动画等）。在音频编码上，MPEG4可以在一组编码工具支持下，对语音、音乐等自然声音对象和具有回响、空间方位感的合成声音对象进行音频编码。 由于MPEG4只处理图像帧与帧之间有差异的元素，而舍弃相同的元素，因此大大减少了合成多媒体文件的体积。应用MPEG4技术的影音文件最显著特点就是压缩率高且成像清晰，一般来说，一小时的影像可以被压缩为350M左右的数据，而一部高
RTP 参考文档 RFC3550/RFC3551 Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： RTP ―传送具有实时属性的数据；RTP 控制协议（RTCP）―监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP 所提供的服务质量（Quality of Service）提供反馈。 RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。 SRTP & SRTCP 参考文档 RFC3711 安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3 月作为RFC3711发布。
Southwest university of science and technology 视频信息处理与传输 实验报告 报告名称RTP-RTCP协议 专业班级电子1002班 学生姓名 学号 指导教师
实验四RTP-RTCP协议 一、实验目的 1、了解实时传输协议RTP和实时传输控制协议RTCP的基本原理； 2、学习使用RTP数据报发送实时数据，并接收重组； 3、学会使用Wireshark进行抓包，并分析数据。 二、实验内容 1、RTP协议报文段的说明语句 RTP（Real-time Transport Protocol，实时传输协议）是一个网络传输协议。RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图1所示，其中： 图1 RTP报头格式 V：RTP协议的版本号，占2位，当前协议版本号为2。 P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。 CC：CSRC计数器，占4位，指示CSRC 标识符的个数。 M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。 PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM 音频、JPEM图像等。 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。 2、RTCP协议报文段的说明语句 RTCP（RTP Control Protocol,控制协议）——监控服务质量并传送正在进行的会话参与者的相关信息。RTCP包括五种数据包类型（RFC3550 Page69）：
E-mail：bryanj@https://www.doczj.com/doc/5715831849.html, 译者：Bryan.Wong（王晶，宁夏固原） 译文版本：alpha 0.80 译文发布时间：2007-7-25 版权：本中文翻译文档之版权归王晶所有。可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。 https://www.doczj.com/doc/5715831849.html,/filedownload?user=bryanj&id=611206 网络工作组 H. Schulzrinne 请求注释: 2326 哥伦比亚大学. 类别: 标准跟踪 A. Rao Netscape R. Lanphier RealNetworks 1998年4月 实时流协议(RTSP) 本备忘录状态 本文为Internet社区描述了一种Internet标准跟踪协议，还需要讨论和建议以便进行改善。请查看最新版本的"Internet正式协议标准"（STD 1）了解本协议的标准化进程和状态。本备忘录的传播不受限制。 版权声明： 版权为The Internet Society 所有。所有权利保留。 摘要： 实时流协议（RTSP）是应用层协议，控制实时数据的传送。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。本协议旨在于控制多个数据发送会话，提供了一种选择传送途径（如UDP、组播UDP与TCP）的方法，并提供了一种选择基于RTP (RFC1889)的传送机制的方法。
目录： 1 介绍 1.1 目的 1.2 要求 1.3 术语 1.4 协议特性 1.5 RTSP扩展 1.6 整体运作 1.7 RTSP状态 1.8 与其他协议的关系 2 符号协定 3 协议参数 3.1 RTSP版本 3.2 RTSP URL 3.3 会议标识 3.4 会话标识 3.5 SMPTE 相对时间戳 3.6正常播放时间 3.7 绝对时间 3.8 选项标签 3.8.1 用IANA注册新的选项标签*4 RTSP消息 4.1 消息类型 4.2 消息头
即時傳輸協議RTP（Realtime Transport Protocol）：是針對Internet上多媒體資料 流程的一個傳輸協定, 由IETF(Internet工程任務組)作為RFC1889發佈。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間資訊和實現流同步。RTP的典型應用建立在UDP上，但也可以在TCP或ATM等其他協議之上工作。RTP本身只保證即時資料的傳輸，並不能為按順序傳送資料包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。 即時傳輸控制協議RTCP（Realtime Transport Control Protocol）：負責管理傳輸品 質在當前應用進程之間交換控制資訊。在RTP會話期間，各參與者週期性地傳送RTCP包，包中含有已發送的資料包的數量、丟失的資料包的數量等統計資料， 因此，伺服器可以利用這些資訊動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的回饋和最小的開銷使傳輸效率最佳化，故特 別適合傳送網上的即時資料。 RTCP主要有4個功能: （1）用回饋資訊的方法來提供分配資料的傳送品質，這種回饋可以用來進行流量的擁塞控制，也可以用來監視網路和用來診斷網路中的問題； （2）為RTP源提供一個永久性的CNAME（規範性名字）的傳送層標誌，因為在發現衝突或者程式更新重啟時SSRC(同步源標識)會變，需要一個運作痕跡，在一組相關的會話中接收方也要用CNAME來從一個指定的與會者得到相聯繫的資料流程（如音頻和視頻）； （3）根據與會者的數量來調整RTCP包的發送率； （4）傳送會話控制資訊，如可在用戶介面顯示與會者的標識，這是可選功能。 4.2 RTP/RTCP工作過程 工作時，RTP協議從上層接收流媒體資訊碼流（如H.263），裝配成RTP資料包發送給下層，下層協定提供RTP和RTCP的分流。如在UDP中，RTP使用一個偶 數號埠，則相應的RTCP使用其後的奇數號埠。RTP資料包沒有長度限制，它的 最大包長只受下層協議的限制。 4.3 伺服器的演算法 伺服器軟體模型主要有兩種，即併發伺服器和迴圈伺服器。迴圈伺服器(Iterative
资源下载： https://www.doczj.com/doc/5715831849.html,/source/444512 实时流协议RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP(实时传输）和RTCP（实时控制）之上，它使用TCP或RTP完成数据传输。HTTP与RTSP相比，HTTP传送HTML，而RTP传送的是多媒体数据。HTTP请求由客户机发出，服务器作出响应；使用RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。 实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。 RTSP是应用级的协议，完成多媒体服务器的远程控制，控制信息的传输可以使用TCP，控制指令包括如：Setup、Play、Record、Pause、Teardwon等等。 对于流媒体应用，用户和服务器都可以发出请求，请求包括几种连接方法：持久、每个请求/响应传输一个连接、无连接。 常见的URL流媒体地址如： rtsp://https://www.doczj.com/doc/5715831849.html,:554 RTP 数据报组成：Header + Payload RTCP：应用程序启动RTP会话时将同时占用两个端口，供RTP和RTCP使用。 如果有必要，RTP使用时可以有两个伴随文档：1）配置文档，定义负载的编码类型和格式。2）负载格式的规范文档。 在流传输过程中，有两类服务完成对流的转发处理： 1）译流服务器Translator，进入的流在流出时发生变化，作用之一是更好地穿越防火墙。 2）混流服务器Mixer，多个流进入，合并后变成一个流流出。 由于进入的流可能有多个源，比如视频会议，会有多个话筒和视频头等等情况，对于RTP来说，就有一个同步化源的问题，因此，RTP协议中用SSRC（Synchronization Source）字段来供Mixer实现同步功能。 Translator的一个作用是多播变成多个单播。 为了提供播放和回放功能，RTP提供时间标签+序列号，在流动的概念中，时间标签是最重要的信息。 RTP报文不提供长度和报文边界的描述。 RTP虽然是传输层协议，但没有在OSI体系中作为单独的层来使用。 RTP是目前解决流媒体实时传输问题的最好办法，如果要开发，可以选择JRTPLIB库。JRTPLIB是一个面向对象的RTP库，它完全遵循RFC 1889设计。JRTPLIB是一个用C++语言实现的RTP库，目前已经可以运行在Windows、Linux、FreeBSD、Solaris、Unix和VxWorks等多种操作系统上。 了解更多RTP参考： https://www.doczj.com/doc/5715831849.html,/zouzheng/archive/2008/01/04/38449.html 下面的例子参考jrtplib的example1,加了解析负载的部分。 // RTPClient.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "rtpsession.h"
3.1. RTP协议分析 3.1.1. RTP是什么 RTP全名是Real-time Transport Protocol（实时传输协议）。它是IETF提出的一个标准，对应的RFC文档为RFC3550（RFC1889为其过期版本）。RFC3550不仅定义了RTP，而且定义了配套的相关协议RTCP（Real-time Transport Control Protocol，即实时传输控制协议）。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由RTCP 来提供。 3.1.2. RTP的协议层次 ——传输层的子层 RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。
3.1.3. RTP协议原理 RTP协议原理比较简单，负责对流媒体数据进行封包并实现媒体流的实时传输，即它按照RPT数据包格式来封装流媒体数据，并利用与它绑定的协议进行数据包的传输，具体见本文2.2.1RTP数据格式；RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。 3.1.3.1. RTP的封装 版本号（V）：2比特，用来标志使用的RTP版本。 填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。 扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩
信令与协议分册目录 目录 第2章RTP与RTCP协议...................................................................................................... 2-1 2.1 概述................................................................................................................................... 2-1 2.2 RTP/RTCP协议应用.......................................................................................................... 2-1 2.3 报文格式和含义................................................................................................................. 2-2 2.3.1 RTP报头的格式 ...................................................................................................... 2-2 2.3.2 RTCP包格式........................................................................................................... 2-3 2.3.3 RTCP的主要功能.................................................................................................... 2-3 2.3.4 RTCP发送间隔 ....................................................................................................... 2-4
竭诚为您提供优质文档/双击可除 http视频流传输协议 篇一：流媒体传输技术 流媒体科技名词定义中文名称：流媒体英文名称：streamingmedia定义：采用流式传输的方式在因特网与内联网播放的媒体格式。应用学科：通信科技（一级学科）；服 务与应用（二级学科）以上内容由全国科学技术名词审定委员会审定公布求助编辑百科名片所谓流媒体是指采用流式 传输的方式在internet播放的媒体格式。流媒体又叫流式 媒体，它是指商家用一个视频传送服务器把节目当成数据包发出，传送到网络上。用户通过解压设备对这些数据进行解压后，节目就会像发送前那样显示出来。目录 a/V服务器建立联系，是为了能够把服务器的输出重定 向到一个不同于运行a/Vhelper程序所在客户机的目的地址。实现流式传输一般都需要专用服务器和播放器，其基本原理如图所示。 智能流技术（surestream） 今天，28.8kbps调制解调器是internet连接的基本速率，cablemodem、adsl、dss、isdn等发展快，内容提供商
不得不要么限制发布媒体质量，要么限制连接人数。根据Realnetwork站点统计，对28.8kbps调制解调器，实际流量为10bps到26kbps，呈钟形分布，高峰在20kbps。这意味着若内容提供商选择20kbps固定速率，将有大量用户得不到好质量信号，并可能停止媒体流而引起客户端再次缓冲，直到接收足够数据。一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲，在Realsystem5.0中，这种方法称为“视频流瘦化”。这种方法的限制是RealVideo文件为一种数据速率设计，结果可通过抽取内部帧扩展到更低速率，导致质量较低。离原始数据速率越远，质量越差。另一种解决方法是根据不同连接速率创建多个文件，根据用户连接，服务器发送相应文件，这种方法带来制作和管理上的困难，而且，用户连接是动态变化的，服务器也无法实时协调。智能流技术通过两种途径克服带宽协调和流瘦化。首先，确立一个编码框架，允许不同速率的多个流同时编码，合并到同一个文件中；第二，采用一种复杂客户/服务器机制探测带宽变化。 针对软件、设备和数据传输速度上的差别，用户以不同带宽浏览音视频内容。为满足客户要求，progressivenetworks公司编码、记录不同速率下媒体数据，并保存在单一文件中，此文件称为智能流文件，即创建可扩展流式文件。当客户端发出请求，它将其带宽容量传给服务
RTP 参考文档RFC3550/RFC3551 Real-time Tran sport Protocol）是用于In ternet 上针对多媒体数据流的一 种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk ）系统（配合 H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP本身并没有提供按时发送机制或其它服务质量（QoS保证，它依赖于低层服务去实现这一过程。RTP并不保证传送或防止无序传送，也不确定底层网络的可靠 性。RTP实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也 能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP由两个紧密链接部分组成：RTP —传送具有实时属性的数据；RTP控制协议（RTCP —监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 实时传输控制协议（Real-time Tran sport Control Protocol 或RTP Co ntrol Protocol或简写RTCP是实时传输协议（RTR的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band ）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打 包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP 所提供的服务质量（Quality of Service ）提供反馈。 RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失 分组数，jitter ，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试 图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据 加密或身份认证。SRTCP可以用于此类用途。 SRTP & SRTCP 参考文档RFC3711 安全实时传输协议（Secure Real-time Tran sport Protocol 或SRTP 是在实时传输协议（Real-time Tran sport Protocol或RTF）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
实时传输协议RTP 1.RTP协议： RTP（ Real-time Transport Protocol）协议最初是在70年代为了尝试传输声音文件，把包分 成几部分用来传输语音，时间标志和队列号。经过一系列发展，RTP第一版本在 1991年8月由美国的一个实验室发布了。到本世纪1996年形成了标准的的版本。很多著名的公司如Netscape ,就宣称“Netscape LiveMedia”是基于RTP协议的。Microsoft 也宣称他们的“NetMeeting”也是支持RTP协议. RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重 的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。RTP与辅助控制协议RTCP一起得到数据传输的一些相关的控制信息。 2．RTP协议的工作原理： 如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。RTP协议就是提供了时间标签,序列号以及 其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。不同的媒体格式调时属性是不一样的。但是RTP本身并不负责同步，RTP只是传输层协议，为了 简化了运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层 完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保 证实时地传输数据，不支持资源预留，也不保证服务质量。RTP报文甚至不包括长度和报文边界的描述。同时RTP协议的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 RTP协议和UDP二者共同完成运输层协议功能。UDP协议只是传输数据包，是不管数据包传输的时间顺序。RTP的协议数据单元是用UDP分组来承载的。在承载RTP数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而UDP的多路复用让RTP协议利用支持显式的多点投递，可以满足多媒体会话的需求。 RTP协议虽然是传输层协议但是它没有作为OSI体系结构中单独的一层来实现。RTP协议通常根据一个具体的应用来提供服务， RTP只提供协议框架，开发者可以根据应用的具体要求对协议进行充分的扩展。目前，RTP的设计和研究主要是用来满足多用户的多媒体会议的需要，另外它也适用于连续数据的存储，交互式分布仿真和一些控制、测量的应用中。基于RTP的实验和商业产品也层出不穷。最常用的协议是RTMP(Real Time Messaging Protocol，实时消息传送协议)，RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。还有RTSP,HLS等。 实时传输控制协议RTCP协议 1. RTCP协议： RTCP（Real-time Transpor、Control Protocol）是设计和RTP一起使用的进行流量控制和拥塞控制的服务控制协议。 2. RTCP协议如何工作： 当应用程序开始一个RTP会话时将使用两个端口：一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务。在RTP的会话之间周期的发放一些RTCP包以用来传监听服务质量和交换会话用户信息等功能。RTCP包中含有已发送的数据包的数量、丢失的数据包的数量等统计资料。因此，服务器可以利 用这些信息动态地改变传输速率，甚至改变有效载荷类型。RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特别适合传送网上的实时数据。根据用户间的数