企业官网建设流程全解析

简介：这是面向数字电视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 接收端，只要你的工作里绕不开 TS（Transport 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 固定是 0x1FFF，PAT 表的 PID 固定是 0x0000。
• continuity_counter（连续性计数器）：4 bit，范围 0~15，循环递增。接收端拿它检测有没有丢包。注意，如果某个 TS 包里只有 adaptation field 而没有 payload，这个计数器是不递增的，这是规范允许的，不要一看到不递增就以为丢包了。
• adaptation_field_control：2 bit，标志这个包是“只有负载”“只有字段”“字段+负载”还是“无负载”。PCR 就放在 adaptation field 里。

这几个字段搞明白后，绝大多数码流问题的第一轮排查你就有方向了。软件界面里那一排排的十六进制字节，本质就是在表达这些信息。

2.2 PSI/SI 表：码流里的“目录”

TS 流里除了音视频数据，还有一种特殊的数据叫 PSI（Program Specific Information）和 SI（Service 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.264，0x24 是 HEVC，0x0F 是 AAC。

在用码流分析软件拆包时，PAT/PMT 通常是软件自动解析并做成树形结构展示的。看一个真实码流时，我习惯先看 PAT 里列了几个节目，再看每个节目的 PMT 里音视频 PID 是否合理，最后再对照着看实际数据包的 PID 统计，往往就能发现问题，比如 PMT 里指向的音频 PID 在整段码流里根本不存在，那这个节目抽走音频就是必然的。

除了 PSI，DVB 体系里还有 SI 表：SDT（服务描述表）提供频道名称、服务类型，EIT（事件信息表）提供节目单，NIT（网络信息表）描述频率、调制参数等信息。SI 表不是解码必需的，但对 EPG 显示、频道搜索至关重要。

2.3 PES 和时间戳：让视频能“正常播放”的骨架

音视频数据在进入 TS 包之前，先要打包成 PES（Packetized Elementary Stream）。PES 包里有 PTS（展示时间戳）和 DTS（解码时间戳），这两个时间戳是音频视频同步的命脉。

为什么需要 PTS/DTS？因为视频编码里有 B 帧（双向预测帧）。解码顺序和显示顺序不一致：比如一个 GOP 里，显示顺序是 IBBP，但解码顺序是 IPBB。DTS 告诉解码器“什么时候解”，PTS 告诉解码器“什么时候显示”。如果 PTS/DTS 有问题，最典型的症状就是画面一顿一顿，或者声音和画面差着几百毫秒。

PES 打包之后，再根据负载大小拆成一到多个 TS 包，每个 TS 包加上 PID 和连续性计数器。整个 TS 流的逻辑关系可以理解为：

一路节目 = PSI（PAT/PMT 等表） + 一路 PES 视频流（若干个 PID）+ 一路或多路 PES 音频流 + 可能的字幕/数据流

码流分析软件里看到的树形结构，就是把这一层一层的封装关系给可视化出来了。你点开一个 PID，软件会告诉你这个 PID 承载的是视频还是音频还是表，解析了多少个 PES 包，PTS 起始值是多少、有没有跳变——这种“透视”能力，是任何普通播放器都给不了的。

3. 拿码流分析软件排查实际问题的典型场景

工具再好，不会用于排查也是白搭。这里我挑几个自己遇到的真实场景，讲讲排查思路。

3.1 音画不同步：优先查 PCR 和 PTS

音画不同步是编码、复用、传输环节都容易出的问题。用码流分析软件排查时，我的顺序是：

1. 查 PCR 间隔和抖动。PCR（节目时钟基准）是编码器送出的 27MHz 时钟，解码器靠它恢复系统时钟。DVB 规范要求 PCR 间隔一般不超过 100ms（具体值看 PCR_rep 字段），PCR 抖动要控制在 ±500ns 以内。分析软件会直接标出 PCR 间隔的最大值、最小值，以及计算出的抖动（PI，即 PCR 不准确度），还能画出趋势曲线。如果 PCR 间隔忽大忽小，或者相邻 PCR 差值对应的时钟和你设定的频率对不上，那解码器的时钟参考就是乱的，音画怎么可能同步得了。
2. 查 PTS/DTS 是否单调递增。如果软件里看到 PTS 来回跳、或者视频 PTS 和音频 PTS 差值持续增大，基本可以判定是编码端时间戳基点没对齐，或者是复用器重新打时间戳时手滑了。
3. 对比视频 PID 和音频 PID 的 PTS 时间差。正常应该稳定在一个较小范围内（比如几百毫秒以内），如果差距一直在慢悠悠地漂移，多半是时钟频率基准有偏差。

3.2 频道搜不到或黑屏：先看 PAT/PMT

之前我遇到过一个挺诡异的案例：一台编码器输出的流，接到解码器上，能搜到频道名，但点进去就黑屏。换了一个解码器也一样。用码流分析软件打开抓流文件，软件自动解析出 PAT，里面 program_number 和 PMT PID 都正常。但再看 PMT，发现视频 PID 指向了一个根本不存在的 PID——实际码流里那个 PID 一个包都没有。

然后软件报出 PMT 里声明的 stream_type 是 0x1B（H.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_number，SDT 里有 service_id，有时候一个分析软件界面上写 program_number，另一个写 service_id，一开始我以为这俩是同一个东西，结果对着同一个频点怎么也对不上号。

program_number 是 PAT/PMT 里区分节目的逻辑号，范围 0~65535，只在这个流内部有意义；service_id 是 SDT 里服务描述用的标识，本质上是节目号在服务层面的“对外名称”，DVB 通常会把两者设成一样，但规范并没有强制要求两者必须一致。如果在 DVB 扫描时发现“搜得到流搜不到频道”，可以留意一下这个字段是不是迁移了。

4.3 关于工具的选择和结果验证

市面上的码流分析工具五花八门，有商业的，有开源的，也有命令行出身的。我自己的看法是，工具不用太纠结“哪个最好”，关键是要熟练、并且知道它的局限：

• 界面友好的商业软件（比如 TSPE、EasyICE、DVBAnalyzer 一类）适合现场快速定位问题，树形结构、表格统计都非常直观，适合把整个码流“摊开看”。
• 命令行工具（比如 tsduck 里的tsp、tsanalyze，ffprobe 也可以做简单解析）适合自动化处理、批量分析，适合你写个脚本扫一堆抓流文件，找出异常的那一个再拿图形工具细看。
• 我个人的习惯是：先拿命令行工具批量筛一遍，再用图形工具手动深入分析异常点。比如用tsp -I file x.ts -P analyze -1一次性分析出 PAT/PMT、CC 错误数、PCR 最大间隔，然后把这几个关键指标打成一个报告。然后再针对有问题的流，开图形工具看 PCI、PTS 趋势。

另外，有一点必须提醒：任何解析工具的结果都可能受抓流起点影响。抓流时如果起始位置不在 TS 包边界，前面的几个包可能解析不出来。所以抓流时最好留出几秒冗余，分析时跳过开头那一段，等软件找到连续同步字节后再看统计数据。不然你看到“PAT 解析失败”的通知，可能只是抓流起点的同步问题，不是流本身的问题。

5. 我自己用下来最喜欢的功能和日常分析流程

聊到这一步，可能有人想问：如果我现在就想开始学 TS 结构，该怎么下手？我建议你搞一个真实的抓流文件，随便开哪款码流分析软件都行，然后按这个流程走一遍：

1. 看 Overview/总览页：了解这个流里有哪些 PID、各自占比多大、有没有警告。先宏观感知一下。
2. 看 PAT→PMT 的节目结构树：确认节目数量和每个节目的成分。这时候 TS 结构的“目录感”就出来了。
3. 看一个视频 PID 的 PES 解析：找到第一个 PES 包的 PTS，再看下一个，体会 PTS 的递增规律；如果还有 B 帧，看 DTS 和 PTS 的差值。
4. 看 PCR 分析页：看看 PCR 间隔最大值是多少，有没有超过 100ms，PCR 抖动在什么量级。
5. 看 CC 错误和 bitrate 统计：综合判断码流健康状况。
6. 有报错就点开详情：顺着软件的高亮警告反查具体 TS 包，对照十六进制数据看是哪个字段异常。

这个流程走完一遍，你对 TS 结构的感觉会完全不一样。之后再遇到分析任务，你就能很快判断“这个问题是 PAT/PMT 配置问题，还是 PCR 时钟问题，还是 IP 网络丢包问题”，下手会精准很多。

我还想多说一句：别迷信软件给出的“结论”。码流分析软件本质是一个解析工具，它给你的是字段值、统计量、警告，但最终“这个值为什么异常”“这个警告到底影响不影响用户观看”，还是需要你结合业务场景去判断。比如 PCR 间隔偶尔一次 120ms，可能不影响观看；但如果频繁超过这个值，那就要警惕了。工具帮你把“看不到的”变成了“看得到的”，但分析和决策还是得靠人。

希望这篇关于码流分析软件和 TS 结构的东西，能帮你少走一些我当年走过的弯路。如果你也在调试 TS 流的路上，欢迎多交流实战中的坑。

本文还有配套的精品资源，点击获取