影片服務品質(QOS)教程

下載選項

  • PDF     (527.7 KB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (205.5 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (213.5 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)。 相比之下，影片流量容易突發，稱為可變位元率(variable-bit-rate，VBR)，因此影片傳輸的位元率不一定為常數，如果我們要保持一定的品質[2]。

    圖1

    確定影片所需的頻寬和突發也更加重要。本檔案稍後將對此進行討論。

    • 影片流量激增。
    • 視訊資料包可能很大。
    • 音訊始終為CBR。影片通常為VBR。 

    為什麼影片突發？

    答案在於影片的壓縮方式。請記住，影片是一系列播放的影象（幀），用於提供視覺運動效果。影片編解碼器使用的壓縮技術使用稱為增量編碼[3]的方法，該方法通過將位元組的值儲存為連續（取樣）值之間的差（增量）而不是值本身。因此，影片被編碼（和傳送）為僅攜帶「運動部分」而不是整個幀的連續幀。

    您可能會想為什麼，音訊也逐漸改變？這話說得沒錯，但「運動」（或動態）對音訊的影響並不像對影片的影響那麼大。當delta編碼、影片樣本(幀)編碼時，8位音訊樣本的壓縮效果並不更好。從樣本(幀到幀)到樣本影片的相對變化比音訊要小得多。根據運動的性質和程度，影片樣本的大小可能會有很大差異。圖2說明影片壓縮 —

    圖2

    I幀是幀內編碼影象，實際上是一個完全指定的影象，就像傳統的靜態影象檔案。

    P幀(預測影象)僅保留影象中的前一幀的變化。編碼器不需要在P幀中儲存不變的背景畫素，從而節省了空間。P幀也稱為delta幀。

    B幀（雙預測影象）通過使用當前幀與前幀和後幀之間的差異來指定其內容，從而節省了更多的空間。

    影片品質測量

    Cisco video gear本身不測量或報告影片品質，因此影片品質是感知的，而不是測量的。有標準化的演算法通過MOS（平均意見得分）來衡量品質。 但是，如果所報告的音訊品質問題可以說明任何問題，則更有可能開啟影片品質(TAC)案例，因為使用者察覺到了品質問題，而不是工具的報告。

    端點控制元件

    影響影片品質的因素包括：

    • 影片編解碼器（MPEG4、H261、H263、H264和H265）
    • 大小（第1/8螢幕、第1/4螢幕、全屏）
    • 幀速率（每秒1到30幀，預設6幀）
    • 壓縮品質設定（低、中、高）

    通常，上述每個在端點是可選擇/可控制的。

    可見工件

    絎縫、梳理和條帶適用這些術語，這是影片損傷分類的一部分。有關常見視訊損害的詳細資訊，請參閱以下檔案：

    參考： 

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

      

    用於影片品質的傳輸網路SLA

    影片[4]的建議網絡SLA如下：

    • 延遲≤ 150-300ms
    • 抖動≤ 10 ms-50 ms
    • 虧≤為0.5%

    順便提一下，建議用於傳輸音訊的網路SLA為：

    • 延遲≤ 150-300ms
    • 抖動≤ 20 ms-50 ms
    • 損失≤ 1%

    附註：  顯然，影片對資料包丟失比語音更為敏感。  一旦您瞭解幀間需要來自先前幀的資訊，就應該預料到這種情況，這意味著幀間的丟失對重建影片影象的過程可能是災難性的。

    傳輸網路中的控制

    通常，影片傳輸的SLA可以使用與音訊傳輸非常類似的QoS策略來提供。但是，由於影片流量的性質，存在一些差異。

      

    附註：  雖然本文檔的範圍限製為CUBE元件，但請記住QoS是端到端的。

    影片種類

    影片都一樣嗎？也不盡然。影片作為媒介的變化包括：

    • 視訊電話/視訊會議
      • 即時互動
      • 頻寬相對較低。最高約1 Mbps
    • TelePresence
      • 即時互動
      • 沈浸式體驗
      • 需要很高的頻寬
    • 串流
      • 即時、單向
      • 可以是單播或組播
      • 高頻寬
      • 非延遲敏感（影片可能需要幾秒鐘才能排隊）
      • 對抖動基本上不敏感（因為應用緩衝）
      • 損失不應超過5%。
      • 延遲不應超過4到5秒（取決於影片應用的緩衝功能）
      • 某些影片（例如娛樂）可能考慮用於Scavenger服務。

    附註：  為簡潔起見，上面列出的每種型別的影片都不提供插圖。

    影片流量編解碼器

      • H.261編解碼器最初設計用於通過ISDN線路傳輸。使用影片繫結時，影片位元率是64 Kbit/s的倍數。
      • H.263 — 編解碼器用於基於IP的視訊會議以及ISDN網絡。H.263需要一半的頻寬才能達到與H.261相同的影片品質。因此，H.263在很大程度上取代了H.261。H.263已針對大範圍的位元率進行了最佳化，而非64K bits/s（如H.261）。
      • H.264/MPEG-4 - Cs是目前最常用的格式之一，使用的位元率小於或等於MPEG-2、H.263或MPEG-4第2部分。
      • H265 -廣泛使用的H.264的幾個潛在繼承者之一，基於相同概念的擴展。支援高達8192,4320的×辨率，包括8K UHD。

    附註：  影片與音訊一樣，以即時協定(RTP)傳輸

    適用於視訊的QoS機制

    原則上，用於為影片傳輸網路提供SLA的QoS機制大部分與音訊的SLA相同。但有一些差異，主要由於影片和VBR傳輸的突發性。

    實現QoS的方法主要有整合服務(intserv)和差異服務(diffserv)。

    將Intserv視為在信令級別運行，而在媒體級別運行diffserv。換句話說，Intserv模型通過在控制平面上操作來確保品質；diffserv旨在通過在日期平面級別運行來確保品質。

    在IntServ架構中，網路裝置在執行這些流的分類、標籤和排隊服務時，對靜態頻寬預留請求並保持所有預留流的狀態；intServ體系結構運行並整合了控制平面和資料平面，由於固有的擴展限制，因此基本上被放棄。用於進行頻寬預留的協定是RSVP(Resource reSerVation Protocol)。

    還有IntServ/DiffServ模型，它是一種混合模型。該模型將控制平面操作和資料平面操作分開。RSVP操作僅限於准入控制；使用DiffServ機制處理分類、標籤、策略和排程操作。因此，IntServ/DiffServ模型具有高可擴充性和靈活性。

    附註：  本文僅重點介紹diffserv（viz-a-viz優先順序方案，LLQ）方法。

    頻寬保證

    頻寬顯然是最基本的qos引數。 這取決於幾個引數，最明顯的是：

    • 使用的編解碼器
    • 幀速率
    • 影象大小
    • 呼叫量（峰值和平均值）

    為解決問題投入頻寬的舊伎倆並不總是解決辦法。影片品質尤其如此。例如，使用CUVA(Cisco Unified Video Advantage)時，所涉及的兩個裝置（電話和PC）之間沒有同步機制。因此，QoS應配置為最小化抖動、延遲、分段資料包和亂序資料包。

    附註：  互動式影片的服務級別要求與VoIP相同，因為語音呼叫被嵌入影片流中。流式影片的要求要寬鬆得多，因為應用程式內建了大量的緩衝區。

    最後，重要的是要瞭解，與VoIP不同，沒有用於計算所需增量頻寬的簡單公式。這是因為視訊資料包大小和資料包速率有很大差異，並且很大程度上取決於傳輸影片影象中的運動程度。稍後將對此進行詳細說明。

    佇列

    低延遲隊列(LLQ)是VoIP音訊的首選隊列策略。鑑於TP對延遲/抖動有嚴格的要求，並且需要對CUVA同步音訊和影片，建議對所有影片流量使用優先順序(LLQ)隊列。請注意，對於影片，優先順序頻寬通常被提高20%以彌補開銷。



    標頭壓縮

    不建議影片使用。

    連結分割和交錯

    LFI是一種常用的機制，可確保慢速鏈路上的抖動不會失控，因為慢速鏈路的序列化延遲可能很高。

    但是，對於慢速連結，同樣不建議使用Interactive-Video。這是因為影片流量分配到的LLQ不受分段影響。這表示大型互動式視訊資料包（如1500位元組全運動I幀）可能導致較小的互動式視訊資料包的序列化延遲。

    擁塞規避

    基於RTCP的選擇性丟棄

    突發

    此QoS機制對於影片流量非常重要，如前所述，影片流量是突發的。

    可選突發引數可配置為priority命令[6]的一部分。

    使用H.264時，最壞的情況是全屏（空間壓縮）影片。根據對TP系統的大量測試，發現其大小為64 KB。因此，LLQ突發引數應配置為允許每個螢幕每幀高達64 KB的突發量。因此，運行在1080p-Best的CTS-1000系統(可選擇支援輔助影片流[7])將配置一個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。

    頻寬計算

    影片電話系統和其他傳統視訊會議系統的頻寬計算趨於簡單。

    例如，考慮解析度為1080 x 1920的TP呼叫。  所需的頻寬計算如下 —

         每幀2,073,600畫素

            每畫素x3顏色

            每色x1位元組（8位）

            x 30幀/秒

            每螢幕1.5Gbps。解壓縮！

    使用壓縮時，每個螢幕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。

    分類/標籤影片流量

    如何識別/區分影片流量？使用DSCP標籤對CUBE上的資料包進行分類的一種方法。

    下表說明了每個Cisco QoS基線以及RFC 4594的DSCP標籤。

    流量

    第3層PHB

    第3層DSCP

    通話訊號

    CS3

    24

    語音

    EF

    46

    視訊會議

    AF41

    34

    TelePresence

    CS4

    32

    多媒體串流

    AF31

    26

    廣播影片

    CS5

    40

    PHB — 每跳行為。指路由器在封包分類和流量調節功能方面執行的作用，例如計量、標籤、整形和管制。

    預設情況下，9.0版之前的CUCM(Cisco Unified Call Manager)會將所有影片流量（包括網真）標籤為AF41。從9.0版開始，CUCM預配置以下DSCP值：

    • CS4和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使用以下邏輯：

    • 在優惠（待辦事項呼叫）中，CUBE使用配置的頻寬。
    • 在（EOs的響應）上，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%。這可以容納從第2層到第4層的10%突發和網路開銷。

    監測/測量

    如前所述，先前影片終端不會報告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]此引數的預設值為優先順序頻寬下的200ms流量。Cisco LLQ演算法已實施為包括相當於200毫秒流量的預設突發引數。測試表明，此突發引數不需要對單個IP視訊會議(IP/VC)流進行額外的調整。對於多個流，可以根據需要增加該突發引數。

    [7]輔助影片流是5fps的影片通道，用於共用資料投影儀中的簡報或其他附屬小瓶。

    [8]請註意，某些系統使用「AS」（特定於應用程式）修飾符來傳遞最大頻寬。  對此屬性的解釋取決於應用程式的最大頻寬概念。

    CUBE與特定頻寬修飾符（TIAS或AS）無關。

    [9] Mediatrace是IOS軟體的一項功能，用於發現IP流路徑中的路由器和交換機。

     StartSelection:0000000199選：0000000538

    TAC Authored

    由思科工程師貢獻

    • Baktha Muralidharan
      Cisco TAC工程師
    • Edited by Anoop Kumar
      Cisco TAC工程師

    這份文件是否有所幫助？

    Feedback意見

    讓思科協助您