视频服务质量(QOS)教程

下载选项

  • PDF     (489.8 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (205.3 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (212.8 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2017 年 9 月 18 日
文档 ID:212134

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

    简介

    本文档回顾视频呼叫质量主题，并提供有关在思科统一边界要素(CUBE)或时分复用(TDM)网关上配置服务质量(QoS)时要牢记的事项的教程。

    作者：Baktha Muralidharan，思科TAC工程师，Anoop Kumar编辑。

    先决条件

    要求

    本文档对熟悉IP语音(VoIP)的工程师最有益，但其他人可能认为它很有用。

    使用的组件

    本文档没有特定的硬件或软件。

    背景信息

    最简单形式的数字化音频是一组音频样本，每个样本都描述这段时间的声压。  会话音频可以高精度地捕获和再现，每秒仅8000个样本[1]。  这意味着只要网络能够传输样本而不产生过多的延迟、抖动和丢包，音频就可以在另一端被忠实地再现。

    相比之下，视频的呈现、处理和传输要复杂得多。亮度、对比度、色彩饱和度、响应（运动）和唇音同步只是决定视频质量的一些属性。视频样本通常需要更大的空间。毫不奇怪，视频对网络带宽的需求在传输网络中会大得多。音频质量由：头戴式耳机的麦克风扬声器编解码器 — 压缩传输网络视频呼叫质量受以下因素影响：摄像头显示设备视频编解码器传输网络兼容性/互操作性

    注意：  与音频不同，在调谐质量方面，视频终端上会发生相当多的变化。

    目标

    QoS通常是一个庞大而复杂的主题，需要考虑整体流量需求（而不仅仅是您希望提高质量的流量），并且需要检查媒体流路径中每个网络组件上的流量。在视频会议中实现视频质量更加复杂，因为它除了涉及网络组件外，还涉及对终端的配置和调整进行审核和检查。总的来说，视频质量意味着：

    • 终端调整 — 优化终端配置（例如分辨率、每秒帧数）
    • 传输优化 — 优化网络以根据网络SLA传输视频流量。
    • 互操作性注意事项 — 视频呼叫通常涉及不同功能的终端。设计和配置系统以最大限度地提高互操作性会影响视频质量。

    本文档中的具体重点是处理视频呼叫时IOS网关或CUBE上的QoS注意事项。

    在端点进行调整涉及调整视频端点上的一组参数。这当然取决于产品，但以下是一些一般的“旋钮”：

    • 分辨率（即图片大小）
    • 帧率（即运动敏感度/现实度）
    • 标记（即ToS标记）

    调整视频网络通常涉及以下内容：

    • 了解流经CUBE的流量的组成 — 例如峰值[呼叫]卷等。
    • 检查网络链路/管道容量
    • 设计适当的QoS策略，确保满足每个流量类的SLA

    当异类(视频电话和网真(TP))系统参与会议呼叫时，互操作性就会发挥作用。TP和视频电话系统提供的体验有着根本的不同。它们之间的互操作性通常通过使用称为级联的过程来桥接它们。

    这不包括什么

    这既不是设计文档，也不是全面的视频QoS文档。具体而言，本文档不涵盖以下主题：

    • 视频呼叫的信令[协议]，超出说明QoS相关方面所需的信令。
    • 视频终端设置/配置
    • 全面回顾QoS机制，包括策略、队列、整形和突发
    • 复习第2层交换机上的QoS配置或信任边界注意事项。

    视频的网络流量特征

    视频，如音频是实时的。 音频传输是恒定比特率(CBR)。 而视频流量往往是突发的，即可变比特率(VBR)。因此，如果需要保持一定的质量，视频传输的比特率就不一定[2]。

    图1

    确定视频所需的带宽和突发量也更为重要。本文档稍后将讨论此问题。

    • 视频流量突发。
    • 视频数据包可能非常大。
    • 音频始终为CBR。视频通常是VBR。 

    为什么视频会爆发？

    答案在于视频的压缩方式。请记住，视频是播放的一系列图像（帧），以提供视觉运动效果。视频编解码器使用的压缩技术使用一种称为增量编码[3]的方法，该方法通过将字节值存储为顺序（样本）值之间的差（增量），而不是值本身。因此，视频被编码（和传输）为仅携带“移动部分”而非整帧的连续帧。

    您可能会想为什么，音频也会逐步更改？没错，但“动作”（或动态）对音频的影响远不及对视频的影响。当Delta编码时，8位音频采样（帧）压缩效果不佳。从采样(帧到帧)到采样的相对变化是视频比音频小得多。视频样本的大小可能因运动的性质和程度而有很大差异。图2显示了视频压缩 —

    图2

    I帧是内编码图像，实际上是完全指定的图像，就像常规静态图像文件。

    P帧(预测图片)仅保存来自前一帧的图像中的变化。该编码器不需要将不改变的背景像素存储在P帧中，从而节省空间。P帧也称为delta帧。

    B帧(双预测图像)通过使用当前帧与前帧和后帧之间的差异来指定其内容，从而节省了更多空间。

    视频质量测量

    思科视频设备不会因此测量或报告视频质量，因此视频质量是感知而非测量。有标准化的算法通过MOS（平均意见分数）来衡量质量。 但是，如果音频质量报告的问题是任何指示，则视频质量(TAC)案例更可能被打开，因为用户感觉到质量问题，而不是通过工具报告。

    终端控制

    影响视频质量的因素包括：

    • 视频编解码器（MPEG4、H261、H263、H264和H265）
    • 大小（第1/8屏幕、第1/4屏幕、全屏）
    • 帧速率（每秒1到30帧，默认6帧）
    • 压缩质量设置（低、中、高）

    通常，上述每个在终端上都是可选/可控的。

    可见对象

    Quilting、Scoming & Banding已经习惯了这些术语，这是视频减损分类法的一部分。有关常见视频损坏的详细信息，请参阅本文档：

    参考： 

    http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitulos/VirtualDub-1.6.14/help/p-artifacts.html

      

    传输网络SLA以实现视频质量

    建议的视频网络SLA[4]如下：

    • 延迟≤ 150-300ms
    • 抖动≤ 10毫秒 — 50毫秒
    • 损耗≤ 0.5%

    顺便提一下，用于传输音频的推荐网络SLA是：

    • 延迟≤ 150-300ms
    • 抖动≤ 20毫秒 — 50毫秒
    • 损失≤ 1%

    注意：  显然，视频比语音对丢包更敏感。  一旦您了解帧间需要来自前一帧的信息，即表示帧间丢失对重建视频图像的过程可能具有毁灭性的影响，就应该会出现这种情况。

    传输网络中的控制

    通常，视频传输的SLA可以使用与音频传输使用的QoS策略进行交付。但是，由于视频流量的性质，也存在一些差异。

      

    注意：  尽管本文档的范围仅限于CUBE组件，但请记住QoS是端到端的。

    视频变体

    视频都一样吗？不是。视频作为介质的变体包括：

    • 视频电话/视频会议
      • 实时交互
      • 带宽相对较低。最高约1Mbps
    • 网真
      • 实时交互
      • 沉浸式体验
      • 需要非常高的带宽
    • 流
      • 实时、单向
      • 可以是单播或组播
      • 高带宽
      • 延迟不敏感（视频可能需要几秒钟才能排队）
      • 对抖动基本不敏感（因为应用缓冲）
      • 损失不应超过5%。
      • 延迟不应超过4到5秒（取决于视频应用的缓冲功能）
      • 某些视频（例如娱乐）可能会被视为Scavenger服务。

    注意：  为简洁起见，没有为上面列出的每种类型的视频提供大量图解。

    视频流量编解码器

      • H.261-Codec最初设计用于通过ISDN线路传输。使用视频绑定后，视频比特率是64 Kbit/s的倍数。
      • H.263 — 编解码器用于基于IP的视频会议和ISDN网络。H.263需要一半的带宽才能达到与H.261相同的视频质量。因此，H.263已经大大取代了H.261。H.263已针对大范围的比特率而优化，而不像H.261那样只有64K位/秒。
      • H.264/MPEG-4 - Cs目前是最常用的格式之一，使用的比特率为MPEG-2、H.263或MPEG-4第2部分的一半或更低。
      • H265 — 广泛使用的H.264的几个潜在后继路由器之一，基于相同概念的扩展。它支持高达8192×4320的分辨率，包括8K UHD。

    注意：  视频（如音频）在实时协议(RTP)中传输

    视频的QoS机制

    原则上，用于为视频传输网络提供SLA的QoS机制与音频机制基本相同。但是，存在一些差异，主要是由于视频的突发性和VBR传输。

    QoS的实现方法有集成服务(intserv)和区分服务(diffserv)两种。

    将Intserv视为在信令级别运行，而将Diffserv视为在媒体级别运行。换句话说，inserv模型通过在控制平面操作来保证质量；diffserv旨在通过在日期平面级别操作来确保质量。

    在IntServ架构中，网络设备发出静态带宽预留请求，并在对这些流执行分类、标记和排队服务的同时，维护所有预留流的状态；IntServ架构操作并集成控制平面和数据平面，因此由于固有的扩展限制，已基本放弃。用于预留带宽的协议是RSVP（资源激活协议）。

    还有IntServ/DiffServ模型，这是一种混合。此模型将控制平面操作与数据平面操作分开。RSVP操作仅限于准入控制；DiffServ机制处理分类、标记、策略和调度操作。因此，IntServ/DiffServ模型具有高度可扩展性和灵活性。

    注意：  本文档仅重点介绍diffserv（即优先级划分方案，LLQ）方法。

    带宽保证

    带宽显然是最基本的qos参数。 这取决于几个参数，最显着的是：

    • 使用的编解码器
    • 帧速率
    • 图像大小
    • 呼叫量（峰值和平均值）

    将带宽用于问题的老把戏并不总是解决问题。视频质量尤其如此。例如，使用CUVA(Cisco Unified Video Advantage)时，涉及的两台设备（电话和PC）之间没有同步机制。因此，应配置QoS，使抖动、延迟、分片数据包和无序数据包最小化。

    注意：  交互式视频与VoIP的服务级别要求相同，因为语音呼叫嵌入在视频流中。流视频由于内置在应用程序中的缓冲量大，要求要宽松得多。

    最后，必须了解的是，与VoIP不同，没有计算所需增量带宽的干净公式。这是因为视频数据包大小和数据包速率差异很大，并且在很大程度上是传输的视频图像中运动程度的函数。稍后再谈。

    队列

    低延迟队列(LLQ)是VoIP音频的首选队列策略。鉴于TP对延迟/抖动敏感的严格要求以及CUVA对音频和视频同步的需要，建议对所有视频流量也使用优先级(LLQ)排队。请注意，对于视频，优先级带宽通常会扩展20%以计算开销。



    报头压缩

    不建议用于视频。

    链路分段和交织

    LFI是一种常用机制，可确保缓慢链路上的抖动不会失控，在慢速链路上，串行化延迟可能很高。

    但是，对于慢速链路，建议不要使用交互式视频。这是因为视频流量分配到的LLQ不会分段。这意味着大型交互式视频数据包（例如1500字节全动I帧）可能导致小型交互式视频数据包的序列化延迟。

    拥塞避免

    基于RTCP的选择性丢弃

    突发

    此QoS机制对于视频流量非常重要，如前所述，视频流量是突发性的。

    可将可选突发参数配置为priority 命令[6]的一部分。

    使用H.264时，最坏的突发是全屏（空间压缩）视频。根据对TP系统的广泛测试，发现此值为64 KB。因此，应将LLQ突发参数配置为允许每帧每屏幕最多64 KB的突发。因此，以1080p-Best(辅助视频流[7]的可选支持)运行的CTS-1000系统将配置LLQ，其最佳突发参数为128(2x64)KB。

    多少带宽？

    那么，忠实传输视频呼叫需要多少带宽？在开始计算之前，了解视频独有的以下概念非常重要。

    分辨率

    这基本上是指图像的大小。  其他常用术语包括视频格式和屏幕大小。  常用视频格式如下所示。

    格式

    视频分辨率（像素）

    SQCIF

    128x96

    QCIF

    176x144

    SCIF

    256x192

    SIF

    352x240

    CIF

    352x288

    DCIF

    528x384

    4CIF

    		  

    704x576

    16CIF

    1408x1152

    绝大多数视频会议设备都采用CIF或4CIF格式运行。

    参考：http://en.wikipedia.org/wiki/Common_Intermediate_Format

    注意：  在音频世界中，（视频）分辨率没有等同性

    帧速率

    这是指成像设备生成唯一连续图像的速率，称为帧。帧速率以每秒帧数(fps)表示。

    注意：  音频世界中的等效度量是采样时间。例如，8000用于g.711ulaw。

    带宽计算

    视频电话系统和其他传统视频会议系统的带宽计算往往更简单。

    例如，假设TP呼叫的分辨率为1080 x1920。  所需带宽的计算方式如下：

         每帧2,073,600像素

            每像素x3色

            每色x1字节（8位）

            每秒x 30帧

            =每屏1.5 Gbps。未压缩！

    使用压缩时，每屏4Mbps的带宽（压缩率> 99%）足以传输上述帧！

    下表列出了

    图片
    格式

    亮度
    像素

    亮度
    行

    未压缩
    比特率(Mbit/s)

    10帧/秒

    30帧/秒

    灰色

    颜色

    灰色

    颜色

    SQCIF

    128

    96

    1.0

    1.5

    3.0

    4.4

    QCIF

    176

    144

    2.0

    3.0

    6.1

    9.1

    CIF

    352

    288

    8.1

    12.2

    24.3

    36.5

    4CIF

    704

    576

    32.4

    48.7

    97.3

    146.0

    16CIF

    1408

    1152

    129.8

    194.6

    389.3

    583.9

    请注意，以上计算是针对单屏幕进行的。TP呼叫可能涉及多个屏幕，因此呼叫的总带宽将是每个屏幕带宽的倍数。

    有关Cisco TP系统的良好带宽计算器，请参阅https://supportforums.cisco.com/thread/311604。

    对视频流量进行分类/标记

    如何识别/区分视频流量？在CUBE上对数据包进行分类的一种方法是使用DSCP标记。

    下表说明了每个Cisco QoS基线和RFC 4594的DSCP标记。

    Traffic

    第3层PHB

    第 3 层 DSCP

    呼叫信令

    CS3

    24

    语音

    EF

    46

    视频会议

    AF41

    34

    网真

    CS4

    32

    多媒体流

    AF31

    26

    广播视频

    CS5

    40

    PHB — 每跳行为。指路由器对数据包分类和流量调节功能（如计量、标记、整形和策略管制）的作用。

    默认情况下，在9.0版CUCM(Cisco Unified Call Manager)之前，CUCM将任何和所有视频流量（包括网真）标记为AF41。从9.0版开始，CUCM预配置以下DSCP值：

    • 网真（沉浸式视频）呼叫(在CS4和
    • AF41上的视频（IP视频电话）呼叫

    配置

    配置以调整音频质量需要计算优先级带宽并在WAN链路上实施LLQ策略。这通常基于预期呼叫量和使用的音频编解码器。

    虽然原理相同，但通过CUBE的视频带宽不太容易计算。这是由多种因素造成的，包括：

    • 如何计算给定不同TP呼叫（流经CUBE）所需的总带宽可能涉及不同数量的屏幕和不同分辨率？
    • 突发性与VBR
    • [带宽计算]中复杂性的另一个方面与“互操作性呼叫”有关？  互操作性呼叫使用TIP。TIP代表网真互操作性协议。TIP用于将多个屏幕、多个音频流以及辅助数据屏幕多路复用为两个RTP流，每个流用于视频和音频。它支持点对点和多点会话，以及多屏幕和单屏幕终端的混合。TIP是思科专有协议。TIP基于RTCP。

    因此，视频系统的带宽调配有时会以相反的顺序进行，即传输网络可以通过LLQ策略提供的带宽量首先确定，然后基于此配置终端。终端视频系统足够智能，可以根据管道大小调整各种视频参数！因此，终端发出呼叫信号。

    CUBE带宽处理

    那么，CUBE如何处理其(SIP)提供/应答中的带宽（在发出视频呼叫信令时）？CUBE按如下方式填充SDP中的视频带宽字段：

      1.从传入SDP中的带宽属性。在SDP中，存在带宽属性，该属性具有用于指定值引用的比特率类型的修饰符。  该属性具有以下形式：b=<modifier>:<value>

      2.从CUBE上配置的视频带宽。例如，估计的最大带宽是根据CTS用户使用的功能计算的，估计的带宽是使用CLI在CUBE上预配置的

    • <bandwidth video tias-modifier>或
    • <bandwidth video as-modifier>

      3.默认视频带宽(384 Kbps)

    下面显示的呼叫流程说明CUBE如何在呼叫信令消息中填充带宽 —

    具体而言，CUBE使用以下逻辑：

    • 在优惠（用于DO呼叫）中，CUBE使用已配置的带宽。
    • 在（EO的答案）上，CUBE发送带宽，其值为提供和本地配置的最小值。

    在SDP会话级别，TIAS值是使用所有声明的媒体流时所需的最大带宽量[8]。

    视频编解码器负载类型

    这是视频与音频不同的另一个区域。 音频编解码器使用静态负载类型。相反，视频编解码器使用动态RTP负载类型，这些类型使用范围96到127。

    使用动态负载类型的原因与视频编解码器的广泛适用性有关。视频编解码器具有为接收方提供要发送的流属性的参数。视频负载类型在SDP中使用a=rtpmap参数定义。此外，“a=fmtp：”属性可用于指定格式参数。fmtp字符串不透明，仅传递到另一端。

    以下是-

    m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

    请注意，呼叫中涉及的两个终端可能对同一编解码器使用不同的负载类型。CUBE以在另一条支路上收到的a=rtpmap线路对每一端做出响应。这意味着视频呼叫需要配置“非对称负载已满”才能正常工作。

    L2带宽

    与语音不同，实时IP视频流量通常是比特率流，有些突发。因此，与语音不同，视频没有明确的网络开销计算公式，因为视频数据包的大小和速率会随着视频图像本身内的运动程度按比例变化。从网络管理员的角度来看，带宽始终在第2层调配，但数据包大小和数据包从端到端传输的第2层介质的多样性使得计算应在第2层调配的实际带宽非常困难。然而，经过全面测试和广泛使用的保守规则是过度调配视频带宽20%。这可满足10%的突发量和从第2层到第4层的网络开销。

    监控/测量

    如前所述，视频终端不报告MOS。但是，以下工具可用于测量/监控传输网络性能和监控视频质量。

    IP SLA视频

    IOS、IP SLA（服务级别协议）中嵌入的功能可主动监控网络性能。IP SLA视频操作与其他IP SLA操作的不同之处在于，所有流量都只是单向的，响应方需要在本地处理序列号和时间戳，并等待来自源的请求，然后再发回计算的数据。

    当当前视频操作完成时，源设备向响应方发送请求。此请求向响应方发出信号，表示不会再有数据包到达，并且视频操作中的视频接收功能可以关闭。当响应方的响应到达源时，从消息中读取统计信息，并更新操作中的相关字段。

    CiscoWorks IPM（IOS性能监控器）使用IP SLA探测功能和MediaTrace[9]来测量用户流量性能和报告。

    CUBE VQM

    CUBE上提供的VQM（视频质量监控器）功能是监控两个关注点之间视频质量的绝佳工具。结果以MOS表示。

    这可从IOS 15.2(1)T及更高版本获得。请注意，VQM使用DSP资源。

    参考


    [1]基于约4000Hz的最高音频人声频率。参考：奈奎斯特定理。

    [2]可以通过视频实现恒定比特率(CBR)传输方案，但它们会牺牲质量来维护CBR。

    [3]用于帧间压缩

    [4]注意SLA对TP更加严格。

    [5]真实大小的图像和高质量音频

    [6]此参数的默认值是优先级带宽下的200毫秒流量。Cisco LLQ算法已实施，以包括相当于200毫秒流量的默认突发参数。测试表明，此突发参数不需要对单个IP视频会议(IP/VC)流进行额外调整。对于多个流，此突发参数可能会根据需要增加。

    [7]辅助视频流是5 fps视频通道，用于在数据投影仪上共享演示或其他辅助内容。

    [8]请注意，某些系统使用“AS”（特定应用）修饰符来传输最大带宽。  此属性的解释取决于应用的最大带宽概念。

    CUBE与特定带宽限定符（TIAS或AS）无关。

    [9] Mediatrace是一种IOS软件功能，可发现沿IP流路径的路由器和交换机。

     StartSelection:0000000199 EndSelection:0000000538

    TAC Authored

    由思科工程师提供

    • Baktha Muralidharan
      Cisco TAC Engineer
    • Edited by Anoop Kumar
      Cisco TAC Engineer

    此文档是否有帮助?

    Feedback反馈

    联系我们