您的瀏覽器不支援JavaScript語法,但是並不影響您獲取本網站的內容。

技術探索

利用可變長度片段複製技術之調色盤編碼

中文摘要

  螢幕內容分享服務隨著Apple airplay推出後,成為熱門影音分享服務。另一個新興雲端互動式螢幕分享服務亦透過網際網路將遠端伺服器執行的螢幕畫面分享至使用者,讓使用者可透過互動介面操控遠端伺服器,此應用包括雲端信箱、雲端遊戲、雲端智慧家庭、Remote Play、Thin Client及遠端桌面等。針對上述應用,國際視訊標準組織ISO/IEC MPEG與ITU-T共同成立了JCT-VC團隊,著手制定新的高效能螢幕內容編碼標準。本論文會先介紹由微軟所提出的一個全新的編碼工具:調色盤編碼技術(palette-based coding,PBC),其概念是搜尋一個或多個主要顏色來代表這個編碼單元(coding unit,CU)內的畫面,並利用這些顏色所對應到的顏色索引(color index)來對編碼單元內的每一畫素進行索引編號,最終再針對這些顏色索引去進行無失真編碼。而為了提升調色盤編碼技術之效能,本論文提出一種利用可變長度片段複製的索引編碼技術,讓編碼器可以彈性的選擇一可變長度之索引片段,從已解碼之顏色索引進行複製編碼,達到更高的壓縮效能。我們所提出的索引編碼技術,在相同的視覺品質下,可達到0.6%的壓縮率。

Abstract

  Screen sharing services have received extensive attention since apple Inc. announced screen mirroring functionality, called airplay. Besides, there are also many envisioned applications of screen sharing, such as cloud mailbox, cloud gamming, cloud play, remote play, thin -client, remote desktop control and so on. For meeting the requirements of emerging applications, ISO/IEC MPEG and ITU-T are jointly working on making a high efficiency screen content coding standard (SCC).This article will first introduce a palette-based coding (PBC) proposed by Microsoft. The concept of PBC is to search one or more major colors to represent the pixels inside a coding unit (CU), and to use the color indexes of the major colors to sequentially code each pixel in the current CU. To improve the coding performance, this article proposes a variable-length segment copy technique for compressing index map of palette coding in SCC. The results show that the proposed technique outperforms current standard one in terms of coding gain under the same visual qualit y.

關鍵詞(Key Words)

顏色索引編碼技術(Color index coding;CIC)
調色盤編碼技術(Palette-based coding;PBC)
高效能螢幕內容編碼(High efficiency screen content coding;SCC)

圖1 螢幕內容視訊應用之範例(a) 投影片放映 (b) 網頁瀏覽畫面

圖1 螢幕內容視訊應用之範例(a) 投影片放映 (b) 網頁瀏覽畫面

1. 前言

  ISO/IEC MPEG及ITU-T VCEG兩大標準組織於2010年成立了JCT-VC團隊,其最初目標是發展一個可應用於4K2K大尺寸電視的下一代視訊標準技術H.265/HEVC,而此大尺寸電視應用的環境多以自然視訊影像為主, 並已於2013年完成制訂[1]。而螢幕應用環境通常會有混合的視訊內容素材(如圖1),例如畫面可能同時包含自然影像、大量文字圖片、滑鼠指標及各種線條等, 由於此螢幕應用環境已不符H.265/HEVC當初所設計的目標, 故JCT-VC自2013年起已將重心轉至發展新的高效能螢幕編碼標準技術(High efficiency screen content coding; SCC) ,並在2014年初,公告向各家公司尋求SCC的解決方案[2]。

  JCT-VC正在制定的SCC 標準是基於H.265/HEVC現有的工具下進行開發,其中新發展出來的工具包括畫面內區塊複製技術(Intra block copy; IBC)及調色盤編碼技術(Palette-based coding; PBC) [3-4]等,本論文所探討的即是專屬於SCC標準的調色盤編碼技術技術。調色盤編碼技術是由微軟公司最先提出來[3],其技術的概念是搜尋一個或多個顏色來代表現在正在編碼中的單位區塊(coding unit;CU)內之畫面,並利用這些顏色所對應到的索引來對CU內的每一個畫素進行索引編號,最終編碼端便會將一個或多個代表顏色以及每個畫素的顏色索引傳輸到解碼端。其中顏色索引編碼(Color index coding; CIC)的方式包含了三種模式, 包括向上複製模式、向左複製模式與一般模式。編碼器會根據CU區塊內連續兩列的畫素所對應到的顏色編號之間的關係,來決定該選擇哪一種模式進行編碼。目前該項技術仍在發展、討論與改善中。

  本篇論文主要會先針對SCC標準制定過程中所發展出來的調色盤編碼技術工具進行廣泛性的簡介,內容包括主要顏色表的編碼方式以及顏色索引編碼技術。而為了提升調色盤編碼技術之效能,本論文提出一種利用可變長度片段複製的索引編碼技術,讓編碼器可以彈性的選擇一可變長度之索引片段,從已解碼之顏色索引進行複製編碼,達到更高的壓縮效能,所提之編碼技術同樣擁有三種編碼模式:向上複製模式、向左複製模式與配對模式,但編碼器如果選擇配對模式時,可使用一種配對機制彈性地決定是否要使用一種可變長度片段複製的索引編碼技術。最後我們也將所提出的顏色索引編碼技術實作在JCT-VC所提供的參考軟體上,而實驗結果也顯示所提出的顏色索引編碼技術相較目前標準之編碼技術最多可有-8.7%左右的編碼效能增益。

2. 調色盤編碼技術之簡介

  螢幕相關應用的視訊內容在一個區塊畫面內時常都可由少數幾個顏色來表示,如圖1所示部份的網頁部分之背景幾乎都是以白色來表示, 而網頁內的字與線條之顏色也大多僅僅為單調的黑色或藍色等, 所以其實一個畫面裡面可以只使用幾個主要顏色來代表就可以了,調色盤編碼技術就是根據此概念所衍生出來的。

  一個區塊(例如一個64×64大小的CU區塊)內的畫面若非常單調,那麼就可以用少數幾個顏色來表示這個區塊的畫素, 所以調色盤編碼技術所針對的畫面即為較為單調的畫面。而使用這種方法,都會需要傳輸一個或多個的主要顏色,所以假設所要傳輸的顏色個數是一樣的,那麼大區塊(例如64×64或32×32大小的CU區塊)所獲得的壓縮效率當然會比小區塊(例如16×16或8×8大小的CU區塊)要來得要高出非常多,所以調色盤編碼技術所針對的畫面區塊是大小較大的CU區塊,其對於處理較大的CU區塊是有很高的壓縮效益的。目前微軟所提出的調色盤編碼技術[3]所處理的區塊大小雖然仍然是介於64×64的最大CU區塊到8×8的最小CU區塊,但經過分析統計後,普遍已認知其壓縮增益的來源是來自於64×64~16×16的區塊。

圖2 一個區塊的原始畫面畫素值與其主要顏色表

圖2 一個區塊的原始畫面畫素值與其主要顏色表

  圖2即為一個簡單範例說明調色盤編碼技術的主要顏色之概念,為了方便說明,這個圖例與本論文之後的圖例都是以8×8的區塊來說明,但請注意實際上的運作可以是64×64 、32×32、16×16或8×8的CU區塊大小。而圖2裡面的每個圓圈代表一個畫素點,其對應的數值為各自對應的畫素值。可發現這些畫素點可以區分成五個主要顏色,此五個主要顏色分別為70、30、100、150及200,假設此區塊畫面內的所有畫素值都可以用這五個主要顏色來表示即可,那麼主要顏色表就是依此五個主要顏色依序建立而得。此節下列部分接著詳細說明此技術的編碼流程,其中包括主要顏色表的編碼方式與顏色索引的編碼方式。

2.1 主要顏色表編碼技術

  編碼器在找出能代表這個CU區塊畫面的一個或多個主要顏色後, 便會根據這些顏色建立出一個主要顏色表。理論上必須要將表裡面的每個主要顏色傳輸到解碼器, 解碼器才能知道現在這個CU的主要顏色。但是為了減少傳輸量, 微軟提出一種主要顏色表預測的方法,其做法是根據左邊CU的主要顏色表內的主要顏色與上面CU的主要顏色表內的主要顏色,來針對現在CU的主要顏色表內的主要顏色依序地做主要顏色的預測。如果現在CU的主要顏色表內的第i個主要顏色與上面CU的主要顏色表內的第i個主要顏色一樣,那麼就只需傳輸訊號10至解碼端即可;如果現在CU的主要顏色表內的第i個主要顏色與左邊CU的主要顏色表內的第i個主要顏色一樣, 那麼就只需傳輸訊號11至解碼端即可; 但若現在CU的主要顏色表內的第i個主要顏色與上面CU的主要顏色表內的第i個主要顏色不一樣,且亦與左邊CU的主要顏色表內的第i個主要顏色不一樣,那麼就需要將現在CU的主要顏色表內的第i個主要顏色直接傳輸至解碼器。解碼器則是依序解出接收的訊號即可還原, 若收到10表示現在解碼中的CU的第i個主要顏色與上面CU的第i個主要顏色一樣;若收到11表示現在解碼中的CU的第i個主要顏色與左邊CU的第i個主要顏色一樣;若收到0表示現在解碼中的CU的第i個主要顏色與左邊CU的第i個主要顏色不一樣, 且與上面CU的第i個主要顏色也不一樣。

圖3 微軟所提出的主要顏色表編碼技術之範例.

圖3 微軟所提出的主要顏色表編碼技術之範例.

  我們以圖3為例,此範例延續圖2之範例。假設CU C是現在正要編碼中的CU、CU A是CUC的上面CU、CU B是CU C的左邊CU。主要顏色表C的主要顏色依序為70、30、100、150及200(請參考圖2之說明),此五個主要顏色即能代表CU C的畫面;主要顏色表A的主要顏色依序為60、30及100,此三個主要顏色即能代表CU A的畫面;主要顏色表B的主要顏色依序為70、90、10及30,此四個主要顏色即能代表CU B的畫面。假設使用傳統做法,直接將主要顏色表C的五個主要顏色依序傳輸至解碼器, 則會需要傳輸40個位元數,請注意:這邊假設每個主要顏色是以8個位元來表示。但若採用微軟所提出的主要顏色表的預測編碼方式,則編碼過程如下:由於主要顏色表C的第一個主要顏色與主要顏色表B的第一個主要顏色相同,所以只需傳輸兩個位元個數的訊號11;同樣地,由於主要顏色表C的第二個與第三個主要顏色分別和主要顏色表A的第二個與第三個主要顏色相同,所以分別都只需傳輸兩個位元個數的訊號10;而因為主要顏色表C的第四個主要顏色與主要顏色表B的第四個主要顏色不相同,且主要顏色表A沒有第四個主要顏色,所以需要傳輸一個位元個數的訊號0,且再另外傳輸8個位元數的主要顏色值150;而因為主要顏色表A與表B沒有第五個主要顏色,所以需要傳輸一個位元個數的訊號0,且再另外傳輸8個位元數的主要顏色值200。如此一來,如圖3所示,所需要傳輸的位元數就僅有24個位元。相較於傳統做法須要40個位元數,這個範例微軟做法可以節省多達40%的位元傳輸量。

2.2 顏色索引編碼技術

  編碼器找到主要顏色並將主要顏色傳送到解碼器後, 接著就需要將區塊畫面內的每個畫素做主要顏色之索引編號, 並將這些顏色索引傳送到解碼器。這裡為了方便說明, 利用圖4到圖5延續圖2與圖3的範例,講解顏色編號編碼技術。

圖4 區塊內的每個畫素做主要顏色之索引編號

圖4 區塊內的每個畫素做主要顏色之索引編號

圖5 區塊畫面內的顏色編號以列為單位進行編碼

圖5 區塊畫面內的顏色編號以列為單位進行編碼

  如圖2可知五個主要顏色為70、30、100、150及200,假設這五個主要顏色的編號依序分別是0、1、2、3和4,則圖2區塊畫面內的畫素值可以改用如圖4的編號方式來表示即可,如此一來編碼器就不需要傳輸原始畫素值,僅需傳輸顏色索引編號到解碼器即可,這樣就可以大幅提高螢幕視訊的壓縮率。我們可以詳細計算位元數:若不採用調色盤編碼技術,前五列會需要傳輸如圖2的40個原始畫素,這會需要高達320個位元。但若使用顏色編號編碼方法傳輸圖2前五列的畫面,則只需要如圖4的主要顏色之編號,而因為只有五個主要顏色,所以圖4內的每個顏色編號只需要三個位元數,所以圖4前五列的40個畫素,只須要傳輸120個位元數。

圖6 區塊畫面內的顏色編號以列為單位進行編碼

圖6 區塊畫面內的顏色編號以列為單位進行編碼

  但是為了再提升顏色編號編碼技術的壓縮率,微軟進一步提出一種以列(row)為單位的編號編碼機制,此編號編碼機制共分成三種模式:一般模式(傳0)、向左複製模式(傳11)及向上複製模式( 傳10)。圖5延續圖4的範例來示範微軟所提出的列編碼的方法。原本所要傳輸的訊息量是原始畫素值所各自對應到的顏色索引編號, 此時所要傳輸的符號是依照圖4內由上到下且由左到右的順序進行傳輸;而為了要再降低傳輸的訊息量,微軟再進一步提出以列為單位的編號編碼機制,此編碼機制以列為單位的方式將圖4的編號再重新編碼:如圖5所示,其第一列的主要顏色編號因為都是0,所以採用向左複製模式,先傳11,再傳第一列的左邊第一個畫素的主要顏色編號0;第四列因為與第三列傳送的顏色編號完全一樣,所以採用向上複製模式,此模式只需要傳一個符號10告知解碼器要解碼此列的方法為向上複製即可;第二列、第三列與第五列的顏色編號不為向左複製且也不為向上複製模式,所以採用一般模式,此模式須先傳送符號0,再傳送此列由左到右的每個主要顏色索引編號,以第五列為例,傳送符號0後依序要傳輸顏色編號:2, 2, 1, 1, 1,1, 1, 4。相較圖4需要傳輸每個畫素的顏色索引的做法,圖5所需傳送的訊息量又更少。經過換算圖5傳送前五列的顏色編號僅需要傳輸82個位元數,相較於圖4需要120個位元數,節省約32%的位元傳輸量。

  圖5的列編碼方式,雖然已相較於圖4可以更大幅降低位元的傳輸量,但是可以發現在一般模式的時候,壓縮效率仍然無法得到任何的好處,仍然需要將一般模式內每個索引值所對應到的顏色索引傳輸到解碼器。因此,微軟的顏色索引編碼方法,最終又針對一般模式內的每個顏色索引去做預測處理,此預測處理可以有三種選擇模式: 向左預測模式、向上預測模式及不預測模式。假設現在正在編碼中的畫素列選擇採用一般模式,則若其內的一個畫素所對應到的顏色索引與左邊畫素的顏色索引一致, 該畫素就會選擇向左預測模式;若其內的一個畫素所對應到的顏色索引與上面畫素的顏色索引一致,該畫素就會選擇向上預測模式;若其內的一個畫素所對應到的顏色索引與左邊畫素的顏色索引不一致,且亦與上面畫素的顏色索引不一致,就會選擇不預測模式。我們以圖6為例,此圖6延續圖5的範例,圖6的第一列與第二列分別對應到圖5的第四列與第五列。由於圖6的第二列選擇一般模式,所以此列內的顏色編號若採用傳統做法須要將每個顏色傳送到解碼器, 因此會需要24位元的傳送量。若圖6第二列的顏色索引編碼方式改採對每個顏色索引做預測處理,其運作流程如下: 第二個與第七個畫素所對應到的顏色索引(分別為2及1),與其各自左邊的顏色索引一致, 所以採用向左預測模式,分別只需要傳輸兩個位元的符號00告知解碼器即可; 而第三個畫素到第六個畫素所對應到的顏色索引(剛好都是1),與其各自上面的顏色索引一致,所以採用向上預測模式,分別只需要傳輸一個位元的符號1告知解碼器即可;至於第一個與第八個畫素所對應到的顏色索引( 分別為2及4),與其各自上面與左邊的顏色索引都不一致,所以採用不預測模式,此模式除了需要各自傳輸兩個位元的符號01,還需要傳輸各自的顏色索引(即為2及4),所以如圖6第二列的範例,最終所需傳輸的符號為:01, 2, 00, 1, 1, 1, 1,00, 01, 4,其位元數為18個位元的傳送量,相較傳統做法須要24位元的傳送量,可節省高達25%的位元數。

3. 所提的顏色索引編碼技術

3.1 所提可變長度索引片段複製技術之概念

  調色盤編碼技術在找到主要顏色並將主要顏色傳送到解碼器後,接著就是將區塊畫面內的每個畫素所對應到的顏色索引依序傳送到解碼器。而顏色索引編碼的目的,就是希望能夠用最有效率的方式,傳送區塊畫面內的每一個顏色索引。由於螢幕相關應用的視訊內容在一個區塊畫面內,其每一列與每一列的畫素值的重複性相當高,如圖1的網頁畫面,其每一列的線條、文字與背景畫面的重複性相當的高,因此可以推斷出微軟在採用圖5所示的列編碼方式時,有很高的比例可經由過去已解碼之可變長度索引片段複製得到。

  在目前的調色盤編碼設計,垂直模式僅允許使用的上面相鄰的第一列進行匹配搜尋且要求上面相鄰第一列的每個索引值與目前列的每個索引值均相同。由於對畫面內容的特殊特性,如重複出現的物件/線條和簡單的背景中,除了上述相鄰第一列的其餘列的已解碼索引值,也可利用來提升編碼效能。在後續的章節中,我們首先將分析目前編碼列和其餘在相同CU內的已解碼列的相關性。

3.2 前列線匹配分析和一般2-D索引段複製

  Previous line matched analysis (前列匹配分析)與一般的2-D索引分析結果顯示於表1中,在此表中, ”occur once” 意味著只有一個matched line 被找到,”occur twice” 和”occur repeatedly” 代表兩個以上的matched line,測試視訊序列的名稱可由表2查詢對照得到。

  表1的分析結果顯示,一旦垂直模式已被選擇,這是極有可能在同一CU找到一個精確匹配的line(90%以上)。因此,我們可以假設如果current line與above line不能match,它仍在目前CU內搜尋到一個matched line,根據這個觀察結果,我們提出了一個調色盤索引編碼的改進算法。這個算法包括兩部分:

表1 垂直模式的分析結果表

表1 垂直模式的分析結果表

表2 視訊序列ID與視訊序列名稱對照表

表2 視訊序列ID與視訊序列名稱對照表

3.2.1 全局搜尋

  對於current coding line,它可以被看作是片段的組合結果,而且可以有許多可能的組合結果為current line , 對於一個組合結果的片段,編碼器能找到過去已解碼的匹配片段,如果找到一個匹配片段,移動向量和片段長度則被記錄下來,向量和長度被用來表示複製片段的起點與其長度,如果當前的起始位置無法找到任何匹配的索引,則編碼為正常模式。

  如果搜尋階段包含多個搜索結果(multiple matched lines),編碼器將計算每個matched line的Rate-distortion成本,最終選出具有最小成本的matched line為最後搜索結果。舉例來說,一個8×8區塊的第8列是current line, current line被分成兩個片段, 對於這兩個部分,匹配片段定位在第6和第2條line。移動向量和第一片段的長度分別為( 0,-2)及3,第二段則是( -1,-6)及5。上述演算法具備相當高的複雜度,底下我們將提出另一簡化的演算法。

3.2.2 簡化演算法: Copy 2nd above mode

  如在前節所示之分析,編碼器有很高的機率在已解碼索引中搜尋到current line的匹配,根據此結果,我們設計了一個簡化演算法,允許編碼器搜尋above及2nd above line。與原來的調色盤編碼具有的三個模式相較,在此簡化演算法,我們引入一個額外的模式:Copy 2nd above mode, 當current line和above line是不同的,編碼器將繞過垂直模式,並使用我們提出的2nd above line mode,如果2nd above line與current line相同,所提出的模式則會被選擇,解碼器可經由解析模式標誌得知採用所提之2nd above line mode,並複製2nd above line到current line。

  在8x8 CU區塊大小中,對於原始垂直模式而言,如果5th 和current 6th line是不同的,在此情形下垂直模式將不被選用,反之,如果4thline與6th line是相同的,在此情況下,我們所提的2nd above line mode中,將會被選用以提高編碼效能。

4. 實驗結果

  為了評估本論文所提出的預測模式,本章將所提出的技術實作於JCT-VC所提供的最新參考軟體HM13.0+RExt6.0, 並根據JCT-VC所規定的模擬環境設定的三種模式(AI, RA 和LB),去比較lossy壓縮模式的結果[2]。另外,視訊的格式有YUV和RGB兩種,總共會有24個測試視訊檔案。這24個測試的視訊檔案根據視訊內容的不同及格式的不同可以分成10種類別。這10種類別裡,text & graphics with motion會是SCC較常遇到的視訊應用,其內大多為簡報、軟體呈現等SCC常見應用;而mixed content則是包含SCC常用的視訊應用也包含HEVC常見的自然影像之應用;另animation則是動畫視訊,此應用較少用於SCC環境,而目前已知的SCC技術在這個類別的壓縮效果都不大。這些視訊類別根據大小又區分成720p,1080p和1440p三種。而本章節所呈現的數據都是BDrate,此亦為標準所採用的客觀評判標準。BDrate的意義是參考軟體和我們所提之壓縮方法在相同的畫質下,bit-rate可以減少多少百分比。當此數據負的越多,表示壓縮率越高。而為了與其他公司的做法做比較,我們也提供了在相同測試環境下的微軟的調色盤編碼技術之數據,兩者的比較對象都是參考軟體HM13.0+RExt6.0。請注意參考軟體HM是根據JCT-VC已接受的技術所實作出來的軟體程式。

表3 我們整合之軟體在All-Intra編碼環境之實驗模 D擬r數at據(BDrate)

表3 我們整合之軟體在All-Intra編碼環境之實驗模 D擬r數at據(BDrate)

  表3是我們在參考軟體HM13.0+RExt6.0上整合微軟調色盤編碼技術之後,以參考軟體HM作為Anchor,並且在All-Intra的編碼環境下所得到的BDrate模擬結果。微軟的調色盤編碼技術在SCC測試的視訊檔案類別中,最高增加了8.7%的編碼效能。在text & graphics with motion,1080p 的RGB和YUV 類別,分別增加8.3% 和8.7%的編碼效能。而text & graphics with motion,720p的RGB和YUV類別,微軟的調色盤編碼技術可以提高3.8%和3.0%的編碼效能。

表4 Copy 2nd line mode在All-Intra編碼環境之實驗 模擬數據(BDrate)

表4 Copy 2nd line mode在All-Intra編碼環境之實驗 模擬數據(BDrate)

  我們所提出的Copy 2nd line mode,相較於整合了微軟調色盤編碼技術之參考軟體,於All-Intra 編碼環境下,在text & graphics with motion, 1080p的RGB類別,能夠增加0.5%的編碼效能,如表4所示。在text & graphics with motion, 1080p的YUV類別,則是可以提升0.6%的編碼效能。由於本論文所提出之Copy 2nd line mode相較於全局搜尋的方法,大幅度地降低了在硬體實作上的複雜度以及所需要的搜尋時間,因而無法像全局搜尋般在目前的CU裡面找到最佳的匹配,使得Copy 2nd line mode在其他的視訊檔案類別當中,其編碼效能並沒有顯著的提升。

5. 結論

  本論文先針對標準組織提供的視訊檔案進行了前列匹配分析與一般的2-D索引的分析,結果顯示目前正在處理的列和之前的列,彼此之間有著非常高的關聯性。因此,我們提出了全局搜尋的方法來改善調色盤索引編碼的效能。然而, 全局搜尋的演算法複雜度較高,考量到硬體實作的困難度,我們提出了在複雜度與編碼效能之間能獲得平衡的Copy 2nd line mode。透過這一個新增的模式,能夠在text & graphics with motion,1080p的類別中,相較於微軟的調色盤編碼技術,有0.6%編碼效能的增加。

  未來SCC標準的發展, 仍會將PBC編碼工具的改良列為重要項目之一,且在新會期會將PBC放進標準組織的核心實驗中[6],各家公司在會期中將會提出各種不同的方法與實驗結果來探討此工具, 而我們工研院也會提出我們的改良方案[7]。此外, 近期SCC標準發展出一種新的編碼工具: single color mode [5],此工具類似PBC與intra prediction的結合,預期此新工具也會是未來討論的重點工具之一。

參考文獻

  1. B. Bross, W. J. Han, J. R. Ohm, G. J.Sullivan, Y. K. Wang, and T. Wiegand,“High Efficiency Video Coding (HEVC)Text Specification Draft 10,”JCTVC-L1003, Jan. 2013.
  2. MPEG2014/N14175, “Joint Call for Proposals for Coding of Screen Content,”ISO/IEC JTC1/SC29/WG11, Jan. 2014.
  3. X. Guo, Y. Lu, and S. Li, “RCE4: Test 1.Major-color-based screen content coding,”JCTVC-P0108, Jan. 2014.
  4. W. Pu, X. Guo, P. Onno, P. Lai, and J. Xu,“AHG10: Suggested Software for Palette Coding based on RExt6.0,” JCTVC-Q0094,Mar. 2014.
  5. Y. W. Chen, Y. C. Sun, Y. W. Huang, and S. Lei, “SCCE3 Test D.1: Single color intra mode for screen content coding,”JCTVC-R0058, Jun. 2014.
  6. Y. W. Huang, P. Onno, R. Joshi, R. Cohen,X. Xiu, and Z Ma, “Description of Screen Content Core Experiment 3 (SCCE3):Palette mode,” JCTVC-Q1123, Apr. 2014.
  7. Y. J. Chang, C. L. Lin, C. H. Hung, C. C.Lin, and J. S. Tu, “Non-SCCE3: Run-copy coding method for two-color index map of palette CU,” JCTVC-R0076, Jun. 2014.

作者簡介

林敬傑

現任職於工研院資通所視訊編碼核心技術部副工程師。專長為視訊編碼。
E-mail: JackLin@itri.org.tw

林俊隆

國立清華大學資訊工程系博士,現任工研院資通所視訊多媒體通訊技術組視訊編碼核心技術部工程師。專長為多媒體視訊傳輸與編碼、影像處理、圖形辨識、無線感知器網路等。

凃日昇

現任職於工研院資通所視訊編碼核心技術部副工程師。畢業於清華大學資訊應用與系統研究所。專長為視訊編碼。

張耀仁

國立中央大學通訊工程系博士,現任工研院資通所視訊多媒體通訊技術組視訊編碼核心技術部工程師。專長為視訊壓縮訊號處理、通訊訊號處理。目前從事視訊標準制定。
E-mail: britpablo@itri.org.tw

洪朝雄

國立交通大學電子工程系博士,現任工研院資通所視訊多媒體通訊技術組視訊編碼核心技術部工程師。專長為視訊和影像壓縮訊號處理。目前從事視訊標準制定。
E-mail: chhung@itri.org.tw