如前所述，播出系统链路涉及到大量的QoS和QoE指标，用于确保电视台或运营商的安全播出和节目质量，这些指标已被大量科学家在实践中证明有效并形成国际标准。现在，我们已经初步了解了信号采集、编码、复用、传输、解码等环节所产生的问题与这些指标之间的联系。

　　没有实践的理论是纸上谈兵且容易犯教条主义的错误。要把学到的理论变成能力，我们就必须在工作中不断地实践。作为播出部门的工程师，离不开以下工作实践：

　　• 产品选型测试

　　• 播出标准规范制订

　　• 日常播出运维监测计划

　　• 故障原因定位和分析

　　• 系统改进及运营优化策略

　　必须注意，这些工作不是简单的重复，因为每项计划的标准规范值并不一致。例如，ETSI TR101290是国际公认的TS流测量功能之一，被所有主流编码、复用、传输、解码、包括码流分析仪或监控/监测系统所采用，因此在产品选型时，把ETSI TS101290测量建议值作为标准之一并无不妥；但在实际播出运维监测时，很多播出工程师就会有新的困惑。

　　11.1. 播出监测告警和实践困惑

　　实践中，您可能产生过两种困惑：

　　1) 监测系统指标告警，但播出端并没有什么问题；

　　2) 播出端有故障，但监测系统没有告警。

　　这些困惑会让您怀疑部署监测系统的必要性，甚至让您怀疑自己有没有必要了解这些复杂的TS流指标。这很正常，这是我们在任何学习过程中都会碰到的挫折感。您所要做的就是更多学习、分析和实践，坚持终究会把努力的人和平庸的人区分开来。

　　11.1.1.  频繁的TR101290监测告警

　　TR101290是一个很好的例子，现实中它被很多工程师用于播出监测指标之一。如果您用TR101290建议标准实时监测播出链路系统，您将会发现很多告警错误——甚至从头到尾都有告警错误，但实际主观察看播出端并没有什么太大问题。你可能会怀疑：是不是TR101290监测已经过时？或者我用的监测系统测量不准？

　　从原理上分析，TS流结构到现在并没有发生太大变化：它仍然是每个数据包188个字节，仍然是前4个字节的包头，仍然是解析PSI得到PAT表和PMT表再指向PES PID，仍然要靠PCR信息锁定本地时钟、靠DTS和PTS作为解码时间和显示时间戳，视频编码仍然是IBP帧结构，……。无论是编码、复用、传输还是解码，所有的设备依然在遵循这些规格和流程。TR101290并不过时！

　　根源在于TR101290中每个指标建议的临界值。比如以下实际案例：

　　PCR_OJ（PCR Overall Jitter，PCR整体抖动）错误

　　TR101290建议PCR_OJ（PCR Overall Jitter，PCR整体抖动）值要控制在±500 ns之间，超出这个范围值将可能会导致Buffer上溢或下溢、引起接收端停帧或跳帧；很多电视台或运营商的这一指标远远超出这个值，但实际并没有带来停帧或跳帧问题。

PCR_OJ错误容忍度监测：超过±500 ns

　　这个实践结果说明：当今的大多数播出或运营商系统环境下，让PCR_OJ发生错误的临界值要远大于±500 ns！ETSI TR101290自上个世纪90年代就作为DVB测量指南，受当时的科技限制，系统设备的容差度要小于现在。不过，对于产品选型时的测量，我们仍然要按±500 ns的建议，它会保证我们设备有更好的兼容广度。至于您的播出环境中PCR_OJ发生错误的临界值具体应该是多少，您必须在实践中观察，因为每家的播出链路环境并不完全一样，后续我们在ATSC推荐实践中有一个借鉴参考。

　　11.1.2.  兼容性问题产生的播出故障

　　播出中出现问题、但监测系统没有任何告警是常见的另一种困惑。

　　我们以一个兼容性问题为例。比如，编码器输出一个VBR（Variable Bit Rate，可变码流）TS流，且没有违反DVB、ETSI或ISO/IEC 13818-1等标准，因此它的监测不会告警错误；但在实际运营中，下游有线、地面或卫星数字电视运营商会抱怨有播出问题。

　　这时，前端播出部门要充分理解各项指标与播出兼容性的关系。和CBR（Constant Bit Rate，恒定码率）相比，VBR编码可根据场景变化适配码率以便在同等画质下更好压缩以节省带宽，但它会增加解码器的开销，因此会导致一些兼容性较差的机顶盒播放时出现卡顿现象。同样的，GOP结构也会导致兼容性问题。所以，前端编码参数的设置，不能一味只考虑质量，它是在质量、带宽和兼容性上的一个综合平衡。

码率监测：VBR编码有更好的质量，但会增加解码端开销

GOP结构监测：自适应GOP有更好质量，但会牺牲解码器兼容性

　　如果您的端到端播出链路中存在这样的问题，那么您就必须重新调整播出系统的监测指标要求，比如加入流码率变化监测告警项和GOP值违反告警项。

　　11.2. 播出链路监测实践中的指标临界值

　　监测系统在播出没有什么大问题时不断告警、或者播出真正出现问题时监测系统却没有告警，都让播出运维人员不胜其烦，他们会怀疑部署监测系统的本来意义。如前所述，这与具体监测指标的错误临界值有关。虽然有时候会违反标准，但对真实世界的解码器并没有什么影响。如果分析仪或监测设备供应商将任何错误都作为告警，那么在多次误报警之后，播出人员可能会忽略所有报警。这是不可取的。

　　《ATSC推荐实践：TS流验证》（ATSC Recommended Practice: Transport Stream Verification）参考了ATSC、ISO/IEC 13818、ETSI的多个标准，经过实践，形成了一套更符合实际播出运营的科学验证体系。它将TS流错误（注意：仅仅是TS层）分为不同的类型，并根据错误引起的后果分成5种严重程度。

　　• 1级：TS停播：（Transport Stream Off Air，TOA）

　　TS错误严重到足以损坏TS层逻辑结构导致停播，接收端无法解调或解码任何节目。

　　• 2级：节目停播：（Program Off Air，POA）

　　TS中某一路服务（频道）故障，以致没有任何问题的接收端不能播出。

　　• 3级：组件缺失：（Component Missing，CM）

　　找不到PMT或PMT无法解码。组件是指视频或音频流。

　　• 4级：服务质量：（Quality Of Service，QOS）

　　参数超出标准规格很大，以至于相当一部分接收端播放有缺陷。大部分情况可以播放，但播放有体验问题。

　　• 5级：技术上不符合：（Technically Non-Conformant，TNC）

　　违反标准但对实际观看体验影响不大。这种错误也应该被纠正，但不是那么迫切。

　　可以看出，这些严重性分类仍然按照TS的逻辑架构来区分。我们国内的TS流或DVB并不要求遵循ATSC标准（ATSC有更多的表元素），但其实践得出的通用指标临界值值得借鉴。这些错误严重程度分级也根据国际标准值，比如按国际指标标准值的2倍、2倍-5倍、5倍以上。

　　11.2.1.  PSI错误

　　PSI包括PAT和PMT两个表（其重要性参见3.1.1.3和3.1.1.5），其语法在ISO/IEC 13818-1中定义。ATSC标准要求PAT最大间隔为100ms、PMT最大间隔为400ms（DVB和MPEG标准中两者最大间隔都是500ms）。这些间隔稍微超出标准值都不会对接收器产生什么重大影响。

　　1) PAT错误条件

　　2) PMT错误条件

　　11.2.2.  PCR、PTS和Buffer错误

　　时序（PCR、DTS、PTS）是MPEG-2 TS编码和解码的关键（参见3.2、3.3）。接收端时钟需与编码器端时钟设备同步，因此PCR 27MHz时钟时间戳要以足够频繁的速率在流中发送。

　　很多情况可能导致解码器时钟与编码器时钟不同步：

　　• TS中插入不正确的PCR

　　• PCR插入的频率不够

　　• 传输过程带来的抖动（数据包抵达时间早或晚，解码端时钟漂移，可能导致Buffer上溢或下溢）

　　一些传输（比如调制）可能需要填充空包（Null Packets）以维护TS的恒定码率，一些设备会将空包视为投机数据包并将其替换为私有数据包。这个过程不应影响正常的接收端。然而，在调制之前物理性丢弃空包，或者用两个私有数据包替换一个空数据包，将对PCR时序产生负面影响，也可能影响到调制器。因此，无论何时数据包随时间平移时，重复用器必须非常小心准确地重新标记所有的PCR、PTS和DTS值。

　　解码过程中也需要参考时钟指示数据何时在缓冲区之间移动数据、何时解码以及何时显示，这是DTS和PTS的任务。如果解码器时钟与编码器端不同步，它可能会提供不正确的时序从而影响解码，后果可能导致Buffer上溢或下溢，带来停帧或跳帧，甚至带来视音频同步问题。

　　Buffer、PTS和DTS错误也可能由PCR错误以外的编码器或复用器引起，它们也会导致一些缺失或解码元素同步的时序问题。

　　注意，现实中的解码器可能具有比标准要求的最小缓冲更大的缓冲区，因此能够容忍一定的时序错误和Buffer溢出问题。标准只是提供了一个永远不会上溢也不会下溢的理论模型的最小RAM值，因此一些超过标准要求内存的接收端可以良好运行，而另一些就可能有问题。比如，采用符合标准最小内存数的型号可能就有问题，而具备超过最小内存要求50%的型号运行就很良好，这相当于实际编码器的T-STD不是上溢就是下溢。满足缓冲标准的解码器确实可以解码，但它不能保证节目质量。

　　1) PCR错误条件

　　注意：ATSC推荐实践PCR阈值不同于TR101290（见3.1.2.4和3.1.2.5）阈值，个人认为在实际播出监测环境更有参考意义；对于产品选型的独立测试，个人认为仍应按TR101290建议。

　　2) PTS错误条件

　　3) Buffer错误条件

　　首先，Buffer上溢或下溢可能会导致播放卡顿甚至失真（比如“花屏”、音画同步问题），但有些缓存能力很强的接收端可能并不会出现此问题；其次，Buffer测量是T-STD模型理论值，它根据编码流的设置推断缓冲所需的最低RAM值，注意其结果并不能保证所有解码器完美表现，这意味着即使监测系统没有Buffer告警也有可能实际导致某些机顶盒出现上溢或下溢问题；第三，实践发现市场上有些机顶盒的标称RAM规格并不准确。这些情况增加了实际播出链路中界定播出问题的难度，但是，确保设备没有Buffer监测问题仍然很有必要，它保证了编码器自身没有编码问题。

　　以下ATSC推荐实践也只能参考不同Buffer错误带来的严重程度。

　　11.2.3.  综合性错误

　　ATSC推荐实践还列出一些与传输相关的综合性错误，可用于日常播出链路监测参考。

　　ATSC建议：对于5级问题，应将单个告警事件视为小问题，除非周期性地再次发生，否则不需要担心。如果重复出现，则应该引起注意，因为这可能表明设备即将完全失效。对于4级问题，它可能会有一些影响节目的短暂静帧/跳帧（比如Buffer引起）或花屏（比如丢包引起）问题。

　　11.3. 如何在播出链路中正确使用监测系统

　　很多人对监测系统的使用是错误的，他们了解监测指标的含义，却没有深入研究这些指标对播出链路影响的实际关系。例如，在一个实际播出链路环境中，值班人员希望监测系统能够准确告知播出链路中发生的故障以确保安全播出，但监测系统频繁的告警误报却让他们非常失望，这不是他们想要的。

　　问题的原因是综合性的。但从根本上讲，您可能缺乏一套真正切实可行的安播监控综合标准，或者您已有的监控标准设定不够明确、不适合当前的安播要求，以致无法达到您希望有效监控的目的。

　　因此，您首先要做的是：

　　11.3.1.  建立适合自己、切实可行的安播监控综合标准

　　参考前面我们的理论，这个标准不应只包括黑场、静帧、静音、花屏等这些主观QoE指标，也应包含所有与安全播出相关的综合QoS和QoE指标。通过理论学习，您已经很清楚实时监测这些指标对您的安全播出和节目质量是多么重要，是时候拿出纸和笔，按照技术原理，参照您播出节目的特点和要求，列出您需要的指标项。

　　例如（仅举例说明，实际标准应更详细）：

　　建立安全播出监测标准指标应遵循以下原则：

　　1) 按QoS和QoE分类的树状结构

　　一个可按图索骥的树状结构有助于在问题发生时，工程师明确知道问题发生在哪一层、哪一类，快速定位问题发生的原因，为问题的解决提供思路；

　　2) 建立适合自己的标准

　　我们希望监控系统能对安播和节目质量问题精确告警，因此您不能生搬硬套行业标准规定值，它也许和您的安播诉求并不契合，您需要参考行业经验并结合自己的实践建立适合自己的标准。值得注意的是，每个电视台或运营商的播出链路系统设备都有所区别，兄弟单位发生问题的指标阈值也许在自己的系统并不会产生问题，不同的播出部门应该建立自己的标准——适合自己的播出运营标准；

　　3) 建立标准是一项理论+实践的系统工程

　　实践是检验真理的标准！设定的标准是否合理，您必须要通过实践进行验证并不断调整，直到最后定型。

　　11.3.1.  在监测系统中设定监测流程

　　有了上面的标准，您需要在监测系统中按标准设定流程，当发现错误时配置监控系统应采取的举措。

　　专业的监测系统都有配置流程的功能，除具备全面的指标监测能力外，他们允许您自定义指标阈值、判断错误的严重程度以及配置错误发生时的举措。以Orion为例，它可以将客户制订的标准配置成监测模板，在模板中设置监测指标并自定义违反阈值，并根据超出阈值的程度设定不同的严重程度并采取不同的告警举措。

　　下图是Orion中TS层、TS解码子类中的PTS相关指标错误发生时的告警流程设置过程。

在Orion中配置安全播出监测模板

　　Orion可让用户根据违反标准阈值的程度将错误分成以下错误等级：

　　红色：Outage（致命）

　　紫色：Critical（严重）

　　黄色：Major（主要）

　　棕色：Minor（次要）

　　绿色：No Error（无错）

　　用户还可配置不同错误发生时，监测系统可采取的举措：

　　• 发送邮件通知

　　• 触发SNMP告警

　　• 触发自定义告警

　　• 触发声音告警

　　• 录制视频流

　　有了错误严重性的提示，值班人员才能明确哪些错误需要立即解决、哪些错误需要保持关注、哪些错误可以暂时忽略，参考我们在11.2 ATSC推荐实践中对5种不同严重程度错误所需要做的应对那样。

　　同时我们也提到，实际监测中这些告警如果不是你想要的那种，您就需要对自己建立的标准和对监控模板指标进行调整，使其适合自己的运营标准。

　　下图是在Orion中配置断流指标的另一个例子。假设您的播出系统中，当信源中断时，中断5秒是一个可接受范围、中断10秒您需要让系统显示视觉告警、中断15秒就必须启动声音警报并发送告警信息到您的主控系统。

根据错误的严重程度，建立适合自己的运营标准

　　11.3.2.  监测状态和结果分析

　　观察监测状态、分析监测结果是实践学习的好方法，他能将您学到的理论知识真正转变成能力。专业分析仪或监测系统都有实时显示监控状态和实时错误告警的能力，包括实时可视化图形曲线、错误可视化、元数据显示和错误报告详情。实时观察关键数据的临界变化的同时对比观看解码后的画面和声音，对建立和优化自己的播出标准指标很有帮助。

　　播出值班人员需要时刻关注安全播出问题的实时监测状态和错误告警，而分析告警结果并分析监测运营趋势是播出运维工程师的主要职责。随着广电总局越来越严格的安播监管要求，播出出现关键问题就意味着播出事故，播出部门反而希望监测系统永远不要报警。从这个意义上讲，实时错误告警只是监测系统的基本要求，而如何快速定位问题、从而解决问题和避免问题才是重点。

　　下面的例子是一个响度指标的实时告警分析。响度问题不影响安全播出，但却影响用户体验，或许您可设定其严重程度为“次要错误”，值班人员见到此类问题无须采取诸如主备切换的紧急措施；而运维工程师则需要点开错误报告，判断发生响度问题的链路设备节点，观察发生的时间点、持续时长、发生频率、超标程度等，以决定是否在未来的优化和改造中优先处理。

实时告警分析：响度错误

　　另一个因画面异常（花屏）导致监测系统告警的例子则要稍微复杂些，如下图。假设值班人员看到监测系统告警“画面异常”，需要运维人员分析具体原因。

“画面异常”告警结果分析

　　从我们前面学到的理论，发生这种问题的可能性有多种，比如QoS层的网络抖动导致的TS流丢包、或者信源本身就有这种问题。此时，您需要查看告警报告，如果只有QoE层（解码后的特殊计算）错误、没有QoS层（数据没有问题），则可以判断信源画面本身问题；如果发现QoS和QoE层都有错误告警，则说明错误的根本原因是因QoS数据错误（连续计数错误——包缺失）引起。

　　专业监测系统还可长期保留监测数据以便进行趋势分析。通过长时间粒度的监测数据，您可以观察并统计分析频繁发生的共性问题，寻找规律以便找出解决办法：比如，人为问题——加强培训、设备问题——优先改造、设置问题——合理优化等。

　　11.3.3.  端到端链路部署监测

　　播出系统是包含很多设备的复杂系统，设备之间有上下游的链路关系。上游发生的错误，很可能向下延续，造成下游一连串设备都有输出错误。因此，在每个关键链路部署监控探针，形成一套整体端到端链路监测方案很有必要。它能帮您迅速定位故障发生的流程节点和设备位置，通过分析其错误指标，从而为解决问题快速找到依据。

　　下图是一个端到端监测系统快速定位故障点、故障设备和故障原因的例子。

端到端链路监控系统：快速定位故障点和故障原因

　　如上图，一套整体端到端链路监控系统在每个关键节点都部署了监控探针，下游客户端观看时听到声音抖噪问题（不连续的说话声音）。此时，观察监控系统界面，发现错误源自编码器；通过监测报告，发现编码器输出音频信号中有真峰值错误——它是下游抖噪问题产生的根本原因。因此，运维工程师可通过调整编码器的响度控制参数快速解决此问题。

　　一个常见电视台播出部门的链路如下，要实现端到端监控，可在信源（CCTV新闻联播）、播出服务器、编码器、复用器等关键节点部署监控探针。

电视台端到端监控部署

　　11.3.4.  合规性、一致性、兼容性监测

　　专业的分析仪或监测系统通常都面向多种应用，监测目的不同，监测指标标准也应不同。因此，播出部门对监测的设置不应只是播出安全告警一种标准模板。比如，针对设备的选型测试，仍应采用行业标准指标组成的严格监测模板，确保设备有良好的兼容性、合规性和一致性。

　　兼容性、合规性和一致性指标之间的区别说明如下。

　　兼容性（Compatibility）

　　兼容性是指设备之间的互通性。它可能不是一种行业标准错误，比如在播出中一个VBR（可变码率）编码的TS流，不影响大多数设备的连接或播出问题，但会影响接收端少量性能较差的机顶盒解码。它也有可能是一种行业标准错误，比如一般的PCR_OJ错误会影响专业录制设备，却不影响机顶盒解码播放。这两种情况都是兼容性问题。

　　合规性（Compliance）

　　合规性是指各项法律法规或监管性要求。比如广电总局规定了播出中必须使用的格式、分辨率、色度格式、声轨数和通道数、响度标准等。

　　一致性（Conformance）

　　一致性标准是最重要的指标项。一致性是指行业标准如MPEG、DVB、IPTV等技术标准规范，比如我们前面提到的很多QoS指标，播出系统中因为一旦违反，就可能带来解码问题。比如MPEG定义每个TS数据包包头中必须有PAT和PMT表，一旦丢失，任何节目都不能解码。有些一致性问题可能不会影响解码、但会导致兼容性问题，比如TR101290 3级中的EIT表，它不影响解码，但会影响需要EIT信息的系统兼容性。

　　12. 监测的本质——预测式运维

　　大多数电视台和运营商（有线、IPTV、OTT、社交媒体等）希望监测系统能够在播出发生问题时准确报告错误，以便应对越来越严格的监管要求，这是他们对监测系统真正的诉求吗？对于实时直播，错误一旦发生——特别是严重错误，就可能意味着被监管部门定义为播出事故，从而面临追责或整改，这肯定不是使用方想要的。

　　从本质上来说，监测的目的是为了节目不间断、高质量地分发以确保用户的优质视听体验，实现良好的社会效益或经济效益——这也是监管政策的目的之一。因此，仅仅对播出问题实时告警并不是使用方的核心目的。特别在广电行业经营困难的今天，确保观看体验、增加用户粘性是获取收益的重要手段。里德·哈斯廷斯（Netflix创始人）将公司的成功归功于极致的用户体验。

　　如何更好地发挥监测系统的作用？全球顶尖电视台和运营商的专家们已经给出了答案，那就是更加关注预测式运维，以便在问题影响观看体验之前预测问题，提前采取有效措施。要做到这一点，不仅需要覆盖所有关键链路节点的综合端到端监测系统，也需要具备合格技术和分析能力的专业性人才，能够随时了解内容在线上的每个流程都发生了什么。如果监测系统还能够帮助使用方实现某些方面的自动化，比如播出系统中发生的问题的端到端之间关系的可视化，事情会变得更加容易。

　　融媒体时代为内容方提供了更多的分发平台，监测更是流媒体时代视频技术的主要支柱，因为电视台和内容方面对的是无法直接控制的公网分发。他们只能进行测量，然后做出相应的反应，既要在传输过程中尽可能地保证质量，又要决策旨在改善长期体验的措施。我们将在另一篇文章中，讨论公网/互联网或OTT分发播出链路的监测技术指标。

　　参考文献：

　　《ETSI TR 101 290 TECHNICAL REPORT: Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems》

　　《Buffer Analysis: MPEG-2 TS Analysis & Monitoring - R&S》

　　《ATSC Recommended Practice: Transport Stream Verification》

　　《Orion User Guide - Interra Systems》