TS流解析需严格按188字节分包并校验0x47同步字节，PID定位流类型，PCR/PTS/DTS须按规范组合提取，否则导致解析错位或音画不同步。
TS流解析的核心是理解PID和包结构
TS流不是普通二进制文件，不能用fread直接当字节流读完就完事。每个188-byte包以同步字节0x47开头，后面紧跟着PID（Packet Identifier），它决定了这个包属于哪个视频流、音频流或PSI表。漏掉PID过滤或误判0x47位置（比如被误当作数据内容），就会导致后续所有解析错位。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 必须按
188字节严格分包，不要依赖文件末尾对齐——实际TS文件常有填充（0xFF）或不完整包 - 读包前先校验首字节是否为
0x47；若不匹配，需向前/向后滑动搜索，但最多跳过188*3字节，避免死循环 - 用
uint16_t pid = ((buf[1] & 0x1F) 提取PID，注意高位在<code>buf[1]低5位，不是整个字节
如何识别并提取视频/音频ES流
仅靠PID无法直接知道它是H.264还是AAC——PID只是“通道号”，真正编码类型藏在Program Map Table (PMT)里。PMT的PID由PAT（Program Association Table）指定，而PAT的PID固定为0x0000。跳过这层解析，会把所有0x100~0x1FFF范围的PID当成有效流，结果可能混入空包或私有数据。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先扫出PID为
0x0000的包，解析PAT，拿到program number对应的PMT PID - 再过滤该PMT PID，解析PMT中的
elementary_stream_type字段：值为0x1B是H.264，0x24是H.265，0x0F是AAC-LC - 记录下这些流的PID，在后续包中只保留它们，其余丢弃——否则内存会因解析大量无效PID暴涨
如何重组PES包并提取原始帧
TS包本身不携带完整帧，而是把PES（Packetized Elementary Stream）切片塞进去。一个PES帧可能跨多个TS包，也可能一个TS包含多个PES头部（尤其在adaptation_field存在时）。直接按TS包边界截取数据，会导致H.264的00 00 01起始码被劈开，解码器报invalid NAL unit。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 维护每个PID对应的PES重组缓冲区；遇到TS包中
payload_unit_start_indicator == 1（bit 4 ofbuf[1]），说明新PES开始，清空旧缓冲区 - 跳过
adaptation_field（看adaptation_field_control字段）；只取payload部分追加到缓冲区 - 对H.264，等缓冲区出现完整
00 00 01+ NAL type，并且长度足够（如NALU size > 2），才视为一帧可送解码器
常见错误：时间戳（PCR/PTS/DTS）解析偏差
TS里的时间戳不是简单整数。PCR（Program Clock Reference）占6字节，高33位是base，低9位是extension，需组合计算；PTS/DTS更复杂，要从PES头部的PTS_DTS_flags判断是否存在，再按固定偏移+掩码提取。用错位移或忽略marker_bits（固定为0x01），会导致音画不同步或播放卡顿。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- PCR解析：base =
((buf[0] & 0x3F) > 7)，extension =((buf[4] & 0x01) - PTS解析（PES header中）：先确认
PTS_DTS_flags == 0x02或0x03，再取buf[9]~buf[14]，每字节取中间3位拼成33位PTS - 别假设所有包都有PCR——只有PID为PCR_PID的包才含PCR，且未必每个包都带
最易被忽略的是TS包的continuity_counter校验：同一PID的连续包，该字段应模4递增。丢包或解析错位时它会突变，这是定位解析断裂点的关键信号，但多数初版代码直接忽略它。
