ios音视频--H264结构与码流

H264结构

我们通过H264压缩技术得到了一帧帧的H264视频帧, 每一个视频帧实际上是一个结构化的东西, 我们看下面这个图:

H264结构图

这张图的最上面是一串压缩后的视频帧序列, 我们取其中的一帧, 我们可以看到, 每一帧(或者说图像)都是由多个片组成, 每一个片都是由一个个宏块组成, 每一个宏块又可以分成多个子块, 这就是一个H264帧的结构.

H264编码分层

H264在编码的时候分成了两层: NAL层和VCL层

NAL层

NAL层(Network Abstraction Layer, 视频数据网络抽象层). 它的作用是拆包和组包, 我们编码的H264最终要在网络上进行传输, 以太网的传输单元是每个包不能超过1500个字节, 而H264的帧往往大于1500字节, 所以我们需要对它进行拆包, 讲一个帧拆成多个包进行传输. 所有的拆包和组包都是通过NAL层去处理的.

VCL层

VCL层 (Video Coding Layer, 视频数据编码层). 它的作用就是对视频原始数据进行压缩.

码流的基本概念

SODB (String of Data Bits, 原始数据比特流), 因为它是流, 所以它的长度不一定是8的整数倍. 它是由VCL层产生的, 因为它不是8的整数倍所以处理起来比较麻烦

RBSP (Raw Byte Sequence Payload, SODB + trailing bits) 算法是在SODB最后一位补1, 不按字节对齐补0, 如果补齐0, 不知道在哪里结束, 所以补1, 如果不够8位则按位补0.

EBSP (Encapsulate Byte Sequence Payload) 就是生成压缩流之后, 我们还要在每个帧之前加一个起始位, 起始位一般是十六进制的0001. 但是在整个编码后的数据里, 可能会出来连续的2个0x00. 那这样就与起始位产生了冲突, 这应该怎么处理呢? H264规范里说明了处理2个连续的0x00, 就额外增加一个0x03, 这样就能预防压缩后的数据与起始位产生冲突.