简介这是面向数字电视TS开发与学习的码流分析工具以Tree树形展示PAT、PMT、SDT、EIT及Subtitle的PES包层级节点与SI表结构一一对应适合TS入门者和DTV调试工程师。相比同类软件额外解析LCN和Subtitle数据可仿真显示字幕图片、仿真搜台和EPG双击EIT的eventid可看事件详情。资源包为RAR格式共30个文件、161KB以GIF图标为主另含可直接运行的EXE程序、C语言源码、JavaScript脚本、数据库文件及HTML结果模板适合直接体验也可阅读源码理解Tree控件与解析逻辑。支持将PAT/PMT/SDT/NIT或EIT表导出为网页码流大小不限目前已有1909人学习浏览。 刚接触数字电视和视频编码那会儿我拿到一个.ts后缀的文件第一反应就是拖进播放器能放出来就完事。直到有一天领导丢给我一段从机顶盒抓回来的几十兆码流说“你帮我看下这个流到底哪里有问题”我才意识到播放器这种“黑盒”根本帮不了你。真正能让你快速掌握 TS 结构、看清每一个字节背后的含义的是一款顺手的码流分析软件TS analysis tool。这篇文章我结合自己这些年用过的工具和踩过的坑聊聊 TS 结构里的核心东西以及码流分析软件该怎么用才能真正帮到你。无论你是做数字电视、视频编码、流媒体服务器还是搞安防监控、DVB/IPTV 接收端只要你的工作里绕不开 TSTransport Stream传输流那这篇文章就是给你写的。1. 先搞明白TS 流为什么需要专门的“透视工具”1.1 TS 流和 MP4、MKV 这类文件的本质区别很多人第一次接触 TS 流时容易把它和 MP4、MKV 混在一起。同样是视频文件为什么 MP4 用播放器打开偶尔还能用剪辑软件修一修而 TS 流却非得用专门的码流分析软件去“解剖”关键区别在于MP4、MKV 这类格式是面向文件存储设计的而 TS 流是面向传输设计的。MP4 有一个庞大的 box 结构moov 里存着一大堆索引moof 里还有分片信息。播放器打开 MP4先读索引再按索引去跳转基本上可以算作“先查目录再看正文”。但 TS 流不一样它是电视广播、网络传输场景下诞生的格式设计的时候就没打算让你随机寻址。霜 TS 流在 UDP 组播、同轴线缆、卫星信号里一路“飘”过来接收端必须边收边解不可能像读本地文件那样先看目录。所以 TS 流的每一个包都是独立的、固定长度的、自描述的。接收端只要从任意一个 188 字节的包开始找到同步字节就能“一头扎进去”开始解析。不依赖全局索引不怕丢包丢了一个包顶多少一帧画面不至于整个文件全废。这种“面向传输”的设计决定了它的分析工作不能靠播放器必须靠能够逐包拆解的码流分析软件。播放器只会告诉你“能不能播”“卡不卡”而码流分析软件能告诉你“为什么能播”“为什么卡”“丢了多少包”“PCR 抖了多少纳秒”“PAT 表里有没有问题”——这才是排查问题需要的深度。1.2 什么时候你会真正需要一款码流分析软件我自己的经验是以下几个场景里码流分析软件几乎不可替代排查音画不同步、卡顿、花屏你以为换了播放器就能解决但问题很可能出在码流本身——PCR 间隔过大、时间戳异常、连续性计数断裂。这些信息播放器一概不给你。做 CA条件接收/加扰调试ECM、EMM 走了哪些 PID加扰控制字有没有生效只有逐 PID 分析才看得清。设备抓流与方案验证机顶盒、编码器、复用器、IP QAM 调制器各个设备出来的流是否符合 DVB 或 ATSC 规范拿软件盯一遍 PAT/PMT/SDT/PCR比联调时被各种“玄学问题”折腾要高效得多。学习 TS 结构说实话我当年学 TS 结构就是靠码流分析软件打开一个真实抓包对着树形结构一点点看。光看文档上那一堆字段表格记不住拿软件“解剖”一个真实码流看它是怎么分包、怎么封装 PES、怎么嵌套 section 的很快就通了。2. TS 结构核心拆解188 字节一个包别被二进制吓到很多刚接触 TS 结构的人被那一堆字段命名吓退——transport_error_indicator、payload_unit_start_indicator、adaptation_field_control……名字一个比一个长。其实你不需要背字段表核心骨架就那么几个东西。2.1 TS 包头的关键字段先盯住这几个一个 TS 包固定 188 字节开头 4 字节是包头剩下 184 字节是负载。包头里最关键的是这几样sync_byte同步字节固定 0x47一个字节。解析器找同步就是连续找到若干个 0x47 且间隔 188 字节才敢确认抓包起始点是对的。PID包标识符13 bit这是整个 TS 结构里最重要的东西。可以理解为“快递单上的收件人地址”——不同数据类型用不同的 PID 区分。比如视频通常是 0x1011、0x0100 这种编码器自定义值空包PID 固定是 0x1FFFPAT 表的 PID 固定是 0x0000。continuity_counter连续性计数器4 bit范围 0~15循环递增。接收端拿它检测有没有丢包。注意如果某个 TS 包里只有 adaptation field 而没有 payload这个计数器是不递增的这是规范允许的不要一看到不递增就以为丢包了。adaptation_field_control2 bit标志这个包是“只有负载”“只有字段”“字段负载”还是“无负载”。PCR 就放在 adaptation field 里。这几个字段搞明白后绝大多数码流问题的第一轮排查你就有方向了。软件界面里那一排排的十六进制字节本质就是在表达这些信息。2.2 PSI/SI 表码流里的“目录”TS 流里除了音视频数据还有一种特殊的数据叫 PSIProgram Specific Information和 SIService Information。PSI 的作用是告诉接收端这个流里有几个节目每个节目的音视频分别用哪个 PID 传输。PSI 中最核心的两张表PAT节目关联表固定 PID 0x0000。它列出流里所有节目的 program_number以及每个节目对应的 PMT 的 PID。相当于一本总目录想找第 1 频道的节目单请去 PMT 那一页。PMT节目映射表PAT 里指定 PID 的表。它进一步列出单个节目内部的成分视频 PID、音频 PID、PCR PID、以及 stream_type编码格式。比如 stream_type 0x1B 是 H.2640x24 是 HEVC0x0F 是 AAC。在用码流分析软件拆包时PAT/PMT 通常是软件自动解析并做成树形结构展示的。看一个真实码流时我习惯先看 PAT 里列了几个节目再看每个节目的 PMT 里音视频 PID 是否合理最后再对照着看实际数据包的 PID 统计往往就能发现问题比如 PMT 里指向的音频 PID 在整段码流里根本不存在那这个节目抽走音频就是必然的。除了 PSIDVB 体系里还有 SI 表SDT服务描述表提供频道名称、服务类型EIT事件信息表提供节目单NIT网络信息表描述频率、调制参数等信息。SI 表不是解码必需的但对 EPG 显示、频道搜索至关重要。2.3 PES 和时间戳让视频能“正常播放”的骨架音视频数据在进入 TS 包之前先要打包成 PESPacketized Elementary Stream。PES 包里有 PTS展示时间戳和 DTS解码时间戳这两个时间戳是音频视频同步的命脉。为什么需要 PTS/DTS因为视频编码里有 B 帧双向预测帧。解码顺序和显示顺序不一致比如一个 GOP 里显示顺序是 IBBP但解码顺序是 IPBB。DTS 告诉解码器“什么时候解”PTS 告诉解码器“什么时候显示”。如果 PTS/DTS 有问题最典型的症状就是画面一顿一顿或者声音和画面差着几百毫秒。PES 打包之后再根据负载大小拆成一到多个 TS 包每个 TS 包加上 PID 和连续性计数器。整个 TS 流的逻辑关系可以理解为一路节目 PSIPAT/PMT 等表 一路 PES 视频流若干个 PID 一路或多路 PES 音频流 可能的字幕/数据流码流分析软件里看到的树形结构就是把这一层一层的封装关系给可视化出来了。你点开一个 PID软件会告诉你这个 PID 承载的是视频还是音频还是表解析了多少个 PES 包PTS 起始值是多少、有没有跳变——这种“透视”能力是任何普通播放器都给不了的。3. 拿码流分析软件排查实际问题的典型场景工具再好不会用于排查也是白搭。这里我挑几个自己遇到的真实场景讲讲排查思路。3.1 音画不同步优先查 PCR 和 PTS音画不同步是编码、复用、传输环节都容易出的问题。用码流分析软件排查时我的顺序是查 PCR 间隔和抖动。PCR节目时钟基准是编码器送出的 27MHz 时钟解码器靠它恢复系统时钟。DVB 规范要求 PCR 间隔一般不超过 100ms具体值看 PCR_rep 字段PCR 抖动要控制在 ±500ns 以内。分析软件会直接标出 PCR 间隔的最大值、最小值以及计算出的抖动PI即 PCR 不准确度还能画出趋势曲线。如果 PCR 间隔忽大忽小或者相邻 PCR 差值对应的时钟和你设定的频率对不上那解码器的时钟参考就是乱的音画怎么可能同步得了。查 PTS/DTS 是否单调递增。如果软件里看到 PTS 来回跳、或者视频 PTS 和音频 PTS 差值持续增大基本可以判定是编码端时间戳基点没对齐或者是复用器重新打时间戳时手滑了。对比视频 PID 和音频 PID 的 PTS 时间差。正常应该稳定在一个较小范围内比如几百毫秒以内如果差距一直在慢悠悠地漂移多半是时钟频率基准有偏差。3.2 频道搜不到或黑屏先看 PAT/PMT之前我遇到过一个挺诡异的案例一台编码器输出的流接到解码器上能搜到频道名但点进去就黑屏。换了一个解码器也一样。用码流分析软件打开抓流文件软件自动解析出 PAT里面 program_number 和 PMT PID 都正常。但再看 PMT发现视频 PID 指向了一个根本不存在的 PID——实际码流里那个 PID 一个包都没有。然后软件报出 PMT 里声明的 stream_type 是 0x1BH.264但实际视频包的 stream_type 与 PMT 不一致。这个问题的根源是编码器在 PMT 更新时用了旧的音视频 PID 配置导致指引出错。接收端按 PMT 去找视频流找到个空自然就黑屏了。这个案例想说明的是PMT 是流内部逻辑和实际数据之间的“契约”契约不对再好的解码器也白搭。用码流分析软件时要看它有没有报“PMT PID 指向空”“音视频 PID 冲突”“stream_type 非法”这类逻辑错误。很多软件会用红色警告标出来一眼就能看到重点。3.3 算码率/查带宽异常PID 统计是最快的入口TS 流本质上是一个“挤在固定带宽里”的通道不管有没有有效数据带宽都得被包填满。空包PID 0x1FFF就是用来填带宽的。如果你想看频道实际占了多少带宽直接看每个 PID 的包占比就行。码流分析软件一般会给出每个 PID 的包数量、占比、码率估计值。计算方法很简单某个PID的码率 ≈ 该PID的包数 × 188字节 × 8 bit / 抓流时长秒比如一段 10 秒的抓流里视频 PID 共抓到 25 万个 TS 包那么视频码率大约是 250000×188×8/10 37.6 Mbps。如果你看到的视频 PID 码率比预期高很多说明编码器在“给 I 帧疯狂堆码率”或者有人在流里偷偷塞了私有数据。另外空包占比也是一个很值得看的指标。空包占总带宽的比例高说明实际有效节目占的带宽低复用器在“注水”。如果空包占比异常低、同时 PCR 间隔明显偏大说明复用器可能把 PCR 包挤掉了——这又会引出音画同步问题。3.4 断流、花屏、马赛克从 continuity_counter 入手信号传输过程中发生丢包最直接的表现就是 continuity_counter 不连续。比如上一个视频包计数器是 5下一个变成 7中间少了 6那就可以认为中间丢了一个 TS 包。用码流分析软件时你会看到一个“continuity error”“CC error”之类的统计。如果连续丢包率很高那花屏、马赛克一点都不奇怪。顺便说一句这种场景下也别急着怪编码器很大概率是 IP 网络抖动、或者四层交换机的组播配置问题。分析软件抓流的时间点和网络环境很关键对比不同时间点的丢包率能帮你定位丢包是随机性还是周期性的。4. 使用码流分析软件时容易忽略的坑工具用久了总会踩到一些文档上不会写清楚的坑。这里分享几个我自己的真实体会。4.1 continuity_counter 不递增不一定就是丢包很多刚上手的人看到 continuity_counter 跳变就紧张。但实际上有两种情况计数器不递增是正常的携带 adaptation field 但没有 payload 的包传输条件接收加扰状态切换、PCR 插入时经常会出现这种包。adaptation_field_control 标志区分了“带负载”和“不带负载”没有负载的包计数器不递增。空包PID 0x1FFF多数复用器产的码流里空包的 CC 依次递增但有些设备输出的空包 CC 是乱的这问题不大——反正空包就是填充不影响解码。所以排查时先看丢包的是不是业务 PID视频、音频、表如果视频 PID 的 CC 不连续再结合时间轴看是不是固定周期丢包这样才能定位到是网络抖动、抖动缓冲配置还是编码器发包节奏的问题。光看 CC 错误总数不说明问题要看“在哪个时间点、丢的是哪个 PID 的包”。4.2 program_number 和 service_id 不是一回事这个坑我在用软件看 DVB 码流时踩过。PAT 里有 program_numberSDT 里有 service_id有时候一个分析软件界面上写 program_number另一个写 service_id一开始我以为这俩是同一个东西结果对着同一个频点怎么也对不上号。program_number 是 PAT/PMT 里区分节目的逻辑号范围 0~65535只在这个流内部有意义service_id 是 SDT 里服务描述用的标识本质上是节目号在服务层面的“对外名称”DVB 通常会把两者设成一样但规范并没有强制要求两者必须一致。如果在 DVB 扫描时发现“搜得到流搜不到频道”可以留意一下这个字段是不是迁移了。4.3 关于工具的选择和结果验证市面上的码流分析工具五花八门有商业的有开源的也有命令行出身的。我自己的看法是工具不用太纠结“哪个最好”关键是要熟练、并且知道它的局限界面友好的商业软件比如 TSPE、EasyICE、DVBAnalyzer 一类适合现场快速定位问题树形结构、表格统计都非常直观适合把整个码流“摊开看”。命令行工具比如 tsduck 里的tsp、tsanalyzeffprobe 也可以做简单解析适合自动化处理、批量分析适合你写个脚本扫一堆抓流文件找出异常的那一个再拿图形工具细看。我个人的习惯是先拿命令行工具批量筛一遍再用图形工具手动深入分析异常点。比如用tsp -I file x.ts -P analyze -1一次性分析出 PAT/PMT、CC 错误数、PCR 最大间隔然后把这几个关键指标打成一个报告。然后再针对有问题的流开图形工具看 PCI、PTS 趋势。另外有一点必须提醒任何解析工具的结果都可能受抓流起点影响。抓流时如果起始位置不在 TS 包边界前面的几个包可能解析不出来。所以抓流时最好留出几秒冗余分析时跳过开头那一段等软件找到连续同步字节后再看统计数据。不然你看到“PAT 解析失败”的通知可能只是抓流起点的同步问题不是流本身的问题。5. 我自己用下来最喜欢的功能和日常分析流程聊到这一步可能有人想问如果我现在就想开始学 TS 结构该怎么下手我建议你搞一个真实的抓流文件随便开哪款码流分析软件都行然后按这个流程走一遍看 Overview/总览页了解这个流里有哪些 PID、各自占比多大、有没有警告。先宏观感知一下。看 PAT→PMT 的节目结构树确认节目数量和每个节目的成分。这时候 TS 结构的“目录感”就出来了。看一个视频 PID 的 PES 解析找到第一个 PES 包的 PTS再看下一个体会 PTS 的递增规律如果还有 B 帧看 DTS 和 PTS 的差值。看 PCR 分析页看看 PCR 间隔最大值是多少有没有超过 100msPCR 抖动在什么量级。看 CC 错误和 bitrate 统计综合判断码流健康状况。有报错就点开详情顺着软件的高亮警告反查具体 TS 包对照十六进制数据看是哪个字段异常。这个流程走完一遍你对 TS 结构的感觉会完全不一样。之后再遇到分析任务你就能很快判断“这个问题是 PAT/PMT 配置问题还是 PCR 时钟问题还是 IP 网络丢包问题”下手会精准很多。我还想多说一句别迷信软件给出的“结论”。码流分析软件本质是一个解析工具它给你的是字段值、统计量、警告但最终“这个值为什么异常”“这个警告到底影响不影响用户观看”还是需要你结合业务场景去判断。比如 PCR 间隔偶尔一次 120ms可能不影响观看但如果频繁超过这个值那就要警惕了。工具帮你把“看不到的”变成了“看得到的”但分析和决策还是得靠人。希望这篇关于码流分析软件和 TS 结构的东西能帮你少走一些我当年走过的弯路。如果你也在调试 TS 流的路上欢迎多交流实战中的坑。本文还有配套的精品资源点击获取