简介面向数字电视与MPEG-2传输流初学者的TR101290总结文档系统梳理ES、PES、TS、PS四大流结构从访问单元定义、PES分组最大64K字节、TS固定188字节分组及调整字段等细节逐步拆解帮助读者快速厘清数字电视信号传输与保存的基本线索。文档重点解读PSI节目专用信息涵盖PAT0x0000、CAT0x0001以及由PAT指定的PMT、NIT等表的PID分配与调用关系并结合实例演示从PAT找到PMT、再按原始流PID定位视频、音频和数据流的完整过程能有效解决多路节目复用中的定位与解析疑问。除此之外还介绍了PSI表周期性发送、CAT加密信息ECM/EMM和NIT网络参数等实际应用要点并附部分保留PID速查表方便查询。压缩包内含单个doc文档整体仅1.11MB图文与表格对照适合机顶盒、DVB、音视频编解码方向的开发者作为入门或复习资料。已有278人学习对于需要理解TS流结构、调试复用器或准备相关技术面试的读者可节省自行整理标准知识的时间。1. TR101290不是协议是一条码流验收流水线任何一个做过编码器交付或前端系统集成的人都可能在某个节点被客户问住“能不能按 TR101290 出一份测试报告”TR101290 不是业务协议而是 ETSI 针对 MPEG-2 TS 码流发布的一套测量指南它把能导致黑屏、花屏、卡顿、丢台的 TS 层故障归纳为三个优先级按“能不能解出画面、画质会不会劣化、业务会不会中断”逐层展开排查。标题里的“转 TR101290 总结”实际就是两件事把待测码流转进这套监测流程再把监测结果转成一份看得懂、能决策的交付文档。下面按最常见的落地场景写编码、复用、转码链路的验收与回归。这套流程适合三类人——前端系统集成工程师、编码器/复用器固件测试、IPTV 或广电播出的值班维护。目标是让你今天就能在本地跑出一条 TR101290 报告并清楚它的可信度边界。2. 先看懂 TR101290 在查什么三级优先级与判定边界TR101290 的核心是一张按优先级组织的错误清单它不是让测试仪器“报个错”就完事而是按故障影响程度排序帮你从一堆告警里快速定位根因。下面把每一级拆开讲重点放在“判据是什么”和“常见误读”上。2.1 优先级 1解不出画面的硬错误第一优先级共五项TS 同步丢失、同步字节错误、连续性计数错误、PAT 错误、PMT 错误。这组错误直接决定解码器能否锁定码流并解出第一帧画面。TS 同步丢失TS sync loss指解码器连续找不到 0x47 同步字节同步字节错误sync byte error是找到了 0x47但它的位置不在 188 字节包边界上。这两种通常由链路误码、文件截断或复用器输出异常引起是最基础的硬故障。连续性计数错误continuity count error是现场出现频率最高的一项。每个 PID 独立维护一个 4 bit 计数器每收到一个 TS 包加 1到 15 后回 0。解码器期望同一个 PID 的下一个包计数值比上一个大 1如果出现 0 或 2说明发生了丢包或重复发包。判断时要注意这个指标必须按 PID 分组看混在一起统计没有意义。高频 PID 丢一个包只算一次错误低频 PID 可能隔很久才来一个包丢一个就非常显眼两者的业务影响完全不在一个量级。PAT 错误和 PMT 错误属于 PSI 表超时或表内字段错误。PAT 固定出现在 PID 0x0000 上规定周期内必须出现一次PAT 里的每个 program 都必须能在 PMT 上找到对应节目。PMT 错误还包括 PMT_PID 在 PAT 中指到了不存在的 PID以及 PMT section 的 CRC 失败。实际排查里PAT 正常但 PMT 报错多半不是码流文件坏了而是复用器改动过 PMT_PID接收设备还在用缓存的旧值。2.2 优先级 2画质劣化与时间戳问题第二优先级关注 transport_error_indicator、CRC 错误、PCR 相关错误和 PTS 相关错误。这一级不直接导致完全黑屏但会造成花屏、音画不同步、解码器反复重同步。transport_error_indicator 是 TS 包头里的一个标记位由前级系统在发生无法恢复的丢错时置 1CRC 错误则针对 PSI/SI 表含义是某张表的 section 内容在传输中损坏。这两个指标高发通常指向信道误码而不是复用器本身。PCR节目时钟基准是这一级里最值得花时间理解的指标。解码器靠 PCR 恢复出视频和音频的时钟PCR 间隔过长会导致时钟漂移表现为播放一段时间后音画不同步PCR 抖动超过阈值会造成解码器频繁调整时钟画面出现周期性卡顿。行业里常用的 PCR 抖动阈值是 500nsPCR 间隔常见判据是不超过 100ms。PTS显示时间戳允许在流里重复两次以对抗误码但重复间隔不能过长也不能出现非单调递增。PTS 异常的症状比 PCR 更直接画面还在动声音已经慢半拍或快半拍。注意同一段码流用不同时钟参考去测 PCR 抖动结果可能差一个数量级。自由运行的解码器时钟和锁相后的参考时钟测出来的 jitter 数值完全不同。所以从这一章开始就要建立一个习惯报告里必须写清 PCR 参考源是什么否则 PCR_Jitter 这个数字没有可比性。2.3 优先级 3PSI/SI 与业务持续性第三优先级针对 NIT、SDT、EIT、TDT/TOT、RST、CAT 等 PSI/SI 表格。它们不直接影响当前画面却决定切台速度、EPG 显示、CA 授权和待机唤醒。NIT 丢了部分接收机切台变慢EIT 丢了EPG 变成空白TDT/TOT 丢了接收机失去时间校正待机后唤醒可能出现黑屏CA 相关的 CAT 或描述符异常轻则加密节目授权延迟重则直接解不出节目。这一层容易被当成“无关紧要”但现场反馈里“切台转圈三秒”“EPG 是空的”“待机一晚黑屏”这类问题十有八九要落到 P3 的表缺失或周期超时上。P3 层面的排查特点是要有耐心。P1、P2 错误通常几十秒内就能复现而 EIT 或 TDT 的缺失可能要等一个完整发送周期才暴露一次所以统计窗口不能太短。2.4 阈值不是标准硬编码用哪组阈值要写进报告TR101290 是测量指南不是合格判定标准它规定了“测什么”和“怎么测”但没有给出每个项目唯一的合格线。真正在你验收报告里出现的阈值来自行业实践和上下游约定。下面是我常用的基础阈值组供参考。指标常用阈值说明PCR 抖动500 nsDVB 测量指南建议值高清、4K 建议收紧PCR 间隔≤ 100 ms超过即报 PCR 间隔类错误PAT 周期≤ 500 ms前端系统常收紧到 100 msPMT 周期≤ 500 ms与 PAT 同步收紧TDT/TOT 周期≤ 30 s超过影响时间校正EIT 周期≤ 30 s实际 EPG 周期越短越稳阈值不统一会带来一个很尴尬的局面同一个码流A 厂商用宽松阈值测出来合格B 厂商用收紧阈值测出来不合格两边都坚持自己是对的。所以从项目一开始就把“使用哪组阈值”写进报告环境表比争论谁的仪器准更有价值。这一步是后面第 6 章总结模板的第一项强制内容。3. 把一段 TS 流转进 TR101290 监测最小可复现流程这一章直接用能在 Linux 工作站上跑通的流程覆盖文件离线分析、IP 实时监测、转码后回归验证三步。所有命令以 tsduck 工具集为前提这是 TS 分析领域最常见的开源工具安装后包含 tsanalyze、tsp 等命令。不同版本参数略有差异遇到参数对不上时先执行带--help的命令自查。3.1 文件级离线分析一条命令出报告先把抓回来的 TS 文件喂给 tsanalyzetsanalyze captured.ts tr101290_report.txt 21如果手头版本没有独立的 tsanalyze 命令改用传输流处理主程序 tsp 的 analyze 插件tsp -I file captured.ts -P analyze -o tr101290_report.txt逻辑说明第一条命令把 TS 文件的 TR101290 分析结果重定向到文本文件第二条用-I file指定文件输入-P analyze在流水线上挂分析插件-o把分析结果写文件而不是刷屏。分析插件会把错误按优先级 1/2/3 分组输出包括每个错误的计数和出现位置。第一次执行前先跑tsp -P analyze --help确认当前版本支持的参数避免凭记忆写参数。参数说明analyze 插件默认对全 PID 统计。在多节目复用流上默认统计会得到一个很大的计数总量但这不代表所有节目都受影响。真正看报告时Priority 1 里只要 TS sync loss、continuity count error、PAT/PMT error 有非零值这个文件就已经不满足“可稳定解码”的底线。P1 全为 0 才具备往下谈画质和业务的前提。3.2 实时监测 IP 流从 UDP/RTP 接入到告警落盘文件分析适合验收测试连续监测要接实时流。常见做法是用 tsp 的 IP 输入插件直接监听 UDP 组播或单播端口tsp -I ip 239.1.2.3:5000 -P analyze -o live_report.txt现场是单播流时把地址换成192.168.1.20:5000RTP 封装需要先解封装tsduck 在 IP 输入侧做 RTP 处理具体选项以tsp -I ip --help输出为准。逻辑说明这条命令是边收边测分析插件在每个统计窗口结束时刷新错误计数输出文件里保存的是累计值。要做持续告警更稳的做法是把统计结果推给监控系统而不是靠人盯终端。实时监测的统计窗口不能太短我最小用 3 分钟窗口。原因很简单PAT/PMT 周期最长 500msTDT 发送周期最长 30s窗口只有 10s 时P3 类的低频表缺失根本测不出来误判率会非常高。参数说明IP 输入的缓冲区设置要关注。码率 20Mbps 的流缓冲区默认值可能不够遇到突发丢包但交换机统计正常的现象优先调大输入缓冲再谈码流问题。3.3 转码/复用后的回归验证先构造一条“已知坏流”验证监测链路本身没瞎比验证设备更重要。我习惯先用 ffmpeg 造一条正常流再用 dd 从中间断开制造同步错误把两条流都过一遍分析器ffmpeg -f lavfi -i testsrcduration10:size720x576:rate25 -c:v mpeg2video -f mpegts ok.ts dd ifok.ts ofbroken.ts bs188 count200 skip7 tsanalyze broken.ts第一行生成 10 秒的 MPEG-2 TS 测试流第二行跳过 7 个 188 字节包后取出 200 个包相当于从一个 TS 包中间开始切同步字节全部错位第三行分析这条坏流。预期在报告里看到 sync loss 和 continuity count error 明显上升。逻辑说明这个“坏流对照”的价值在于确认环境参数是对的。如果 broken.ts 都测不出任何错误说明要么过滤条件太严格把错误滤掉了要么分析器根本没真正工作。每次换工作目录、换软件版本时先跑一遍对照能省下后面排障的大把时间。参数说明bs188是 TS 固定包长count200保证样本量足够skip7是从文件中间起切不要用 0。从 0 开始切还是在包边界上什么错误都造不出来。4. 阈值、过滤与抽样三个让结果可信的配置细节TR101290 报告难的不是测出来而是测出来的数字能不能拿来下结论。下面三个配置细节是现场最容易拉开差距的地方也是很多人测完不敢签字的根因。4.1 PID 过滤别让空包污染连续性计数多节目复用流上空包 PID0x1FFF会一直填充剩余带宽。全 PID 统计时空包的连续性计数也会被计入错误所以报告里“continuity_count_error500”可能一半来自空包真实业务 PID 根本没有丢包。常见做法是把分析范围限定到业务 PID 集合单节目流只测 0x0000PAT、PMT 指到的视频/音频 PID 和 PCR PID多节目流按目标节目从 PAT 里把对应 PID 列表摘出来。tsp 的 analyze 插件里通常有过滤或白名单参数具体字段名以tsp -P analyze --help为准但思路不变——先拿目标节目 PID 清单再让分析器只看这些 PID。逻辑说明连续性计数按 PID 独立维护全扫描会把不同 PID 的丢包直接求和这个总数不反映任何单一节目的体验。按 PID 分组后才能回答“哪个节目在丢包、丢了多少”。只看总量去定位故障很容易把空包导致的数量虚高当成业务损伤白白排查半天。4.2 取样窗口与去抖把网络抖动和码流缺陷分开IP 传输的 TS 天然带抖动。交换机拥塞、网卡中断合并、RTP 重排都会在 PCR 测量里表现为抖动超限。直接把 IP 镜像口数据喂给分析器很容易得到“全线 PCR 错误”的假象而码流本身可能是干净的。我常用的做法是先抓到 pcap在 Wireshark 里按 RTP 序号重排再导出 TS 喂给 tsanalyze连续跑 3 分钟以上比较重排前后的 PCR jitter 变化。重排后错误明显减少说明是网络抖动问题重排后错误原样保留才是码流本身的 PCR 缺陷。逻辑说明PCR 测量本质上测的是包到达时间规律网络把 TS 包拉伸或压缩就会叠加额外抖动。设备端通常有 jitter buffer软件分析器如果直接测原始到达时间必须自己加等效去抖。没有现成去抖参数时用重排后的文件作为判定依据最稳妥。参数说明去抖深度参考主视频码率1080p25 的流我习惯缓冲 200ms标清流 100ms。不要拉满到秒级去抖太深会把真正的 PCR 错误也抹平等于把设备缺陷洗干净了。4.3 输出格式文本给人工XML 给系统tsanalyze 默认文本报告适合人工看但接持续集成和告警系统需要结构化输出。把文本报告转成 CSV 的小脚本如下注意正则要兼容带空格的字段名#!/usr/bin/env python3 import re import csv import sys from pathlib import Path def main(): path Path(sys.argv[1]) text path.read_text(encodingutf-8, errorsignore) rows [] # 匹配 字段名: 数值字段名允许包含空格与点号 for mo in re.finditer(r^([\w\s\.]?):\s*(\d), text, re.M): rows.append((mo.group(1).strip(), int(mo.group(2)))) if not rows: raise SystemExit(no metrics found, check report format) with open(summary.csv, w, newline) as f: writer csv.writer(f) writer.writerow([metric, count]) writer.writerows(rows) print(fconverted {len(rows)} metrics to summary.csv) if __name__ __main__: main()逻辑说明正则^([\w\s\.]?):\s*(\d)按行匹配字段名部分既匹配TS sync loss这种带空格的名称也匹配PID 0x0101: 3这类子项。如果报告里有HH:MM:SS格式的时间戳同样会被匹配进来需要先看一眼真实输出再决定是否加过滤条件。参数说明这个脚本只做格式转换不做阈值判断。阈值判断统一放在第 6 章的回归入口里避免每个脚本里散落一份阈值逻辑改阈值时到处漏改。5. TR101290 现场排查五个高频坑与排查顺序注意下面五条按我现场固定的排查顺序排列先查链路和统计方式再怀疑码流本身。顺序反过来十次有八次会白忙活。5.1 现象continuity_count_error 刷屏画面完全正常原因统计没按 PID 过滤空包或加扰流里的填充包被计入或者是抓包工具自己丢了包把抓包丢失算成了码流丢包。解决先用固定样本文件重测样本来自 pcap 重排后导出的 TS再按 PID 分组看错误归属。如果错误 PID 集中在 0x1FFF 或低频 PID 上多半是统计口径问题不是业务损伤。只有错误集中在视频、音频和 PCR PID 上才需要往前端设备查。5.2 现象转码后 PCR_Jitter 全线超限原因转码器或复用器重新打时间戳时没有做 PCR 重标PCR 和实际到达时间错位或者视频编码器用自由运行时钟没有锁到系统参考时钟上。解决用带 PCR 重标能力的复用器配置里把 PCR 源指定为编码器输出或外部参考时钟转码链路里所有设备锁同一个参考源。改完重测重点看 Priority 2 里的 PCR_Jitter 是否回落到 500ns 以内。这条在转码验收里几乎必现不是仪器问题。5.3 现象PAT 正常PMT 却报错原因PAT 中的 program 号没变但 PMT_PID 被复用器改了接收机或分析器还缓存着旧的 PMT_PID或者 PMT 的 section 重复周期超时。解决确认 PAT 中每个 program 对应的 PMT_PID 和实际 PMT 的 PID 一致重启测试设备清缓存。手工验证可以用分析工具单独拉 PID 0 并 dump PAT 内容比对 PMT_PID 字段。5.4 现象实时监测报错离线文件分析却干净原因实时链路有丢包或抖动而抓包工具用重排序或重传机制掩盖了也可能实时监测和分析文件用了不同的 PID 过滤条件统计口径不一致。解决把同一组流抓两份一份直接喂实时分析器一份先重排再离线分析比较两者差异。差异集中在 PCR/Jitter说明网络层抖动为主差异集中在 continuity 和 PAT说明链路丢包为主。比较之前先确认两边的 PID 过滤条件一致。5.5 现象文件抓回来一切正常一接设备就报 P1 错误原因设备输出的 TS 层本身有问题比如 ASI 接口误码、复用器在切换节目瞬间没有发 SI 表或者设备输出码率超出分析仪器输入口处理能力导致分析器自身丢包。解决用设备自带的监测口或镜像口抓流确认抓到包的连续性把输出码率降到设备标称值以下再测一轮。设备侧自带 TR101290 自检时先跑一遍自检把自检结果和外部仪器结果对齐。这条坑最容易归咎为“仪器问题”实际仪器同步丢失率通常很低先怀疑输出端更靠谱。6. 从监测数据到 TR101290 总结报告一套可复用的导出与回归习惯6.1 报告固定三张表阈值组写进环境表我出的 TR101290 报告固定三段环境表、三级汇总表、失败明细。环境表里写输入源、接入方式、统计窗口、阈值组、软件版本三级汇总表把 P1/P2/P3 的每个错误计数列出来失败明细记录错误 PID 和时间点。没有环境表别人拿到你的“P1 全 0”结论根本无法复现换一台仪器、换一组阈值就可能得出相反结论。6.2 把 TR101290 接进发布流水线给一个最小回归脚本跑完直接判断通过与否#!/usr/bin/env bash set -euo pipefail tsanalyze golden.ts report.txt 21 python3 parse_report.py report.txt summary.csv awk /Priority 1/{flag1} /Priority 2/{flag0} flag /: [1-9]/{exit 1} report.txt逻辑说明awk 片段负责在 Priority 1 段落内找非零计数找到就退出码 1CI 判定失败。/Priority 1/{flag1}进入 P1 段/Priority 2/{flag0}离开 P1 段flag /: [1-9]/匹配“字段名: 非零值”。这个写法不依赖具体字段名只要报告按优先级分段落就能用。我个人的习惯是每次回归都拿上一版报告做 delta 对比不看绝对值。绝对值容易受统计窗口、PID 过滤条件影响同一条流换个窗口就变样而同一环境下两次回归的差值能直接暴露“这版固件让 PCR 抖动翻了一倍”这类隐蔽劣化。有一次就是因为只看绝对值得出“合格”结论漏掉了 PCR 抖动翻倍的问题后来所有报告都自动留档跑完先比 delta 再下结论这个习惯救过我不少次。希望帮到你。本文还有配套的精品资源点击获取