实时视频传输和控制协议v2.docx
《实时视频传输和控制协议v2.docx》由会员分享，可在线阅读，更多相关《实时视频传输和控制协议v2.docx（8页珍藏版）》请在冰豆网上搜索。
实时视频传输和控制协议v2
实时视频传输和控制协议_v2
全球眼
实时视频传输和控制协议v2
修改历史
日期
修改人姓名
注释
2006-06-23
朴希闯
创建
2006-08-07
朴希闯
添加说明节
重新排版
复审人
日期
部门
姓名和职务
一、说明
这份协议描述了视频服务器与流媒体分发服务器、视频服务器与企业客户端之间传输实时视频的方法。
文档中没有针对媒体分发服务器与企业客户端（第三方播放器）之间的通信方法，但是媒体分发服务器与企业客户端（第三方播放器）之间的通信方法尊守RTC1889和RPC2326定义的规范。
在这篇文档里我们把象视频服务器这样能够给观看者提供视频数据的设备称为逻辑上的服务端角色（也就是视频源），象企业客户端这样播放视频的终端设备称为逻辑上的客户端角色（也就是接收者或观看者）。
流媒体分发服务器同时具有两种角色。
交互流程中列出了两种模式，我们当前要先实现接模式。
推模式是为了视频服务器在私网环境时也可以通过流媒体发服务器向用户提供视频服务。
推模式暂不实现。
协议中没有提及RTCP协议，但并不影响视频通信质量，而且目前很难实现有效的编解码之间返馈的处理方法，所以现在，以及将来的一段时间都不会考虑RTCP协议，除非出现有效的视频质量控制机制。
本文参考RFC1889、1890、2326、3550完成，如有不符合标准的、或者不完善的陈述，请提出来，发电子邮件到piaoxichuang@。
如果您有更好的想法也可以通过邮件进行交流。
二、协议
通信方式使用RTPoverTCP方式。
（RTC1889、RFC2326）
1、一个完整的包
网络字节顺序
2、RTP包的封装（RTPoverTCP）
网络字节顺序
ChannelIdentifier：
取值0。
因为只有一个流在一个TCP连接中传递，同时不使用RTCP协议。
参见RFC2326[10.12]节。
Lenth：
取值为RTP包的大小，包括RTP头部，但不包含本身的4个字节，以BYTE为单位。
3、RTP12字节头部
网络字节顺序
V：
版本，取值2。
[可能会使用0值，还没想清
MD32（X）=Y[1]^Y[2]^Y[3]^Y[4]
注：
RTP包大小最大值为2048。
（因为DSS支持的最大包为2048Bytes）
4、RTP扩展头
网络字节顺序
T：
扩展头标志，取值0或1。
PacketType：
负载类型。
取值见下表：
T
PacketType
说明
0
1
连接请求
2
连接请求应答
3
视频头部
1
1
I帧
2
音频帧
3
非I帧
Length：
扩展头长度，取值0。
其中1=4Bytes，不包括当前列出的32Bits数据。
参见RFC3550[5.3.1]节。
1、Playload的格式
扩展头部定义的Playload类型：
T=0，PacketType=1
XML格式，定义如下
S
T=0，PacketType=2
XML格式，定义如下
N
T=0，PacketType=3
二进制的原始视频头部数据
T=1，PacketType=1
二进制的原始视频数据
T=1，PacketType=2
二进制的原始音频数据
T=1，PacketType=3
二进制的原始视频数据
注：
Naming是摄像头的全局唯一标识符，用与平台与联，目前的视频服务器协议可以忽略这个属性。
三、交互流程
在全球眼系统中，对于实时视频传输控制协议扮演服务器角色的是前端视频服务器，扮演客户端角色的有企业客户端、流分发服务器、显示服务器、WEB客户端。
下面以前端视频服务器与流分发服务器为例说明实时视频传输控制协议的交互流程。
1、拉模式
第一步：
流分发服务器（客户端角色）发起到前端视频服务器（服务器角色）的TCP连接请求，前端视频服务器接受这个连接。
完成TCP连接的建立。
第二步：
流分发服务器发送连接请求数据报到前端视频服务器。
（扩展头部T字段为0，PacketType为1）
第三步：
前端视频服务器验证请求，如果请求有效，则回应给流分发服务器连请求应答（扩展头部T字段为0，PacketType为2）数据报；如果请求无效，则回应给流分发服务器一个请求有错的连接请求应答（扩展头部T字段为0，PacketType为2）数据报，并关闭TCP连接，前端视频服务器（服务器角色）算法结束。
第四步：
流分发服务器如果接收到一个正确的连接请求应答，则进入第五步；否则如果接收到错误的连接请求应答（或者说没有接收到连接请求应答），则关闭TCP连接，流分发服务器（客户端角色）算法结束。
第五步：
前端视频服务器向流分发服务器发送视频头部（扩展头部T字段为0，PacketType为3）数据报。
第六步：
前端视频服务器根据编码器产生的实时音视频数据向流分发服务器发送视频数据报（扩展头部T字段为1，PacketType为1，2，3）。
第七步：
前端视频服务器重复第六步，直到TCP连接断开，前端视频服务器算法结束。
第八步：
流分发服务器持续接收前端视频服务器在第六步、第七步发送的视频数据报。
第九步：
流分发服务器不再需要视频流数据时（停止观看），流分发服务器关闭TCP连接，流分发服务器（客户端角色）算法结束。
2、推模式
算法与拉模式相似，只在第一步、第二步、第三步算法中把服务器角色和客户端角色对换。
算法描述如下：
第一步：
前端视频服务器（服务器角色）发起到流分发服务器（客户端角色）的TCP连接请求，流分发服务器接受这个连接。
完成TCP连接的建立。
第二步：
流分发服务器发送连接请求数据报到流分发服务器。
（扩展头部T字段为0，PacketType为1）
第三步：
流分发服务器验证请求，如果请求有效，则回应给前端视频服务器连请求应答（扩展头部T字段为0，PacketType为2）数据报；如果请求无效，则回应给前端视频服务器一个请求有错的连接请求应答（扩展头部T字段为0，PacketType为2）数据报，并关闭TCP连接，流分发服务器（客户端角色）算法结束。
第四步：
前端视频服务器如果接收到一个正确的连接请求应答，则进入第五步；否则如果接收到错误的连接请求应答（或者说没有接收到连接请求应答），则关闭TCP连接，前端视频服务器（服务器角色）算法结束。
第五步：
前端视频服务器向流分发服务器发送视频头部（扩展头部T字段为0，PacketType为3）数据报。
第六步：
前端视频服务器根据编码器产生的实时音视频数据向流分发服务器发送视频数据报（扩展头部T字段为1，PacketType为1，2，3）。
第七步：
前端视频服务器重复第六步，直到TCP连接断开，前端视频服务器算法结束。
第八步：
流分发服务器持续接收前端视频服务器在第六步、第七步发送的视频数据报。
第九步：
流分发服务器不再需要视频流数据时（停止观看），流分发服务器关闭TCP连接，流分发服务器（客户端角色）算法结束。
四、兼容性
视频服务器作为服务端角色，应该实现对原来版本实时视频传输协议的兼容机制。
这篇文档中不会规定实现新旧版本的兼容机制或算法。
最终实现者可以考虑基于数据包头部来区分版本。
五、传输控制
1、服务器角色
●服务器角色在发送数据时必须保证视频帧的完整性
●服务器角色必须支持一个时间阀值，以保证由服务器解色在传输上引入的时延小于该阀值。
●服务器应该统计传输的丢帧率，并在到达一个预定义的阀值时放弃该传输。
2、客户端角色
升级会员 