简介TS流解析C代码包面向数字电视与流媒体开发学习者完整实现MPEG-2 TS传输流中PAT、SDT、PMT、EIT、NIT、CAT、TDT等表的解析可在终端展示节目号、解码名称、音视频PID等信息并输入节目号保存对应音视频包供播放器直接播放。压缩包共74个文件以37个C源文件和34个头文件为核心代码另附2份PDF国际标准文档和1个exe流分析工具整体仅2.63MB目录按数组、链表等结构组织便于查阅。已有1766人浏览学习适合数字电视课程设计、毕设或协议解析入门者使用。资源不仅覆盖PSI/SI核心表解析流程还支持查看未来几天节目信息、NIT网络信息、CAT条件接收表及系统时间配合标准文档和tsr.exe工具可验证解析结果帮助读者快速掌握TS协议栈的关键实现。1. TS流解析代码一个 188 字节的小盒子卡住了一堆播放器与转码工具某开发者在做录制文件转封装时遇到过这样一件事从机顶盒导出的 TS 文件VLC 能正常出画面但自研的转码工具一打开就报“找不到可用的音视频流”。排查了很久才发现问题不在解码器而在 TS 流解析这一步——播放器愿意自动从 PAT/PMT 表里找流而他的转码工具只按 PID 硬猜把节目关联表当成了垃圾数据丢掉。TS 流最大的特点是没有文件头告诉你视频在哪、音频在哪它把 PSI 表、PES 数据、空包全部切成 188 字节的小块混在同一个连续字节流里靠 13 位 PID 来区分逻辑信道。所以“TS流解析代码”这个方向核心就是把同步字节、PID、PAT/PMT、PES 载荷逐层拆开让上层播放器或录制工具知道节目有哪些、音视频在哪个 PID 上、时间戳该怎么恢复。适合正在写播放器、直播录制、码流分析工具的开发者也适合被某些“能播但转不了码”的 TS 文件折磨的人。2. 从同步字节到 PSI 表188 字节的 TS 包结构和 PAT/PMT 的解析顺序TS 包固定 188 字节这个长度来自早期传输系统的设计约束今天几乎所有 DVB、ATSC 和部分 IPTV 流都沿用这个尺寸。解析时有个强顺序先找同步字节 0x47再解 4 字节头部接着读 PID最后按 PID 分发到 PAT、PMT 或 PES 处理函数。PAT 必须最先解析因为 PMT 的 PID 存放在 PAT 里而真正的音视频 PID 又存放在 PMT 里。这个“表找表”的间接关系就是 TS 流和一般封装格式最不一样的地方。2.1 头部 4 字节的位级解读sync_byte、PID、adaptation_field_control 与 continuity_counter每个 TS 包的前 4 字节是头部结构固定。第 1 字节必须是 0x47否则这个包无效。第 2、3 字节里有 13 位 PID是流的身份标识。第 4 字节里同时塞着加密标志、适配域控制字段和连续性计数器。字段分布参考下表。字节偏移字段位长取值与说明0sync_byte8固定 0x471transport_error_indicator1传输错误标志解析时通常忽略1payload_unit_start_indicator11 表示本包是一个 PSI/PES 段的开始1transport_priority1优先级一般不用1 ~ 2PID130x0000 是 PAT0x0011 是 SDT0x1FFF 是空包3scrambling_control20 表示未加密3adaptation_field_control21 只有载荷2 只有适配域3 两者都有3continuity_counter4同一 PID 包计数模 16 递增注意第 4 字节的位划分经常被写错bit7~6 是 scrambling_controlbit5~4 是 adaptation_field_controlbit3~0 是 continuity_counter。拿到 PID 后必须先看 adaptation_field_control值为 2 时整个包都是适配域没有任何 payload值为 3 时第 4 字节后面紧跟一个字节的 adaptation_field_length跳过这段才能取 payload。这个逻辑可以写成一个通用函数后面所有包的处理都复用它。def get_ts_payload(packet): if len(packet) 188 or packet[0] ! 0x47: return b afc (packet[3] 0x30) 4 if afc 1: return packet[4:] if afc 2: return b if afc 3: af_len packet[4] return packet[5 af_len:] return b这个函数返回的是 TS 包的 payload 部分。第一次写解析器的人最容易漏掉 afc 3 的情况直接取 packet[4:] 就把适配域当成了数据后面所有表解析都会错位。参数上没有任何需要调的东西唯一要确认的是 packet 长度必须是 188有些录制文件开头会有残留的无关字节那种情况不属于这里放到第 3 章定界时统一处理。2.2 PAT 先于 PMT从节目号拿到 PMT PIDversion_number 是缓存失效的开关PID 为 0x0000 的包携带的是 PAT 表。PAT 的 table_id 固定是 0x00payload 里第一个字节是 pointer_field通常为 0真正的表数据从第 2 个字节开始。PAT 里最核心的内容是 program_number 到 PMT_PID 的映射program_number 为 0 时这条对应 NIT可以忽略非 0 的节目号才是真正可播放的节目。很多单节目流的 PAT 里只有一个节目所以新手常以为 PAT 就是“拿到一个 PMT PID 就完事”。但 DVB 多节目流或转发流里一个 PAT 可以列出好几路节目必须循环解析。另一个必看的字段是 version_number它占据第 6 字节的 bit5~1。PAT 版本一变意味着节目映射关系整个变了旧的 PMT 必须全部作废。def parse_pat(payload): # payload 是经过 pointer_field 偏移后的数据 if len(payload) 8 or payload[0] ! 0x00: return None section_length ((payload[1] 0x0F) 8) | payload[2] version (payload[5] 1) 0x1F programs [] pos 8 end 3 section_length - 4 # 减去末尾 CRC while pos 4 end: program_number (payload[pos] 8) | payload[pos 1] pmt_pid ((payload[pos 2] 0x1F) 8) | payload[pos 3] if program_number ! 0: programs.append((program_number, pmt_pid)) pos 4 return {version: version, programs: programs}这里容易翻车的点是 section_length。它是 12 位有效长度描述的是“从第 3 字节开始直到 CRC 结束”的总长度不是 TS 包 payload 的长度。一个 PAT section 可能跨多个 TS 包必须在内存里把同一个 table_id 的连续 section 拼完整再解析。上面的代码里pos 从 8 开始是因为前 8 字节是 table_id、section_length、transport_stream_id、version、section_number、last_section_number这 6 个字段占了 8 个字节。end 用3 section_length - 4算是因为 section_length 本身从第 3 字节开始计数最后 4 字节是 CRC解析节目表时不需要吃掉它。2.3 过滤空包与多节目流为什么只按 PID 过滤会同时收到多个节目流PID 为 0x1FFF 的是空包用来填充固定码率流里的空隙。空包没有有效数据但会持续占据带宽统计 PID 流量时如果不剔掉PAT/PMT 的占比会算出一堆假数字。解析主循环里遇到 0x1FFF 直接跳过即可不用做任何处理。多节目流的情况更隐蔽PAT 里有两个节目时就对应两个不同的 PMT_PID每个 PMT 又各自带一路或多路音视频 PID。如果用“第一个 PMT 里所有 PID 都收”的写法第二个节目的音频会被误收进第一个节目的播放列表里。正确做法是建立一个节目维度的字典key 是 program_numbervalue 里存该节目的 PMT_PID、video_PID、audio_PID 列表。这样后面取某一路节目时只碰属于它的 PID不串台。这个结构在内存里叫节目表缓存第 3 章会直接用在解析器里。3. 用代码跑通一个最小 TS 解析器逐包循环、适配域跳过与三路分发这一章写一个最小但能跑的 TS 解析器语言用 Python因为改起来快、打印调试方便。设计目标不是追求极致性能而是让逻辑透明、每一步都能看到结果。解析器只有三件事定界读包、按 PID 分发、缓存 PAT/PMT 表。PES 部分下一章再加。3.1 定界与读包先连续验证 N 个 0x47 再按 188 步进直接从文件读二进制流时不能默认第一个字节就是 0x47。有些录制工具会在文件头写几字节自定义信息导致整个文件偏移 4 或 8 个字节。常见做法是先扫到第一个 0x47然后从这个位置开始按 188 步进校验连续命中 N 个包才确认是真正的 TS 流。N 取 5 或 6 就够太少容易误判太多对文件头有额外要求的场合不友好。def align_ts_packets(data, packet_len188, validate_count5): for start in range(len(data) - packet_len * validate_count): if data[start] ! 0x47: continue ok True for i in range(validate_count): if data[start i * packet_len] ! 0x47: ok False break if ok: return start return -1这个函数的思路是把每个可能是同步头的位置都试一遍只有连续 validate_count 个包都在固定偏移上出现 0x47才认为对齐成功。注意不要把 validate_count 调得太大有些 UDP 抓包文件中间有丢包丢包后同步头对不上反而找不到起始位置。返回的 start 就是从文件头到第一个有效 TS 包的偏移量之后主循环用file_data[start i * 188:start (i 1) * 188]切包即可。3.2 主循环与分发头部解包、适配域处理、把包交给 PAT/PMT/PES 各自的回调主循环的职责很单纯读 188 字节校验同步字节解头部跳过适配域然后按 PID 路由。为了可读性我把解析器写成一个类PAT 和 PMT 的处理逻辑作为独立方法PES 部分先留口子。class TSDemuxer: def __init__(self, path): self.path path self.pat None self.pmt {} # program_number - pcr_pid, streams self.continuity {} def parse_packet(self, packet): if packet[0] ! 0x47: return pusi (packet[1] 0x40) 6 pid ((packet[1] 0x1F) 8) | packet[2] afc (packet[3] 0x30) 4 cc packet[3] 0x0F if pid 0x1FFF: return if self.continuity.get(pid) is not None: expect (self.continuity[pid] 1) 0x0F if cc ! expect: self.on_cc_error(pid, expect, cc) self.continuity[pid] cc payload get_ts_payload(packet) if not payload: return if pid 0x0000: table self.parse_table(payload) if table and table[table_id] 0x00: self.on_pat(table) elif pid in self.pmt_pids(): table self.parse_table(payload) if table and table[table_id] 0x02: self.on_pmt(pid, table) elif self.is_pes_pid(pid): self.on_pes(pid, pusi, payload) def run(self): with open(self.path, rb) as f: data f.read() start align_ts_packets(data) if start 0: raise ValueError(no ts sync) for i in range(start, len(data) - 187, 188): self.parse_packet(data[i:i188])代码里三个分发目标的优先级要讲清楚。PAT 和 PMT 本身也是 TS 包不是 PES 数据所以必须先判断这两个 PID再去碰 PES。is_pes_pid 的实现要等 PMT 解析完成后才有效否则就得在 PMT 没出来时先缓存所有包的 payload等 PMT 到了再补解析。这个“等表齐了再干活”的顺序决定了你的解析器是单遍扫描还是两遍扫描。上面给的是单遍扫描版本实际使用时建议先完整解析一遍拿到节目表再跑第二遍去拼 PES逻辑上更不容易错。3.3 表缓存和版本更新PAT/PMT 放进 dictversion_number 变化时清空旧表PAT 和 PMT 是需要跨包缓存的。一个 PAT 表可能被拆到两三个 TS 包里解析时必须先把相同 table_id、相同 section_number 的 payload 片段拼起来凑满 section_length 后再交给 parse_pat 或 parse_pmt。缓存结构按 PID 维度做key 是 PIDvalue 是累计缓冲区和当前已收集长度。def parse_table(self, payload): if payload[0] ! 0x00 and payload[0] ! 0x02: return None table_id payload[0] section_length ((payload[1] 0x0F) 8) | payload[2] total_len 3 section_length key (table_id, payload[1] 6 0x03) self.section_buf.setdefault(key, b) self.section_buf[key] payload if len(self.section_buf[key]) total_len: return None buf self.section_buf[key][:total_len] self.section_buf[key] b return {table_id: table_id, version: (buf[5] 1) 0x1F, buf: buf}这里 key 里加了个 payload 首字节高位的 section_syntax_indicator是为了防止不同的 section 拼到一起。实际码流里更安全的是把 table_id、table_id_extension、section_number 都放进 key但最小解析器不需要那么周全。version_number 的作用在缓存更新时体现PAT 的 version 和当前缓存的 version 不一致就要清空整个 PMT 缓存因为旧 PMT 已经指向了过期的 PID 映射。不这么做切台后你的解析器会继续用旧 PMT 里的 PID 抓音频轻则只有画面没声音重则直接拿视频 PID 去解音频解码器报一堆奇奇怪怪的错。4. 从 TS 里取出可播放的 H.264/H.265PES 载荷拼接、PTS/DTS 与 PCR 时钟对齐PAT/PMT 解析出来只是拿到了地图真正要做播放或转封装还得把音视频流从 PES 层面恢复出来。TS 包的 payload 不直接是 H.264 的 NAL 单元而是 PES 包。PES 包有自己的起始码、长度、可选时间戳字段真正的编码数据在 PES 头后面。4.1 PES 头解析起始码、stream_id、PES_packet_length 与 PTS/DTS 标志位PES 包以00 00 01三个字节起始第四个字节是 stream_id。常见取值0xE0 以上是视频0xC0 到 0xDF 是音频0xBD 是私有数据。PES_packet_length 是紧随其后的 2 字节表示这个 PES 包从下一个字节开始还有多长0 表示长度不限定视频流经常出现这种情况。可选 PES 头里最关键的是 PTS/DTS 标志。第 6 个字节从 PES 起始码算起的下标 6的 bit5~4 是 PTS_DTS_flags2 表示只有 PTS3 表示同时有 PTS 和 DTS。时间戳被压缩在 5 字节里位运算时要小心遮掩不能用简单的字节拼接。def parse_pts_5bytes(b): if len(b) 5: return 0 pts ((b[0] 0x0E) 29) | ((b[1] 0xFF) 22) pts | ((b[2] 0xFE) 14) | ((b[3] 0xFF) 7) pts | (b[4] 0xFE) 1 return pts def parse_pes_header(pes_packet): if pes_packet[0:3] ! b\x00\x00\x01: return None stream_id pes_packet[3] pes_len (pes_packet[4] 8) | pes_packet[5] pts_dts_flags (pes_packet[6] 4) 0x03 header_data_len pes_packet[7] pts parse_pts_5bytes(pes_packet[8:13]) if pts_dts_flags 0x02 else None dts parse_pts_5bytes(pes_packet[13:18]) if pts_dts_flags 3 else None payload_offset 8 header_data_len return { stream_id: stream_id, pes_len: pes_len, pts: pts, dts: dts, payload: pes_packet[payload_offset:] }pts_dts_flags 为 3 时PTS 在前 5 字节DTS 在后 5 字节中间不相邻。很多人第一次写会把 DTS 直接读成pes_packet[8:13]那拿到的其实是 PTS 的高位混着 DTS 的高位解出来的时间戳完全是乱的。参数上没有需要调的地方但建议把解析结果和 ffprobe 的时间戳对比一次能提前发现这一类位运算错误。4.2 载荷拼接PES_packet_length 为 0 的视频流怎么处理音频 PES 通常一个包就是一个完整帧PES_packet_length 非零直接按长度切就行。视频不是这样一个 PES 里可能装了半个 H.264 访问单元也可能装了好几个遇到 pes_len 为 0 的情况只能靠 H.264 的起始码00 00 01或00 00 00 01去分帧。常见做法是维护一个按 PID 区分的拼接缓冲区收到 PES payload 就追加进去对视频流不断在缓冲区里搜索下一个 NAL 起始码找到就认为前面的数据是一个完整的访问单元交给解码器或封装器对音频流则等 PES 头里的 length 凑满再提交。这个处理顺序反过来会出大问题先切 NAL 再拼 PES会把一个 PES 头切成两半时间戳全丢。def feed_pes(self, pid, payload): buf self.pes_buffers.setdefault(pid, b) buf payload if pid in self.video_pids: while True: idx find_start_code(buf) if idx 0: break if idx 0: nal buf[:idx] self.submit_access_unit(pid, nal) buf buf[idx:] if len(buf) 4: break self.pes_buffers[pid] buffind_start_code 返回第一个00 00 01或00 00 00 01的位置。这里有个细节H.264 的 SPS/PPS 可能单独出现在一个 NAL 里也可能跟在关键帧 NAL 后面拼接时不要把它们丢掉解码器初始化必须要 SPS/PPS。第一次写拼接代码的人常在 idx 等于 0 的时候死循环因为起始码就在缓冲区开头没有“上一个 NAL 结束”的概念处理时要在循环开头判断 idx 0 就退出或等下一个包再试。4.3 时间戳换算与 PCRPTS 为什么按 90kHz 计PCR 在适配域里要单独读PTS/DTS 的单位是 90kHz换算成毫秒要除以 90。所以一个 25fps 的视频相邻帧 PTS 差值约 3600换算后约 40ms音频 48kHz 采样率下每个音频帧长 23ms 左右PTS 跳跃值也是对应关系。不要拿 PTS 直接当毫秒用否则音画同步全乱。PCR 是恢复解码时钟的参考存放在 adaptation_field 里和 PTS 不在一个位置。PCR 由 33 位 base、6 位保留、9 位 extension 组成实际值等于 base * 300 extension。和你解析 PTS 一样PCR 也要按位拆。音画同步时播放器会拿 PCR 校准本地时钟再拿 PTS/DTS 对齐帧的呈现时刻。如果 PCR 解析错了最典型的现象是越播越卡或者每隔几秒音画不同步一次但文件本身没有问题。def parse_pcr(packet): afc (packet[3] 0x30) 4 if afc not in (2, 3): return None af_len packet[4] pcr_flag packet[5] 0x10 if pcr_flag 0: return None pcr_bits packet[6:12] base (pcr_bits[0] 25) | (pcr_bits[1] 17) base | (pcr_bits[2] 9) | (pcr_bits[3] 1) base | (pcr_bits[4] 7) ext ((pcr_bits[4] 0x01) 8) | pcr_bits[5] return base * 300 extPCR 字段在适配域里的偏移是固定的adaptation_field 的第一个字节是长度第二个字节是标志位PCR_flag 在 bit4PCR 数据从适配域第 3 个字节开始。这个packet[6:12]的取法依赖 af_len 解析正确如果第 4 字节的适配域长度读错PCR 就会对到 payload 上解出来的值像随机数一样跳。写完后用一段没有丢包的文件跑一遍PCR 应该是一条平滑递增的曲线而不是来回甩。5. TS 解析避坑指南5 个最容易翻车的细节与调试手法TS 解析的难点不在标准有多复杂而在于细节太容易错。下面 5 个坑是我见过最常出现的也是排查起来最耗时间的。5.1 在载荷里搜 0x47 重新同步没丢包也会解析翻车现象解析长文件时中途重新搜索同步字节发现 PID 统计里多出大量奇怪的 PID节目表偶尔能解析、偶尔不能。原因H.264 的 NAL 数据里本来就可能出现 0x47 这个字节拿它当同步头会从 PES 中间开始切包之后所有包都错位。丢了同步后连续解析失败其实是系统性的不是这一次抽风。解决不要在一包校验失败后立即重新搜 0x47。先记录失步位置从失步点开始按 188 步进找下一个连续 5 个 0x47 的位置确认后再恢复解析。主循环里已经 align 过一次后续包如果 sync_byte 不对优先检查是不是文件截断或自己切包时下标算错了。5.2 continuity_counter 不递增却继续拼 PES花屏和爆音的真凶现象画面出现马赛克或花屏音频偶尔有爆音但解析日志里没有任何报错。把 PID 打印出来看连续性计数器时断时续。原因录制或网络传输过程中丢了 TS 包。丢包导致 continuity_counter 跳跃但解析器没察觉继续把不完整的 PES 拼到一起最后解码器拿到的 H.264 数据是残缺的。解决在进入 PES 拼接前先检查 cc。如果当前包的 cc 不等于上一个 cc 加 1 取模 16说明这个 PID 的流有断点应该清空该 PID 的 PES 拼接缓冲区等下一个 PES 起始码出现再重新累计。宁可丢一个访问单元也不要拼出一个坏帧。if cc ! (self.continuity[pid] 1) 0x0F: self.pes_buffers.pop(pid, None) self.on_cc_error(pid)这段代码的 on_cc_error 里可以统计丢包率。丢包率超过 5% 的文件先别急着怀疑解析器代码往往是源文件本身质量不行。5.3 PAT version_number 变了但缓存的 PMT 还在切台后解码器起不来现象同一个文件里前半段正常后半段所有的 PMT 都解析不出来但 PAT 是好的。播放器切台后卡在黑屏解码器初始化失败。原因直播流切台或源端重组节目时PAT 的 version_number 会加 1PMT 的 PID 可能跟着变。解析器还在用缓存的旧 PMT_PID 去收 PMT自然什么都收不到。解决parse_pat 时把 version 也存下来每次 PAT 的 version 变化就清空 pmt 缓存和各自对应 PID 的 PES 缓冲区。注意清空顺序很关键先清 PMT再清按旧 PMT 建的 PID 映射否则新 PMT 还没到旧的音视频 PID 还在被拿来拼 PES。5.4 adaptation_field_control2 时硬取 payload解析出一堆 0xFF 和乱码现象PMT 偶尔解析出几百个字节的乱码流节目数对不上。用十六进制看 payload前面全是连续的 0xFF。原因遇到 adaptation_field_control 为 2 的包时没有跳过适配域把填充用的 0xFF 当成了 PSI 数据。这种包通常出现在 PCR 插入较密的码流里每几十个包就会出现一个纯适配域的包。解决get_ts_payload 里优先处理 afc 为 2 的情况直接返回空字节。任何后续逻辑都不应该看到 afc 为 2 的包里的“payload”因为那根本不是 payload。写测试样例时特意构造一个这样的包验证比用真实文件碰运气靠谱。5.5 用包尾判断 section 结束PAT 只解析出前两个节目现象一个 PAT 里有四五个节目但解析出来只有前两个。后面的节目像被吃掉一样也没有报错。原因用 TS 包的 payload 尾部判断了 section 的结尾。PAT section 可能跨越两个 TS 包只从当前包切数据等于提前把 section 截断了。解决按 section_length 来算结束位置不按 payload 长度。解析器里维护一个 section 拼接缓冲区只有当缓冲区长度达到 3 section_length 才交给 parse_pat / parse_pmt。判断条件不要写后不截断直接把整段丢进去会导致 CRC 处理错位重试时缓冲区越攒越多。6. 验证解析器用 ffprobe 交叉比对节目表、PCR 抖动检测与 PID 流量统计写完解析器后先别急着对接播放器先验证它解析出来的节目表和真实码流一致。我一般做三层验证第一层对比节目清单第二层统计 PID 流量第三层看 PCR 是否平滑。6.1 ffprobe 交叉比对节目号、PID 与编码类型逐项核对拿到一个 TS 文件后先跑一遍 ffprobe再跑自己的解析器把输出摆在一起对。ffprobe 能直接读 TS 的 PAT/PMT 并打印出节目列表和流信息。ffprobe -hide_banner -show_programs input.ts ffprobe -hide_banner -show_streams input.tsshow_programs 的输出里有 program_id 和对应的 PID 列表show_streams 里有每个流的具体编码类型。我的习惯是把自己的解析器打印成program_number: PMT_PID, video0x101, audio0x102这种格式和 ffprobe 的结果逐项比对。比对对了再去做转封装能省掉后面调音画同步时的大量排查时间。6.2 两个自检脚本PID 流量统计与 PCR 间隔异常流量统计脚本很简单遍历所有包按 PID 计数最后打印占比。正常单节目流里视频 PID 的包占比最高通常在 80% 上下空包占比和码率填充策略有关。如果 PAT 或 PMT 的占比占比高得不正常比如超过 5%大概率是解析时把视频 PID 误判成了表 PID。PCR 检测稍微复杂一点计算相邻两个 PCR 包之间的实际到达时间和理论间隔的偏差。简化做法是统计 PCR 值是否持续递增按包序号记录下来相邻两个 PCR 差值应当稳定在一个区间内差值降到接近 0 又突然跳大通常是 PCR 解析错位。还有一个更快的粗检把 PCR 值转换成毫秒和相邻两张表的 PTS 对照如果 PCR 已经走了 10 秒而视频 PTS 才走了 2 秒说明时间戳取错了位置。6.3 一个动作先于一切先打一张节目表再往下走我现在的习惯是任何解析器对接新文件类型前第一步永远是把 PAT 里的节目号、PMT 里的 PCR_PID、视频 PID、音频 PID 全打出来。这一步做完文件格式上有没有坑已经知道大半。某开发者一开始图快跳过了这步直接拼 PES结果在一个多节目的录播文件上折腾了两天最后发现是 PMT 里有两路视频他默认只取第一路。从那以后他养成了一来就先看节目表的习惯。这个习惯能帮你绕开大多数“为什么解析不对”的玄学问题。希望帮到你。本文还有配套的精品资源点击获取