RTSP中文版(实时流媒体协议)
RTSP协议实时流传输协议简介
RTSP协议实时流传输协议简介RTSP（Real-Time Streaming Protocol）是一种用于实时流传输的网络协议。
它的主要作用是控制多媒体服务器上的流媒体数据，实现实时的传输和控制。
一、RTSP协议的概述RTSP协议是由IETF（Internet Engineering Task Force，互联网工程任务组）制定的一种应用层协议。
它通过控制服务端上的媒体数据流，为客户端提供实时播放、暂停、倒带、快进等控制功能。
二、RTSP协议的特点1. 实时性：RTSP协议能够提供低延迟的实时传输，适用于对实时性要求较高的应用场景，如视频监控、视频会议等。
2. 灵活性：RTSP协议支持多种编解码器、多种传输协议，可以适应不同的网络环境和设备要求。
3. 扩展性：RTSP协议允许通过扩展方式定义新的方法和参数，以满足个性化的业务需求。
三、RTSP协议的工作原理1. 客户端发送请求：客户端通过建立RTSP连接向服务器发送命令请求，如PLAY、PAUSE、SETUP等。
这些命令指示服务器开始、暂停或切换媒体流的传输。
2. 服务器响应请求：服务器接收到客户端的请求后，将相应的媒体流数据传输给客户端，并返回相应的状态码和信息。
3. 媒体流传输：客户端通过UDP或TCP协议与服务器建立数据传输通道，实现实时媒体流的传输。
4. 控制指令交互：客户端与服务器之间进行控制指令的交互，如快进、快退、暂停等，实现对媒体流的控制。
四、RTSP协议与RTP协议的关系RTSP协议通常与RTP（Real-Time Transport Protocol）协议配合使用。
RTP协议负责将媒体数据进行分片并在网络中传输，而RTSP协议则负责控制RTP协议的传输和播放。
两者配合使用，可以实现流媒体的实时传输和控制。
五、RTSP协议的应用场景1. 视频监控：RTSP协议适用于实时监控系统，可以帮助实现远程监控图像的实时传输和控制。
2. 视频会议：RTSP协议可以实现多方视频会议中的视频数据传输和控制，保证会议的实时性和流畅性。
RTSP协议
状态码
状态码是服务器试图理解和满足请求报文的结果代码，由三位数 字组成，其中第1位表示响应的分类，一共是5大类，剩余两位 并未分类： 1xx，Informational 接受请求，持续处理； 2xx，Success 成功地接受理解行为； 3xx，Redirection 为了完成请求采取进一步的措施； 4xx，Client Error 请求存在语法错误，或不能被执行； 5xx，Server Error 服务器不能执行正确的请求。 状态码是可扩展的，对RTSP应用软件来说没有必要理解全部注 册状态码的含义，但需要理解第1位表示的类别，这样就可以将 一些不能够识别的状态码等同于该类别的x00代码来对待。
RTSP协议是应用层协议
应用层
RTSP RTP/RTCP
传输层
TCP
网络层
UDP
IP
RTSP协议的工作原理
RTSP中的所有的操作都是通过服务器和客户端的消息应答来完成 的，其消息包括请求（Request）和响应（Response）两种。 通过服务器和客户端的消息应答来完成媒体流的创建、初始化 （SETUP）、VCR控制（PLAY、PAUSE）以及拆线 （TEARDOWN）等操作的。
= |
请求首部（Require-Header）
请求首部（Require-Header）允许向服务器传送请 求行之外的以及客户端自身的一些信息，类似于程 序中方法所使用的传送参数。
request-header = Accept | Accept-Encoding | Accept-Language | Authorization | Proxy-Require | User-Agent | Range | Scale | Session | Speed | Transport 。。。
流媒体协议标准RTSP
DESCRIBE CC->S ANNOUNCE CC->S, S->C SGET_PARAMETER C->S, S->C CSOPTIONS CC->S, S->C SPAUSE PLAY RECORD REDIRECT SETUP SET_PARAMETER TEARDOWN CC->S CC->S CC->S SS->C CC->S CC->S, S->C SCC->S
2:消息头部结构 语法RFC889规定,类似HTTP/SIP等协议 语法RFC889规定,类似HTTห้องสมุดไป่ตู้/SIP等协议 messagemessage-header = field-name ":" [ field-value ] fieldfield其语义有协议自身规定,一次请求或者响应可以有多个头结构.
RTSP方法——rtsp交互指令 RTSP方法——rtsp交互指令 A: option 方法,这是一个双向的方法,两端请求对方的能力集.
OPTIONS * RTSP/1.0 SEQ :1 SESSION:12345678
B: DESC方法,用在客户端,向媒体源请求媒体发布信息. DESC方法,用在客户端,向媒体源请求媒体发布信息.
2:快进,快退,后退方法实现 Scale header 这个RTSP头,指定了相对于正常播放速率的比率.该头部参数,可以由Record 这个RTSP头,指定了相对于正常播放速率的比率.该头部参数,可以由Record Play方法携带; Play方法携带; PAUSE这个会话.然后使用定义的Sacle值来设定Play. PAUSE这个会话.然后使用定义的Sacle值来设定Play. PLAY rtsp:///audio RTSP/1.0 CSeq: 836 Session: 12345678 Scale:2 //两倍速率快进 //两倍速率快进 Scale:0.5 Scale:Scale:-1 Scale:Scale:-2 Scale:Scale:-0.5 //1/2倍速率慢进 //1/2倍速率慢进 //后退 //后退 //两倍速度快退 //两倍速度快退 //半倍速度快退 //半倍速度快退
RTSP协议详解中文版
RTSP协议详解中文版RTSP（Real Time Streaming Protocol）是一种用于控制实时流媒体的应用层协议，用于在客户端和服务器之间进行媒体资源的传输和控制。
它工作在TCP或UDP上，并且可以与各种流媒体服务器和客户端软件兼容。
RTSP协议的通信模型是基于客户端和服务器之间的请求和响应。
客户端通过发送请求来向服务器发送控制指令，服务器则通过发送响应来告知客户端请求的结果。
请求和响应是基于文本的，并且使用类似于HTTP的格式。
RTSP协议的请求由方法、URL和协议版本组成。
常见的请求方法包括DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等。
DESCRIBE方法用于获取媒体资源的描述信息，SETUP方法用于建立与服务器的连接，PLAY方法用于开始播放，PAUSE方法用于暂停播放，TEARDOWN方法用于关闭连接。
RTSP协议的响应由状态码、状态描述和协议版本组成。
常见的状态码包括200 OK，表示请求成功；401 Unauthorized，表示未经授权；404 Not Found，表示资源不存在等。
状态码和状态描述用于告知客户端请求的结果。
RTSP协议还支持使用SDP（Session Description Protocol）来描述媒体资源。
SDP是一种用于描述会话信息的协议，它可以描述媒体资源的类型、媒体格式、传输地址等。
客户端可以使用DESCRIBE方法获取媒体资源的SDP描述，从而可以解析和播放媒体资源。
RTSP协议的优点包括灵活性和互操作性。
由于RTSP协议本身只负责控制，而不直接传输媒体数据，因此可以适用于各种不同的流媒体传输协议，如RTP、RTCP、RTMP等。
同时，RTSP协议还可以与其他媒体相关的协议配合使用，如RTSP over HTTP、RTSP over SSL等。
总结起来，RTSP协议是一种用于实时流媒体控制的协议，它可以实现实时流媒体的连续控制和广泛的交互性。
RTSP协议实时流媒体传输的基本协议
RTSP协议实时流媒体传输的基本协议随着互联网的发展和网络带宽的提升，实时视频流媒体传输变得越来越普遍。
为了满足用户对实时视频的需求，一种被广泛应用的协议是实时流媒体传输协议（Real-Time Streaming Protocol，RTSP）。
一、什么是RTSP协议？RTSP协议是一种应用层协议，旨在管理和控制实时流媒体的传输。
它允许客户端和服务器之间进行交互和通信，以控制媒体播放，例如播放、暂停、停止、快进和倒退等。
RTSP协议使用基于文本的请求和响应模型，类似于HTTP协议。
客户端向服务器发送请求，服务器通过响应来回应客户端的请求。
这种交互的方式使得RTSP协议具有灵活性，同时也增加了其可扩展性。
二、RTSP协议的工作原理RTSP协议在实时流媒体传输中起着重要的作用。
以下是RTSP协议的基本工作原理：1. 建立连接客户端与服务器之间首先建立RTSP连接。
通常，客户端会向服务器发送一个OPTIONS请求，以确认服务器是否支持RTSP协议。
服务器回复一个带有支持的方法列表的响应。
2. 会话描述客户端发送一个DESCRIBE请求，请求服务器提供有关媒体资源的描述信息。
服务器回复一个带有媒体描述的响应，包括媒体类型、媒体格式等信息。
3. 控制会话客户端通过发送SETUP请求来建立媒体传输的会话。
服务器回复一个带有会话标识符的响应，以便将来的操作都与该会话标识符相关联。
4. 媒体控制客户端可以通过发送PLAY、PAUSE、TEARDOWN等请求来控制媒体的播放，暂停和停止。
服务器相应地回复相关响应来执行相应操作。
5. 终止连接当会话结束时，客户端发送TEARDOWN请求来终止与服务器的连接。
三、RTSP协议的优点和应用场景RTSP协议具有以下几个优点：1. 灵活性和可定制性RTSP协议允许客户端与服务器之间进行多种交互，提供了灵活的控制和管理实时流媒体的能力。
客户端可以根据需要控制媒体的播放、暂停、停止等操作，满足不同的需求。
RTSP协议转换RTMP直播协议 (2)
RTSP协议转换RTMP直播协议协议名称：RTSP协议转换RTMP直播协议一、背景和目的RTSP（Real-Time Streaming Protocol）是一种用于实时数据传输的网络协议，常用于流媒体服务。
RTMP（Real-Time Messaging Protocol）是一种用于实时数据传输的协议，常用于视频直播。
本协议的目的是将RTSP协议转换为RTMP直播协议，以实现流媒体服务的直播功能。
二、定义和缩写1. RTSP：Real-Time Streaming Protocol，实时流媒体传输协议。
2. RTMP：Real-Time Messaging Protocol，实时消息传输协议。
三、协议内容1. 协议概述本协议定义了将RTSP协议转换为RTMP直播协议的过程和规则。
2. 协议流程2.1 客户端发送RTSP请求客户端向服务器发送RTSP请求，请求指定的流媒体资源。
2.2 服务器响应RTSP请求服务器接收到RTSP请求后，根据请求内容进行处理，并向客户端发送RTSP 响应。
2.3 客户端发送RTMP连接请求客户端通过RTMP连接请求向服务器发起连接请求，包括连接参数和握手过程。
2.4 服务器响应RTMP连接请求服务器接收到RTMP连接请求后，进行握手过程，并向客户端发送握手响应。
2.5 客户端发送RTMP发布请求客户端通过RTMP发布请求向服务器发送发布请求，包括发布参数和发布流媒体数据。
2.6 服务器响应RTMP发布请求服务器接收到RTMP发布请求后，根据请求内容进行处理，并向客户端发送发布响应。
2.7 客户端发送流媒体数据客户端通过RTMP协议向服务器发送流媒体数据，包括音频、视频等。
2.8 服务器转发流媒体数据服务器接收到客户端发送的流媒体数据后，进行相应的处理，并将数据转发给其他客户端。
3. 协议规则3.1 RTSP请求规则- 请求方法：支持常见的RTSP请求方法，如OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN等。
rtsp协议书介绍
rtsp协议书介绍甲方（提供方）：_____________________乙方（使用方）：_____________________鉴于甲方拥有合法的RTSP（Real Time Streaming Protocol）流媒体服务提供能力，乙方需要使用甲方提供的RTSP服务进行实时音视频传输。
为明确双方的权利和义务，特订立本协议。
第一条定义1.1 RTSP：即实时流媒体协议，是一种网络控制协议，用于建立和控制音视频数据的实时数据流。
1.2 流媒体服务：指通过RTSP协议传输的音视频数据服务。
1.3 服务期限：指本协议约定的乙方使用甲方RTSP服务的时间范围。
第二条服务内容2.1 甲方同意在服务期限内向乙方提供符合行业标准的RTSP流媒体服务。
2.2 乙方应按照甲方提供的技术要求和操作指南使用RTSP服务。
第三条服务期限3.1 本协议服务期限自____年____月____日起至____年____月____日止。
第四条费用及支付方式4.1 乙方应按照本协议约定向甲方支付服务费用，具体金额为：___________。
4.2 乙方应在本协议签订之日起____天内支付首期服务费用，后续费用按照____支付。
第五条甲方的权利和义务5.1 甲方有权根据本协议约定收取服务费用。
5.2 甲方应保证所提供的RTSP服务的稳定性和安全性。
5.3 甲方应提供必要的技术支持和咨询服务。
第六条乙方的权利和义务6.1 乙方有权按照本协议约定使用甲方提供的RTSP服务。
6.2 乙方应按时支付服务费用。
6.3 乙方应遵守甲方提供的使用指南和操作规范，不得进行任何可能影响服务稳定性和安全性的行为。
第七条保密条款7.1 双方应对在履行本协议过程中知悉的对方商业秘密予以保密。
7.2 未经对方书面同意，任何一方不得向第三方披露、提供或允许第三方使用上述商业秘密。
第八条违约责任8.1 如一方违反本协议约定，应承担违约责任，并赔偿对方因此遭受的损失。
RTSP协议详解中文版
RTSP协议详解中文版RTSP（Real Time Streaming Protocol）是一种用于控制媒体流传输的应用层协议。
它在传输数据之前，通过建立控制信道，协商会话参数，完成媒体流的控制和管理。
本文将详细介绍RTSP协议的各个方面。
RTSP协议中，客户端发送请求，服务器回复响应，请求和响应的消息格式基于文本，并且可以使用多种传输协议（如TCP或UDP）进行通信。
RTSP协议定义了丰富的方法（Method），以便客户端可以控制会话的各个方面。
常用的方法包括OPTIONS，DESCRIBE，SETUP，PLAY和TEARDOWN。
OPTIONS方法用于查询服务器支持的方法，客户端可以通过此方法获取服务器的能力信息。
DESCRIBE方法用于获取媒体会话的描述信息，客户端可以通过此方法获得媒体流的信息，例如编码格式和媒体地址。
SETUP方法用于建立媒体流的传输通道，客户端可以通过此方法告知服务器自己的传输能力，并请求服务器向其指定的地址发送数据。
服务器可以根据实际情况来进行响应，例如选择合适的传输协议（如TCP或UDP）以及传输端口。
PLAY方法用于开始播放媒体流，服务器会将实时传输协议（RTP）数据发送给客户端。
客户端可以通过TEARDOWN方法来终止会话，服务器在接收到TEARDOWN请求后会释放资源并关闭连接。
总结起来，RTSP协议是一种用于控制媒体流传输的应用层协议。
它使用文本消息格式，在客户端和服务器之间建立控制信道，并通过方法来实现会话管理和媒体流的控制。
RTSP协议具有可扩展性和灵活性，可以与其他协议结合使用，适用于不同的应用场景。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
E-mail：**************译者：Bryan.Wong（王晶，宁夏固原）译文版本：alpha 0.80译文发布时间：2007-7-25版权：本中文翻译文档之版权归王晶所有。
可于非商业用途前提下自由转载，但必须保留此翻译及版权信息。
/filedownload?user=bryanj&id=611206网络工作组 H. Schulzrinne请求注释: 2326 哥伦比亚大学.类别: 标准跟踪 A. RaoNetscapeR. LanphierRealNetworks1998年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 URL3.3 会议标识3.4 会话标识3.5 SMPTE 相对时间戳3.6正常播放时间3.7 绝对时间3.8 选项标签3.8.1 用IANA注册新的选项标签*4 RTSP消息4.1 消息类型4.2 消息头4.3 消息主体4.4 消息长度*5 普通头部段*6 请求6.1 请求行6.2 请求消息头段*7 响应7.1 状态行7.1.1 状态码和原因短语7.1.2 响应头部段*8 实体8.1 实体头部域8.2 实体主体24*9 连接9.1 流水线化259.2 可靠性及确认25 *10 方法定义25 10.1 可选项26 10.2 描述2610.3 通知2610.4 建立2610.5 播放2710.6 暂停2710.7 断开2710.8 获取参数2810.9 设置参数2810.10 重定向2810.11 录制2910.12 嵌入（交织）的二进制数据29 *11状态码定义2911.1成功2xx 3011.1.1 存储空间低250 3011.2 重定向3xx 3111.3 客户端错误4xx 3111.3.1方法不允许3211.3.2无法理解参数3211.3.3会议未找到3311.3.4 带宽不足3311.3.5 会话未找到3411.3.6 本状态下该方法无效3411.3.7 头部域与资源不匹配3411.3.8 无效范围3511.3.9 参数为只读3511.3.10 不允许合操作3611.3.11 只允许合操作3611.3.12 不支持的传输3611.3.13 目标不可达3711.3.14 不支持的选项3712 头部段定义（Header Field Definitions）38 12.1 接受3812.2 接受-编码3812.3 接受-语言3912.4 允许（Allow）3912.5 授权（Authorization）4012.6 带宽4012.7 块大小 4012.8 缓存控制4112.9 会议4112.10 连接4112.11 内容-基础4212.12 内容-编码（Content-Encoding）4212.13 内容-语言4312.14 内容-长度（Content-Length）4312.15 内容-位置4312.16 内容-类型（Content-Type）4412.17 命令序列题头（CSeq）4412.18 日期（Date）4412.19 过期（Expires）4512.20 来自（From）4512.21 主机4512.22 如果匹配4512.23如果-被修改-自从（If-Modified-Since）4612.24 最后修改（Last-Modified）4612.25 位置（Location）4612.26 代理认证4712.27 代理要求4712.28 公布 4712.29 范围4912.30 提交方（Referer）4912.31 稍后重试4912.32 要求4912.33 RTP信息4912.34 倍速（Scale）12.35 速度4912.36 服务器（Server）4912.37 会话4912.38 时间戳4912.39 传输4912.40 不支持4912.41 用户代理（User-Agent）4912.42 变化4912.43 通过4912.44 WWW-认证（WWW-Authenticate）50 *13 缓存50*14 例子5014.1 按需点播（单播）5014.2 容器文件的流化5114.3 单个流容器文件5114.4 实况媒体表示的组播5114.5 在存在的会话中播放媒体5114.6 录制52*15 语法5215.1 基本语法5216 安全考虑（Security Considerations）52 *附录A RTSP协议状态机53*A.1 客户端状态机53*A.2 服务器端状态机53*附录B 与RTP协议的交互53*附录C 使用SDP进行RTSP会话描述54 +C.1 定义54o C.1.1 控制URL 55o C.1.2 媒体流55o C.1.3 有效载荷类型55o C.1.4 详细格式参数55o C.1.5 表示的范围56o C.1.6 有效时间56o C.1.7 连接信息56o C.1.8 实体标签57+C.2 合控制不可用57+C.3 合控制可用57*附录D 最小RTSP实现58+D.1 客户端58D.1.1基本回放58D.1.2 认证enabled 58+D.2 服务器59D.2.1基本回放 59D.2.2认证enabled 59*附录E 作者地址60*附录F 致谢60*参考书目60*版权申明611 介绍1.1 目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体，比如音频或视频。
尽管在连续媒体流中有可能插入控制流（见10.12节），但RTSP本身通常并不发送连续媒体流。
换言之，RTSP充当多媒体服务器的"网络遥控器"。
表示描述定义了流的控制操作的集合，但本文并没有规定表示描述的格式。
RTSP没有"连接"这个概念，而由RTSP会话(session)代替（服务器端保持一个由识别符标记的会话）。
RTSP会话没有绑定传输层连接（如TCP连接）。
在RTSP会话期间，RTSP客户端可以打开或关闭多个到服务器端的可靠传输连接以发出RTSP请求。
但也可以使用无连接传输协议，比如UDP，来发送RTSP请求。
RTSP所控制的流可能用到RTP，但RTSP的操作并不依赖用来传送连续媒体的传输机制。
实时流协议在语法和操作上有意地类似于HTTP/1.1，使得HTTP的扩展机制大都可加入RTSP。
尽管如此，RTSP在很多重要方面与HTTP有所不同：*RTSP引入了很多新方法并且有不同的协议标识符。
*RTSP服务器在绝大多数默认情况下需要维持状态，而HTTP是无状态协议。
*RTSP客户机和服务器都可以发出请求。
*数据由信带外的另一个协议传送（但有一个特例）。
*RTSP使用ISO 10646(UTF-8) 而不是ISO 8859-1，以配合当前HTML的国际化。
*RTSP的URI请求时总是包含绝对URI。
而由于历史原因造成的后向兼容性问题，HTTP/1.1只在请求中包含绝对路径，把主机名放入单独的头部域中。
当只有一个IP的主机要提供多个文档树时，可使"虚拟主机"的实现更简单。
协议支持以下操作：从媒体服务器上获得媒体：用户可通过HTTP或其它途径请求一个表示描述。
如果该表示是组播，表示描述就包含用于该连续媒体的的多播地址和端口。
如表示仅通过单播发送给用户，用户为了安全应起见要提供目的地址。
邀请媒体服务器进入会议：媒体服务器可被"邀请"加入已存在的的会议，包括向该表示内回放媒体，或记录此表示中的一部分或全部媒体。
这种模式在分布式教学应用上很有用。
会议中的各方可轮流"按网络遥控器的按钮"。
将媒体加到已存在的表示中：现场表示的专用概念。
当服务器可以告诉客户端"可以附加媒体"时有用。
和HTTP/1.1类似，RTSP的请求可由代理、通道与缓存处理。
1.2 要求在本文档中的关键字"必须"，"必须不"、"需要"、"必须"、"必须不"、"应该"、"不应该"、"推荐"、"可能"、和"可选的"，都和RFC2119 [4]中的解释一致。
1.3 术语一些HTTP/1.1的术语被采用。
这里没有举出的术语，其定义与HTTP/1.1相同。
合控制：服务器使用一条时间线对多个流进行控制。
对音频/视频的回放来讲，这意味着客户端仅需发送一条播放或者暂停消息就可同时控制音频和视频的回放。
会议：多方参与的多媒体表示，这里的多方意味着大于或等于一方。
客户端：指请求媒体服务器上连续流媒体数据的客户端。
连接：以通讯为目的，在传输层建立的两个程序间的虚拟信道。
容器文件：可以容纳多个媒体流的文件，而这些媒体流共同播放时通常还包含一个表示。
RTSP服务器可以为这些容器文件提供合控制，但容器文件的概念本身并不包含在本协议中。
连续媒体：接受器和数据源之间存在时序关系的数据。
也就是说，接受器需要重放原来存在于源数据中的时序关系。
最普通的连续媒体的例子是音频和动画视频。
连续媒体可以是实时的（交互的），它们在源和接受器之间是一种紧密的时序关系；或者是流（回放）的形式，时序关系没那么严格。
实体：请求或者响应的载荷部分中所传输的信息。
实体由信息元组成，而每个信息元由由实体头部域和实体主体组成。
实体头部域内是信息格式，实体主体内是信息内容，如第8章所述。
媒体初始化：数据类型/编码的具体初始化。
这包括时钟频率，颜色空间等。
客户端请求一个媒体流回放时所需的任何独立于传输的信息，都是在流创建时媒体初始化阶段产生的。
媒体参数:对于某种特定的媒体类型来说，回放前或者回放中有可能会发生改变的一些参数。