TW200814780A

TW200814780A - DVC delta commands

Info

Publication number: TW200814780A
Application number: TW096115354A
Authority: TW
Inventors: Gary W Shelton; William Lazenby; Michael Potter
Original assignee: Avocent Corp
Priority date: 2006-04-28
Filing date: 2007-04-30
Publication date: 2008-03-16
Also published as: WO2007127452A2; IL194952A0; US20090290647A1; US8660194B2; US7782961B2; CA2650663A1; WO2007127452A3; EP2016767A2; US20070253492A1; EP2016767A4; IL194952A; MY149291A

Description

200814780 九、發明說明： t發明所屬之技術領域3 發明領域本申請案主張美國臨時申請案60/795,577的優先權，其 5 整篇内容在此以參照形式被併入本文。此申請案也與下列共同審查之美國專利申請案有關，該專利申請案一般為本申請案所有，其内容以參照形式被併入本文： 1、名為“Video Compression System”並於2002年 10月 1 日提 1〇出申請的美國申請案1〇/260,534。此揭露是關於一電腦視訊壓縮系統。發明背景一視訊壓縮單元在此被揭露，其使用了基於先前在申 15請案10/260,534中所揭露之方向演算法概念的一壓縮方案。被稱為“DVC編碼”的該演算法在此被使用並具有一些新增加的擴充。本申請案減少在透過一擴充鏈結傳送一視 δί1框緩衝器時所使用的頻寬。假定美國申請案10/260,534 的内各對於讀者是已知的。利用美國申請案10/260,534之 2〇 “DVC編碼”的產品已被商品化且應該被視為先前技術。该“DVC編碼”演算法之一層面就是該鏈結的每一端總有别一訊框的一完整版本作為參考使用。這允許隨後的訊框中每一像素被下列命令定義： 1、與前一訊框中的像素比沒有變化（沒有變4匕 5 200814780 (NO_CHANGE)) 2、與上一行中的像素相同（複製上方(COPY_ABOVE)) 3、與左邊的像素相同（複製左邊(c〇pY一left)) 4來自先如已知子集的像素序列（製作序列 5 (MAKE—SERIES)) 5、新像素(NEW—Pixel) 只有该New 一 Pixel選項需要一完整像素透過該鏈結被發迗。岫二個只需要指示出哪一類編碼被使用以及有多少連續像素被根據該編碼類型來編碼的一短命令訊息被發 10运。在編碼期間，被壓縮的目前訊框及（如果是可應用的）前一訊框這二者的像素資料從記憶體中被讀出。接著目前像素與一參考像素比較：前一像素(類似kC〇py_left)、月ί) 一行（類似於COPY一ABOVE)及前一訊框（類似於 NO—CHANGE)。對於該三個方向命令中之每一個，如果該 15命令是有效的且其相關聯的比較匹配，則該命令保持有效且預期組再增加一個像素。當所有方向命令由於失效或結束條件而已終止時，最後的有效命令被選擇為該組像素編碼。如果機會相同，則優先順序可以以下列順序來被指疋·例如，NO—CHANGE、COPY—LEFT、COPY ABOVE。 20這是先荊的DVC-編碼產品在歷史上所使用的順序，是依據解碼的難易來被安排。儘管如此，其他順序可被使用。在每一端進行雙倍或三倍緩衝，則所有三個命令需要解碼器付出類似的努力。前一像素（PreviousPixel)的單個複本被保留用於執行 6 200814780 該COPY—LEFT比較，而一整行像素資料(previ〇usLine)被保留用於執行C0PY—AB0VE比較。前一訊框(Previ〇usFrame) 像素由記憶體子系統與目前像素一起提供。因為NEW_PIXEL是效率最低的壓縮方法，所以其最不 5受喜愛且只有在該等其他壓縮類型都不適用於一目前像素時才被使用。因此，一NEW一PIXEL決定總是終止一像素編碼串流並發送前一命令串進行傳輸及解碼。接著， NEW—PIXEL命令在一逐個像素基礎上被完成直到另一編碼類型將再次用於一目前像素。 10 邊MAKE—SERIES編碼類型利用了全部來自一先前唯一像素色彩子集的一像素序列。標準模式是使用一雙色集，其對於正文視窗（text window)是理想的。這可根據硬體實施選擇併入的序列比較器及暫存器的數目被擴充至四色或更多（一的層冪）。一序列比較器在硬體中被需要用於該子 15集中的每一像素。當每一像素被處理(從記憶體中被讀出）時，它與目前序列子集暫存器中的每一像素比較。所有該專比較被平行執行，結果被發送給命令程序。只要該等子集比較器中的任何一個（且不應超過一）為真，則該Series命令是有效的且可以繼續執行。 20 這前五個命令類型被稱為原始的基於DVC的命令，其等在申請案10/260,534中被詳細描述。此揭鉻使用了結合較複雜的編碼命令與該等原始的基於DVC的命令。該等較複雜的編碼命令如下·· 6、來自前一訊框中相同像素的差量（差量—無變化 7 200814780 (DELTA_NC)) 7、來自正上方像素的差量（差量—複製上方 (DELTA_CA)) 8、來自前一像素的差量（差量—複製左邊(Delta_cl)) 5 差量命令是發送全精度色彩的一可選擇方案，取代發送一個小得多的值，該值為真實色彩與用作參考的相鄰色彩中之一個之間的差異（差量）。在24_位元色彩情況中，該全精度色彩疋24-位元而該差量是4個位元或12個位元。有多個可被實施的不同類型的差量命令。一些包括每一色彩 10通道的一唯一差量值，而其他含有被施加到所有色彩通道的一均勻差量。每一差量的大小（以位元表示）也可以根據配置而變化。 r 該視訊壓縮單元也可以使用“色彩減少，，來減少頻寬使用。色彩減少從每一色彩通道中移除掉一些最低有效位 15元，因此增加了相鄰像素與比較器看起來相同的可能性，且也減少了被需要來發送一未壓縮像素的資料之大小。【明内容】發明概要 1、一種視訊壓縮常式，包括： 20 才欢查所選擇的先前及目前視訊框中的像素；對於一給定的該目前訊框及對於其-目前像素，製作定義至少該目前像素的固定位元長度封包，該等封包包括： ⑴稷製像素封包，具有至少一封包類型的識別符位元及至J/ -反覆計輯別位元； 8 200814780 (2) 色彩定義封包，具有至少一封包類型的識別符位元及至少一色彩識別符位元； (3) 差量定義封包，具有至少一封包類型的識別符位元及至少一差量識別符位元；以及 5 (4)雙色序列已編碼封包，具有至少一封包類型的識別符位元及至少一系列二進制色彩識別符位元，該等二進制色彩識別符位元只對應於兩個色彩且與該目前像素及緊接在該目前像素之後的多個像素的色彩一致。圖式簡單說明 10 關於附圖所給出的下列描述參考該等非限制性的圖例可以被較好地理解，其中該等附圖顯示：第1圖係一示範性視訊壓縮系統；第2圖係一示範性輸入訊息單元格式；第3圖係一示範性讀命令單元格式； 15 第4圖係一示範性編碼標頭單元格式；第5圖係原始DVC命令的示範性8-位元單元；第6圖係差量命令的示範性8-位元單元；第7圖係示範性差量模式；第8圖係包括示範性差量模式的單元； 20 第9圖係一示範性比較方塊；第10圖係示範性命令單元格式及命令表；第11圖係示範性色彩深度命令單元及色彩深度模式表；第12圖係示範性命令單元；第13圖係示範性多位元組命令單元； 9 200814780 第14圖係—示範性命令資料單元；及第15圖係示範性核心時鐘率表。 L· 較佳實施例之詳細說明 5第1圖顯示—視訊系統之示範性視訊壓縮系統1〇〇。該視訊壓⑽、統腫卩分包括命令程㈣2及—輸出程序 1命令程序102是主程序，其回應來自數位視訊輸 ()單元IG4之輸人並接著藉由向記憶體控制器1〇6發出-請求而開始處理-訊框。輸出程序1〇3為該系統的其餘 10部分產生輸出。該命令程序1()2包括一訊息介面1〇5及一記 U體"面107，该讯息介面105用於接收來自該單元⑺4 的訊息而該記憶體介面107用於與記憶體控制器1〇6進行通訊。 δ亥命令程序1〇2的訊息介面1〇5起初接收來自該dvi單元104的一輸入訊息1〇1。該訊息是由該DVI單元1〇4所寫入 15的一個171170 8_位元訊息。最普遍的訊息填入單一個位元組中’而頗為罕見的時序值佔用多個位元組且因此需要多個時鐘。該輸入訊息101的基本訊息標頭（任何訊息的第一位元組)被顯示於第2圖中。該訊息標頭具有一個四-位元類型欄 20 位(7 : 4)與一個四-位元資料欄位(3 : 0)。該類型欄位指定下列訊息類型中之一個：開始訊框（Start Frame)(0001)、結束訊框(End Frame)(0010)、水平時序(Horizontal Timing)(0100)、垂直時序(Vertical Timing)(0101)及像素時鐘率(Pixel Clock Rate)(0110)。應該注意的是儘管目前五個訊息類型被定 200814780 義，但是更多的訊息類型可以利用“保留的，，位元值來被定義。該標頭之資料欄位根據訊息類型來提供訊息資訊。如果訊息類型是一開始訊框或結束訊框訊息，則該訊息被包含在該標頭之資料欄位中。 5 視訊時序訊息(水平時序、垂直時序或像素時鐘率）需要该汛息標頭之後的5或6個位元組資料。對於這些訊息，該標頭之資料欄位指定後面的位元組數。每一類視訊時序訊息的資料結構被顯示於第2圖中。該等位元組首先被發送最低有效位元組及位元，所以使用該水平時序作為參考，有 10效資料的位元〇映射到位元組0的位元〇。有效資料位元7映射到位元組0的位元7。有效資料位元8映射到位元組丨的位元0。該記憶體介面107處理兩個類型的資料：被發送到記憶體的一讀命令108以及隨後被返回的資料(像素資料）。該命 15令程序102使用一讀命令1〇8來發送一請求以開始從目前及之前訊框中讀出像素資料並經由像素中的寬度及高度來指定訊框的大小。該讀命令108被顯示於第3圖中且含有命令類型、訊框寬度、訊框高度以及兩個訊框ID欄位（一個是最早存取的訊框之識別號而另一個是最近存取的訊框之識別 20號）。這些欄位指定哪個像素應該被發送給該命令程序102。一旦該記憶體控制器106已接收到識別像素的一讀命令108 ’則該記憶體控制器ι〇6就應該開始用來自二個來源訊框(source frame)的像素資料填充目前資料nFO 110及前一資料FIFO 112。被返回的資料被假定為全24-位元像素資 11 200814780 料，且如果需要較低色彩深度，則隨後將被該視訊壓縮系統100減少。該記憶體控制器106直接將該返回資料寫入該目前資料FIFO 110及之前資料FIFO 112。該命令程序1〇2監視目前資料FIFO 110及之前資料FIF0 112這二者的空白旗 5標以決定它們每一個何時有像素資料要處理。該等旗標可利用一布林或運算來被組合形成一信號。一旦该命令程序102決定有像素資料要處理，則當資料可知時，它開始處理一訊框資料（一組像素該命令程序疋作出與哪個編碼要執行有關的決定且每作用時鐘⑽μ 1〇 dock)將產生的決定發送給該輸出_1〇3的核心。此判決可以是以下任何一個： 1、在像素已被編碼到一主動執行的命令中之情況下 (此時沒有東西被發送給該輸出程序103)，不產生決定。 2、請求儲存-個值在輸出緩衝器中(像素、差量或序列) 15 3、=求直接產生命令輸出（典型地完成-方向命令）月求產生-命令’自輸出緩衝器中之—個 (完成一基於像素、差量或序列的命令）。 20 笛令程序1G2可以執行的兩個類型的編碼被顯示於 „中。如在基於爾的編㈣，視訊封包是基於8-位但其他單元數可被替代。有根編圖所示之命 “被疋義的多個類型的標頭單元元組__具有第4圖所示之下列基本格式/、弟四個m前三個位元Μ是衫命令的命令位元。第凡）疋擴充位兀。當-標頭使該擴充位元被設定 12 200814780 時，則該命令後面奴還有至少—位元組。該擴充位元的主要目的是為了擴充含有-計數的命令之計數攔位的大小，即：使一命令適於用在更多的像素，比以四個位元可被指定的。一擴充位元組的基本格式被顯示於第4圖中。★亥 5位元組將具有一額外的擴充位元及7個計數位元。對於這此命令而言，隨後的單元含有該計數的額外最高有效位元。因此，被限制為16(24)個像素的單一個位元組命令可以以一個二位元組命令來被擴充到2〇48(2ιι)個像素、以一個三位元組命令來被擴充到262144(218)個像素以及以四個位 10 元組（應該被需要的最多位元組數）來被擴充到超過33百萬個像素。由於四個位元組應該是目前視訊色彩及視訊解析度所需的最多位元組數，所以該命令典型地被限制最多為

四個位元組。限制該命令最多為4個位元組的另一原因是為了便於能夠在一週期内將該命令寫入一個32_位元寬的 15 FIFO中。應該注意的是儘管該命令典型地被限制為四個位元組，但是如果需要，該命令可被擴充到更多位元組而不脫離本發明之範圍。第5圖顯示原始DVC命令的封包格式。 NO—CHANGE(NC)(命令=000)指定連續像素的計數自 20 前一訊框以來沒有變化，且因此可以從該前~ (參考）訊框中被複製而來。 COP Y—LEFT(CL)(命令=001)指定連續像素的計數與緊接它們左邊的像素(前一像素)相同。 COPY-ABOVE(CA)(=010)指定連續像素的計數與它 13 200814780 們正上方的像素（前一行)相同。 MAKE—SERIES(MS)H)1 丨）表序列，嗲箄德去—3 σ十數長度内的一像素示的每-像素的一資料位元指定 =了色所t 是第二指定色彩。在一實施例中，指定色伽所遇到的兩個最近的不同色彩。這;：7r色彩是一行中 10 =衫(在一資料位元被清除時被選擇)以及該序列之前 =㈣最後-像素的色彩（在1料位元被設定時被 k擇）。這可藉由使用多個資料位元來表轉—像素而很容易被擴充到-較大深度。該深度由實施定義讀由適當的 INFO命令在下游被傳遞（第1〇圖）。由於輸出保持緩衝器的大小，最大序列深度典型地是 384個位元或12個四位元組的字。這允許以2色深 \ U 384個像素、4色達192個像素、8色達％個像素等^。在此實施中’最大序列長度被限制為256。應該注意的是如果該輸出保持緩衝器的大小被增加，則該最大序列深度可被擴充。由於MakeSeries並未提供最有效的壓縮，（每位元組可被表示的像素數），所以與該等方向執行長度編碼…^、CL °及CA)相比’有時候最好終止一MakeSeries並切換至一方向編碼來取代。提前決定最好是終止該MakeSeries還是繼續，並不總是容易的。該實施例在所有操作期間，包括 MakeSeries，對連續的NC、CL及CA像素比較進行計數。該專計數值在一MakeSeries開始時被重置，且接著可能在該 200814780

MakeSeries命令所處理的每8個像素之後。一8或更多個像素的方向命令被確保不會較被附加在一MakeSeries末端的另外8個像素差。但是，如果那8個之後的下一些像素只能用被中斷的同一MakeSeries來被編碼，則 5該中斷實際上需要至少一位元組的一額外MakeSeries標頭。對於MakeSeries的中斷及隨後的重新開始，該組長度需要超過32個像素以確保最好地中斷該MakeSeries。這允許^一可能的重新開始，為大於16的一計數使用一2_位元組 MakeSeries標頭。一實施例根據一個為16的組大小來作出判決。這有了切換入及切換出MakeSeries的可能性，但由於這被預計為是非常罕見的，所以簡化應該是值得的。在MakeSeries所處理的每8個像素之後，該等方向長度將被檢查。如果任何長度為16或更長，則一方向組可能已 15處理了最後16個像素。該MakeSeries被減少ι6，且接下來的

20 方向命令被植入一個為16的開始計數。這需要基於一 MakeSeries_8_像素範圍。在每—位元組的開始清^方向性的檢查，如果它是少於8,藉由去除任何部分位元組來處理。 NEW_PIXEL命令為不能被壓縮的一系列像素指定完全色彩值。資料量料每像㈣色彩之位核數乘在此命令中被編碼的像素數。由於該演算法所需制以緩衝像素且稍後返回並填充該標頭的計數的緩衝量，所以不打算擴纽命令超過對16個像素的支援。因此，該擴充位元= 定的NEW—HXEL目前不被使用。 15 200814780 在一不範實施中，當該視訊壓縮系統100操作於7_位元色和^式中時，該NewPixel命令具有一個為1的組計數且資料的母-像素需要一NewPixd標頭單元。&簡單的標頭單兀被顯不為第5圖中的“單個像素-7，，。這對於8-位元資料可 5能產生一個冑達2乂的頻寬影響，或對於24-位元資料產生高達33%的額外負擔。因此協定允許使用一計數，藉此一= 施可選擇緩衝或延遲發送像素資料直到一計數可被決定。同樣地，對資料強加限制為16個像素減輕了緩衝需求及潛時。應该注意的是如果前一行緩衝器丨3 〇被設計具有兩個 1〇獨立的讀埠則可以提供此能力。否則將需要一個獨立的 16x24-位元fifo。由於該標頭格式，7-位元模式不支援〜⑽㈤執行或者下述之額外的差量命令。第6圖顯示額外的差量命令。第6圖所示之這些命令格 15式適用於24-位元及5-位元色彩模式。該等差量命令試圖在該等基於方向的命令失效且一無效率的NEW—PIXEL必須被發送時限制所發送的位元數。該等差量命令在假定像素可能色彩接近於其相鄰像素中之一個的情況下操作。如果該像素色彩接近於其相鄰像素中之 2〇一個，則對該相鄰像素的一簡單參考(經由命令欄位元)及一 π付號的色彩差量可將資料減少到該NEW_PIXEL命令本來所需資料的25%，而不發送該new_PIXEL。下述之該等差量命令可以指定兩像素之間的色彩差異為絕對差異（兩個24-位元數之間的4_位元帶符號差異）或指 16 200814780 定每一色彩通道的差異（每一色彩的三個4_位元差異）。如第 6圖所示，當擴充位元未被設定時(位元4中的“〇，，），單個差里值被用作目前像素與前一像素的24-位元字串之間的帶付號差異。當該擴充位元被設定時(位元4中的“1”），每〆色 5彩通道的一差量值被提供。差量值被加到來自與該目前像素相比的像素之各自值上以產生該目前像素的色彩。該等差里印々可以根據差量模式來使用帶符號的4-位元值，該等值支援卜8,7]的範圍或另一範圍。 DELTA一NC指定此像素只稍微不同於前—訊框中的相 10 同像素，即只相差特定差量。 DELTA一CL指定此像素只稍微不同於前_像素，同樣只相差特定差量。 DELTA一CA指定此像素只稍微不同於正上方的像素，同樣只相差特定差量。 15 第6圖中所示之該等差量命令是標準差量命令。如下所述，有許多差量模式。該等差量命令根據該差量模式被致能並被組配。被定義的該等差量模式被顯示於第7圖中。第6圖所示之該等差量命令是模式〇，上面所示之該標準格式每命令具有被表示的單個像素。模式4、5、8及9是 20利用了位元差量值的差量命令之實施例。模式4、5、8及 9透過差量值的範圍（即[-4,3]或[0,7])及所利用的封裝方案類型（即類型1或類型2)來被區別。類型丨及類型2被顯示於第 8圖中且為支援封裝多像素差量至單一命令的額外格式，因此減少負擔。模式4及5是類型1而模式8及9是類型2。 17 200814780 在類型1中，擴充欄位被用以識別另一像素是否緊接著。當遇到一被清除的擴充欄位時(Ext=0)，該命令已結束而目前位元組中不必要的位元（如果有）被忽略。如第8圖所示，使用類型1允許兩個像素被三個位元組表示。如果該差 5 量命令必須被發送給每一像素，則會需要四個位元組來表示兩個像素。同樣地，五個像素可以被七個位元組表示而不是十個位元組。類型2利用了第5圖中所示之不被使用的命令= 111及擴充=1。在類型2中，當命令= 111及擴充=1時，差量NC、差 10 量CL或差量CA中之一個適用。被嵌入每一像素之串流中的一個2_位元命令(Dcmd)決定該差量NC、差量CL或差量CA 中哪一個適用並取代前面格式的單個位元擴充欄位。它對於為多個方向之混合的差量的長執行特別有用。Dcmd指定下列中之一個：差量NC(00)、差量CL(01)、差量CA(10)或 15 命令終止（11)。一碰到兩個連續差量，類型2(封裝的3-位元差量）對於一個4-位元非均勻差量的字串就變成一較好的壓縮選擇。差量資料被寫入差量緩衝器，唯一需要的額外資訊是目前連續差量中之任何一個是否已超過3-位元格式。當遇到第 20 二連續差量時，作出切換至封裝的差量之判決。此時，所有隨後差量的類型與3-位元資料欄位都將需要被寫入該12-位元差量緩衝器。接著該輸出程序103可以使用目前的差量類型及連續差量來處理以進行分析並相對應地輸出差量緩衝器。 18 200814780 第7圖也顯示類似於模式〇的模式丨，除了範圍是[〇，15] 不疋[8,7]。模式1對於添加一差量值到先前被截斷色彩中是有用的。该命令程序102決定該等DVC或差量命令中哪一個可 5透過三個方向比較方塊114、116及118應用，該等方向比較方塊發送貧訊給該命令程序1〇2。該等比較方塊114、及 118亚列操作，每一個都將目前像素⑷與它們各自的參考像素相比較且如果該等像素被決定為是相等的則發送一真實(TURE)信號給該命令程序1〇2。該等比較方塊也計算每 1〇一通道的差量並發送被封裝入一 12-位元值的資訊給，例如该命令程序102使用。除了該12_位元值，一獨立差量旗標被傳遞以便指示該等被觀測的差量是否在該目前範圍中。這防止該命令程序1〇2必須解碼一個全零差量值。苐9圖顯示一示範性差量比較方塊。每一差量比較方塊 15接收兩個24_位元串（資料A[24]及資料B[24])，一個表示一目前像素而另一個表示前一像素。該等位元串被利用一24_ 位元比較器902來做比較。如果該等位元串相等，則該24-位元比較器902輸出一真實值。該示範性差量比較方塊也包括三個8-位元減法方塊904、906及908，用於從表示該前一 20像素的一 24_位元數之該等各自的8-位元色彩值中減去表示該目前像素的一 24-位元數之8-位元色彩值。來自該等減法方塊904、906及908的該四個最高有效位元被發送到12-位元反或閘910中，該12-位元反或閘決定一差量狀況是否存在，即每一色彩通道的該四個最高有效位元是否相等，即 19 200814780 相減結果是否為0000。該等減法方塊904、906及908也發送每一色彩通道的差量值（即四個最低有效位元之間的差）給該命令程序102。應該注意的是儘管該示範性差量比較方塊被組配用於一 24_位元色彩實施及在其中為每一色彩通道 5產生一位元差量值的一差量模式，但是這僅是為了達到解釋之目的且並不打算是限制性的。該領域中具有通常知識者會瞭解其他硬體組態可被用於該實施且其他硬體組態對於其他實施可能是必需的。方塊912是用於製作序列決定的可取捨的邏輯。 10 该視訊壓縮系統也具有一些序列比較方塊120及 122(沒有差量計算），其等並列操作以決定一製作序列狀況是否出現。比較方塊120及122將該目前像素與最近的唯一像素做比較且如果該等像素相等，則發送一真實(true)信號給該命令程序102。應該注意的是儘管該實施例對於該兩個隶近的像素只使用兩個序列比較器，但更多比較器可被使用。該命令程序102追蹤哪些命令（信號）是可允許的（根據一訊框内的位置等等”哪些命令仍具有有效執行以及在目前執行中有多少像素。當該命令程序1〇2決定出一執行結 2〇束，達到行末端或達到一訊框末端時，則適當的命令124與資料126被產生並被發送給輸出程序103。該命令程序1〇2也更新前一像素128及該前一行緩衝器130中的目前位置。位置被XP0S變數132及YP〇s變數134追蹤而對以像素為單位的一訊框内的水平及垂直位置進行計數。這些位置 20 200814780 被用以定址該前一行緩衝器13〇内的目前位置並決定一與訊框邊界。 ^ 該輸出程序103產生輸出ι36給該系統之剩餘部分。如果該輸出程序103不能寫或正忙著寫資料的多個片段且不 5能接受輸入，則該單元中的其他都必須等待。此獨立浐序的原因是由於輸出命令的緩衝性質。該等命令被緩衝，— 此-旦已知大小（計數），則標頭可被填充。沒有此獨立= 序，該主命令程序舰可能會花費兩倍長的時間來處理^ 素。使用此雙程序實施，兩程序以一管線方式並列操作。 10 該輸出程序103依據被需要來壓縮多個像素的位元組數在母一訊框期間追蹤壓縮性能。此比率可在每一命令後被追蹤，且當其超過一臨限值(被使用者經由一小型應用程式(applet)來定義）時，該輸出程序1〇3將通知該命令程序1〇2 需要減少色彩深度努力節省頻寬。該輸出程序1〇3將定義並 15追蹤每訊框位元組（BytesPerFrame)及每訊框像素 (PixelsPerFrame)，這二者在每一訊框末端被重置。為了避免錯誤判決，該等值實際上不被使用直到該每訊框像素指示出該程序是進入該訊框的至少一行。最可能的臨限值是對位元組/秒之數目的限制。這可被 20 轉換為以下一位元組/像素(BP)率： X位元組/秒 >=(寬度*高度）*BP*fps BP=X/(寬度*高度*fpS) 對於使用以30fps的1024x768的一最大頻寬配置，即 8MBps而言，這可能等於以下的位元組/像素率·· 21 200814780 BP 率=8Μ/(1024*768*30)=0·34 該簡單實施會使目前像素計數乘以果是否仍大於目前位元組計數。如果否且如果可能該命令程序102需要減速。這個值，然後看結 ’則該頻寬被超過 5 然而，包括一浮點乘法器可能不熹盘廿—ϋ〜认〆一疋必舄的。倒轉該比率並疋義匕為母位元組像素，允許了在 "&期望速率上具有少一點準確度的整數乘法。 10 胸8*30/购.94=3(實際上是7.咖㈣处將此比率捨入至最近的整數是傳統方法，但此做法可此放棄大量頻寬。

•該視訊壓縮系統100也可以使用“色彩減少，，來減少頻見使用I、使用者可能已經為電腦組配的基於色彩深度的作業系統設定分離。不考慮該作業系統設定該視訊壓 ^糸統儲存24·位元色彩資料。該視訊壓縮系統⑽將同 Μ樣雌記憶體中讀出24_位元色彩資料，但色彩減少將從每色π通道中移除掉__些最低有效位元(例如設定它們為零），因此增加了該_像素將看起來與料比較器ιΐ4 6及118相同的可⑯性’且也減少了被需要來發送一未壓細像素的貧料之大小。 20 /視Λ[縮系統⑽可被設計而始終操作於8或Μ.位色々1由於其需要以高解析度與訊框率來處理24 -位元補天然地處理較低色彩深度無法獲得任何好 =。这僅僅會使該實施由於預計罕見的東西而複雜化。如果它是唯—域較高解析度的方式，則它可能是所想要的。 22 200814780 它對於不打算支援24-位元色彩的一實施例也可能是所想要的，但此實施可能需要對該視訊壓縮系統1〇〇做出整體改變以使效能最佳化而使閘總數及成本最小化。除了作業系統及天然的色彩深度，還有一對與色彩深 5 度有關的其他用語。“比較深度，，是在比較兩個色彩時被用以描述所使用的最高有效色彩位元數（每色彩通道）的用語。還有該子系統的目前色彩深度（非自然深度），其為該視訊壓縮系統1〇〇參考“色彩深度”時所參照的。該比較深度不必與該色彩深度相同。例如，比較可以以15-位元色彩來被 10 執行（每通道5個位元），而24-位元像素可經由該等差量及 NEW__：PIXEL命令被發送。這將產生稍微多於螢幕上可能顯示的215個色彩，但稍微改變了一些相鄰色彩而將減少色彩逼真度。優點就是該壓縮憑藉寬鬆的相等需求而可能被改善。有效的色彩深度（ColorDepth)值被視訊協定的位元組 15 性質限制如下：24-位元、15-位元及7-位元。可被用以改善壓縮的比較深度為：3、6、9、12、15、18、21及24。該深度每通道可被變化。比較邏輯所使用的比較深度被保留在比較深度 (ComparisionDepth)暫存器中。這指定單個通道的深度且被 20用以產生一個遮罩，該遮罩被用於被饋送入比較器源暫存器的每一像素。色彩深度暫存器控制該輸出程序1〇3如何建構 NEW_：PIXEL命令及該系統的剩餘部分中的邏輯如何操作。如果該色彩深度被設定為24-位元或15-位元模式，則該 23 200814780 NEW—PIXEL命令以一 8_位元標頭（支援達16個像素)及每像素24-位元（或15-位元）的色彩資料來被建構。對於一個為7的色彩深度，DVC演算法典型地已使用色彩範圍的一特殊映射。這在此偏愛色彩遮罩的目前實施中 5未被執行。取而代之的是，7個位元被使用，其中每2-位元用於紅色及藍色而3個位元用於綠色。由於與紅色或藍色相比，人眼較易於檢測到綠色及細微的陰影變化，所以綠色一般在數位成像色彩格式中受喜愛。這產生了一個位元協定，其中一NEWJPIXEL以單個位元標頭及每像素7_位元 10 的色彩資料來被建構。色彩深度及比較深度暫存器這二者都是可由使用者組配的狀態之一部分。預設可經由跨接線或硬編碼入硬體而被控制。使用者應該能夠經由一小型應用程式而直接或間接調整這些，該小型應用程式讓它們調整頻寬等等。此小 15型應用程式透過該控制單元102與該硬體進行通訊。當這些值被設定時，必須確保該視訊子系統是閒置的或者該等值必須被分級，藉此不會做出改變直到該視訊子系統能夠處理變化。該視訊壓縮系統100需要知道像素深度(位元數)及訊框 20 大小（以像素表示的高度及寬度）以考量行寬以及在一行或訊框之末端可能必需的任何填充（padding)。由於 COPY—ABOVE對於一訊框之第一行可能被關閉而 COPY_LEFT對於每一行之第一像素可能被關閉，所以該視訊壓縮系統100也必須知道每一訊框的開始。 24 200814780 要注意此特定實施並沒有壓制COPY_ABOVE或 COPY—LEFT ’而是分別與前一訊框的最後一列或前一行的最後一像素相比。如果一時序變化而引起在一結束訊框：清除訊息之後重新開始，則左邊及上方與黑像素值 5 0x000000做比較。第10圖顯示被產生於該命令程序102處的控制命令。控制命令需要與該等編碼命令被區分開。控制命令透過以下事實來被辨識：最低的5個有效位元全為〇(表明一零計數) 而最高有效位元是空白（clear)(表明其為一個需要一計數的 10 命令)(對具有色彩的差量或新像素命令）。第10圖所示之該組控制命令按照具有子標頭位元組的 INFO—HEADER來被分組，該子標頭位元組指定類型及類型的值。類型在第10圖所示之該表中被定義。值對於每一類型都是特定的，但一般是緊接在比此2_位元組標頭長的命 15令之標頭（不包括該2_位元組標頭）之後的位元組數。對於只由此標頭之兩個位元組所組成的命令而言，值為一個扣位元資料值。第11圖顯示每一類型的INFQ_HEADER。該色彩深度命令被用以指定色彩模式。目前，24_位 20元、15、位元及7·位元色彩模式在此實施中被支援。色彩深度核式被疋義於第n圖中。色彩深度經由一組態暫存器被提供給該視訊壓縮系統100而不是透過訊息串流進入。應^ 注意的是儘管該實施例只定義了三個色彩模式，但在^ 更多色彩模式可被定義而不脫離本發明之範圍。 25 200814780 第12圖所示之序列深度（SERIES_DEPTH)命令被用以指定用於在一序列命令中識別每一像素之色彩的位元欄位的寬度。預設深度是1，這允許由2個色彩所構成的序列。所支援的最大深度按照實施而變化，但在該較佳實施例 5 中，4個位元（16個色彩）的深度是想要的最大值。差量模式(DELTA—MODE)指定被用於所有後面命令的差量模式。後面沒有資料位元組。清除—訊框（CLEAR_FRAME)命令被用以指示前一訊框要被清除為零，或至少下一訊框應該與全零相比而不是 10 前一訊框的内容。比較深度(COMPARISION—DEPTH)命令被用以控制像素相互比較時所使用的位元數。這是以位元/通道來被指定。比較深度經由一組態暫存器被提供給該視訊壓縮系統 100而不是透過訊息串流進入。 15 訊框狀態（FRAME-STATUS)命令被用以傳輸一訊框的狀態，表示成功完成或需要中止進一步處理目前訊框。狀態欄位元為0指示成功而1指示需要中止。第13圖顯示訊框—大小(FRAME_SIZE)命令。訊框寬度 (Frame Width)及訊框高度（FrameHeight)以像素指定後面訊 20 框的維度，範圍從〇變化到65,535。實施一般將具有一較小的最大支援值，依據應用，等級等於或小於4000。每像素位元（BitsPerPixel)指定被用以定義每像素的色彩的位元數。這典型地在等於或小於24個位元之範圍中，儘管將來較大深度是可能的。對於此實施，這被固定為24-位元。 26 200814780 此訊框大小訊息的唯一目的就是要較快地傳輸該訊框大小資訊給鏈結另一端的視訊解壓縮單元（VDU)(未被顯示）。此單元典塑地聚集來自時序訊息的幾段不同的資料以備位於該鏈結之遠端的DVI輸出單元使用。將所有資訊封裝 5 在此訊息中（其與該VDU相結合)允許該VDU忽略該等時序訊息。遠訊框大小命令的爛位被定義如下：像素時鐘：此命令被用以發送為在該鍵結的另一端顯示而重新產生一像素時鐘所需的值。水平時序：此命令被用以發送水平顯示時序值給該鏈 10 結的另一端。垂直時序：此命令被用以發送垂直顯示時序值給該鏈結的另一端。弟14圖顯示一個一般的資料封包。此一般目的的資料封包被用以透過該鏈結傳送資料。假設該鏈結的另一端可 15 以分析該資料。應该注意的是在一整個訊框可被編碼為一個無變化 (NoChange)訊息時獲得最大壓縮。然而，在該實施例之雙緩衝架構中，此編碼會在該視訊壓縮系統1〇〇開始處理一訊框與該VDU開始接收該處理的結果之間產生一整個訊框時 20 間的潛時（等級為16ms)。取代讓一執行長度命令建立在該整個訊框内的是，該等命令被限制大小並在該整個訊框内被週期性發送。為了簡化，這被執行於每一行的末端處。如果絕對效能變得比潛時更重要，則這可以以多種方式被微調。 27 200814780 應該注意的是由於數位輸入單元(DIU)(未被顯示）之架構’该視訊壓縮系統1〇〇在接收到指示解析度正在變化的資訊時可能已經在處理一訊框。此資訊將是清除位元被設定的一結束訊框訊息之形式。 5 ^該視訊壓縮糸統1 〇〇完成一訊框時，它應該在其進入的FIFO中看到具有一個〇清除位元的一結束訊框訊息。如果它反而在其FIF 0之前看到具有清除位元的一結束訊框訊息或任何時序訊息，則它知道前一訊框（它剛剛結束處理的訊框）無效。接著該視訊壓縮系統100發送一訊框中止 10 (FrameAbort)訊息給該VDU以指示該前一訊框不應該被顯示。如果該進入的FIFO中沒有任何訊息，則該視訊壓縮系統1〇〇等待直到出現一個。如果該解析度已降低，則該視訊壓縮系統1〇〇將已經嘗斌從記憶體中讀出遠遠大於實際上記憶體將能夠提供的。 15該記憶體介面單元(MIU)107確保該視訊壓縮系統100讀指標跟在該DIU寫指標之後，藉此該視訊壓縮系統1〇〇不會超過所寫的資料。DVI 104資料到記憶體1〇6的提早終止將意味著該DIU寫指標將拖延而暫停一段時期，使得該視訊壓縮系統100也拖延以等待資料。當該記憶體介面單元1〇7決定 20終止該請求時，它將僅僅中止該視訊壓縮系統100的讀請求處理。该視机壓細糸統100必須不停地監測其進入的命令 FIFO，同時處理來自圮憶體106的像素。如果該視訊壓縮系統100看到來自該DIU的一個結束訊框、清除或垂直時序訊 28 200814780 息’則它立即終止處理目前訊框並發送訊框中止訊息給該 VDU。該視訊壓縮系統1〇〇也立即發送一清除訊框（pur^

Frame)訊息給該MIU 107。此訊息告訴該MIU 107停止發送目前在進行中的訊框的進一步資料給該視訊壓縮系統 5 1〇0。隨後該MIU 107將清除自該DIU中被讀出的剩餘的任何資料。該視訊壓縮系統1〇〇在通知該MIU 1〇7停止增加目前及前一FIFO之後負責將它們清除。該視訊壓縮系統1〇〇每時鐘需要處理一像素，其中每訊框潛日守的等級為幾個像素且像素之間沒有潛時。這主要取 10決於該記憶體控制器106能夠以必需的速率來提供輸入資料，也取決於輸出不阻塞且迫使一延遲。叙疋滿足上述準則且每時鐘一像素可被處理，則時鐘率是基於每訊框的像素數及所期望的訊框率。第15圖中的表顯示了各種組合所需的速率。 15 允终一些負擔，該表顯示一個80MHz的核心時鐘對於 30fps HDTV可能足夠了。一較可能的目標可能在等級 100-125MHZ之間’其甚至可處理3〇如的qXga且可支援超過40fps的HDTV。雖然很高訊框率的很高解析度可能需要太高的一時鐘率而在«上/經濟上科行，但是處理速率 20及成本方面的發展實際上將使得甚至於那些很高的解析度及訊框率也能夠以經濟上可行的現成產品來被實施。同樣地，現今為商業/經濟合理之界線的時鐘率使用現成產品將很快在經濟上可實行。能夠以速率為6Gfps壓縮單個訊框，改善了終端使用者 29 200814780 所感知到的潛時，且因此是一個值得的目標，即便訊框被有意丟棄或每秒不被發送60次。雖然已結合目前被視為最可實施且較佳實施例對本發明進行了描述，但要理解的是本發明並未被限制到該所揭 5 露之貫施例5相反的’其意在涵盖被包括在附加申請專利範圍之精神與範圍内的各種修改及等效配置。 L圖式簡單說明3 第1圖係一示範性視訊壓縮系統；第2圖係一示範性輸入訊息單元格式； 10 第3圖係一示範性讀命令單元格式；第4圖係一示範性編碼標頭單元格式；第5圖係原始DVC命令的示範性8-位元單元；第6圖係差量命令的示範性8-位元單元；第7圖係示範性差量模式； 15 第8圖係包括示範性差量模式的單元；第9圖係一示範性比較方塊；第10圖係示範性命令單元格式及命令表；第11圖係示範性色彩深度命令單元及色彩深度模式表；第12圖係示範性命令單元； 20 第13圖係示範性多位元組命令單元；第14圖係一示範性命令資料單元；及第15圖係示範性核心時鐘率表。 30 200814780 【主要元件符號說明】 100.. .視訊壓縮系統 101…輸入訊息 102.. .命令程序 103…輸出程序 104…數位視訊輸入單元 105…訊息介面 106.. .記憶體控制器/記憶體 107…記憶體介面單元 108·.·讀命令

110…目前資料FIFO

112.. .前一資料FIFO 114〜118...方向比較方塊 120〜122...序列比較方塊 124···命令 126…資料 128.. .前一像素 130.. .前一行緩衝器 132.. .XPos 變數 134.. .YPos 變數 136.··輸出 902.. .24.位元比較器 904〜908... 8-位元減法方塊 910.. . 12-位元反或閘 912.. .可取捨的邏輯方塊 31 200814780 <序列表〉 #define MAX_FRAME_WIDTH 2048 #define MAX_FRAME_HEIGHT 1536

#define MAX_LINE_BUFFER_SIZE MAX_FRAiyiE_WIDTH #define MAX_SERIES_LENGTH 360 #define MAX_SERIES_DEPTH 2 #define MAX_PIXEL_RUN 15 #define 〇UTPUT_FIF〇_SIZE 17 10 15 #define MESSAGE_START_FRAME 1 #define MESSAGE_END_FRAME 2 #define MESSAGE_H〇RIZ〇NTAL_TIMING 4 #define MESSAGE_VERTICAL_TIMING 5 #define MESSAGE PIXEL CLOCK RATE 6 20 25 30 #define COLOR_DEPTH_MODE_24 8 #define COLOR_DEPTH_MODE_7 7 #define COLOR_DEPTH_MODE_15 5// // Compression Commands// #define CMD_NC 0x0 #define CMD_CL 0x1 #define CMD_CA 0x2 #define CMD_SERIES 0x3 #define CMD_DELTA_NC 0x4 #define CMD_DELTA_CL 0x5 #define CMD_DELTA_CA 0x6 #define CMD NEW PIXEL 0x7 35 40 #define CMD_DELTA_NC_UNIF〇RM Oxc #define CMD_DELTA_CL_UNIF〇RM Oxd #define CMD DELTA CA UNIFORM Oxe #define INF〇_HEADER 0x20 #define FRAME_SIZE_HEADER 0x85 #define FRAME_STATUS 0x50 #define CLEAR FRAME 0x30 #define FRAME_STATUS_OK 0 #define FRAME STATUS ABORT #def ine MEMORY TIMEOUT 100000000 / / on the ordei: of one second? #define MAX_ENCODE_COUNT MAX_FRAME_WIDTH; 32 45 200814780 uint24 uint24 uint24

LineBuffer[MAX LINE_BUFFER_SIZE];

CPixelFIFO PPixelFIFO

[MEMORY+OUTPUT+FIFO+DEPTH] ,-ΓΜΕΜΟΗΥ+ΟυΤΡυΤ+ΡΙΡΟ+ϋΕΡΤΗ] ; 5 uint8 工nFIFQ [8]; struct MemFIF〇_s { uint13 width; uint13 height； 10 uint2 previousBuffer； uint2 currentBuffer； uint2 command； } MemFIFO[4]； 15 struct CmdFIF〇_s { uint8 command； uint24 data; } CmdFIFO[4]; 20 uint32 〇utFIF〇[〇UTPUT_FIF〇_SIZE]; uint24 DataFIFQ [15] ; / / This provides space for up to 15 pixels, // or 3 6 0 bits worth of series data. 25 // // Do we need to stage frame parameters (height, width, series // depth, etc) or are the processes in sync enough to just stall // the whole VCU pipe momentarily when a parameter changes? // 30 struct Header { uint4 data; uint1 extend； uint3 type; }； 35 uint16 FrameHeight； uint16 FrameWidth； uint1 ClearFrame； uint4 ColorDepthMode； // current color depth output 40 uint4 Feedback； // register used to provide feedback from the output // process to the command process. // // The following are configuration registers 45 // uint4 InitialColorDepthMode; // controls color depth output uint24 ComparisonMask； // controls comparison depth uintl6PBRatio; // controls color depth throttling (0 disables) 33 200814780 5 10 15 20 25 30 35 40

Command Process uint2 CurrentBuffer； uint2 PreviousBuf fer； uintl ClearFrame； uint13 FrameWidth； uint13 FrameHeight； uint2 4 Compari sonMask； uint4 ComparisonDepth； uint2 SeriesBitWidth； uint2 CurrentSeriesMatch； uint2 PreviousSeriesMatch； uint4 ConsecutivePixels； uint10 EncodeCount； uint8 SeriesDataCount； uint2 4 SeriesData； uint4 SeriesRun； bool FramestatusPending； bool FramesizeChanged； typedef struct { boolean equal; boolean delta; boolean uniform； uint12 value; } cmpStruct; void OnReset(){ PreviousBuf fer = 0； CurrentBuf fer = 0； ColorDepthMode = COLOR_DEPTH_MODE_24; Compari sonMask = Oxffffff； Compari sonDepth = 8； ClearFrame = TRUE； FrameWidth = 0； FrameHeight = 0； SeriesBitWidth = 1； FrameStatusPending = FALSE; Frames i zeChanged = FALSE; Feedback = 0； 45 50 void Forever (){ uint8 message； while (InFIFO empty) ;// spin Read message from InFIFO; switch ( (message > > 4) 8c Oxf) { case MESSAGE_START_FRAME: if (FrameStatusPending) SendFrameStatus(FRAME_STATUS_OK)； 34 55 200814780 if (ColorDepthModeChanged | ComparisonMaskChanged) SendModelnfo()； if (FrameSi zeChanged)

SendFrameSize()； 5 ProcessFrame(message)； break； 10 15 case MESSAGE_H〇RIZ〇NTAL_TIiyiING: case MESSAGE_VERTICAL_TI1VIING: case MESSAGE_PIXEL_CL〇CK_RATE: if ( FramestatusPending)

SendFrameStatus(FRAME_STATUS_ABORT)； ForwardMessage(message)；

FrameSi zeChanged = TRUE； break；

case MESSAGE_END_ FRAME : if (message & Oxf ) ClearFrame = ：TRUE; 20 else ClearFrame = ：FALSE if (ClearFrame & FramestatusPending)

SendFrameStatus(FRAME_STATUS_ABORT)； 25 else if ( FramestatusPending)

SendFrameStatus(FRAME_STATUS_OK)；

Flush byte from 工nFIFO; 30 35 40 // // Send a ClearFrame command over the link// if (ClearFrame) { while (CmdFIFO is full) ;// spin Write CLEAR_FRAME to CmdFIFO; } _ break; default：// // unrecognized header, Error.// Flush byte from 工nFIFO; break； 35 45 200814780 void ForwardMessage(uint8 message){ uint8 data; uint16 snoop = 0； int count = message & Oxf； int type = (message & Oxf 0) > > 4; 10 15

Flush byte from 工nFIFO; for (int b = 0; b < count； b++) { Read data from 工nFIF〇； while (CmdFIFO is full) ；// spin Write data to CmdFIFO; snoop = (snoop < < 8) | data； if (b == 1) { 20 25 // // snooped frame size ready// if (type == MESSAGE_H〇RIZ〇NTAL_TIiyiING) FrameWidth = snoop > > 3; else if (type == MESSAGE_VERTICAL_TIMING) FrameHeight = snoop >> 3;} Flush byte from 工nFIFO; 30 35 bool ResolutionChange(){ if (工nFIFO not Empty) { uint8 data; uint4 peek; Read data from 工nFIFO; // do not flush! peek = (data >> 4) Sc Oxf; if ( ( (peek == MESSAGE_END_FRAME) && (data & 0x1)) (peek == MESSAGE_VERTICAL_TIMING)) { 40 // // Stop ! Resolution has changed. // Forward an Abort message to the VDU // and abort the current frame processing. 45 50 //

SendFrameStatus(FRAME_STATUS_ABORT)； return ( TRUE )； return ( FALSE)； 36 200814780 void ProcessFrame(message)

MemRequest request； 5 // // 工nit some frame specific variables //

CurrentSeriesMatch = 0; 10 PreviousSeriesMatch = 0;

ConsecutivePixels = 0；

EncodeCount = 0；

SeriesDataCount = 0；

SeriesData = 0； 15 SeriesRun = 0; / / / f ///.1 20

Reset mode to that selected initially. (ColorDepthMode !=工nitialColorDepthMode) {

ChangeColorDepth(0)；

ColorDepthMode =工nitialColorDepthMode; 25

CurrentBuffer = (message & OxfO) >> 4;

PreviousBuffer = 1 - CurrentBuffer； // 2-buffer specific // // 工ssue a read request to memory for the relevant frame 30 // information. // while (MemFIFO·FULL) ;// spin 35 request.CurrentBuffer = CurrentBuffer； request.previousBuf fer = PreviousBuffer; request. width = FrameWidth； request. height = FrameHeight；

Write request to MemFIFO； 40 // // Now wait for the requested data to show up and then // proceed to process it. // Note： This does incur a startup delay on each frame of 45 // compression waiting f〇r memory FIFOs to be ''primed77 . // uint16 x, y； for (y = 0； y < FrameHeight； y++) { 50 for (x = 0; x < FrameWidth； ) { if (Feedback != 0)

PendingChange = TRUE； 55 if (ResolutionChange()) return； 37 200814780 10 15 20 25 30 35 40 // // Spin waiting for data from memory. Keep an eye out for // incoming messages indicating a resolution change and // the need to abort the current frame processing. // uint32 time = 0; while (CurFIFO. empty | | PrevFIFO. empty) { CheckForResolutionChange()； if (ResolutionChange()) { return；

CurPixel = data from CurFIFO; OldPixel = data from PrevFIFO; LinePixel = LineBuffer[x]； if (ProcessPixel(x,y)) { // // update line buffer and previous pixel // LineBuffer [x] = CurPixel; PrevPixel = CurPixel； // // Update the Series Pixels if series is not // active. CurrentSeriesMatch will have been // set to zero if series is still active, otherwise // CurrentSeriesMatch will be the index of the // matching entry. If no match, it will be the // index of the oldest entry which will cause all // entries to shift. // if (CurrentSeriesMatch != 0) { for (i = CurrentSeriesMatch； i > 1; i - -) { sPixel [i] = sPixel [i - 1]; } sPixel [0] = CurPixel； } x + + ;

Flush pixel from CurFIFO and PrevFIFO; } if ( PendingChange) { 45

ChangeColorDepth(Feedback)；

Feedback = 0；

ClearFrame = FALSE;

FramestatusPending = TRUE； 38 50 200814780 // // Global inputs to ProcessPixel are： 5 10 15 // CurPixel 一 the output of the CurPixel FIFO from Memory // OldPixel — the output of the OldPixel FIFO from Memory // PrevPixel - the previous pixel register // LinePixel - the pixel read from Line Buffer // bool ProcessPixel(uint16 x, uint16 y) { uint12 deltaValue； boolean currentPixelProcessed = TRUE; unsigned command； bool endHere = FALSE; uint6 startRL = 0; int MSTerminate = 0； cmpStruct frameCmp, lineCmp, pixelCmp； bool seriesCmp [1VIAX_SERIES_DEPTH]; 20 if (ClearFrame) { if (y == 0)

LinePixel = 0； if ((x == 0) ScSc (y == 0))

PrevPixel = 0； 25 OldPixel = 0； // // The following Cmp* logic blocks all operate in parallel 30 // processing a pixel each clock // pixelCmp = CmpDelta(CurPixel, PrevPixel); lineCmp = CmpDelta(CurPixel, LinePixel); frameCmp = CmpDelta (CurPixel, OldPixel); 35 for (uint5 i = 0; i < MAX_SERIES_DEPTH; i++) seriesCmp[i] = Cmp(CurPixel, SerPixel [i]); if (ClearFrame) pFActive = FALSE; 40 45 50 // // Initialize the default command as the leading // contender of active commands in case run terminates here. // if (pFActive) command = CMD_NC； else if (pPActive) command = CMD_CL； else if (pLActive) command = CMD__CA ； else if (SActive) command = CMD_SERIES; else command = NULL; 39 55 200814780 // Adjust current state of active encodings based on inputs // pFActive = pFActive Sc f rameCmp . equal ； pLActive = pLActive Sc lineCmp . equal ； pPActive = pPActive & pixelCmp. equal； sActive = sActive & (seriesCmp [ 0] | ... | seriesCmp[SeriesDepth])；

20

If Series is still active, determine which pixel in the series matches the current pixel. (sActive) { uint2 serNum； for (serNum = 0; (seriesCmp[serNum] == 0) && serNum < SeriesDepth； i + +) if (serNum == SeriesDepth) 1;

CurrentSeriesMatch = SeriesDepth else

CurrentSeriesMatch = serNum； 25 30 // // // // // if 35 40 45

Determine the leading delta contender, if any. Uniform deltas take precedence, followed by no: in the order： frame, line, pixel. (f rameCmp. uniform) { deltaType = CMD_DELTA_NC | 0x8; deltaValue = f rameCmp. value； else if (pixelCmp. uniform) { deltaType = CMD_DELTA_CL | 0x8; deltaValue = pixelCmp. value； else if (lineCmp. uniform) { deltaType = CMD_DELTA_CA | 0x8; deltaValue = lineCmp. value； else if (frameCmp. delta) { deltaType = CMD_DELTA_NC; deltaValue = f rameCmp. value； else if (pixelCmp.delta) { deltaType = CMD_DELTA_CL； deltaValue = pixelCmp. value； else if (lineCmp. delta) { deltaType = CMD_DELTA_CA; deltaValue = lineCmp. value； else { deltaType = NULL； deltaValue = 0； -uni form 40 50 200814780 // // See if any of the directional encodings are still active // and legal. // 5 if ( (pFActive || (pPActive ScSc ( (x ! = (FrameWidth - 1)) | | CopyLef tWrap) ) | | (pLActive ScSc (yPos !=〇))) { g 10 15 20

EncodeCount ++;// // We're de-activating series if ANY runs are possible // to avoid having to track the order of pixels within // a series command.// sActive = FALSE; if (EncodeCount == MAX_ENCODE_COUNT) endHere = TRUE； } else if (sActive && (PendingChange == 0)) { // // Series is the only active command. 25 30 35 40 // Accumulate series bits internally until they exceed // internal limits, then write to the output series buffer // Series count should always be internal, so therefore has // a max of 2A25 pixels. . . more than enough. //

EncodeCount ++；

SeriesData = (SeriesData << SeriesBitWidth) |

CurrentSeriesMatch；

SeriesDataCount += SeriesBitWidth； // // Keep track of RL counts while in series // if ( frameCmp·equal) MSRunNC++; else MSRunNC = 0； if (lineCmp. equal) MSRunCA++； else MSRunCA = 0； if (pixelCmp. equal) MSRunCL++； else MSRunCL = 0； 41 45 200814780 // // When series is at a boundary, check runs // if (EncodeCount Sc 0x7) == 0) { 5 MSTerminate = 〇; if (MSRunNC < 8) MSRunNC = 〇； if (MSRunCL < 8) MSRunCL = 〇； 10 if (MSRunCA < 8) MSRunCA = 〇； if (MSRunNC == 16) MSTerminate |= 0x1 ; if (MSRunCL == 16) 15 MSTerminate |= 0x2 ; if (MSRunCA == 16) MSTerminate I = 0x4 20 if (MSTerminate) { // this command // It's beneficial to terminate the series at // point and replace with an active Run Length 25 // endHere = TRUE;

EncodeCount -= 16;

SeriesDataCount = 0; startRL = 16; 30 } else if (EncodeCount == MAX_SERIES_LENGTH) { endHere = TRUE； } if ((SeriesDataCount == 24) { 35 // // write 24-bit SeriesData out // while (DataFIFO·FULL) 40 ； // spin write SeriesData to DataFIFO;

SeriesData = 0；

SeriesDataCount = 0； } 45 CurrentSeriesMatch = 0; } else { endHere = TRUE; } 42 50 200814780 5 10 15 20 if (endHere | | PendingChange) { // // Run is terminating (or never started) // if (EncodeCount == 0) { // // Run never started, output pixel or delta // if (deltaType != NULL) { FinishPendingPixels()； WriteCommand (deltaType, deltaValue)； } else { while (DataFIFO. FULL) ；// spin Write curPixel to DataFIFO； ConsecutivePixels++； if (ConsecutivePixels >= MAX_ PIX E L_RUN) { WriteCommand(CMD_NEW_PIXEL, ConsecutivePixels)； ConsecutivePixels = 0； 25 30 35 40 } else { // // Run has terminated, either because encoding // failed, or end condition reached. // if (not about to do a NewPixel) FinishPendingPixels () ; // flushanyDataFIFOpixels if (SeriesDataCount & (command == CMD_SERIES) ) { // // flush any pending series data to the DataFIFO // while (DataFIFO·FULL) ;// spin Write SeriesData to DataFIFO； SeriesData = 0; SeriesDataCount = 0； 45 currentActive = pFActive | pLActive | pPActive | sActive； if (currentActive == 0) { // 50 // Encoding failed on this pixel, and therefore // the current command does not include this pixel. // Output command for previous encoding which // was initialized on entry to this function //

WriteCommand(command, EncodeCount)； currentPixelProcessed = FALSE; 43 55 200814780 } else { // // run terminated due to end of line, frame, etc . // Pick command based on current active encoders. // if (pFActive) command = CMD_NC； else if (pPActive) 10 15 command = CMD_CL； else if (pLActive) command = CMD_CA； else if (sActive) command = CMD_SERIES;

WriteCommand(command, EncodeCount)； 20 25 30 if (startRL != 0) { pFActive = pLActive = pPActive = sActive = FALSE; if (MSTerminate & 0x1) pFActive = TRUE； if (MSTerminate & 0x2) pLActive = TRUE; if (MSTerminate & 0x4) pPActive = TRUE; EncodeCount = startRL； } else pFActive = pLActive = pPActive = sActive = TRUE; return (currentPixelProcessed)； } 35 void ChangeColorDepth(uint4 feedback) { uint8 data [2]； 40 45 50 if (feedback == 0) ColorDepthMode if (feedback == 1) ColorDepthMode else ColorDepthMode

COLOR_DEPTH_ COLOR_DEPTH_ COLOR DEPTH

data [0] = INF〇_HEADER; // 40 data [1] = COLOR DEPTH HEADER for (int index = 0; index < 2; while (CmdFIFO FULL) ;// spin Write data[index] to CmdFIFO; MODE_24; MODE_15; _MODE_7; ColorDepthMode； index++) { 44 55 85200814780 void SendFrameSize() 10 uint8 data[6]; data[0] = INF〇_HEADER; // 40 data[1] = FRAME_SIZE_HEADER; // data [2] = FrameHeight & Oxff; data [3] = (FrameHeight & OxffOO) data [4] = FrameWidth & Oxff; data [5] = (FrameWidth & OxffOO) data [6] = ColorDepth； //???? > > 8 ; > > 8 ; 15 for (int index = 0; index < 7; index++) { while (CmdFIFO FULL) ；// spin Write data [ index] to CmdFIFO,· 20 void SendFrameStatus(uint4 status){ uint8 data[2 ]； data[0] = INF〇_HEADER; // 40 data [1] = FRAME_STATUS | status; 25 30 void for (int index = 0; index < 2; index++) { while (CmdFIFO FULL) ；// spin Write data[index] to CmdFIFO;} FramestatusPending = FALSE; SendModelnfo() uint8 data [ 6]；

35 data [ 0] data [ 1] data [2] data [3]

=INF〇_HEADER; // 40 =COLOR_DEPTH_HEADER =INF〇_HEADER; // 40 =SERIES DEPTH HEADER

ColorDepthMode； SeriesDepthMode； 40 data[4] = INF〇_HEADER; // 40 data [5] = C〇MPARIS〇N_DEPTH_HEADER | ComparisonDepth; for (int index = 0; index < 6； index++) { while (CmdFIFO FULL) ;// spin

Write data[index] to CmdFIFO; 45 45 200814780 cmpStruct CmpDelta( PIXEL cur, PIXEL ref) { cmpStruct cd； uint8 diffred, diffgreen, diffblue; cur = cur & ComparisonMask； ref = ref & ComparisonMask； 0 10 15 20 diffred = cur. red - ref . red； dif fgreen = cur . green 一 ref . green； diffblue = cur . blue - ref . blue； if (cur == ref) cd. equal = TRUE； else cd. equal = FALSE; if ((diffred > MAX_DELTA) || (diffred < MIN_DELTA) || (diffgreen > MAX_DELTA) || (diffgreen < MIN_DELTA) (diffblue > MAX_DELTA) | | (diffblue < MIN_DELTA) ) { cd. delta = FALSE; cd. uniform = FALSE; } else { cd. delta = TRUE; 25 30 if ((diffred == diffgreen) && diffgreen == diffblue)) cd. uniform = TRUE; else cd. uniform = FALSE; 35 cd. value = (diffred Sc Oxf) | ((diffgreen Sc Oxf) < < 4) | ((diffblue & Oxf) < < 8); 40 boolean Cmp(PIXEL cur, PIXEL ref) { cur = cur & ComparisonMask； ref = ref & ComparisonMask； if (cur == ref) return(TRUE)； 45 else return ( FALSE)； 50 void FinishPendingPixels() { if (ConsecutivePixels) { WriteCommand(CMD_NEW_PIXEL, ConsecutivePixels)； ConsecutivePixels = 0； 46 55 200814780 void WriteCommand(uint8 command, uint24 count) { if ( (command != CMD_NEW_PIXEL) && ConsecutivePixels) FinishPendingPixels()； if ((command == CMD SERIES) && SeriesDataCount) // 10 // flush any pending series data to the DataFIFO// 15 while (DataFIFO·FULL) ；// spin Write SeriesData to DataFIFO; SeriesData = 0； SeriesDataCount = 0； 20 // // Write command to Command FIFO for output processing// uint3 2 data = (command < < 24) | count; while (CmdFIFO FULL) ;// spin Write data to CmdFIFO; 25 void ForwardMessage(uint8 header) 30 uint8 data; uint4 count = header . count； \ 35 40 while (CmdFIFO FULL) ;// spin write header to CmdFIFO; while (count) { Flush byte from InFIFO; while (InFIFO empty) ;// spin Read data from InFIFO,· while (CmdFIFO FULL) ；// spin Write data to CmdFIFO; 45

Flush byte from InFIFO; 47 200814780

Output Process «define MINIMUM_：PIXEL_THR〇TTLE 1024 // Minimum number of pixels that // have to be processed for a frame // before contemplating throttling 5 // back on the color depth. uint4 Mode; void OnReset() { 10 Mode = InitialColorDepthMode;

BytesPerFrame = 0；

PixelsPerFrame = 0； } 15 void Forever () {

CmdFIFO_s message; 20 25 30 35 40 while (CmdFIFO is empty) ;// spin Read message from CmdFIFO; if (message == INFO_HEADER) {// // For informational messages, process the // second byte.// Flush message from CmdFIFO； while (CmdFIFO is empty) ;// spin e from CmdFIFO; Read messag ProcessINFO(message)； return；} switch(message . command) { case CMD_NC： case CMD_CA: case CMD_CL:// // Output an encoded compression command // up to 32-bits per clock. The entire command // is included in this message.// OutputCommand(message . command, message . data)； break; 48 45 200814780 case CMD DELTA*: 5 10 15 20 25 30 35 // // output a single delta command, contained // entirely in this message.// OutputDelta(message . command, message . data)； break； case CMD_NEW_PIXEL:// // output a pixel per clock // The first output consists of the command byte // and the first pixel. The subsequent data // is pulled from the Pixel Buffer // OutputPixels(message . data)； break; case CMD_SERIES:// // output up to 32-bits per clock // consisting of up to 32-bits of incoming command // followed by data from the Series Buffer// OutputSeries(message . data)； break; default： break；} Flush message from CmdFIFO; if ((PBRatio != 0) && (PixeIsPerFrame > MINIMUM一PIXEL_THR〇TTLE) && ((BytesPerFrame ★ PBRatio) > PixelsPerFrame) && (Feedback ==〇)){ 40 // // Need to try and throttle back the color depth // if (Mode == COLOR_DEPTH_MODE_24) 45 Feedback = 1； else if (Mode == COLOR_DEPTH_MODE_15)

Feedback = 2； } } 49 50 200814780 void Processlnfo(uint8 message) 10 15 20 25 30 // // First, output INFO header and sub-header// while (OutFIFO FULL) ；// spin Write INF〇_HEADER to OutFIFO; Write message to OutFIFO； Flush byte from CmdFIFO;// // Then read and output each byte of info// int count = message & Oxf； for (int index = 0; index < count； index++) { Read data from CmdFIFO; while (OutFIFO FULL) ;// spin Write data to OutFIFO,· Flush byte from CmdFIFO; }// // Now do any local processing required// switch( (message & Oxf 0) > > 4) { case FRAME STATUS : // 1 // This allows a // 35 BytesPerFrame = break； place for the output process to see EOF 0; // reset this here. case COLOR DEPTH: 40

Mode = message & Oxf; break； 50 200814780 void OutputCommand(uint8 header, uint24 count) { uint3 2 data; uint4 shift = 8; 5

PixelsPerFrame += count; data = (header < < 0x5) | (count & Oxf); count = count >> 4; 10 if (count) data I = 0x10；

BytesPerFrame ++; while (count) { 15 data |= ( (count Sc 0x7 f) < < shift)； count = count > > 7; if (count) data |= (0x8 0 < < shift)； shift += 8； 20 BytesPerFrame ++; } // // The following data should be written at up to 32 25 // in a single clock. // while (OutFIFO FULL) ；// spin write data to the OutFIFO,· 30 } 51 200814780 void OutputPixels(uint4 count) uint2 4 data2 4； 5 10 15 /' \20 if (DataFIFO is empty) { // // WHOA! Error!!! DataFIFO should always have data // by the time the CmdFIFQ is written t〇 with a command // that expects data. //} PixelsPerFrame += count;

Read data24 from DataFIFQ; if 25 (Mode == COLOR_DEPTH_MODE_7) uint8 data8; data8 = data24 Sc 0x7 f ； data8 |= 0x80; while (OutputFIFQ FULL) ；// spin Write data8 to OutputFIFO,· BytesPerFrame += 1； { 30 } else { uint4 index; uint32 data32； 35 40 data32 = (data24 << 8) | (CMD一NEW_PIXEL << 4) | (count while (OutputFIFO FULL) ；// spin Write data32 to OutputFIFO; BytesPerFrame += (Mode == COLOR_DEPTH_MODE_15) ? 3 for (index = 1; index < count； index+ +) { if (DataFIFO is empty) Error!!! Read data from DataFIFO； 1); 4; 45 while (OutputFIFO FULL) ；// spin Write data to OutputFIFO; BytesPerFrame += ((Mode == COLOR_DEPTH_MODE_15) ? 2 : 3)； 52 200814780 void OutputSeries(uint24 count) { uint32 data; int sent = 0； 5 int shift = 0； uint4 command = CMD_SERIES; uint8 bytesToSend = count >> 3; PixelsPerFrame += count; 10 // // use count to determine header size and construct header if (count < 16) { data = (command < < 5) | count; 15 shift =8 ; bytesToSend += 1; } else { data = (command < < 5) | HEADER_EXT | (count Sc 0xf )； data |= ( ( count & 0x7 f 0) < < 4)； 20 shift = 16； bytesToSend += 2;

BytesPerFrame += bytesToSend； 25 30 35 40 // // Series data stream is read from the DataFIFO in // 24-bit chunks, but can be written to the OutFIFO // in 32-bit chunks including the header initially. // while (sent < count) { uint24 sdata;

Read sdata from DataFIFO; data |= (sdata << shift)； shift += 24; if (shift >= 32) { uint3 numbytes = (bytesToSend > 4) ? 4 ： bytesToSend； while (OutputFIFO FULL) ;// spin

Write ''numbytes77 of data to OutputFIFO; shift = shift - 32; data = sdata >> (24 - shift)； 53 45 200814780 void OutputDelta(uint8 header, uint24 delta) { while (OutputFIFO FULL) ;// spin PixelsPerFrame ++； 10 15 ..f 20 // // Handle Uniform and non-uniform differently// if (header & 0x8) { uint8 data; data = ((header & 0x7) << 5) | (delta & Oxf)； Write data to OutputFIFO,· BytesPerFrame ++; } else { uint16 data; data = (header < < 5) | 0x10 | (delta & Oxf) | I ( (delta < < 4) & Oxf f 0 0); Write data to OutputFIFO; BytesPerFrame += 2； 25 54

Claims

200814780 十、申請專利範圍： 1. 一種視訊壓縮常式，包括：欢宜所選擇的先前及目前視訊框中的像素；對於-給定的該目前訊框及對於其—目前像素，製作定義至少該目前像素_定㈣長度包括： f 10 15

20 -⑴複製像素封包，具有至少—封包類型的識別符位元及至少一反覆計數識別位元； / (2)色料義封包，具有至少_封包類型的識別符位兀及至少一色彩識別符位元； (3)差里疋義封包，具有至少_封包類型的識別符位元及至少一差量識別符位元；以及 ⑷雙色序列已編碼封包，具有至少_封包類型的識別符位元及至少-系列二進制色彩識別符位元，該等二進制色彩識別符位元只對應於兩個色彩且與該目前像素及緊接在該目前像素之後的多個像素的色彩一致。 2. —種視訊傳輸系統，包含：一視訊編碼常式，根據一演算法對連續像素資料進行編碼，泫演异法包括對於一組給定的連續像素，選擇下列編碼中之一個來產生較高壓縮比率： ⑴製作資料封包的複製像素編碼，該等資料封包定義可藉由複製有-訊框位置關係的一個別像素的色彩而被表示的該等連續像素的數目； ⑺製作資料封包的個別著色像素編碼，該等資料封 55 200814780 包的每一個都定義該組給定的連續像素中該等像素的每一個色彩； (3) 製作資料封包的差量值像素編碼，該等資料封包的每一個定義一目前像素與一有一訊框位置關係的個 5 別像素的色彩之間的差異；以及 (4) 製作一資料封包的雙色序列像素編碼，該資料封包包括指示一雙色集中之哪個色彩用於該系列連續像素中之每一像素的每一位元，其中該組給定的連續像素中的像素包含來自一個雙色集的色彩。 10 3.如申請專利範圍第2項所述之視訊傳輸系統，其中：該複製像素及該差量值像素編碼包括根據該目前訊框中的目前像素與該目前訊框中的另一像素之間的一訊框位置關係來進行編碼。 4. 如申請專利範圍第2項所述之視訊傳輸系統，其中： 15 該複製像素及該差量值像素編碼包括根據以下各項之一選擇來進行編碼：該目前訊框中的目前像素與該目前訊框中目前像素左邊的另一像素之間的一關係；該目前訊框中的目前像素與該目前訊框中目前像 20 素上方的另一像素之間的一關係；以及該目前訊框中的目前像素與位於相同位置但處於前一訊框中的另一像素之間的一關係。 5. 如申請專利範圍第2項所述之視訊傳輸系統，其中：該雙色序列像素編碼包括其中以該目前像素開始 56 200814780 的X個像素之一順序序列只包含來自一個雙色集的色彩的編碼。 6. —種編碼視訊的方法，包含以下步驟：根據該目前像素與其他像素之間的訊框位置關係 5 來預先定義一組複製像素命令；對於該目前像素，根據來自以下各項中之一個的一階層式選擇進行編碼： (1) 製作資料封包的複製像素編碼，該等資料封包定義可藉由複製有一訊框位置關係的一個別像素的色彩 10 而被表示的該等連續像素的數目； (2) 製作資料封包的個別著色像素編碼，該等資料封包的每一個都定義該組給定的連續像素中該等像素的每一個色彩； (3) 製作資料封包的差量值像素編碼，該等資料封包 15 的每一個定義一目前像素與一有一訊框位置關係的個別像素的色彩之間的差異；以及 (4) 製作一資料封包的雙色序列像素編碼，該資料封包包括指示一雙色集中之哪個色彩用於該系列連續像素中之每一像素的每一位元，其中該組給定的連續像素 20 中的像素包含來自一個雙色集的色彩。 7. 如申請專利範圍第6項所述之方法，其中該編碼包括製作固定大小的資料封包，該等資料封包包括一操作碼部分及一負載部分，該操作碼部分識別該複製像素編碼、差量值像素編碼、雙色序列像素編碼及個別著色像素編碼。 57 200814780 8.如申請專利範圍第7項所述之方法，其中對於該等固定大小的資料封包中之至少一些：該操作碼包括識別對應的資料封包是否與該個別著色像素編碼相關聯的一位元； 5 與該複製像素編碼及該雙色序列像素編碼相關聯的該資料封包的操作碼包括識別與三個不同的像素複製命令及該雙色序列像素命令相關聯的該等階層式選擇的兩個額外位元；以及該負載部分具有一長度為至少η-位元。 10 9.如申請專利範圍第8項所述之方法，其中該等固定大小的資料封包中之其他封包包括將該資料封包之負載與前一資料封包之負載予以鏈結的一擴充位元且包括一個大於η-位元的負載。 10. 如申請專利範圍第9項所述之方法，其中該等固定大小 15 的封包中之其他封包包括將目前資料封包之負載與下一資料封包之負載予以鏈結，下一資料封包包括一個大於η-位元的負載。 11. 一種用於壓縮包含η-位元色彩值所定義之像素的一視訊框之方法，包含以下步驟： 20 在一編碼器處：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一η-位元參考像素色彩值與一η-位元目前色彩值之間的一差異來決定一（η-χ)-位元差量值，在此X是η的一預先決定的有效位元數； 58 200814780 如果該η-位元參考像素色彩及該η-位元目前色彩值的該等X個有效位元實質上相等，則發送該差量值給一解碼器；以及在該解碼處· 5 藉由用該差量值來調整該η-位元參考像素色彩值而產生該η-位元目前色彩值。 12. 如申請專利範圍第11項所述之方法，其中該等方向關係類型指定該參考像素與該目前像素的以下關係：該目前像素左邊之一位置； 10 該目前像素上方之一位置；以及與該目前像素位置相同但在前一訊框中之一位置。 13. —種用於壓縮包含被分成三個yr位元、y2-位元及y3-位元通道的η-位元色彩值所定義之像素的一視訊框之方法，包含以下步驟： 15 對於該yr位元通道：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一yr位元參考像素色彩值與一各自的yr位元目前色彩值之間的一差異來產生一（yi-χι)-位元差量值，在此χι是yi的一預先決定 20 的有效位元數；對於該y2-位元通道：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一y2-位元參考像素色彩值與一各自的y2-位元目前色彩值之間的一差異來產 59 200814780 生一（y2-x2)•位元差量值，在此χ2是y2的一預先決定的有效位元數；對於該y3-位元通道：對於一目前像素相對於一參考像素的複數個 5 方向關係類型，藉由決定一y3-位元參考像素色彩值與一各自的y3-位元目前色彩值之間的一差異來產生一（y3-x3)-位元差量值，在此x3是y3的一預先決定的有效位元數；以及如果yi-位元、y2-位元及y3-位元通道各自的該 10 等xi、X2及A個有效位元對於該η-位元參考像素色彩及該η-位元目前色彩值而言是相等的，則藉由用該等各自的差量值來調整該η-位元參考像素色彩值中之每一通道而決定該η-位元目前色彩值。 14. 一種視訊傳輸系統，包含： 15 一編碼器，對於一目前與參考像素之間的複數個方向關係類型，藉由決定一 η-位元參考像素色彩值與一 η-位元目前色彩值之間的一差異來決定一（η-χ)-位元差量值，在此X是η的一預先決定的有效位元數，且如果該η-位元參考像素色彩與該η-位元目前色彩值的該等X個有 20 效位元相等，則產生一差量值；以及一解碼器，適於接收來自該編碼器的該差量值並藉由用該差量值來調整該η-位元參考像素色彩值而產生該η-位元目前色彩值。 15. 如申請專利範圍第14項所述之視訊傳輸系統，其中該等 60 200814780 方向關係類型指定該參考像素與該目前像素之間的以下關係：該目前像素左邊之一位置；該目前像素上方之一位置；以及 5 與該目前像素位置相同但在前一訊框中之一位置。 16.—種視訊傳輸系統，在此一視訊框包含被分成三個yr 位元、y2-位元及y3-位元通道的η-位元色彩值所定義的像素，包含：一編碼器 10 對於該yi-位元通道：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一yr位元參考像素色彩值與一各自的yr位元目前色彩值之間的一差異來產生一（yrXi)-位元差量值，在此义1是>^1的一預先決定 15 的有效位元數；對於該y2-位元通道：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一y2-位元參考像素色彩值與一各自的y2_位元目前色彩值之間的一差異來產 2〇生一（y2-x2)-位元差量值，在此X2是y2的一預先決定的有效位元數；對於該y3-位元通道：對於一目前像素相對於一參考像素的複數個方向關係類型，藉由決定一位元參考像素色彩值 61 200814780 與一各自的y3-位元目前色彩值之間的一差異來產生一（y3-x3)-位元差量值，在此χ3是y3的一預先決定的有效位元數；以及如果yr位元、y2-位元及y3-位元通道各自的該 5 等χι、X2及&個有效位元對於該η-位元參考像素色彩及該η-位元目前色彩值而言是相等的，則為每一通道產生一差量值；以及一解碼器，適於藉由用該等各自的差量值來調整該 η-位元參考像素色彩值中之每一通道而決定該η-位元目 10 前色彩值。 17. 如申請專利範圍第16項所述之視訊傳輸系統，其中該等方向關係類型指定該參考像素與該目前像素之間的以下關係：該目前像素左邊之一位置； 15 該目前像素上方之一位置；以及與該目前像素位置相同但在前一訊框中之一位置。 18. —種用於動態調整一視訊壓縮系統之效能的方法，該視訊壓縮系統藉由將目前像素之X個最高有效η-位元與一參考像素之該等各自的X個最高有效位元做比較來壓縮 20 包含η-位元色彩值通道所定義之像素的一視訊框，包含以下步驟：指定一位元組每像素率(ΒΡ); 對於視訊框中的一組被壓縮的像素，決定被需要來壓縮該組像素的一實際位元組數； 62 200814780 藉由使BP與該組中的像素數相乘來決定一臨限位元組數；將該實際位元組數與該臨限位元組數相比；以及如果該實際位元組數大於該臨限位元組數，則減少X。 5 19.如申請專利範圍第18項所述之方法，其中BP由下列方程式定義： BP=(位元組/秒)/(訊框寬度*訊框高度*訊框每秒）；以及其中該設定一位元組每像素率（BP)之步驟更包含 10 設定該（位元組/秒）值。 63