淄博企业建网站,wordpress在线朗读,代做预算网站,网站建设数字的代码编写H264码流打包分析
SODB 数据比特串#xff0d;#xff0d;#xff1e;最原始的编码数据
RBSP 原始字节序列载荷#xff0d;#xff0d;#xff1e;在SODB的后面填加了结尾比特#xff08;RBSP trailing bits 一个bit“1”#xff09;若干比特“0”,以便字节对齐。…H264码流打包分析
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去掉。 也称为脱壳操作。 本文福利 免费领取C音视频学习资料包学习路线大纲、技术视频/代码内容包括音视频开发面试题FFmpeg webRTC rtmp hls rtsp ffplay 编解码推拉流srs↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓ h264的功能分为两层视频编码层VCL和网络提取层NAL
VCL数据即被压缩编码后的视频数据序列。在VCL数据要封装到NAL单元中之后才可以用来传输或存储。NAL单元格式如下图 NAL单元 每个NAL单元是一个一定语法元素的可变长字节字符串包括包含一个字节的头信息用来表示数据类型以及若干整数字节的负荷数据。一个NAL单元可以携带一个编码片、A/B/C型数据分割或一个序列或图像参数集。 NAL单元按RTP序列号按序传送。其中T为负荷数据类型占5bitR为重要性指示位占2个bit最后的F为禁止位占1bit。具体如下 1NALU类型位 可以表示NALU的32种不同类型特征类型112是H.264定义的类型2431是用于H.264以外的RTP负荷规范使用这其中的一些值来定义包聚合和分裂其他值为H.264保留。 2重要性指示位 用于在重构过程中标记一个NAL单元的重要性值越大越重要。值为0表示这个NAL单元没有用于预测因此可被解码器抛弃而不会有错误扩散值高于0表示此NAL单元要用于无漂移重构且值越高对此NAL单元丢失的影响越大。 3禁止位 编码中默认值为0当网络识别此单元中存在比特错误时可将其设为1以便接收方丢掉该单元主要 用于适应不同种类的网络环境比如有线无线相结合的环境。例如对于从无线到有线的网关一边是无线的非IP环境一边是有线网络的无比特错误的环境。假 设一个NAL单元到达无线那边时校验和检测失败网关可以选择从NAL流中去掉这个NAL单元也可以把已知被破坏的NAL单元前传给接收端。在这种情 况下智能的解码器将尝试重构这个NAL单元已知它可能包含比特错误。
而非智能的解码器将简单地抛弃这个NAL单元。NAL单元结构规定了用于面向分 组或用于流的传输子系统的通用格式。在H.320和MPEG-2系统中NAL单元的流应该在NAL单元边界内每个NAL单元前加一个3字节的起始前缀 码。在分组传输系统中NAL单元由系统的传输规程确定帧界因此不需要上述的起始前缀码。一组NAL单元被称为一个接入单元定界后加上定时信息 SEI形成基本编码图像。该基本编码图像PCP由一组已编码的NAL单元组成其后是冗余编码图像RCP它是PCP同一视频图像的冗余表 示用于解码中PCP丢失情况下恢复信息。如果该编码视频图像是编码视频序列的最后一幅图像应出现序列NAL单元的end表示该序列结束。一个图像序 列只有一个序列参数组并被独立解码。如果该编码图像是整个NAL单元流的最后一幅图像则应出现流的end。 H.264采用上述严格的接入单元不仅使H.264可自适应于多种网络而且进一步提高其抗误码能力。序列号的设置可发现丢的是哪一个VCL单元冗余编码图像使得即使基本编码图像丢失仍可得到较“粗糙”的图像。 实现RTP协议的H.264视频传输系统
RTP 协议关键参数的设置
RTP 协议是 IETF 在 1996 年提出的适合实时数据传输的新型协议。RTP 协议实际上是由实时传输协议RTPReal-time Transport Protocol和实时传输控制协议RTCPReal-time Transport Control Protocol两部分组成。RTP 协议基于多播或单播网络为用户提供连续媒体数据的实时传输服务RTCP 协议是 RTP 协议的控制部分用于实时监控数据传输质量为系统提供拥塞控制和流控制。RTP 协议在RFC3550 中有详细介绍。每一个 RTP 数据包都由固定包头Header 和载荷Payload两个部分组成其中包头前12个字节的含义是固定的而载荷则可以是音频或视频数据。RTP 固定包头的格式如图1所示 其中比较关键的参数设置解释如下 1标示位M 1 位该标示位的含义一般由具体的媒体应用框架profile 定义 目的在于标记处RTP 流中的重要事件。 2载荷类型PT7 位用来指出RTP负载的具体格式。在RFC3551中对常用的音视频格式的RTP 传输载荷类型做了默认的取值规定例如类型2 表明该RTP数据包中承载的是用ITU G.721 算法编码的语音数据采用频率为 8000HZ并且采用单声道。 3序号:16 位每发送一个 RTP 数据包序号加 1。接受者可以用它来检测分组丢失和恢复分组顺序。 4时间戳32 位时间戳表示了 RTP 数据分组中第一个字节的采样时间反映出各RTP 包相对于时间戳初始值的偏差。对于RTP 发送端而言采样时间必须来源于一个线性单调递增的时钟。 从 RTP 数据包的格式不难看出它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息。这些都为实时的流媒体传输提供了相应的基础。而传输控制协议RTCP为 RTP传输提供了拥塞控制和流控制它的具体包结构和各字段的含义可参考RFC3550此处不再赘述。
3. H.264 基本流结构及其传输机制
3.1 H.264 基本流的结构
H.264 的基本流elementary stream,ES的结构分为两层包括视频编码层VCL和网络适配层NAL。视频编码层负责高效的视频内容表示而网络适配层负责以网络所要求的恰当的方式对数据进行打包和传送。引入NAL并使之与VCL分离带来的好处包括两方面其一、使信号处理和网络传输分离VCL 和NAL 可以在不同的处理平台上实现其二、VCL 和NAL 分离设计使得在不同的网络环境内网关不需要因为网络环境不同而对VCL比特流进行重构和重编码。
H.264 的基本流由一系列NALU Network Abstraction Layer Unit 组成不同的NALU数据量各不相同。H.264 草案指出[2]当数据流是储存在介质上时在每个NALU 前添加起始码0x000001用来指示一个 NALU的起始和终止位置。在这样的机制下*在码流中检测起始码作为一个NALU得起始标识当检测到下一个起始码时当前NALU结束。每个NALU单元由一个字节的 NALU头NALU Header和若干个字节的载荷数据RBSP组成。其中NALU 头的格式如图2 所示 Fforbidden_zero_bit.1 位如果有语法冲突则为 1。当网络识别此单元存在比特错误时可将其设为 1以便接收方丢掉该单元。 NRInal_ref_idc.2 位用来指示该NALU 的重要性等级。值越大表示当前NALU越重要。具体大于0 时取何值没有具体规定。
Type5 位指出NALU 的类型。具体如表1 所示 需要特别指出的是NRI 值为 7 和 8 的NALU 分别为序列参数集sps和图像参数集pps。参数集是一组很少改变的为大量VCL NALU 提供解码信息的数据。其中序列参数集作用于一系列连续的编码图像而图像参数集作用于编码视频序列中一个或多个独立的图像。如果*没能正确接收到这两个参数集那么其他NALU 也是无法解码的。因此它们一般在发送其它 NALU 之前发送并且使用不同的信道或者更加可靠的传输协议如TCP进行传输也可以重复传输。
3.2 适用于 H.264 视频的传输机制
前面分别讨论了RTP 协议及H.264基本流的结构那么如何使用RTP协议来传输H.264视频了?一个有效的办法就是从H.264视频中剥离出每个NALU在每个NALU前添加相应的RTP包头然后将包含RTP 包头和NALU 的数据包发送出去。下面就从RTP包头和NALU两方面分别阐述。
完整的 RTP 固定包头的格式在前面图 1 中已经指出根据RFC3984[3]这里详细给出各个位的具体设置。
V版本号2 位。根据RFC3984目前使用的RTP 版本号应设为0x10。 P填充位1 位。当前不使用特殊的加密算法因此该位设为 0。 X扩展位1 位。当前固定头后面不跟随头扩展因此该位也为 0。
CCCSRC 计数4 位。表示跟在 RTP 固定包头后面CSRC 的数目对于本文所要实现的基本的流媒体服务器来说没有用到混合器该位也设为 0x0。 M标示位1 位。如果当前 NALU为一个接入单元最后的那个NALU那么将M位置 1或者当前RTP 数据包为一个NALU 的最后的那个分片时NALU 的分片在后面讲述M位置 1。其余情况下M 位保持为 0。 PT载荷类型7 位。对于H.264 视频格式当前并没有规定一个默认的PT 值。因此选用大于 95 的值可以。此处设为0x60十进制96。 SQ序号16 位。序号的起始值为随机值此处设为 0每发送一个RTP 数据包序号值加 1。 TS时间戳32 位。同序号一样时间戳的起始值也为随机值此处设为0。根据RFC3984 与时间戳相应的时钟频率必须为90000HZ。
SSRC同步源标示32 位。SSRC应该被随机生成以使在同一个RTP会话期中没有任何两个同步源具有相同的SSRC 识别符。此处仅有一个同步源因此将其设为0x12345678。 对于每一个NALU根据其包含的数据量的不同其大小也有差异。在IP网络中当要传输的IP 报文大小超过最大传输单元MTUMaximum Transmission Unit 时就会产生IP分片情况。在以太网环境中可传输的最大 IP 报文MTU的大小为 1500 字节。如果发送的IP数据包大于MTU数据包就会被拆开来传送这样就会产生很多数据包碎片增加丢包率降低网络速度。对于视频传输而言若RTP 包大于MTU 而由底层协议任意拆包可能会导致接收端播放器的延时播放甚至无法正常播放。因此对于大于MTU 的NALU 单元必须进行拆包处理。
RFC3984 给出了3 中不同的RTP 打包方案
1Single NALU Packet:在一个RTP 包中只封装一个NALU在本文中对于小于 1400字节的NALU 便采用这种打包方案。 2Aggregation Packet:在一个RTP 包中封装多个NALU对于较小的NALU 可以采用这种打包方案从而提高传输效率。 3Fragmentation Unit:一个NALU 封装在多个RTP包中在本文中对于大于1400字节的NALU 便采用这种方案进行拆包处理。
4. H.264 流媒体传输系统的实现
一个完整的流媒体传输系统包含服务器端和客户端两个部分[5][6]。对于服务器端其主要任务是读取H.264 视频从码流中分离出每个NALU 单元分析NALU 的类型设置相应的 RTP 包头封装 RTP 数据包并发送。而对于客户端来说其主要任务则是接收 RTP数据包从RTP 包中解析出NALU 单元然后送至*进行解码播放。该流媒体传输系统的框架如图3 所示。 5. 结论
本文所设计的流媒体传输系统服务器端运行在Windows XP 系统用VLC 播放器作为客户端接收H.264 视频RTP 数据包。经测试客户端在经过2 秒的缓冲过后即能流畅播放,传输速度设为 30 帧每秒的情况下未出现丢包拖影等现象视频主观质量良好与本地播放该H.264 视频无明显区别。
AnyChat采用国际领先的视频编码标准H.264MPEG-4 part 10 AVC /H.264编码H.264/AVC 在压缩效率方面有着特殊的表现一般情况下达到 MPEG-2 及 MPEG-4 简化类压缩效率的大约 2 倍。H.264具有许多与旧标准不同的新功能它们一起实现了编码效率的提高。特别是在帧内预测与编码、帧间预测与编码、可变矢量块大小、四分之一像素运动估计、多参考帧预测、自适应环路去块滤波器、整数变换、量化与变换系数扫描、熵编码、加权预测等实现上都有其独特的考虑。 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
----------------------------------比特流信息----------------------------------------------
①NALU(Network Abstract Layer Unit)两标准中的比特流都是以NAL为单位每个NAL单元包含一个RBSPNALU的头信息定义了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宏块的亮度cbpcoded_block_pattern%16色度cbpcoded_block_pattern/16 。其中亮度cbp最低4位有效每位决定对应宏块的残差系数能不能为0色度cbp为0时对应残差系数为0cbp为1时DC残差系数不为0AC系数为0cbp为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打包格式就是开始的若干字节124字节是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 10MPEG-4 AVCAVCMPEG-4 (in the broadcasting world MPEG4 part 2 is ignored)H.264JVT (Joint Video Team, nowadays rarely used referring to actual spec)H.26L (early drafts went by this name) All of the above (and those Ive 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字节就在后面插入一个0x3。当解码器在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.
H.264的主要目标
1高的视频压缩比
2良好的网络亲和性
解决方案
VCL video coding layer 视频编码层 NAL network abstraction layer 网络提取层 VCL核心算法引擎块宏块及片的语法级别的定义
NAL片级以上的语法级别如序列参数集和图像参数集同时支持以下功能独立片解码起始码唯一保证SEI以及流格式编码数据传送 VCL设计目标尽可能地独立于网络的情况下进行高效的编解码 NAL设计目标根据不同的网络把数据打包成相应的格式将VCL产生的比特字符串适配到各种各样的网络和多元环境中。
NALU头结构NALU类型(5bit)、重要性指示位(2bit)、禁止位(1bit)。 NALU类型112由H.264使用2431由H.264以外的应用使用。 重要性指示标志该NAL单元用于重建时的重要性值越大越重要。 禁止位网络发现NAL单元有比特错误时可设置该比特为1以便接收方丢掉该单元。
2NAL语法语义
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的优先级。03取值越大表示当前NAL越重要需要优先受到保护。如果当前NAL是属于参考帧的片或是序列参数集或是图像参数集这些重要的单位时本句法元素必需大于0。 Nal_unit_type当前NAL 单元的类型
3H.264的NAL层处理
结构示意图 NAL以NALUNAL 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层输出的比特流SODBString Of Data Bits到nal_unit之间经过了以下三步处理 1.SODB字节对齐处理后封装成RBSPRaw Byte Sequence Payload。 2.为防止RBSP的字节流与有序字节流传送方式下的SCPstart_code_prefix_one_3bytes0x000001出现字节竞争情形循环检测RBSP前三个字节在出现字节竞争时在第三字节前加入emulation_prevention_three_byte 0x03具体方法
nal_unit( NumBytesInNALunit ) {forbidden_zero_bitnal_ref_idcnal_unit_typeNumBytesInRBSP 0for( i 1; i NumBytesInNALunit; i ) {if( i 2 NumBytesInNALunit next_bits( 24 ) 0x000003 ) {rbsp_byte[ NumBytesInRBSP ]rbsp_byte[ NumBytesInRBSP ]i 2emulation_prevention_three_byte /* equal to 0x03 */} elserbsp_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个字节的前缀即同步字节。在比特流应用中每个图像需要增加一个附加字节作为边界定位。还有一种可选特性在字节流中增加附加数据用做扩充发送数据量能实现快速边界定位恢复同步 Case2IP网络的RTP打包封装 分组打包的规则 (1)额外开销要少使MTU尺寸在10064k字节范围都可以 (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文件存储和多媒体信息文件服务 3MPEG-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单元以前发送并且重复传送大大提高纠错能力。序列和图像参数集可以在“带内”也可以用更为可靠的其他“带外”通道传送。 本文福利 免费领取C音视频学习资料包学习路线大纲、技术视频/代码内容包括音视频开发面试题FFmpeg webRTC rtmp hls rtsp ffplay 编解码推拉流srs↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓
