从NALU解析到播放器兼容：H.264 Annex B格式的完整处理流程详解

从字节流到画面：构建一个健壮的H.264 Annex B流处理引擎

如果你刚刚踏入音视频开发的大门，面对一堆十六进制字节流和复杂的协议文档，可能会感到无从下手。特别是当你试图让一段H.264裸流在浏览器中流畅播放时，常常会遇到黑屏、花屏或者解码失败的问题。这背后，往往是对H.264 Annex B格式的处理不够完善导致的。与封装在MP4等容器中、自带长度信息的AVCC格式不同，Annex B格式的流更像是一串连续的、需要你自己去“断句”的字节序列。它广泛存在于实时流媒体传输、广播信号以及一些原始的录像文件中。本文将带你深入Annex B格式的腹地，从最底层的字节解析开始，一步步构建一个完整的处理链路，并最终实现在Chrome浏览器中的兼容播放。我们不仅会讲清楚原理，更会提供可直接运行的代码片段和实用的调试技巧，让你能亲手搭建起这个处理引擎。

1. 理解H.264 Annex B格式的“语法”

在开始动手写代码之前，我们必须像学习一门新语言的语法一样，彻底理解Annex B格式的构成规则。这不仅仅是知道几个概念，而是要明白数据是如何组织、如何被正确解读的。

1.1 NALU：视频数据的基本单元

H.264编码后的输出并不是一整帧画面数据，而是被分割成一个个称为网络抽象层单元的独立包，也就是我们常说的NALU。每个NALU都是一个自包含的语法结构，可以独立传输和处理。理解NALU的结构是解析一切的基础。

每个NALU的第一个字节（称为NAL Header）包含了至关重要的信息。我们可以通过位运算来提取它们：

def parse_nalu_header(nalu_header_byte):
    """
    解析NALU头字节
    :param nalu_header_byte: 一个字节的整数（0-255）
    :return: 字典，包含禁止位、重要性指示和NALU类型
    """
    forbidden_zero_bit = (nalu_header_byte >> 7) & 0x01  # 第1位，必须为0
    nal_ref_idc = (nalu_header_byte >> 5) & 0x03         # 第2-3位，重要性
    nal_unit_type = nalu_header_byte & 0x1F              # 第4-8位，类型
    return {
        'forbidden_zero_bit': forbidden_zero_bit,
        'nal_ref_idc': nal_ref_idc,
        'nal_unit_type': nal_unit_type
    }

# 示例：解析一个头字节 0x67 (二进制: 0110 0111)
header_info = parse_nalu_header(0x67)
print(f"类型: {header_info['nal_unit_type']}")  # 输出: 类型: 7 (SPS)

NALU主要分为两大类：VCL和Non-VCL。VCL包含实际的视频编码切片数据，而Non-VCL则承载了解码所需的元数据。对于播放器来说，有几类关键的NALU必须被正确处理：

NALU 类型值	英文全称	中文名称	类别	关键作用
7	Sequence Parameter Set	序列参数集	Non-VCL	包含解码器配置信息，如档次、级别、分辨率、帧率。
8	Picture Parameter Set	图像参数集	Non-VCL	包含熵编码模式、切片组等图像解码参数。
5	Coded slice of an IDR picture	IDR图像切片	VCL	即时解码刷新帧，是关键帧，其后的帧不参考此帧之前的帧。
1	Coded slice of a non-IDR picture	非IDR图像切片	VCL	普通的P帧或B帧。
6	Supplemental enhancement information	补充增强信息	Non-VCL	包含时间戳、用户数据等附加信息。
9	Access unit delimiter	访问单元分隔符	Non-VCL	可选，用于标识一个完整帧（访问单元AU）的开始。

提示：一个完整的帧（称为访问单元，AU）可能由一个或多个NALU组成。通常，一个AU以可选的AUD开始，后跟SPS、PPS，然后是一个或多个VCL NALU（切片）。解码器需要收集齐一个AU的所有NALU后才能解码出一帧图像。

1.2 起始码与防竞争字节：Annex B的“标点符号”

Annex B格式没有像AVCC那样在每个NALU前放置一个长度字段。那么解码器如何知道一个NALU从哪里开始，又到哪里结束呢？答案就是起始码。

起始码是一个特殊的字节序列，用于标记NALU的边界。它有两种形式：

• 3字节起始码：0x00, 0x00, 0x01
• 4字节起始码：0x00, 0x00, 0x00, 0x01

4字节起始码通常用于流中的随机访问点（如SPS、PPS、IDR帧开头），以便于字节对齐和快速定位。而3字节起始码用于流内其他NALU，以节省带宽。在解析时，我们寻找这些起始码序列，它们之间的数据就是一个NALU（不包括起始码本身）。

然而，问题来了：如果NALU的原始数据中，恰好包含了0x00, 0x00, 0x01这样的序列怎么办？解码器会错误地认为这是一个新的NALU开始。为了防止这种“竞争”，H.264标准引入了防竞争字节机制。

规则是：在生成NALU的原始字节序列载荷（RBSP）时，如果出现连续两个0x00字节后紧跟一个0x00、0x01、0x02或0x03的情况，就在这两个0x00之后插入一个0x03字节。因此：

• 0x00, 0x00, 0x00 会变成 0x00, 0x00, 0x03, 0x00
• 0x00, 0x00, 0x01 会变成 0x00, 0x00, 0x03, 0x01

这样，在NALU的有效载荷中，永远不会出现真正的3字节起始码。我们的解析器在找到起始码、提取出NALU数据后，必须反向操作，删除这些插入的0x03字节，才能得到原始的RBSP数据供解码器使用。这是Annex B解析中最容易出错的一个环节。

2. 构建Annex B流解析器

理论清晰后，我们进入实战环节。我们将用Python构建一个健壮的Annex B流解析器。选择Python是因为其语法清晰，易于理解原理，你可以轻松地将其思路移植到C++、JavaScript等其他语言。

2.1 核心解析算法实现

解析器的核心任务是：输入一个包含Annex B格式H.264流的字节数组，输出一个NALU对象的列表。每个NALU对象应包含其类型、重要性、原始数据以及处理后的RBSP数据。

import struct
from dataclasses import dataclass
from typing import List, Optional

@dataclass
class NALUnit:
    """表示一个NALU的数据类"""
    start_code_length: int  # 起始码长度，3或4
    forbidden_zero_bit: int
    nal_ref_idc: int
    nal_unit_type: int
    raw_data: bytes  # 包含防竞争字节的原始数据
    rbsp_data: bytes # 去除防竞争字节后的RBSP数据

class AnnexBParser:
    def __init__(self):
        self.three_byte_start_code = b'\x00\x00\x01'
        self.four_byte_start_code = b'\x00\x00\x00\x01'

    def find_next_start_code(self, data: bytes, offset: int) -> Optional[tuple]:
        """
        从指定偏移开始，查找下一个起始码的位置和长度。
        返回 (起始码开始位置, 起始码长度)，如果未找到则返回 (None, None)。
        """
        data_len = len(data)
        i = offset
        while i < data_len:
            # 检查4字节起始码
            if i + 4 <= data_len and data[i:i+4] == self.four_byte_start_code:
                return i, 4
            # 检查3字节起始码
            if i + 3 <= data_len and data[i:i+3] == self.three_byte_start_code:
                # 需要确保前面不是0x00，即不是4字节起始码的一部分
                if i == 0 or data[i-1] != 0x00:
                    return i, 3
            i += 1
        return None, None

    def remove_emulation_prevention_bytes(self, data: bytes) -> bytes:
        """
        从NALU数据中移除防竞争字节(0x03)。
        规则：遇到 0x00 0x00 0x03 序列，且第三个字节为 0x00, 0x01, 0x02, 0x03 之一时，删除0x03。
        """
        if not data:
            return b''
        rbsp = bytearray()
        i = 0
        data_len = len(data)
        while i < data_len:
            # 检查是否可能为防竞争字节模式
            if i + 2 < data_len and data[i] == 0x00 and data[i+1] == 0x00 and data[i+2] == 0x03:
                # 确认是防竞争模式（第三个字节在特定范围内）
                if i + 3 < data_len and data[i+3] <= 0x03:
                    rbsp.append(data[i])
                    rbsp.append(data[i+1])
                    # 跳过0x03，直接添加下一个字节（在下次循环）
                    i += 3
                    continue
            rbsp.append(data[i])
            i += 1
        return bytes(rbsp)

    def parse(self, data: bytes) -> List[NALUnit]:
        """
        主解析函数：将Annex B字节流解析为NALU列表。
        """
        nalus = []
        offset = 0
        data_len = len(data)
        prev_start_pos = None
        prev_start_code_len = None

        while offset < data_len:
            # 查找下一个起始码
            start_pos, start_code_len = self.find_next_start_code(data, offset)
            if start_pos is None:
                # 没有找到更多起始码，剩余数据可能是一个不完整的NALU或垃圾数据，通常丢弃
                break

            # 如果之前已经找到一个起始码，那么两个起始码之间的数据就是一个NALU
            if prev_start_pos is not None:
                nalu_start = prev_start_pos + prev_start_code_len
                nalu_end = start_pos
                nalu_raw_data = data[nalu_start:nalu_end]

                if nalu_raw_data:  # 确保有数据
                    # 解析NALU头
                    nalu_header = nalu_raw_data[0]
                    forbidden_zero_bit = (nalu_header >> 7) & 0x01
                    nal_ref_idc = (nalu_header >> 5) & 0x03
                    nal_unit_type = nalu_header & 0x1F

                    # 去除防竞争字节，获取RBSP
                    rbsp_data = self.remove_emulation_prevention_bytes(nalu_raw_data)

                    nalus.append(NALUnit(
                        start_code_length=prev_start_code_len,
                        forbidden_zero_bit=forbidden_zero_bit,
                        nal_ref_idc=nal_ref_idc,
                        nal_unit_type=nal_unit_type,
                        raw_data=nalu_raw_data,
                        rbsp_data=rbsp_data
                    ))

            # 更新前一个起始码信息，并移动偏移量到当前起始码之后继续查找
            prev_start_pos, prev_start_code_len = start_pos, start_code_len
            offset = start_pos + 1  # 移动一位继续搜索，避免无限循环

        # 处理最后一个起始码之后的NALU（流结尾）
        if prev_start_pos is not None:
            nalu_start = prev_start_pos + prev_start_code_len
            nalu_raw_data = data[nalu_start:]
            if nalu_raw_data:
                nalu_header = nalu_raw_data[0]
                forbidden_zero_bit = (nalu_header >> 7) & 0x01
                nal_ref_idc = (nalu_header >> 5) & 0x03
                nal_unit_type = nalu_header & 0x1F
                rbsp_data = self.remove_emulation_prevention_bytes(nalu_raw_data)
                nalus.append(NALUnit(
                    start_code_length=prev_start_code_len,
                    forbidden_zero_bit=forbidden_zero_bit,
                    nal_ref_idc=nal_ref_idc,
                    nal_unit_type=nal_unit_type,
                    raw_data=nalu_raw_data,
                    rbsp_data=rbsp_data
                ))

        return nalus

这个解析器采用了双指针滑动的方式查找起始码，能高效地分割出每个NALU。remove_emulation_prevention_bytes函数是正确性的关键，它小心翼翼地移除那些为了规避与起始码竞争而插入的0x03字节。

2.2 处理边界情况与错误恢复

真实的流数据可能不完美，可能会遇到文件损坏、网络丢包或编码器输出异常等情况。一个工业级的解析器必须考虑这些边界情况。

• 残缺的起始码：流末尾可能只剩0x00 0x00，构不成完整的起始码。我们的解析器在find_next_start_code函数中通过检查数组边界来避免越界访问，并会停止解析。
• 错误的防竞争字节：理论上，防竞争字节只应在特定模式后出现。但有些编码器可能不规范。更健壮的做法是，在移除0x03时，不仅检查前两个字节是0x00，还检查0x03后面的字节是否确实在0x00-0x03范围内。上面的代码已经实现了这一点。
• 无起始码的头部数据：有些流文件开头可能没有起始码，直接就是SPS。我们可以在解析前，手动在流起始位置插入一个虚拟的“前一个起始码”位置为-start_code_len，从而将开头的NALU也纳入解析。或者更简单地在解析循环开始前，先判断流开头是否有起始码，如果没有，则假设偏移量0就是第一个NALU的开始。

    def parse_robust(self, data: bytes) -> List[NALUnit]:
        """更健壮的解析版本，处理开头无起始码的情况。"""
        # 检查数据开头是否有起始码
        if not (data.startswith(self.three_byte_start_code) or data.startswith(self.four_byte_start_code)):
            # 假设开头就是一个NALU，我们手动添加一个虚拟的“前一个起始码”
            # 这里我们简单地在数据前拼接一个3字节起始码，并记录偏移
            virtual_data = self.three_byte_start_code + data
            parsed = self.parse(virtual_data)
            # 修正第一个NALU的起始码长度为0（因为它是虚拟的）
            if parsed:
                parsed[0].start_code_length = 0
            return parsed
        return self.parse(data)

注意：处理残缺数据时，是选择尽力解析、跳过错误还是直接报错，取决于你的应用场景。对于播放器，通常需要较强的容错能力，可能会记录错误并尝试跳到下一个可靠的起始点（如下一个SPS/PPS或IDR帧）继续解码。

3. 为Web播放准备：封装成MediaSource可用的格式

解析出NALU只是第一步。我们的目标是在Chrome等现代浏览器中播放这些数据。浏览器通过<video>标签和MediaSource Extensions API来播放媒体。对于H.264视频，浏览器通常期望接收封装在ISO BMFF（类似MP4片段）格式中的AVCC格式数据，或者通过video/mp4; codecs="avc1.xxxxxx"这样的MIME类型指定的格式。直接喂给浏览器Annex B裸流是行不通的。

因此，我们需要一个转封装或实时转换的过程。有两种主流思路：

1. 服务端转换：在服务器端将Annex B流转封装成标准的MP4片段（Fragmented MP4）或MPEG-2 TS流，再通过HTTP或WebSocket推送给前端。这是最规范、兼容性最好的方式，但需要服务器端支持。
2. 客户端实时转换：在前端JavaScript中，实时接收Annex B流，将其转换为浏览器MediaSource API可以接受的格式（通常是封装了AVCC格式的MP4片段）。这种方式更灵活，适合WebRTC、WebSocket等实时流场景。

我们将重点介绍第二种方式，因为它更贴近“手把手实现”的主题。核心在于，我们需要动态生成MP4文件的一些必要盒子（Box），并将NALU数据以AVCC格式打包进去。

3.1 构建MP4初始化片段（Initialization Segment）

初始化片段包含了让解码器开始工作所必需的信息：SPS和PPS。在AVCC格式中，这些信息存放在avcC盒子（AVC Decoder Configuration Record）里。

首先，我们需要从解析出的NALU列表中提取出SPS和PPS。通常，它们在流的前部，在IDR帧之前。

// 假设我们已经用类似Python的逻辑（通过WebAssembly或翻译成JS）解析出了NALU列表 `naluList`
function extractSpsPps(naluList) {
    let sps = null;
    let pps = null;
    for (let nalu of naluList) {
        if (nalu.nalUnitType === 7) { // SPS
            // nalu.rbspData 是去除防竞争字节后的数据
            sps = new Uint8Array(nalu.rbspData);
        } else if (nalu.nalUnitType === 8) { // PPS
            pps = new Uint8Array(nalu.rbspData);
        }
        // 通常找到一对就可以停止了，但有些流可能有多个SPS/PPS
        if (sps && pps) {
            break;
        }
    }
    return { sps, pps };
}

然后，我们需要构造avcC盒子。其结构如下表所示（基于ISO/IEC 14496-15）：

字段	长度 (字节)	描述
版本	1	总是 0x01
AVC Profile Indication	1	来自SPS的 profile_idc
AVC Compatibility	1	来自SPS的 constraint_set_flags (通常取sps[1])
AVC Level Indication	1	来自SPS的 level_idc
长度尺寸MinusOne	1 (低6位)	(NALULengthSizeMinusOne & 0x03)，表示NALU长度字段的字节数-1。通常为3，表示4字节长度。
SPS 数量	1 (低5位)	SPS的个数，通常为1。
SPS 长度	2	下一个SPS数据的长度（大端序）。
SPS 数据	可变	SPS的NAL Unit数据（注意，是包含起始字节的完整NALU，即RBSP前加上NALU头）。
PPS 数量	1	PPS的个数，通常为1。
PPS 长度	2	下一个PPS数据的长度（大端序）。
PPS 数据	可变	PPS的NAL Unit数据。

注意：avcC盒子中存储的SPS/PPS数据，是包含NALU头字节（0x67, 0x68等）的完整NALU，而不是纯粹的RBSP。这一点很容易混淆。

下面是一个简化版的JavaScript函数，用于生成avcC盒子的字节数据：

function createAvccBox(spsNalu, ppsNalu) {
    // spsNalu 和 ppsNalu 是完整的NALU字节数组（包括NALU头）
    // 例如 spsNalu[0] = 0x67, ppsNalu[0] = 0x68

    const configLength = 11 + spsNalu.length + ppsNalu.length; // 基础长度 + SPS + PPS
    const avccData = new Uint8Array(configLength);
    const view = new DataView(avccData.buffer);
    let offset = 0;

    // 版本
    avccData[offset++] = 0x01;
    // AVC Profile (来自SPS第二个字节？实际上通常是sps[1])
    avccData[offset++] = spsNalu[1]; // 示例，实际解析更复杂
    // AVC Compatibility (通常取sps[2])
    avccData[offset++] = spsNalu[2];
    // AVC Level (通常取sps[3])
    avccData[offset++] = spsNalu[3];
    // 长度尺寸MinusOne (低6位为3，表示4字节长度) 和 reserved bits (全1)
    avccData[offset++] = 0xff; // 二进制 1111 1111，低6位是 11 1111，其中低2位是11(3)，高3位是111
    // 更准确的写法： (0x3 << 6) | 0x3F; // 0xFC | 0x3F = 0xFF
    // 但标准写法是： reserved(6bits) + NALULengthSizeMinusOne(2bits)。假设NALULengthSizeMinusOne=3
    // 则： 0b111111 | (0b11) = 0b11111111 = 0xFF

    // SPS 数量 (通常1个)
    avccData[offset++] = 0xe1; // 二进制 1110 0001，低5位是 00001 (1个)，高3位是111 (reserved)
    // SPS 长度 (大端序)
    view.setUint16(offset, spsNalu.length, false); // false 表示大端序
    offset += 2;
    // SPS 数据
    avccData.set(spsNalu, offset);
    offset += spsNalu.length;

    // PPS 数量 (通常1个)
    avccData[offset++] = 0x01; // 假设只有1个PPS
    // PPS 长度 (大端序)
    view.setUint16(offset, ppsNalu.length, false);
    offset += 2;
    // PPS 数据
    avccData.set(ppsNalu, offset);
    // offset += ppsNalu.length; // 不需要了

    return avccData;
}

有了avcC数据，我们就可以构建完整的MP4初始化片段了。初始化片段主要包含ftyp（文件类型）和moov（电影元数据）盒子，而moov盒子下包含trak（轨道），trak下包含mdia（媒体信息），mdia下包含minf（媒体信息），minf下包含stbl（采样表），stbl下包含stsd（采样描述），stsd里面就是包含avcC的avc1盒子。手工构建这一切非常繁琐。在实际项目中，我们通常会使用一些库来简化操作，比如mp4box.js。但为了理解原理，下面给出一个极度简化的初始化片段结构概念：

1. ftyp盒子：声明文件兼容性。
2. moov盒子：
   • mvhd：电影头，包含时间尺度、时长。
   • trak：
     • tkhd：轨道头。
     • mdia：
       • mdhd：媒体头。
       • hdlr：处理器，声明这是视频轨道。
       • minf：
         • vmhd：视频媒体头。
         • dinf：数据信息。
         • stbl：采样表，其中stsd包含了avc1和avcC。

3.2 构建媒体片段（Media Segment）与实时转换

对于实时流，我们更关注媒体片段。一个媒体片段包含一个moof（电影片段）盒子和一个mdat（媒体数据）盒子。moof描述了mdat中数据样本（帧）的时间戳、大小等信息，mdat则存放实际的视频数据。

我们的任务是将连续的Annex B NALU流，转换成一系列这样的媒体片段。关键步骤是：

1. 识别访问单元（AU）：将连续的NALU按照AUD（如果存在）或帧类型（IDR、非IDR）组合成完整的帧。
2. 转换NALU格式：将Annex B格式的NALU（以起始码分隔）转换成AVCC格式（每个NALU前加长度前缀）。长度前缀的字节数由初始化片段中的NALULengthSizeMinusOne决定（通常是4字节）。
3. 打包进mdat：将转换后的NALU数据（包含长度前缀）按顺序拼接起来，放入mdat盒子的数据区。
4. 构建moof：为这个mdat中的每一帧（样本）创建trun（Track Fragment Run）条目，指定样本大小、时长、关键帧标志等。时间戳需要根据帧率或接收时间计算。

下面是一个简化的JavaScript函数，用于将一组NALU（代表一个AU）转换为AVCC格式并添加长度前缀：

function convertNalusToAvcc(naluArray, lengthSize = 4) {
    // naluArray: 每个元素是Uint8Array类型的NALU数据（包含NALU头）
    // lengthSize: 长度前缀的字节数，通常是4
    let totalLength = 0;
    // 计算总长度：每个NALU的长度 + 每个NALU的长度前缀
    for (let nalu of naluArray) {
        totalLength += lengthSize + nalu.length;
    }
    const avccData = new Uint8Array(totalLength);
    const view = new DataView(avccData.buffer);
    let offset = 0;

    for (let nalu of naluArray) {
        // 写入长度前缀（大端序）
        if (lengthSize === 4) {
            view.setUint32(offset, nalu.length, false);
        } else if (lengthSize === 2) {
            view.setUint16(offset, nalu.length, false);
        } else if (lengthSize === 1) {
            view.setUint8(offset, nalu.length);
        } // 理论上还有3，但不常见
        offset += lengthSize;
        // 写入NALU数据
        avccData.set(nalu, offset);
        offset += nalu.length;
    }
    return avccData;
}

在实时流中，每当收集到一个完整的帧（AU）的NALU后，就调用此函数生成AVCC数据块，然后将其与对应的moof盒子数据一起，通过MediaSource的SourceBuffer追加到播放器中。

// 伪代码，展示如何追加片段
function appendFrameToMediaSource(videoElement, sps, pps, frameNalus, timestamp) {
    // 1. 如果MediaSource还未初始化，先创建并设置初始化片段
    // 2. 将frameNalus转换成AVCC格式数据块
    const avccFrameData = convertNalusToAvcc(frameNalus, 4);
    // 3. 构建一个包含此帧的MP4片段（moof + mdat）
    const mp4Segment = buildMp4SegmentForFrame(avccFrameData, timestamp, isKeyFrame);
    // 4. 将mp4Segment (ArrayBuffer) 追加到 videoElement 的 sourceBuffer 中
    sourceBuffer.appendBuffer(mp4Segment);
}

4. 调试技巧与实战问题排查

理论实现之后，真正的挑战在于调试。浏览器开发者工具是你的主要战场。

4.1 使用浏览器开发者工具

打开Chrome的开发者工具（F12），切换到Network标签页，过滤media请求。当你播放视频时，可以看到MediaSource发出的请求。点击一个请求，在Headers和Response标签页中，你可能看到的是ArrayBuffer数据。你可以将其复制为hex格式，然后用十六进制查看器分析。

更强大的是Media面板（在开发者工具的More tools中）。它可以显示当前加载的媒体片段、初始化片段的结构，以及解码器的状态。如果视频无法播放，这里通常会给出错误信息，例如DEMUXER_ERROR_NO_SUPPORTED_STREAMS（通常意味着codec字符串不对或初始化片段有问题）或BUFFER_OVERRUN等。

4.2 常见问题与排查清单

1. 黑屏，无画面，控制台无错误：

   • 检查初始化片段：确保ftyp和moov盒子结构正确，特别是avcC盒子里的SPS/PPS数据是否准确。一个错误的profile-level-id就会导致解码器初始化失败。可以尝试使用mp4box.js或ffmpeg来分析你生成的初始化片段是否正确。
   • 检查MIME类型：MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E"')，这里的42E01E需要根据你的SPS计算出来（Profile、Level等）。如果不对，浏览器会拒绝该格式。
   • 检查时间戳：确保moof盒子中的tfdt（Track Fragment Decode Time）或trun中的样本时间戳是单调递增的，且单位正确（通常是timescale的倍数）。

2. 画面花屏、卡顿或解码错误：

   • 检查防竞争字节处理：这是最常见的原因。确认在将Annex B NALU放入avcC或mdat前，已经正确移除了防竞争字节。而在将NALU从mdat中提取出来转换回Annex B时（如果需要），则需要添加防竞争字节。你的处理流程必须一致。
   • 检查NALU顺序：确保一个访问单元（AU）内的NALU顺序正确。通常是：AUD(可选) -> SPS -> PPS -> SEI(可选) -> IDR Slice / Slice。顺序错乱会导致解码器无法解析。
   • 检查关键帧：浏览器通常需要在第一个媒体片段中包含一个关键帧（IDR帧）。如果第一个moof里都是P帧/B帧，可能会播放失败。

3. 内存增长与缓冲问题：

   • 及时清理SourceBuffer：使用sourceBuffer.remove(startTime, endTime)来移除已经播放过的缓冲数据。否则缓冲会无限增长，导致内存耗尽。
   • 注意appendBuffer的异步性：在updateend事件触发前，不要进行下一次appendBuffer操作，否则会抛出QuotaExceededError。
   • 合理设置appendWindowStart/End：可以用于控制缓冲的时间范围。

4.3 实用调试代码片段

在JavaScript中，打印关键的二进制信息对于调试至关重要。

function logHex(data, name = 'Data') {
    // data 可以是 ArrayBuffer 或 Uint8Array
    const uint8 = new Uint8Array(data);
    let hexStr = '';
    for (let i = 0; i < Math.min(uint8.length, 128); i++) { // 只打印前128字节
        hexStr += ('00' + uint8[i].toString(16)).slice(-2) + ' ';
        if ((i + 1) % 16 === 0) hexStr += '\n';
    }
    console.log(`${name} (first ${Math.min(uint8.length, 128)} bytes):\n${hexStr}`);
}

// 在关键步骤打印，例如转换前后的NALU
logHex(spsNalu, 'SPS NALU');
logHex(avccData, 'AVCC Box Data');
logHex(mp4Segment, 'MP4 Segment');

处理音视频流就像在解构和重构一座精密的时钟。每一个字节都有其意义，每一步处理都关乎最终能否呈现出流畅的画面。从Annex B字节流的解析，到防竞争字节的微妙处理，再到为Web播放器精心准备MP4格式的“食粮”，这个过程充满了细节。我最初实现这个流程时，花了大量时间在花屏问题上，最终发现是SPS/PPS提取时多截了一个字节。另一个坑是时间戳的计算，没有考虑到timescale，导致播放速度异常。这些经验让我深刻体会到，在音视频开发中，对数据格式的精确把握和耐心的调试是通往成功的不二法门。当你看到自己处理的裸流在浏览器中清晰播放时，那种成就感是无与伦比的。