实时视频传输和控制协议v2

《实时视频传输和控制协议v2》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、全球眼实时视频传输和控制协议v2修改历史日期修改人姓名注释2006-06-23朴希闯创建2006-08-07朴希闯添加说明节重新排版复审人日期部门姓名和职务一、说明这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就

2、是接收者或观看者）。流媒体分发服务器同时具有两种角色。交互流程中列出了两种模式，我们当前要先实现接模式。推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。推模式暂不实现。协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。本文参考RFC1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@megaeyes.com。如果您有更好的想法也可以通过邮件进行交流。二、协

3、议通信方式使用RTPoverTCP方式。（RTC1889、RFC2326）1、一个完整的包网络字节顺序2、RTP包的封装（RTPoverTCP）网络字节顺序ChannelIdentifier：取值0。因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。参见RFC2326[10.12]节。Lenth：取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。3、RTP12字节头部网络字节顺序V：版本，取值2。[可能会使用0值，还没想清楚，可能的使用情况是为了实现防火墙穿透]P：附加数据，取值为0。X：扩展头，取值为1。CC：CSRC列表数量，取值为0。M：记号，

4、取值0或1。关于M字段的取值：如果扩展头中T字段为1，则当一个包（RTPPacket）是一个帧（Sample）的最后一个包时取值1，否则取值0；扩展头中T字段为1时，由于指令长度较小，一个RTP就可以传输完成，所以取值为1。除非要使用多个RTP包传输，最后一个RTP包取值为1，前面的包取值为0。PT：负载类型，动态，取值96。参见RFC1890[7]节。SequenceNumber：RTP包的序号，初始值是随机的，不是0。Timestamp：以视频编码算法提供者的需要填写或单调增长的时间戳。[将来可能把这个值也传递给视频解码算法中去。]SSRC：随机数，用于在同一个会话中区分不同的流。建议使

5、用MD32。UINTY[4]IfY=MD5(X)ThenMD32(X)=Y[1]^Y[2]^Y[3]^Y[4]注：RTP包大小最大值为2048。（因为DSS支持的最大包为2048Bytes）4、RTP扩展头网络字节顺序T：扩展头标志，取值0或1。PacketType：负载类型。取值见下表：TPacketType说明01连接请求2连接请求应答3视频头部11I帧2音频帧3非I帧Length：扩展头长度，取值0。其中1=4Bytes，不包括当前列出的32Bits数据。参见RFC3550[5.3.1]节。1、Playload的格式扩展头部定义的Playload类型：T=0，PacketType=1X

6、ML格式，定义如下ST=0，PacketType=2XML格式，定义如下NT=0，PacketType=3二进制的原始视频头部数据T=1，PacketType=1二进制的原始视频数据T=1，PacketType=2二进制的原始音频数据T=1，PacketType=3二进制的原始视频数据注：Naming是摄像头的全局唯一标识符，用与平台与联，目前的视频服务器协议可以忽略这个属性。三、交互流程

7、在全球眼系统中，对于实时视频传输控制协议扮演服务器角色的是前端视频服务器，扮演客户端角色的有企业客户端、流分发服务器、显示服务器、WEB客户端。下面以前端视频服务器与流分发服务器为例说明实时视频传输控制协议的交互流程。1、拉模式第一步：流分发服务器（客户端角色）发起到前端视频服务器（服务器角色）的TCP连接请求，前端视频服务器接受这个连接。完成TCP连接的建立。第二步：流分发服务器发送连接请求数据报到前端视频