c++如何解析MPEG-TS流中的PAT与PMT节目表【深度】

C++如何解析MPEG-TS流中的PAT与PMT节目表【深度】

PAT表位于PID为0x0000的TS包中，需通过payload_unit_start_indicator标识新表起始，跳过adaptation field后解析payload，校验table_id=0x00、section_syntax_indicator=1，并按section_length和CRC32重组跨包section，最终提取program_number及对应PMT PID。

如何从TS包中定位并提取PAT表

解析MPEG-TS流，第一步往往就是找到节目关联表（PAT）。这张表固定在PID为 0x0000 的传输包中，但这里有个常见的误解：并非所有PID为0x0000的包都包含完整的PAT数据。实际情况是，它可能被拆分到多个包中，也可能被重复发送以提高鲁棒性。因此，解析的第一步是过滤出所有 pid == 0x0000 的TS包，然后依靠 payload_unit_start_indicator（位于TS包头第4字节的第4位）来判断当前包是否是一个新表格的起始点。

新手最容易踩的坑，是直接读取TS包有效载荷（payload）的前4个字节当作table_id，却忽略了 adaptation_field_control 字段的存在。这个字段决定了包内结构：如果它是 0b10（只有payload）或 0b11（既有适配字段又有payload），你需要先跳过可能存在的adaptation field，才能找到真正的payload起始位置；如果它是 0b01（只有adaptation field），那么这个包里根本就没有PAT数据，必须直接跳过。

这里有几个实用的操作建议：

• 首先校验TS包的同步字节是否为 0x47，再按188字节的结构进行解析。
• 使用 ts_header[3] & 0x40 来提取 payload_unit_start_indicator 标志。
• 计算payload偏移时，若 adaptation_field_control == 0x02，payload从第5字节开始；若为 0x03，则需要读取第5字节的 adaptation_field_length，并跳过相应字节数。
• 最后，确认PAT的 table_id 必须是 0x00，并且 section_syntax_indicator（位于payload第1字节的第7位）必须为1，否则这就不是一个有效的PAT表。

如何拼接跨包的PAT section并校验CRC

PAT表的一个section很可能跨越多个TS包，尤其是当section长度超过184字节（一个TS包payload的最大可用空间）时。所以，绝不能假设单个TS包就包含完整的section。正确的做法是依赖 section_length（位于payload的第1和第2字节，由高4位和后12位组成）和 last_section_number（payload第7字节）等信息来进行数据重组。

另一个容易被忽略的关键步骤是CRC32校验。MPEG-TS标准强制要求PAT末尾的4个字节必须是符合ISO/IEC 13818-1标准的CRC校验码，校验范围是从 table_id 开始，一直到CRC字节之前的所有数据（不包括CRC本身）。如果跳过这个校验就直接解析，可能会把被传输噪声破坏的错误PAT表当作正确的，从而导致后续PMT PID映射全部错乱，整个解析流程功亏一篑。

在具体实现时，可以遵循以下建议：

• 维护一个缓冲区（buffer）。每次收到新的payload数据时，根据 payload_unit_start_indicator 判断：如果是新section的起点，就清空缓冲区并写入当前payload；如果不是，就追加到缓冲区末尾。
• 当缓冲区的数据大小满足 section_length + 3（这里的3是table_id、section_syntax_indicator等固定头部字节数），并且最后4字节的CRC能够通过 crc32(buffer, section_length + 3) 验证时，才认为这是一个完整、有效的section。
• 需要特别注意：section_length 字段的值是“本section的总长度（包含头部和CRC）减去3”。因此，实际承载节目映射信息的有效载荷长度应为 section_length - 9（减去3字节的头部、4字节的CRC以及另外2字节的固定字段）。

如何从PAT获取PMT PID并识别节目号

PAT表的核心内容，就是零个或多个 program_map_PID 字段，每个字段占4个字节。这4个字节的结构是：前16位是 program_number（节目号），紧接着的4位是保留位，最后的12位则是对应PMT表的PID。

这里有一个至关重要的细节：如果 program_number 是 0x0000，那么它指向的不是普通节目，而是NIT（网络信息表）的PID，解析时需要跳过。除此之外的所有 program_number，就是逻辑频道号，通常用于在用户界面上显示频道列表。

提取PID字段时需要小心，因为它只有13位（bit 0~12），但却存储在两个字节中。组合方式如下：假设两个字节为 b0 和 b1，那么 PID = ((b0 & 0x1f) （b0的低5位 + b1的全部8位）。

在编程实践中，建议这样做：

• 从PAT payload的第8个字节开始，以每4个字节为一组进行遍历，直到达到 section_length 指定的边界。
• 对于每个解析出的program_number，检查是否已经存在映射关系，避免重复注册同一节目号的多个PMT PID（虽然标准允许，但在实际流中非常罕见）。
• 一旦记录下 program_number → pmt_pid 的映射，就应该立即启动对该 pmt_pid（例如 0x0102）的TS包监听，而不是等待下一次PAT表的轮询，这样可以加快频道切换速度。
• 值得注意的是，某些加密流或动态流会变更PMT的PID。此时仅靠PAT提供的初始值可能不够，需要结合PMT表中的 version_number 和 current_next_indicator 字段来判断是否需要更新PID映射。

如何解析PMT并提取音视频ES PID与stream_type

节目映射表（PMT）位于PAT指定的PID上，其 table_id 必须为 0x02，同样需要进行CRC32校验。PMT的结构比PAT更复杂：除了固定头部，它还包含PCR_PID、program_info_length，以及一个可变长度的基本流（ES）循环体。

解析过程中最容易出错的地方就是ES循环体。每个ES描述块以1字节的 stream_type 开头，后面跟着2字节的 elementary_PID（PID的提取方式与PAT中相同），再后面是2字节的 ES_info_length，最后才是描述符（descriptor）数据。如果忽略了 ES_info_length，直接去读取下一个 stream_type，会导致字节偏移完全错乱，解析程序崩溃。

以下是一些关键的解析要点：

• elementary_PID 是音视频基本流的实际PID，例如H.264视频流常用 0x0100~0x01ff 范围，AAC音频流常用 0x0110~0x01ff。但这些值完全由PMT定义，切勿在代码中硬编码假设。
• stream_type 的值需要查表对应：例如，0x01 代表MPEG-2 Video，0x0f 代表AAC，0x1b 代表H.264，0x24 代表H.265。需要注意，不同标准文档的编号可能略有差异，建议以ISO/IEC 13818-1:2018 Annex A为准。
• PCR_PID位于PMT头部（第8–9字节），用于定位解码时间基准。如果该值为 0x1fff，则表示本节目不提供PCR，需要从视频PES包中提取PTS/DTS作为同步依据。
• 描述符（descriptor）部分常常包含语言代码（ISO 639）、AC-3元数据等信息。但如果只是进行基础的音视频分离和路由，可以暂时跳过这部分，仅依靠 stream_type 和 elementary_PID 就足以完成任务。

说到底，解析PAT和PMT真正的难点，往往不在于格式本身，而在于应对TS流各种复杂的现实情况：包丢失、CRC错误、section碎片化、PID漂移、多版本并发……这些因素会让“按照规范走通流程”和“在真实环境中稳定运行”变成两件完全不同的事。尤其是广播级的TS流，常常包含非标准的填充或私有描述符。因此，一个非常实用的建议是：在动手编写解析逻辑之前，先用 dvbsnoop -s ts 或 tsdump 这类工具确认真实流的结构，做到心中有数，再下笔编码。