简介面向数字电视与MPEG-2传输流学习者的总结文档围绕TR101290标准系统梳理了ES、PES、TS、PS四种数据流的结构与特点ES为编码压缩后的原始流包含访问单元PES是原始流的分组分组首部加有效负载最大可达64K字节TS是188字节的传输包必要时附加调整字段PS则适用于DVD等不易出错的环境。文档重点介绍了PSI节目专用信息体系对PAT、CAT、PMT、NIT四张表的PID取值、作用和解析顺序进行了说明并给出从PAT定位PMT、再由PMT获取音视频PID的完整解复用流程同时结合实例分析帮助读者理解数字电视信号的复用与解复用原理。资料为单个doc文档大小1.11MB排版紧凑适合作为开发与测试中的快速查阅手册。目前已有278人次学习下载适合刚接触数字电视协议或希望系统理解TS流结构的工程技术人员。1. TR101290DVB 质量监测的默认语言三层告警一次说清做数字电视和 DVB 信号质量监测的工程师几乎没有谁能绕开 TR101290。它是一套 ETSI 定义的测量准则不关心你用的是 QAM 还是 OFDM也不管前面是编码器还是复用器只管把 TS 流里的错误按严重程度拆成三层优先级从最致命的 TS 同步丢失一路排到 PTS 误差这类相对次要的指标。搞懂它你就拿到了和码流分析仪、第三方验收报告、前端监测系统对话的同一套语言。这份转 TR101290 总结资源是我把三层告警的触发条件、参数配置和实际踩坑记录归拢成的一份可直接照做的材料适合做码流分析、机顶盒测试、前端监测系统交付的工程师。标准原文你不需要死记但你需要这份把标准翻译成可操作步骤的笔记。2. 三层优先级怎么判定从 TS 同步丢失到 PTS 误差每个告警的触发条件2.1 优先级 1 层五个直接判死的指标TR101290 的优先级 1 是整套体系里最狠的一层任何一项触发基本意味着传输层已经处于不可用状态解复用器拿到这个码流大概率直接黑屏。五个判定指标分别是 TS 同步丢失、同步字节错误、PAT 错误、连续性计数错误和 PMT 错误对应的判定条件如下表。指标判定条件触发意味着什么TS_sync_loss连续 2 个 TS 包的同步字异常或丢失传输层整体失步最严重的状态Sync_byte_error同步字节不是 0x47单包级别误码可能伴随丢包PAT_errorPAT 表到达间隔超过 500ms或 section 内容不合法解复用直接瘫痪找不到节目Continuity_count_error同一 PID 的 continuity_counter 不连续存在丢包或重复包PMT_errorPMT 到达间隔超过 500ms或节目信息错误音视频流无法定位TS 同步丢失和同步字节错误经常一起出现但含义不同。前者看的是连续两个包都丢了同步字属于失步级别后者只是单个包里的 0x47 被误码改写了。我在实际监测里见过最多的情况是链路误码率高的时候同步字节错误先冒出来紧接着就是连续性计数错误最后才演变成同步丢失。所以排查顺序应该是先看 sync_byte_error 的出现频率再判断是不是已经在向 TS_sync_loss 演化。PAT 和 PMT 的 500ms 间隔是 290 标准里的经典参数所有正经的码流分析仪都按这个阈值判。这两个表属于 PSI 表解复用器要靠它们才知道节目结构长什么样表超时比内容错误更隐蔽——内容错误一般立刻黑屏超时则表现为开机慢、切台慢、偶尔卡在加载中。2.2 优先级 2/3 层PCR、SI 重复率与缓冲器时间窗口比指标本身更关键优先级 2 层关注的已经不是「能不能解出来」而是「解出来以后质量够不够」。PCR 误差看的是 PCR 到达间隔标准里按帧率给了两档25fps 的系统PCR 间隔超过 40ms 就算 PCR_error30fps 的系统可以放宽到 100ms。PCR_accuracy 则是另一个维度的判定看 PCR 值本身抖不抖容忍范围是 ±500ns。这两个指标经常被混为一谈实际上一个管间隔、一个管精度PCR_error 报警时先确认你选的是不是主节目的 PCR PID我曾经在一套多节目复用流上把辅助 PCR PID 当成主 PCR 来测抖动自然超标。PTS_error 属于这一层里最容易被漏掉的因为它不是每帧都出现只在 PTS 重复、回退或缺失时才触发。监测端如果只看短期窗口很容易错过。传输错误指示位和 CRC 错误也在这层CRC 错误主要针对 section 级别的表数据数据被误码污染后校验失败和物理层的误码率直接正相关。优先级 3 层是告警数量最多的包含 NIT_error、SI_repetition_error、Buffer_error、Unreferenced_PID、SDT_error、EIT_error、RST_error、TDT/TOT_error。这一层的特点是没有统一的硬阈值SI 表的重复率按表类型分别给参考值NIT 推荐 10s 一次SDT 建议 2sEIT 建议 25s 以内TDT/TOT 建议 30s。实际判的时候监测设备一般取目标值的几倍作为容差比如 NIT 超过 25s 才报错而不是严格卡 10s。层指标代表判定核心时间窗口优先级 1TS_sync_loss、PAT_error、CC_error传输层可用性500ms/连续包优先级 2PCR_error、PCR_accuracy、CRC_error解码质量40ms/100ms、±500ns优先级 3NIT_error、SI_repetition_error附加信息完整性秒级到几十秒级Buffer_error 是这层里最像玄学的一个它检测的是 TSTD 缓冲器模型的上溢和下溢。问题在于缓冲器模型和实际解码器的缓冲实现并不完全一致经常出现监测端报了、解码器却没问题的反向情况。我的处理习惯是Buffer_error 单独记录不参与前三层的优先判级只有连续多次触发才升级处理。3. 把裸 TS 流跑成 TR101290 指标监测流程、参数档位与可执行步骤3.1 动手前先定三件事码流来源、时间窗口、统计口径转 TR101290 监测之前我一般会先把三个前置条件定死否则后续所有告警数据都是糊涂账。第一是码流来源离线文件可以直接整段扫描实时码流就要考虑是旁路镜像还是分光获取采样位置不同误码表现完全不同分光点之前的链路错误不会体现在你的监测结果里。第二是时间窗口。TR101290 标准本身不规定统计时长但所有判定的结果都受窗口影响。常见的做法是 5 秒判定窗口加 1 秒轮询每秒钟采一次样连续 5 秒内错误事件累积到阈值才上报。窗口太短会把瞬时抖动误报成持续故障窗口太长又会掩盖偶发丢包。第三是统计口径这里是最容易翻车的。同样是连续性计数错误有的设备按事件次数统计有的按持续秒数统计还有的按涉及 PID 的数量统计。我在交付监测系统时会先把口径写进验收文档错误事件定义为「一次从正常到异常的跳变」一个 PID 连续 10 个包不连续只算一次事件而不是按丢包个数累计。3.2 用开源的 tsduck 跑一遍三层分析命令、参数与输出解读tsduck 是目前我用下来最适合做 TR101290 前期验证的开源工具包单文件就能跑不需要图形界面。先跑 analyze 插件它会输出整个 TS 的基本结构和整体错误概览。tsp -I file input.ts -P analyze -o report.txt这条命令把 input.ts 作为输入文件交给 analyze 插件分析结果写入 report.txt。analyze 输出里能看到总码率、包数量、同步丢失事件、PAT/PMT 间隔统计这些基础信息适合先建立整体印象。逻辑上它是在做单遍扫描把每个 TS 包过一遍统计器所以跑得很快一个 10 分钟的文件几秒钟就出结果。接下来要细分到 PID 级别分析连续性计数和 PCR 指标tsp -I file input.ts -P continuity -p -1 -P pcr -p -1这里的 -p -1 表示扫全段所有 PID不限定范围。continuity 插件会按 PID 输出连续性计数错误的位置和涉及包序号pcr 插件计算 PCR 间隔和抖动值。参数说明如果你只想看某个节目可以把 -1 换成具体的 PID 值比如 -p 0x0100减少干扰项。我一般先全扫一遍拿到全景再对异常 PID 单独跑一次。如果要对 PSI/SI 表做间隔验证用 tables 插件tsp -I file input.ts -P tables -p -1 -o tables.txttables 插件输出所有表的到达间隔、section 数量、CRC 校验结果直接用 grep 过滤对应表名就能判断是不是超时。3.3 阈值档位怎么调不同业务场景的实践配置同一个 TR101290在不同场景下的参数档位完全不同。我按业务场景整理过一套实践配置可以直接抄。场景PAT/PMT 阈值PCR 阈值SI 重复率建议监测时长播出前端验收500ms40ms按标准值严格判30 分钟以上机顶盒兼容性测试500ms100ms放宽 1.5 倍视测试用例而定传输链路排查500ms40ms不关注持续监测定位突发现象播出前端验收是最严格的场景所有参数按标准死卡而且监测时长要够长我一般至少录 30 分钟的码流覆盖一个完整的轮播周期。机顶盒兼容性测试反过来重点看优先级 1 和 PCR 相关SI 重复率可以放宽因为很多老解码器本身对 SI 表超时就不敏感。传输链路排查场景最特殊优先级 3 的 SI 指标基本不看重点抓 Transport_error 和 CRC_error 的聚类特征这两个指标的突增通常指向物理层问题。参数档位调完之后别忘了和码流分析仪的出厂设置做一次并排对比。不同仪表对时间窗口的默认值不一样有的用 1 秒判定有的用 10 秒这会导致同一段码流两台设备报出完全不同的结论。4. 转 TR101290 常见问题排查五个高频误判与修正记录4.1 连续性计数大面积告警但画面没有任何异常现象监测报告里 Continuity_count_error 覆盖了一大半 PID但解码画面全程正常没有破块也没有卡顿。原因监测端把空包 PID0x1FFF和填充包也纳入了连续性计数统计空包的 continuity_counter 在部分复用器里不是递增的直接导致误报。解决在监测配置里显式过滤 0x1FFF并且只对承载 PES 的音频、视频 PID 做连续性判定。我的习惯是先把 PID 清单导出来排除空包、NIT、SDT 这类非业务 PID再跑计数检查。4.2 PCR_error 频发但 PCR_accuracy 完全正常现象优先级 2 层 PCR_error 每分钟报一次但同一条流上 PCR_accuracy 稳定在几十纳秒级别没有任何抖动。原因PCR_error 判的是到达间隔不是精度。如果 PCR PID 选错选到了一个低频率插入 PCR 的辅助节目间隔自然超标。另一个常见原因是时间窗口设得太短把正常的间隔波动也判成了超时。解决先确认 PCR PID 是不是主节目的然后用 40ms/100ms 双档位对比同一段码流。如果 100ms 档位下不报错说明是帧率档位配置问题。4.3 PAT_error 按秒级别重复上报但手动解析 PSI 表一切正常现象PAT_error 高频告警间隔看起来远超 500ms但用表格插件导出 PAT 的内容和到达时间发现间隔其实稳定在 400ms 左右。原因部分仪表在计算表间隔时把「解析耗时」也算进了周期。如果码流本身存在定语法的 section 重传或者仪表解析速度跟不上高码率判定误差会被放大。解决把判定窗口从默认的 5 秒改成 3 秒排除解析耗时的干扰。同时检查 PAT section 是否有重复冗余传输正常的 PAT 周期 500ms 是足够宽裕的。4.4 同一段 TS两台分析设备的告警结果完全对不上现象A 设备报优先级 1 层五项全绿B 设备报 Continuity_count_error 和 Sync_byte_error验收双方拿着结论互相对质。原因统计口径不一致。一个按「每秒错误数」判级错误数低于阈值就显示正常另一个按「是否存在任何一次错误事件」判级出现一次就告警。还有的设备默认带纠错重同步把误码修掉了再统计。解决验收前先把统计口径写进文件明确三个概念错误事件怎么定义、统计窗口多长、是否启用纠错预处理。并排对比时用同一个源文件不经过任何中间设备。4.5 转码后的流 TR101290 全绿但机顶盒就是卡现象转码器出来后的码流跑 TR101290 三层全绿拿到真实机顶盒上播放每隔几分钟卡顿一次。原因TR101290 只覆盖传输层和 PSI/SI 表的正确性不覆盖编码层的主观质量问题。转码产生的 I 帧损坏、GOP 结构异常、P 帧丢失在这个标准里没有对应的告警项。解决在全绿的情况下用解码器实际输出做二次验证检查解码错误率和帧到达时间戳。从那以后我再也不把 TR101290 全绿当作「可以上线」的唯一依据它只是及格线不是满分。5. 进阶用法三层告警判级脚本把监测日志整理成一份可归档的质量报告5.1 脚本思路与判级规则tsduck 的文本日志里每个错误项都有对应的关键字但日志是平铺的不会自动按 TR101290 的优先级归档。我的做法是写一个判级脚本把日志里的错误关键字映射到三层优先级输出一份带统计信息和按 PID 聚合的报告。判级规则直接复用标准优先级 1 层五项为致命级优先级 2 层为严重级优先级 3 层为提示级。5.2 完整脚本与使用步骤#!/usr/bin/env python3 # TR101290 报告判级脚本把 tsduck 文本日志整理成三层质量报告 import re import sys from collections import Counter, defaultdict # 三层优先级的关键字映射 P1 {ts_sync_loss, sync_byte_error, pat_error, continuity_count_error, pmt_error} P2 {transport_error, crc_error, pcr_error, pcr_accuracy, pts_error} P3 {nit_error, si_repetition_error, buffer_error, unreferenced_pid, sdt_error, eit_error, rst_error, tdt_tot_error} def parse_log(path): counts Counter() by_pid defaultdict(int) with open(path, encodingutf-8, errorsignore) as f: for line in f: m re.search(r(?i)\b([a-z0-9_]_error)\b, line) if not m: continue name m.group(1).lower() counts[name] 1 # 尝试从日志行里提取 PID 编号 pid_m re.search(rPID\s(0x[0-9a-f]), line, re.I) if pid_m: by_pid[pid_m.group(1)] 1 return counts, by_pid def grade(counts): p1 sum(counts.get(k, 0) for k in P1) p2 sum(counts.get(k, 0) for k in P2) p3 sum(counts.get(k, 0) for k in P3) return p1, p2, p3 if __name__ __main__: if len(sys.argv) 2: print(用法: python3 tr290_grade.py tsduck日志文件) sys.exit(1) counts, by_pid parse_log(sys.argv[1]) p1, p2, p3 grade(counts) print( TR101290 三层判级报告 ) print(f优先级1 致命: {p1} 优先级2 严重: {p2} 优先级3 提示: {p3}) print(\n--- 按错误类型统计 ---) for name, cnt in counts.most_common(): # 标注每个错误所属的优先级层 if name in P1: layer P1 elif name in P2: layer P2 else: layer P3 print(f[{layer}] {name}: {cnt}) print(\n--- 按 PID 聚合 (仅列出有错误的 PID) ---) for pid, cnt in sorted(by_pid.items(), keylambda x: -x[1]): print(fPID {pid}: {cnt} 次)脚本里最核心的是 parse_log 函数它用正则把日志行里的错误关键字抓出来再通过关键字集合映射到对应优先级。参数说明P1、P2、P3 三个集合就是按 TR101290 标准定义的如果你们内部约定把 PTS_error 归到优先级 1直接改集合就行。by_pid 的聚合逻辑依赖日志里存在 PID 0x... 这样的格式tsduck 默认输出带 PID 标识其他工具导出的日志需要先做格式归一化。运行方式很简单把 tsduck 的命令行输出重定向到文件tsp -I file input.ts -P continuity -p -1 -P pcr -p -1 ts290.log 21 python3 tr290_grade.py ts290.log跑完会得到一份三层的统计报告P1 层的数字一眼就能判断这条码流能不能进下一步流程。脚本里有两处可以按需改关键字集合的正则匹配大小写已经做了兼容但不同版本 tsduck 的错误关键字略有差异如果发现匹配不到先打开日志文件确认关键字格式再往集合里补。我最初跑的时候就是因为日志里写的是 int errors 而不是 continuity_count_error正则匹配半天没结果后来干脆把日志里所有带 error 的词条都打出来人工核对了一遍。从那以后我每次给客户出质量报告都强制把这条判级脚本的输出连同原始日志和码流文件快照一起归档防止验收时双方拿着不同版本的结论扯皮。希望帮到你。本文还有配套的精品资源点击获取