我们知道，h264 流格式有两种：avcC与AnnexB。
avcC 就是在 NALU 前面写上几个字节，这几个字节组成一个整数（大端字节序）这个整数表示了整个 NALU 的长度。在读取的时候，先把这个整数读出来，拿到这个 NALU 的长度，然后按照长度读取整个 NALU，我们不妨把这几个字节叫做NALU Body Length。
AnnexB 就是在一个 NALU 前面加上三个或者四个字节，这些字节的内容是 0 0 0 1 或者 0 0 1。当我们读取一个 H264 流的时候，一旦遇到 0 0 0 1 或者 0 0 1，我们就认为一个新的 NALU 开始了，因此，这些用来做分隔符的字节，一般也被称为 start code。
所以，接下来重点分析下startcode。
startcode的有两种形式
3字节的0x000001和4字节的0x00000001
为什么需要startcode？
主要是为了将相邻两个NALU划分开，让他们有一个界线，方便解码，比如将h264的数据存储在一个文件当中，解码器无法从数据流中分别每个NALU的起始位置。
在编码时，每个NALU前面添加startcode(占4字节0x00000001或者3字节0x000001)，这里有人会想到万一中间出现0x000001怎么办呢，h264有个防止竞争的机制，在编码完一个NAL时，如果出现有连续两个0x00字节，就在后面插入一个0x03（解码的时候这个0x03会被丢弃）。
startcode占4字节还是3字节？
实际上startcode只占3字节，4字节的startcode = zero_byte + start_code_prefix_one_3bytes，就是说无论啥时候其实startcode都是3字节，关键就在于zero_byte。
- 包含SPS，PPS的NALU前面要加
zero_byte（4字节）。 - 当一帧被分为多个slice时，首个NALU前面要加
zero_byte（4字节）。也就是，当一个完整的帧被编为多个slice的时候，除掉第一个NALU，剩下的都用3字节的，其余的都是4字节，这个在后面的实例分析中可以得到验证。
比如给定一组frame：
SPS （4字节头）
PPS （4字节头）
SEI （4字节头）
I0(slice0) （4字节头）
I0(slice1) （3字节头）
P1(slice0) （4字节头）
P1(slice1) （3字节头）
P2(slice0) （4字节头）
P2(slice1) （3字节头）
- I0(slice0)是序列第一帧（I帧）的第一个slice，是当前Access Unit的首个nalu，所以是4字节头。而I0(slice1)表示第一帧的第二个slice，所以是3字节头。
- P1(slice0) 、P1(slice1)同理。
h264stream文件实例分析
0x00000000的地址开始是SPS，这时候startcode是0x00000001，4个字节
0x00000019的地址开始是PPS，这时候startcode是0x00000001，4个字节
0x00000021的地址开始是SEI，这时候startcode是0x000001，3个字节
0x00000281的地址开始是第一个I帧的slice 0，这时候startcode是0x000001，3个字节
0x000002CE的地址开始是第一个I帧的slice 1，这时候startcode是0x00000001，3个字节
0x00000310的地址开始是接着的P帧的slice 0，这时候startcode是0x0000000001，4个字节
0x000006A4的地址开始是接着的P帧的slice 1，这时候startcode是0x00000001，3个字节
0x000008BA的地址开始是接着的下一个P帧的slice 0，这时候startcode是0x0000000001，4个字节
依次往后分析，每一个完整的帧开始的时候startcode都是4个字节的startcode，每个帧的slice使用3个字节的startcode分隔。
对比ffprobe生成信息
ffprobe生成frame信息文件videoframes.info：
ffprobe -show_frames -select_streams v -of xml 256x144.h264 > videoframes.info
简化这个xml文件内容后如下：
<?xml version="1.0" encoding="UTF-8"?>
<ffprobe>
<frames>
<frame pkt_pos="0" pkt_size="784" pict_type="I">
<side_data_list>
<side_data side_data_type="H.26[45] User Data Unregistered SEI message"/>
</side_data_list>
</frame>
<frame pkt_pos="784" pkt_size="1450" pict_type="P" coded_picture_number="1" />
<frame pkt_pos="2234" pkt_size="2951" pict_type="P" coded_picture_number="2" />
<frame pkt_pos="5185" pkt_size="3647" pict_type="P" coded_picture_number="3" />
<frame pkt_pos="8832" pkt_size="644" pict_type="P" coded_picture_number="4" />
<frame pkt_pos="9476" pkt_size="952" pict_type="P" coded_picture_number="5" />
<frame pkt_pos="10428" pkt_size="981" pict_type="P" coded_picture_number="6" />
<frame pkt_pos="11409" pkt_size="678" pict_type="P" coded_picture_number="7" />
<frame pkt_pos="12087" pkt_size="1003" pict_type="P" coded_picture_number="8" />
<frame pkt_pos="13090" pkt_size="415" pict_type="P" coded_picture_number="9" />
<frame pkt_pos="13505" pkt_size="772" pict_type="P" coded_picture_number="10"/>
<frame pkt_pos="14277" pkt_size="799" pict_type="P" coded_picture_number="11"/>
<frame pkt_pos="15076" pkt_size="424" pict_type="P" coded_picture_number="12"/>
<frame pkt_pos="15500" pkt_size="466" pict_type="P" coded_picture_number="13"/>
<frame pkt_pos="15966" pkt_size="745" pict_type="P" coded_picture_number="14"/>
</frames>
</ffprobe>
从这个结果对比后面的代码分析，ffprobe拿到的frame 0的信息，packet size是784，刚好是从起始地址到I帧结束的大小，0x00000310换算成10进制就是784，对比流的16进制和后面代码对stream的解析来看，ffprobe给出的信息第一个frame的实际上包含了SPS，PPS，SEI，I帧数据，在SPS和PPS前面的startcode是4个字节，而后面的程序解析，frame#0是SPS，frame#1是包含PPS和SEI的I帧。
代码解析startcode
后面的这段代码解析前面的h264stream文件，然后打印每一个frame的大小，通过输出信息来看，和前面的xml统计信息符合，区别就是Frame 0和Frame 1的输出分别是SPS和PPS的4个字节的startcode开始的帧，这个和前面用工具分析的截图完全一致。
Frame 0: 25 bytes
Frame 1: 759 bytes
Frame 2: 1450 bytes
Frame 3: 2951 bytes
Frame 4: 3647 bytes
Frame 5: 644 bytes
Frame 6: 952 bytes
Frame 7: 981 bytes
Frame 8: 678 bytes
Frame 9: 1003 bytes
Frame 10: 415 bytes
Frame 11: 772 bytes
Frame 12: 799 bytes
Frame 13: 424 bytes
Frame 14: 466 bytes
#include <stdint.h>
#include <stdio.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define START_CODE_PREFIX_LENGTH 3
#define START_CODE_LENGTH 4
int main(int argc, char *argv[])
{
FILE *fp = fopen(argv[1], "rb");
if (!fp) {
printf("Failed to open file\n");
return -1;
}
// Allocate buffer for reading file
int buffer_size = 1024 * 1024;
uint8_t *buffer = (uint8_t *)malloc(buffer_size);
// Allocate buffer for storing frame data
int frame_size = buffer_size;
uint8_t *frame = (uint8_t *)malloc(frame_size);
int frame_count = 0;
int bytes_read = 0;
int frame_start = 0;
int frame_end = 0;
int frame_length = 0;
int start_code_prefix_found = 0;
while ((bytes_read = fread(buffer, 1, buffer_size, fp)) > 0)
{
for (int i = 0; i < bytes_read; i++) {
if (!start_code_prefix_found) {
/*
* 这里用001来判断的好处是，当发现后面的四个字节是0001的时候，说明frame结
* 束，这时候buffer[i]的位置已经是下一个0001的0位置，下次循环进来的时候
* buffer指向的位置刚好是001，因为有i++运算，已经去掉了前导0
* (leading_zero_8bits)
*
* 如果是0001，那么经过i++，start_code_prefix_found的位置就是下下一个
* startcode的位置了。
*/
if (i < bytes_read - START_CODE_PREFIX_LENGTH) {
if (buffer[i] == 0x00 &&
buffer[i+1] == 0x00 &&
buffer[i+2] == 0x01) {
start_code_prefix_found = 1;
frame_start = i + START_CODE_PREFIX_LENGTH;
}
}
} else {
if (i < bytes_read - START_CODE_LENGTH) {
if (buffer[i] == 0x00 &&
buffer[i+1] == 0x00 &&
buffer[i+2] == 0x00 &&
buffer[i+3] == 0x01) {
start_code_prefix_found = 0;
frame_end = i;
frame_length = frame_end - frame_start;
if (frame_length > frame_size) {
frame_size = frame_length;
frame = (uint8_t *)realloc(frame, frame_size);
}
memcpy(frame, buffer + frame_start, frame_length);
printf("Frame %d: %d bytes\n", frame_count++, frame_length + START_CODE_LENGTH);
}
} else if (i == bytes_read-1) {
frame_length = bytes_read - frame_start;
memcpy(frame, buffer + frame_start, frame_length);
printf("Frame %d: %d bytes\n", frame_count++, frame_length + START_CODE_LENGTH);
}
}
}
}
fclose(fp);
free(buffer);
free(frame);
return 0;
}
