《实时传输.docx》由会员分享，可在线阅读，更多相关《实时传输.docx（6页珍藏版）》请在三一办公上搜索。
1、实时传输实时传输 1、 RTP的包头 M标志位：标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界。 由于一个视频采样压缩之后仍然有可能相当巨大，可能超出预先约定规定的RTP数据报大小，这个时候就需要拆分数据报了。但是由于这些数据报都属于同一个整个视频采样，因此这些数据报的时间戳应该是一致的。此外，Mark标志用来作为区分这些拆分数据报和普通数据报的分界线。只有当受到Mark标志的多个数据报都到达了才能构成一个完整的数据帧提交解码器。 SSRC：同步源标识。 序列号：每发送一个RTP数据包，序列号加1，接收端可以据此检测丢包和重建包序列。 CSRC：只有当混频器加入时才有此
2、项。可不考虑。 设置恰当的时戳单元：这是RTP会话初始化过程所要进行的另外一项重要工作，这是通过调用RTPSession类的SetTimestampUnit 方法来实现的，该方法同样也只有一个参数，表示的是以秒为单元的时戳单元。例如，当使用RTP会话传输8000Hz采样的音频数据时，由于时戳每秒钟将递增8000，所以时戳单元相应地应该被设置成1/8000，可以用以下代码来实现Sessionparams.SetOwnTimestampUnit(1.0/8000)。30帧/秒的视频SetOwnTimestampUnit(1.0 /30)；如果RTP包是周期性产生的，那么将使用由采样时钟决定的名义上
3、的采样时刻，而不是读取系统时间。例如，对一个固定速率的音频，采样时钟将在每个周期内增加1。如果一个音频从输入设备中读取含有160个采样周期的块，那么对每个块，时间戳的值增加160。也就是时间戳增量如上8000Hz的音频，如果每个包含有20ms的时间，则需要session.SetDefaultTimestampIncrement(160)。 另外不同媒体流的RTP时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此，虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体，我们把与采样时刻相关联的RTP时间戳与来自于参考时钟上的时间戳相关联。因此
4、参考时钟的时间戳就了数据的采样时间。参考时钟用于同步所有媒体的共同时间。这一时间戳对，用于判断RTP时间戳和NTP时间戳的对应关系，以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的RTCP的SR中。 RTP中时间戳的作用： l 调整语序 时间戳字段是RTP首部中说明数据包时间的同步信息，是数据能以正确的时间顺序恢复的关键。时间戳的值给出了分组中数据的第一个字节的采样时间(Sampling Instant)，要求发送方时间戳的时钟是连续、单调增长的，即使在没有数据输入或发送数据时也是如此。在静默时，发送方不必发送数据，保持时间戳的增长，在接收端，由于接收到的数据分组的序号
5、没有丢失，就知道没有发生数据丢失，而且只要比较前后分组的时间戳的差异，就可以确定输出的时间间隔。 RTP规定一次会话的初始时间戳必须随机选择，但协议没有规定时间戳的单位，也没有规定该值的精确解释，而是由负载类型来确定时钟的颗粒，这样各种应用类型可以根据需要选择合适的输出计时精度。 在RTP传输音频数据时，一般选定逻辑时间戳速率与采样速率相同，但是在传输视频数据时，必须使时间戳速率大于每帧的一个滴答。如果数据是在同一时刻采样的，协议标准还允许多个分组具有相同的时间戳值。 l 控制媒体数据发送速度 由于RTP协议没有规定RTP分组的长度和发送数据的速度，因而需要根据具体情况调整服务器端发送媒体数据
6、的速度。对来自设备的实时数据可以采取等时间间隔访问设备缓冲区，在有新数据输入时发送数据的方式，时间戳的设置相对容易。对已经录制好的本地硬盘上的媒体文件，以H.263格式的文件为例，由于文件本身不包含帧率信息，所以需要知道录制时的帧率或者设置一个初始值，在发送数据的时候找出发送数据中的帧数目，根据帧率和预置值来计算时延，以适当的速度发送数据并设置时间戳信息。 l 调整多种流同步 RTCP的一个关键作用就是能让接收方同步多个RTP流，例如：当音频与视频一起传输的时候，由于编码的不同，RTP使用两个流分别进行传输，这样两个流的时间戳以不同的速率运行，接收方必须同步两个流，以保证声音与影像的一致。为能
7、进行流同步，RTCP要求发送方给每个传送一个唯一的标识数据源的规范名(Canonical Name），尽管由一个数据源发出的不同的流具有不同的同步源标识(SSRC)，但具有相同的规范名，这样接收方就知道哪些流是有关联的。而发送方报告报文所包含的信息可被接收方用于协调两个流中的时间戳值。发送方报告中含有一个以网络时间协议NTP(Network Time Protocol)格式表示的绝对时间值，接着RTCP报告中给出一个RTP时间戳值，产生该值的时钟就是产生RTP分组中的TimeStamp字段的那个时钟。由于发送方发出的所有流和发送方报告都使用同一个绝对时钟，接收方就可以比较来自同一数据源的两个流
8、的绝对时间，从而确定如何将一个流中的时间戳值映射为另一个流中的时间戳值。 RTP时戳设置为内容的采样时戳。必须使用90 kHz 时钟频率。如果NAL单元没有他自己的时间属性(即,parameter set and SEI NAL units),RTP时戳设置成访问单元主编码图像的RTP时戳。 负载格式: 对于负载格式规范文件，定义了特定类型的负载，比如用H.264压缩的视频文件如何用RTP包来传送。需要参考RFC 3984协议在这个文件中，下列选项可能会被重新定义： n RTP data header n Payload types n RTP data header additions n
9、RTP data header extensions n RTCP packet types n RTCP report interval n SR/RR extension n SDES use n Security n String-to-key mapping n Underlying protocol n Transport mapping n Encapsulation 可以通过RTPPacket类和RTCPPacket类进行这些修改。 为了通过RTP进行H.264视频传输，需要把H.264视频数据根据规范封装成数据包。根据RTP封装规范，我们采用简单的打包方案，即将每个NALU单独
10、封装成一个RTP包。发送端按照RTP数据包的格式放入数据，并且配置RTP包头的负载类型、序列号、时间戳等参数。形成一个完整的RTP数据包。通过网络发送给接收端。实现端到端的视频流传输。接收端收到RTP包以后，取出包里的NAL单元送给解码器进行解码播放。 RFC3984中的规范：单个NAL单元包 单个NAL单元包: 荷载中只包含一个NAL单元。NAL头类型域等于原始 NAL单元类型,即在范围1到23之间。分片单元: 用于分片单个NAL单元到多个RTP包。现存两个版本FU-A，FU-B,用NAL单元类型 28，29标识。 其中NAL单元字节头格式： 分片单元 (FUs)：本荷载类型允许分片一个NA
11、L单元到几个RTP包中。分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成. 每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似, NAL单元必须按照RTP顺序号的顺序装配。当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs,MTAP不可以被分片。 FUs不可以嵌套。即, 一个FU 不可以包含另一个FU。 JM输出的RTP格式的库文件结构如下表 长度(LEN）是除去前8个字节的长度。TS1是JM编码的时候设
12、置的，在实际传输数据的时候这个字段没有用到。随后的12个字节是一个标准的RTP头部。特别要说明的是，H.264的负载类型(PT. payloadtype)是一个确定的值为0x69(105)。SSRC的值被设置为0x12345678。 2、 RTCP的包格式 以下是RTCP包的5种类型： n SR: Sender report 会话中频繁发送包的参与者的报告 n RR: Receiver report 非频繁发包的参与者发送的接受方统计数据 n SDES: Source description items 发送源描述项，包括CNAME信息 n BYE: 终止参与会议信息的包 n APP: 用于特
13、定进程的包 3、 另外一个需要注意的地主是RTP包的大小，库默认是1400b。 4、MTU size最大传输单元大小：指在传输层和网络层无需被分割/重组的数据包 的最大长度。通常建议编码后的图像片的大小与之接近，但不可大于它。原因有二，一是最优化净荷与头部的开销关系，二是使得丢包率尽可能的小。 如果数据包的长度超过了MTU，那么网络层就要对数据包进行分割(fragmentation)操作，使每一片的长度都小于或等于MTU。如果其中某一片在传输层被丢失，那么数据包其他片就会被网络层/传输层的协议所丢弃。 在有线的IP连接中一般定义MTU的大小在1500字节左右。在无线网络环境中，其值往往要小的多。在JVT的关于无线环境的研究中定义其大小为100字节左右。 简单打包，实际上，VCL为了避免IP层的再分割，已经限制了NAL单元的大小不大于MTU的大小。 NAL单元分割 在编码时，往往会遇到这样的情况，编码器不能按照当前网络的MTU的大小要求来编码，许多NAL单元的大小大于MTU。所以，应用层的分割方案是RTP打包机制的一个必要部分。 分片： 回调 OnCapture采集压缩打包发送 显示解压重组包接收
