播出运维:IP链路中的安全播出和节目质量监测(一)
李宏泉| 流媒体网| 2024-03-25
【流媒体网】摘要:对于播出工程师每天都要面对的IP链路、TS流,我们不能让它挡住我们的脚步,必须要去了解它、掌握它!

  相关阅读:

  播出运维:IP链路中的安全播出和节目质量监测(二)

  播出运维:IP链路中的安全播出和节目质量监测(三)

  播出运维:IP链路中的安全播出和节目质量监测(四)

  前言

  无论是传统的卫星、发射、有线电视还是称为新媒体的IPTV/OTT,广义的播出应包含从信源处理一直到观众观看的整个复杂链路。系统越复杂,对播出工程师的培训和学习的要求就越高。大多数播出人员不会过多考虑他们下游方的信号情况,更多精力放在自身系统的播出保障上,但实际下游方的播出品质与上游提供的信号质量密切相关。这就是为什么作为信源方的电视台,他们自己的输出看上去没什么问题、却会经常受到来自有线、发射或电信网络方的抱怨?发生播出“灾难”时,对于整个播出链路,观众会认为“任何一片雪花都不是无辜的”,这时候厘清责任也很重要。

  无论您通过IP还是ASI接口传输,TS(MPEG-2 TS)流几乎是数字电视和IPTV前后端链路中唯一的信号,学习并掌握TS流知识始终是播出工程师绕不开的课题。虽然大多数电视台都配备了流分析仪甚至播出监测系统,但是,有多少工程师真正了解它呢?

  TS流的确很复杂,因为它涉及了大量的编解码基础知识,看上去令人生畏,但并非不可掌握。理论结合实践是我们解决问题的法宝!首先,碰到问题不要躲,从业者每天都要面对它,躲是躲不过去的;其次,不要指望你一下子就掌握它,学习TS是一个持久战,给自己制订一个循序渐进计划;第三,学习没有捷径却有方法,掌握一个东西须从其原理入手,万变不离其宗;最后,实践非常重要,它能让你将学到的知识真正转化为能力。

  1. QoS和QoE

  我们先从两个基本概念开始:QoS(Quality of Service,服务质量)和QoE(Quality of Experience,体验质量)。QoS和QoE是国际上针对播出要求最常用的两类指标,中国人更习惯性地称为“安全播出”和“节目质量”,这两种叫法的关注点一致,但在衡量方法上却大相径庭,基础出发点完全不同。我们很多播出人员更相信自己的眼睛和耳朵,却往往忽略引起播出安全和节目质量问题的本质原因。

  1.1.  QoE是流解码后的主观感知

  通常,大部分电视台会对播出安全提出一些指标要求,比如:不能有黑场、彩条、静音、花屏、响度问题等,并对这些指标设定一些安全播出的阈值,这些指标都是QoE的范畴。类似的这些我们眼睛看到、耳朵听到的指标都已经不是TS流本身、而是TS解码之后的表象;因此,和眼睛和耳朵一样,监控设备需要先解码,然后通过各种算法判断表象问题,比如黑场是通过计算像素亮度值和持续时间来判断、静音是计算音量和持续时间来判断等等。很明显,这些指标只关注了表象,因而在问题发生时并不能知道问题到底因为什么而出,不利于问题的解决;甚至,表象有时会欺骗我们的眼睛和耳朵,因为同样的错误在不同链路中的表象有可能是不一样的,下图的OTT播出链路是一个很好的例子。

上游信号中断时,不同链路的表象可能不同

  如图所示,当上游信号中断时,这种因上游信号中断引起的播出问题在不同链路中的表象是不同的:失去信源的编码器输出画面是漆黑一片且没有声音(黑场+静音),在流服务器端看到的表象则是静帧和静音,观众端看到的却是一个转圈的视频缓冲。因此,在一个复杂链路中,只看表象,我们是无法知道问题到底出在哪里。

  1.2.  QoS是数据层面的客观度量

  我们知道,流是以数据形式存在的,播出/分发的本质是确保将数据安全无误地送到目的地、并确保用户能正确解码/播放。这是我们往往会忽略的QoS部分。如上所述,QoE是人主观视觉和听觉的感知,它需要对流先进行解码以判断画面和声音是否正常,它也很重要——但却无法帮助我们找到问题的根源。而QoS关注的是流的数据层面,它关注的是我们的流是否能够正确传输和解码,它从流的技术原理出发、通过科学的度量指标关注影响流正常传输和解码的问题;QoS不需要解码,它需要对数据进行解析。当问题发生时,QoS指标要比我们眼睛看到和耳朵听到的QoE指标更加关键,它对问题的定位、溯源、解决都至关重要。下图是TS流QoS和QoE指标的一个简单分类。

TS流的QoS和QoE指标分类

  无论是QoS还是QoE,按照TS的技术原理将其按树状结构分类是一个好主意,它能让您在问题发生时知道问题出在哪个层面、从而从其技术角度知道该如何解决。从上图我们看到,QoE比较简单,眼睛看到的就是视频层、听到的是音频层;QoS分类则稍显复杂,它包括IP(网络)层、TS层、视频层、音频层、数据(字幕)层等,往下又延伸出很多的指标分类。人们往往对自己不了解的事物充满怀疑和否定,QoS在现实中让我们一些工程师驻足不前,抱怨专业的流分析仪或监控系统太复杂、不好用,殊不知它正是TS的数据结构——不是因为仪器或系统复杂——而是TS的技术原理本该如此。

  对于播出工程师每天都要面对的IP链路、TS流,我们不能让它挡住我们的脚步,必须要去了解它、掌握它!

  2. TS流的编码和解码

  了解IP流要从其基本原理入手,从根本到细节;就像我们看一棵大树一样,先了解树干,再到大树枝、小树枝,最后才是树叶这些细节。您不能还没弄明白TS和PES的情况下就去尝试了解PCR、在没了解PAT和PMT的情况下去研究TR101290,那会把你的脑子搞得一团糟。

  2.1.  TS流的编码

  从我们熟悉的SDI信号开始,下图是一个编码器从SDI输入、TS流输出的编码过程。SDI包含的视频(YUV)和音频(PCM)部分在编码器中会分开编码成视频流(Video ES)和音频流(Audio ES);但ES是连续流,不利于传输,因此在编码器内部会切割成利于传输的数据包,分别形成视频PES和音频PES;最后,视频和音频PES打包成适应通信网络播出的TS流——它是一串固定长度为188字节的数据包。

TS流的编码过程

  现在,相信您已经掌握以下术语了:

  • ES:Elementary Stream(基本流)

  • PES:Packetized Elementary Stream(打包的基本流)

  • TS:Transport Stream(传输流)

  所以,我们可以将TS流分为三层:TS层、PES层、ES层。ES层就是音视频数据,PES层是在音视频数据上加了时间戳等对数据帧的说明信息,TS层是在PES层上加入了数据流识别和传输的必要信息。显然,要想获得可高质量传输的TS流,播出前端必须对音视频信号进行正确、高质的编码。但是,PES和TS附加信息的正确性对接收方能正确接收并解码还原也至关重要。

  注意:TS流可以包含单个节目(单节目流,SPTS),也可以包含多个节目(多节目流,MPTS)。

  • SPTS:Single Program Transport Stream(单节目流)

  • MPTS:Multiple Program Transport Stream(多节目流)

  播出部门和下游网络所作的一切努力都是为了流的正常传输以便确保观众能正确播放,因此,我们有必要了解TS流的解码过程。

  2.2.  TS流的解码

  TS数据包在打包过程中加入了一些必要信息,这些信息正是为传输和解码/播放准备的用于识别和业务的各种数据,它们保存在每个188字节的TS数据包的前4个字节,称为TS数据包包头(TS Packet Header)。其余的184字节是Payload(有效数据,我们真正需要的视音频PES数据)。

  当播放器(比如电视机顶盒)接收到TS流后,它会先访问每个数据包的包头,找到PID为0的信息字段——PAT表(节目关联表);通过节目关联表,再找到里边包含的节目单——PMT表(节目映射表);节目映射表关联着视频和音频PES流,解码器将它们还原成视频和音频信号后,观众才能在电视机上看到画面、听到声音。下图是一个多节目流(MPTS)的结构,播放端通过TS包头识别到PAT和PMT,PMT链接对应的视音频PES数据。

一个多节目TS流的解码结构:PAT和PMT

  现在,我们又掌握了以下术语:

  • PID:Packet Identifier(包标识符)

  • PAT:Program Association Table(节目关联表)

  • PMT:Program Map Table(节目映射表)

  不要被这些术语吓倒,我们可以用一个形象的例子说明。假设某电视台大楼里有1000人分布在10层楼的100个房间里,您现在要去电视台大楼办事,您怎么找到要找的人呢?幸运的是,电视台不仅有组织结构,而且每个房间都标有房号。通过这些信息,您可以很容易地找到位于8楼8001房间、播出部技术科设备组的张小丽。那么这些房号、姓名等标签都可以看成是PID,PAT、PMT、PES则相当于层级组织结构。

  现在我们可以展开想象,如果PID、PAT、PMT丢失或者错误了会怎么样?还拿刚才的例子,电视大楼100个房间都没了房间号、播出部被错误标成制作部——您就无法找到要找的人。同理, PAT、PMT丢失或错误的TS流是无法被进一步解码的。曾经有某电视台复用器中PAT表丢失造成了断播问题,这时如果有专业的监测告警设备,您马上可以知道问题在哪、如何解决。

  除了PAT和PMT,TS包头中还有一些非常关键的信息,如果丢失、错误、延迟等,都会给观众的播放带来问题。不要着急,让我们一步步探讨这些信息。

  3. TS层QoS指标

  3.1.  TR101290检测

  《TR101290技术报告——DVB(数字电视)系统测量指南》是几乎所有传输或MPEG流分析仪的基础,其目的是在运营中对TS进行连续或定期监控。TR101290被设计用于检测TS的完整性,对流中最重要的元素进行检查。不同的流分析仪显示的信息可能有所不同,也可能提供更多检测功能,但基于TR101290的分析原理都是一样的。

  这些测试被归纳为一系列不同参数的监测和测量,要么是错误发生的频率、要么是时间上的变化等等。TR101290对不同参数的临界值做出了定义,如果违反,监测系统就发出告警并报告错误。根据TS错误对下游带来影响的严重程度,TR101290将错误分为3个等级,建议作为检测的一级优先、二级优先和三级优先。我们刚才提到的PAT和PMT错误,它会导致断流而引起停播事故,因此被划分在一级优先中。

  3.1.1.  一级优先

  第一优先级的错误基本上是那些会让你停播的错误,它是正确解码所需要的必需项,因此建议7x24小时连续监测。

  TR101290一级优先包括以下错误检测:

  3.1.1.1.  TS sync loss(TS同步缺失

  TS同步丢失是最严重的错误。TS流失去同步,标志着传输过程中会有部分数据丢失,接收端可能出现的现象是影响解码甚至无法解码。

  连续检测到5个正常的同步字节视为TS码流同步,连续检测到2个或以上不正确的同步则认为同步字丢失。

  3.1.1.2.  Sync byte error同步字节错误

  同步字节存在但不正确,这也相当于没有同步。因此,此检测要验证同步字节的值必须是0x47。如果同步字节不正确,接收端也影响解码甚至无法解码。

  3.1.1.3.  PAT errorPAT错误

  节目关联表(PAT)只出现在PID 0x0000包中,它告诉解码器TS中有哪些节目,并指向节目映射表(PMT), PMT又指向组成节目的视频、音频和数据流。

  如果PAT缺失,解码器什么也做不了,任何节目都不能解码。

  PID 0x0000中除了PAT外,不应该包含其他任何东西。

  它检测:

  • PID 0x0000没有至少每隔0.5秒出现一次;

  • PID 0x0000不包含table_id 0x00(即PAT);

  • PID 0x0000的Scrambling_control_field(加密控制字段)不是00。

  3.1.1.4.  Continuity count error连续计数错误

  它检测:

  • 错误的包序;

  • 数据包出现两次以上;

  • 丢包。

  TS包头中有4个bit的连续性计数器(continuity counter),该计数器会随着具有相同PID的TS包数量的增加而增加,该计数器的最大值是15,当到达15后从0再次开始新的计数。

  这是一项联合3项检测的一个指标值,很多人认为连续计数错误就意味着丢包是片面的。发生连续计数错误时,因为数据包携带着视音频数据,这些数据是组成画面和声音的元素,它的缺失或不正确会影响这些元素的呈现。

  3.1.1.5.  PMT errorPMT错误

  它检测:

  • table_id 0x02段数据(即PMT),没有至少每隔0.5秒出现在PAT引用的PID上;

  • 所有包含table_id 0x02(即PMT)的PID包的Scrambling_control_field(加密控制字段)不是00。

  PMT是节目映射表,它指明了组成每路业务(service,我们习惯叫频道)的音频流、视频流的位置(PID),以及每路业务的节目参考时钟(PCR)的位置(PCR包的PID)。

  节目关联表(Program Association Table, PAT)告诉解码器流中有多少节目,并指向包含可以找到任何给定事件组件位置的信息的PMT(节目映射表)。这里的组件是指视频流(通常是一个,也可以多个频道的复用流)、音频流和数据流(例如Teletext)。

  没有PMT,相应的节目是不能解码的。

  3.1.1.6.  PID errorPID错误

  它检查是否每个PID都有数据流,如果相关PID在指定时间内未找到,就会报告此错误。此错误可能发生在TS多路复用、或解复用并再复用时。

  用户对视频或音频PID的指定监测时间不应超过5s。ISO 639 [i.17]中,大于'0'类型的语言描述符的数据服务和音频服务应该被排除在这个5秒限制之外。

  注:对于带有ISO 639 [i.17]中大于'0'类型的语言描述符的其他信息如字幕(Subtitle)、数据服务的PID,则相同PID的两个连续数据包之间的时间可能会明显变长。

  PID错误会导致该PID的解码问题,比如对应的视频PID或音频PID。

  3.1.2.  二级优先

  第二级优先错误是那些可能影响单个频道解码和视音频质量的错误,这种错误造成的影响程度要比一级低但也很关键,它不会造成停播但是也会引起重大播出事故,比如引起咱们熟悉的静帧、声画不同步等现象。因此也建议7x24小时监控或定期监测。

  TR101290二级优先包括以下错误检测:

  3.1.2.1.  Transport error传输错误

  如果解调器不能纠正流中的错误,则在TS头中设置此标志。它监测TS头中的Transport_error_indicator(传输错误指示器)值是否为“1”,表示此数据包错误。

  3.1.2.2.  CRC error(CRC错误)

  对CAT、PAT、PMT、NIT、EIT、BAT、SDT、TOT进行CRC(Cyclic Redundancy Check,循环冗余校验)检查,检查对应表的内容是否损坏。CRC错误表明这些表中有数据损坏。

  3.1.2.3.  PCR error(PCR错误)

  PCR(Program Clock Reference,节目时钟参考)是编码器或复用器嵌在TS流中的信息,用于接收端重新生成本地27MHz系统时钟。如果PCR没有在一定规律性时间内到达,那么该时钟可能会抖动或漂移,接收器/解码器可能失去锁定。

  在DVB中,重复时间不允许超过100ms(以前建议最多40ms)。

  它检测以下PCR问题,如果不符,则称为PCR错误:

  • PCR不连续超过100ms(无特定指示时)

  • 两个连续PCR值之间的时间间隔大于100ms

  3.1.2.4.  PCR Accuracy ErrorPCR精度错误)

  所选节目的PCR准确度不在±500ns以内,称为PCR精度错误。

  注:该测试仅适用于MPEG-2 TS CBR规格

  3.1.2.5.  PTS error(PTS错误)

  PTS(Presentation Time Stamps,显示时间戳)包含在TS流中,帮助解码器以正确的速度和同步按时播放节目。PTS和PCR有先后关系,因此会和PCR进行比较。

  PTS重复周期超过700ms(不适用于静帧),称为PTS错误。

  3.1.2.6.  CAT error(CAT错误)

  CAT(Conditional Access Table,条件访问表)用于对节目进行加密/加扰,比如非付费用户不能观看加密的节目。

  它做以下检测,如果不符,则称为CAT错误:

  • 带有transport_scrambling_control(传输加密控制)的数据段不是00,但却没有table_id = 0x01(即CAT)的数据包;

  • 在PID 0x0001上发现table_id非0x01值(即不是CAT)的数据段。

  3.1.3.  三级优先

  TR101290三级优先检测主要和应用服务有关,比如网络信息表(Network Information Table,NIT)、Buffer上溢/下溢等。除了Buffer的上溢和下溢会响应播放质量外(我们后续讨论),其他三级错误不会对播放有太大影响。

  有兴趣的读者可索阅晶蓝科技的《ETSI TR 101 290指标测量和监控》一文。

  3.1.4.  TR101290 3个优先级的测量本质

  TR101290 3个优先级主要关注TS数据包中的包头信息,检测其是否符合MPEG-2 TS和DVB标准。这些指标是下游设备对TS流接收或解码的检索信息,通过前面的原理分析,我们可以想象到这些指标错误将对下游带来哪些影响。更重要的是,这些指标的分类让我们在问题发生时可以对问题进行定位,以便知道该如何解决。

  通过下图,您可以将它的3个优先级条目和对应包头数据对应起来。

  TS包头语法信息与TR101290检测的对应关系:1、2级优先指标

  TS包头结构信息与TR101290检测的对应关系:1级中的PAT和PMT

  3.1.5.  PSI和SI

  PSI和SI都是TS流中的表(Table),这些表包含着流的各种业务信息。PSI由MPEG-2 TS标准定义,包括PAT、PMT、CAT和NIT 4个表,包含了我们前面讲到的最重要的PAT和PMT;SI由DVB标准定义,包括BAT、SDT、EIT、RST、TDT、TOT、ST等9个表。下面是各种表的定义:

  PSIMPEG-2 Program Specific Information(MPEG-2节目具体信息)

  • PAT:Program Association Table(节目关联表)

  • PMT:Program Map Table(节目映射表)

  • CAT:Conditional Access Table(条件接收表)

  • NIT:Network Information Table(网络信息表)

  SI:Service Information(服务信息)

  • BAT:Bouquet Association Table(信束关联表)

  • SDT:Service Description Table(服务描述表)

  • EIT:Event Information Table(事件信息表)

  • RST:Running Status Table(运行状态表)

  • TDT:Time and Date Table(时间日期表)

  • TOT:Time Offset Table(时间偏移表)

  • ST:Stuffing Table(填充表)

  3.2.  PCR(节目时钟参考)

  视频信号被编码成TS数据包时,会从其27MHz时钟生成计数器,在TS包中插入PCR(Program Clock References,节目时钟参考),其作用是让电视接收端的输出视频与该视频信号相锁定。复用器必须确保插入到TS中的PCR值反映其在TS中的最终时间位置,使观看视频的时序和速度与信号源一致。

PCR在编码器/复用器中的生成

  在接收端,PCR被从TS中恢复,并将其计数器值与本地生成的27MHz时钟驱动的类似计数器进行比较。接收到的计数器值和本地生成的计数器值之间的任何差异都可以用来驱动一个相位锁定环路(Phase Locked Loop,PLL)以控制本地时钟。显然,时钟之间的差异程度会对本地生成的时钟造成或大或小的变化,实际的变化由播放端锁相环的特性决定。锁相环可以跟踪低频的少量变化,但或许不能跟踪高频端的变化。

  接收端本地生成的27MHz时钟将被用来再生成其输出端的视频,该时钟频率的任何变化都有可能作为视频的同等时间损伤而转移到输出端视频上。虽然一些设备如用户的电视可能接受这些损伤,但其他设备如专业录机可能就不能接受这些损伤,因为它会导致系统失锁,严重时导致节目质量损失——时钟过慢造成缓存中没有数据导致停帧、时钟过快造成缓存中数据溢出导致跳帧。

  评估PCR损伤需要对PCR进行有效测量。

  3.2.1.  系统时钟和PCR测量的参考模型

  这是一个包含编码器和传输网络的模型,虚线A和B之间是编码器/复用器,虚线B和C之间是传输网络。

  标准的系统时钟频率是27MHz,但实际频率会有一个fdev(p,t)函数的偏差,此函数随时间(t)变化并且只对应单个PCR PID (p)。PCR_FO(PCR Frequency Offset,PCR频率偏移)测量的是fdev(p,t) 的值,而PCR_DR(PCR Drift Rate,PCR漂移率)测量的是fdev(p,t)随时间变化的比率。

  Np,i是系统时钟驱动PCR计数器产生的PCR计数的一个理想值,这里的(p)对应特定PCR PID,(i)指的是TS中的bit位置。假设有一个PCR不精确源产生了Mp,i的偏差,实际TS流中PCR值为Pp,i,那么:

  Pp,i=Np,i+Mp,i

  这里的Mp,i就是PCR_AC(PCR Accuracy,PCR精度)问题所在。

  B点之后的物理传输机制或通信网络带来D+Ji的延迟,假设bit的出发时间为Ti,到达时间为Ui,那么:

  Ui-Ti=D+Ji

  在PCR中,Ui是包含PCR字段的最后1个Byte的最后1个bit到达的时间;D是一个常数,表示通过通信网络的平均延迟;Ji表示网络延迟中的抖动,其在所有时间中的平均值为0。那么,我们所说的PCR_OJ(PCR Overall Jitter,PCR整体抖动)就是Ji+Mp,i之和。

  在TS流通常是恒定码率(CBR)的情况下,在B点TS以恒定码率Rnom发出。如果码率精准不变,不会因码率变化而产生错误,那么数据包出发时间为:

  T0是1个常数,表示第0个bit离开的时间。由此可得出:

  3.2.2.  PCR的测量

  测量PCR时需要采用一个界定频率,用于界定PCR和/或TS时间变化的漂移率和抖动频率范围。所用界定频道必须从以下表中选择,并与测量结果一起注明。

  表:PCR抖动和漂移率测量采用的模式

  3.2.2.1.  PCR_FO(PCR Frequency Offset,PCR频率偏移)

  3.2.2.2.  PCR_DR(PCR Drift Rate,PCR漂移率)

  3.2.2.3.  PCR_OJ(PCR Overall JitterPCR_OJ

  3.2.2.4.  PCR_ACPCR Accuracy,PCR精度

  3.3.  DTS(解码时间戳)和PTS(显示时间戳)

  前端编码过程中,ES在PES层打包的时候,在包的头部插入了DTS(Decoding Time Stamp,解码时间戳)和PTS(Presentation Time Stamp,显示时间戳)两个标签,他们为系统目标解码器分别指定了ES流的预期解码时间和显示时间。

  解码端捕获PCR,恢复出本地的STC(System Time Clock,系统时序时钟),将其作为音视频同步控制的基准,并依据PTS和DTS时间标签来安排解码和显示时间表,使音视频分别同步于STC,以实现音视频之间的同步。因此,PCR、DTS、PTS是有先后顺序的。

  我们知道,为了在同等带宽下实现高质量画质,视频图像压缩时有三种帧:

  • I帧(Intra picture Frame,本帧):可独立解码,不依赖于其他帧

  • B帧(Bi-directional interpolated prediction Frame,双向预测帧):不能独立解码,依赖前后的I帧和P帧

  • P帧(Predictive Frame,前向预测帧):不能独立解码,依赖前面的I帧或P帧

  PTS和DTS两种时间戳是因为B帧的存在,I帧和P帧的PTS等于DTS。如果一个视频没有B帧,则PTS和DTS相同。

  下图视频流中只有I帧和P帧,因此解码顺序和显示顺序一样。

只有I帧和P帧的流的解码和显示顺序

  解码器接收流后,接收的帧顺序和解码顺序相同。但如果有B帧,解码顺序(DTS)和显示顺序(PTS)则有很大区别。下图中,因为B帧的存在,解码顺序和显示顺序有很大不同。

包含B帧的流的解码和显示顺序

  音频PES中只有PTS(同DTS),视频的I、P帧两种时间戳都要有,视频B帧只要PTS(同DTS)。

  3.4.  Buffer(缓存)上溢和下溢

  解码器端(比如机顶盒)通常在本地有一些物理缓存(RAM),用于暂时容纳接收的数据并发送给解码器来解码,以避免传输影响带来的数据过快或过慢造成的播放问题。但是,如果到来的数据量过大超出缓存能力(Buffer上溢),解码器就会舍弃一些数据,画面可能会跳帧;相反,如果到来的数据过少(欠流或Buffer下溢),不足以满足播放所需,解码器就会等待数据,画面可能就会静帧。

Buffer原理示意

  有一些情况会导致Buffer上溢和下溢,比如PCR严重抖动导致时钟失锁,但TS系统目标解码器(transport stream system target Decoder,T-STD)测量并非为实际解码器端设计。

  想象一个固定码率传输且包含多个节目(多个频道)的TS流,每个节目由多个基本流组成,如视频、音频、数据(字幕),ES中的比特率通常随时间变化如视频ES中的I、B、P帧,与B和P帧相比,I帧的尺寸很大。如果TS的码率足够大,在任何给定时间内保持一个峰值;这时如果另一个ES的峰值碰巧同时出现,则TS将无法允许解码器同时正确解码两组内容的方式来保存和发送数据。因此,将多个服务(频道)整合到一个固定有限码率的TS中(复用器)是一个挑战,编码器和复用器必须创建能够在播放过程中无任何问题地解复用和解码的数据流。任务是确定ES的数据与其他ES相比如何延迟,以使音频同步解码过程在每种情况下都能成功。

  ISO/IEC 13818-1提供了TS系统目标解码器(transport stream system target Decoder,T-STD)。虽然解码器端需要真正的缓冲区,以便正确地呈现传输数据包的内容,但T-STD并不打算作为真正解码器的参考设计。T-STD目的是有助于确保多路复用器或编码器正常工作,确保通过这个“理论”解码器的传输流可以被任何真正的解码器所解码,T-STD的缓冲模型体现的是数据的及时传递和受控传递。

  每个服务(频道)都必须使用自己的目标解码器进行解码。如下图所示,每个ES(如音频和视频服务)引入单个解码器路径。此外,PAT和PMT等系统信息(SI)也有特定的解码路径。

  模型中的组件如下:

  • TB:Transport Stream Buffer(TS流缓冲)

  • B:Main Buffer(主缓冲)

  • EB:Elementary Stream Buffer(ES流缓冲)

  • MB:Multiplex Buffer(复用缓冲)

T-STD模型

  如上图所示,每个解码器路径都包含TS流缓冲(TB),它将解码器与TS传输码率分开,以便解码可变码率的TS。视频ES必须经过复用缓冲(MB)和ES缓冲(EB),音频和系统数据被直接分离到主缓冲区(B)。缓冲区之间的传输速率、缓冲区大小和解码时间通过流中的信息计算或通过其中的PTS(显示时间戳)可得。访问单元(Access Unit,AU)被定义为视频或音频帧的编码表示,在解码时从输出缓冲区中移除。每个访问单元(例如视频)的大小取决于场景复杂性和特定视频帧的类型。

  验证Buffer与编码格式和所采用的设置有关。对MPEG-2视频,除了根据MPEG-2采用的设置外,还可以通过编码中的VBV(Video Buffer Verifier,视频缓冲验证器)信息验证;对H.264,可以通过编码中的HRD(Hypothetical Reference Decoder,假设参考解码器)和CPB(Coded Picture Buffer,编码图像缓冲区)信息验证。音频和系统信息TB(TS缓冲)则以固定速率传输到主缓冲区(B),只有有效负载(音频数据)被写入B。

  3.5.  MPEG-2 TS层解析

  如果TS有解析问题,会导致节目解码问题。因此以下指标需要监测解析问题。

  3.6.  码率检测

  有些传输需要严格的码率控制,比如需要调制的有线、地面和卫星数字电视,可能需要检测码率合规性。需要验证的指标包括:

  • Duplicate packet for PID(PID重复数据包):传输流中的任何PID都不应该有重复数据包。

  • Transport Bitrate (Actual)(传输码率(实际))

  • Transport Bitrate (Muxed)(传输码率(复用))

  • Transport Bitrate Difference (Actual vs Muxed)(传输码率差异(实际和复用))

  • PES Bitrate(PES码率)

  • PID Bitrate(PID码率)

  • Service Bitrate(频道码率)

  • NULL Packets(空包率)

  3.7.  流中断和异常验证

  包括接收不到数据错误(不可用)和关键信息改变引起的异常。监测系统应设定规定阈值,如果错误超过阈值,则应报告错误。

  • 信源不可用错误(Feed unavailability error):接收不到数据

  • 频道不可用错误(Service unavailability error):接收某个服务/频道的数据

  • PES不可用错误(PES unavailability error):未收到TS包(No TS Packet received)错误和未收到PES头(No PES Header received)

  • 信源监控停顿由于异常(Feed monitoring stalled due to anomalies):PAT和TSID改变超过设定时间阈值

  • 频道监控停顿由于异常(Service monitoring stalled due to anomalies):PMT改变超过设定时间阈值

  • PES监控停顿由于异常(PES monitoring stalled due to anomalies):编码格式改变、加密改变或丢包超过设定的时间

  • PAT改变(PAT Change):信源的TSID改变或信源中的频道被添加、删除或调整时,PAT就会改变

  • PMT改变(PMT Change):在频道中添加、删除或修改节目时,PMT会发生变化

  • PMT中的PCR PID改变(PCR PID changed in PMT)

  • 编码格式改变(Codec change)

 

责任编辑:李楠

分享到:
版权声明:凡注明来源“流媒体网”的文章,版权均属流媒体网所有,转载需注明出处。非本站出处的文章为转载,观点供业内参考,不代表本站观点。文中图片均来源于网络收集整理,仅供学习交流,版权归原作者所有。如涉及侵权,请及时联系我们删除!