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

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

PAT表是解析MPEG-TS流的关键起点，它固定位于PID为0x0000的TS包中。解析时需通过payload_unit_start_indicator标志定位新表起始，正确处理adaptation field以找到payload，校验table_id=0x00及section_syntax_indicator=1，并根据section_length和CRC32重组跨包数据，最终提取节目号（program_number）及其对应的PMT PID，为后续解析音视频流奠定基础。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

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

解析MPEG-TS流的第一步，是准确找到并提取节目关联表（PAT）。PAT表是流中所有节目信息的目录，它始终位于PID为 0x0000 的传输包中。但需要注意，PAT数据可能被分割到多个TS包中传输，也可能被重复发送以增强抗干扰能力。因此，解析流程的第一步是筛选出所有 pid == 0x0000 的TS包，然后利用TS包头中的 payload_unit_start_indicator 标志（位于第4字节的第4位）来判断当前包是否是一个新表格数据的开始。

一个常见的解析误区是直接读取TS包payload的前几个字节作为表头，而忽略了 adaptation_field_control 字段。该字段决定了TS包的有效载荷结构：若其值为 0b10（仅有有效载荷）或 0b11（既有适配字段又有有效载荷），你需要先跳过可能存在的adaptation field，才能定位到真正的payload起始位置；若为 0b01（仅有适配字段），则该包不含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 section并校验CRC

PAT表的一个数据段（section）长度可能超过单个TS包payload的最大容量（184字节），因此经常被拆分到多个包中传输。解析时绝不能假设单个TS包包含完整section。正确的方法是依据 section_length 字段（位于payload的第1和第2字节，由高4位和后12位组成）以及 last_section_number（payload第7字节）等信息进行数据重组。

另一个至关重要的步骤是CRC32校验。MPEG-TS标准强制规定，PAT表section末尾的4个字节必须是符合ISO/IEC 13818-1标准的CRC校验码，校验范围从 table_id 开始，直至CRC字节之前的所有数据。如果跳过此校验，可能会将因传输错误而损坏的PAT表误判为正确，导致后续提取的PMT PID全部错误，整个解析流程失败。

在具体编程实现时，建议遵循以下方法：

• 维护一个数据缓冲区（buffer）。当收到新的payload数据时，根据 payload_unit_start_indicator 判断：若为新section起点，则清空缓冲区并写入当前payload；否则，将数据追加到缓冲区末尾。
• 当缓冲区数据大小达到 section_length + 3（其中3为table_id等固定头部字节数），且最后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 等工具分析真实流的结构，做到心中有数，再着手编码实现。