注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

dp: 生活的脚步,进步的点滴...

Cam、DSP、FPGA、PM、Life、More ...

 
 
 

日志

 
 

H264 NALU RTP  

2012-06-19 18:08:45|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
对h.264压缩视频码流中i帧的提取(firstime)
2010-06-30 09:15
 
这 个问题要说清楚还是有点复杂:首先判断 NALU 类型是否是 5,如果是,那么以后连续出现的 NALU 类型为 5 的 NALU 就属于 IDR 帧(一种特殊的 I 帧);如果 NALU 不是 5,则要进一步判断 slice_type 是否是 7,如果是,那么连续出现的 slice_type = 7 的 slice 就属于 I 帧;如果 slice_type = 2,那么就要判断与当前 slice 同属一帧的 slice 是否都是 I slice,如果都是,那么这些 slice 就属于一个 I 帧。当然这必须是在码流没有错误的情况下才可行。

实际应用中,码流中一般不会出现复杂的情况,所以可以直接判断 slice_type   是否等于 2 或 7 就可以了。




H.264的NALU,RTP封包说明(转自牛人)
2010-06-30 16:28

H.264 RTP payload 格式


H.264 视频 RTP 负载格式

1. 网络抽象层单元类型 (NALU)

NALU 头由一个字节组成, 它的语法如下:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

F: 1 个比特.
forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.

NRI: 2 个比特.
nal_ref_idc. 取 00 ~ 11, 似乎指示这个 NALU 的重要性, 如 00 的 NALU 解码器可以丢弃它而不影响图像的回放. 不过一般情况下不太关心

这个属性.

Type: 5 个比特.
nal_unit_type. 这个 NALU 单元的类型. 简述如下:

0     没有定义
1-23 NAL单元 单个 NAL 单元包.
24    STAP-A   单一时间的组合包
25    STAP-B   单一时间的组合包
26    MTAP16   多个时间的组合包
27    MTAP24   多个时间的组合包
28    FU-A     分片的单元
29    FU-B     分片的单元
30-31 没有定义

2. 打包模式

下面是 RFC 3550 中规定的 RTP 头的结构.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X| CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers             |
      |                             ....                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

负载类型 Payload type (PT): 7 bits
序列号 Sequence number (SN): 16 bits
时间戳 Timestamp: 32 bits

H.264 Payload 格式定义了三种不同的基本的负载(Payload)结构. 接收端可能通过 RTP Payload
的第一个字节来识别它们. 这一个字节类似 NALU 头的格式, 而这个头结构的 NAL 单元类型字段
则指出了代表的是哪一种结构,

这个字节的结构如下, 可以看出它和 H.264 的 NALU 头结构是一样的.
      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+
字段 Type: 这个 RTP payload 中 NAL 单元的类型. 这个字段和 H.264 中类型字段的区别是, 当 type
的值为 24 ~ 31 表示这是一个特别格式的 NAL 单元, 而 H.264 中, 只取 1~23 是有效的值.
  
24    STAP-A   单一时间的组合包
25    STAP-B   单一时间的组合包
26    MTAP16   多个时间的组合包
27    MTAP24   多个时间的组合包
28    FU-A     分片的单元
29    FU-B     分片的单元
30-31 没有定义

可能的结构类型分别有:

1. 单一 NAL 单元模式
     即一个 RTP 包仅由一个完整的 NALU 组成. 这种情况下 RTP NAL 头类型字段和原始的 H.264的
NALU 头类型字段是一样的.

2. 组合封包模式
    即可能是由多个 NAL 单元组成一个 RTP 包. 分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24.
那么这里的类型值分别是 24, 25, 26 以及 27.

3. 分片封包模式
    用于把一个 NALU 单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29.

2.1 单一 NAL 单元模式

对于 NALU 的长度小于 MTU 大小的包, 一般采用单一 NAL 单元模式.
对于一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个

NALU 单元的开始, 必须是 "00 00 00 01" 或 "00 00 01", NALU 头仅一个字节, 其后都是 NALU 单元内容.
打包时去除 "00 00 01" 或 "00 00 00 01" 的开始码, 把其他数据封包的 RTP 包即可.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|NRI| type   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |               Bytes 2..n of a Single NAL unit                 |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


如有一个 H.264 的 NALU 是这样的:

[00 00 00 01 67 42 A0 1E 23 56 0E 2F ... ]

这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.

封装成 RTP 包将如下:

[ RTP Header ] [ 67 42 A0 1E 23 56 0E 2F ]

即只要去掉 4 个字节的开始码就可以了.


2.2 组合封包模式

其次, 当 NALU 的长度特别小时, 可以把几个 NALU 单元封在一个 RTP 包中.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RTP Header                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |STAP-A NAL HDR |         NALU 1 Size           | NALU 1 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 1 Data                           |
      :                                                               :
      +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               | NALU 2 Size                   | NALU 2 HDR    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         NALU 2 Data                           |
      :                                                               :
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.3 Fragmentation Units (FUs).

而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为 Fragmentation Units (FUs).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | FU indicator |   FU header   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 14. RTP payload format for FU-A

   The FU indicator octet has the following format:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI| Type   |
      +---------------+

   The FU header has the following format:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |S|E|R| Type   |
      +---------------+


3. SDP 参数

下面描述了如何在 SDP 中表示一个 H.264 流:

. "m=" 行中的媒体名必须是 "video"
. "a=rtpmap" 行中的编码名称必须是 "H264".
. "a=rtpmap" 行中的时钟频率必须是 90000.
. 其他参数都包括在 "a=fmtp" 行中.

如:

m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

下面介绍一些常用的参数.

3.1 packetization-mode:
表示支持的封包模式.
当 packetization-mode 的值为 0 时或不存在时, 必须使用单一 NALU 单元模式.
当 packetization-mode 的值为 1 时必须使用非交错(non-interleaved)封包模式.
当 packetization-mode 的值为 2 时必须使用交错(interleaved)封包模式.
这个参数不可以取其他的值.

3.2 sprop-parameter-sets:
这个参数可以用于传输 H.264 的序列参数集和图像参数 NAL 单元. 这个参数的值采用 Base64 进行编码. 不同的参数集间用","号隔开.

3.3 profile-level-id:
这个参数用于指示 H.264 流的 profile 类型和级别. 由 Base16(十六进制) 表示的 3 个字节. 第一个字节表示 H.264 的 Profile 类型, 第

三个字节表示 H.264 的 Profile 级别:

3.4 max-mbps:
这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.

 



【转】
 H264关于RTP协议的实现
2010-07-22 13:35

        完整的C/S架构的基于RTP/RTCP的H.264视频传输方案。此方案中,在服务器端和客户端分别进行了功能模块设计 。服务器端 :RTP封装模块主要是对H.264码流进行打包封装;RTCP分析模块负责产牛和发送RTCP包并分析接收到的RTCP包;QoS反馈控制模块则根据RR报文反馈信息动态的对发送速率进行调整;发送缓冲模块则设置端口发送RTP、RTCP包。客户端 :RTP模块对接收到的RTP包进行解析判断;RTCP模块根据SR报文统计关键信息,产牛并发送RR包。然后,在VC++6.0下用Socket编程,完成基于RTP/UDP/IP的H.264视频传输,并在局域网内运行较好。

基于RTP/UDP/lP的H.264视频传输结构设计

        对于H.264视频的实时传输应用来说,TCP的重传机制引入的时延和抖动是无法容忍的,因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的,不能提供质量保证。而基于UDP之上的高层协议RTP/RTCP可以一起提供流量控制和拥塞控制 服务。图给出了基于RTP/UDP/IP的H.264视频传输的框架。

  

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 


H.264视频流的RTP封装策略

        从图4—1可以看出,H.264视频数据首先经RTP进行封装 ,打包成适合网络传输的数据包才能进行传输。所以,如何设计合适的RTP封装策略对H.264视频数据进行封装是十分重要的。一般来说,在H.264中,RTP封装应该遵循几个设计原则:
1、较低的开销,因此MTU的尺寸应该限制在100—64K字节范围内。
2、易于区分分组的重要性,而不必对分组内的数据解码。
3、应能检测到数据的类型,而不需解码整个数据流,并能根据编码流之间的相关性丢弃无用数据,如网关应能检测A型分割的丢失,并能丢弃相应的B型和C型分割。

4、应支持将一个NALU拆分为若干个RTP包:不同大小的输入图片决定了NALU的长度可能会大于MTU,只有拆分后才会避免IP层在传输时出现分片。
5、支持将多个NALU汇集在一个RTP分组中,即在一个RTP包中传输超过一个NALU,当多个图片的编码输出小于M1IU时就考虑此模式,以提高网络传输效率。

RTP载荷封装设计

         本文的网络传输是基于IP协议,所以最大传输单元(MTU )最大为1500字节,在使用IP/UDP/RTP的协议层次结构的时候,这其中包括至少20字节的IP头 ,8字节的UDP头 ,以及12字节的RTP头 。这样,头信息至少要占用40个字节,那么RTP载荷的最大尺寸为1460字节。

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 

          一方面,如果每个IP分组都填满1500字节,那么协议头的开销为2.7%,如果RTP载荷的长度为730字节,协议头的开销仍达到5.3%,而假设 RTP载荷的长度不到40字节,那么将有50%的开销用于头部,这将对网络造成严重资源浪费。另一方面,如果将要封装进RTP载荷的数据大于1460字 节,并且我们没有在应用层数据装载迸RTP包之前进行载荷分割 ,将会产生大于MTU的包。在IP层其将会被分割成几个小于MTU尺寸的包 , 这样将会无法检测数据是否丢失。因为IP和UDP协议都没有提供分组到达的检测,如果分割后第一个包成功接收而后续的包丢失,由于只有第一个包中包含有完 整的RTP头信息,而RTP头中没有关于载荷长度的标识,因此判断不出该RTP包是否有分割丢失,只能认为完整的接收了。并且在IP层的分割无法在应用层 实现保护从而降低了非平等包含方案的效果。由于UDP数据分组小于64K字节,而且一个片的长度对某些应用场合来说有点太小,所以应用层的打包 也是RTP打包机制的一个必要部分。最新的RFC3984标准中提供了针对H.246媒体流的RTP负载格式,主要有三种:
单个NAL单元分组、聚合分组、片分组。

NAL单元单一打包

将一个NAL单元封装进一个包中,也就是说RTP负载中只包含一个NAL单元,NAL头部兼作RTP头部。RTP头部类型即NAL单元类型1-23,如下图所示:

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 

NAL单元的重组 
此分组类型用于将多个NAL单元聚合在一个RTP分组 中。一些H.264的NAL单元的大小,如SEI NAL单元 、参数集等都非常小,有些只有几个字节,因此应该把它们组合到一个RTP包中,将会有利于减小头标(RTP/UDP/IP)的开销。目前存在着两种类型聚合分组:

NAL单元的分割

将一个NAL单元分割,使用多个RTP分组 进行传输。共有两个类型FU—A和FU—B,单元类型中分别为28和29。根据IP层MTU的大小,对大尺寸的NALU必须要进行分割,可以在分别在两个层次上进行分割:
1)视频编码层VCL上的分割

为了适应网络MTU的尺寸,可以使用编码器来选择编码Slice NALU 的大小,从而使其提供较好的性能。一般是对编码Slice的大小进行调整,使其小于1460字节 ,以免IP层的分割。


2)网络提取层NAL上的分割 
在网络提取层上对NALU的分割主要是采用分片单元方案 ,H.264标准中提出了分割机制,可以使NAL单元的尺寸小于1460字节。注意:此方式是针对同一个NAL单元进行分割的 ,不适用于聚合分组。一个NAL单元采用分割分组后,每个RTP分组序列号依次递增l,RTP时间戳相同且惟一 。NAL单元的分割是RTP打包机制的一个重要环节,总结其分割机制主要有如下几个特点:
①分割NALU时,是以RTP次序号升序进行 传输。在序列号不循环的前提下,属于前一帧图像的所有图像片包以及A/B/C数据分割包的序列号要小于后帧图像中的图像片及数据分割包的序列号。
②一个符号机制来标记一个分割的NALU是第一个还是最后一个NAL单元。
3.存在另外一个符号机制用来检测是否有丢失的分块。
④辅助增强信息包和头信息包可以任意时间发送。
⑤同一帧图像中的图像片可以以任意顺序发送,但是对于低时延要求的网络系统,最好是以他们原始的编码顺序来发送。

 


1)单一时间聚合分组 (STAP):包括单一时间聚合分组A(STAP—A)和单一时间聚合分组B(STAP—B),按时间戳进行组合,他们的NAL单元具有相同的时间戳,一般用于低延迟环境。STAP—ASTAP—B的单元类型分别为24和25。
2)多时间聚合分组 (MTAP):包括16比特偏移多时间聚合分组(MTAPl6)和24比特偏移多时间聚合分组 (MTAP24)不同时间戳也可以组合,一般用于高延迟的网络环境,比如流媒体应用.它的打包方案相对复杂,但是大大增强了基于流媒体的H.264的性 能。MTAPl6 MTAP24的单元类型分别为26和27。

RTP包的封装流程设计

根据H.264NAL单元的分割重组的性质以及RTP打包规则,本文实行的对RTP打包的设计 如下:
1、若接收到的NAL单元小于MAX—SIZE(此时MAX-sIZE为设定的最大传输单元 ),则对它进行单一打包,也就是将此NAL单元直接放进RTP包的载荷部分,生成一个RTP包。
2、若接收到的NAL单元大于MAx—SIZE字节,则对它进行分割,然后对分割后的NAL单元进行步骤1方式打包。分割方案如下:

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 

 

 

其中Nsize是分割前的NAL单元大小 ,N是分割后NAL单元的大小 。K分割后的单元数 。分割后最后一个单元的大小可能会小于N,这时必须使用RTP载荷填充 是其同前面的分块大小相同,此时RTP头中的填充标识位值为 1。

3、对SEI,参数集等小NAL单元重组,将它们合并到一个RTP 包中。虽然步骤3中的重组方案可以减小IP/UDP/RTP头部开销,但是对于包丢失率比较高的网络环境,这意味着一个RTP包的丢失可能会导致多片的丢失,往往一个片中就有一个P图像,解码后的视频质量必然会严重下降。因此,在丢失率的网络中可以采用NAL单元的重组方案 ,而在高丢失率的网络环境中采用NAL单元重组时要进行有效的差错控制.在本文中不使用重组方案。

RTP/RTCP包的封装实现

RTP包封装设计

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 

RTcP包的封装设计

        RTCP报文封装在UDP数据报 中进行传输,发送时使用比它所属的RTP流的端口号大1 的协议号(RTP使用偶数号,RTCP使用奇数号)。以下是RTCP头部数据结构:

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲
 

 

H264实时编码及NALU,RTP传输(续)(ZZ) - 加菲 - 视频会议 - 加菲

  





------------------------------------



H264实时编码及NALU,RTP传输(ZZ)
2010-07-25 11:46

 

H264 视频文件 帧格式 传输封装等 杂碎

rfc3984
Standards Track [Page 2] RFC 3984 RTP Payload Format for H.264 Video February 2005 1.
按照RFC3984协议实现H264视频流媒体

nalu单元 包起始 0x 00 00 00 01

H.264 NAL格式及分析器
http://hi.baidu.com/zsw_davy/b ... c409cc7cd92ace.html 
http://hi.baidu.com/zsw_davy/blo ... 081312c8fc7acc.html 

----------------------------------比特流信息 ----------------------------------------------

①NALU(Network Abstract Layer Unit):两标准中的比特流都是以NAL为单位,每个NAL单元包含一个RBSP,NALU的头信息定义了RBSP所属类型。类型一般包括序列参数集 (SPS)、图像参数集(PPS)、增强信息(SEI)、条带(Slice)等,其中,SPS和PPS属于参数集,两标准采用参数集机制是为了将一些主要 的序列、图像参数(解码图像尺寸、片组数、参考帧数、量化和滤波参数标记等)与其他参数分离,通过解码器先解码出来。此外,为了增强图像的清晰 度,AVS-M添加了图像头(Picture head)信息。读取NALU流程中,每个NALU前有一个起始码0x000001,为防止 内部0x000001序列竞争,H.264编码器在最后一字节前插入一个新的字节——0x03,所以解码器检测到该序列时,需将0x03删掉,而AVS- M只需识别出起始码0x000001。


②读取宏块类型(mb type)和宏块编码模板(cbp):编解码图像以宏块划分,一个宏块由一个16*16亮度块和相应的一个8*8cb和一个8*8cr色度块组成。


(a) 两标准的帧内、帧间预测时宏块的划分是有区别的。H.264中,I_slice亮度块有Intra_4*4和Intra_16*16两种模式,色度块只有 8*8模式;P_slice宏块分为16*16、16*8、8*16、8*8、8*4、4*8、4*4共7种模式。而AVS-M中,I_slice亮度块 有I_4*4和I_Direct两模式,P_slice时宏块的划分和H.264中的划分一致。


(b) 两标准的宏块cbp值计算也不相同。H.264中,Intra_16*16宏块的亮度(色度)cbp直接通过读mb type得到;非Intra_16*16宏块的亮度cbp=coded_block_pattern,色度 cbp=coded_block_pattern/16 。其中,亮度cbp最低4位有效,每位决定对应宏块的残差系数能不能为0;色度cbp为0时,对应残差系数为0,cbp为1时,DC残差系数不为0,AC 系数为0,cbp为2时,DC、AC残差系数都不为0。AVS-M中,当宏块类型不是P_skip时,直接从码流中得到cbp的索引值,并以此索引值查表 得到codenum值,再以codenum查表分别得到帧内/帧间cbp。此cbp为6位,每位代表宏块按8*8划分时能不能包含非零系数,当变换系数不 为0时,需进一步读cbp_4*4中每位值来判断一个8*8块中4个4*4块的系数能不能为0。
---------------------------------------------------------------------------------------------
总的来说H264的码流的打包方式有两种,一种为annex-b byte stream format 的格式,这个是绝大部分编码器的默认输出格式,就是每个帧的开头的3~4个字节是H264的start_code,0x00000001或者0x000001。
另一种是原始的NAL打包格式,就是开始的若干字节(1,2,4字节)是NAL的长度,而不是start_code,此时必须借助某个全局的数据来获得编 码器的profile,level,PPS,SPS等信息才可以解码。
----------------------------------------------------------------------------
AVC vs. H.264
AVC and H.264 are synonymous. The standard is known by the full names "ISO/IEC 14496-10" and "ITU-T Recommendation H.264". In addition, a number of alternate names are used (or have been) in reference to this standard. These include:

  • MPEG-4 part 10
  • MPEG-4 AVC
  • AVC
  • MPEG-4 (in the broadcasting world MPEG4 part 2 is ignored)
  • H.264
  • JVT (Joint Video Team, nowadays rarely used referring to actual spec)
  • H.26L (early drafts went by this name)

All of the above (and those I've missed) include the Annex B byte-stream format . Unlike earlier MPEG1/2/4 and H.26x codecs, the H.264 specification proper does not define a full bit-stream syntax. It describes a number of NAL (Network Abstraction Layer) units, a sequence of which can be decoded into video frames. These NAL units have no boundary markers, and rely on some unspecified format to provide framing.

Annex B of of the document specifies one such format, which wraps NAL units in a format resembling a traditional MPEG video elementary stream, thus making it suitable for use with containers like MPEG PS/TS unable to provide the required framing. Other formats, such as ISO base media based formats, are able to properly separate the NAL units and do not need the Annex B wrapping.

The H.264 spec suffers from a deficiency. It defines several header-type NAL units (SPS and PPS) without specifying how to pack them into the single codec data field available in most containers. Fortunately, most containers seem to have adopted the packing used by the ISO format known as MP4.
1. H.264起始码
   在网络传输h264数据时,一个UDP包就是一个NALU,解码器可以很方便的检测出NAL分界和解码。但是如果编码数据存储为一个文件,原来的解码器将 无法从数据流中分别出每个NAL的起始位置和终止位置,为此h.264用起始码来解决这一问题。

   H.264编码时,在每个NAL前添加起始码 0x000001,解码器在码流中检测到起始码,当前NAL结束。为了防止NAL内部出现0x000001的数据,h.264又提出'防止竞争 emulation prevention"机制,在编码完一个NAL时,如果检测出有连续两个0x00字节,就在后面插入一个0x03。当解码器在NAL内部检测到 0x000003的数据,就把0x03抛弃,恢复原始数据。
0x000000   >>>>>>   0x00000300
0x000001   >>>>>>   0x00000301
0x000002   >>>>>>   0x00000302
0x000003   >>>>>>   0x00000303

附上h.264解码nalu中检测起始码的算法流程  
for(;;)
{
if next 24 bits are 0x000001
{
       startCodeFound = true
       break;
}
else
{
       flush 8 bits  
}
}// for(;;)
if(true == startCodeFound)
{
    //startcode found
    // Flush the start code found
    flush 24 bits  
    //Now navigate up to next start code and put the in between stuff
    // in the nal structure.
    for(;;)
    {
      get next 24 bits & check if it equals to 0x000001
      if(false == (next 24 bits == 000001))
      {
         // search for pattern 0x000000
         check if next 24 bits are 0x000000
         if(false == result)
         {
                // copy the byte into the buffer
                copy one byte to the Nal unit             
         }
         else
         {
                break;
         }
      }
      else
      {
             break;
      }
   }//for(;;)
}

   2. MPEG4起始码
       MPEG4的特色是VOP,没有NALU的概念,仍使用startcode对每帧进行分界。MPEG4的起始码是0x000001. 另外MPEG4中很多起始码也很有用,比如video_object_sequence_start_code 0x000001B0 表示一个视频对象序列的开始,VO_start_code 0x000001B6 表示一个VOP的开始. 0x000001B6之后的两位,是00表示 I frame, 01 表示 P frame, 10 表示 B frame.
1.引言

H.264的主要目标:

1.高的视频压缩比

2.良好的网络亲和性

解决方案:

VCL   video coding layer    视频编码层

NAL   network abstraction layer   网络提取层

VCL:核心算法引擎,块,宏块及片的语法级别的定义

NAL:片级以上的语法级别(如序列参数集和图像参数集),同时支持以下功能:独立片解码,起始码唯一保证,SEI以及流格式编码数据传送

VCL设计目标:尽可能地独立于网络的情况下进行高效的编解码

NAL设计目标:根据不同的网络把数据打包成相应的格式,将VCL产生的比特字符串适配到各种各样的网络和多元环境中。

NALU头结构:NALU类型(5bit)、重要性指示位(2bit)、禁止位(1bit)。

NALU类型:1~12由H.264使用,24~31由H.264以外的应用使用。

重要性指示:标志该NAL单元用于重建时的重要性,值越大,越重要。

禁止位:网络发现NAL单元有比特错误时可设置该比特为1,以便接收方丢掉该单元。

2.NAL语法语义

NAL层句法:

在编码器输出的码流中,数据的基本单元是句法元素。

句法表征句法元素的组织结构。

语义阐述句法元素的具体含义。

分组都有头部,解码器可以很方便的检测出NAL的分界,依次取出NAL进行解码。

但为了节省码流,H.264没有另外在NAL的头部设立表示起始位置的句法元素。

如果编码数据是存储在介质上的,由于NAL是依次紧密相连的,解码器就无法在数据流中分辨出每个NAL的起始位置和终止位置。

解决方案:在每个NAL前添加起始码:0X000001

在某些类型的介质上,为了寻址的方便,要求数据流在长度上对齐,或某个常数的整数倍。所以在起始码前添加若干字节的0来填充。

检测NAL的开始:

0X000001和0X000000

我们必须考虑当NAL内部出现了0X000001和0X000000

解决方案:

H.264提出了“防止竞争”机制:

0X000000——0X00000300

0X000001——0X00000301

0X000002——0X00000302

0X000003——0X00000303

为此,我们可以知道:

在NAL单元中,下面的三字节序列不应在任何字节对齐的位置出现

0X000000

0X000001

0X000002

Forbidden_zero_bit =0;

Nal_ref_idc:表示NAL的优先级。0~3,取值越大,表示当前NAL越重要,需要优先受到保护。如果当前NAL是属于参考帧的片,或是序列参 数集,或是图像参数集这些重要的单位时,本句法元素必需大于0。

Nal_unit_type:当前NAL 单元的类型

3.H.264的NAL层处理

结构示意图:

NAL以NALU(NAL unit)为单元来支持编码数据在基于分组交换技术网络中传输。

它定义了符合传输层或存储介质要求的数据格式,同时给出头信息,从而提供了视频编码和外部世界的接口。

NALU:定义了可用于基于分组和基于比特流系统的基本格式

RTP封装:只针对基于NAL单元的本地NAL接口。

三种不同的数据形式:

SODB 数据比特串-->最原始的编码数据

RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit“1”)若干比特“0”,以便字节对齐

EBSP 扩展字节序列载荷-->在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要添加每组 NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示,ox00000001,否则用3位 字节表示ox000001.为了使NALU主体中不包括与开始码相冲突的,在编码时,每遇到两个字节连续为0,就插入一个字节的0x03。解码时将 0x03去掉。也称为脱壳操作

处理过程:

1.   将VCL层输出的SODB封装成nal_unit, Nal_unit是一个通用封装格式,可以适用于有序字节流方式和IP包交换方式。

2.   针对不同的传送网络(电路交换|包交换),将nal_unit 封装成针对不同网络的封装格    式。



第一步的具体过程:

VCL层输出的比特流SODB(String Of Data Bits),到nal_unit之间,经过了以下三步处理:

1.SODB字节对齐处理后封装成RBSP(Raw Byte Sequence Payload)。

2.为防止RBSP的字节流与有序字节流传送方式下的SCP(start_code_prefix_one_3bytes,0x000001)出现字节竞 争情形,循环检测RBSP前三个字节,在出现字节竞争时在第三字节前加入emulation_prevention_three_byte (0x03),具体方法:

nal_unit( NumBytesInNALunit ) {

forbidden_zero_bit

nal_ref_idc

nal_unit_type

NumBytesInRBSP = 0

for( i = 1; i < NumBytesInNALunit; i++ ) {

if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) {

rbsp_byte[ NumBytesInRBSP++ ]

rbsp_byte[ NumBytesInRBSP++ ]

i += 2

emulation_prevention_three_byte

} else

rbsp_byte[ NumBytesInRBSP++ ]

}

}

3. 防字节竞争处理后的RBSP再加一个字节的header(forbidden_zero_bit+ nal_ref_idc+ nal_unit_type),封装成nal_unit.

第秪>+ ]on_prevention_tha
!( i + 2 &1 BR>&n0X00任tar/starta_inunit T1<(t; InRBSP = 0<

2.为防止RBSP的字节流与有序鬃纸诰SP再n_prevention_three_by<要依 时延簊p;>1bit)∠ 陀Φ检测出N" C规范出头信]<前缀层在同步]&要少.N笽GH曜疾该遵循64k]肪队谟蠦R>校贗P层的分割无法包指詈64千]校装砈TRON(IETF)保来支特流特征ring Of Da(1)>&n>1.SODB字>&遇笛------集246媒ring Of Da(1)戏肿1.SODB字>NA义了〕鯪柚。1.引≒PS)〗诘0x03〃PPS)是很少p。,助摹#用× &n字节分组愕募觳字絘_4鯮TP包中ring Of Da=猬宏块及片迪裰鳎;"串焦NAe.1.SODB字001.IDR受到CL层为昕榧捌。IDR_un组 N组成见0X0>1.SODB字接梅庾案袷剑梢允艿奖EIGHT像主,从合传昕椋++ 或BR><,损稳≤到1.SODB字浆宏磕语法级别的禫CL8和 RT &n字节分组以前包可以叮重复Sequ用<哐映来砟芰Α,宏磕语法级别的禫CL8骸按肧o>詐τVCL材N更为可靠的 2 “疵外”通能癳qu。T-SIZE:

BR-------------> 

 &包中,ɡ嘈褂肐V>AL局组虬TAP2种不。<直嘁匀斡到A填加界蛋VCL残褂肨RO褪敲ATM等 2鼀loa,囟苑NAL yloa由001.密且皇" 砈TR桓&能闹植粂loa海块P;,秠loa。实时PANloa(Real Ties.BR>鼻<缜 Btoco合15pnit<缬蒖eal -------s和---scape公司共同L内1序黙tte="C海块C椤5⊿P目的是HM计薝DP煌蔐У;&n输虬TAP2种不包中V植粂loa15p闹植粂loasp;6 H.264种不bsp; 庖莇 FoP打包机> &以緊++ 5p闹植槐ǖ淖常ィ℉础r恍枋NE-H器蟖ylI><)001.砈TR桓(SP参省常デ12+ ]
句是固如下嫉腘NE-H则VCL残且魀x;是煤洗植话校种不辩下〕%sp; 椋受1元,NA 萩bp3中当前NA姆域er&湟庖逅 CSRC记PS莹CCBR>>>>StarCSRC谝桓的数啮包CSRC谝桓紧跟干盩P固如〕%,VO_表拭于簍ar5p闹植槐----源戏NALNloa允许at 教++ 会话以N鎚atBR><种不源戏T-SIVCL驳计5p幕旌掀鱖E: ,解码浦植辉触位鏡ONG>
++ CSRC列表于簍ar++ 电话;" , ;" 导扑++ 5p幕旌掀鹘玊STR奖硎者中5ピ糁植婚(MT,解码5p闹植辉 NE-H掉,而PTBR>>>>S昝装进NE-H" >>>>拭于为
禁义了探岜环指络中木呲三自任拥何e[ N蜱中木种不灾节节,程ODB约旱氖虑 ,敖鳱loa时延并不NE-鹬植4以痛 庾案袷剑梢脏时间尽〖锹剂薔E-H椋現ON+ ]
<瓷样嗍奔BR>BR>禁能够嗍奔渚能够确=.2植4业用锿沸疟硎玖素偏 对有5跋熳匀问痹邳成世床钩ヘ偏 对釉纸诮冢蘋DB约旱 事 引钟5p闹植槐缦聅p; /16芽蹿1序玫搅&n输TAP2。掉,、sp; 、昕呐>⑧时间聚参释沸畔⒏郊又植浑借助腡RON些都为>&nbstaMTAP2&n输义了符懈咝У基 础包中loaeam康氖且辶>&nb2植滑块0; >音px和合传端到端&n输P/R詐ν干盩P质盠的忿法容 伺机制建罫的底输木抖动忿法或抖动非忿法中0n输Nloa。但NG>縋分和依赖于特损稳』同地址sp; 嫉腘仅仅节—加阶输0n输Nloa±<码痢(F conta恍枋分段>縋时延还不义了耍可靠性现0x00ON些都_id0n输Nloa;是媒冢蘋DB约河诤S肬D的典BR>浇冢Ч号<>縋仿隨li淙胪计Nloa。但作谓ㄚ,程ODH.2装砈TR加P詃 Fo下嫉椋受2元,NA块C;,秠loa15pC;,秠loa—加1NAL2植籒loaON起配绻用自缺节,程OD启动++ 5p幕峄艾在逼多室约001.STRO字絘别供NAL海块C殓褂冒校时延并不能6位按饕持编2植话辶丝煽康氖头趾鸵辶朔勘Vぁ6赨DP諸RON些都由5pC槔碞E-鸺乒豑CPɡ5pC椴闶ⅲ1NALH.26蛴销"现0x00向会话以&nbSTR 成员周期性地包可;,秠助摹#冢蘋D导扑>BR>ON些2植滑<种谢袢』峄安斡胝吣芗觳庾柿瑁厚参柿鞣阶纯觥嵌运氐缰懈判就韧发送RTC用<只哪芄晦制/R赡芑bsp;控 制;是蒙 RTP状况bsp;诊断、 5pC镹loa的-妒堑计舜似禩RONCL2植槐ɡ磀 Fo下嫉p;。NAL单元抵值簦 SR>>>>包可端报竢ac所谓包可端是指发 5p闹植槐>浇冢蘋D;是弥斩000包可端贫嗍τVCL彩>BR>侗晔 RR>>>>>BR>侗报竢ac所谓>BR>侗是指仅紹R>但睶oS反NAL2植槐缦陆冢蘋D;是弥斩0晔 SDES>>>>源描什1衟;。-妒亲魑交峄俺稍秉丢授一歌助牡&nb体嫉椋用户名嗍件地址、电话号>>>>通知纗001衟;。-妒峭缒车++ ;是锚的吩床辉侉蔐Р阍谕ㄖ峄耙&n 2 成员B约黑逼顺龌峄瓣 AP剑>>噬节,程ODB约撼鐾稡R><静砍ONCL---its性别出 VS-且为琹oa的d Fo者义了匪酣装sta榛钚躁 RNCL2植槐ㄐⅲ/R赡芑监控的摈样抵。能够拗疲疪赡芑bsp;动潭TR;的大旋据焦晦至鞣交赽sp;ㄊLУ;,禤层的稲NCL2植槐ㄏⅲㄝ匆馐嗖nce詐ν 此会话以&nbSTR成员都VCL驳计5pCL2植槐ǚ祷氐;,秠助模幢嗦p;)他参与者能些重傲鞲UD的++ 典BR>浇冢Ч号<包可P打包机纸冢蘋D将周期性地
包可端报竢SR, 肦NCL2植槐ü执似禤打包挥δ芡浆助摹R参室丫傻氖齪;&n和TBR>侗赡艿ON些VCL补兰瞥鍪导康氖齪;0n输速p"≈节x;" >&nb>BR>侗会向bSTR已000陌啥税>BR>侗报竢RR, 肦NCL2植槐ü忠>BR>数p;&n⒙缰心臼齪;&n数啮阿延时 对雍秃合分椎戎匮 。包可端节,赡艿ON些VCL补兰瞥鐾&nb延 VS-且VCL采能凳齪;&n电中概芯和汉延 对影流付禩髡伤賞":癫改善流方基于状况要优者赡艿流方状况平滑 地;的唇冢蘋D0陌/R赡芑包中SP实时PANloa 作谓++ 节,层琹oa<>縎P义了匪++ 可供-its的;RON戏T- >意义包戍以得实时PAP打笆齪;的受控酆香播变得码唯琀" 四馨<>縎PR>1.&aMTAP2簍ar协 oa<依赖于下输0n输Nloa所义了eam⒘谌⒆刺>縎PΦ母由5pS;,赌径打傲骷2VCL睵ANtar描什1ㄔ贜sL内为了防Dcatiop诓砍)来出头BR所谓Ntar是指aMTAP2埃疪器义了给客户机++ 或敲蒖><斗节S榘/R器的;煽0n输忿法以发 5p-的喊蠸P琹oa亲楹掷<特流连续虾 检薓TAP2:>>允许用户导扑HTAL优者 2谌騊打鞍/R器义交++ Ntar描什挠畔Ntar是组d鷂3b騈tar描什在狐到,从该P打包机肿閐刂份打TRONG;H.264 ar是亥播销_3 庾案袷剑梢遭装格式,可以庾案袷剑梢遭装格式,可意装格6位了安全在ptar描什中ピ<滞义了m康牡刂贰 邀请争情:>>P打鞍/R器VCL脖谎氩渭诱耐sp;界" ,优者在ptar中回放P打耙耪咴趐tar中录制全部P打盎蚱渥有枰ピ264疽馔布式教研∮ 了仿写虬:>>通知用户新争情的;伞,肞打包籘RONide殖〗沧鵄L静显得尤 进行母与HTAL/1.1类似BR5pS榍肭螃覸CL步籨0砗蚉苡耪呋捍鍭L局组处 理海 必 JM86椋e[ N涉及>庄PS雍&nbs鼻癗n组_unDR组 N组成型(梅庾案袷剑梢栽趀 NAL u中 INT-并不偷ヒ随机访慰的能力TRON个-队 nDR 承担诤糯前稳------由 nNT-承担诤用封装格式,可以nDR 会嵌杂 DPBRBS剖俏列表——单郧关及在在)清空嫉腘 nN仓露。必锈装格式,可以I_unDR组其实BR><霉用担8cb骸<。4.庾案袷剑梢訧DR受到ON定鯱n受到,但n受到和襈定鯱nDR受到遇++ 昕鯬图像觭tart的n受到,n受到,VO_st受到VCL惨胣受到,V应能蛙到做运动剖>1.ve ad5,0,0); broooooo

broooooo
adiv> broooooo
adiv> div> broooo E: div > adiv> adiv> broooooo
brooooooE: spNALclass rptcp"> brooooooE:E: spNALclass riヽbp bcmimg">庾案袷 aapNA> brooooooE:E: spNALclass rnbc-0 nbc-0-40 ptcmt ptcmt-2">评论这张 aapNA> brooooooE: aapNA> broooooo adiv> div utyl包穌isplay:LU R"Lclass rptc phoundztag"> brooooooE: spNALclass rptcp"> brooooooE:E: spNALclass rnbc-0 nbc-0-40 ptcmi"> brooooooE:E:E: img src; TEXT-DEb.bst.126."r(/newpsty/imstys/micro="_b.png?bqs/> brooooooE:E: aapNA> brooooooE:E: spNALclass rnbc-0 nbc-0-40 ptcmt">转发至微博 aapNA> brooooooE: aapNA> broooooo adiv> broooooo
brooooooE:庾案袷 aa> broooooo adiv> broooooo broooooo
brooooooE: spNALclass rptcp"> brooooooE:E: spNALclass rnbc-0 nbc-0-40 ptcmi"> brooooooE:E:E: img src; TEXT-DEb.bst.126."r(/newpsty/imstys/micro="_b.png?bqs/> brooooooE:E: aapNA> brooooooE:E: spNALclass rnbc-0 nbc-0-40 ptcmt">转发至微博 aapNA> brooooooE: aapNA> broooooo adiv> broooooo
brooooooE: broooooo broooooo
brooooooE:E: spNALclass rkc07">阅读( spNALid="$_apNAiReadC ==t">1src aapNA>ctuapNA> spNALclass r suikc07">| aapNA> broooooobroo spNALclass rkc07">评论( spNALid="$_apNAiCis knts ==t">1 aapNA>ctuapNA> broooooo broooooo broooooo broooooo
brooooooE:E: div class rp997" rdif"> brooooooE:E:oo spNALutyl包穌isplay:LU R"Lclass rp997" sui su-lastikc07">| aapNA> broooooobroooo div class rshnbs-prop p997" > broooooobroooooo spNALid="$_ahnbsBtn_lof琩 "Ltitl包贩窒淼絃OFTER brooooooE:E:broo spNALid="$_ahnbsBtn_ (Saweibo brooooooE:E:broo spNALid="$_ahnbsBtn_qq brooooooE:E:broo spNALid="$_ahnbsBtn_qqweibo brooooooE:E:broo div id="$_ahnbsBtn_weixin broo img src; TEXT-DEb"_b.163: non) {MaxImstyGen.do?url=409cc7cderlylee.="_b.163: non)"_b) broo div class rtips" broooooo

用微信庾案袷剑梢“肾陀扫”

将文章分享到朋友圈。

broo
adiv> broobroooooobroo adiv> broooooo broooo div id="$_ahnbsBtn_yixin broo img src; TEXT-DEb"_b.163: non) {MaxImstyGen.do?url=409cc7cderlylee.="_b.163: non)"_b) broo div class rtips" broooooo

用易信庾案袷剑梢“肾陀扫”

将文章分享到朋友圈。

broo
adiv> broobroooooobroo adiv> broooooo broo adiv> broobroooooobr broooooobroooo > broobroooooobroo in;&nbs="houR><"字絤="thirdId" vgt;="fks_08706608嘉8508306808208608506607208708507加穙臃508106808加穕Ba/> brooooooE:E:broo in;&nbs="houR><"字絤="ot n" vgt;="BLOGPOSTBa/> brooooooE:E:broo in;&nbs="houR><"字絤="Bitl" vgt;="rmat字节 RNPBa/> brooooooE:E:broo in;&nbs="houR><"字絤="deo L内" vgt;="al_uV>

合传 i组 N提取(fir>MP ac輑_uve a荩 輑_u
H.264 NAL格式及分析" 因蕂r(="le="C" rR: "gb(51,10" 字絝 "409cc7cd92ace.html" sdlyfdy" 荩fnbsy586輑_uvA荩蚥sp;原始数bsp;原始数l_ucorR: "gb(51,10" 字絝 "409cc7cd92ace.html" sdlyfdy" 荩409cc7cd92ace.html" sdlyfdy&l_uvA荩蚻_uve a荩 輑_u< nN枰砑甸9鸅R><鞋那么ON些2枰 H.≈捣++ nNT-桓鯪然这盧><另虼&nbs盠的匾约傲鞲袷掣鋈械母輑_uBR荩蚻_uBR荩实伎节,Φ检 仿隨仓露tes#辉及流竌c所以VCL彩保含纷枰砦数集Lunit原始数bsp;原始 头信等值 2 或 7众一CL部出篙l_uve a荩輑_uBR荩蚻_uBR荩輑_uBR荩蚻_uBR荩璐笥0。
H.264 NAL格式及分析" rR: "gb(51,10" 字絝 "409cc7cwww.cpp="_b. nonczanyou/bsp;ive/age8/1yte6/67940p://h" 荩璐笥 RNPp; ylI>< sp; 輑_uvA荩蚻_uvH2荩 輑_u="LINE-H"> 

0 

0酱砦它进:輑_uvP荩 輑_u="LINE-H"> 

0 

0按諂ZZ, T坪跬鏞N个2纸赨 4以外的, 如>按招2纸赨 都有器可L捕┪NAL蛋响受到00回放.N仓扑+般傲鞲袷和耀关心輑_u/P荩 輑_u="LINE-H"> 

0a粜.輑_u/P荩 輑_u="LINE-H"> 

0 

0 

0 

01>1b.輑_uBR荩輇sp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始 +4*4块的系数能不+輑_uBR荩蚥sp;原始蔐unit原始数bsp;原始蔐unit原始蔐unit原始 |0|1|2|3|4|5|6|7|輑_uBR荩蚥sp;原始蔐unit原始数bsp;原始蔐unit原始蔐unit原始 +-+-+-+-+-+-+-+-+輑_uBR荩蚥sp;原始蔐unit原始数bsp;原始蔐unit原始蔐unit原始 |F|NRI| T疞unit原始蔐bsp;原始 |輑_uBR荩蚥sp;原始蔐unit原始数bsp;原始蔐unit原始蔐unit原始 +44*4块的系数能+輑_uBR荩字段 T: ON个2RNPp; ylI>< 中 纸谀单位时,本. ON个T<段和e NAL u中掉,字段约伴成是, 当bsl_uBR荩4以滴 >1~232度块荽值.輑_uBR荩輇sp;原始瘦bsp;原始瘦l_uBR荩24Lunit原始蔐unit原始瘦bsp;原始 STAP-ALunit原始蔐unit原始誓单一嗍奔的码合包輑_uBR荩25esInNA原始数bsp;原始 STAP-BLunit原始蔐unit原始誓单一嗍奔的码合包輑_uBR荩26Lunit原始蔐unit原始蔐unit原始 型分16Lunit原始蔐unit原始 BR><趾戏的码合包輑_uBR荩27Lunit原始蔐unit原始蔐unit原始 型分24Lunit原始蔐unit原始 BR><趾戏的码合包輑_uBR荩28Lunit原始蔐unit原始蔐unit原始 FU-ALunit原始蔐unit原始蔐unit原始蔐unit原始 分贫TR;肿檩l_uBR荩29Lunit原始蔐unit原始蔐unit原始 FU-BLunit原始蔐unit原始蔐unit原始蔐unit原始 分贫TR;肿檩l_uBR荩30-31 盠的出头輑_u/P荩 輑_u="LINE-H"> 

0 

0< 24, 25, 26 癫问 27.輑_u/P荩 輑_u="LINE-H"> 

0<2RNPp包. 存在鯮TP包中 FU-A 和eFU-B. 掉,值Ra别>< 28 和e29.輑_u/P荩 輑_u="LINE-H"> 

0校2璐笥2纸赨 抵组掣由 [Snbsp;Co輑_uWBR荩de] [纸赨 H础r] [纸赨 蟖ylI><] SODSTR桓, 萩bp Snbsp;Co輑_uWBR荩de ,从谝籸单郧++ 輑_u/P荩 輑_u="LINE-H"> 

0<>< "按瞻凑按瞻1" 或 "按瞻凑1",2纸赨 生钓++ T< 纸赨 ;肿閙谌.輑_uBR荩戳也l比コ "按瞻凑1" 或 "按瞻凑按瞻1" 的;_se码, 把;)他数p;封要校2RNPp环即码.輑_u/P荩 輑_u="LINE-H"> 

0 

0 

0 

0 

0&nbsSIZE: 0&nbsSIZE: 0< > 

0 

0 

0<2璐笥 流:輑_uvP荩 輑_u="LINE-H"> 

0<>< "vnR>o"輑_uBR荩. "a=rtpmap" 行中的编码名称盧><>< "rmat".輑_uBR荩. "a=rtpmap" 行中的时窒传&时R><>< 90000.輑_uBR荩. ;)他≒PS都包括ate"a=fmtp" 行中.輑_u/P荩 輑_u="LINE-H"> 

0 

0 

0 

0 

3ali" 荩輇sp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始 完整校C/S架构的基于RNP/RTCP的H.mat合传传输方案。此方案Φ检在服务器端和客户端Ra别蛃p;了輑_utTRONG荩功能模块设计輑_u/tTRONG荩輇sp;原始述篙l_uSTRONG荩服务器端輑_u/tTRONG荩輇sp;原始剩篟NP节的模块主要是对H.mat&nbs蛃p;戳也节的;RTCP分析模块NE-鸩:头⑺蚏TCP包并分析>BR> 校RTCP包;QoS反馈控制模块则根据RR报文反馈信息动潭TR对发送速率蛃p;调整;发送缓冲模块则设置端口发送RTP、RTCP包龈輑_uSTRONG荩客户端輑_u/tTRONG荩輇sp;原始剩篟NP模块对>BR> 校RTP包蛃p;解析;RTCP模块N軸R报文统计关键信息,产牛并发送RR包。然后检在VC++6.0下用Socket编程,完成基于RNP/UDP/IP的H.mat合传传输,并在局域网内运p;较好龈輑_uvthe 荩蚻_u/P荩 輑_uP荩輑_uthe above ("> 

6ali" 荩輑_utTRONG荩基于RNP/UDP/lP的H.mat合传传输絫yp设计輑_u/tTRONG荩輑_u/the 荩蚻_u/P荩 輑_uP荩輑_uthe above ("> 

3ali" 荩輇sp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始 时间H.mat合传的实时传输节,来说,TCP的重传机制引入的时延和抖动是无砦溯忍的,因此我们并(UDP传输协议桓霁是UDP协议本身是面向无连交约,不能提供质量保证。而基于UDP之上的s卟阈镽NP/RTCP可L惨黄鹛峁┹l_utTRONG荩流量控制和拥塞控制輑_u/tTRONG荩輇sp;原始史瘛M几Ate了基于RNP/UDP/IP的H.mat合传传输的;蚣荟篙l_uvthe 荩蚻_u/P荩 輑_uP荩輑_uthe above ("> 

3ali" 荩輇sp;原始瘦bsp;原始瘦l_u/the 荩蚻_u/P荩 輑_u

&nbsFAMILY: Ariali" 荩輇sp;原始瘦l_u/the 荩蚻_uthe above ("COLOR: rgb(51,51,51); >&nbsFAMILY: Ariali" 荩 輑_u 

6ali" 荩輑_utTRONG荩RNP载荷节的设计輑_u/tTRONG荩輑_u/the 荩蚻_u/P荩 輑_uP style "LINE-HEIGH NA26ali" 荩輇sp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始瘦bsp;原始 本文的流方传输是基于IP协议,所以輑_utTRONG荩最葱传输抵组(型U輑_u/tTRONG荩輇sp;原始)最葱为1500T裕沸畔⒅辽僖加40个T的;_销为2.7%,如果RNP载荷的0001为730T的;_销仍达到5.3%,而假设2RNP载荷的0001不到40TBR>而后续 N包丢失,由从蚅的礔ON+ 也中包含有完 整校RNP头信息,而RNP头中肔的关于载荷0001的标识,因此不出该RNP包是否有絘割丢失,只能认为完整校>BR>了。并且在IP层H.穉割无砦在节,层 实现保护从而降低了非平等包含方案的效果「由于UDP数p;吩素指詈64KT<片的0001对某些节,场合来说的点太小,所以輑_utTRONG荩节,层的戳也輑_u/tTRONG荩輇sp;原始室彩荝NP戳也机制挡陀个必议DSTR。最新校RFC3984标准帜提供了<对H.m46媒体流校RNPNE-Hsp; ,主要有袷<:輑_uBR荩单><纸;肿榻运亍⒕酆戏运亍⑵斗运亍]l_u/P荩 輑_u="LINE-H"LINE-HEIGH NA26ali" 荩輑_utTRONG荩輑_uthe style "> 

6ali" 荩纸;肿檩ヒ淮烈草l_u/the 荩蚻_u/tTRONG荩輑_u/P荩輑_uthe style "LINE-HEIGH NA26ali" 荩将加><纸;肿榻诘慕痈霭校簿投人礡NPNE-H中只包含加><纸;肿椋节头部兼作RNP头部。RNP头部掉,即纸;肿榈簦1-23,如下图所示:輑_u/the 荩 輑_uP style "LINE-HEIGH NA26ali" align "c> 

6ali" 荩輑_utTRONG荩纸;肿檩粗刈檩l_u/tTRONG荩輇sp;原始瘦l_u/the 荩蚻_uBR荩蚻_uthe above ("> 

3ali" 荩此吩素掉,,从将輑_utTRONG荩BR><纸;肿榫酆系牡++ RNP吩素輑_u/tTRONG荩輇sp;原始手小R恍〩.mat的纸;肿檩创笮椋巛l_utTRONG荩SEIb纸;肿檩l_u/tTRONG荩輇sp;原始省ⅷPPS集等都非常虚,块蚅的姆T 

6ali" 荩輑_utTRONG荩纸;肿檩捶a割輑_u/tTRONG荩輑_u/the 荩蚻_u/P荩 輑_uP style "LINE-HEIGH NA26ali" 荩輑_uthe style "> 

3ali" 荩将加><纸;肿榻a割,使(輑_utTRONG荩BR><议蛃p;R指睿蒐苍诜a别在鯮个ㄣ次上蛃p;絘割:輑_uBR荩1)合传编码层輑_utTRONG荩VCL上的穉割輑_u/tTRONG荩輑_u/the 荩蚻_u/P荩 輑_uP style "LINE-HEIGH NA26ali" 荩輑_uthe style "> 

3ali" 荩为了适应流方型U的0叽纾蒐彩梗ū嗦肫骼囱≡褫l_utTRONG荩编码Sliceb纸赨輑_u/tTRONG荩輇sp;原始实拇笮椋佣蛊涮峁┙虾玫男阅荟敢"隨是对编码Slice的大虚蛃p;调整,使其指詈輑_utTRONG荩1460T 

3ali" 荩2)流方提取层輑_utTRONG荩纸谏系姆a割輑_u/tTRONG荩輇sp;原始瘦l_uBR荩在流方提取层上对纸赨的穉割主要是并(輑_utTRONG荩吩片抵组方案輑_u/tTRONG荩輇sp;原始剩琀.mat标准帜提te了穉割机制,可L彩怪节;肿檩0叽缰割1460T<纸;肿橥sp;絘割的輑_u/tTRONG荩輇sp;原始剩皇视泳酆戏运伥敢"><纸;肿椴ⅲǚa割吩素后检每个RNP吩素昕呐依次递增l,輑_utTRONG荩RNP汉戏肿相同且惟一輑_u/tTRONG荩輇sp;原始省V节;肿檩捶a割是RNP戳也机制挡陀个重议"方R检总结其穉割机制主要有耒下姆特点:輑_uBR荩①穉割纸赨时,是以RNP次序号輑_utTRONG荩升序蛃p;輑_u/tTRONG荩輇sp;原始蚀洹T诂宏磕挪谎>的前提下,属于前一帧受到的所有蛙到片包癫问A/B/C数p;吩割要校昕呐要指詈后帧受到中的蛙到片及数p;吩割要校昕呐。輑_uBR荩ON+ 符号机制来标记++ 穉割的纸赨是礔ON+ 还是最后"><纸;肿椤]l_uBR荩3.存在鲰蚇++ 符号机制,来检测是否有丢失的穉控。輑_uBR荩④辅助增强信息包和头信息包可L踩我夂合贩⑺汀]l_uBR荩⑤同加帧受到中的蛙到片可L惨踩我馑承蚍⑺停鞘奔涞褪毖右性剂鞣较低臣熳詈檬且运窃BR>校编码顺序来发送。輑_u/the 荩輑_u/P荩 輑_u="LINE-H"LINE-HEIGH NA26ali" 荩輇sp;原始瘦l_u/P荩 輑_uP style "LINE-HEIGH NA26ali" 荩輑_uBR荩蚻_uthe above ("> 

3ali" 荩1)輑_utTRONG荩荪一汉戏聚合吩素輑_u/tTRONG荩輇sp;原始(STAP):包括荪一汉戏聚合吩素A(STAP—A)和荪一汉戏聚合吩素B(STAP—B),按汉戏肿蛃p;素合,他们的纸;肿榫哂邢嗤氖奔浯粒"隨蝇从低延迟环境。STAP—ASTAP—B校抵组掉,絘别为24和25。輑_uBR荩2)輑_utTRONG荩多汉戏聚合吩素輑_u/tTRONG荩輇sp;原始(MTAP):包括16比特偏移多汉戏聚合吩素(型APl6)和24比特偏移多汉戏聚合吩素 (型AP24)仓投时间戳也可L菜睾希"隨蝇从高延迟约流方环境,比如流媒体节,.霜校戳也方案相对复杂,但是葱大增强了基于流媒体的H.mat的性 能龈型APl6 型分24校抵组掉,絘别为26和27。輑_u/the 荩輑_u/P荩 輑_u="LINE-H"LINE-HEIGH NA26ali" 荩輑_uthe style "> 

6ali" 荩輑_utTRONG荩RNP要校节的流程设计輑_u/tTRONG荩輑_u/the 荩蚻_u/P荩 輑_uP style "LINE-HEIGH NA26ali" 荩輑_uthe style "> 

3ali" 荩根据H.mat纸;肿檩捶a割重组的性质癫问RNP戳也规则,本文实p;礡对輑_utTRONG荩RNP戳也的设计輑_u/tTRONG荩輇sp;原始嗜缦拢狠l_uBR荩1、若>BR> 校纸;肿橹割篗AX—SIZE(此时MAX-sIZE为设定的輑_utTRONG荩最葱传输抵组輑_u/tTRONG荩輇sp;原始),则对它蛃p;荪一戳也,也就度将此纸诘肿橹苯臃沤鳵NP要校载荷DSTR,生桓++ RNP要。輑_uBR荩2、若>BR> 校纸;肿榇笥谛Ax—SIZET 

3ali" 荩其中輑_utTRONG荩Nsrz欠愿钋暗闹节;肿榇笮檩l_u/tTRONG荩輇sp;原始剩是輑_utTRONG荩吩割后纸;肿檩创笮檩l_u/tTRONG荩輇sp;原始省]l_utTRONG荩K吩割后的抵组PS輑_u/tTRONG荩輇sp;原始省7愿詈笞詈笠"><抵组的大虚码唯会指詈N,这时盧><>梗ㄝl_utTRONG荩RNP载荷填充輑_u/tTRONG荩輇sp;原始适瞧渫懊娴姆a控大虚相同,此时RNPa;礡輑_utTRONG荩填充标识位缘谓輑_u/tTRONG荩輇sp;原始1。輑_u/the 荩輑_u/P荩 輑_u="LINE-H"LINE-HEIGH NA26ali" 荩輑_uthe style "> 

3ali" 荩3、对SEI,睵PS集等小纸诘肿橹刈椋l_utTRONG荩T-SI合并到加><片中就禹加><起始码0x000001,为防止 内部0x000001昕竞赵,璐笥诒嗦肫髟谧詈笠"T<新校T的3~4个T校纸诖烈瞫p; ,就度开始的若干T<借助某个全荆H.数p;来获胆编 有器的pro輑_uWBR荩file,level,PPS,SPS等信息才可L步加小]l_uBR荩----------------------------------------------------------------------------輑_uBR荩AVC vs.2璐笥谳l_uBR荩AVC and2璐笥 are synonymous.2Theestandard is known by theefull n絤痵e"ISO/IEC 14496-10輖uo and2輖uoITU-T Recommendation2璐笥谳quo. In addition, a number of al(ernate n絤痵eare used (or have been) in referencebto this standard.2These inclutr:輑_uBR荩輑_uBR荩 輑_uUL荩 輑_uLI style "LIST-STYLE-TYPE: none;輖uo 荩 輑_u/LI荩輑_uLI荩MPEG-4bpart 0 輑_u/LI荩輑_uLI荩MPEG-4bAVC 輑_u/LI荩輑_uLI荩AVC 輑_u/LI荩輑_uLI荩MPEG-4b(in theebroadcastrly world MPEG4bpart 2 is ignored) 輑_u/LI荩輑_uLI荩璐笥 輑_u/LI荩輑_uLI荩JVT (Joint VnR>o Team, nowadays rarely used referrrly to actualsspec) 輑_u/LI荩輑_uLI荩璐笥L (early draf{< w>o fr絤痵.2These 纸 un {< have no boundary marker<, and2rely on2some unspecified > fr絤rly.輑_uBR荩輑_uBR荩Annex B of of theedocumentsspecifi痵eon輑_uWBR荩eesuch >o elementary stream, thus makrly itssuitableefor use with containers like MPEG PS/TS unableeto provnR> theerequired >r絤rly. Other from a deficiency. It defines severalsheador-typee纸 un {< (SPS and2PPS) withoutsspecifyrly how to pack them into theesrlyleec(trc da輑_uWBR荩ta field availableein most containers. F<0l03桓霰郊有器在纸谀诓考觳獾 0l000003H.数p;,就把0l03抛弃,恢复原始数据。輑_uBR荩0l000000輇sp;原始瘦bsp;原始 輇sp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;原始数bsp;原始 0l00000300輑_uBR荩0l000001輇sp;原始瘦bsp;原始 輇sp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;原始数bsp;原始 0l00000301輑_uBR荩0l000002輇sp;原始瘦bsp;原始 輇sp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;原始数bsp;原始 0l00000302輑_uBR荩0l000003輇sp;原始瘦bsp;原始 輇sp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;,据bsp;原始数bsp;原始 0l00000303輑_uBR荩輑_uBR荩附上h.mat郊有nalu中检测起始码的算法流程輇sp;原始瘦bsp;原始瘦l_uBR荩fo_object_sequence_start_co輑_uWBR荩de 0l000001B0 ptar"个合传对象昕的;_始,VO_start_co輑_uWBR荩de 0l000001B6 ptar"个VOP的;_始. 0l000001B6之后的两位检是00ptar2I >r絤e, 01 ptar P >r絤e, 0 ptar2B >r絤e.輑_u/o c(trly layer 輇sp;原始瘦bsp;原始 合传编码层輑_uBR荩輑_uBR荩纸谳bsp;原始瘦bsp;原始 network abstraction2layer輇sp;原始瘦bsp;原始 流方提取层輑_uBR荩輑_uBR荩VCL:核心算法引擎,块,宏块及片的语砦级别的定义輑_uBR荩輑_uBR荩纸冢浩兑陨系挠镯渭侗穑ㄈ绗宏坎PPS集和受到≒PS集),投时支常以下功能:独立片郊有,起始码唯一保证,SEI癫问流sp; 编码数p;传送輑_uBR荩輑_uBR荩VCL设计目标:尽码唯地独立从枉方的情况下絪p;高的编郊有輑_uBR荩輑_uBR荩纸谏杓颇勘辏焊莶滞禩R枉方把数p;戳也成相应的sp; ,将VCL产生的比特字符串适配到各种各样的流方和多蚤"肪持小]l_uBR荩輑_uBR荩纸赨头絫yp:纸赨掉,(5bit)觫重议性网络位(2bit)觫禁止位(1bit)觯輑_uBR荩輑_uBR荩纸赨掉,:1~12由璐笥谑梗ǎ24~31由璐笥谝酝獾挠冢梗ā]l_uBR荩輑_uBR荩重议性网络:标志辅纸诘肿橛又亟ㄊ陛粗匾樾裕翟酱螅街匾椤]l_uBR荩輑_uBR荩禁止位:枉方发现纸诘肿橛斜忍卮砦笫笨缮柚酶帽忍匚1,以便>BR>方丢掉该抵组。輑_uBR荩輑_uBR荩2.纸谟镯斡镆遢l_uBR荩輑_uBR荩纸诓憔浞ǎ狠l_uBR荩輑_uBR荩在编码器输出的码流中,数p;的基本抵组是句法元素。輑_uBR荩輑_uBR荩句法表征句法元素校T橹typ。輑_uBR荩輑_uBR荩语义阐述句法元素校具体含煎。輑_uBR荩輑_uBR荩吩素都有头部,郊有器可L埠芊奖愕募觳獬鲋节的穉界,依次取出纸诮sp;郊有。輑_uBR荩輑_uBR荩但为了节省码流,璐笥诿L的另蚇在纸诘耐凡可枇tar起始位置的句法元素。輑_uBR荩輑_uBR荩如果编码数p;是存储在介质上的,可于纸诙纫来谓裘芟嗔模加衅骶臀揄卧谑齪;流中絘辨出每个纸诘钠鹗嘉恢煤椭罩刮恢谩]l_uBR荩輑_uBR荩解决方案:在每个纸谇疤砑悠鹗悸耄0X000001輑_uBR荩輑_uBR荩在某些掉,的介质上,为了寻>的方便,要切数p;流在0001上对菩,或某个常PS荽整PS倍。所以在起始码前添加若干T<患虑当纸谀诓砍鱿至0X000001和0X000000輑_uBR荩輑_uBR荩解决方案:輑_uBR荩輑_uBR荩璐笥谔岢隽恕胺乐咕赫浴被疲狠l_uBR荩輑_uBR荩0X000000——0X00000300輑_uBR荩輑_uBR荩0X000001——0X00000301輑_uBR荩輑_uBR荩0X000002——0X00000302輑_uBR荩輑_uBR荩0X000003——0X00000303輑_uBR荩輑_uBR荩为此,我们可L仓溃狠l_uBR荩輑_uBR荩在纸诘肿橹校0X0的三T璐笥0。輑_uBR荩輑_uBR荩Nal_un {_type:当前纸谀单位时,本輑_uBR荩輑_uBR荩3.璐笥诘R纸讪愦磔l_uBR荩輑_uBR荩絫ypar尖图:輑_uBR荩輑_uBR荩纸谝灾节U(纸 un {)伍荪组荡支常编码数p;在基于吩素交换技术枉方中传输。輑_uBR荩輑_uBR荩它定义了符合传输层或存储介质要切约数p;sp; ,投时窤te头信息,从而提供了氏传编码和殊部世浇的接口龈輑_uBR荩輑_uBR荩纸赨:定义了竣(于基于吩素和基于比特流系统的基本sp; 輑_uBR荩輑_uBR荩RNP节的:只N<对基于纸谳プ榈谋镜刂节接口龈輑_uBR荩輑_uBR荩袷<仓投TR数p;形; :輑_uBR荩輑_uBR荩SODB 数p;比特串-->最訠R>校编码数p;輑_uBR荩輑_uBR荩RBSP 訠R>T<)。輑_uBR荩輑_uBR荩2.为防止RBSP校T检测RBSP前三个T<纸;肿榍懊嬖黾3个T<蛙到需要增加"个附加T<纸赨汇集的++ RNP皆素Φ。輑_uBR荩輑_uBR荩RNP的头标可L彩侵节U的头标,并可L彩迪忠陨系拇烈补嬖颉]l_uBR荩輑_uBR荩"个RNP絘组里放入加><纸赨,将纸赨(包括投时作伍载荷头标的纸赨头)放入RNP的载荷中,设置RNP头标值。为了避免IP层对葱吩素荽再x;"次吩割,贫吩素的大虚"隨都议懈詈M蚒0叽纭赣捎诎偷穆肪恫滞叮加卸艘匦露云斗运嘏判颍琑NP包含的次序信息可L玻唇饩稣庖晃侍狻]l_uBR荩輑_uBR荩纸赨吩割輑_uBR荩輑_uBR荩时间预先已经编码的内;,纸赨码唯大于型U0叽 N限制。虽然IP层的穉割可L彩故齪;控指詈64千T<片的0001对某些节,场合来说太小,所以节,层戳也是RNP戳也方案校ON睸TR。輑_uBR荩輑_uBR荩新校讨论方案(IETF)鸡当符合以下特征:輑_uBR荩輑_uBR荩(1)纸赨的穉块以按RNP次序号升序传输;輑_uBR荩輑_uBR荩(2)能够标记礔ON+ 和最后"><纸赨吩块;輑_uBR荩輑_uBR荩(3)可L布觳舛У姆a控。輑_uBR荩輑_uBR荩纸赨合并輑_uBR荩輑_uBR荩加纸赨如SEI、≒PS集等非常虚,将T-SI合并的+起有利于减少头标縚销。已有两种集合吩素:輑_uBR荩輑_uBR荩(1)荪一汉戏集合吩素(STAP),按汉戏肿蛃p;素合;輑_uBR荩輑_uBR荩(2)多汉戏集合吩素(MTAP),不投时间戳也可L菜睾稀]l_uBR荩輑_uBR荩纸诠娣妒洗齪;的sp; ,主要是提供头部信息,也适合各种媒体的传输和存储。纸谥С8髦滞鞣剑ǎ狠l_uBR荩輑_uBR荩1.任何使(RNP/IP协议约旱时有线和无线Interne( 服务輑_uBR荩輑_uBR荩2.作伍MP4文件存储和多媒体信息文件服务輑_uBR荩輑_uBR荩3.蠵EG-2系统輑_uBR荩輑_uBR荩4.;)它网輑_uBR荩輑_uBR荩纸诠娑ㄒ又滞ǎǖ膕p; ,既适合面狭也传输,也适合流传送。实际上,安传输和流传输的方式是相同的,不投之处是传输前面增加了"个起始码前缀輑_uBR荩輑_uBR荩在类似Interne(/RNP面狭也传送协议系统中,包絫yp中包含包边界识别T<个别的蛙到輑_uBR荩輑_uBR荩昕和受到≒PS集机制,减少了重复睵PS的传送,每><蛙到睵PS集包含"个标识,指向的关的昕睵PS集的内;輑_uBR荩輑_uBR荩因此检蚅得少PS的指针息,引用大量的睵PS,葱大减少每> 

4p COLOR: rgb(0,0,102)I" 荩輑_utTRONG荩輑_uBR荩輑_uBR荩輑_uBR荩輑_uBR荩輑_uBR荩輑_uBR荩輑_u/tTRONG荩輑_u/the 荩輑_uBR荩rmat实时编码及纸赨,RNP传输(续)(ZZ)輑_u/<存储荪组时鸡"个蛙到。每><存储荪组包含"组VCLe纸谳プ榧熳槌梢"个主编码蛙到,VCLe纸谳プ橛杀tar氏传蛙到采样的像条所组成。存储荪组前面可L布右"个前缀检穉界存储荪组,s郊釉銮啃畔ⅲ⊿EI)(如蛙到定时信息)也可L卜旁谥鞅嗦胪艿秸校前面。主编码蛙到后s郊拥腣CLe纸谳プ椋兑煌艿降娜哂啾tar,称为冗余编码蛙到,当主编码蛙到数p;丢失或损坏时,可用冗余编码蛙到郊有。编码氏传昕"个编码氏传昕由"串戡续招4娲⑤プ樽槌桑褂猛兑滑宏坎PPS集。每><氏传昕可独立郊有。编码昕的;_始是即时刷新存储荪组(IDR)。IDR度"个I帧蛙到,眛ar后面的蛙到仓用 ≒考以前的蛙到。"个纸谳プ榱骺砂"个或更多的编码氏传昕。RNP协议:旱时传输协议(Real-time Transp<)鯮个睸TR组成,其 中头部前12个T<数p;源,T-SI可L餐ü齊NP混合器合并为"个数p;源。谍如,可L膊"个CSRC列表来眛ar"个电话会议,该会议通过"个RNP混合器将T薪不罢哒校语音数p;素合为"个RNP数p;源。 NE-H掉,(PT)  标明RNPNE-H的sp; ,包括所并(的编码算法、ㄉ样频率、承载通道等。谍如,掉,2表明辅RNP数p;包中承载的是用ITU G.721算法编码校语音数p;,采样频率为8000Hz,并且并(单声道。 輇sp;原始瘦bsp;原始 昕号  棵来为>BR>方提供探测数p;丢失的方法,但如何处理丢失的数p;则是节,程序T约旱氖虑椋琑NP协议本身并不NE-鹗齪;荽重传。 輇sp;原始瘦bsp;原始 时间戳 记录了NE-Ha;的+个T方能够时间戳能够确定数p;荽到达是否受到了延迟抖动校影响,但具体如何来补偿延迟抖动则是节,程序T约旱 事情。从RNP数p;报的sp; 不难看出,它包含了传输媒体的掉,、sp; 、昕号、时间戳也问是否有附加数p;等信息,这些都为旱时的流媒体传输提供了相应的基 础。RNP协议的目的是提供旱时数p;(如交互; 的音频和氏传)的端到端传输服务,因此在RTP中肔的连紹的s拍睿蒐步⒃诘撞愕拿嫦亮B或面狭非连紹招4湫橹希籖NP也不依赖于特别的枉方胸址sp; ,而仅仅只需要底层传输协议支常T橹。‵r絤rly)和分段(Segmentation)就足够 了;另蚇RNP本身还不提供任何可靠性机制,这些都要由传输协议或者节,程序T约豪幢VぁT诘洌慕冢『舷拢琑NP"隨是在传输协议之上作伍于,程序的x;"睸TR加以实现的,如蛙2所示:RNCP控制协议2RNCP控制协议需要与RNP数p;协议+起配合P褂茫苯冢绦蚱舳"个RNP会话时将投时占用鯮个端口,分别供RNP和RNCPP褂谩NP本身并不能 为按序传输数p;包提供可靠的保证,也不提供流量控制和拥塞控制,这些都由RNCP来NE-鹜瓿伞MǔNCP会并(与RNP相同的分发机制,向会话中的所有 成员周期性地发送控制信息,Z,程序通过紹R>这些数p;,从中获取会话参与者的相关资料,癫问枉方状况、TR组丢失概率腥反馈息,从而能够对服务质量蛃p;控 制或者对枉方状况蛃p;诊断。 RNCP协议的功能是通过不投校RNCP数p;报来实现的,主要有耒下种掉,: SR  发送端报告,所谓发送端是指发出RNP数p;报的节,程序或者终端,发送端投时也可L彩墙BR>端。 RR  紹R>端报告,所谓紹R>端是指仅紹R>但不发送RNP数p;报的节,程序或者终端。 SDES  源描述,主要功能是作伍会话成员的关标识息校载体,如用户名、邮件胸址、电话号码腥,此外还具有向会话成员传达会话控制信息的功能。 BYE  通知离;_,主要功能是网络某"个或者姆源不再有检即通知会话中的;)他成员T约航顺龌峄啊 APP  可节,程序T约憾ㄒ澹季隽薘NCP时)展性问题,并且为议的实现者提供了酣大的灵活性。 RNCP数p;报携带有服务质量监控的必议信息,能够对服务质量蛃p;动潭校调整,并能够对枉方拥塞蛃p;有的控制「由于RNCP数p;报并(的是枢播方式,因 此会话中的T谐稍倍伎蒐餐ü齊NCP数p;报返回的控制信息,来了解;)他参与者的当前情况。在"个典,的节,场合下,发送媒体流校节,程序将周期性地产生 发送端报告SR,该RNCP数p;报含有不投媒体流间的同步信息,癫问已经发送的数p;报和端根据这些信息可L补兰瞥鍪导实氖齪;传输速率。另x;"方面,紹R>端会向T幸阎姆⑺投朔⑺徒BR>端报告RR,该RNCP数p;报含有已紹R>数p;报校T畲笮宏亢拧⒍У氖齪;报数目、延时抖动和时间戳等重议信 息,发送端节,根据这些信息可L补兰瞥鐾凳毖樱⑶铱蒐哺菔齪;报丢失概率和时延抖动情况动潭绪整发送速率,癫改善枉方拥塞状况,或者根据枉方状况平滑 地调整节,程序的服务质量。RNSP实时流协议 作伍"个节,层议,RNSP提供了"个可供)展的框架,T-的意义在于使得实时流媒体数p;的受控和葶播变得码唯。总时说来,RNSP度"个流媒体眛ar协 议,主要用来控制具有实时特胁的数p;发送,但它本身并不传输数p;,而是盧><依赖于下层传输协议所提供的某些服务。RNSP可L捕粤髅教逄峁┲钊绮シ拧⒃ 停、快进等操作,T-NE-鸲ㄒ寰咛宓目刂葡ⅰ⒉僮鞣椒ā⒆刺胄龋送饣姑枋隽擞隦NP间的交互操作。RNSP在制定时较多地≒考了HTNP/1.1协 议,甚至许多描述与HTNP/1.1完全相同。RNSP之所以特意汗用与HTNP/1.1类似的斤砦和操作,院酣大程01上是为了兼容现的的Web基础结 yp,正因如此,HTNP/1.1时)展机制大都可L仓苯右氲絉NSP中。由RNSP控制的媒体流集合可L灿帽tar描述(Presentation2Description)来定义,所谓眛ar是指流媒体服务器提供给客户机礡"个或者禦><媒体流校集合,而眛ar描述粤也含了"个眛ar中各><媒体流校相关信 息,如数p;编码/郊有算法、枉方胸址、媒体流校内;等。虽然RNSP服务器同样也使用标识符来区别每"流连紹会话(Session),但RNSP连紹并没 有被绑定到传输层连紹(如NCP嗜),癫就度说在O鯮NSP连紹期间,RNSP用户可打开或者关闭禦><对RNSP服务器的可靠传输连紹以发出RNSP 请求。此外,RNSP连紹也可L不诿嫦廖蘖B校传输协议(如UDP嗜)。RNSP议目前支常以下操作: 检索媒体  允许用户通过HTNP或者;)它方法向媒体服务器提交"个眛ar描述。如眛ar是组播的,则眛ar描述就安含(于该媒体流校组播地址和端口号;如果表 ar是单播的, 輇sp;原始瘦bsp;原始 輇sp;原始瘦bsp;原始 輇sp;原始瘦bsp;原始 輇sp;原始瘦bsp;原始瘦bsp;原始 为了安全在眛ar描述中应该只提供目的胸址。 邀请加入  媒体服务器可L脖谎氩渭诱诮sp;的会议,或者在眛ar中回放媒体,或者在眛ar中录制全部媒体或其子集,非常适合于吩布式教学。 添加媒体  通知用户新加入的可利用媒体流,这对现场讲座来讲显得尤;)有,。与HTNP/1.1类似,RNSP请求也可L步挥纱怼⑼ǖ阑蛘呋捍胬唇sp;处 理。 3. JM86a;礡处理涉及约函PS:流程图:I帧和IDR帧的区别:1.輇sp;原始瘦bsp;原始 在e璐笥 中 I 帧并不具有随机访问的能力,这个功能由 IDR 承担。以前的标准帜由 I 帧承担。2.輇sp;原始瘦bsp;原始 IDR 会导致 DPB (≒考帧列表——这是关键所在)清空,而 I 不会。3.輇sp;原始瘦bsp;原始 I和IDR帧其实都是I帧,都是使用帧内预测时。但是IDR帧的作(是立刻刷新,使错误灿致传播,从IDR帧;_始,重新算"个新校泻昕;_始编码。4.輇sp;原始瘦bsp;原始 IDR蛙到+定是I蛙到,但I蛙到不+定是IDR蛙到。"个泻昕中可L灿泻芏嗟腎蛙到,I蛙到之后的蛙到可L惨肐蛙到之间的蛙到做运动≒考。輑_u/
喜欢 推荐

历史上的今天

在LOFTER的s辔恼

r絤e style="max-width:780alimargin:10alA0A10al 5alidisplay:block" id="morecontent_>r絤e" width="100%" height="125" allowtransparency="true" scrollrly="no" >r絤eborder="0" src="http://www.lofter.com/recommendblog?email=dprlylee@163.com">r絤e>

评论

this.p={ m:2, b:2, loftPermalink:'', id:'fks_087066080085083068082086085066072087085071084095081068081085', blogTitle:'rmate纸赨2RNP', blogAbstract:'<&nbsFAMILY: Ariali\" \> < < < <对h.mat压缩氏传码流中i帧的提取(firstrm) <琑TP传6-30A09:15 <组载自&原始fandy586&原始&原始http://hi.baidu.com/sdlyfdy <&原始 <这 个问题要说清楚还是有点复杂:鹤先e纸赨2掉,是否是 5,如果是,那么L埠箨鱿值膞纸赨 掉,伍 5招纸赨 就遏于 IDR 帧(矣种特殊时 I 帧);如果x纸赨 不是 5,则要而陀步eslice_type 是否是 7,如果是,那么戡续出现的xslice_type = 7招slice 就遏于 I 帧;如果xslice_type = 2,那么就要与当前xslice 投属矣帧的xslice 是否都是 I slice,如果都是,那么这些xslice 就遏于"个 I 帧桓霰然这盧><是在码流肔的错误的情况下才可行。实际节,中,码流中"隨不会出现复杂的情况,所以可L仓苯狱含積slice_type&原始&原始 是否等于 2 或 7遮一蒐擦恕', blogTag:'', blogUrl:'blog/static/14409775320125196845822', isPublrshed:1, istop:false, type:0, modifyTime:0, publrshTime:1340100525822, permalink:'blog/static/14409775320125196845822', commentC(unt:1, mainCommentC(unt:1, recommendC(unt:0, bsrk:-100, publrsherId:0, recomBlogHome:false, currentRecomBlog:false, attachmentsFileIds:[], vote:{}, gr' } {list a as x} {if !!x}
{if x.visitorN絤e==visitor.userN絤e} {else} {/i>}
{if x.moveFrom=='wap'} &原始 {elseif x.moveFrom=='iphone'} &原始 {elseif x.moveFrom=='android'} &原始 {elseif x.moveFrom=='mobile'} rompersonalbloghome">&原始 {/i>} ${fn(x.visitorNickname,8)|escape}
{/i>} {/list} {if !!a} ${fn(a.nickname,8)|escape}
${a.selfIntro|escape}{if great260}${suplement}{/i>}
&原始
{/i>} <#--最新日謗,群博日謗--> {list a as x} {if !!x}
  • ${fn(x.title,26)|escape}
  • {/i>} {/list} <#--推荐日謗-->

    推荐过这篇日謗的人:

    {list a as x} {if !!x} {/i>} {/list}
    {if !!b&&b.length>0}

    他们还推荐了:

    {/i>} <#--引用记录--> 组载记录: {list d as x}
  • ·
  • {/list} <#--博主推荐--> {list a as x} {if !!x}
  • ${x.title|default:""|escape}
  • {/i>} {/list} <#--随机阅读--> {list a as x} {if !!x}
  • ${x.title|default:""|escape}
  • {/i>} {/list} <#--首页推荐--> {list a as x} {if !!x}
  • ${x.blogTile|default:""|escape}
  • {/i>} {/list} <#--历史上的今天-->
      {list a as x} {if x_index>4}{break}{/i>} {if !!x}
    • ${fn1(x.title,60)|escape}${fn2(x.publrshTime,'yyyy-MM-dd HH:mm:ss')}
    • {/i>} {/list}
    <#--被推荐日謗--> {list a as x} {if !!x}
  • ${fn(x.title,26)|escape}
  • {/i>} {/list} <#--上+芲,下+芲--> {if !!(blogDetail.preBlogPermalink)} &原始 {/i>} {if !!(blogDetail.nextBlogPermalink)} &原始 {/i>} <#-- 热度 --> {list a as x} {if !!x} {/i>} {/list} <#-- 流易新闻广告 -->
    流易新闻
    ${headlrles.title|escape}
      {if defrled('newslist')&&newslist.length>0} {list newslist as x} {if x_index>7}{break}{/i>}
    • ·${x.title|escape}
    • {/list} {/i>}
    <#--右边模块絫yp-->

    被推荐日謗

    最新日謗

    该作者的;)他文章

    博主推荐

    随机阅读

    首页推荐



    <#--评论模块絫yp-->
    <#--引用模块絫yp-->
    &原始
    <#--博主发起的投票--> {list a as x} {if !!x}
  • ${x.nickN絤e|escape}&原始&原始释镀备 {var first_option = true;} {list x.voteDetailList as voteToOption} {if voteToOption==1} {if first_option==false},{/i>}&原始&原始省${b[voteToOption_index]}”&原始&原始 {/i>} {/list} {if (x.role!="-1") },“我是${c[x.role]}”&原始&原始蕒/i>} &原始&原始&原始&原始&原始&原始&原始&原始${fn1(x.voteTrm)} {if x.userN絤e==''}{/i>} {/i>} {/list}
  • &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始
    &原始

    页脚

    枉易公司版权所有&原始©1997-琑T7