rtp文章转载集合

这里主要转载了rtp的一些文章；

卸载前面，有时间可以看 RFC3550 RFC3984（英文版），翻译的中文版可以快速了解用；

https://tools.ietf.org/html/rfc3550

 

RFC的所有英文文章：

http://www.faqs.org/rfcs/

 

 

 

（1）维基百科对RTP的介绍：

   http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

 

（2）维基百科对流媒体的介绍：

   http://en.wikipedia.org/wiki/Streaming_media

 

（3）stackoverflows论坛关于RTP vs TCP的讨论

   http://stackoverflow.com/questions/361943/why-does-rtp-use-udp-instead-of-tcp

 

（4）关于RTP的负载类型和时间戳的讲解

   http://ticktick.blog.51cto.com/823160/350142

 

（5） RTP FAQ

   Some Frequently Asked Questions about RTP

 

 

 

 

 

《谈谈RTP传输中的负载类型和时间戳》

 

最近被RTP的负载类型和时间戳搞郁闷了，一个问题调试了近一周，终于圆满解决，回头看看，发现其实主要原因还是自己没有真正地搞清楚RTP协议中负载类型和时间戳的含义。虽然做RTP传输，有着Jrtplib和Ortp这两个强大的库支持，一个是c++接口，一个是c语言接口，各有各的特点，各有各的应用环境，但是仅仅有库就能解决一切问题吗？可能仿照着一些例子程序，你能够完成主要的功能，但一旦问题发生了，不清楚原理你是很难定位和解决问题的，所以在此，用我的经验劝劝大家，磨刀不误砍柴工，做应用还是先把原理搞清楚再动手吧……
    看这篇文章之前，首先你应该知道什么是RTP协议，可以去看RTP协议原文（RFC3550协议），也可以看一些网友对RTP协议的讲解的文章，很多，这里我提供一篇我个人觉得写得还不错的：http://blog.csdn.net/bripengandre/archive/2008/04/01/2238818.aspx 。

   好，下面言归正传，首先谈谈RTP传输中的负载类型吧。

    首先，看RTP协议包头的格式：
          

    10~16 Bit为PT域，指的就是负载类型（PayLoad），负载类型定义了RTP负载的格式，协议原文说该域由具体应用决定其解释。
    目前，负载类型主要用来告诉接收端（或者播放器）传输的是哪种类型的媒体（例如G.729，H.264，MPEG-4等），这样接收端（或者播放器）才知道了数据流的格式，才会调用适当的编解码器去解码或者播放，这就是负载类型的主要作用。
    就ORTP库（本文用的是ortp-0.9.1）而言，负载类型定义如下：
        

    每一种负载类型都有着其独特的参数，这里基本上涵盖了当前主流的一些媒体类型，例如pcmu 、g.729、h.263（很奇怪，竟然没有定义h.264，注：新版本已经添加了对h.264的支持）、mpeg-4等等。Jrtplib库应该也有相类似的定义，你可以去找找源码，在此我就不再赘述了。

    在ORTP库和JRTplib库中，都提供了设置RTP负载类型的函数，千万要记得根据实际的应用进行设置，我就是当时没有注意，使用ORTP默认的pcmu音频的负载类型，传输H.264编码的视频数据，结果传输中一直有问题，困扰我好久好久。

    好了，再说说RTP的时间戳吧。

    首先，了解几个基本概念：

    时间戳单位：时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是为了是时间戳单位更为精准。比如说一个音频的采样频率为8000Hz，那么我们可以把时间戳单位设为1 / 8000。
    时间戳增量：相邻两个RTP包之间的时间差（以时间戳单位为基准）。
    采样频率：  每秒钟抽取样本的次数，例如音频的采样率一般为8000Hz
    帧率：      每秒传输或者显示帧数，例如25f/s
    
    再看看RTP时间戳课本中的定义：

    RTP包头的第2个32Bit即为RTP包的时间戳，Time Stamp ，占32位。
    时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使是没有信号发送时，时间戳的数值也要随时间不断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块，从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。
    在RTP协议中并没有规定时间戳的粒度，这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳，以强调这种时间戳的粒度取决于信号的类型。例如，对于8kHz采样的话音信号，若每隔20ms构成一个数据块，则一个数据块中包含有160个样本（0.02×8000=160）。因此每发送一个RTP分组，其时间戳的值就增加160。

    官方的解释看懂没？没看懂？没关系，我刚开始也没看懂，那就听我的解释吧。

    首先，时间戳就是一个值，用来反映某个数据块的产生（采集）时间点的，后采集的数据块的时间戳肯定是大于先采集的数据块的。有了这样一个时间戳，就可以标记数据块的先后顺序。
    第二，在实时流传输中，数据采集后立刻传递到RTP模块进行发送，那么，其实，数据块的采集时间戳就直接作为RTP包的时间戳。
    第三，如果用RTP来传输固定的文件，则这个时间戳就是读文件的时间点，依次递增。这个不再我们当前的讨论范围内，暂时不考虑。
    第四，时间戳的单位采用的是采样频率的倒数，例如采样频率为8000Hz时，时间戳的单位为1 / 8000 ，在Jrtplib库中，有设置时间戳单位的函数接口，而ORTP库中根据负载类型直接给定了时间戳的单位（音频负载1/8000，视频负载1/90000）
    第五，时间戳增量是指两个RTP包之间的时间间隔，详细点说，就是发送第二个RTP包相距发送第一个RTP包时的时间间隔（单位是时间戳单位）。
    如果采样频率为90000Hz，则由上面讨论可知，时间戳单位为1/90000，我们就假设1s钟被划分了90000个时间块，那么，如果每秒发送25帧，那么，每一个帧的发送占多少个时间块呢？当然是 90000/25 = 3600。因此，我们根据定义“时间戳增量是发送第二个RTP包相距发送第一个RTP包时的时间间隔”，故时间戳增量应该为3600。

 

      【补充】：最近思考了一下，又有了新的体会和解释，可能对大家更容易地去理解这个时间戳增量会有所帮助，补充在下面吧：

 

       其实，网络发送重点关注的是流量的平衡，即均匀地利用网络带宽，为了实现这一点，需要满足：数据采集的速率与数据网络传输的速率尽量保持一致。时间戳增量的设置影响的是RTP包的网络传输的速率，时间戳增量越小，发送速度越快。

 

      下面再进一步解释一下时间戳增量是怎么计算出来的：

 

      对于PAL制式的视频而言，每秒摄像头会采集 25 帧 数据，那么，每采集到 1帧 耗时 1/25 s ，如果我们设计为1个RTP包只包含1帧数据，并且一次发送1帧，那么，要想网络流量均匀，则时间戳增量应该设计为 1/25 s .  而在一般的RTP协议的实现中，时间戳单位不是 秒（s），而约定为采样频率的倒数，由于一般视频的采样频率是 90000，故时间戳单位为 1/90000 s，因此，实际的时间戳增量 = 时间戳增量 ( 1/25 s ) / 时间戳单位(1/90000 s) = 3600  

    在Jrtplib中好像不需要自己管理时间戳的递增，由库内部管理。但在ORTP中每次数据的发送都需要自己传入时间戳的值，即自己需要每次发完一个RTP包后，累加时间戳增量，不是很方便，这就需要自己对RTP的时间戳有比较深刻地理解，我刚开始就是因为没搞清楚，随时设置时间戳增量导致传输一直有问题，困扰我好久。

    好了，关于RTP的负载类型和时间戳的介绍就到这里了，这次通过解决RTP传输中的问题学到了不少知识，在此分享希望对大家有用。有说得不正确的地方欢迎高手指教，也可以来信交流：lujun.hust@gmail.com

 

 

 

最近被RTP的负载类型和时间戳搞郁闷了，一个问题调试了近一周，终于圆满解决，回头看看，发现其实主要原因还是自己没有真正地搞清楚RTP协议中负载类型和时间戳的含义。虽然做RTP传输，有着Jrtplib和Ortp这两个强大的库支持，一个是c++接口，一个是c语言接口，各有各的特点，各有各的应用环境，但是仅仅有库就能解决一切问题吗？可能仿照着一些例子程序，你能够完成主要的功能，但一旦问题发生了，不清楚原理你是很难定位和解决问题的，所以在此，用我的经验劝劝大家，磨刀不误砍柴工，做应用还是先把原理搞清楚再动手吧……
    看这篇文章之前，首先你应该知道什么是RTP协议，可以去看RTP协议原文（RFC3550协议），也可以看一些网友对RTP协议的讲解的文章，很多，这里我提供一篇我个人觉得写得还不错的：http://blog.csdn.net/bripengandre/archive/2008/04/01/2238818.aspx 。

   好，下面言归正传，首先谈谈RTP传输中的负载类型吧。

    首先，看RTP协议包头的格式：
          

    10~16 Bit为PT域，指的就是负载类型（PayLoad），负载类型定义了RTP负载的格式，协议原文说该域由具体应用决定其解释。
    目前，负载类型主要用来告诉接收端（或者播放器）传输的是哪种类型的媒体（例如G.729，H.264，MPEG-4等），这样接收端（或者播放器）才知道了数据流的格式，才会调用适当的编解码器去解码或者播放，这就是负载类型的主要作用。
    就ORTP库（本文用的是ortp-0.9.1）而言，负载类型定义如下：
        

    每一种负载类型都有着其独特的参数，这里基本上涵盖了当前主流的一些媒体类型，例如pcmu 、g.729、h.263（很奇怪，竟然没有定义h.264，注：新版本已经添加了对h.264的支持）、mpeg-4等等。Jrtplib库应该也有相类似的定义，你可以去找找源码，在此我就不再赘述了。

    在ORTP库和JRTplib库中，都提供了设置RTP负载类型的函数，千万要记得根据实际的应用进行设置，我就是当时没有注意，使用ORTP默认的pcmu音频的负载类型，传输H.264编码的视频数据，结果传输中一直有问题，困扰我好久好久。

    好了，再说说RTP的时间戳吧。

    首先，了解几个基本概念：

    时间戳单位：时间戳计算的单位不是秒之类的单位，而是由采样频率所代替的单位，这样做的目的就是为了是时间戳单位更为精准。比如说一个音频的采样频率为8000Hz，那么我们可以把时间戳单位设为1 / 8000。
    时间戳增量：相邻两个RTP包之间的时间差（以时间戳单位为基准）。
    采样频率：  每秒钟抽取样本的次数，例如音频的采样率一般为8000Hz
    帧率：      每秒传输或者显示帧数，例如25f/s
    
    再看看RTP时间戳课本中的定义：

    RTP包头的第2个32Bit即为RTP包的时间戳，Time Stamp ，占32位。
    时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使是没有信号发送时，时间戳的数值也要随时间不断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块，从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。
    在RTP协议中并没有规定时间戳的粒度，这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳，以强调这种时间戳的粒度取决于信号的类型。例如，对于8kHz采样的话音信号，若每隔20ms构成一个数据块，则一个数据块中包含有160个样本（0.02×8000=160）。因此每发送一个RTP分组，其时间戳的值就增加160。

    官方的解释看懂没？没看懂？没关系，我刚开始也没看懂，那就听我的解释吧。

    首先，时间戳就是一个值，用来反映某个数据块的产生（采集）时间点的，后采集的数据块的时间戳肯定是大于先采集的数据块的。有了这样一个时间戳，就可以标记数据块的先后顺序。
    第二，在实时流传输中，数据采集后立刻传递到RTP模块进行发送，那么，其实，数据块的采集时间戳就直接作为RTP包的时间戳。
    第三，如果用RTP来传输固定的文件，则这个时间戳就是读文件的时间点，依次递增。这个不再我们当前的讨论范围内，暂时不考虑。
    第四，时间戳的单位采用的是采样频率的倒数，例如采样频率为8000Hz时，时间戳的单位为1 / 8000 ，在Jrtplib库中，有设置时间戳单位的函数接口，而ORTP库中根据负载类型直接给定了时间戳的单位（音频负载1/8000，视频负载1/90000）
    第五，时间戳增量是指两个RTP包之间的时间间隔，详细点说，就是发送第二个RTP包相距发送第一个RTP包时的时间间隔（单位是时间戳单位）。
    如果采样频率为90000Hz，则由上面讨论可知，时间戳单位为1/90000，我们就假设1s钟被划分了90000个时间块，那么，如果每秒发送25帧，那么，每一个帧的发送占多少个时间块呢？当然是 90000/25 = 3600。因此，我们根据定义“时间戳增量是发送第二个RTP包相距发送第一个RTP包时的时间间隔”，故时间戳增量应该为3600。

 

      【补充】：最近思考了一下，又有了新的体会和解释，可能对大家更容易地去理解这个时间戳增量会有所帮助，补充在下面吧：

 

       其实，网络发送重点关注的是流量的平衡，即均匀地利用网络带宽，为了实现这一点，需要满足：数据采集的速率与数据网络传输的速率尽量保持一致。时间戳增量的设置影响的是RTP包的网络传输的速率，时间戳增量越小，发送速度越快。

 

      下面再进一步解释一下时间戳增量是怎么计算出来的：

 

      对于PAL制式的视频而言，每秒摄像头会采集 25 帧 数据，那么，每采集到 1帧 耗时 1/25 s ，如果我们设计为1个RTP包只包含1帧数据，并且一次发送1帧，那么，要想网络流量均匀，则时间戳增量应该设计为 1/25 s .  而在一般的RTP协议的实现中，时间戳单位不是 秒（s），而约定为采样频率的倒数，由于一般视频的采样频率是 90000，故时间戳单位为 1/90000 s，因此，实际的时间戳增量 = 时间戳增量 ( 1/25 s ) / 时间戳单位(1/90000 s) = 3600  

    在Jrtplib中好像不需要自己管理时间戳的递增，由库内部管理。但在ORTP中每次数据的发送都需要自己传入时间戳的值，即自己需要每次发完一个RTP包后，累加时间戳增量，不是很方便，这就需要自己对RTP的时间戳有比较深刻地理解，我刚开始就是因为没搞清楚，随时设置时间戳增量导致传输一直有问题，困扰我好久。

    好了，关于RTP的负载类型和时间戳的介绍就到这里了，这次通过解决RTP传输中的问题学到了不少知识，在此分享希望对大家有用。有说得不正确的地方欢迎高手指教，也可以来信交流：lujun.hust@gmail.com

 

 

 

 

 

 

 

 

@http://blog.chinaunix.NET/uid-24404030-id-2609484.html

 

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%5Fdavy/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%16，色度 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 /* equal to 0x03 */

} else

rbsp_byte[ NumBytesInRBSP++ ]

}

}

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

第二步的具体过程：



case1：有序字节流的封装



byte_stream_nal_unit( NumBytesInNALunit ) { 

while( next_bits( 24 ) != 0x000001 ) 

zero_byte /* equal to 0x00 */ 

if( more_data_in_byte_stream( ) ) { 

start_code_prefix_one_3bytes /* equal to 0x000001 */ nal_unit( NumBytesInNALunit ) 

} 

} 

类似H.320和MPEG-2/H.222.0等传输系统，传输NAL作为有序连续字节或比特流，同时要依靠数据本身识别NAL单元边界。在这样的应用系 统中，H.264/AVC规范定义了字节流格式，每个NAL单元前面增加3个字节的前缀，即同步字节。在比特流应用中，每个图像需要增加一个附加字节作为 边界定位。还有一种可选特性，在字节流中增加附加数据，用做扩充发送数据量，能实现快速边界定位，恢复同步

Case2：IP网络的RTP打包封装

分组打包的规则 

    (1)额外开销要少，使MTU尺寸在100～64k字节范围都可以； 

    (2)不用对分组内的数据解码就可以判别该分组的重要性； 

    (3)载荷规范应当保证不用解码就可识别由于其他的比特丢失而造成的分组不可解码； 

    (4)支持将NALU分割成多个RTP分组； 

  　(5)支持将多个NALU汇集在一个RTP分组中。 

    RTP的头标可以是NALU的头标，并可以实现以上的打包规则。 

    一个RTP分组里放入一个NALU，将NALU(包括同时作为载荷头标的NALU头)放入RTP的载荷中，设置RTP头标值。为了避免IP层对大分组的再 一次分割，片分组的大小一般都要小于MTU尺寸。由于包传送的路径不同，解码端要重新对片分组排序，RTP包含的次序信息可以用来解决这一问题。 

NALU分割 

    对于预先已经编码的内容，NALU可能大于MTU尺寸的限制。虽然IP层的分割可以使数据块小于64千字节，但无法在应用层实现保护，从而降低了非等重保 护方案的效果。由于UDP数据包小于64千字节，而且一个片的长度对某些应用场合来说太小，所以应用层打包是RTP打包方案的一部分。 

    新的讨论方案(IETF)应当符合以下特征： 

    (1)NALU的分块以按RTP次序号升序传输； 

    (2)能够标记第一个和最后一个NALU分块； 

    (3)可以检测丢失的分块。 

NALU合并 

    一些NALU如SEI、参数集等非常小，将它们合并在一起有利于减少头标开销。已有两种集合分组： 

    (1)单一时间集合分组(STAP)，按时间戳进行组合； 

    (2)多时间集合分组(MTAP)，不同时间戳也可以组合。

NAL规范视频数据的格式，主要是提供头部信息，以适合各种媒体的传输和存储。NAL支持各种网络，包括：

1．任何使用RTP/IP协议的实时有线和无线Internet 服务

2．作为MP4文件存储和多媒体信息文件服务

3．MPEG-2系统

4．其它网 

NAL规定一种通用的格式，既适合面向包传输，也适合流传送。实际上，包传输和流传输的方式是相同的，不同之处是传输前面增加了一个起始码前缀

在类似Internet/RTP面向包传送协议系统中，包结构中包含包边界识别字节，在这种情况下，不需要同步字节。

NAL单元分为VCL和非VCL两种

VCL NAL单元包含视频图像采样信息，

非VCL包含各种有关的附加信息，例如参数集（头部信息，应用到大量的VCL NAL单元）、提高性能的附加信息、定时信息等

参数集：

参数集是很少变化的信息，用于大量VCL NAL单元的解码，分为两种类型：

1．序列参数集，作用于一串连续的视频图像，即视频序列。

   两个IDR图像之间为序列参数集。IDR和I帧的区别见下面。

2．  图像参数集，作用于视频序列中的一个或多个个别的图像

序列和图像参数集机制，减少了重复参数的传送，每个VCL NAL单元包含一个标识，指

向有关的图像参数集，每个图像参数集包含一个标识，指向有关的序列参数集的内容

因此，只用少数的指针信息，引用大量的参数，大大减少每个VCL NAL单元重复传送的信息。

序列和图像参数集可以在发送VCL NAL单元以前发送，并且重复传送，大大提高纠错能力。序列和图像参数集可以在“带内”，也可以用更为可靠的其他“带外”通道传送。

存储单元：

一组指定格式的NAL单元称为存储单元，每个存储单元对应一个图像。每个存储单元包含一组VCL NAL单元，组成一个主编码图像，VCL NAL单元由表示视频图像采样的像条所组成。存储单元前面可以加一个前缀，分界存储单元，附加增强信息（SEI）（如图像定时信息）也可以放在主编码图像 的前面。主编码图像后附加的VCL NAL单元，包含同一图像的冗余表示，称为冗余编码图像，当主编码图像数据丢失或损坏时，可用冗余编码图像解码。

编码视频序列

一个编码视频序列由一串连续的存储单元组成，使用同一序列参数集。每个视频序列可独立解码。编码序列的开始是即时刷新存储单元（IDR）。IDR是一个I帧图像，表示后面的图像不用参考以前的图像。一个NAL单元流可包含一个或更多的编码视频序列。

RTP协议：

实时传输协议（Real-time Transport Protocol，RTP）是在Internet上处理多媒体数据流的一种网络协议，利用它能够在一对一（单播）或者一对多（multicast，多播） 的网络环境中实现传流媒体数据的实时传输。RTP通常使用UDP来进行多媒体数据的传输，但如果需要的话可以使用TCP或者ATM等其它协议，整个RTP 协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议。实时流协议（Real Time Streaming Protocol， RTSP）最早由Real Networks和Netscape公司共同提出，它位于RTP和RTCP之上，其目的是希望通过IP网络有效地传输多媒体数据。

RTP数据协议 

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示： 

其中比较重要的几个域及其意义如下： 

CSRC记数（CC）　　表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存 在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者 的语音数据组合为一个RTP数据源。 

负载类型（PT）　　标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。 

  序列号　　用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。 

  时间戳　记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自 己的事情。从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应 的基础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非 连接的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足 够了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序 的一部分加以实现的，如图2所示：

RTCP控制协议 

RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能 为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有 成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控 制或者对网络状况进行诊断。 

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型： 

SR　　发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。 

RR　　接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。 

SDES　　源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。 

BYE　　通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。 

APP　　由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。 

RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。

在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节 的计数，接收端根据这些信息可以估计出实际的数据传输速率。另一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报 的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动 态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑地调整应用程序的服务质量。

RTSP实时流协议 

作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协 议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂 停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作。

RTSP在制定时较多地参考了HTTP/1.1协议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操 作，在很大程度上是为了兼容现有的Web基础结构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。

由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信 息，如数据编码/解码算法、网络地址、媒体流的内容等。

虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没有被绑定到传输层连接（如TCP等），也就是说在整个 RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。

RTSP协议目前支持以下操作： 

检索媒体　　允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表示是单播的，              为了安全在表示描述中应该只提供目的地址。 

邀请加入　　媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。 

添加媒体　　通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/1.1类似，RTSP请求也可以交由代理、通道或者缓存来进行处理。 

3． JM86中的处理

涉及的函数：

流程图：



I帧和IDR帧的区别：

1．  在 H.264 中 I 帧并不具有随机访问的能力，这个功能由 IDR 承担。以前的标准中由 I 帧承担。

2．  IDR 会导致 DPB （参考帧列表——这是关键所在）清空，而 I 不会。

3．  I和IDR帧其实都是I帧,都是使用帧内预测的。但是IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。

4．  IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。

 

 

 

 

 

 

 

 

 

 

 

 

图像编码中的小白问题sps ,pps ,nalu ,frame ,silce ect....

 

H.264中NAL、Slice与frame意思及相互关系

NAL nal_unit_type中的1（非IDR图像的编码条带）、2（编码条带数据分割块A）、3（编码条带数据分割块B）、4（编码条带数据分割块C）、5（IDR图像的编码条带）种类型

与 
Slice种的三种编码模式：I_slice、P_slice、B_slice

还有frame的3种类型：I frame、P frame、 B frame之间有什么映射关系么？

最后，NAL nal_unit_type中的6（SEI）、7（SPS）、8（PPS）属于什么帧呢？

不好意思，文档看得头晕晕的了，问题比较多~~~ 
PS：偶是新人 没多少分，要是哪位达人帮忙下的话  我就给我所有的分，好像只有十几分

1 frame的数据可以分为多个slice. 
每个slice中的数据，在帧内预测只用到自己slice的数据， 与其他slice 数据没有依赖关系。 
NAL 是用来将编码的数据进行大包的。 比如，每一个slice 数据可以放在NAL 包中。 
I frame 是自己独立编码，不依赖于其他frame 数据。 
P frame 依赖 I frame 数据。 
B frame 依赖 I frame, P frame 或其他 B frame 数据。

建议楼主看一点视频编码的书吧， 自己看标准还是很难懂的。

那NAL nal_unit_type中的哪几种类型是I frame，现在只能确定nal_unit_type==5（IDR图像的编码条带）是I frame

sps、pps、SEI算不算I frame呢？ 还有 属于编码条带分割的DPA、DPB、DPC呢？

能给个从视频流中提取I frame 和P frame的方法么？

谢谢楼上的回复，我也翻了两三本视频的书籍，感觉都是一个样的，都很少说到点的。楼主能推荐一两本好点的视频书籍么？

没人回答么？？

直接给你代码吧 ：）

// 
// H.264 NAL type 
enum H264NALTYPE{ 
H264NT_NAL = 0, 
H264NT_SLICE, 
H264NT_SLICE_DPA, 
H264NT_SLICE_DPB, 
H264NT_SLICE_DPC, 
H264NT_SLICE_IDR, 
H264NT_SEI, 
H264NT_SPS, 
H264NT_PPS, 
}; 
int H264GetNALType(LPVOID pBSBuf, const LONG nBSLen) 
{ 
if ( nBSLen < 5 )  // 不完整的NAL单元 
return H264NT_NAL;

UINT8* pBS = (UINT8 *)pBSBuf; 
ULONG nType = pBS[4] & 0×1F;  // NAL类型在固定的位置上  
if ( nType <= H264NT_PPS ) 
return nType;

return 0; 
}

其中 H264NT_SLICE_IDR 是关键帧，H264NT_SLICE 是P帧

一个frame是可以分割成多个Slice来编码的，而一个Slice编码之后被打包进一个NAL单元，不过NAL单元除了容纳Slice编码的码流外，还可以容纳其他数据，比如序列参数集SPS。

1、NAL、Slice与frame意思及相互关系

NAL指网络提取层，里面放一些与网络相关的信息 
Slice是片的意思，264中把图像分成一帧（frame）或两场（field），而帧又可以分成一个或几个片（Slilce）；片由宏块（MB）组成。宏块是编码处理的基本单元。

2、NAL nal_unit_type中的1（非IDR图像的编码条带）、2（编码条带数据分割块A）、3（编码条带数据分割块B）、4（编码条带数据分割块C）、5（IDR图像的编码条带）种类型 
与 Slice种的三种编码模式：I_slice、P_slice、B_slice 
NAL nal_unit_type 里的五种类型，代表接下来数据是表示啥信息的和具体如何分块。 
I_slice、P_slice、B_slice 表示I类型的片、P类型的片，B类型的片.其中I_slice为帧内预测模式编码；P_slice为单向预测编码或帧内模式；B_slice 中为双向预测或帧内模式。

3、还有frame的3种类型：I frame、P frame、 B frame之间有什么映射关系么？ 
I frame、P frame、 B frame关系同 I_slice、P_slice、B_slice，slice和frame区别在问题1中已经讲明白。

4、最后，NAL nal_unit_type中的6（SEI）、7（SPS）、8（PPS）属于什么帧呢？ 
NAL nal_unit_type 为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）不属于啥帧的概念。表示后面的数据信息为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）。

能给个从视频流中提取I frame 和P frame的方法么？ 
可以看slice中的头信息。

查找NAL起始码，然后读取NAL类型不就可以了吗

pBS[4] & 0×1F 

怎么是第5个字节的第五位啊  前面4字节分别是什么（值）？

NAL单元的第1个字节的低五位吧？

然后在问个问题，怎么在一段视频流中检测 NAL的开始和结束？

 

引用 5 楼 hugeice 的回复:
直接给你代码吧 ：）

 

// 
// H.264 NAL type 
enum H264NALTYPE{ 
H264NT_NAL = 0, 
H264NT_SLICE, 
H264NT_SLICE_DPA, 
H264NT_SLICE_DPB, 
H264NT_SLICE_DPC, 
H264NT_SLICE_IDR, 
H264NT_SEI, 
H264NT_SPS, 
H264NT_PPS, 
}; 
int H264GetNALType(LPVOID pBSBuf, const LONG nBSLen) 
{ 
if ( nBSLen < 5 )  // 不完整的NAL单元… 

H.264视频流是以NAL单元传送的。。。但在一个NAL单元里面，可能既存放I-Slice（P-Slice或B-Slice），同事也可能存放图像的其他信息 
那么 是不是说 I frame， P frame，B frame是把收到的NAL单元中的VCL的信息先提取出，然后按内容进行I、P、B frame分类？

而我们只能通过NAL nal_unit_type来判别NAL单元中数据的类型哈~~~

====================================================================

 

 

 

《如何结合H.264标准看JM代码》这个web文件，大家都应该有了吧。不过，那个web文档是“H.264乐园”群中聊天的内容，因此看的不是很方便......我在开学来的时候看的时候，做了一些总结，希望与大家分享！不对的地方请指正！

 

1、一个sps后，有若干个pps吗？
      这主要又编码器决定，但JM代码中只有一个

 

2、标准中第二栏的C是什么意思？
    请看标准7.2--分类（在表中以C标记）表明了片数据被划分为三类片数据分割的情况。片数据A类分割包含所有的2类语法元素。片数据B类分割包含所有的3类语法元素。片数据C类分割包含所有的4类语法元素。其他类语法元素取值的含义未做规定。对于某些语法元素，使用一个垂直竖线表示其包含两类语法元素。在这种情况下，该语法元素将使用的分类值将在文本中进一步确定。

3、一个NALU对应一个片吗？
    这种说法不太准确，NALU 包括一个片、SPS、PPS、SEI等等

 

4、decode_one_frame()包括I、P、B

 

5、 case NALU_TYPE_SLICE:
      case NALU_TYPE_IDR:
      case NALU_TYPE_DPA
      case NALU_TYPE_DPB:
      case NALU_TYPE_DPC
      case NALU_TYPE_SEI:
      case NALU_TYPE_PPS
      case NALU_TYPE_SPS
      case NALU_TYPE_AUD:
      case NALU_TYPE_EOSEQ:
      case NALU_TYPE_EOSTREAM:
      case NALU_TYPE_FILL
     问题：什么时候进入哪个，有什么说明的文章或书么？
        答 ：进入哪个 case 是由从 NALU 头里解码出来的 nalu_type 决定的

 

6、解码器中的误码隐藏只对丢包有用，丢包之后，包的序号不连续，解码器一旦检测到包序号不连续就会将不连续地方的 ei_flag  置 1

 

7、字节流格式和RTP格式码流，具体的不同点有哪些?相关的资料哪里有?
      字节流格式主要用于文件存储，因此在该格式码流中 NALU 前面只有一个开始前缀，RTP格式码流因为需要进行网络传输， 因此 NALU 前面还有很多辅助信息

 

8、ｒｔｐ格式就是在字节流前加包头吗？
      不是，字节流=开始前缀+NALU，而 RTP 中没有 开始前缀

 

9、RTP中没有开始前缀，为什么还是要插03？
       防止伪起始码、、RTP完全可以不用起始码，或许是为了与字节流格式统一吧

 

10、NALU是对RBSP的封装。而RTP之类的是对NALU的封装。

 

11、为什么要分ＡＢＣ片？
        ——分ＡＢＣ片主要目的是为了对重要程度不同的数据进行不同程度的保护

 

12、baseline没有数据分割吧?
      baseline只是如何产生RBSP，如何封装NALU。具体如何传输，RTP之类只是一种方式，文件copy也是一种方式，那一般 baseline最多有多少参考帧？任意个。

 

13、解码profile_idc之后解码器要做什么工作?比如baseline不支持CABAC那么后面相应的位entropy_coding_mode_flag是不是就不存在了，如果存在，相抵触怎么办?
      当然不会执行 CABAC 的代码，编码器如果是编码 baseline ，那么码流中自然就不存在与 CABAC 相关的语法元素，例如  entropy_coding_mode_flag ，解码器解码 SPS ，得知码流是 baseline 后，自然也就不会去调用与 CABAC 相关的解码程 序，也就不会出错了。profile_idc 为 baseline ，active_pps->entropy_coding_mode_flag 就不会为 CABAC，，码流是 否是 baseline 并不是由多少个参考帧决定的

 

14、JM 进行 CAVLC 编码时候，对于 level = 8 的情况是采用 escape suffix 处理的，我修改代码将 level = 8 的情况采用无符号数表示，结果编码出来的码流与未修改完全一样

附：RBSP、SODB、EBSP三者的区别和联系！
        SODB：最原始的编码数据，没有任何附加数据
        RBSP：在 SODB 的基础上加了rbsp_stop_ont_bit（bit 值为 1）并用 0 按字节补位对齐
        EBSP：在 RBSP 的基础上增加了防止伪起始码字节（0X03）

       1、1 frame的数据可以分为多个slice.
       2、每个slice中的数据，在帧内预测只用到自己slice的数据， 与其他slice 数据没有依赖关系。
       3、NAL 是用来将编码的数据进行大包的。 比如，每一个slice 数据可以放在NAL 包中。
       4、I frame. 是自己独立编码，不依赖于其他frame. 数据。
            P frame. 依赖 I frame. 数据。
            B frame. 依赖 I frame, P frame. 或其他 B frame. 数据。

     一个frame是可以分割成多个Slice来编码的，而一个Slice编码之后被打包进一个NAL单元，不过NAL单元除了容纳Slice编码的码流外，还可以容纳其他数据，比如序列参数集SPS。

 

15、NAL、Slice与frame意思及相互关系

NAL指网络提取层，里面放一些与网络相关的信息
Slice是片的意思，264中把图像分成一帧（frame）或两场（field），而帧又可以分成一个或几个片（Slilce）；片由宏块（MB）组成。宏块是编码处理的基本单元。

 

16、NAL nal_unit_type中的1（非IDR图像的编码条带）、2（编码条带数据分割块A）、3（编码条带数据分割块B）、4（编码条带数据分割块C）、5（IDR图像的编码条带）种类型与 Slice种的三种编码模式：I_slice、P_slice、B_slice NAL nal_unit_type 里的五种类型，代表接下来数据是表示啥信息的和具体如何分块。I_slice、P_slice、B_slice 表示I类型的片、P类型的片，B类型的片.其中I_slice为帧内预测模式编码；P_slice为单向预测编码或帧内模式；B_slice 中为双向预测或帧内模式。

 

17、还有frame的3种类型：I frame、P frame、 B frame之间有什么映射关系么？
I frame、P frame、 B frame关系同 I_slice、P_slice、B_slice，slice和frame区别在问题1中已经讲明白。

 

18、最后，NAL nal_unit_type中的6（SEI）、7（SPS）、8（PPS）属于什么帧呢？
NAL nal_unit_type 为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）不属于啥帧的概念。表示后面的数据信息为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）。

========================================================

 

 

首先我觉得先要找相关书籍把基本原理搞懂，不要急于看标准和源代码。要知道什么是采样格式，什么是I、P、B，他们的原理是什么,了解CAVLC、CABAC熵编码的实现过程，一定要认认真真。这样各个主要模块攻克之后，你就可以结合标准和源代码一步一步的看下去。
 

    下面以解码过程为例说一下具体过程： 
 

        1、 过程：码流→NALU→RBSP。

 

 

如果是字节流的码流当然就首先要对字节流进行解析，这就要看附录 B 了，如何查找起始码和去除伪起始码（为什么有伪起始码呢？）；如果是 RTP 格式的码流，那就要按 RFC3984 来解析了（标准没有规定 RTP 格式码流的解析过程）；字节流解析完后提取出来的就是 NALU 了，对 NALU 的解析就要看第七章了。黑色的粗体字都是在码流中可能出现的语法元素，解码器的首要任务就是要对这些语法元素进行解析。对于这些码流中的语法元素我们要进行解析必须知道三个问题：
 

（1）、什么时候存在于码流中？这样我们才能知道当前解析的是哪个语法元素；
 

  （2）、采用什么样的熵编码方式？这样我们才能知道如何解析；
  （3）、含义是什么？这样我们才知道解析出来之后用来干什么。
 

NALU 的前面三个语法元素所组成的一个字节我们称为 NALU 头，其余部分（也就是语法表 7.3.1 中的其余部分）我们称为 NALU 体。对 NALU 体的解析要看 7.3.2 小节。因为 NALU 有很多种类型，所以要针对 NALU 的不同类型去解析 NALU 体（表 7-1 说明了不同 NALU 对应的语法表）。例如，如果当前的 NALU 是 SPS，那么当然就要看 7.3.1 小节；如果当前的 NALU 是 DPA，那么当然就要看 7.3.2.9.1 小节了；
         2、对于属于 VCL 的 NALU（哪些 NALU 是 VCL NALU 呢？如果你看了 nal_unit_type 的语义，你就应该知道），例如表 7-1 中类型为 5 的 NALU，根据表 7-1 我们知道 NALU 体的语法表是 7.3.2.8。而从 7.3.2.8 我们可以看到，对这种 NALU 的 NALU 体解析实际就是对片级语法进行解析。语法表 7.3.2.8 显示片级语法解析首先要解析 slice_header()（这种带括号的表示是另一个语法结构），那么 slice_header() 怎么解析呢？往下看，7.3.3 的所有内容都被第一行的 slice_header() 包括在内，所以 7.3.3 就是对 slice_header() 这个语法层的码流规定；
        3、按照语法表 7.3.2.8 解析完了 slice_header() 就该解析 slice_data() 了。下面以最常见的 I 帧（CAVLC 熵编码、非 MBAFF）的解析过程为例简单描述怎么继续读标准。这时在码流中出现的第一个 slice_data() 层的语法元素是语法表 7.3.4 中的 macroblock_layer()，也就是说直接到了宏块层的语法解析，那就要又要看 7.3.5 小节了；
      4、基于我们对编解码流程的了解，我们知道解码是一个预测值加残差得到重建图像的过程，那么我们下面的解码过程就要分成两步走了：首先，得到预测值；其次，得到残差。基于我们对 H.264 关键技术的了解，我们知道 intra 宏块（提醒：我们举的例子是 I 帧，因此解析的是 intra 宏块）的预测值是需要使用到预测模式的，所以我们需要解析语法表 7.3.5 中的 mb_pred(mb_type) 语法层，那么又去看 7.3.5.1 小节。按照 7.3.5.1 小节解析出宏块或块的预测方式后我们怎么计算预测值呢？去看标准 8.3 小节；得到预测值后我们继续按照语法表 7.3.5 解析语法元素直到 residual() 语法层，这就又要去看 7.3.5.3 小节；按照 7.3.5.3 小节解析出残差系数后我们如何把它还原成真实的残差呢？去看标准 8.5 小节；
        5、预测值和残差都有了，加起来就是解码图像了。解码的主要工作到此也算基本完成了。当然，上面的过程中还会用到标准其他章节的相关内容（例如，8.5 小节会用到 5.7 小节中定义的 InverseRasterScan）总体过程也就如此吧，详细内容要大家自己去认真的学习

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

H264—帧，片，参数集，NALU等概念

 

h264是一个编码压缩的格式，可以使用x264库进行编码，源码开放，可下载编译使用。

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

H.264 Codec

 

h264概念上区分视频编码层(VCL)和网络抽象层(NAL).

 

VCL包含Codec的信令处理功能;以及如转换，量化，运动补偿预测机制；以及循环过滤器。他遵从今天大多数视频codec的一般概念,基于宏快的编码器，使用基于运动补偿的图像间预测和残余信号的转换编码。

(NAL)编码器封装VCL编码器输出的片断到网络抽象层单元(NAL units),它适合于通过包网路传输或用于面向包的多路复用环境。

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

网络抽象层单元（NALU）类型

NAL单元类型字节格式如下： 
    
      +---------------+ 
      |0|1|2|3|4|5|6|7| 
      +-+-+-+-+-+-+-+-+ 
      |F|NRI|  Type   | 
      +---------------+ 
 
   NAL单元类型字节部件的语义在H.264规范中制定, 简要描述如下. 
 
   F: 1 bit 
      forbidden_zero_bit.  H.264规范声明设置为1指示语法违例。 
 
   NRI: 2 bits 
      nal_ref_idc.  00值指示NAL单元的不用于帧间图像预测的重构参考图像。这样的NAL单元可以被丢弃而不用冒参考 
      图像完整性的风险。大于0的值指示NAL单元的解码要求维护参考图像的完整性。 
 
   Type: 5 bits 
      nal_unit_type.  本部件指定NAL单元荷载类型定义在[1]的表 7-1中和本文后面。为了参考所有当前定义的NAL单元类型 
      和他们的语义

 

• 0：未规定

• 1：非IDR图像中不采用数据划分的片段

• 2：非IDR图像中A类数据划分片段

• 3：非IDR图像中B类数据划分片段

• 4：非IDR图像中C类数据划分片段

• 5：IDR图像的片段

• 6：补充增强信息（SEI）

• 7：序列参数集（SPS）

• 8：图像参数集（PPS）

• 9：分割符

• 10：序列结束符

• 11：流结束符

• 12：填充数据

• 13：序列参数集扩展

• 14：带前缀的NAL单元

• 15：子序列参数集

• 16 – 18：保留

• 19：不采用数据划分的辅助编码图像片段

• 20：编码片段扩展

• 21 – 23：保留

• 24 – 31：未规定

在实际的H264数据帧中，往往帧前面带有00 00 00 01 或 00 00 01分隔符，一般来说编码器编出的首帧数据为PPS与SPS，接着为IDR帧（关于IDR与I的区别http://blog.csdn.net/jammg/article/details/52357245）

 

比如，将rgb转换转换成yuv后（x264只支持将yuv编码压缩），使用x264编码器编码出的264文件前面一般是这样：

00 00 00 01 67 ....(sps)....... 00 00 00 01 68 .........(pps)....... 00 00 00 01 65 ......(IDR)...........

[由于NAL的语法中没有给出长度信息，实际的传输、存储系统需要增加额外的头实现各个NAL单元的定界。]

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

参数集概念(SPS/PPS)
 
   H.264一个非常基本的设计概念是产生自包含包, 使得如RFC2429的头重复或MPEG-4的头扩展编码（HEC）[11]机制变得不必要。 
   这是通过从媒体流解耦合不止一个片断的相对信息来实现的。高层meta信息应该可靠/异步的发送,事先不和包含片断包的RTP 
   包流发送。(对于没有通过带外传输信道发送本信息的应用，通过带内发送本信息也提供了手段)。高层参数的组合被称为参数集。 
   H.264规范包括两类参数集:顺序参数集和图像参数集。一个活动顺序参数集在一个编码视频序列中保持不变,一个活动图像参数集 
   在一个编码图像里保持不变。顺序和图像参数集结构包含如图像大小，采用的可选的编码模式，宏块到片断组映射等信息。 
 
   为了改变图像参数(如图像大小)而不用同步传送参数集修改给片断包流,编码器和解码器可以维护不止一个顺序和图像参数集的 
   列表。每个片断头包含一个码字指示使用的顺序和图像参数集。 
 
   本机制允许从包流中解耦合参数集的传输,通过外部手段传输他们(即,作为能力交换的副作用),或通过一个(可靠或不可靠)控制协议 
   他们从没有被传送但是被应用设计规范修复甚至是可能的。

 

帧（frame）与 片(slice)

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

大小关系

对于 H.264中出现的一些概念从大到小排序依次是：序列、图像（大多时候称为帧，包括I,P,B帧）、片组、片（包括I,P,B片，SP片，SI片）、NALU、宏块、亚宏块、块、像素。

注：图像以序列为单位进行组织。

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

帧、NALU、片

（1）、在 H.264协议中图像是个集合概念，顶场、底场、帧都可以称为图像（本文图像概念时都是集合概念）。因此我们可以知道，对于H.264 协议来说，我们平常所熟悉的那些称呼，例如：I 帧、P 帧、B帧等等，实际上都是我们把图像这个概念具体化和细小化了。我们在 H.264里提到的“帧”通常就是指不分场的图像；
（2）、如果不采用FMO（灵活宏块排序） 机制，则一幅图像只有一个片组；
（3）、如果不使用多个片，则一个片组只有一个片；
（4）、如果不采用DP（数据分割）机制，则一个片就是一个NALU，一个 NALU 也就是一个片。

      否则，一个片由 三个 NALU 组成（即标准“表7-1”中 nal_unit_type 值为2、3、4 的三个 NALU 属于 一个片）；  

   2编码条带数据分割块A  slice_data_partition_a_layer_rbsp()

   3 编码条带数据分割块Bslice_data_partition_b_layer_rbsp( )

   4 编码条带数据分割块Cslice_data_partition_c_layer_rbsp( )
也即对应上面的：        
        H264NT_SLICE_DPA,
        H264NT_SLICE_DPB,
        H264NT_SLICE_DPC,

帧可以包含一个或多个片，片由宏块组成，宏块是编码处理的基本单元。

一幅图像由 1～N个片组组成，而每一个片组又由一个或若干个片组成一个片由一个NALU或三个NALU（假如有数据分割）组成。图像解码过程中总是按照片进行解码，然后按照片组将解码宏块重组成图像。从这种意义上讲，片实际是最大的解码单元。
-------------------------------------------------------------------------------------------------------------

 

I,P,B帧的依赖关系

I frame 是自己独立编码，不依赖于其他frame 数据。

P frame 依赖 I frame 数据。 

B frame 依赖 I frame, P frame 或其他 B frame 数据。

 

对应地，NAL nal_unit_type中的1（非IDR图像的编码条带）、2（编码条带数据分割块A）、3（编码条带数据分割块B）、4（编码条带数据分割块C）、5（IDR图像的编码条带）种类型 与 Slice种的三种编码模式：I_slice、P_slice、B_slice NAL nal_unit_type 里的五种类型，代表接下来数据是表示啥信息的和具体如何分块。 
I_slice、P_slice、B_slice 表示I类型的片、P类型的片，B类型的片.其中I_slice为帧内预测模式编码；P_slice为单向预测编码或帧内模式；B_slice 中为双向预测或帧内模式。

 

 

// H.264 NAL type
   enum H264NALTYPE
    {
        H264NT_NAL = 0,
        H264NT_SLICE, //P 帧
        H264NT_SLICE_DPA,
        H264NT_SLICE_DPB,
        H264NT_SLICE_DPC,
        H264NT_SLICE_IDR, // I 帧
        H264NT_SEI,
        H264NT_SPS,
        H264NT_PPS,
   };

//  0x00 0x00  0x00 0x01  0x65(0x45)   前四个字节为帧头，0x65  是关键帧

//0x00  0x00 0x01  0x65(0x45)  也为关键帧

H264GetNALType(unsigned char * pBSBuf, const int nBSLen)
{
if ( nBSLen < 5 )  // 不完整的NAL单元
   return H264NT_NAL;


unsigned char * pBS = (unsigned char *)pBSBuf;

int nType = pBS[4] & 0x1F;  // NAL类型在固定的位置上 
if ( nType <= H264NT_PPS )
    return nType;// nTYPE  为5  表示关键帧


return 0;
}

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

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 单元的类型

 

 

 

 

 

 

 

H.264 NAL层解析(0x00000001,编码,打包,NALU)

 

1．引言

H.264的主要目标：

1．高的视频压缩比

2．良好的网络亲和性

解决方案：

VCL  video codinglayer       视频编码层

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和0X00000001

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

如果NALU对应的Slice为一帧的开始，则用4字节表示，即0x00000001；否则用3字节表示，0x000001。 

 

解决方案：为了防止NAL内部出现0x000001的数据，h.264又提出'防止竞争 emulation prevention"机制，在编码完一个NAL时，如果检测出有连续两个0x00字节，就在后面插入一个0x03，则在NAL数据内肯定不会存在NAL起始码0x000001。当解码器在NAL内部检测到0x000003的数据，就把0x03抛弃，恢复原始数据。   
  0x000000  >>>>>>  0x00000300(结束码)

   0x000001 >>>>>>  0x00000301(起始码)

   0x000002 >>>>>>  0x00000302(保留)

   0x000003 >>>>>>  0x00000303(保证解码器正常工作)

 

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 单元的类型

 标识NAL单元中的RBSP数据类型，其中，nal_unit_type为1， 2， 3， 4， 5的NAL单元称为VCL的NAL单元，其他类型的NAL单元为非VCL的NAL单元。

§    0：未规定

§    1：非IDR图像中不采用数据划分的片段

§    2：非IDR图像中A类数据划分片段

§    3：非IDR图像中B类数据划分片段

§    4：非IDR图像中C类数据划分片段

§    5：IDR图像的片段

§    6：补充增强信息（SEI）

§    7：序列参数集（SPS）

§    8：图像参数集（PPS）

§    9：分割符

§    10：序列结束符

§    11：流结束符

§    12：填充数据

§    13：序列参数集扩展

§    14：带前缀的NAL单元

§    15：子序列参数集

§    16 –18：保留

§    19：不采用数据划分的辅助编码图像片段

§    20：编码片段扩展

§    21 –23：保留

§    24 –31：未规定

 

 

3．H.264的NAL层处理

结构示意图：

NAL以NALU（NAL unit）为单元来支持编码数据在基于分组交换技术网络中传输。它定义了符合传输层或存储介质要求的数据格式，同时给出头信息，从而提供了视频编码和外部世界的接口。

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

 

 

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

三种不同的数据形式：

SODB　数据比特串－－＞最原始的编码数据 （raw）

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

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

 

 

处理过程：

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

2．针对不同的传送网络（电路交换|包交换），将nal_unit 封装成针对不同网络的封装格式。

 

第一步的具体过程：

VCL层输出的比特流SODB（String OfData Bits），到nal_unit之间，经过了以下三步处理：

1.SODB字节对齐处理后封装成RBSP（RawByte 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 /*equal to 0x03 */

} else

rbsp_byte[ NumBytesInRBSP++ ]

}

}

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

 

 

第二步的具体过程：

 

case1：有序字节流的封装

 

byte_stream_nal_unit( NumBytesInNALunit ) {

while( next_bits( 24 ) != 0x000001 )

zero_byte /* equal to 0x00 */

if( more_data_in_byte_stream( ) ) {

start_code_prefix_one_3bytes /* equal to 0x000001 */nal_unit( NumBytesInNALunit )

}

}

类似H.320和MPEG-2/H.222.0等传输系统，传输NAL作为有序连续字节或比特流，同时要依靠数据本身识别NAL单元边界。在这样的应用系统中，H.264/AVC规范定义了字节流格式，每个NAL单元前面增加3个字节的前缀，即同步字节。在比特流应用中，每个图像需要增加一个附加字节作为边界定位。还有一种可选特性，在字节流中增加附加数据，用做扩充发送数据量，能实现快速边界定位，恢复同步

Case2：IP网络的RTP打包封装

分组打包的规则

    (1)额外开销要少，使MTU尺寸在100～64k字节范围都可以；

    (2)不用对分组内的数据解码就可以判别该分组的重要性；

    (3)载荷规范应当保证不用解码就可识别由于其他的比特丢失而造成的分组不可解码；

    (4)支持将NALU分割成多个RTP分组；

    (5)支持将多个NALU汇集在一个RTP分组中。

    RTP的头标可以是NALU的头标，并可以实现以上的打包规则。

    一个RTP分组里放入一个NALU，将NALU(包括同时作为载荷头标的NALU头)放入RTP的载荷中，设置RTP头标值。为了避免IP层对大分组的再一次分割，片分组的大小一般都要小于MTU尺寸。由于包传送的路径不同，解码端要重新对片分组排序，RTP包含的次序信息可以用来解决这一问题。

 NALU分割

        对于预先已经编码的内容，NALU可能大于MTU尺寸的限制。虽然IP层的分割可以使数据块小于64千字节，但无法在应用层实现保护，从而降低了非等重保护方案的效果。由于UDP数据包小于64千字节，而且一个片的长度对某些应用场合来说太小，所以应用层打包是RTP打包方案的一部分。

    新的讨论方案(IETF)应当符合以下特征：

    (1)NALU的分块以按RTP次序号升序传输；

    (2)能够标记第一个和最后一个NALU分块；

    (3)可以检测丢失的分块。

 NALU合并

    一些NALU如SEI、参数集等非常小，将它们合并在一起有利于减少头标开销。已有两种集合分组：

    (1)单一时间集合分组(STAP)，按时间戳进行组合；

    (2)多时间集合分组(MTAP)，不同时间戳也可以组合。

NAL规范视频数据的格式，主要是提供头部信息，以适合各种媒体的传输和存储。NAL支持各种网络，包括：

1．任何使用RTP/IP协议的实时有线和无线Internet 服务

2．作为MP4文件存储和多媒体信息文件服务

3．MPEG-2系统

4．其它网

NAL规定一种通用的格式，既适合面向包传输，也适合流传送。实际上，包传输和流传输的方式是相同的，不同之处是传输前面增加了一个起始码前缀

在类似Internet/RTP面向包传送协议系统中，包结构中包含包边界识别字节，在这种情况下，不需要同步字节。

 

NAL单元分为VCL和非VCL两种

VCL NAL单元包含视频图像采样信息，

非VCL包含各种有关的附加信息，例如参数集（头部信息，应用到大量的VCL NAL单元）、提高性能的附加信息、定时信息等

 

参数集：

参数集是很少变化的信息，用于大量VCL NAL单元的解码，分为两种类型：

1．序列参数集，作用于一串连续的视频图像，即视频序列。两个IDR图像之间为序列参数集。IDR和I帧的区别见下面。

2．图像参数集，作用于视频序列中的一个或多个个别的图像序列和图像参数集机制，减少了重复参数的传送，每个VCL NAL单元包含一个标识，指向有关的图像参数集，每个图像参数集包含一个标识，指向有关的序列参数集的内容因此，只用少数的指针信息，引用大量的参数，大大减少每个VCL NAL单元重复传送的信息。

序列和图像参数集可以在发送VCL NAL单元以前发送，并且重复传送，大大提高纠错能力。序列和图像参数集可以在“带内”，也可以用更为可靠的其他“带外”通道传送。

 

存储单元：

一组指定格式的NAL单元称为存储单元，每个存储单元对应一个图像。每个存储单元包含一组VCL NAL单元，组成一个主编码图像，VCL NAL单元由表示视频图像采样的像条所组成。存储单元前面可以加一个前缀，分界存储单元，附加增强信息（SEI）（如图像定时信息）也可以放在主编码图像的前面。主编码图像后附加的VCL NAL单元，包含同一图像的冗余表示，称为冗余编码图像，当主编码图像数据丢失或损坏时，可用冗余编码图像解码。

 

 

编码视频序列:

一个编码视频序列由一串连续的存储单元组成，使用同一序列参数集。每个视频序列可独立解码。编码序列的开始是即时刷新存储单元（IDR）。IDR是一个I帧图像，表示后面的图像不用参考以前的图像。一个NAL单元流可包含一个或更多的编码视频序列。

 

 

I帧和IDR帧的区别：

1．在 H.264 中 I 帧并不具有随机访问的能力，这个功能由 IDR 承担。以前的标准中由 I 帧承担。

2．IDR 会导致 DPB （参考帧列表——这是关键所在）清空，而 I 不会。

3．I和IDR帧其实都是I帧,都是使用帧内预测的。但是IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。

4．IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

         H264 NALU RTP

对h.264压缩视频码流中i帧的提取(firstime)

2010-06-30 09:15

转载自 fandy586  http://hi.baidu.com/sdlyfdy

 

这 个问题要说清楚还是有点复杂：首先判断 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视频传输的框架。

  

 

 

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字节。

 

 

          一方面，如果每个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，如下图所示：

 

 

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方式打包。分割方案如下：

 

 

 

 

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

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

RTP／RTCP包的封装实现

RTP包封装设计

 

 

 

 

RTcP包的封装设计

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

 

 

  

 

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



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.

第二步的具体过程：



case1：有序字节流的封装



byte_stream_nal_unit( NumBytesInNALunit ) {

while( next_bits( 24 ) != 0x000001 )

zero_byte

if( more_data_in_byte_stream( ) ) {

start_code_prefix_one_3bytes nal_unit( NumBytesInNALunit )

}

}

类似H.320和MPEG-2/H.222.0等传输系统，传输NAL作为有序连续字节或比特流，同时要依靠数据本身识别NAL单元边界。在这样的应用系 统中，H.264/AVC规范定义了字节流格式，每个NAL单元前面增加3个字节的前缀，即同步字节。在比特流应用中，每个图像需要增加一个附加字节作为 边界定位。还有一种可选特性，在字节流中增加附加数据，用做扩充发送数据量，能实现快速边界定位，恢复同步

Case2：IP网络的RTP打包封装

分组打包的规则

(1)额外开销要少，使MTU尺寸在100～64k字节范围都可以；

(2)不用对分组内的数据解码就可以判别该分组的重要性；

(3)载荷规范应当保证不用解码就可识别由于其他的比特丢失而造成的分组不可解码；

(4)支持将NALU分割成多个RTP分组；

   　(5)支持将多个NALU汇集在一个RTP分组中。

RTP的头标可以是NALU的头标，并可以实现以上的打包规则。

一个RTP分组里放入一个NALU，将NALU(包括同时作为载荷头标的NALU头)放入RTP的载荷中，设置RTP头标值。为了避免IP层对大分组的再 一次分割，片分组的大小一般都要小于MTU尺寸。由于包传送的路径不同，解码端要重新对片分组排序，RTP包含的次序信息可以用来解决这一问题。

NALU分割

对于预先已经编码的内容，NALU可能大于MTU尺寸的限制。虽然IP层的分割可以使数据块小于64千字节，但无法在应用层实现保护，从而降低了非等重保 护方案的效果。由于UDP数据包小于64千字节，而且一个片的长度对某些应用场合来说太小，所以应用层打包是RTP打包方案的一部分。

新的讨论方案(IETF)应当符合以下特征：

(1)NALU的分块以按RTP次序号升序传输；

(2)能够标记第一个和最后一个NALU分块；

(3)可以检测丢失的分块。

NALU合并

一些NALU如SEI、参数集等非常小，将它们合并在一起有利于减少头标开销。已有两种集合分组：

(1)单一时间集合分组(STAP)，按时间戳进行组合；

(2)多时间集合分组(MTAP)，不同时间戳也可以组合。

NAL规范视频数据的格式，主要是提供头部信息，以适合各种媒体的传输和存储。NAL支持各种网络，包括：

1．任何使用RTP/IP协议的实时有线和无线Internet 服务

2．作为MP4文件存储和多媒体信息文件服务

3．MPEG-2系统

4．其它网

NAL规定一种通用的格式，既适合面向包传输，也适合流传送。实际上，包传输和流传输的方式是相同的，不同之处是传输前面增加了一个起始码前缀

在类似Internet/RTP面向包传送协议系统中，包结构中包含包边界识别字节，在这种情况下，不需要同步字节。

NAL单元分为VCL和非VCL两种

VCL NAL单元包含视频图像采样信息，

非VCL包含各种有关的附加信息，例如参数集（头部信息，应用到大量的VCL NAL单元）、提高性能的附加信息、定时信息等

参数集：

参数集是很少变化的信息，用于大量VCL NAL单元的解码，分为两种类型：

1．序列参数集，作用于一串连续的视频图像，即视频序列。

两个IDR图像之间为序列参数集。IDR和I帧的区别见下面。

2．   图像参数集，作用于视频序列中的一个或多个个别的图像

序列和图像参数集机制，减少了重复参数的传送，每个VCL NAL单元包含一个标识，指

向有关的图像参数集，每个图像参数集包含一个标识，指向有关的序列参数集的内容

因此，只用少数的指针信息，引用大量的参数，大大减少每个VCL NAL单元重复传送的信息。

序列和图像参数集可以在发送VCL NAL单元以前发送，并且重复传送，大大提高纠错能力。序列和图像参数集可以在“带内”，也可以用更为可靠的其他“带外”通道传送。

H264实时编码及NALU，RTP传输(续)（ZZ）

2010-07-25 11:47

存 储单元：一组指定格式的NAL单元称为存储单元，每个存储单元对应一个图像。每个存储单元包含一组VCL NAL单元，组成一个主编码图像，VCL NAL单元由表示视频图像采样的像条所组成。存储单元前面可以加一个前缀，分界存储单元，附加增强信息（SEI）（如图像定时信息）也可以放在主编码图像 的前面。主编码图像后附加的VCL NAL单元，包含同一图像的冗余表示，称为冗余编码图像，当主编码图像数据丢失或损坏时，可用冗余编码图像解码。编码视频序列一个编码视频序列由一串连续 的存储单元组成，使用同一序列参数集。每个视频序列可独立解码。编码序列的开始是即时刷新存储单元（IDR）。IDR是一个I帧图像，表示后面的图像不用 参考以前的图像。一个NAL单元流可包含一个或更多的编码视频序列。RTP协议：实时传输协议（Real-time Transport Protocol，RTP）是在Internet上处理多媒体数据流的一种网络协议，利用它能够在一对一（单播）或者一对多（multicast，多播） 的网络环境中实现传流媒体数据的实时传输。RTP通常使用UDP来进行多媒体数据的传输，但如果需要的话可以使用TCP或者ATM等其它协议，整个RTP 协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议。实时流协议（Real Time Streaming Protocol， RTSP）最早由Real Networks和Netscape公司共同提出，它位于RTP和RTCP之上，其目的是希望通过IP网络有效地传输多媒体数据。RTP数据协议 RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其 中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。RTP数据报的头部格式如图1所示： 其中比较重要的几个域及其意义如下： CSRC记数（CC）　　表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存 在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者 的语音数据组合为一个RTP数据源。 负载类型（PT）　　标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。    序列号　　用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。    时间戳　记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的 事情。从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基 础。RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接 的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够 了；另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的 一部分加以实现的，如图2所示：RTCP控制协议 RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能 为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有 成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控 制或者对网络状况进行诊断。 RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型： SR　　发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。 RR　　接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。 SDES　　源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。 BYE　　通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。 APP　　由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。 RTCP数据报携带有服务质量监控的必要信息，能够对服务质量进行动态的调整，并能够对网络拥塞进行有效的控制。由于RTCP数据报采用的是多播方式，因 此会话中的所有成员都可以通过RTCP数据报返回的控制信息，来了解其他参与者的当前情况。在一个典型的应用场合下，发送媒体流的应用程序将周期性地产生 发送端报告SR，该RTCP数据报含有不同媒体流间的同步信息，以及已经发送的数据报和字节的计数，接收端根据这些信息可以估计出实际的数据传输速率。另 一方面，接收端会向所有已知的发送端发送接收端报告RR，该RTCP数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信 息，发送端应用根据这些信息可以估计出往返时延，并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率，以改善网络拥塞状况，或者根据网络状况平滑 地调整应用程序的服务质量。RTSP实时流协议 作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协 议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂 停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作。RTSP在制定时较多地参考了HTTP/1.1协 议，甚至许多描述与HTTP/1.1完全相同。RTSP之所以特意使用与HTTP/1.1类似的语法和操作，在很大程度上是为了兼容现有的Web基础结 构，正因如此，HTTP/1.1的扩展机制大都可以直接引入到RTSP中。由RTSP控制的媒体流集合可以用表示描述（Presentation Description）来定义，所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合，而表示描述则包含了一个表示中各个媒体流的相关信 息，如数据编码/解码算法、网络地址、媒体流的内容等。虽然RTSP服务器同样也使用标识符来区别每一流连接会话（Session），但RTSP连接并没 有被绑定到传输层连接（如TCP等），也就是说在整个RTSP连接期间，RTSP用户可打开或者关闭多个对RTSP服务器的可靠传输连接以发出RTSP 请求。此外，RTSP连接也可以基于面向无连接的传输协议（如UDP等）。RTSP协议目前支持以下操作： 检索媒体　　允许用户通过HTTP或者其它方法向媒体服务器提交一个表示描述。如表示是组播的，则表示描述就包含用于该媒体流的组播地址和端口号；如果表 示是单播的，              为了安全在表示描述中应该只提供目的地址。 邀请加入　　媒体服务器可以被邀请参加正在进行的会议，或者在表示中回放媒体，或者在表示中录制全部媒体或其子集，非常适合于分布式教学。 添加媒体　　通知用户新加入的可利用媒体流，这对现场讲座来讲显得尤其有用。与HTTP/1.1类似，RTSP请求也可以交由代理、通道或者缓存来进行处 理。 3． JM86中的处理涉及的函数：流程图：I帧和IDR帧的区别：1．   在 H.264 中 I 帧并不具有随机访问的能力，这个功能由 IDR 承担。以前的标准中由 I 帧承担。2．   IDR 会导致 DPB （参考帧列表——这是关键所在）清空，而 I 不会。3．   I和IDR帧其实都是I帧,都是使用帧内预测的。但是IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。4．   IDR图像一定是I图像，但I图像不一定是IDR图像。一个序列中可以有很多的I图像，I图像之后的图像可以引用I图像之间的图像做运动参考。

 

 

 

 

 

 

 

 

 

 

 

                     摘要: H.264 基础及 RTP 封包详解

一. h264基础概念

1、NAL、Slice与frame意思及相互关系 

 

1 frame的数据可以分为多个slice.
每个slice中的数据，在帧内预测只用到自己slice的数据， 与其他slice 数据没有依赖关系。 
NAL 是用来将编码的数据进行大包的。 比如，每一个slice 数据可以放在NAL 包中。
I frame 是自己独立编码，不依赖于其他frame 数据。
P frame 依赖 I frame 数据。 
B frame 依赖 I frame, P frame 或其他 B frame 数据。  

一个frame是可以分割成多个Slice来编码的，而一个Slice编码之后被打包进一个NAL单元，不过NAL单元除了容纳Slice编码的码流外，还可以容纳其他数据，比如序列参数集SPS。


NAL指网络提取层，里面放一些与网络相关的信息
Slice是片的意思，264中把图像分成一帧（frame）或两场（field），而帧又可以分成一个或几个片（Slilce）；片由宏块（MB）组成。宏块是编码处理的基本单元。

2、NAL nal_unit_type中的1（非IDR图像的编码条带）、2（编码条带数据分割块A）、3（编码条带数据分割块B）、4（编码条带数据分割块C）、5（IDR图像的编码条带）种类型 
与 Slice种的三种编码模式：I_slice、P_slice、B_slice 
NAL nal_unit_type 里的五种类型，代表接下来数据是表示啥信息的和具体如何分块。
I_slice、P_slice、B_slice 表示I类型的片、P类型的片，B类型的片.其中I_slice为帧内预测模式编码；P_slice为单向预测编码或帧内模式；B_slice 中为双向预测或帧内模式。

3、还有frame的3种类型：I frame、P frame、 B frame之间有什么映射关系么？ 
I frame、P frame、 B frame关系同 I_slice、P_slice、B_slice，slice和frame区别在问题1中已经讲明白。

4、最后，NAL nal_unit_type中的6（SEI）、7（SPS）、8（PPS）属于什么帧呢？ 
NAL nal_unit_type 为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）不属于啥帧的概念。表示后面的数据信息为序列参数集（SPS）、图像参数集（PPS）、增强信息（SEI）。 
 

二， h264 rtp 封包详解 ---转载

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实时编码及NALU，RTP传输(续)

标签： RTP jrtplib

2014-06-24 11:23 587人阅读 评论(0)收藏举报

对h.264压缩视频码流中i帧的提取(firstime)

2010-06-30 09:15

转载自 fandy586  http://hi.baidu.com/sdlyfdy

最终编辑 fandy586

这 个问题要说清楚还是有点复杂：首先判断 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:
这个参数的值是一个整型, 指出了每一秒最大的宏块处理速度.

 

 

 

 

 

 

 

 

按照RFC3984协议实现H264视频流媒体

 

http://www.cnblogs.com/GoAhead/archive/2012/12/21/2828153.html

转自： http://topic.csdn.net/u/20100104/16/0fd992e8-b0a6-4c2b-85a4-d9513d3b1491.html

相信有不少人和我一样，希望实现H264格式视频的流媒体播放。但是对于一个新手来说，往往不知道从何入手。利用百度，GOOGLE等搜索资料真是沙里淘金。在琢磨了N周之后，才弄出来了点成果，其中费了很多无用的功夫，光看英文协议就费了一周，后来才知道有中文版，并且我所达到的目的很简单，只要让VLC实时播放就行，不需要了解整个协议。我也很希望能直接搜出来一套代码，都一直没找到，还是得自己动手。现在我把自己的代码贴出来，希望对做类似工程的朋友有所帮助。
    一、本示例代码在我的电脑上实现了对标准H264码流的RTP打包发送到本机的1234端口，用VLC播放器从1234端口能接收到该码流并实时播放。代码附有详细的注释，应该很容易理解（前提是大家稍微对RFC3550 RFC3984协议有了解）。
    二、本示例代码是按照RFC3984协议仅完成了RTP打包，并没有完成发送RTCP。原因就引用这位达人的话：“1.RTCP里头有很多关于RTCP发送简隔的时间计算，RTP信息的统计，这种操作不是难，而是烦，我不想去写。2.RTCP和RTP一开始出来的时候并不是因为视频的点播等应用的，而是视频会议。RTCP有管理与会者的层面含义，这一功能在很多场合并不会用到。3.我想简单，没有写多个流间的同步，如一个影片的视频和音频流。这些其实是RTCP来完成的。我懒得去写，因为这些工作RTP的各个库类（例如JRTPLIB库）都做得很好。我觉得用库的最大优点就在这吧”。
    三、和代码相关的原理性的东西，大家应该去看看RFC3550，RFC3984.这两份协议都有热心网友翻译好的中文版。我把他们放在压缩包里，大家就不用再累个半死去搜索注册下载了。如果为了更省事，我觉得看看这位网友总结的RFC3984的内容就够了。网址是http://www.cppblog.com/czanyou/archive/2009/12/25/67940.html。如果打不开网页，就到压缩包里资料文件夹下找吧。我已经把网页保存下来了。
    四、代码并非是我完全原创的，而是我在搜索到得网友的代码的基础上修改的。这里要特别感谢以下几位网友：1.猫头上的鹰（他的博客地址http://blog.csdn.net/Tinnal/archive/2008/09/03/2871734.aspx）在他的博客里我第一次找到了有价值的东西，并且他无偿提供的MPEG的RTP打包源码只要拷贝下来建个工程就能实现MPEG的流媒体，对我启发很大。2.liming，他提供的代码已经实现了H264的码流分析，将其中的每个NALU单元分离开来，并分析出了NALU的类型，长度等信息。为我实现RTP打包提供了很大的方便，事实上，这份示例代码就是在他的代码上添加了RTP打包部分，我连工程名字都没有改。他的源代码在这里http://www.pudn.com/detail.asp?id=510807。3****，他提供的SDP文件在关键时候帮了我大忙，我发送的RTP数据包通过Wireshark抓包工具分析一直没错，可VLC播放器就是没任何反应。直到下载了他的SDP文件文件后终于出画面了。某位网友说VLC对H264只能通过TS封包或SDP文件打开RTP码流，在此我也这么怀疑。4.jessiepan和他的帖子，http://topic.csdn.net/u/20090725/11/5FBC75B0-1091-4DD4-9154-3E3D59F9B6D1.html ，这里提供了很多有用的信息。

    使用方法：直接在VC6上打开工程，编译。（需要注意的是大家要把IP地址和端口改为自己的。在h264.h的#define DEST_IP "192.168.0.30"和#define DEST_PORT 1234这两行修改就行了。同时w.sdp文件里也要改成一致的IP和端口号，不然VLC是接受不到数据的。在c=IN IP4 192.168.0.30 和m=video 1234 RTP/AVP 96这两行。中间的1234是我设置的端口号。）在执行程序之前，先用VLC打开w.sdp文件，然后执行程序，就可以看到画面了：）。同样需要注意的是VLC1.0以后的版本不支持直接打开h.264视频文件，但是0.97版本就支持。两个版本的VLC播放器大家去着哩下载这里我测试用1.03和0.97两份版本的VLC都可以接受并播放h.264RTP码流。
    目前还有几个问题我没有弄明白，希望有高手在看完这个帖子后能帮我解答：
    1.关于时间戳的设置。RFC3984里没有提到时间戳具体如何计算，我也是按照各方面的小道消息这样设置。unsigned int timestamp_increse=0;timestamp_increse=(unsigned int)(90000.0 / framerate); 即初始值设为0，时间戳增量设为90000.0 / framerate，framerate我设为25，即每秒25帧。每发送一个NALU单元，时间戳增加。若是该NALU大于1400字节，需要分片时，则多个分片拥有相同的时间戳。这样设置是否正确。请牛人给个权威解答。
    2.按照我的理解，SDP文件仅实现了告诉VLC在哪个IP和端口接受264RTP包，同样的信息我也通过在VLC的媒体-》打开网络串流，协议选RTP，然后填写IP和端口号中设置好了，为什么用打开SDP文件的方法能接收，但用后者VLC却没有一点反应。
    3.当我将帧率设为25时（即代码里的float framerate=25；）vlc能接受码流，但会比较卡，常缓冲，提示错误为main error: ES_OUT_SET_(GROUP_)PCR is called too late, increasing pts_delay to 339 ms。我怀疑是我的电脑发送UDP包速度不够每秒播放25帧的所需要的UDP包数量，因此在SDP文件我添加了a=framerate:15来限制播放器每秒播放15帧，同时在代码里的相应行float framerate=15;也将帧率改为15这样虽然解决了卡的问题，但是视频播放很慢。请问要是我想达到每秒播放25帧，难道只能换台好电脑了？
    4.下一步我想用jrtplib来打包RTP，因为听说用这个库实现RTCP很方便，是不是这个库会根据网络状况自动发送RTCP信息。如果哪位高手有这方面的代码或者是实现了RTSP的代码，希望能拿出来交流，哪怕是部分代码或者是实现部分功能也好。
   源码下载地址：http://download.csdn.net/source/1961862 大家下载后有什么问题可以直接和我联系，不留邮箱了，直接留QQ号吧：1002666420.另外我这里还有一个老外写的用LIVE555库实现H264 STREAMING的教程及代码，有需要的可以联系我。

 

部分回复：

1. vlc1.0.5播放sdp没问题，0.9.7我测试不行。sdp里面的ip地址不用设置也行。 
2. vlc播放一段时间后，1个小时或者2个小时就会出现大量丢帧，谁知道这是vlc的问题还是rtp封包的问题？
3. 关于时间戳的设置，只要和 *.sdp中的定义一致就好了.
   a = rtpmap:96 H264/90000 (这个时间戳可以改，越大client的播放速度越快)

   用SDP的方法可以直接match你的naldecoder的设置，如果用VLC自己的设置，可能有些参数不一样，你可以试

   着用 98 试一下

   播放速度可能是资源问题，也可能是sdp中时钟频率的设置问题

   如果要用Jrtp做底层的发送的话, client也需要用JRTP接受才行

4. 顶起楼主，但是重问33楼的问题，为什么用NALDecoder，解码出的码流，虽然播放流畅，但是却非常缓慢

   呢，我试图修改了时钟频率，播放速度发生了变化，但是却无法按照正常的时间长度播放，什么样的时钟能

   够让VLC正常播放视频呢？

5. 你这个跟你的帧的时间戳设置有关，帧与帧之间的单位间隔大了就会慢。90000那个是控制基本单位的长短

   的，控制完基本单位后播放时的速度就由两帧时间戳之间的基本单元数决定。

 

6. 看过代码，关于播放速度的问题，我觉得可能因为时间戳写的有错误，代码中每个Nal单元都会造成时间戳增

   加3600（也就是90K时钟下，25帧/s时一帧的时间）,而每个Nal单元中不一定就是一帧图像。

 

 

 

 

 

 

         udp丢包 又是udp丢包

2014-07-09 10:39 3828人阅读 评论(1)收藏举报

分类：

C++（20）

自己在做UDP传输时遇到的问题，接收端没设置缓存，结果总是丢包。

看到这篇文章设置了一下接收缓存就好

 

[cpp] view plain copy

1. int nRecvBuf=32*1024;//设置为32K  
2. setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));  

 

 

http://www.cnweblog.com/fly2700/archive/2011/09/19/317825.html

什么会导致udp丢包呢，我这里列举了如下几点原因：

1.调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2.发送的包巨大丢包。虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过30K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3.发送的包较大，超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4.发送的包频率太快，虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。
5.发送的广播包或组播包在windws和Linux下都接收正常，而arm上接收出现丢包。这个还不好解决，我的解决方法是大包切割成大小为1448的小包发送，每个包之间sleep 1毫秒，虽然笨，但有效。我这里mtu size为1500字节，减去udp包头8个字节，减去传输层几十个字节，实际数据位1448字节。
除此之外还可以试试设置arm操作系统缓冲：
//设置mtu size 1500最大
ifconfig eth0 mtu 1500
//查看接收缓冲最大和默认大小。
sysctl -A | grep rmem
//设置接收缓冲的最大大小
sysctl -w net.core.rmem_max=1048576
sysctl -w net.core.rmem_default=1048576
sysctl -w net.ipv4.udp_mem=1048576
sysctl -w net.ipv4.udp_rmem_min=1048576
6,局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。

总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。

 

 

 

 

 

RFC3550转载：

 

sequence number: 16 bits
      The sequence number increments by one for each RTP data packet
      sent, and may be used by the receiver to detect packet loss and to
      restore packet sequence.  The initial value of the sequence number
      SHOULD be random (unpredictable) to make known-plaintext attacks
      on encryption more difficult, even if the source itself does not
      encrypt according to the method in Section 9.1, because the
      packets may flow through a translator that does.  Techniques for
      choosing unpredictable numbers are discussed in [17].

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering



Schulzrinne, et al.         Standards Track                    [Page 14]Section 9.1, because the
      packets may flow through a translator that does.  Techniques for
      choosing unpredictable numbers are discussed in [17].

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations (see Section 6.4.1).  The
      resolution of the clock MUST be sufficient for the desired
      synchronization accuracy and for measuring packet arrival jitter
      (one tick per video frame is typically not sufficient).  The clock
      frequency is dependent on the format of data carried as payload
      and is specified statically in the profile or payload format
      specification that defines the format, or MAY be specified
      dynamically for payload formats defined through non-RTP means.  If
      RTP packets are generated periodically, the nominal sampling
      instant as determined from the sampling clock is to be used, not a
      reading of the system clock.  As an example, for fixed-rate audio
      the timestamp clock would likely increment by one for each
      sampling period.  If an audio application reads blocks covering



Schulzrinne, et al.         Standards Track                    [Page 14]

---

 
RFC 3550                          RTP                          July 2003


      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

      The initial value of the timestamp SHOULD be random, as for the
      sequence number.  Several consecutive RTP packets will have equal
      timestamps if they are (logically) generated at once, e.g., belong
      to the same video frame.  Consecutive RTP packets MAY contain
      timestamps that are not monotonic if the data is not transmitted
      in the order it was sampled, as in the case of MPEG interpolated
      video frames.  (The sequence numbers of the packets as transmitted
      will still be monotonic.)

      RTP timestamps from different media streams may advance at
      different rates and usually have independent, random offsets.
      Therefore, although these timestamps are sufficient to reconstruct
      the timing of a single stream, directly comparing RTP timestamps
      from different media is not effective for synchronization.
      Instead, for each medium the RTP timestamp is related to the
      sampling instant by pairing it with a timestamp from a reference
      clock (wallclock) that represents the time when the data
      corresponding to the RTP timestamp was sampled.  The reference
      clock is shared by all media to be synchronized.  The timestamp
      pairs are not transmitted in every data packet, but at a lower
      rate in RTCP SR packets as described in Section 6.4.

      The sampling instant is chosen as the point of reference for the
      RTP timestamp because it is known to the transmitting endpoint and
      has a common definition for all media, independent of encoding
      delays or other processing.  The purpose is to allow synchronized
      presentation of all media sampled at the same time.

      Applications transmitting stored data rather than data sampled in
      real time typically use a virtual presentation timeline derived
      from wallclock time to determine when the next frame or other unit
      of each medium in the stored data should be presented.  In this
      case, the RTP timestamp would reflect the presentation time for
      each unit.  That is, the RTP timestamp for each unit would be
      related to the wallclock time at which the unit becomes current on
      the virtual presentation timeline.  Actual presentation occurs
      some time later as determined by the receiver.

      An example describing live audio narration of prerecorded video
      illustrates the significance of choosing the sampling instant as
      the reference point.  In this scenario, the video would be
      presented locally for the narrator to view and would be
      simultaneously transmitted using RTP.  The "sampling instant" of a
      video frame transmitted in RTP would be established by referencing



Schulzrinne, et al.         Standards Track                    [Page 15]
RFC 3550                          RTP                          July 2003


      160 sampling periods from the input device, the timestamp would be
      increased by 160 for each such block, regardless of whether the
      block is transmitted in a packet or dropped as silent.

      The initial value of the timestamp SHOULD be random, as for the
      sequence number.  Several consecutive RTP packets will have equal
      timestamps if they are (logically) generated at once, e.g., belong
      to the same video frame.  Consecutive RTP packets MAY contain
      timestamps that are not monotonic if the data is not transmitted
      in the order it was sampled, as in the case of MPEG interpolated
      video frames.  (The sequence numbers of the packets as transmitted
      will still be monotonic.)

      RTP timestamps from different media streams may advance at
      different rates and usually have independent, random offsets.
      Therefore, although these timestamps are sufficient to reconstruct
      the timing of a single stream, directly comparing RTP timestamps
      from different media is not effective for synchronization.
      Instead, for each medium the RTP timestamp is related to the
      sampling instant by pairing it with a timestamp from a reference
      clock (wallclock) that represents the time when the data
      corresponding to the RTP timestamp was sampled.  The reference
      clock is shared by all media to be synchronized.  The timestamp
      pairs are not transmitted in every data packet, but at a lower
      rate in RTCP SR packets as described in Section 6.4.

      The sampling instant is chosen as the point of reference for the
      RTP timestamp because it is known to the transmitting endpoint and
      has a common definition for all media, independent of encoding
      delays or other processing.  The purpose is to allow synchronized
      presentation of all media sampled at the same time.

      Applications transmitting stored data rather than data sampled in
      real time typically use a virtual presentation timeline derived
      from wallclock time to determine when the next frame or other unit
      of each medium in the stored data should be presented.  In this
      case, the RTP timestamp would reflect the presentation time for
      each unit.  That is, the RTP timestamp for each unit would be
      related to the wallclock time at which the unit becomes current on
      the virtual presentation timeline.  Actual presentation occurs
      some time later as determined by the receiver.

      An example describing live audio narration of prerecorded video
      illustrates the significance of choosing the sampling instant as
      the reference point.  In this scenario, the video would be
      presented locally for the narrator to view and would be
      simultaneously transmitted using RTP.  The "sampling instant" of a
      video frame transmitted in RTP would be established by referencing



Schulzrinne, et al.         Standards Track                    [Page 15]

---

 
RFC 3550                          RTP                          July 2003


      its timestamp to the wallclock time when that video frame was
      presented to the narrator.  The sampling instant for the audio RTP
      packets containing the narrator's speech would be established by
      referencing the same wallclock time when the audio was sampled.
      The audio and video may even be transmitted by different hosts if
      the reference clocks on the two hosts are synchronized by some
      means such as NTP.  A receiver can then synchronize presentation
      of the audio and video packets by relating their RTP timestamps
      using the timestamp pairs in RTCP SR packets.
RFC 3550                          RTP                          July 2003


      its timestamp to the wallclock time when that video frame was
      presented to the narrator.  The sampling instant for the audio RTP
      packets containing the narrator's speech would be established by
      referencing the same wallclock time when the audio was sampled.
      The audio and video may even be transmitted by different hosts if
      the reference clocks on the two hosts are synchronized by some
      means such as NTP.  A receiver can then synchronize presentation
      of the audio and video packets by relating their RTP timestamps
      using the timestamp pairs in RTCP SR packets.

 

 

 

 

 

 

[转] rtp h264注意点(FU-A分包方式说明)

总括： 一帧视频数据可以编码成多个H264的NALU， 每个NALU的开头为00 00 00 01； 一个RTP包可以传送 部分、一个或多个 NALU，看NALU的大小而定。

 

之前写过一篇文章，分析了h264使用rtp进行封包的格式介绍：RTP封装h264 (见下面)。但里面好像没有把拆分以及一些需要注意的情况说清楚，因此这里做补充，也作为自己的备忘（自己记性好像不太好）。

 
        关于时间戳，需要注意的是h264的采样率为90000HZ(被标准固定死的，为了方便转换成npt时间，见维基百科：https://en.wikipedia.org/wiki/RTP_audio_video_profile)，因此时间戳的单位为1(秒)/90000，因此如果当前视频帧率为25fps，那时间戳间隔或者说增量应该为3600，如果帧率为30fps，则增量为3000，以此类推。
        关于h264拆包，按照FU-A方式说明：
        1）第一个FU-A包的FU indicator：F应该为当前NALU头的F，而NRI应该为当前NALU头的NRI，Type则等于28，表明它是FU-A包。FU header生成方法：S = 1，E = 0，R = 0，Type则等于NALU头中的Type。
        2）后续的N个FU-A包的FU indicator和第一个是完全一样的，如果不是最后一个包，则FU header应该为：S = 0，E = 0，R = 0，Type等于NALU头中的Type。
        3）最后一个FU-A包FU header应该为：S = 0，E = 1，R = 0，Type等于NALU头中的Type。

        因此总结就是：同一个NALU分包厚的FU indicator头是完全一致的，FU header只有S以及E位有区别，分别标记开始和结束，它们的RTP分包的序列号应该是依次递增的，并且它们的时间戳必须一致，而负载数据为NALU包去掉1个字节的NALU头后对剩余数据的拆分，这点很关键，你可以认为NALU头被拆分成了FU indicator和FU header，所以不再需要1字节的NALU头了。
        关于SPS以及PPS，配置帧的传输我采用了先发SPS，再发送PPS，并使用同样的时间戳，或者按照正常时间戳增量再或者组包发送的形式处理貌似都可以，看播放器怎么解码了，另外提一下，如果我们使用vlc进行播放的话，可以在sdp文件中设置SPS以及PPS，这样就可以不用发送它们了。
        使用VLC播放时，sdp文件中的分包模式选项：packetization-mode=1，否则有问题。另外sdp里面设置的编码type必须和rtp包中的一致。


转自 http://blog.csdn.net/jwybobo2007/article/details/7235942

 
项目中的总结
  (1) FU-A 还原的时候，也是0x00 00 00 01 开始，不需要自己额外添加0x00 00 00 01
  (2) FU-A 的的解析，start end等数据要解析好
  (3) single nal unit 也是以0x00 00 00 01开始，也不需要自己添加分隔符

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

h264 NALU格式

网络抽象层单元类型 (NALU): 一个原始的 H.264 NALU 单元常由 [Start Code] [NALU Header] [NALU Payload] 三部分组成，形如 00 00 00 01 67 42 A0 1E 23， 则67是nalu header, 42之后的是payload(有效的原始视频数据). 有些代码中的 nal_octet 变量指的就是 nalu header 字节。

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

      +---------------+
      |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 没有定义

h264仅用1-23, 24以后的用在RTP H264负载类型头中(即24以后在rtp中使用)

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

 

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

RTP格式：

总括：[RTP Packet] = [RTP Header] + [RTP PayLoad]

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): 7bits      （请和H264 NALU的payload区别开来，H264的payload指的是纯视频编码数据，这里的payload type指的是rtp的载荷类型）
rfc里面对一些早期的格式定义了这个payload type。但是后来的，如h264并没有分配，那就用96来代替。因此现在96以上都不表示特定的格式，具体表示什么要用sdp或者其他协议来协商。

      序列号 Sequence number(SN): 16bits
      时间戳 Timestamp: 32bits     (rtp打包时使用的时间戳都是pts，因为dts是解码器根据I、P、B帧的顺序自己设定的解码顺序，而pts是编码时按照显示顺序输出的帧序列，几乎每个编码器都会按照显示顺序输出帧序 列：如 I B1 B2 B3 P4 B5 B6 B7 B8 B9 P10；而dts是解码器重新排列帧顺序后的解码顺序，前面的解码顺序[dts]为： I P4 B1 B2 B3 P10 B5 B6 B7 B8 B9)

 

RTP 格式Payload的结构，下面介绍的全部都是RTP PayLoad的部分,即RTP PayLoad 封包介绍：

 

单一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 包即可. 以下即是一个被打包进rtp的NALU单元(不包含rtp头)，第一个字节是NALU头：

       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 个字节的开始码就可以了.

 

 

组合封包模式

  其次, 当 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        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

这里只介绍STAP-A模式，如果是STAP-B的话会多加入一个DON域，另外还有MTAP16、MTAP24，具体不介绍，可以看rfc文档，文章尾贴一个链接可以去看。

转载的话注明一下作者：jwybobo2007 出处：http://blog.csdn.net/jwybobo2007/article/details/7054140

例：

 

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

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

  [00 00 00 01 68 42 B0 12 58 6A D4 FF ... ]

  封装成 RTP 包将如下:

  [ RTP Header ] [78 (STAP-A头，占用1个字节)] [第一个NALU长度 (占用两个字节)] [ 67 42 A0 1E 23 56 0E 2F ] [第二个NALU长度 (占用两个字节)] [68 42 B0 12 58 6A D4 FF ... ]

 

分片的单元：

 

  当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   |
      +---------------+

   别被名字吓到这个格式就是上面提到的RTP h264负载类型，Type为FU-A

   The FU header has the following format:

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

     S bit为1表示分片的NAL开始，当它为1时，E不能为1

   E bit为1表示结束，当它为1，S不能为1

   R bit保留位

   Type就是NALU头中的Type,取1-23的那个值

 

 

 

 

 

 

 

 

 

 

 

 

H.264 RTP Streaming

 

根據RFC3984以RTP 封裝H.264 raw data來作video streaming.

1.H.264 raw data
以00 00 01 或 00 00 00 01作為開頭(Start Code),接著是8 bit NALU 
NALU的format

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

F      :   forbidden zero bit, 一定為0
NRI :  nal_ref_idc, 表示資料的重要性, 00為最不重要.
Type :nal_unit_type, H.264只定義1~23的範圍

一個H.264 raw data看起來像這樣
00 00 00 01 09 30 ......

2.RTP header
因為一個H.264 video frame資料的大小往往會在數k bytes到數十K bytes,
在傳送封包時就會將資料切割分別封裝,也因此需要加入一些額外的參數讓
接收端可以正確組合被分割的video frame.這也是RFC3984最主要的目的.

RTP header 中有三個參數要注意
timestamp : 以90KHz作為基準,以30 fps為例,timestamp遞增 90000 / 30.
            實務上是以payload實際間隔時間作計算.同一個video frame的
            分割資料timestamp是相同的
sequence : 每個RTP封包sequence number都遞增.
mark bit : RTP封包封裝的是最後一個分割的video frame時mark bit 為 1.

2.Payload format
1~23 : Single NAL unit packet.

RFC3984使用了H.264 NALU中未定義的type 24~29 (相當於增加H.264 nal_unit_type定義)

24 : STAP-A 單一時間組合
25 : STAP-B 單一時間組合
26 : MTAP16 多個時間組合
27 : MTAP32 多個時間組合
28 : FU-A 分割資料
29 : FU-B 分割資料

比較常見的是28,29.

3.Single NAL unit packet
當資料少於MTU的大小就用此方式封裝.
H.264 raw data foramt 為 [Start code][NALU][Raw Data]
封裝時去掉Start Code即可.Format 如下
[RTP Header][NALU][Raw Date]

4.FU-A (Fragmentation unit)
當資料大於MTU以此方式分割
H.264 raw data foramt 為 [Start code][NALU][Raw Data]
去掉[Start code],[NALU],以不超過MTU大小分割[Raw Data]
以NALU產生FU indicator, FU Header.

RFC 3984

       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   |
      +---------------+

[FU indicator] = (NALU & 0x60) | 28;
[FU Header] = (start << 7) | (end << 6) | (NALU & 0x1f);

format如下

[RTP Header][FU indicator][FU header][Raw Data Part 0]
[RTP Header][FU indicator][FU header][Raw Data Part 1]
[RTP Header][FU indicator][FU header][Raw Data Part 2]
...

5.FU-B (Fragmentation unit)

RFC 3984

       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   |               DON             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
      |                                                               |
      |                         FU payload                            |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 15.  RTP payload format for FU-B

format如下
[RTP Header][FU indicator][FU header][DON][Raw Data Part 0]
[RTP Header][FU indicator][FU header][DON][Raw Data Part 1]
[RTP Header][FU indicator][FU header][DON][Raw Data Part 2]
...

from: https://www.cnblogs.com/welhzh/p/4785545.html