【H.264/AVC標準剖析(三)】
在75期新通訊元件雜誌中我們談了不少巨集區塊(MB)在H.264/AVC上的運作細節，而本期將選擇圖片間的預測(Inter-picture Prediction或稱Inter-prediction)機制等運作來探討，並再談論新問世的H.264 FRExt較重要的增強功能。
H.264/AVC因應IP網路切割視訊片段
先來回顧一下，在74期新通訊元件雜誌中，我們討論了H.264/AVC的每個視訊序列都是由圖片(Picture)所組成，而圖片在傳送時都會被分割成I Slice、P Slice、B Slice、SP Slice與SI Slice等。
P Slice可依亮度區塊需求再切割
一般的P MB型態中有許多不同的移動補償編碼型態(Motion Compensated Coding Types)。P MB可被切割成為更小的區域來作為亮度(Luma)區塊的移動補償預測(Multi-picture MCP)單位，依切割的大小主要有四種型態，分別是16×16、16×8、8×16及8×8等。但值得一提的是，如果選擇的是8×8的區塊切割，那此區塊切割便會伴隨語法要素一起傳送。此語法要素必須指定此8×8的區塊是否還可以被切割成為更小的單位，例如被切割成8×4、4×8或4×4的區塊(圖1)。
每個M×N的亮度區塊預測編碼訊息都被放入記憶體控制器(MC)裡面，並藉由運動向量(MV)及圖片參考索引(Picture Reference Index, PRI)來指定。在H.264/AVC中，運動向量的精確性可達亮度樣本間的水平或垂直距離的四分之一。換句話說，如果運動向量指向一個整數樣本位置，那預測訊號就直接由該位置上的樣本參考圖片所組成。
但問題是，如果運動向量指向一個非整數位置，那該位置上的樣本預測訊號就必須以內插(Interpolation)的方式來計算，不過要注意一點，如果預測位置是橫跨片段(Slice)的邊界上，那就不會有運動向量預測值的發生。
另外，T. Wiegand、X. Zhang及B. Girod等人提到可支援多圖移動補償預測的語法，在這種語法裡面，其移動補償預測可參考多個先前解碼的圖片(圖2)。
這些先前的解碼圖片，會被編碼器(Encoder)存在解碼圖片緩衝區(Decode Pictures Buffer, DPB)內，且解碼圖片緩衝區的參考索引(Reference Index, RI)會與每個有移動補償的亮度區塊結合在一起，不論是16×16、16×8、8×16或是8×8的區塊大小都在其中。至於小於8×8區塊的運動向量P，亦使用相同的RI來作為全部8×8區塊區域的預測依據。
不過P MB亦可被編碼成P_SKIP模式(P_SKIP Mode)，在這種編碼模式裡面，不但沒有量化偵測錯誤訊號，也不會帶有參考索引的運動向量被傳送。其重建訊號的取得，僅使用在解碼圖片緩衝區內列表位置索引0(List 0)的圖片之P_16×16巨集區塊的參考預測訊號。而被使用來重建P_SKIP模式的運動向量，則與16×16區塊使用的運動向量預測器(MV Predictor)相似。因為僅須要使用很少的位元便可以表現這種模式，因而對具有廣大區域卻鮮少改變的場景有很大的效用。
如果編碼器將B Picture指定為參考圖片，其他圖片就可以使用含有B Slice的參考圖片來作為移動補償預測依據。然而B及P Slice之間的差異在於，B Slice的編碼規則裡，用以重建巨集區塊的訊號是立基兩個不同的移動補償預測加權平均值。也就是說，B Slice會使用到兩個解碼圖片緩衝區裡不同的參考圖片列表(分別是List 0及List 1)。不過在巨集區塊分割方式上面，B及P Slice使用的方法是相似的。
另外一個8×8的B MB分割，可以使用直接模式(Direct Mode)編碼，如果沒有錯誤訊號被傳送給直接模式，那此種模式亦可被稱為B_SKIP模式，它和P Slice內的P_SKIP模式一樣可以有效的編碼。
在早期的標準裡面，雙預測(Biprediction)常以兩個預測訊號的平均樣本來完成，因此也被稱為不使用加權性質的P MB型態。但在H.264/AVC中，編碼器可以指定每個片段內的P或B MB預測訊號的加權值以及偏移量。當使用相同的參考圖片時，可以在同一片段內使用不同的加權值或偏移量來計算移動補償預測。
迴圈式去塊狀濾器 改善視訊品質大
區塊式(Block-based)編碼的特徵之一，就是會產生視覺可見的方塊效果，這種情形尤其是在低位元速率(Low Bit Rate)情況下會更加明顯。一般來說，區塊邊界(Block Edge)通常是由移動補償預測進行，但該預測較內部樣本預測不精確。因此在作區塊轉換(Block Transforms)時，就可能產生不連續的區塊邊界。
基於此理由，在H.264AVC裡定義了適應性的迴圈去塊狀濾器(In-loop Deblocking Filter)。此濾器會將真實場景中尖銳化的邊界加以定位，以降低塊狀化的發生。相較於未使用迴圈去塊狀濾器，使用該濾器在視訊/影像主觀品質上提供很大的貢獻。
錯誤修復機制增加傳送可信度
要增加IP網路傳送的可信度，往往必須搭配錯誤修復機制。在H.264/AVC的發展中，其架構除了比現行許多視訊編碼演算法要精進之外，也包含大量錯誤回復工具(Error-resilience Tools)可供使用。
在H.264/AVC常見的錯誤有兩種，一種是解碼器錯誤，另一種是自發性因子的錯誤。要了解解碼器錯誤，就必須先明白H.264/AVC的各種工作版本。
在原始的H.264/AVC裡有三種基本的簡要檔案，分別是基態(Baseline Profile, BP)、主態(Main Profile, MP)以及延展性(Extended Profile, XP)。
H.264/AVC的主要設計特徵，則可區分為五個基本集合(Elemental Sets)，分別是：
主要特徵包括強固性(Robustness)、效率(Efficiency)與彈性(Flexibility)等特徵。屬於此集合之設計者有I Slices、P Slice以及文絡適應可變長度(CAVLC)等。
主要包含集合0的一些強化特徵，尤其是關於強固性與彈性方面。屬於此集合之設計者有彈性巨集區塊排序(FMO)、任意條帶排列(ASO)以及冗餘性片段(RS)。
此集合主要是包含集合1在強固性與彈性方面的進一步強化特徵，屬於此集合之設計者有SI/SP Slice以及片段資料分割(Data Partition)。
其主要是包含強化編碼效率的特徵，屬於此類是設計者有B Slice、場編碼(Field Coding)、加權式切割、巨集區塊適應性之框架/場域(Frame/Field)編碼。
特徵如進一步編碼特徵的強化，此類設計者有文絡適應性二進位算數編碼(CABAC)。在H.264/AVC BP版本裡，強調的是低運算複雜度的編碼效能以及強固性，因此在BP裡面，主要支援五種基本特徵集合的集合0和集合2。在主態裡面，因重點放在編碼效能，所以支援上述集合的種類有集合0、集合3以及集合4。至於H.264/AVC XP版，強調的是高編碼效率的強固性與彈性，因此除了集合4之外，幾乎支援所有集合。
由這些設計特徵我們可以知道，由於H.264/AVC MP版不支援彈性巨集區塊排序、任意條帶排列以及冗餘性片段，因此可被H.264/AVC BP所解碼的視訊串流，不見得可被主態的解碼器所解碼。同樣的道理，集合3以及集合4並非是所有H.264/AVC版本都有支援的特性，所以一些可被MP 版的解碼器所解碼的視訊串流，不見得可被XP版的解碼器所解碼，反之亦然。
因此為了避免不同的位元串流(Bit Stream)混淆，以及選擇正確的解碼器來解碼，在序列參數集(SPS)裡面存有指示旗標，用以指名視訊序列可被哪種版本的解碼器解碼。
關於另一種自發性錯誤，因為H.264是基於以前的視訊壓縮基礎所發展而來，因此以前的如MPEG-1 Part 2、MPEG-2 Part 2、H.261或H.263等視訊壓縮標準(Video Compression Standards)，其所提供的錯誤回復方法，都是H.264現成可用的錯誤回復工具。它包含了不同的圖片分節形式、內置換(Intra Placement)、參考圖片偵測、資料分割等。
在H.264裡面，也提供三個新的錯誤回復方法，分別是冗餘片段、參數集合(Parameter Sets, PS)及彈性巨集區塊排序。
中介負載大熱門
之前談過H.264/AVC的設計時空背景，是要將此新視訊壓縮技術應用在IP網路上，而目前一般IP網路用來進行錯誤修復的方法，主要有壅塞控制與錯誤回復編碼等方法。在H.264/AVC的錯誤修復工具裡面，另一種與壅塞控制相反的方式，也被視為是一種網路層級的控制方式，此方法一般便稱為媒體不感知 (Media-unaware)的中介負載。
中介負載(Meta-payload)技術是種被熱烈討論的即時通訊協定(RTP)負載媒體不感知技術，其主要是利用發送冗餘資訊(Redundant Information)的傳送方式，以增加封包到達率，並達到減少遺失率的目的。
減少封包遺失率增進傳遞效能
要達到減少遺失率的作法通常有三種，分別是封包複製(Packet Duplication)或稱為自動重複要求(Automatic Repeat Request, ARQ)、封包式前導錯誤偵測(Packet-based Forward Error Correction, FEC)與RFC 2198所提的音訊冗餘編碼(Audio Redundancy Coding, ARC)。
封包複製的方法，是最基本也是最直覺的作法，而為了減低網路頻寬的浪費，通常會搭配封包遺失審計的工作，只將常被遺失的封包加以多重複製並傳送，而非全部的封包都以冗餘方式傳送。
至於封包式前導錯誤修正，則是利用被保護封包互斥(XOR)加總檢查值的計算與傳送結果位元來作為冗餘資訊，這種方法在IP-based串流服務應用上被視為有潛在應用價值的錯誤控制技術。但封包式前導錯誤偵測因為會造成額外的延遲發生，並不適用在即時傳統的視訊應用上面，關於更詳細資料可參閱RFC 2733。
音訊冗餘編碼方法不只可用在語音保護，也可用在影像上。基本架構是封包除涵蓋本身標頭及本次負載外，封包後還包含上個封包的負載冗餘資訊，此種方法如在 H.264裡實現，則可用資料分割(Data Partition)來達成。不過須要注意的是，因這種技術會導致額外延遲，因此在低延遲應用領域裡，並無法適切地被使用；此外，大量發行冗餘封包雖可降低封包遺失率，但卻增加網路流量，對整體系統走向精簡的大方向有所違背，因而音訊冗餘編碼是不得已的作法，且僅適用在應用層(Application Layer)，尤對未提供錯誤保護的封包為主。
除了重複發送冗餘封包的方法之外，為了提高更多網路封包的可信度，H.264/AVC在網路抽象層概念裡加入一些新的旗標。雖然在H.264/AVC在規格書的附錄B(Annex B)裡仍支援少數傳統協定環境，如H.320或是MPEG-2的傳輸，但即時通訊協定封包化仍是H.264/AVC傳送的一個重要處理過程，唯要看即時通訊協定的封包化之前，要先看網路抽象層單元(NAL Units, NALU)。
網路抽象層單元決定封包處理型態
網路抽象層單元是一種具有可變長度的位元組字串(Byte String)，包含某些類別語法元件(Syntax Elements)。舉例來說，網路抽象層單元可攜帶已編碼後的Slice、A、B、C型的資料分割或一個SPS/PPS。每一個網路抽象層單元都有一個大小為一位元組的標頭，其內含大小為5位元的網路抽象層單元型態格式，型態種類有25種，也就是三十二種不同型態。
其中Type 1～12乃保留給H.264定義，Type 24～31則釋放給H.264以外資料使用。當進行封包化時，即時通訊協定的負載區(Payload)會使用這些型態數值中的一些部分，來作為訊號集成 (Signal Aggregation)以及分段時使用。其他未使用到的數值，則保留給未來H.264需要時使用。其標頭格式如圖3。
除了標頭資訊外，網路抽象層單元並具有三個固定長度的位元欄位(Bit Fields)以及一個可變長度的編碼字符(Coded Symbols)。nal_reference_idc旗標可用於網路抽象層單元之重建過程上，數值0表示網路抽象層單元不被使用在在預測上面，換句話說，它是比較不重要的，可以被解碼器或是其他網路元件所丟棄而不會有漂移效果的風險。
但如果該數值大於0，則表示該網路抽象層單元在那些要避免漂移效果的重建過程上具有重要地位，不可被任意丟棄。換句話說，該數值越高，表示該網路抽象層單元資訊如果遺失，會對重建造成很大的衝擊，因此網路元件可利用nal_reference_idc旗標來提供重要封包更強力的安全保護。另一個重要的旗標乃是forbidden_bit，在H.264裡面是被指定為0的。
但網路元件可在發現網路抽象層單元出現錯誤時，將此旗標值設定為1。此旗標在一些異質環境裡面非常有用，如有線與無線網路混合環境。在這裡，兩種網路的交接處往往會有閘道器(Gateway)，且這兩種環境可能非常不同。如無線環境可能使用的是非IP協定且容易出現傳送錯誤，但另一邊的有線環境，使用的可能卻是IP-based的環境。假設解碼器與有線網路端的閘道器連接，而從無線網路端傳入未經檢查碼程式Checksum測試的網路抽象層單元封包，並可能存有某些錯誤，此時閘道器可能會選擇將這個未經測試的網路抽象層單元封包自網路抽象層單元串流中移除。
既然要傳送到接受者端的網路抽象層單元封包都必須是零錯誤，因此要確定該封包是零錯誤封包的方便作法，便是讓網路元件可以偵測forbidden_bit 旗標。如果發現該旗標被設定為1，則表示該網路抽象層單元封包出現位元錯誤，此時便可將訊息傳給解碼器並嘗試重建一個沒有位元錯誤的網路抽象層單元封包。
目前所有H.264的封包化形式，都稱為簡易封包化策略(Simple Packetization Schemes)，其主要功能是將網路抽象層單元精準的放入即時通訊協定封包裡。其封包化可概分成三個主要步驟，分別是將網路抽象層單元放入即時通訊協定負載區(RTP Payload)、使用網路抽象層單元標頭資訊設定即時通訊協定封包標頭，以及傳送封包。
在一般理想狀態下，在視訊編碼層(Video Coding Layer, VCL)為了避免資料太大而遭受IP層(IP Layer)切割，通常不會產生大於最大傳送單元(MTU)的資料片段，複製封包到接受端後，會經由即時通訊協定序號資訊來辨識其封包順序，並將會將網路抽象層單元自即時通訊協定封包內取出。接受端如果是種時間依存性的描繪(Rendering)應用，那就會需要即時通訊協定封包內的計時資訊 (Timing Information)而關於計時資訊的覆寫，則屬於補充強化資訊(Supplementary Enhancement Information, SEI)網路抽象層單元的工作。在H.264/AVC的SP及XP版本裡面，他們允許不依順序來解碼片段，因此封包不須在抖動緩衝區(Jitter Buffers)裡重新排序。但如果是使用H.264/AVC主態，就不提供這種隨意不照順序解碼片段的功能。
換句話說，封包必須在緩衝區裡，依據即時通訊協定序號資訊排序後，解碼器才能解碼片段。在目前H.264/AVC的發展裡，封包排序使用的是即時通訊協定本身的序號資訊，但另一種解碼器序號(Decoder Order Number, DON)也已經在IETF研議可能性。
不過，H.264/AVC的封包化設計並非是無所限制的，有關H.264/AVC即時通訊協定負載規範的設計，應注意以下幾點：
因為H.264/AVC的網路抽象層設計概念源自IP環境的使用需求，因此關於IP環境的許多使用限制，在設計H.264/AVC時已經被考慮。網路抽象層單元標頭同時可以作為即時通訊協定的標頭，因而H.264/AVC在完成封包化的過程時不再需要其他負載的標頭。
在如DVD上的MPEG-2影片等部分已事先編碼的媒體內容中，為了使網路抽象層單元傳送更有效率並降低網路流量，適當的將網路抽象層單元分節與集成傳送有相當助益。因編碼器不能即時與最大傳送單元互動，所以在網路傳送時，許多網路抽象層單元會大於最大傳送單元大小的限制。在這種情況下，IP層的分割機制就會被用來分割這些太大的網路抽象層單元，使其控制在64位元組以內。
可以預期的是，傳送片段一旦使用IP層分割機制，就表示其媒體傳送不會有相對的保護機制可供選用。值得慶幸的是，如補充強化資訊網路抽象層單元或參數集網路抽象層單元等H.264/AVC常見的網路抽象層單元都不大，甚至只有數位元組，此將有助於和其他網路抽象層單元集合在同一即時通訊協定封包裡傳送，以減少所需要的IPv4/UDP/RTP標頭以及網路流量。
單/多時集成封包應用有差異
以目前的H.264/AVC集成策略來說，可區分為兩種集成封包，分別是單時集成封包(Single-time Aggregation Packets, STAPs)與多時集成封包(Multi-time Aggregation Packets, MTAPs)。前者之所以稱為「單時」集成封包，即是表示其內的網路抽象層單元都使用同一時間郵戳(Timestamp)；而顧名思義，後者內的每一個網路抽象層單元所使用的時間郵戳都不見得相同。
在使用上，單時集成封包主要是被用在低延遲性的環境裡面，其標頭設計與網路抽象層單元標頭具有相同格式，且只占一個位元組，功用乃為指示該封包是否為單時集成封包。但如果是在高延遲性環境裡面，宜採用多時集成封包的集成方式。
多時集成封包在基本結構上與單時集成封包相似，但每一個網路抽象層單元內所含的時間郵戳，會被解碼器用來當成解碼順序。不過不管是上述的何種集成方式，目前都仍在試行，未來在設計階段是否會再改變仍有待觀察。
不過，對一個沒有提供適當保護的網路應用而言，使用資料分割是一種可用來改善錯誤率的方法，此種方法誘人之處在於它不會增加太多系統負擔。而網路節點利用資料分割來保護封包的主要方式，便是依據資料分割型態的種類來判定封包資料的重要性與否，以提供不同的分級保護。例如：A型資料分割比B型資料分割要重要，則它所應受到的網路保護就應該比B型分割要更周到。而C型資料分割保護，則可容忍遺失。
對一個即時通訊協定接受者而言，它可能會因為網路條件或設定而丟棄那些只擁有B型或C型資料分割的封包。這種機制在媒體感知閘道(Media-aware Gateway)的應用非常有用。在壅塞的網路內，當閘道發現到片段內之A型分割的封包已經遺失時，則它也會丟棄同一片段內的B型或C型資料分割的封包，如此一來可避免無用封包陸續進入網路，並減緩網路擁塞的問題。
強化型H.264規格問世
自從2003年5月第一個版本的H.264/AVC視訊標準釋出以來，全球已經掀起許多新標準的應用風潮，如果先不談授權費(License Fee)，H.26H.264/AVC挾其優異的影像壓縮功能，已成為許多業者的主要賣點。而新的應用標準中，亦指定使用H.264/AVC來作為新一代影像壓縮標準。
只不過第一版的H.264/AVC並無法全面應用在新興領域，為補足H.264/AVC目前所欠缺的能力，JVT強化了H.264/AVC功能，並加入新的特徵，而此強化型的H.264/AVC就稱為H.264 FRExt(H.264 Fidelity Range Extensions)。
2004年7月，H.264 FRExt修正一版(Amendment 1)出爐，在此版本它包含四個新加入的簡介，分別是High Profile(HP)、High 10 Profile(H10P)、High 4：2：2 Profile(H422P)與Hight 4：4：4 Profile(H444P)，然於2006年時又將Hight 4：4：4 Profile排除於Annex A及後續的相關應用。
因為第一版的H.264/AVC主要焦點放在娛樂品質(Entertainment-quality)的視訊上面，因此視訊的樣本採樣是以8位元色彩深度為主，而其色度(Chroma)的模式則使用4：2：0模式。以當時的制訂時點來說，均未將專業環境的應用需求考慮進去，並且在視訊解析度的設計上面也並非採用最高解析度模式。
在第一版釋出後，經過這幾年的推廣與業界的應用需求，JVT為使H.264/AVC標準能在更廣泛的應用中針對工作室的編輯或專業後處理，而加入一些新的應用特徵，這些特徵包含：
基本上H.264 FRExt版本都支援H.264 MP版本的所有特徵與功能，而目前許多數位電視廠商現階段的作法都是將重點放在H.264 FRExt的HP版本上，因為在較近期的發展裡面，H.264 FRExt HP版本被規範在許多新興應用的標準裡面，如BD-ROM、HD-DVD、ATSC或是DVB等行動電視之相關規範。
而在H.264 FRExt裡數項新增的特徵，簡述如下：
．在內部預測(Intra-prediction)方面：提供區塊的亮度預測。
．在整數逆轉換上面：提供整數逆轉換運作，矩陣定義如下：
另一個H.264 FRExt版本的改良之處，在於色彩空間的轉換上面。因為色彩空間的轉換和一般空間轉換一樣，都是一種浮點數運算，因此容易出現四捨五入後的進位錯誤 (Rounding Error)問題。以目前大多數視訊的捕捉與顯示裝置而言，多使用RGB色彩空間，但這種空間裡的色彩元素彼此關聯性太高，與人類視覺系統並不符合。
反而是以亮度元件以及包含色調(Hue)與飽和度(Saturation)色度元件的表現方式比較接近人類視覺系統。因此為了方便色彩之處理，使其更適合我們的視覺感官，通常我們會在壓縮前使用色彩空間轉換(Color Space Conversion)，將RGB色彩空間轉換成YCbCr空間。然後才將此視訊編碼於YCbCrDomain中。這些轉換的計算方式如下：
其中KB＝0.0722，而KR＝0.2126。上述的色彩轉換看似合理，但卻有兩個應用上的問題。首先是轉換過程屬浮點運算，因此在將RGB轉換成 YCbCrDomain時會發生進位錯誤的問題，如此再將YCbCrDomain轉換回RGB色彩空間，經多次運算後色彩失真會被放大。
第二個問題，由於這些色彩轉換通常並非屬於視訊壓縮標準裡面的一個正常處理過程，因此在實作時，會發生色彩轉換複雜度與編碼效率上的取捨問題。
要解決第一個問題，其方法之一便是查表法。也就是說在轉換之前，將原始RGB值記錄下來並放在表格裡面建立索引，每此要轉換到新的色彩空間時，即參考索引載入原始RGB值，促使進位錯誤不被放大。而在進行YCbCr空間逆轉換時，亦可不須經過計算，直接查表可得RGB的色彩空間值。不過這種方法還有一些問題要克服，如需要龐大的表格儲存空間，因而在應用上仍有其限制。
在第二個問題的解決上，則必須回歸視訊壓縮標準的設計層面。換句話說，視訊標準裡面要能將色彩空間轉換納入標準處理流程，而非以外掛的方式處理。在 H.264 FRExt修正一版裡，該版本支援一種新的色彩空間轉換稱為YCgCo，其中Cg表示綠色色度元件，而Co表示橘色色度元件。這種色彩空間的表示不僅比較簡單，而且更具編碼效益。其RGB轉換YCgCo色彩空間的計算方式如下：
YCgCo色彩空間相較於YCbCr色彩空間擁有更低的運算複雜度，不過要注意的是，YCgCo色彩空間並非用來解決進位錯誤問題。要避開這種進位錯誤問題，可從色度元件處理，但在此暫不進行討論。
H.264/AVC與MPEG-4各有所長
大家對新的視訊標準H.264/AVC寄予非常深的期望，而此視訊標準也被設計來使用在許多廣泛的應用裡面，包含廣播應用、傳統視訊服務、媒體互動應用、VOD或媒體串流服務以及多媒體訊息服務等。不過許多人對H.264/AVC還有一些誤解，以為H.264/AVC乃是要用來取代MPEG-4而成為全方位的視訊壓縮標準。
此概念似是而非，主要區別在於這兩者在產業應用上需求不同。前者著重要編碼效率、彈性與強固性的媒體應用上；而後者則著重於多媒體編輯與即時互動應用上，兩者在某些應用裡的確有市場重疊的問題存在，但是在非重疊部分他們仍有並存的價值。
H.264/AVC相較於MPEG-4、H.263、H.262/MPEG-2等系列，提供了許多重要的功能改進，包含預測方面的改良、編碼效能的改良以及網路資料強固性的改良。
在預測改良方面，它加入可變區塊式移動補償、加權預測方式、迴圈去塊化濾器、多重圖片參考的運動向量等技術；在編碼效能方面，它加入了小型4×4區塊轉換 (H.264/AVC)、8×8區塊轉換(H.264 FRExt)、文絡適應性熵編碼、精確配對轉換、階層式區塊轉換等技術。
在資料錯誤或遺失的強固性維護上，H.264/AVC提供了網路抽象層單元的設計、彈性的片段大小、彈性的巨集區塊排序、參數集架構、資料分割等技術。
而整個H.264/AVC架構因H.264 FRExt的功能補足，使其更往專業領域跨足，至於未來是否會成為「全方位」視訊壓縮標準的盟主，就要看MPEG-4相關版本的應用方面是否能在家庭娛樂、互動性(Interactive)與視訊編輯(Video Authoring)上取得更大優勢，如果不能，那MPEG-4被邊緣化的危機就會正式浮現而可能面臨被市場淘汰的命運。