轉HDMI

HDMI協議解析

2017年06月18日 14:19:27

閱讀數：2987

轉載請標明出處floater的csdn blog，http://blog.csdn.net/flaoter

本文從軟件工程師角度對HDMI spec進行解析，基於的spec版本爲1.4，也是設備支持最多最成熟的版本，目前最新版本爲2.0。

1 概述

HDMI（High-Definition Multiface Interface）是Hitachi, Panasonic, Philips, SiliconImage, Sony, Thomson, Toshiba幾家公司共同發佈的一款音視頻傳輸協議，主要用於DVD, 機頂盒等音視頻source到TV，顯示器等sink設備的傳輸。傳輸基於的是TMDS(Transition Minimized Differential Signaling)協議。此外，使用TMDS也是DVI標準的主要特色 。

2 物理結構

 
上圖是HDMI block結構圖，能夠看出HDMI用於audiovisual source和sink之間的鏈接，HDMI cable由3組差分信號傳輸TMDS數據，1組差分信號傳輸clock。此外，HDMI還有一個DDC的通道鏈接到sink的EDID。CEC和HEAC都是HDMI的可選協議。 
 
HDMI定義了五種類型的connector，上圖是最多見的type A。 
1-9是TMDS data傳輸用到的引腳，共有三組； 
10-12是TMDS clock傳輸用到的引腳，共有一組，TMDS clock就是pixel clock； 
13是CEC引腳，一種消費電子兼容的傳輸協議； 
14是保留引腳； 
15,16是DDC的引腳，DDC是基於I2C協議傳輸，故引腳爲SCL和SDA； 
17是接地； 
18是+5V power； 
19是HPD引腳，用於創建鏈接。

3 傳輸

概述

HDMI傳輸由三組TMDS通道和一組TMDS clock通道組成，TMDS clock的運行頻率是video信號的pixel頻率，在每一個cycle，每一個TMDS data通道發送10bit數據。 
 
上圖是HDMI傳輸的示意圖，從圖中可知，HDMI傳輸以下四種類型數據： 
（1）Preamble控制信息，圖中的CTLx，可用來表示後面傳輸的是data island仍是video data。經過channel1和2的D[1:0]傳輸，佔用4bit。 
（2）Data Island，即數據包，如Audio數據包。經過3個channel的D[3:0]傳輸，佔用12bit。 
（3）Video Data，視頻數據。示意圖中傳輸的是RGB格式圖像，R,G,B分別經過channel2,1,0傳輸，每一個顏色8bit，共24bit。 
（4）HSYNC, VSYNC。使用channel0的D[1:0]傳輸，佔用2bit。 
8bit的數據在source通過TMDS encoder後獲得10bit數據，通過serializer後串行輸出；在sink端先進行復原成10bit的數據，再經過TMDS decoder獲得8bit的源數據。 
此外，HDMI視頻是stream式的傳輸，不涉及packet式的傳輸。

流式傳輸的兩大主流種類及流式傳輸特色
2015年04月14日 17:29:02
閱讀數：1870
轉自：http://blog.csdn.net/hguisu/article/details/7418087


     流式傳輸定義很普遍，如今主要指經過網絡傳送媒體（如視頻、音頻）的技術總稱。其特定含義爲經過Internet 將影視節目傳送到PC機。實現流式傳輸有兩種方法：實時流式傳輸（Realtime streaming）和順序流式傳輸（progressive streaming）。（百度百科）

    在網絡上傳輸音/視頻（英文縮寫A/V）等多媒體信息目前主要有下載和流式傳輸兩種方案。A/V文件通常都較大，因此須要的存儲容量也較大；同時因爲網絡帶寬的限制，下載經常要花數分鐘甚至數小時，因此這種處理方法延遲也很大。流式傳輸時，聲音、影像或動畫等時基媒體由音視頻服務器向用戶計算機的連續、實時傳送，用戶沒必要等到整個文件所有下載完畢，而只需通過幾秒或十數秒的啓動延時便可進行觀看。當聲音等時基媒體在客戶機上播放時，文件的剩餘部分將在後臺從服務器內繼續下載。流式不只使啓動延時成十倍、百倍地縮短，並且不須要太大的緩存容量。流式傳輸避免了用戶必須等待整個文件所有從Internet上下載才能觀看的缺點。

　　1.流式傳輸的種類

　　網絡傳輸音頻、視頻等多媒體信息有下載和流式傳輸兩種方案，下載方案因爲A/V文件較大，所需存儲容量也較大，且網絡帶寬的限制致使下載費時久，且延遲亦較大；而流式傳輸方案則避免了用戶需等待整個文件所有下載後才能播放的缺點。流式傳輸技術又分兩種，一種是順序流式傳輸，另外一種是實時流式傳輸。

　　①順序流式傳輸(Progressive Streaming)

　　順序流式傳輸是順序下載，媒體在下載文件的同時，用戶能夠觀看在線節目。在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的部分。順序流式傳輸不像實時流式傳輸那樣，能夠在傳輸期間根據用戶鏈接的速度進行調整。因爲標準的HTTP服務器可發送這種形式的文件，也不須要其餘特殊協議，於是它常常被稱做HTTP流式傳輸。因爲該文件在播放前觀看的部分是無損下載的，最終播放質量較好，於是特別適合質量較高、數據量較小、經過Modem發佈的短片斷，如片頭、片尾、廣告等。但用戶在觀看前必須經歷數秒的延遲，傳輸速度較慢時尤其明顯。對經過調制解調器發佈的短片斷，順序流式傳輸顯得很實用，它容許用比調制解調器更高的數據速率建立視頻片斷。儘管有延遲，畢竟可發佈較高質量的視頻片斷。順序流式文件是放在標準HTTP或FTP服務器上，於是易於管理，基本上與防火牆無關。順序流式傳輸不適合長片斷和有隨機訪問要求的視頻，如講座、演說與演示，它也不支持現場廣播。所以，嚴格地說來，它本質上是一種點播技術。

　　②實時流式傳輸(Realtime Streaming)

　　實時流式傳輸可保證媒體信號帶寬與網絡鏈接匹配，可實時觀看節目。實時流與HTTP流式傳輸不一樣，它須要專用的流媒體服務器與傳輸協議。實時流式傳輸老是實時傳送，於是特別適合現場事件，且支持隨機訪問，用戶可對觀看內容進行快進或後退以觀看前面或後面的內容。理論上，實時流一經播放就不可中止，但實際上，可能發生週期暫停。實時流式傳輸必須匹配鏈接帶寬，這意味着在以調制解調器速度鏈接時圖像質量較差。並且，因爲出錯丟失的信息被忽略掉，網絡擁擠或出現問題時，視頻質量差，而沒有順序流式傳輸視頻質量好。實時流式傳輸須要特定服務器，如QuickTime Streaming Server、RealServer與Windows Media Server。這些服務器容許你對媒體發送進行更多級別的控制，於是系統設置、管理比標準HTTP服務器更復雜。實時流式傳輸還須要特殊網絡協議，如：RTSP(Realtime Streaming Protocol)或MMS(Microsoft Media Server)。這些協議在有防火牆時有時會出現問題，致使用戶不能看到一些地點的實時內容。

　　顯然，在實際應用時，具體採用哪一種傳輸方式可根據須要肯定，且流式傳輸也支持在播放前徹底下載到硬盤。通常狀況下，流式傳輸模式會使用RTP/UDP、RTSP/TCP兩種通訊協議與A/V(Audio/Video)Server創建聯繫，將服務器的輸出重定向到一個運行A/V Player程序所在客戶機的目的地址。一般，流式傳輸系統通常都要配置一套專用的服務器和播放器。

　　2.流式傳輸的特色

　　與單純的下載方式相比，這種對多媒體文件邊下載邊播放的流式傳輸方式具備如下的特色：

　　①大幅度地縮短啓動延時

　　流式傳輸大幅度地縮短啓動延時，由於用戶不用等待全部內容下載到硬盤上纔開始瀏覽，不管是上班時間仍是晚上，速度都至關快。通常來講，一個45分鐘的影片片斷，在一分鐘之內就顯示在客戶端上，並且在播放過程當中，通常都不會出現斷續的狀況。此外，全屏播放對播放速度幾乎無影響，但快進、快倒時，須要時間等待。

　　②大大下降對系統緩存容量的需求

　　因爲Internet是以包傳輸爲基礎進行斷續的異步傳輸，其數據被分解爲許多包進行傳輸。動態變化的網絡使各個包可能選擇不一樣的路由，故到達用戶計算機的時間延遲也就不一樣。所以，在客戶端須要緩存系統來彌補延遲和抖動的影響和保證數據包傳輸順序的正確，從而使媒體數據能連續輸出，且不會因網絡暫時擁堵而使播放出現停頓。雖然，流式傳輸仍須要緩存，但因爲不須要把全部的動畫、視音頻內容都下載到緩存中，於是對緩存的要求大大下降。

　　因爲流媒體技術使用了數據緩衝技術，於是可保持流媒體的不間斷，並保證文件傳輸的可靠性。

　　③有特定的實時傳輸協議實現流式傳輸

　　由前面敘述所知，流媒體目前有三種主流格式，並須要相應的特定的實時傳輸協議。通常，採用RTSP等實時傳輸協議，更加適合動畫、視音頻在網上的流式實時傳輸。

　　此外，採用流媒體技術不會佔用本地的硬盤空間等。

 

 
上圖是傳輸720x480p video的hdmi timing圖。 
在video data period，有效的video數據進行傳輸； 
在data island period，audio和auxiliary數據以包的形式進行傳輸； 
在control period，CTLx和HSYNC, SYNC進行傳輸。 
data island period和control period都是在消隱區進行。圖中行消隱佔用138像素，場消隱佔45行。 
 
上圖中是對時序圖中描述的三種period分別傳輸的數據和編碼類型進行說明。video數據從8bit/channel encode後變爲10bit/channel, data island的packet數據從4bit/channel encode後爲10bit/channel, control數據從2bit/channel encode爲10bit/channel。

Control Period

 
只有兩種類型的preamble信息組合，CTL0:3=1000表明接下來的是video data period，CTL0:3=1010表明接下來的是data island period。HSYNC, VSYNC此時也有可能發生變化。

Video Data Period

video data period以2個字符（pixel）長度的leading gurad band開始，guard band以下： 
ch0: q_out[9:0] = 0b1011001100 
ch1: q_out[9:0] = 0b0100110011 
ch2: q_out[9:0] = 0b1011001100

Data Island Period

data island period傳輸audio數據和輔助數據，輔助數據包括Infoframe和其餘用於音視頻信息描述的數據。data island period以2個字符長度的leading guard band開始，並以2個字符寬度的trailing guard band 結束。guard band以下： 
ch0: q_out[9:0] = n.a 
ch1: q_out[9:0] = 0b0100110011 
ch2: q_out[9:0] = 0b0100110011 
data island傳輸的packet類型和格式詳見spec說明。 
三個傳輸階段的過渡過程以下圖所示： 
 
(1) 左一是control period， 分別佔用三個channel的D[1:0]，channel 0傳輸HSYNC, VSYNC, channel1,2 傳輸Preamble 
(2) 左二是data island period，分別佔用了三個channel的D[3:0]，channel 0的D[1:0]傳輸HSYNC, VSYNC， channel0的D[3:2]傳輸packet header, channel 1,2的D[3:0]傳輸packet。而且兩端以guard band隔離 
(3)右二接下來又是control period 
(4)右一是 video data island, 佔用了所有三個通道，而且開始以guard band 隔離

4 Video

支持三種pixel encoding：RGB4:4:4, YCbCr4:4:4, YCbCr4:2:2 
video format除了CEA-861-D中格式外，還會支持一些較特殊的格式 
color depth可支持一個像素24, 30, 36和48bits 
下面分別是24bit/pixel的RGB444, YCbCr422, YCbCr444的pixel encoding示意圖。RGB444每一個顏色佔8bit， YCbCr422中Y佔12bit，C佔12bit，YCbCr444中Y,Cb,Cr都佔用8bit。 
 
 

Deep Color模式 
Pixel Packing 
24 bit mode: 1 pixel/group, 1 fragment/group 
30 bit mode: 4 pixel/group, 5 fragment/group 
36 bit mode: 2 pixel/group, 3 fragment/group 
48 bit mode: 1 pixel/group, 2 fragment/group 
1fragment/TMDS clock, 如30bit下的4pixel，須要5次傳輸完成，每次1個fragment。 

5 Audio

Audio數據以Audio Sample Packet或High Bitrate Audio Stream Packet的形式傳輸，可是HDMI沒有傳輸audio clock，所以sink設備須要進行audio clock regeneration。原理以下： 
 
128∗fs=N×fTMDS/CTS 
N和CTS會在Audio Clock Regeneration Packet中進行傳輸，TMDS clock可經過硬件獲取，所以sink端可算出source傳輸的audio clock。

6 Control

InfoFrame

Infoframe以Infoframe packet的形式傳輸，它的大小不超過30字節加上一個checksum字節。具體infoframe的格式及內容須要查看spec。 
AVI(Auxiliary Video Information) Infoframe 
Audio Infoframe 
HDMI Vendor Specific Infoframe, 傳輸4kx2k或3D格式時須要發送此packet

EDID & DDC

sink設備在ROM中存放EDID信息，source在收到HPD後會經過DDC通道讀取EDID獲得顯示設備的屬性。EDID包含兩部分，前128字節符合EDID1.3數據結構，128字節的擴展EDID，符合CEA extension verison3。CEA extension verison3以下圖所示。 
 
HDMI VSDB 
HDMI sink設備在第一個擴展EDID中包含HDMI VSDB，source在讀取EDID後會根據是否有此block來判斷設備是HDMI仍是DVI。

Hotplug

source會監測HPD pin的狀態，當source和sink鏈接後，若是HPD爲高電平，說明sink設備正常能夠工做，source可經過DDC讀取EDID，若是爲低電平，說明sink已斷開。 
sink可經過拉低HPD超過100ms來向source代表EDID發生了變化，此時source會從新讀取EDID。

HDCP

涉及內容較多，會在單獨章節中講解。