【H.264/AVC標準剖析(一)】
從撥接上網到光纖到府(FTTH)，隨著網路多媒體的發展，網路頻寬的變化頗為巨大，因而使得媒體壓縮技術也不斷推陳出新，並帶動多媒體應用服務多元化及整體產業的蓬勃。
網路頻寬/壓縮策略決定多媒體服務品質
在網路多媒體應用中，最引人注意的即為廣播應用、媒體傳統服務、多媒體儲存與互動以及即時串流服務(Real-time Streaming Services)等。這些網路多媒體應用帶來的服務類別，涵蓋了數位電視、視訊會議、影像電話、遠距教學與影像儲存裝置等。然而要讓用戶享受高品質的數位多媒體影音服務，必須考量諸多因素，其中最重要的莫過於網路存取頻寬與有效的壓縮策略。
任何基於網際網路通訊協定(IP)為架構的多媒體通訊系統的目的，是提供用戶在合理成本下的最高品質享受。不過，要測量用戶端因為壓縮技術與封包交換傳送，所造成的視聽感官服務品質(Audiovisual Service Quality)客觀失真範圍，並不是一件容易的事。
因為所謂的服務品質，除涉及太多無法加以模型化討論的外在因素外，還包含專業知識、人種、文化、服務內容種類、測量項目認知，以及使用者期待心理的差異等，讓公平公正的客觀評述定義頗有難度。
也因此，雖然IP數位網路廣播技術蓄勢待發，但直到目前為止，國際視訊品質專家群組(Video Quality Expert Group, VQEG)目前仍在努力制訂可應用在媒體串流服務上的測量方式與國際標準。
一般而言，測量標準有主、客觀之分，主觀的測量方式不易標準化；而峰值訊噪比(PSNR)和均方差(MSE)等客觀測量方法，卻又不足以代表與主觀品質上的關連性，因此影音服務品質的評斷方式常常令人頭痛。
然在許多應用中，由於PSNR和MSE較為簡單且為大多數產業人士所熟悉，仍廣為業界採用，並成為新視訊標準設計的基礎依據。
IP網路環境因應用而異
由於一個較高服務品質的視訊編碼切割片段(Slice)，應控制在最大傳送單元(Maximum Transfer Unit, MTU)所允許的範圍內，因此要談視訊傳送的應用，就必須先了解最大傳送單元。最大傳送單元係封包在傳送層或網路層切割限制內，所能負載的最大資料量。之所以要求最大傳送單元的原因，主要是為了方便最佳化標頭(Header)與負載(Payload)之間的關係；其次，則是降低視訊編碼片段的遺失率。
話雖如此，由於最大傳送單元常隨著連結的狀況而發生動態改變，因此要在兩IP端點間的傳送路徑上界定最大傳送單元的大小並不容易。不過在一般有線 (Wired)環境下，最大傳送單元約為1,500個位元組(Bytes)；無線(Wireless)環境的最大傳送單元則約為100個位元組。一個視訊序列(Video Sequence)的組成元素，如圖1所示。
因為IP網路應用型態的不同，能使用的環境資源與配套措施將有所差異，而作為視訊傳送應用的IP網路，目前有三個不同的應用領域。然而，這三種應用類型不僅使用的媒體型態可能不同，就連最大傳送單元容量亦有不同的限制，茲分述如下。
傳統應用領域要求低延遲性
傳統IP網路可以區分為兩種型態，一種是非管理式IP網路(Unmanaged IP Networks)，如網際網路就是一例；另一種是管理式IP網路(Managed IP Networks)，這些有管理的IP網路通常存在於提供遠距通訊的電信公司。
這類的應用包含視訊電話(Video-telephony)與視訊會議(Video Conference），並對低延遲性(Delay)有非常高的要求。例如在點對點(End-to-end/Point-to-point)的通訊中，最佳延遲時間在100 毫秒內，或至少必須低於1秒。因為有最低延遲性的要求，所以編解碼器的運算複雜度(Computational Complexity)便須被限制，如Bipredicted Slices等複雜視訊編解碼器(Video CODEC)便不能使用。
這類應用所能使用的通常是即時(Real-time)的視訊編解碼器，以編碼參數可以隨實際狀況即時被調整的方式來維護一定服務品質。而在錯誤回復 (Error Resilience)的控制方面，適應性錯誤回復工具(Adaptive Error Resilience Tools)與回饋式來源編碼(Feedback-based Source Coding)工具都是常被使用的錯誤修復手段。
完全下載式應用注重編碼最佳化
完全下載式的預先編碼視訊串流，係先將影片壓縮成MPEG-2格式後再提供下載等服務。這種應用是目前許多網路服務的主要型態，媒體資料經過線上或離線的編輯、壓縮及數位出版後，製成單一完整檔案，利用FTP或HTTP協定來提供下載。因為媒體製作與使用者的下載使用非即時性，所以其編碼器有足夠的空間與時間來將傳送位元串流編碼最佳化，以達到最好的編碼效率，並且不須考慮網路遲延或是錯誤回復的問題。正因為這種視訊編解碼方法並非即時處理，所以視訊編解碼器的運算複雜度並非主要關心焦點，且在即時通訊協定(Real Time Protocal, RTP)封包化時，其網路抽象層單元(NALU)亦可能因為太大而被IP層進一步切割。
IP式串流應用須與網路條件相搭配
IP式串流服務如影音解決方案廠商Envivio提供的網路電視(IPTV)、廣播視訊娛樂平台等，此種的應用型態，介於傳統應用與完全下載應用之間，不過目前業界對串流的定義尚無公認標準。
大多數人將串流視為一種藉由網路媒介，將遠端媒體內容以接近即時(Near Real-time)方式傳送到客戶端的多媒體應用型態。和傳統應用一樣，串流具有一定的網路延遲容忍性，但比傳統應用要更具彈性，因此亦可採用較高延遲性的視訊編碼技術。
不過媒體內容並不在本端，而是由內容供應商(Content Provider)提供電子節目選單(Electronic Program Guide, EPG)以供遠端使用者選擇觀賞的媒體種類與互動形式。這種串流視訊的傳送，可由單點、多點或是廣播(Broadcast)的方式進行。根據接受者的群組大小，其回饋式傳送與編碼工具也會不同。
在一般情況下，串流伺服器(Streaming Server)用來傳送串流訊息的傳送協定乃屬不可靠的傳送協定(Unreliable Transmission Protocol)，如使用者數據協定(User Datagram Protocol, UDP)等。而串流的錯誤控制部分，多在來源端(Source)或是通道編碼(Channel Coding)上。在IP式的串流應用型態裡，編碼器只有一個主要限制，即必須考慮現存的網路條件並與目前使用的錯誤回復工具相互搭配，以提供使用者一個可接受的服務品質。
近幾年來，由於3G網路逐漸風行，IP網路型態又新增出一種類型：3G IP無線網路。上述幾種IP網路型態的最大傳送單元都不同，因此在傳送層或是網路層進行封包資料的切割時，封包大小也就有所差異。
利用錯誤控制機制提高錯誤回復率
在IP有線環境裡面，網路封包雖仍會遺失，但因為網路控管技術的精進與硬體設備的穩定性增加，目前這種位元錯誤發生的機率已經大幅降低，部分業界人士甚至認為可暫時忽略此項問題。
要將視訊媒體娛樂平台試行在IP網路上，一般較重視串流速率控制(Rate Control)與傳送控制協定(Transmission Control Protocol, TCP)流量屬性。目前，在大多數網站或電子郵件等網路應用上，流量是以TCP的方式傳送，如果一個正在傳送的TCP流量，初始傳送者將傳送位元速率降低一半，則封包遺失率也會相對提高，而迫使連線重新建立，相對帶來對使用者的困擾。
被迫重新連線的原因，是因為在TCP機制的設計上，為了提高單一區段(Session)通訊的密集性，以及避免路由器(Router)過載並兼顧連線公平性所做的考量。此機制也成為壅塞控制方法(Congestion Control Method)，利用重啟連線並重新選擇遞送路徑，來避免因壅塞造成封包繼續遺失。
在無線網路環境中，連結層協定(Link Layer Protocol)容易造成封包遺失，但目前許多媒體傳送協定的實作仍未將TCP流量屬性考量進去，所以這項問題並未完全解決。因此，為避免錯誤造成即時媒體太大的視覺品質影響，壅塞控制與錯誤回復編碼常被使用在這些錯誤的控制上。雖然壅塞控制與錯誤回復編碼都是一種錯誤控制方法，但仍存在不同差異。
在壅塞控制機制下，一旦TCP網路偵測到封包出現很高的錯誤率時，會減少網路流量的載入，因而減少網路流量；反觀在錯誤回復機制中，如果某些封包出現很高的錯誤率時，為維持一定視訊品質，會增加這些封包的副本拷貝，而會造成網路流量增加。因此這兩種方法存在著品質與流量控管使用上的對立矛盾。但以目前趨勢而言，寧可在不增加流量負擔下，利用減少視訊品質、畫面速率(Frame Rate)、圖片大小，或是在最壞的情況下將整個視訊傳送片段都予以丟棄的方式，來作為錯誤控制所必須付出的代價。
了解網路層級特性 提高媒體串流可靠性
在IP網路上使用MPEG-1或MPEG-2等較早期的視訊標準來傳送即時媒體，就必須建設網路實體層，而根據欲使用的媒體型態，可再區分成不同的網路層級設計，概述如下：
IP網路可在許多實體層與連結層上運作，因此如果運作是基於IP網路以上的應用，即可忽略此兩層次。
在網路層(Network Layer)上，是使用IP運作。在此層裡IP封包從傳送者端到接受者端，是彼此獨立，中間經過的一連串路由器也不盡相同，因此每個封包傳送所需要的時間互有差異，再加上路由器可以依據情況，任意丟棄封包，因此容易造成封包遺失。
此層的另一個重要作用是將服務資料單元(Service Data Unit, SDU)作適當的切割，使其符合最大傳送單元大小以利封包傳送。IP標頭約有20 個位元組並有一個加總檢查值(Checksum)確認標頭的完整性，不過在負載部分則並未提供任何保護。在IP規範書裡，IP封包的大小必須要在64KB 以內。不過因為已經有最大傳送單元的限制，一般IP封包很少會使用到此限制值。
IP網路在傳送層(Transport Layer)常使用的傳輸協定一般有兩種，一種是TCP，另一種是UDP。這兩種協定都包含傳送目標的位置與傳送埠，以及負載部分的錯誤控制機制。但 TCP與UDP不同，TCP屬於位元組導向(Byte-oriented)的連結傳送協定，是一種保證傳達的傳送協定，而其錯誤控制機制主要是用重傳 (Re-transmission)與逾時控制(Time-out Control)。
相較之下，UDP則是簡單不可靠資料傳輸協定，並不保證封包的傳達。UDP封包標頭大小為8個位元組，內含一個加總檢查值，負責偵測或移除封包位元錯誤 (Bit Error）。多媒體視訊串流多使用UDP而不用TCP傳送資料，主要原因在於多媒體資料的量大，如果每一個都要經由重傳或逾時控制，將會對即時要求大打折扣。因為UDP不像TCP負責送達之保證，同時有錯誤控制機制存在，UDP如果要使用錯誤控制或是回復機制，就必須在應用層(Application Layer)等更高層級實作這些機制，也就是所謂的應用層框架(Application Layer Framing, ALF)。
上述的ALF即是被實作成即時傳送協定(Real-time Transport Protocol, RTP)，因此RTP常被使用在IP/UDP架構之上。RTP是一種區段導向(Session-oriented)協定，並包含IP網路位置與UDP的埠號(Port Number)。每一個RTP封包組成，除本身標頭之外，還包含負載部分的標頭以及負載部分。而一個RTP標頭的組成則包含序號(Sequence Number)、時間郵戳(Timestamp)、負載型態(Payload Type)與標記位元(Marker Bit)等部分。
在負載型態部分，因為標示了媒體編解碼器的種類，因此更吸引業界的目光。舉例來說，在音訊編碼中，每個音訊編解碼器都有其對應編號，如A-law格式的 G.711音訊編解碼器，其負載型態便是8、G.723則是對應4號；視訊方面，JPEG對應26、H.263對應34等，更詳細的對應關係，可參考網際網路工作特別小組(IETF)的RFC 3551文件32、33頁，因此即時傳送封包的標頭大小，應為IPv4+UDP+RTP的標頭，也就是20+8+12＝40位元組，這對如無線網路等頻寬較小的環境而言，是必須正視的負擔。
為解決頻寬使用的問題，除一方面加速影音視訊的壓縮技術外，另一方面，封包的標頭壓縮技術也是一項發展重點。如C‧Bormann等人提出的RObust Header Compression(ROHC)技術，對使用RTP協定的語音封包而言，就可省下不少頻寬，並將此作為有效壓縮即時串流封包標頭的解決方案之一。依據 IETF RFC 3095文件的提議，此方法可有效壓縮封包標頭，將IPv4/UDP/RTP封包壓縮到平均只剩兩個位元組，這種ROHC技術對無線網路應用而言具有決定性的影響。
依據IETF官方網站資料，ROHC經過測試可在WCDMA、CDMA-2000以及EDGE上運作，但仍有技術門檻。為簡化實作及更新部分功能，被稱為「ROHCv2專案」的新一代技術因運而生，專案的目的是在不改變ROHC原本的協定架構下，改善壓縮器與解壓縮器之間的封包重排容忍性 (Reordering Tolerance)，並降低協定的複雜度。
媒體串流常使用的控制協定，包括H.245、SIP(Session Initiation Protocol，參閱RFC 3261)所使用的SDP(Session Description Protocol，參閱RFC 2327)或RTSP(Real-time Streaming Protocol)，其主要作用在於建立傳送者與接受者之間的通訊連結、通訊能力協調以及控制執行的通訊區段。
在這裡面類似SDP(SDP-like)的語法使用很廣，除可提供SIP使用外，也可提供SAP(Session Announcement Protocol，參閱2974)或是RTSP環境使用。不過在H.264/AVC裡，其位元串流(Bit Stream)不需要自我包覆(Self-contain)，因為所有會影響超過一個片段的訊息，都可經由使用控制協定等頻帶外(Out-of- band)或是使用MPEG-2傳送串流的頻帶內(In-band)方式傳送。圖2為H.264/ACV使用可靠的頻帶外方式傳遞參數。
因為頻帶外方式可以結合目前許多已存在的成熟控制協定，所以在應用上仍不失為另一種可靠度的保持方式。
H.264/AVC乘網路IP化之勢而起
H.264/AVC視訊壓縮編碼標準是目前最新的視訊編碼國際標準，H.264/AVC與之前ITU-T及MPEG所制訂的編碼標準一樣，都屬於一種區塊式(Block-based)的視訊編碼方法，其採用的是移動補償混合視訊編碼策略(Motion-compensated Hybrid Coding Scheme)。它是由ITU-T與ISO/IEC MPEG群組所通力合作產生的新標準，因此也等同於ISO/IEC 14496-10，亦即MPEG-4 Part 10所稱的進階視訊編碼(Advanced Video Coding, AVC)方法。
由於H.264/AVC的產生，乃是ITU-T的視訊編碼專家群組(Video Coding Expert Group, VCEG)與ISO/IEC動畫專家群組(Motion Picture Expert Group, MPEG)所聯合組成的團隊JVT(Joint Video Team, JVT)之成果，因此在標準上，它定義了兩個主要的層級(Main Layer)，分別是視訊編碼層(Video Coding Layer, VCL)與網路抽象層(Network Abstraction Layer, NAL)。
在視訊編碼層的定義中，包含將圖片裡的一連串巨集區塊(Macroblock)轉碼成分割片段或分割資料的各種工具與方法。之所以要將巨集資料進行轉碼分割動作，在於網路資料封包有一定大小的限制。因此在網路封包限制內，所形成的基本視訊負載傳送單元，即稱為分割槽或分割資料單位。
所以視訊片段分割(Slice Partition)與資料分割(Data Partition)的概念來自網路抽象層單位(NAL Unit)轉換的概念，為網路傳送必要的一環，而圖片的基本標頭資訊則被彙編在參數集(Parameters Set)裡一併傳送。
H.264/AVC乃由核心壓縮引擎(Core Compression Engine)與語法式層級(Syntactic Levels)所組成，設計是盡量與網路分別獨立運作。在H.264/AVC的視訊編碼層裡，也包含數種可修復已壓縮視訊串流的錯誤回復工具。 H.264/AVC網路抽象層的目的，則是提供H.264/AVC在IPv4/RTP/UDP、MPEG-2 Transport、H.324/M以及H.320的傳送能力，而與MPEG-4基礎建設(MPEG-4 Framework)整合的工作也正在進行中。
因此欲掌握整個H.264/AVC，必須了解兩個主要設計核心：訊號處理技術、傳送導向(Transport-oriented)機制，前者為主要核心壓縮技術，而後者則與網路抽象層級的封包處理息息相關。
H.264/AVC發展的主要動力之一，便是因應未來IP網路的應用需要，因此IP網路環境是H.264/AVC標準的設計核心概念。但因為每個視訊序列都由許多圖片(Pictures)組成，而每一個圖片在傳送時會被分割成I Slice、P Slice、B Slice、SP Slice與SI Slice等不同視訊片段。
在I Slice中，所有片段內的巨集區塊都以內部預測(Intra Prediction)作為編碼依據；而P Slice每個巨集區塊的編碼是使用區塊內的一個移動補償預測(Motion-compensated Prediction)訊號的互相預測(Inter Prediction)方式來作編碼依據。
B Slice雖然與P Slice相似，但是使用的是兩個動補償預測的互相預測方式作為編碼依據。
而SP Slice又稱為交換式P Slice(Switching P Slice)，主要設計目的是讓視訊片段可以在單一串流內進行跳躍交換，或在不同視訊串流內進行交換，卻不須要如同I Slice一樣使用很多位元需求。
同理，SI Slice又稱為交換式I Slice(Switching I Slice)，這種片段只被用在內部預測上面。其主要目的，在提供隨機存取(Random Access)功能或作為錯誤回復的一種工具。
在之前的國際視訊編碼標準中，I Slice、B Slice、P Slice的架構便已經存在並且彼此相似，但SI Slice及SP Slice則是H.264標準所提供的新片段種類。圖3為一個圖片被分割成不同片段的架構。
在圖4與圖5中分別顯示H.264/AVC的基本編/解碼器架構與其運作區塊，明顯較其他之前的視訊標準要來得更複雜，因此要了解H.264/AVC的運作，就必須詳細探討每一區塊的設計細節，例如圖片的分節、參考畫面的選擇、資料的分割、參數集、冗餘片段及彈性巨集區塊排序等，此部分將留待下期介紹。