顯示具有 iptv 標籤的文章。 顯示所有文章
顯示具有 iptv 標籤的文章。 顯示所有文章

2011/10/14

實作MPEG2視訊分析

目前監視IPTV電視頻道功能,主要由人工觀察頭端機房電視牆之畫面品質,其缺點除僅為單點監控外,於下班時間亦無人監看,且無法記載短暫或細微的視訊品質劣化過程。若採購3rd Party廠商電視頻道監控設備,由於價格昂貴,限於預算,僅可佈放零星數個監控點。

IPTV用戶障礙申告數偏高,開機用戶率偏低,缺乏一個簡單、迅速、有效且具經濟效益之查測機制,直接導致查修與客服人員之龐大負擔,對提升用戶數與營收亦有負面影響。


於單機實作完成後,大量佈放探針STB於網路拓樸上各監控點,並將結果傳送回主機分析,比較設備前後的監控結果,進而釐清障礙點之所在。

可大量以IPTV機上盒型式佈建於各監控點,成點線面,比較設備前後間之監控結果,協助釐清障礙點所在,過程簡單明瞭,加速解決時程,減少查修人力,降低客戶申告率,進而減輕客服負擔,維護客戶口碑,減低客戶退租之想法。


前10天的分享著重於討論背景知識,先說明各家廠商視訊監視儀的功能比較,再說明目前嵌入式系統發展趨勢,包含ARM與Intel x86兩種架構,接下來解釋MPEG2視訊壓縮標準與部分H.264壓縮演算法。

第11到24天,深入探討研究之主題,若對背景知識有相當熟稔的專家,可以直接參閱這幾篇文章,先研究如何使用網際網路群組管理通訊協定,包含版本1到版本3,接下來說明開發探針程式的過程,包含品質參數,並大篇幅說明如何剖析封包。

第25天到29天,說明設計統計蒐集器,也就是屬於系統後台與資料庫系統部份,包含網頁伺服器的架設,品質參數的接收程式。

第30天,結論與未來展望,也是最後一篇,對整個分享做一個總結與對未來的展望,提出四個擴充演算法則,規劃於資料庫伺服器進行後續資料收集與分析彙整工作,擬進行更進一步之分析研究,以完成點線面之全面監測,包括「點:特徵比對法 & 決策樹分析」、「線:向上搜尋法」與「面:區域比較法」,以擴大研究範圍,豐潤分享成果。

IPTV是一個複雜的服務應用,所要求的網路品質也相對地高,經營IPTV業務,對於電信網路日益複雜的應用服務,以及逐漸減少的預算來說,是一個艱難的挑戰。

由於IP網路本身就是一個不可靠的網路,IPTV服務又是一個要求高傳輸頻寬,低傳輸延時和低jitter的服務,在IPTV服務運行的時候,整個IPTV網路中任何一個環節出現問題,都會導致用戶觀看電視時出現馬賽克、停格,聲音斷斷續續,嚴重時甚至可能導致用戶無法觀看電視。

為了保證服務品質, IPTV服務提供商必須鞏固自身網路建設,為了保證網路結構的最佳化,提高IPTV服務品質,IPTV服務提供商必須對整個IPTV網路進行監控,隨時掌握網路現狀,因此必須使用相應的網路監控工具,進行故障預警及排除。

在IPTV監控中心,最常使用傳統的電視牆的方式進行監控,在出現問題時進行手工記錄,無法保存當前的原始資料,因此就無法對出現的問題進行分析及故障排除。而在傳輸部門,雖然有一些網路監控的工具,但只能分析網路層的資料,不能分析到IPTV存在的問題。

在障礙的排除部份,現行情況是在客戶出現問題後,維修人員需攜帶機上盒、可擕式的電視、筆記本電腦及相關儀錶等一大堆的工具,去到接入機房檢測,如在接入機房沒檢測到任何問題,還需攜帶這些工具去客戶處檢測。



所以透過在各網路點裝設監控工具,實現對IPTV網路的輕鬆維護,快速並準確診斷出障礙點,對將要發生的問題提前預警。



下面將簡介目前Anacise推出的視訊監控設備WatchiTV。

Anacise WatchiTV包括IPTV全網監控系統WatchiTV Distributed和可擕式的IPTV用戶端開通維護工具WatchiTV Portable,幫助客戶管理、維護整個IPTV網路。



●功能概述:寬頻上網與IPTV多媒體影音服務測試,主動測試,不須要STB與電視即可測試頭端影像品質與線路狀況。
- 模擬STB播放影片
- 網際網路連結
- FTP Download 測試
- 流量監控
- HTTP, RTSP, IGMP 協定訊號的產生

●MPEG-2多媒體影音訊號品質分析:
- 同時支援主動與被動測試。
- 支援unicast與multicast。
- Stream 結構發現與呈現(包括IP層與MPEG2 TS層PSI Table)。
- 提供累計Jitter值與瞬間Jitter圖。
- MPEG封包丟失統計與每秒統計圖。
- 影片擷取與重複撥放,並可設定當有packet loss或Jitter過大時自動截取。
- 支援UDP大封包over IP傳輸格式。

●控制訊號與流量監測:
STB服務中控制訊號與流量監測,IPTV服務系統偵測,網路流量偵測、特殊協定偵測,可針對ATUR上IP層屬於STB的資料流單獨測量,提供動態圖形即時呈現流量變化,並針對RTSP與IGMP協定提供即時的時間軸落點指示,透過與動態流量圖的組合,即時監控RTSP與IGMP協定命令後的流量變化。





STB服務中控制訊號與流量監測,IPTV服務系統偵測,網路流量偵測、特殊協定偵測,可針對ATUR上IP層屬於STB的資料流單獨測量,提供動態圖形即時呈現流量變化,並針對RTSP與IGMP協定提供即時的時間軸落點指示,透過與動態流量圖的組合,即時監控RTSP與IGMP協定命令後的流量變化。



支援以下功能:

● ATUR 訊息狀態檢查。
- Max. Upload and Download speed
- Connection Mode
- Attenuation
- SNR margin
- Output power
- Bit per Tone Graph

● STB啟動程序監測,監看STB啟動流程與應用連結層基本查測。
- 偵測並判斷是否STB之IP或Gateway設定錯誤。
- 偵測並判斷是否STB中的STB Booting Server的IP設定錯誤。
- 偵測並判斷是否STB中的STB Booting Server的Mount Path設定錯誤。
- 偵測並判斷是否STB中的Time Server 的IP設定錯誤。
- 偵測並判斷是否STB Booting Server中的URL設定錯誤或是Middle Wave的網頁服務出現問題。


以上一些專有名詞如PES與PSI會在後面的文中分享,下一篇會再繼續介紹另外兩款視訊監控儀! 請不要錯過了喔!

Anasice WT-600外觀:




Anasice WT-600 支援以下參數的量測;
● Priotiy 1
- TS_sync_loss
- Sync_byte_error
- PAT_error
- Continuity_count_error
- PMT_error
- PID_error

● Priotiy 2
- Transport_error
- CRC_error
- PCR_error
- PCR_repetition_errot
- PCR_discontinuity_indicator_error
- PCR_accuracy_error
- PTS_error
- CAT_error

● Priotiy 3
- NIT error
- SI repetition error
- Buffer error
- Unreferenced PID
- SDT actual error
- EIT actual error
- RST error
- SDT other error
- EIT other error
- Data delay error
- TDT error
- Empty buffer error



量測的stream是由IPTV骨幹mirro一份串流下來分析封包,
在實務上必須注意設備的上鏈路徑是否能夠負擔所有頻道的總頻寬,
不然是會造成packet loss,反到自己的電路造成量測錯誤。
頻道數一多,總頻寬可能會超過1Gbps,或者電路同時使用作別的用途時,
也會造成量測錯誤,但在骨幹端及用戶端是正常的,在實務上必須注意。



Anacise WT-600在障礙發生時,可以由手機,email與監控畫面上同時收到告警,
雖然Anacise WT-600支援Priotiy 1,2,3這麼多參數,但由於太靈敏,故實務上僅接收MLR(Media Loss Rate)與DF(Delay Factor)兩種品質參數。

何謂MLR與DF,於開發的章節再一併為大家介紹。



圖IneoQuest Geminus G10

Geminus IPTV品質視訊測試儀是一個從1G~10Gbp的視訊監控、分析、模擬及測試的工具,比較特別的這套機組是採模組化設計,可擴展的硬體平臺。可依需要與使用介面購買卡板。

Geminus系列包含 G10 Max、G10 Base、G2X Max、G2X Base及Geminus G1-T,Geminus G2X 與 Geminus G1-T可連接至1Gb的視訊網路,Geminus G10則可連接於10Gb的視訊網路。

所有Geminus系列針對視訊監控及分析均提供擴充性,G10 Max 與 Geminus G1-T提供一條實體的訊務產生線路供模擬用。

IneoQuest的設備能夠針對IPTV即時品質監測、障礙定位和視訊流模擬。運用高速FPGA晶片,Geminus平臺提供10Mbps到10Gbps速率,同時支援IPTV視訊品質監測和障礙定位的完整解決方案。根據不同的模組,Geminus提供多樣的硬體測試組合。產品功能如下:

‧ 最多即時監控及量測2000個Video Stream。

‧ 最多4個streaming port,4個1Gbps或者2個10Gbps。

‧ 支援10/100/1000 Mbps LX及TX。G10模組支援10 Gbps XFP port。

‧ 依據需要定義告警門檻。

‧ 自動從MPEG-2 Transport Stream檢測節目名稱(需來Source端有提供)。

‧ 記錄即時節目和回傳即時解碼到監控中心(實用度待商確)。

‧ 支持多種的視訊格式(MPEG2,MPEG-4,H.264,VC1,AVS,MPEG-2 TS, ISMA)。

‧ 支援RFC3357 RTP 傳輸品質分析。

‧ 依據PID的告警值進行監測和告警。

‧ 支援 SNMP 和 Syslog 數據收集。

‧ HTML使用者介面。




由於本設備我們單位僅短期測試,沒有正式採購,所以部分圖文來自網路,如有侵權請留言告知,筆者馬上刪除。

IneoQuest對台灣某IPTV業者使用的系統沒有全面進行客制化,所有對於Unicast與NVOD主機Pumping出的Multicast串流無法解析,其實這部份筆者還幫原廠throuble-shooting,提供正確RTSP語法,但卻無法及時修改firmware,對於要賣設備的廠商,比購方不熟這一點是不及格的,後來廠商還打著我的名號到其他分公司推廣,其實像我這種小咖,就不用報出大名出來了,而且替不合用的設備背書,自己挖坑自己跳?

其實RTSP與IGMP語法非常簡單,這次本公司的升資考試還有考到IGMP Version 1的protocol,剛好我有Implement過,關於這部份下一個章節會講到。一直欠東欠西真不好意思,但內容真的很多,就請大家忍耐一下,更精采的內容明天在見喔。

上一篇: [IPTV] 實作MPEG2視訊分析 - 簡介視訊監控儀(2)
http://ithelp.ithome.com.tw/question/10053086

下一篇: [IPTV] 實作MPEG2視訊分析 - 網際網路群組管理通訊協定(1)


Internet Group Management Protocol, Version 1

沒有適當的協定出現,群播勢必無法於Internet上普及。
RFC 1112「Host Extensions for IP Multicasting」中,
定義 IP 群播在 TCP/IP 網路中的使用標準。
除了定義群播位址及主機如何支援群播外,
此 RFC 也定義「Internet Group Management Protocol, Version 1」。
RFC 2236「Internet Group Management Protocol, Version 2」則定義 IGMP Version 2。
目前某企業IPTV環境中,群播電視使用IGMP Version 2,也就是說每一個頻道只會指定群播IP與Port,無法指定來源IP,
故當一個Group IP由兩個以上的來源端同時發送時,解碼器會夾雜接收數個串流,而導致畫面無法解碼,
也會超過DSL所能承載的頻寬而掉封包。
使用「Internet Group Management Protocol, Version 3」 之後,
主機可指定要由特定的來源端接收群播的流量,可以是一部編碼器或是支援群播的視訊伺服器,
也可以由指定特定來源以外的所有來源端接收群播流量。往後會分別介紹IGMP Version 1、Version 2與Version 3。

第一份有關群播的RFC於1986年由Steve Deering撰寫完成,
但大家對於了在群播的需求是近幾年來才開始興起的,
因為企業界對於一對多乃至於多對多的傳輸需求增加,
而單播的對於每一個連線均複製發送一份封包,
消耗掉過多的骨幹網路頻寬,且造成發送端的多重負擔,
若使用廣播的方式傳送資料則會增加網路上其他主機的負擔,
因為不管主機需不需要這一筆資料,使用廣播的方式均會傳送。
遍及整個Internet的群播,必需等待跨AS(inter-as)通訊協定的研究發展完成,
例如Multi-protocol BGP(MBGP)及Border Gateway Multicast Protocol(BGMP)等。

今天的題目就偷懶一點,貼上本公司升資考試的題目,

拜有實際實做過的經驗,這一題我是有答對啦。

終於快可以貼code了,貼code比貼圖輕鬆多了....


IGMP Proxy snooping

IGMP Proxy
IGMP Proxy原理其實就是通過在下鏈的界面上接收IGMP report訊息,然後再從上鏈的界面上傳送出去;同時在路由器上添加對應的virtual interface(VIF)的路由訊息(MFC)。 最後,使得從上鏈的界面收到的群播封包,能發送到下鏈的界面對應的網路去。在實作中,MFC(multicast forward cache)表添加的時候是通過來源IP和群播群組目的IP來產生一個雜湊值作為索引的。但由於IGMP Proxy必須對所有的來源IP的群播包進行添加MFC entry,因此這個雜湊函式就必須修改,比如使用群播群組目的IP和界面索引來產生雜湊值。 當然,也可以用別的方法。

IGMP snooping(Internet Group Management Protocol snooping)是運行在layer 2 Ethernet Switch上的群播約束機制,用於管理和控制multicast group。

IGMP snooping 運行在Data Link Layer。當Layer 2 Ethernet Swtich收到主機和路由器之間傳遞的IGMP封包時,IGMP snooping 分析IGMP 封所帶的訊息。

當監聽到主機發出的IGMP Host report message時,Switch就將與該主機加入到相應的table中;當監聽到主機發出的IGMP leave message,Switch就將刪除與該主機對應的multicast entry。通過不斷地監控IGMP封包,交換機就可以在二層建立和維護Multicast MAC Address Table。之後,交換機就可以根據Multicast MAC Address Table進行轉發從路由器往下發送的群播packet。

沒有運行IGMP snooping 時,multicast packet將在二層廣播。運行IGMP snooping後, 封包將不再在二層廣播,而是進行Layer 2 Multicast 。
Ethernet Switch利用IGMP snooping 實現對IGMP封包的偵測,並為主機及其對應界面與相應的群播組地址建立映射關係。

實務上,由於IGMP Snooping使用的時機非常少,國內某大廠的L2 Switch在IGMP Snooping與IGMP Proxy有不少軟體上的BUG。

IGMP Version 1使用Query-Response模型來允許群播路由器和多層次交換器來確定在本網段內哪個群播群組是啟動的。在這個模型中,路由器或交換器充當IGMP 查詢路由器,每隔60秒週期性地發送IGMP Version 1 Membership Query給224.0.0.1。啟用群播的所有主機監聽該位址並接收Query Packet。主機以IGMP Version 1 Membership Report回覆,表示它要接收特定Group的Multicast Traffic;該網段中的路由器或交換器就可以了解群播群組中有哪些接收者。

主機可以通過發送一個或多個主動的Membership Report封包表明加入(Join)一個群播群組。如: 某個主機主動發送一個Report封包表明要接收群播群組(224.1.1.1)的流量。

主機通過停止處理群播群組訊務以及不回應IGMP Query的方式來離開群播群組。

IGMP Version 1依靠L3的IP Multicast Routing Protocol(PIM、DVMRP等)來解決同一網段中哪個路由器或多層次交換器成為查詢路由器。查詢路由器發送IGMP Version 1的Query來確定哪個群播群組是啟動的。通常Designated Router會被選擇為查詢路由器。IGMP Version 1的封包有2種:Member Query(224.0.0.1, 每60秒查詢一次)與Member Report。

主機群可以加入群播群組,但是IGMP Version 1沒有Leave訊息,路由器或多層次交換器需透過一個逾時機制的運作,讓那些沒有人接收的訊務不再送到不需要的主機成員。

解釋昨天的題目:

這種封包格式常看的人, 這一題就屬於送分題, 但另外一題封包題就出錯了, 害我算很久算不出答案, 但是還是在考試時看出來, 所以我很自私的沒有替大家申訴 (快留言罵我吧!!)
很簡單喔, 16進位的每個數字代表4個byte, 題目問你, 訊息Type, 那就是第二個數字2, 看一下type的?明, 0x2為Host Membership Report, 所以選二, 就這麼簡單!

實做時看你是要Query還是Report, 把GroupAddress用Big Indian的方式填到第5到第8個Octor中, 然後在把Checksum送出去, 串流就會用UDP的方式送過來, Router上是跑PIM-SM或DM就不用管了! 接收也很簡單, 起一個UDP Server就好了, 這時有人會疑惑, 為甚麼Client是起UDP Server而不是UDP Client! 仔細想想就會明白!

今天的題目, 跟主題無關:
剛去抓題目時, 已經改成送分, 請問下面這一題那裡出錯, 修正後的答案為何?

另外這份考卷還有三處答案錯誤, 其中兩處被我申訴成功, 出題的人真的很誇張!!!!

IGMP所使用Checksum函式, 其實這在很多Opensource的軟體中都看的到!!!!
  1. static unsigned short in_cksum(unsigned short *addr, int len)
  2. {
  3. int nleft = len;
  4. int sum = 0;
  5. unsigned short *w = addr;
  6. unsigned short answer = 0;
  7. while (nleft > 1) {
  8. sum += *w++;
  9. nleft -= 2;
  10. }
  11. if (nleft == 1) {
  12. *(unsigned char*)(&answer) = *(unsigned char*)w;
  13. sum += answer;
  14. }
  15. sum = (sum >> 16) + (sum & 0xffff);
  16. answer = ~sum;
  17. return (answer);
  18. }

在Client連接群播群組時,於指定的主機群組中宣告成員資格,傳送IGMP Report。也傳送 IGMP 主機成員資格Report訊息,以回應路由器傳送的 IGMP 主機成員資格查詢(IGMP Query)。主機可使用 IGMP Version 3 Report訊息,指定要由指定的Source接收群播的流量,這是IGMP Version 3最大的不同,也就是不同的編碼器可以丟出相同group的stream。

Client可使用 IGMP Version 3 Report訊息,指定要由指定的Source接收群播的Stream,或是由指定Source以外的所有來源接收群播流量。防止啟用群播的路由將群播傳輸傳遞到沒有Client的子網路。
群播路由器用來每隔一段時間輪詢一次網路中的群組成員。路由器可使用 IGMP Version 3 Query,查詢Client是否要由指定的來源清單,接收群播流量。

IGMP Version 3主要改進的功能是可以允許主機指定它們想要在某個Multicast Group中只接收特定的Multicast Source。這個增強功能使得路由資源可以更加有效地被使用。IGMP Version 3新增了可以根據群播來源來過濾群播的功能。

IGMP Version 3不僅可向下相容於之前版本的IGMP通訊協定。為了維持與較舊版本IGMP系統的向下相容性,IGMP Version 3群播路由器必須也同時採用Version 1和Version 2的通訊協定。

介紹Class D位址範圍群播IP位址
Multicast=群播=組播

共分4部分介紹IGMP,包含igmp SNOOPING與igmp Proxy,如果有大大有興趣的歡迎留言賜教,覺得寫的好才幫我按,覺得寫不好歡迎指點,單純留言鼓勵也非常歡迎。

IANA(Internet Assigned Numbers Authority)定義了由 224.0.0.0 到 239.255.255.255 的 Class D 位址範圍內,Class D 位址保留及指派IP群播位址使用。Class D位址的前四個位元永遠是1110,與Class A、B、C位址範圍很不一樣的是,Class D不再區分子網段,故扣除固定的前四個位元,剩下的28個位元共可以產生228個群播群組。

群播有趣的是,來源端不必知道群組中有哪些接收端,接收者可以隨時加入或離開群組。群播 IP 傳輸會傳送到單一位址,但是卻由多個主機來接收。只有隸屬於群播群組的主機,會接收並處理傳送到群組的資訊。正在接聽指定的IP 群播位址的主機群組,稱為群播群組。

若來源端與接收端在同一LAN中,接收端只要設成接收此群播位址,即可接收資料。但若來源端與接收端不在同一LAN中,亦或說中間有經過路由器,此時情況較為複雜,路由器是可以選擇將群播的封包轉送到所有的LAN中,這樣的做法如同廣播,違反了群播的基本精神,沒有節省到網路資源。所以,路由器必須知道哪個網路內有隸屬於此群組的成員,方式就是透過查詢。每個版本的 IGMP 都會定義通訊協定,以用來交換及更新群播群組中指定主機成員的相關資訊。

視訊壓縮標準概述

眼睛是靈魂之窗,視覺是未來人類獲取資訊最主要的感觀,視頻資料為多媒體資訊中資料量最龐大的一員,此領域已成為目前世界上技術開發和研究的焦點,儲存視訊資料需要最複雜的壓縮技術,同時也代表壓縮與解壓縮時需要較多的CPU時間,目前業界已經制定出許多處理影像訊號壓縮及編碼的技術。
MPEG 的標準由 ISO (International Standards Organization) 所制定,全名為 Moving Pictures Experts Group,這些團隊制定了包括 MPEG1、MPEG2、MPEG4 等標準。
MPEG1 制定於1993年,主要用途為:視訊會議、影像電話、電腦遊戲與CD-ROM。MPEG1被設計來支援大部份的影像與 CD-ROM 的音效,傳輸速度為 1.5 Mbps (30 fps),對類比視訊到數位視訊儲存的產生重大革新。
由於MPEG1壓縮率過低,畫質不如傳統類比視訊儲存媒介,故沒有過多久,MPEG2的標準於1994年被制定出來,MPEG-2 相容於 MPEG-1。MPEG-2是一個非常優秀的壓縮演算標準,加強 MPEG-1 影像品質不足的地方。因此,MPEG2更能昇任其它工作環境,例如:DVD、HDTV、視訊廣播。隨著半導體技術的提升,MPEG2的軟硬體壓縮設備更為低廉,MPEG2直至今日仍佔據視訊壓縮主流角色。
隨著行動裝置以及大尺寸薄型顯示裝置的普及,更合適的MPEG4標準在1998年被提出,包含第十部份的H.264,目前仍持續在增訂中,主要的應用用途比較廣,制定了由低速裝置到高速裝置所有應用標準,包括了視訊會議、影音郵件、無線裝置等等,支援的傳輸速度為 8Kbps ~ 35Mbps。
本章對於目前使用量最多的視訊壓縮技術MPEG2做一個概述,最後簡介目前地表最強大的壓縮技術─H.264如何對視訊壓縮後的畫質有大符度的改善。

視訊編碼概念
當一個二維亮度函數被取樣、量化而變成數位影像時,就會產生很大的資料。事實上,這個資料可能會大到無法進行儲存,處理與通訊傳輸。例如:一張512x512 pixel,8 位元/pixel,3 顏色的影像所需的儲存空間為:512*512*8*3/8約786432個位元組。一段數位視訊若以640x480,每秒15 張,90 分鐘的一段全彩數位視
訊而言,其需要的頻寬為:
640*480(pixels/frame)*3(bytes/pixel)*15(frames/sec) =13824000 bytes/sec=13.18 MB/sec
而所需的儲存空間為13.18*90*60=69.50GB。顯然地,這樣的儲存方式極不具經濟效益,且若直接在網路上的傳輸視訊資料,所耗費的頻寬對絕大部分的人而言根本是無法負擔的。對於數位視訊的高儲存空間,不但儲存是一個問題,傳輸更是一個不可能的任務,因此我們需要將資料壓縮。資料壓縮的目的是減少表示數位資料所需的資料量,可能是減少表示一個訊息所需要之訊號空間量,或者是傳送該訊息所需之頻寬。對於數位視訊而言,有許多的技術被運用來壓縮視訊。

由於連續視訊是一連串靜止畫面所組成,相臨的畫面間會有極大的相似性,因此會產生時間域冗餘(temporal redundancy),若先計算前後畫面間不同的地方,只對不同的地方做編碼,如此就可以達到減少資料量的目的。

再者,同一張的畫面中,鄰近的像素間相關性也極高,會有空間域冗餘(spatial redundancy),我們可以利用此特性來進一步的壓縮,其次是我們觀察人對視訊的感覺,發現人眼的反應相當差,我們將畫面間人眼不易察覺的資訊去除,雖然會失去資料的完整性,但人眼是無法辦別的。最後使用非失真壓縮技術再來對資料做編碼,以最有效率的方式來儲存這些資訊。
1.1 取樣方式
人類視覺系統對於亮度較彩度為敏感,故在視訊之儲存上,常將亮度分離出來,更甚者,使用較多空間儲存亮度資料。例如ITU-R recommendation BT.601定義色差表示法的運算式如表6.1,其中R為紅色,G為綠色,B為藍色,也就是亮度三原色,Y為亮度,可以看出綠色代表的是比較亮的色彩原色,Cb與Cr分別是藍色與紅色的色度通道。

MPEG-2支援隔行掃描和逐行掃描。在逐行掃描模式下,編碼的基本單元是Frame。在隔行掃描模式下,基本編碼可以是Frame,也可以是場(field)。

原始輸入影像首先被轉換到YCbCr顏色空間。其中Y是亮度通道,Cb和Cr是兩個色度通道。對於每一通道,首先採用塊分割,然後形成macroblock,macroblock構成了編碼的基本單元。每一個macroblock再分割成8x8的小塊。色度通道分割成小塊的數目取決於初始參數設定。例如,在常用的4:2:0格式下,每個色度macroblock只採樣出一個小塊,所以三個通道macroblock能夠分割成的小塊數目是4+1+1=6個。

1.2 動態評估
為了取得高壓縮比效果, MPEG 採用了複合式多種壓縮技巧,首先是以區塊為基礎的動態補償 (block-based motion compensation) 方法,利用前一畫面至目前畫面內容之預測 (prediction) ,或是由前一畫面其下移畫面至目前畫面內容之內插預測 (interpolation prediction),計算預測的誤差值 (差異值) 。

因為連續的畫面間通常存在有極大的相關性,如果我們把像素的運動軌跡都可以描述出來,那麼我們只需要編碼、並送出第一個畫面及軌跡的資訊即可。相鄰畫面間的差易性極小,若顏色深度為8bit,共256色階時,相減之後在全部位置上同時加上128。事實上我們是以區塊為基礎來描述運動的向量,我們稱為動作向量(motion vector)。利用動作向量可以幫助我們做畫面間的動作補償(motion compensation)。