TR101290总结：码流健康度三优先级量化与排障实践

简介：一份围绕数字电视传输标准 TR101290 的技术总结文档，面向音视频开发、数字电视协议分析及嵌入式电视接收调试人群。内容系统梳理 MPEG-2 传输流中的 ES、PES、TS、PS 概念，说明 TS 分组 188 字节结构、PES 与 TS 的封装关系，并重点讲解 PAT、PMT、CAT、NIT 四类节目专用信息的 PID 取值与相互引用逻辑，配合解复用流程实例帮助读者从底层理解节目定位与还原原理。文档为单个 doc 文件，大小约 1.11MB，叙述从背景介绍、基础术语到实例分析逐步推进，层次清晰。已有 278 人学习下载，既可供入门者建立协议框架，也可作为从业者排查传输流问题的速查参考。

1. TR101290 总结：码流健康度到底该怎么量化

做数字电视前端运维的人，几乎都遇到过这种场景：半夜值班电话响，说用户端画面卡顿、黑屏，领导第二天要一份"故障分析报告"。你登录网管系统，看到一堆告警，却说不清哪个是根因、哪个是伴随现象。这时候，ETSI TR 101 290 就是那把尺子。TR101290 不是某个厂商的私有协议，而是 DVB 系统里定义的一套码流测量参数标准，它把传输流（TS）的健康度拆成三个优先级，分别对应"能不能锁住信号""码流是否连续""业务信息是否完整"。转 TR101290 总结，说白了就是把一堆十六进制码流数据转成能直接指导排障的结论，让非技术背景的人也能看明白问题出在传输链路、复用器还是编码器上。

2. 三个优先级背后的设计逻辑：为什么同步丢失比 PCR 抖动更致命

2.1 一级参数：锁不住信号，后面全白谈

TR101290 把参数分成三个优先级，这个分级本身就是一套排障哲学。一级参数只有四个：TS 同步丢失、同步字节错误、PAT 错误、连续计数（CC）错误。它们的共同点是——只要任何一个出现，接收端要么黑屏，要么马赛克爆表。我见过不少刚入行的同事，一上来就盯着 PCR 抖动调参数，结果发现症状根本没消，回头一查是 TS 同步丢失在作祟。这就是没理解优先级的意义：一级是地基，地基塌了，二楼三楼再精致也没用。

TS 同步丢失的定义很直白：在连续的 8192 个 TS 包里，同步字节（0x47）没有按每 188 字节一次的规律出现。注意这个 8192 的窗口，它不是随便定的，而是对应了传输帧的常见长度，确保统计意义足够。同步字节错误则是 0x47 出现在错误位置——位置对了但字节值不对，说明链路里发生了字节错位或位翻转，通常是调制环节的星座图映射出问题了。PAT 错误更好理解：PAT（节目关联表）的 PID 固定是 0x0000，它的周期一般为 100ms 以内，如果 PAT 丢失或超时，接收机根本不知道节目流在哪个 PID 上，等于拿到了没有目录的档案柜。

CC 错误是最容易被误判的一级参数。连续计数是在每个 TS 包头第 4 字节的低 4 位，范围 0~15，循环递增。如果同一 PID 的包序号跳了或者重复了，就说明码流在复用或传输过程中发生了丢包或插包。注意，CC 错误的判定是按 PID 独立统计的，不要看见"CC 错误"就认为所有 PID 都挂了，先看是哪个 PID 在跳，往往能直接锁定是某个节目源的问题还是整路复用的问题。

2.2 二级参数：信号锁住了，但体验在下滑

二级参数解决的是"锁住但难受"的问题。传输错误（Transport Error）是由传输层带过来的错误标志位，比如 DVB-S 的星座图里出现了无法纠正的 RS 编码错误，解调器会在 TS 包头打个标记，这个标记会一路传到分析仪里。PCR 错误和 PCR 重复间隔这两个参数直接关系到音视频同步。PCR（节目时钟基准）承载在特定 PID（通常是 PCR PID）的 adaptation field 里，解码器靠它恢复出 27MHz 的系统时钟。如果 PCR 抖动过大，即使 IP 网络延迟很稳定，解码端也会出现音画不同步——因为音频缓冲和视频缓冲的时钟基准漂了。

二级参数里有个容易被忽略的点：PCR 间隔。标准建议 PCR 间隔不超过 40ms，实际运营中我一般要求 30ms 以内，留出余量。因为网络抖动（jitter）会在传输中进一步放大间隔的波动，如果源端就已经 38ms 了，经过一层 IP 封装转发，到用户端可能就突破 60ms 了。这个参数不像 CC 错误那样直接导致画面破裂，但它是"体验类投诉"的主要元凶，排查时优先级并不低。

2.3 三级参数：SI 表不完整，机顶盒的 EPG 变成空白

三级参数里最常见的是 NIT（网络信息表）错误、SDT（业务描述表）错误、EIT 错误和缓冲错误。这些表承载的是"节目指南"和"网络拓扑"信息。实际排障中，三级参数告警往往不会立刻导致黑屏，但如果 EPG 数据是广告商付费投的，那运维压力就会直接传导过来。我处理过一个投诉：某省台的 EPG 在晚上 8 点到 10 点黄金时段频繁"消失"，排查后发现是 EIT 表的重复周期在高峰期被复用器悄悄拉长了——因为带宽不够，复用器优先保证了视频流，把 SI 表的发送间隔从 25ms 放宽到了 2 秒。这就是典型的"参数符合标准下限、但不符合运营预期"的案例。

理解这张表的关键在于：不是所有告警都需要立即动手。一级告警响了，先停业务排查；二级告警响了，可以调参数观察；三级告警响了，记入台账排期处理。这个分级思想，就是"转 TR101290 总结"时最重要的判断框架。

3. 抓流与测量：从码流文件到 TR101290 参数表的完整链路

3.1 用 tsduck 跑一轮三优先级检测：最小命令与输出解读

做 TR101290 测量，常见做法是用开源工具 tsduck（TS Duck）里的 tsp 命令。它支持实时从 ASI/SMPTE 2022-2 输入流读取，也支持离线分析 .ts 文件。我一般会先抓一段 60 秒的码流存成文件，再反复分析，避免在直播链路上反复折腾。

# 从 IP 口抓 60 秒码流存成文件（适用于 SMPTE 2022-2 封装的 TS 流） tsp -I ip 239.1.1.1:5000 -P continuity -P pcr -P psisi -O file capture.ts -t 60 # 对文件做完整 TR101290 三优先级分析，输出文本报告 tsp -I file capture.ts -P analyze -o report.txt -a 3

第一行命令里-I ip是输入插件，后面跟组播地址和端口；-P continuity -P pcr -P psisi是三个处理插件，分别做 CC 连续性检查、PCR 间隔/抖动分析、PSI/SI 表分析；-O file指定输出到文件，-t 60表示只处理 60 秒。第二行命令的-a 3表示按 TR101290 的三个优先级全部检测，-o report.txt输出报告。注意-a的取值可以单独设成 1、2、3 来只测某一优先级，我排查时经常先-a 1只看一级参数，避免二级三级的海量日志干扰判断。

拿到 report.txt 后，不要直接翻到最下面看"错误总数"，而要按优先级逐段看。tsduck 的 analyzer 插件输出里，每个参数的错误记录都带时间戳和 PID 信息。比如看到PID 0x0123 (291): CC error, count=157，就直接定位到 PID 291 在丢包，结合 PAT 表查出这个 PID 是哪个节目，就能迅速判断是某个编码器通道的问题，还是复用器输出带宽打满了。

3.2 自己写脚本过滤误报：为什么不能全信工具给的结果

实话实说，工具给的原始结果不能直接抄进报告里。实际链路中经常有"误报"——比如 PCR 测量在 IP 封装链路里，会因为 RTP 时间戳的重映射而产生虚假抖动。我习惯用 Python 脚本做二次过滤，把连续错误和单点错误分开。单点错误往往是瞬时干扰，而连续错误才是真正的链路劣化。

import re from collections import defaultdict # 读取 tsduck 分析报告，按 PID 和错误类型聚合 errors = defaultdict(list) with open("report.txt", "r", encoding="utf-8") as f: for line in f: # 匹配类似 "PID 0x0123 (291): CC error, count=157" 的行 m = re.search(r"PID 0x([0-9A-Fa-f]+) \(\d+\): (.*?), count=(\d+)", line) if m: pid = int(m.group(1), 16) err_type = m.group(2) count = int(m.group(3)) errors[(pid, err_type)].append(count) # 过滤规则：单次错误且 count < 3 记为瞬时抖动，不进入总结报告 significant = {} for (pid, err_type), counts in errors.items(): total = sum(counts) if total >= 3: significant[(pid, err_type)] = total for (pid, err_type), total in sorted(significant.items()): print(f"PID {pid:#06x} | {err_type} | 累计 {total} 次")

这段脚本的逻辑很简单：用正则从文本报告里抽取出 PID、错误类型和次数，然后把同一 PID 同一错误类型的次数累加。#06x格式化是为了让 PID 显示成 0x0123 这种和原始报告一致的格式，方便同事拿到编号直接去复用器上查。实际使用中，我会把total >= 3这个阈值调成动态的——检测时长越长，阈值应该按比例提高，比如 60 秒检测里 3 次是合理的，但 10 分钟检测里 3 次就太敏感了。这就是典型的"读报告的人得懂测量窗口，否则会被阈值带偏"。

3.3 测量窗口的长度怎么选：60 秒还是 10 分钟？

TR101290 标准本身没有规定测量时长，但实际工程里这个选择直接影响结论。短窗口（比如 30 秒）适合做故障排查——我半夜接到电话时，抓 30 秒就够确认 CC 错误是否还在持续。长窗口（比如 10 分钟）适合做网络健康度评估和设备验收。设备验收时我一般抓 15 分钟，因为有些加密抖动和 PCR 漂移是间歇性的，短窗口看不到。

另外注意一个细节：tsduck 的 analyze 插件默认是把整个输入文件全跑完才输出结果，如果你的文件太大，可以用-t参数配合tsp的定时器来截断处理，而不是把文件全部加载到内存。我见过有同事抓了 2 小时的码流文件直接喂给 analyze，结果 8G 内存的服务器直接 OOM——这不是工具的问题，是使用姿势的问题。正确做法是先tsp -I file big.ts -P t2p -O file segment_60s.ts -t 60截取一段，再丢给 analyze。

4. 把 TR101290 结果转成总结报告：格式、分级与结论推导

4.1 报告结构：一页纸让领导看懂码流发生了什么

转 TR101290 总结的"转"字，核心就在于把技术参数翻译成管理语言。我常用的报告模板分四段，每段一页以内。第一段是"结论"，直接写"本次检测判定传输链路存在间歇性丢包，建议排查卫星接收机到复用器之间的 ASI 线缆及接头"。第二段是"证据"，列出关键错误参数和出现时间点，用表格呈现。第三段是"影响评估"，分级说明用户可感知的症状。第四段是"建议动作"，写清楚先做什么、后做什么、谁来做。

这里有个容易踩的坑：不要把 tsduck 生成的原始报告整篇贴上去。原始报告里有大量"符合标准"的噪音信息，比如每个 PID 的 PCR 抖动最大值和最小值。领导和业务同事只看"有没有超阈值"和"影响什么业务"。我的习惯是只摘录超过阈值的参数，并且每个参数后面加上"人话翻译"——比如"PAT 超时"后面括号里写"机顶盒找不到频道列表，可能表现为开机后长时间黑屏"。

4.2 参数归一化：把三优先级转成一个可比较的健康度分数

总结报告人人会写，但"转"得有没有价值，取决于有没有把参数归一化成一个可比较的指标。我常用的做法是给每个优先级设一个扣分项，一级参数每个错误扣 10 分，二级扣 5 分，三级扣 2 分，然后用 100 分减去总扣分得到"健康度分数"。这样做的目的是跟踪趋势——今天 98 分，明天 95 分，后天 90 分，虽然每天都"在及格线以上"，但趋势说明链路在劣化。单纯看"是否有告警"是布尔判断，看不出来劣化趋势。

# 把三个优先级的错误计数换算成健康度分数 def calc_health_score(p1_errors, p2_errors, p3_errors): score = 100 score -= min(p1_errors * 10, 50) # 一级最多扣 50 分，避免单一故障直接清零 score -= min(p2_errors * 4, 30) # 二级最多扣 30 分 score -= min(p3_errors * 1, 10) # 三级最多扣 10 分 return max(score, 0) health = calc_health_score(p1=2, p2=7, p3=15) print(f"码流健康度: {health}/100")

这个脚本里的扣分上限是拍脑袋定的，但拍脑袋也有讲究。一级参数如果持续报错，说明链路物理层已经不安全了，扣 50 分是为了让报告一眼看出"这路流有问题"。二级参数里的 PCR 抖动受网络影响大，扣 30 分是为了区分"物理链路故障"和"网络质量劣化"两种场景。三级参数问题通常不影响实时收看，扣 10 分足够了。这套评分体系不一定适合所有团队，但作为内部追踪指标，它比"有几个告警"要直观得多。

4.3 一个完整的"转"的案例：从原始日志到报告结论

拿一个实际案例演示一遍完整流程。某次上午 10 点接到投诉，说某体育频道画面每隔几分钟就卡一下。我抓了 120 秒码流，tsduck 报告显示：PID 0x0180（体育频道视频 PID）CC 错误 23 次，PCR 抖动最大值 280ns（标准 500ns），其他 PID 全部正常。关键信息是"只有这一个 PID 有问题"，这就把排查范围缩小到了编码器和复用器之间的单路通道，而不是传输链路。

报告我这么写："本次检测 120 秒内，体育频道视频 PID（0x0180）发生 23 次连续性计数错误，平均每 5 秒一次，频谱表现为周期性丢包。其余 PID 正常，说明传输链路整体稳定，故障局域在体育频道编码器输出至复用器输入之间。建议排查编码器 ASI 输出接口、连接线缆及复用器对应输入板卡。"这段文字的价值在于，运维可以直接拿着它去机房查设备，不用再从一堆 16 进制数据里翻根因。

这个案例说明，"转总结"的本质是"定位责任边界"。同样是 CC 错误，如果所有 PID 都跳，那是复用器后面整个链路的问题；如果只有某个 PID 跳，那是该 PID 源头的问题；如果是 PCR 抖动大但 CC 正常，那是时钟恢复的问题，跟丢包无关。把这层逻辑在报告里讲清楚，比堆砌参数有用得多。

5. TR101290 分析避坑记录：五个让我翻过车的真实案例

5.1 现象：CC 错误大量出现，但画面完全正常

原因：复用了空包（Null Packet）填充后的 PID 值。有些老旧的复用器在删除空包时没有正确重置 CC 计数器，导致部分 PID 的 CC 突然跳变，而实际承载的有效数据没有丢。解决：用 tsduck 的-P continuity -n参数，让它只统计非空包的 CC 错误。我第一次碰到这个场景时差点把复用器整机换了，后来才发现是计数器的历史遗留问题。这类"假告警"在信号源来自转播车或临时链路时特别常见。

5.2 现象：PCR 抖动超标，但用示波器测编码器输出完全正常

原因：测量点位于 IP 网络之后，网络抖动被算进了 PCR 测量结果。TR101290 标准规定 PCR 抖动的测量应该从解调器输出的 TS 流上测，如果中间隔了 IP 封装和解封装，RTP 时间戳的重映射会引入额外延迟。解决：在报告里注明测量点位置，或者把测量点前移到复用器 ASI 输出口。这个坑我栽过一次之后，现在所有报告都会写明"测量位置：复用器 ASI 输出/IP 网关输出"，避免让后端同事瞎猜。

5.3 现象：PAT 错误间歇性出现，每次持续不到 1 秒

原因：复用器的 PSI/SI 生成器在更新 PAT 版本号时，偶尔会有一个 188 字节的包没发出去。这不是标准的"PAT 超时"，而是"PAT 更新过程中的瞬时抖动"。解决：延长测量窗口到 10 分钟以上，如果错误不累计，判断为瞬态问题，记入台账观察；如果错误持续累计，再联系复用器厂商查固件 bug。这里的关键是不要看到 PAT 错误就慌，先用时间戳确认错误的分布形态。

5.4 现象：三个优先级全部报错，但换了分析仪之后全部消失

原因：分析仪自身输入接口的阻抗不匹配，导致误码。ASI 接口的传输距离和线缆质量非常敏感，我遇到过用 15 米长的劣质同轴线接了分析仪，结果仪器自己产生了大量误码，把链路本身的问题掩盖掉了。解决：换短的高质量线缆，或者用环通输出口连接分析仪，避免在链路末端引入新的电气不匹配点。

5.5 现象：EPG 空白，但 SDT/EIT 表分析结果正常

原因：SDT 和 EIT 表本身有数据，但机顶盒因为 NIT 里的频点参数错误，根本没锁定到正确的传输流上。这个"三级参数正常但业务异常"的案例，核心是 SI 表的"链路一致性"问题——不是表坏了，而是表和实际网络参数对不上。解决：同时查看 NIT 的实际频点参数和前端调制器的输出参数，逐项比对频率、符号率、FEC 设置。这类问题在频率规划调整后特别容易发生，因为总有人改了前端忘了改 NIT。

6. 把 TR101290 当运维抓手：从一次告警到一套趋势基线

TR101290 参数不只是故障排查的工具，更应该是日常运维的基线数据。我的做法是每天凌晨对全网所有主用码流跑一次 10 分钟检测，把每个码流的健康度分数和关键参数存进 InfluxDB，用 Grafana 拉趋势图。这样一来，当某天某个码流的 CC 错误从 0 变成 5，我立刻知道是"出现了新的劣化"，而不是"它一直有错只是今天才看到"。这套思路坚持一个月，就能摸清不同频点、不同时段、不同节目源的底噪水平——有的频点天生比别的频点多 2~3 个 CC 错误，这可能是历史设备问题，不影响业务，但如果有一天这个底噪翻倍了，就得警惕了。

具体落地上，我会在 Grafana 上建两个面板：一个显示所有码流的健康度分数排行，另一个显示每个码流的一级参数错误趋势。排行的作用是对比——哪个码流的分数在往下掉，一眼就能看见。趋势面板的作用是找规律——如果某个码流每天固定晚上 8 点开始出现 PCR 抖动，那大概率是复用器在晚间峰值时段的资源调度问题，而不是链路故障。这些经验不是标准文档里能学到的，是天天看曲线看出来的。

做这行久了，我越来越觉得 TR101290 不是一本翻完就合上的标准，而是一套持续运转的体检系统。体检报告一年做一次没用，得天天量体温才有意义。希望这套从参数到报告、从报告到基线的打法对你有点启发，也希望你能少走我当年踩过的那些弯路。

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