MPEG-4多媒體通訊技術之研究---子計畫IV：MPEG-4與MPEG-7系統技術之研究(III)

全文

(1)行政院國家科學委員會專題研究計畫. 成果報告. 子計畫四:MPEG-4 與 MPEG-7 系統技術之研究(3/3). 計畫類別：整合型計畫計畫編號： NSC91-2219-E-009-041執行期間： 91 年 08 月 01 日至 92 年 07 月 31 日執行單位：國立交通大學電子工程學系. 計畫主持人：杭學鳴計畫參與人員：張峰誠唐健霖蔡尚軒楊政偉范振韋曾建統. 報告類型：完整報告處理方式：本計畫可公開查詢. 中. 華. 民. 國 92 年 10 月 23 日.

(2) ■ 成果報告 □期中進度報告. 行政院國家科學委員會補助專題研究計畫. MPEG-4 多媒體通訊技術之研究—子計畫四： MPEG-4 與 MPEG-7 系統技術之研究(3/3) A Study on MPEG-4 and MPEG-7 Systems (3/3) 計畫類別：□ 個別型計畫 ■ 整合型計畫計畫編號： NSC 91-2219-E-009-041 執行期間： 91 年 8 月 1 日至 92 年 7 月 31 日計畫主持人：杭學鳴計畫參與人員：張峰誠唐健霖蔡尚軒楊政偉范振韋曾建統成果報告類型(依經費核定清單規定繳交)：□精簡報告. ■完整報告. 本成果報告包括以下應繳交之附件： □赴國外出差或研習心得報告一份 □赴大陸地區出差或研習心得報告一份 □出席國際學術會議心得報告及發表之論文各一份 □國際合作研究計畫國外研究報告書一份. 處理方式：除產學合作研究計畫、提升產業技術及人才培育研究計畫、列管計畫及下列情形者外，得立即公開查詢 □涉及專利或其他智慧財產權，□一年□二年後可公開查詢執行單位：國立交通大學電子工程學系中. 華. 民. 國. 92 年. 10 月. 15 日.

(3) 行政院國家科學委員會專題研究計畫成果報告 MPEG-4 與 MPEG-7 系統技術之研究(3/3) A Study on MPEG-4 and MPEG-7 Systems(3/3) 計畫編號：NSC 91-2219-E-009-041 執行期限：91 年 8 月 1 日至 92 年 7 月 31 日主持人：杭學鳴. 國立交通大學電子工程學系教授. 計畫參與人員：張峰誠唐健霖蔡尚軒楊政偉范振韋曾建統國立交通大學電子研究所. 中文摘要過去數年間，由於多媒體通訊突飛猛進，網際網路迅速普及，以多媒體物件製作、處理、編輯及傳輸為目標的 MPEG-4 標準活動受到大家的關注。我們在此研究計畫的目的為(1) 深入研究並模擬 MPEG-4 系統，主要為 MPEG-4 IPMP 延伸系統，以及(2)研讀模擬 MPEG-7 系統與製作 MPEG-7 發展平台。關鍵詞：多媒體通訊, MPEG-4, IPMP, MPEG-7,多媒體資料庫. 英文摘要 Due to tremendous advances in multimedia communication and the aggressive expansion of Internet in the past a few years, the MPEG-4 standards activity, which aims at establishing a comprehensive specifications for multimedia object construction, manipulation, editing and delivery, receives a lot of attentions. Our goals in this project are to (1) investigate and simulate the MPEG-4 Systems and its IPMP extension, and (2) study and simulate the MPEG-7 systems and construct an MPEG-7 platform for testing and research purpose. Keywords: Multimedia communication, MPEG-4, IPMP, MPEG-7, Multimedia database. 1.

(4) 目錄 Table of Contents 第一部分 MPEG-4 系統的研究 A. B. C. D.. 背景與目的........................................................................................................................ 3 研究步驟 – IPMP 標準與架構......................................................................................... 3 模擬與實驗........................................................................................................................ 8 結論.................................................................................................................................. 11. 第二部分 MPEG-7 系統的研究 A. B. C. D.. 背景與目的...................................................................................................................... 12 研究步驟 -- MPEG-7 標準與工具................................................................................. 12 MPEG-7 軟體平台 .......................................................................................................... 13 結論.................................................................................................................................. 16. 參考文獻.................................................................................................................................. 16 計畫成果自評.......................................................................................................................... 17 附錄.......................................................................................................................................... 17 1. C.-C. Huang, H.-M. Hang, and H.-C. Huang, “MPEG IPMP Concepts and Implementation,” The 3rd IEEE Pacific-Rim Conference on Multimedia, Hsinchu, Taiwan, Dec. 2002. 2. F.-C. Chang, H.-M. Hang, and H.-C. Huang, “Research Friendly MPEG-7 Software Testbed,” Image and Video Communications and Processing 2003 Conference, USA, Jan. 2003.. 2.

(5) 第一部分 MPEG-4 系統的研究 A. 背景與目的每種多媒體，例如書本、音樂、電影、電視節目等等，被數位化前或者後，都是智慧財產的一種。現今網際網路的蓬勃發展，涉及數位化多媒體財產的電子商務日漸普遍。因此，能保護智慧財產和使得智慧財產可以透過更方便的形式作商務交易的技術 ─ 智慧財產的數位化管理和保護(Intellectual Property Management & Protection，簡稱 IPMP)，將會成為電子商務系統之中不可或缺的一環。由 1997 年開始，MPEG 組織開始嘗試為 IPMP 訂立標準的公用介面和相關協定，以解決數位化媒體在網路上交易所衍生的問題，目標是把 IPMP 整合到現有的 MPEG 標準之中。其中利用密碼方法或數位浮水印的技術以有效的提高非法剽竊的困難度。目前，類似但簡化之技術已被應用在數位電視系統中。截至本論文撰寫時，MPEG-4 和 MPEG-2 標準中的 IPMP 訂定已經快將完成，而 MPEG 組織也開始投入更多的資源訂定 MPEG-21 IPMP 標準。 MPEG-4 IPMP 架構已經歷重大改進，由最初只能作有限範圍保護的 IPMP hook 介面，進展為更具彈性與痛通操作性的 IPMP Extension (IPMPX)介面。MPEG-21 IPMP 尚在起草階段，許多介面方式仍有待討論，不過可以預期將來與 MPEG-21 主架構整合，可以提供比 MPEG-4 IPMPX 更為完善的數位資訊保護。. B. 研究步驟 – IPMP 標準與架構我們的研究承續之前對於 MPEG-4 系統[1]的了解，本期專注於 MPEG-4 標準 (ISO/IEC 14496-1) 中所提供的 IPMP 架構，並輔以部分 MPEG-21 IPMP，以期對 MPEG IPMP 有更前瞻的認識。 MPEG-4 Systems ver.1 中所定義的 IPMP 架構提供了一個標準化的介面讓 MPEG-4 players 可以使用不同的 IPMP System[2]，MPEG-4/AMD3[4]提出後，為了區別兩個版本中差異頗大的 IPMP 子系統，前者稱 IPMP Hook，而後者稱為 IPMP Extension (IPMPX)。 IPMP Hook 運作主由 IPMP ES (Elementary Stream) 以及 IPMP 描述子 (descriptor) 所構成。IPMP ES 傳遞時間上變化較快的週期性的資訊給一個或是多個 IPMP 系統。IPMP 描述子由 object descriptor stream 所攜帶並傳送出去。圖一是 MPEG-4 中的 IPMP Hook 架構。 IPMP Hook 架構的最大不足之處在於工具間的溝通方式並沒有正式定義，這使得各工具的實作者無法利用他人的實作成果。有鑑於此，IPMPX 架構觀念改為虛擬終端機 (Virtual Terminal)，與既有的 MPEG-4 系統以 Message 互相溝通。IPMP 虛擬終端主要由兩大概念合成，一為 Message Router (MR)，另一為 Tool Manager (TM)。Message Router 負責將所有的 IPMP Message 傳送至對應的 IPMP Tool，而各 Tool 則根據 Message 內容負責串流的處理，例如解碼或是權限控制。Tool Manager 負責 Tool 的建立、消滅、與關聯等功能，當需要時，可由 MPEG-4 系統或 Message Router 發出管理需求。. 3.

(6) 圖一 MPEG-4 的 IPMP Hook 架構[3]. 在 IPMPX 下，依據 IPMP Tool Identifier，系統可以使用的 Tool 可分為下列幾類： Unique Implementation -- 代表唯一的獨立實作 Parametric Description 根據給定參數，符合特定條件的實作實作所需的參數可透過 Parametric Configuration Information 傳入 List of Alternative Tools List 中指明的所有 Tool 皆視為等效實作可搭配 Parametric Description 描述所有符合特定條件的等效實作. 4.

(7) 圖二 IPMPX 與 MPEG-4 系統[4]. Missing IPMP Tools. Obtain Missing IPMP Tool(s). Content IPMP Tool Manager. IPMP Tool List. IPMP Tool ID(s) Alternate IPMP Tool ID(s). Content Request. Parametric Tool Description(s). Content Delivery. Terminal. IPMP Tool Elementary Stream. IPMP Information. Terminal-Tool Message Interchange Interface Terminal-IPMP Tool Communications. IPMP Tool 1. IPMP Tool 2. 圖三 IPMP 使用流程示意圖[4]. 5. .... IPMP Tool n.

(8) IPMPX 的起始資訊也是透過 MPEG-4 系統串流傳遞至終端。接收端對於這部分的處理流程如下： 1. 使用者要求特定的數位內容 IPMP 需求先於內容需求在傳送內容前先完成 access control 2. 取得 IPMP Tools descriptoion 從內容中取得所需的 Tool List 根據 Tool List 搜尋可建立的 Tool 3. 取得 Tool 找尋並下載無法在終端機找到的 Tool，這項功能不在標準定義內 4. 建立 Tool instance 實際建立 Tool 從內容中取得 IPMP information 5. 初始化 Tool 與更新 Tool 給予各 Tool 起始 IPMP information 終端開始消化允許處理的內容開始處理內容後，終端機可根據收到的 IPMP 命令，重新出始化或更新 IPMP Tool. MPEG-21[4] IPMP[6]需求文件尚在草稿階段，不過可從其中窺見 MPEG 委員會對於未來 IPMP 系統的構想。在 MPEG-21 的數位內容描述與散佈架構下，MPEG-21 IPMP 涵蓋的範圍非常廣，從某個特定數位內容的生命期來看，IPMP 作用的範圍包含所有觸及權限管理的軟硬體及技術。從技術範圍來看，IPMP 同時具有系統性與切割性。就系統性而言，IPMP 必須整合散佈在整個商業價值鏈的各個部分，包含各點之間信賴關係的建立與管理，商業模式的操作方式與架構等等。另一方面，切割性來自於 IPMP 與許多技術領域相關，例如應用整合、元件化軟體、行動程式碼、作業系統、分散式服務、數位內容管理、安全服務等等。圖四為 IPMP 的抽象系統模型，這個模型從兩個維度來說明。垂直方向代表 IPMP 技術的層次，越上面的越高層。水平方向代表各功能與相對應的技術，可以看出 IPMP 的切割性。最右側的說明方塊標示在 MPEG-21 中對應的標準工具。以下將對圖中五大功能簡略描述：. 6.

(9) Functional Domains. Technical Elements. Packaging, Rules Generation and Modification. Rights Expression Language Rights Data Dictionary Digital Item Structures and Formats. Value Chain Management and License Services. License Generation and Distribution Value Chain Management Services DIID Services. Consumption Services. Rights Evaluation and Enforcement Representation of IPMP Tools Capabilities Rendering Interfaces and IPMP Capabilities Negotiation. Trust Management Services. Trusted Entity References Distributed Trust Management Certification Services. Security and Protected Platform Services. Secure Channels Key Management Trusted Software and Execution Environment Tamper Resistance. DID, REL, RDD. DII&D. DIA. SPKI, X.509. XKMS. 圖四 Abstract IPMP System Model[6]. Packaging, Rules Generation and Modification 的相關技術：數位內容包裝技術，通常包含內容與 meta-data、智慧財產權資訊的整合包裝，最後產出為受到保護的數位內容。著作權與相關資料表示法的標準規格。數位內容的產生與修改。 Value Chian Management and License Services 的相關技術：在商業模式下數位內容的散佈與使用。包裝好的內容除了可以直接實體散佈出去外，也可以採用類似 URL 的方式只將參考連結散佈到使用者手上。 Consumption Services 內容的使用者，包含一般使用者及價值鏈中的內容處理者，皆是透過 Consuption Service 使用數位內容及服務。 Trust Management Services 可用於管理 IPMP 各元件間的信賴關係，這些元件包含執行程序與結構。這部分的功能可能包含下列幾種形式：信賴模式，例如點對點模式、web 模式、階層模式價值鏈中的軟硬體認證 7.

(10) 價值鏈中的軟硬體註冊安全平台或服務的個人化設定安全機制的生命期，包含更新與廢止等管理使用者憑證與密碼管理可信賴的對時服務 Security and Protected Platform Services 要與受到保護的系統或服務溝通，或是使用受保護的內容，本身必須是安全機制中的一環，也必須能夠向對方證明自己的安全能力。這些安全機制可能為：對抗攻擊的能力作業系統執行環境的安全管理軟體個人化對使用者存取遠端或近端資源的認證. 由以上說明，我們可以了解 MPEG IPMP 的目標是建立一個從數位內容產生到消失，整個過程都加以保護的散佈與使用機制。現階段接近完成的為 MPEG-4 IPMPX[9] 與 MPEG-2 IPMP[9]，這二者採用 Virtual Terminal 概念，在現有系統之外，加上 IPMP 介面。為了使 IPMP 工具之間溝通順暢，採用 Message 方式交換 IPMP 資訊及命令。與 MPEG-4 IPMPX 與 MPEG-21 IPMP 最大不同點在於，前者作用範圍在 Terminal 端，後者則散佈在整個傳遞架構各環節中。. C. 模擬與實驗本模擬重點為 IPMPX[8][9]，相關的參考軟體不多，一為 Craig A. Schultz 所作，另一個為 MOSES。兩者皆利用 IM1 為 MPEG-4 player。IM1[7]，或是稱做 AHG (Ad-hoc group) on Systems Reference Software Implementation，是 MPEG 委員會中負責從事開發以及整合 MPEG-4 System 軟體的團體。IM1 軟體包括了所有 MPEG-4 System 中標準化的部分。 MOSES 至今未有正式公開版本，但根據架構圖(圖五)顯示，設計上像是 IM1 的加強版，因此與 Craig 的 IPMPX 實作架構(圖六)有些許不同。我們分析了 IM1 Core 中有關 IPMPX 的部分，了解 IPMPX 系統的操作模式，並據此設計三個程式，以循序漸進的方式，展示 IPMPX 的運作。圖七為本展示程式的資料流程圖，包含 IPMP 資訊的 MPEG-4 串流到達後，先經過 Demultiplex 影像資料流往 player 的 control point。而 IPMP 資料則流向 IPMPX 模組，啟動對應的 IPMP Tool 並開始對流經 control point 的影像資料作處理。. 8.

(11) MOSES IPMPX Implementation. IM1. MOSES IPMPTool. MOSESSimple BifsEnc. IM1. Moses Messages. Binary Messages. IPMPTool. Message Router. MP4 File. Spec Messages. MOSES Msg Parser. Descriptors. SDL Msg Parser IM1-IPMPX Interface “ipmpxinteface.h”. MOSES Messages SDL Messages Binary Messages SCR, Txt files. IPMPX Message Binary Interface.. 圖五 MOSES IPMPX. Application. Executive. Presenter(T). Service. Data Channel ALManager. Media Stream. BIFS Decoder. Media Stream. Decoder. Root Scene Object. FlexMux. Data Channel. Media Object. Media Stream T. Data Channel. Data Channel. Decoder. Media Stream. IPMP Stream. IPMP Tool A. Media Stream T. IPMP Tool B. OD Stream. Message Router IOD. Retrieve Missing Tools. Service Provider. Tool Manager MPEG-4 IPMP Extension to IM1. T : Represents a component which uses a clock to control its operation. Represents a component running as a separate threat. Points from the object which instantiates the object pointed to Represents a component which is a shared data structure Shows the direction of data movement Represents an IPMP tool Represents new IPMP Extension additions. 圖六 IM1 IPMPX (Craig’s version) 9.

(12) .TRIF bitstream. Demux. video stream. Control Point. video stream. Player. 1. Function call from Control Point 2. video stream. 1. IPMP Tool List Descriptor 2. IPMP Tool Descriptor 3. IPMP message. Instantiated IPMP Tool 1. Function call from IPMP module 2. IPMP message. IPMPX Module Available Tool A. Availabl e Tool B. 圖七展示程式 Dataflow. 圖八程式展示. 第一個程式展示 IPMPX 模組啟動，當收到 IPMP 串流時，啟動 AES Tool。當收到後續的 IPMP 資料時，顯示資料內容。第二個程式主要用來展示 IPMP 資訊可以隨著時間變動，因此我們在特定時間送出 IPMP update 命令，使 Tool 失效( 圖八)。第三個程式展示權限控管的概念( 圖九)，在傳送出來的串流中，事先依據不同權限對不同部分加密，接收的使用者必須插入 ID 卡認證，並取得符合其身份的權限，就可對授權部分解密。這種應用可能出現在購物頻道，一般用戶只能看廣告，而物品的優惠訊息則需更高權限的使用者才能 10.

(13) 看到。. 圖九程式展示. D. 結論本研究的主要目的是探討 MPEG IPMP，除了以 MPEG-4 IPMPX 為主要研究對象外，我們也對 MPEG-21 IPMP 的設計進行了解。以現今的多媒體系統而言，要達到 MPEG-21 那種理想並不容易，因此我們以 MPEG-4 IPMPX 為主，追蹤 IM1 程式架構，並了解 IPMPX 運作原理，把標準文件中抽象的 Message Router 與 Tool Manager 對應到實際的系統中。 IPMPX 以 Message 為交換 IPMP 資訊的方法，使得各 Tool 間的互通性大增，也讓 IPMPX 比 IPMP Hook 介面更為可行、更具彈性。了解程式的過程中，我們發現 IPMPX 與 IM1 間的相關性仍然太高，如果想把 IPMPX 抽離 IM1，成為像概念圖上的 MPEG-4 Terminal 與 IPMP Virtual Terminal，仍有許多技術問題需要克服。或許未來 MOSES 正式版本公佈後，可以作些比較。研究的最後，我們以三個程式展示 IPMP 模組的啟動、Message 的傳遞、IPMP 資訊的動態更新，以及透過 IPMP 進行權限控管。根據這幾個程式，我們初步驗證 IPMPX 與 MPEG-4 player 搭配，的確可以執行一些電子商務所需的功能。. 11.

(14) 第二部分 MPEG-7 系統的研究 A. 背景與目的傳統的印象裡，影音資訊經由播放系統送出後，其接收者為人類。現在許多影音應用逐漸增加，其接收者不一定是人，而是特定的運算系統。舉例來說，機器人的視覺及聽覺辨識，或是媒體型態自動轉換（語音轉文字或圖片轉語音等）。也有些應用於搜尋特定條件的媒體，例如監視錄影機一邊錄下影像，一邊比對是否有危險事件發生，再據此決定是否要發出警報。又例如根據電視影片中的特定資訊啟動或關閉錄影機, 只錄下自己要的片段。在未來將會有更多的應用領域需要處理影音資訊，為了增加處理效能, 將影音資訊以特定的格式描述，方便軟硬體處理，是必要的步驟。MPEG 系列的標準已訂出 MPEG-1 及 MPEG-2 這類 frame-base 的影音資料格式，或是 MPEG-4 這種 object-base 的影音資料格式。這些格式只表示出資料的值，卻無法表示資料在概念上的關係或意義，如果我們想從中找尋具有特定意義的影音片段，傳統上多靠人工搜尋。MPEG-7 就是基於上述的需求而生，如圖十所示，目的為定義一套多媒體的描述格式。其應用的範圍並無特定限制，原則上只要是與影音資訊搜尋比對相關的應用皆可使用。. feature extraction. standard description. search engine. scope of MPEG-7 圖十 MPEG-7 Scope. B. 研究步驟 -- MPEG-7 標準與工具研究 MPEG-7 的過程中，我們先對 MPEG-7 標準的內容進行研讀，除了了解 MPEG-7 可以有哪些應用方式外，還對其提供的工具加以追蹤，最後我們提出一個軟體測試平台，並利用平台建立原型程式驗證架構的設計是否有足夠彈性，希望能利用這個架構輔助往後的 MPEG-7 研究。為了能表達影音資料的意義，我們會產生另一種資料，這種資料並非原本影音資訊的一部份，可視為附加上去的，有些時候，我們稱這種描述資料的資料為 meta-data。 MPEG-7 正是規範 meta-data 格式的標準，為了讓 MPEG-7 資料能在最多的系統之間交換及處理，MPEG-7 採用 XML 相關技術定義其提供的工具。也就是說，符合 MPEG-7 的 meta-data 格式都是 XML 的 Application。參與 MPEG-7 的專家們除了規範各式各樣的基本 descriptor（簡稱 D）及 description scheme（簡稱 DS），同時也提供一套參考軟體供大家驗證其可行性。Descriptor 用來描述媒體單一方面的特性，例如色彩分佈、紋理、物體輪廓、物體移動軌跡等等。Description scheme 可視為用來組合基礎特徵 (D or DS) 的樹狀資料結構。以下簡述 MPEG-7 提供的各項工具： Systems[10] 定義 MPEG-7 資料的傳送及使用方式，meta-data 除了可以用純文字 XML 12.

(15) 格式傳送外，也可以採用 MPEG-7 內定義的 binary 格式(BiM)傳送。 Description Definition Language[10] 用來定義新的 D 或 DS 的語言，是根據 XML Schema 標準而來，主要目的是讓使用者能根據不同需求，定義新的資料型態及結構。 Visual[10] 與視訊相關的 D 及 DS。這部分包含顏色、紋路、形狀、以及移動等相關 meta-data。 Audio[10] 與聲音相關的 D 及 DS。這部分包含音效、樂音、以及語音等相關 meta-data。 Generic Entities and Multimedia Description Schemes[10] 基本的 D 與 DS。這部分除了包括通用於視訊與音訊的 meta-data 外，例如時間與解析度，還定義其他類型的 meta-data，例如基本資料類型、媒體使用資訊與管理、媒體瀏覽、使用者互動等等。 Reference Software[10] 簡稱 XM，為 eXperimentation Model 的縮寫。主要提供一套 C++軟體，展示各 D 及 DS 的可行性與搜尋準確度。特徵抽取與比對演算法不在 MPEG-7 標準定義範圍內，但 XM 中所採用的演算法，雖然不是最好的，卻是研究 MPEG-7 的很好入門參考。 Conformance[10] 規範如何測試是否為 MPEG-7 相容系統的原則。 MPEG-7 提供許多現成的 D 與 DS，並不代表這些 meta-data 有一定的使用方法，事實上， MPEG-7 的 formative 部份只提及格式及其代表的意義，至於參考的使用方法則列在 informative 部份。. C. MPEG-7 軟體平台儘管 MPEG-7 XM 已經提供 C++軟體供我們研究，但其目的是驗證各個 D 與 DS 是否可行，以及參考演算法是否正確無誤。對於深入研究的需求，例如以圖表方式顯示找出的 D 或 DS 內容，或是資料庫運作的設計，XM 的功能就不符所需。我們根據 MPEG-7 的通用使用狀況，配合研究上可能的需求（資料庫、網路、圖形化展現等等），規劃一個軟體平台。如圖十一所示，這個平台以 Java 語言為基礎，其上建構一個我們設計的 framework，這個 framework 主要由三類抽象元件構成： Data：觀察或處理的主體，可能是媒體資料或 meta-data。 DataAlg：與 Data 關聯的演算法，就媒體資料而言，為編碼與解碼。若作用主體為 meta-data，則除了編解碼之外，還包括抽取與比對演算法。 Viewer：用來觀察 Data 的圖形化介面，或是轉換 Data 型式的演算法。在這個測試平台中，以 Data 為中心，允許有零至多個 DataAlg 或 Viewer 與其相關，因此設計 Component Management Unit 用來維護元件間的關聯性。有了 framework 與 Component Management Unit 後，我們就可依此架構實作不同的媒體、D、DS、以及相對應的顯示元件。目前在此平台中，我們完成了 Scalable Color、Color Layout、Dominant Color、Edge Histogram 等 meta-data 相關元件，也完成 image 相關元件。實際應用上，如何搭配資料庫搜尋以達到最佳效能也是研究重點之一，因此我們設計資料庫單元，允許研究者設計專屬特定型態資料儲存媒介的存取方式。例如儲存媒體為關聯資料庫時，可以利用 JDBC 完成。我們特別實作一個檔案系統的 Persistence 13.

(16) Manager 來展現這個設計不只可以與實際的資料庫相連，其彈性足以應付其他種類的儲存媒體。此外，為了讓程式架構維持元件化的形式，我們將資料庫單元的介面設計成以物件為處理單位，其功能簡述如下：. 圖十一軟體平台架構. 物件存取 key(obj)：取得物件的 key，必須是此物件型別下的 unique key listKeys(type)：列出資料庫中某物件型態的有效 key get(key)：按照 key 取出物件 insert(key,obj)：將物件加入資料庫 remove(key)：將物件移出資料庫 match(obj)：依照定物件作相似性比對，並將結果傳回 match(obj,alg)：依照指定的演算法對指定物件作相似性比對資料庫單元維護 getInstance(config)：依照組態建立資料庫單元 configure(config)：依照組態設定資料庫單元 register(type, cmds)：將物件存取命令與物件型別關聯起來 deregister(type)：取消某物件型別的存取命令 14.

(17) 命令搜尋的方式採相容式比對，當有已註冊的命令時，就以此為準，如果沒有，則根據物件型別的繼承關係，先比 interface 再比 super class，如果有相符的命令，就以此相容命令為準，如果沒有，繼續向上搜尋，直到到達繼承關係頂點為止. 圖十二所示為利用此軟體平台開發出來的原型程式，在這個程式中，我們除了展示了 Histogram、Color Layout、Edge Histogram、Scalable Color 相關的 feature extraction、 feature matching、以及 image/feature viewer，並利用設計的 Component Management 單元展示如何在不更動程式下，新增或移除 Concrete Components。此外，我們在應用程式層次加上額外兩種 matching 方式，稱為 weighted matching 及 multi-step matching，前者可用 weighting factor 方式組合多個 D 或 DS 作為搜尋條件，後者則是進一步將搜尋分成多級，每級皆為 weighted matching，且每級的搜尋範圍限制在前一級的搜尋結果中。實驗結果發現，適當安排各級搜尋條件不僅可以得到較令人滿意的結果，而且搜尋速度與 weighted matching 相差不會太多。除了 weighted matching 類型外，我們也實作了以集合運算結合多種特徵的比對方式，實驗結果顯示在某些狀況下的確可以得到比較好的結果，但缺點是如果集合不夠大，可能無法取到共同交集。. 圖十二軟體平台程式展示. 15.

(18) D. 結論在 MPEG-7 系統的研究中，我們先研讀 MPEG-7 標準及相關參考資料，了解 MPEG-7 的目的、內涵、使用的技術、與提供的工具。接著針對 MPEG-7 XM 不足之處，我們根據 MPEG-7 精神加上日後研究所需，設計軟體測試平台。這個平台以 Java 實作而成，主要是由 framework (Viewer-Data-DataAlg 關聯 ) 、 Component Management 、以及 Persistence Management 組合所形成的基礎架構。在此架構之上，我們以數個 MPEG-7 中定義的 Descriptor 為例，在此平台上實作出來，以確認作為 meta-data 測試平台的可行性。最後，設計一個影像特徵抓取與搜尋原型程式，除了展示基本的 MPEG-7 應用方式 (特徵抓取、儲存、比對、整合)，並提供使用者檢視 descriptor 內容的介面，最重要的，此程式驗證了測試平台的設計具有足夠彈性，可用來開發 MPEG-7 相關的研究或應用程式，且在程式測試期間，可以充分利用平台上提供的動態關聯，在不需更動程式碼的狀況下，試驗不同組態下的執行速度與比對準確度。當決定組態後，亦可從平台中將各元件抽離，以程式碼固定關聯性，可減少耗費在元件管理機制中的執行時間。. 參考文獻 [1]ISO/IEC JTC1/SC29/WG11 N3747. MPEG-4 Overview - (V.16 – La BauleVersion), Contribution for La Baule, October 2000. [2]ISO/IEC JTC1/SC29/WG11 N3850. ISO/IEC 14996-1 ,COR1, AMD1. [3]ISO/IEC JTC1/SC29/WG11 N2614 MPEG-4 Intellectual Property Management & Protection (IPMP) Overview & Applications. [4]ISO/IEC JTC1/SC29/WG11 N5068, Study of FPDAM ISO/IEC 14496-1:2001/AMD3, Jul. 2002. [5]ISO/IEC JTC1/SC29/WG11 N5333, MPEG-21 Requirements v.14, Dec. 2002. [6]ISO/IEC JTC1/SC29/WG11, N5535, Requirement for MPEG-21 Intellectual Property Management and Protection, Pattaya, Mar. 2003. [7]ISO/IEC JTC1/SC29/WG11, Part 5 – Reference Software – Systems (ISO/IEC 14496-5 Systems) [8]ISO/IEC JTC1/SC29/WG11 N4702, MPEG-4 IPMP Extension Reference Software Architecture based on IM1, Jeju, Mar. 2002. [9]ISO/IEC JTC1/SC29/WG11 N4850, MPEG-2 and MPEG-4 IPMP Extension Reference Software Architecture based on IM1, May. 2002. [10] ISO/IEC FCD 15938-1 Information Technology - Multimedia Content Description Interface - Parts 1 to 7.. 16.

(19) 計畫成果自評本計畫有以下幾類成果。第一類為研究 MPEG-4 Systems (IPMP)與 MPEG-7 多媒體系統所發展出的技術、經驗及成品極具實用價值，可促進國內工業研發技術開發。第二類為計畫執行過程所獲得之研究成果論文兩篇，已發表於國際學術會議。其三，參與計畫之同學可獲得國際多媒體最先進的 MPEG-4 與 MPEG-7 相關技術及多媒體系統設計經驗，畢業後進入產業，直接有助於產業界開發新產品，提昇我國工業技術能力。達到人才培育之目的。綜合評估：本計畫產出相當多具有學術與應用價值的成果，並培育高科技人才培育，整體成效良好。已發表學術論文兩篇以及碩士學位論文一冊如下表。. Publications: (1) C.-C. Huang, H.-M. Hang, and H.-C. Huang, “MPEG IPMP Concepts and Implementation,” The 3rd IEEE Pacific-Rim Conference on Multimedia, Hsinchu, Taiwan, Dec. 2002. (2) F.-C. Chang, H.-M. Hang, and H.-C. Huang, “Research Friendly MPEG-7 Software Testbed,” Image and Video Communications and Processing 2003 Conference, USA, Jan. 2003. (3) Kin-Lam Tong 唐健霖, An Implementation of MPEG IPMP System, MS Thesis, NCTU, June 2003.. 附錄 1. C.-C. Huang, H.-M. Hang, and H.-C. Huang, “MPEG IPMP Concepts and Implementation,” The 3rd IEEE Pacific-Rim Conference on Multimedia, Hsinchu, Taiwan, Dec. 2002. 2. F.-C. Chang, H.-M. Hang, and H.-C. Huang, “Research Friendly MPEG-7 Software Testbed,” Image and Video Communications and Processing 2003 Conference, USA, Jan. 2003.. 17.

(20) <附件一>. Advances in Multimedia Information Processing – PCM 2002, pp. 344-352, Springer-Verlag, Dec. 2002.. MPEG IPMP Concepts and Implementation Cheng-Ching Huang1, Hsueh-Ming Hang2 , and Hsiang-Cheh Huang2 Department of Electronics Engineering, National Chiao-Tung University, Hsinchu, Taiwan. [email protected] 2{hmhang, huangh}@cc.nctu.edu.tw. Abstract. Intellectual Property (IP) protection is a critical element in a multimedia transmission system. Therefore, ISO/IEC MPEG started the IP protection standardization project on MPEG-4 a few years ago. A basic IPMP (Intellectual Property Protection and Management) structure and interface was first defined in its System part. In this paper, we will first outline the MPEG-4 basic IP protection mechanism and then describe our simulation of an MPEG-4 IPMP system. An IP protection application is constructed using the MPEG-4 system software – IM1 (Implementation Model one). This application includes a clientserver program, in which a client can request the keys from a server in a secure way using a hierarchical key distribution structure.. 1 Introduction With the rapid development in computer industry and the swift growth of Internet, there is a widespread use of the digital multimedia contents in our daily life. The progress in data compression techniques also makes transmission of multimedia data stream possible. However, Internet is an open environment, therefore, if the user data and information are not protected, it might be illegally used and altered by hackers. To protect privacy and intellectual property (IP) right, people often use cryptographic techniques to encrypt data, and thus the contents protected by encryption are expected to be securely transmitted over the Internet. One requirement of typical multimedia applications is the demand for real-time transmission. In contrast, conventional security methods are often designed to protect digital data files, which might not be suitable and efficient for real-time applications. To fulfill the demands for both real-time distribution and data security, including the IP protection mechanism into the multimedia standard might be a feasible and effective way to achieve an unambiguous communication environment. MPEG (Moving Picture Expert Group) is the ISO committee to set up the international standards for multimedia data exchange. MPEG-2 has been applied to digital video broadcasting with some access control specifications [1][2]. IPMP (Intellectual Property Management and Protection), proposed for MPEG-4 standard, aims at protecting the compressed multimedia. In this paper, we will describe and implement a multimedia transmission system using the MPEG-4 IPMP concepts..

(21) This paper is organized as follows. Sec. 2 is an overview of the MPEG-4 System and IPMP standards. Sec. 3 describes the IPMP plug-ins in the MEPG-4 System reference software “IM1.” Sec. 4 describes the procedure of constructing the MPEG-4 IP plug-ins and an application example is included. Sec. 5 concludes this paper.. 2 MPEG-4 Standard Overview and IPMP Framework MPEG-4 is an international standard defined by the ISO/IEC committee. Compared to it predecessors, MPEG-4 pays more attention on the following three subjects: (i) real-time streaming, (ii) object-based coding, and (iii) enriched user interaction. MPEG-4 standards contain 10 parts. The portion related to IP protection is in the first part, Systems. The IPMP framework in ISO/IEC 14496 consists of a normative “interface” that permits an ISO/IEC 14496 terminal to host one or more IPMP subsystems. An IPMP sub-system is a non-normative component of terminal, which provides several intellectual property management and protection functions. At the moment, MPEG committee is refining and extending the MPEG-4 IPMP specifications. A Message Router mechanism is to be added into the third Amendment of 14496-1. In the MPEG-4 standards, the IPMP interface consists of IPMP elementary streams and IPMP descriptors. The IPMP elementary streams usually convey time-variant information such as keys associated with the encryption algorithm, which may change very rapidly. IPMP descriptors often convey time-invariant information associated with a given elementary stream or a set of elementary streams. IPMP elementary streams are treated as regular media elementary streams. And the IPMP descriptors are transmitted as part of an object descriptor stream. Fig.1 shows how an IPMP sub-system works in an MPEG-4 terminal. Almost all the streams may be controlled or accessed by the IPMP sub-system but the Object Descriptor streams shall not be affected by the IPMP sub-systems. Stream flow controller is a conceptual element that accompanies with every elementary stream. Stream flow controller can take place between the SyncLayer decoder and the decoder buffer. As Fig. 1 indicates, elements of IPMP control can take place at other points in the terminal. For example, they can appear after decoding (as in the case with watermark extractors).. 3 IPMP in IM1 IM1 is an MPEG-4 Systems software developed by the MPEG committee. It may be used to verify and demonstrate the functionalities of MPEG-4 [4]. The Systems Core module in IM1 defines the infrastructure to implement MPEG-4 players. It provides the functionality of MediaObject, the base class for all specific node types. The API for Decoder, DMIF and IPMP plug-ins is also supported by IM1. Moreover, the code is written in C++, which is fairly platform-independent [5].. 2.

(22) Elementary Stream Interface. DMIF. Audio CB. Video DB. Video Decode. Video CB. OD DB. OD Decode. BIFS DB. BIFS Decode. IPMP DB. IPMP-ES. IPMP-Ds. Decoded BIFS. Render. Audio Decode. Composite. DMUX. Audio DB. BIFS Tree. IPMP System(s). Possible IPMP Control Points. Fig. 1. IPMP sub-system in the ISO/IEC 14496 terminal architecture [3]. 3.1 IPMPManager In IM1, IPMP sub-systems are implemented by extending the IPMPManager class. IPMPManager is an interface between MPEG-4 player and the IPMP sub-system. Each media content access unit goes through the sub-system before it is stored in the decoding buffer. An implementation of IPMPManager can decrypt the encrypted content and thus block the unauthorized access to the media content. IPMPManagerImp extends the IPMPManager interface, and it provides the major functionality of an IPMP sub-system. Simple implementations need to overload a few setup functions and the Decrypt() function, which decrypts one access unit using one IPMP stream. More complex implementations, for instance, when multiple IPMP streams are used to decrypt a single elementary stream, may overload the Run() function and implement different data flows by directly accessing the MediaStreams. IPMP plug-ins interact with the core codes of the player through a special kind of buffer, known as MediaStreams. An IPMPManager object fetches an access unit, which is a kind of media, from one MediaStream object. After decrypting an access unit, it will dispatch one decrypted access unit into an output MediaStream object, which usually is a decoding buffer [6]. 3.2 IPMPManagerImp IPMPManagerImp extends the IPMPManager interface. It is the base class of all the IPMP sub-systems. IPMPManagerImp provides all the needed functions of a regular IPMP sub-system. Each IPMP sub-system runs on its own thread. An IPMP sub-system is usually attached to three MediaStream objects – the encrypted input stream, the decrypted output stream, and the IPMP stream. According to the SDK [6], the workflow of a typical IPMP sub-system is shown in Fig.2. Our design procedure is modified from that in [6] and is outlined below.. 3.

(23) DMIF. Video DB. Video Decode. DMUX. OD DB. OD Decode. BIFS DB. BIFS Decode. Decoded BIFS. Renderer. Compositor. 2. 2. BIFS Tree. 4. 3 IPMP DB. Video CB. IPMP-ES. IPMP-Ds. IPMP System(s). IPMP Control Point. Fig. 2. A typical IPMP sub-system workflow. 1. An object derived from IPMPManagerImp is instantiated by the IPMP sub-system module (usually a Dynamic Link Library, or DLL). 2. The application calls IPMPManager::SetInputStream() and IPMPManager::Set OutputStream() to attach input and output MediaStreams to the IPMP sub-system. 3. The application calls IPMPManager::SetIPMPStream() to attach an IPMP stream to the IPMP sub-system. This function may be called more than once if the elementary stream is protected by multiple IPMP streams. 4. The application calls IPMPManager::SetDescriptor() for each IPMP descriptor assigned to the elementary stream. 5. The application calls IPMPManager::Init() to initialize the IPMP sub-system and to confirm that the user has access to the protected elementary stream. 6. The application calls IPMPManager::Start(), which spawns the IPMP sub-system thread. 7. The IPMP sub-system thread fetches an access unit from the input stream and the corresponding access unit from the IPMP stream. Note that one IPMP access unit can control multiple content access units. 8. The IPMP sub-system calls a private virtual function, Decrypt(). This function is overloaded by specific IPMP sub-systems and performs the actual decryption. 9. The output of Decrypt() is stored in the output MediaStream. 10. Steps 7-9 are repeated until IPMPManager::Stop() is called by the application, or until reaching the end of the input stream. Some of these steps have been implemented in IPMPManagerImp class, but in some special cases, we need to re-implement them again. 3.3 MediaStream MediaStream class handles the buffering and synchronization of an elementary stream. It manages the memory buffer and fetch/disfetch access units from the buffer. The stored access unit maybe has time stamp on it. The current solution is to fetch the ac-. 4.

(24) cess unit immediately and ignore the time stamp, fetch the matured unit only, or otherwise suspend.. 4. Constructing an MPEG-4 IPMP Application Example. We will implement and demonstrate a multimedia transmission system with MPEG-4 IPMP by incorporating modern cryptographic techniques [7]. In designing the system, we adopt the Conditional Access (CA) concept by using a hierarchical key distribution structure as shown in Fig. 3. In this system, we encrypt only the bitstreams in the TRIF files. The server generates and embeds the keys into the bitstream. When the keys are correctly retrieved, the decoded and decrypted video sequence can be played properly. Otherwise, the bitstreams cannot be decoded successfully. Diffie Hellmen Key Agreement. Client, MPEG-4 IPMP System. Server. K DH. K DH. AES. EAES[KC]. AES-1. Random Sorce. KC pool. KC pool. Content. DES / XOR. KC. KC. KC. KC. EDES/XOR[Content]. (DES / XOR)-1. Content. Fig. 3. The hierarchical key distribution structure. 4.1 System structure and handshaking protocol Our hierarchical key distribution system is illustrated by Fig. 3. At the upper level, we use the Diffie-Hellmen Key Agreement [8] that enables both the client-end and the server-end to securely retrieve the Session Key, KDH, over the Internet. By applying the Advanced Encryption Standard (AES) [9], KDH can serve as a secret key to encrypt KC, and the encrypted KC are then transmitted. The use of KC is to serve as the key for the bottom layer encryptor. In our example, the contents to be encrypted are the compressed video, audio, or image bitstreams. Similar to the CA system in DVB, we achieve the security requirement by changing KC frequently. The throughput of KC is so high that we need a KC pool to generate the keys constantly.. 5.

(25) Client. Server. request. accept. server_key_exchange Time. Diffie-Hellmen Key Agreement. client_key_exchange. user_name cont_number Encrypted by AES block_length key_length key_period. ask_for_key Loop until end KC. end_of_service. Fig. 4. The handshaking protocol. One of the most important elements of our system is the handshaking protocol. Fig. 4 shows the basic steps in establishing a connection between the client-end and the server-end. The procedure is stated as follows. 1. Client sends request = 0x31403 (4 bytes). 2. Server sends accept = 0x31403 (4 bytes). 3. Client and server proceed with the Diffie-Hellmen key agreement; all the forthcoming information will be encrypted with AES by this key. 4. Client sends user_name (44 bytes) and cont_number (4 bytes), representing the user name and content number, respectively. 5. Server sends block_length (2 bytes) and key_lengh (2 bytes) to initialize the encryptor, and key_period (1 byte) to tell the bottom layer encryptor the lifetime of KC. 6. Client sends ask_for_key = 0x5327 (4 bytes) to ask for a new key from the server. Server sends a new KC to client after receiving ask_for_key. 7. Client sends end_of_service = 0x0 (32 bytes) to terminate the handshaking.. 4.2 The client-end IPMP plug-in The player is the “IM1 2D player” executed under the Windows environment. Hence, the IPMP plug-in can be implemented with the DLL file in Windows.. 6.

(26) There is one implementation of IPMP plug-in in IM1 core called IPMPNull. It works like a buffer to send the input MediaStream directly to the output side. Based on the existing IPMPNull program, we implement two new IPMP plug-ins in our system: IPMPXOR.dll and IPMPDES.dll. They are essentially two encryption methods. The first plug-in conducts the XOR operation between the received bitstreams and the key at the decryptor, a very simple encryption technique; the second one uses the DES [7] scheme for decryption. In the MPEG-4 design, the IPMP stream is used to transmit keys. In our example, we transmit the key using TCP/IP, not DMIF, to avoid the incompatibility between our example system and the standard system. The first step to implement IPMPDES is to create an IPMPDES class, and it inherits a class called “IPMPManagerImp.” Then, we implement the SetDescriptor() function. The IPMPDescriptor within the TRIF file contains the information of the server location and the content identification number that is to be played. The SetDescriptor() function uses the above information to make a connection to the server and to initialize the decryptor locally. Next, we implement the Decryptor() function, which can decrypt the received MediaStream, and count the number of times KC is used. Figs. 5(a) and 5(b) are the demonstrations of two IM1 2D players. The video sequence is coded in the H.263 format. The bottom-left bitstreams in both figures are decrypted by IPMPXOR, and the ones on the bottom-right are decrypted by IPMPDES. The sequences on the upper side are not protected in both Figs. 5(a) and 5(b). In Fig. 5(a), we assume that the key can be reliably transmitted and received. Hence, the two encrypted bitstreams can be decrypted and displayed successfully. In Fig. 5(b), the keys are not retrieved. Thus, the encrypted bitstream cannot be decoded and displayed.. (a) (b) Fig. 5. Demonstration of the proposed system: the unprotected bitstreams (upper) and the protected bitstreams (lower). (a) Correctly retrieved keys, and (b) keys not retrieved. 4.3 The server-end The server can be divided into two parts, one is the encryptor and the other part is responsible for sending keys. Fig.6 is a screenshot of the server-end application. We write it in C++ and it is a DOS command-line program. But the GUI is done in Java using the pipes stdin and stdout.. 7.

(27) Fig. 6. The server that can turn on/off keys. 5. Conclusions. In this paper, we first briefly describe the MPEG-4 IPMP system concepts. We then analyze the IPMP API in the reference software of the MPEG-4 Systems – IM1. After studying the IM1 Core and its IPMP API, we implement a functional IPMP subsystem by modifying IPMPNull – a prototype of the IPMP sub-system. We use the hierarchical key architecture to construct an application example, following the MPEG-4 IPMP concepts. Our example simulates the functionalities suggested by the standard. We demonstrate that the MPEG-4 IPMP is a practical way for protecting the multimedia content.. 6 Acknowledgement This work was supported by National Science Council (Taiwan, ROC) under Grant NSC 90-2213-E-009-137.. References 1. ISO/IEC 13818-1 Generic Coding of Moving Pictures and Associated Audio Information: Part 1 Systems (ISO/IEC JTC1/SC29/WG11 N0801rev), April 1995. 2. H. Benoit, Digital Television, MPEG-1, MPEG-2 and Principles of The DVB system, Arnold, 1997. 3. ISO/IEC 14496-1:2000(E) Coding of Audio-visual Objects: Part 1 Systems (ISO/IEC JTC1/SC29/WG11 N3850), October 2000. 4. ISO/IEC JTC1/SC29/WG11 N4291, MPEG Systems (1-2-4-7) FAQ, Jul. 2001. 5. ISO/IEC JTC1/SC29/WG11 N4709, MPEG-4 Systems Software Status and Implementation Workplan, March 2002. 6. ISO/IEC JTC1/SC29/WG11 M3860, IPMP Development Kit, Aug. 1998. 7. B. Schneier, Applied Cryptography, 2nd edition, John Wiley & Sons, 1996. 8. PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Technical Note, ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc. 9. J. Daemen and V. Rijmen, AES Proposal: Rijndael (corrected version), http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaeldocV2.zip.. 8.

(28) <附件二>.

(29) "!$#&%('*),+-./1023)546 78:9<;.8=;>=?A@,B,C"DE8F9HGI8"D.?J@,B,C=?A@LKMDE8F9H;.8=DN=?J@,B,O OPQSR ?AT<UV Q @WUYXAZ\[\] QS^ U_T_X`@La ^Sb [\@,BAac@ QdQ T_ae@,B,C=f?JUaeX`@=?A]5;>,ag?JXih N,@,Bj@Laek Q T b aeUmlonpfq;hrjqstCvu*w`wLu h

(30) ?x9mD b N Q >zyYXW?JK5C=D b ac@ ^ >{N5C"h

(31) ?Aae|?A@6}`w`w~u*wLC=y8&8;.8 E "r& ¦¢¥/±(*²"_p³ª´

(32) µpt¶·x<¦d¸d3

(33) ¦¦©¤Stx ¡\J¢£¹ºx*E¤¥p»J¦t*¢§©¨5_¼tªtJ¼t¢£x¦q¤¾½«¨v¡ ¡¡t±(¬²"=³ª´

(34) ,µp¡x¶·ªpJH®*x¯x°W©¤«5txxH¥»x*¡/¯x&p ©¤¾m¦dt ±H²"x³ªt´

(35) ¦µp¶¾«t¦¢ x»x*°·¦dx±(t²3_³ªÄd´

(36) »xµ©¶*<¹¿À<S ¦{ t*,x<¦E»J¢£*»x°ÁxW¹,vÅ¦¤ <x®*<x¦¢

(37) v¡= ¡_ÄS<»«=ÂS*«¦¨=¦¦A¡¦dq"v¦¬_p_t Ã ¡/x¢£tx*¦¤ ¢ ¦t¤*¢§©©¨5<Étp¢£¦d<q<¹rSÆ5¡r»Jp ¡x&°ÊdmÃ»«=¬<¦txp¦pÇx<¦¦¢5.J¦d¢£ tt_\¨ª¡x¦dYÈ`¢£«W_»*»x°©_¤¥»¦¢/¡«L(ÊSxÃ(¡<r¾Ã¾¦Hx*S¦ <«"¹¬tJÅ·t¡¾»x»x¡ JHp®*¯A¯xYq¢£¯¾¦¤Y<¦<xÃp¦d»xm(x<¨Ë<<®¦tA¦Íxd ¦dÌt tJÎ·¨v¡¦t ¦¡q©¤¾¦x¨/t»x< <¦¦d¬xt¹.»\<¬¦xtpd

(38) <¡.Y*xH®*H¯*©¦d¤&¦t¹ ¢5¡ Ï(ÐSÑWÒ¥ÓJÔÕ~Öd×v±(²"³ª´

(39) µp¶¾«p¯A{«p¢£¦dq«¾¢£_»x\<®Sdm¦d{«¾t ¡ ØÚÙ"ÛÜ YÝqÞ·ß Û Ý Ü ¸d*Ãt¡x<¡5(¦p¢~¨<¡¥tx»J**¦µcÃ¾Ã<p»J¦xtA_S ¡¦xi¦d*¤«*/¦¤S/d¤¬¦t¦¬¢ÍH¦¦**»J»H<«J *«=p¡q¯»*¨vd*«xtJ.<d¦x»x»\¦¢/¾»¡x¥.¯A<S 5¦t¢,<¥«»x°tx¡ <¦S<S<JH¹:àÇácâã¦t¢,Æ5±(¡²"

(40) ³ª´

(41) ¦µp¶t¦¬»x/t/¦d¦»SÃSª¦t¢L*¡d\° xtW¦dH¯¦dS¬<S ¢£¦3v¡¥x»xH°Í¬tÈd

(42) ¬t ¡ ¡¥txxrHH<Ã<Ãtt`c¹ *°är<»°5 ÈA¹,Æ5¡ *H¢£¦d±<¬Ã²"³ªv´

(43) ¦d¦tµp¢Ç¶¾¥« å áe»æç_pAtHp*¦Ã&<Çt¦t¢L Â° v¹¼è(±(é*êFëc²"ì§í³<´

(44) î Sïtµ©ìñ¶ðÂtò"¦Jór_ôxH¢£ëÀ¦dÁxî<ôx¬¬ë t&õvîmpö<x÷<.ømxì ùA©tëcìñ¦ ó ôit¨úmÇôJ¤·ëg»î<ø£¦ûH¢ÇAð¦÷ *î<_«3¹ <¯t&<ä¬Ã<tS¦d»x¦S©¦d¤SA¢£¦¦p¢Ç_t»x *¡¦txµgEÃ¾t»xxt ¢£x¦d¦¬Ã¾Æ5t¡x*¦Í¦d{Y¯*¹Âü©¿gH r¡<ÃJHtÇ¦t¯¢¦t¢ª±p²"¢ñ³ªpxY´

(45) tµpt¶r J*iÍ½<<_ä¬q¦q<p¦¾t¦SJ¬

(46) <t¦q¦ *S*½<SH¬H¦¯JS<¥S ¡xp»µg¯xJ«=ÁxE**qHH¦dxd«5<tSJ¦iý¨v¢£¦d*Ç<¡&SÃ°rÁJ¦»Jx/¦d©{¤¾¹¸»AÆ5Ç¡¦tH<¢\tH¦t»x¢£¦d¢"*d¦t¦¾«ªµg¦Ã¾±(<«{²"»x³t~´

(47) _*µ©¶ µ õ¡îHÍöH÷<øm¦ì ùA¬ëcìñóô.Ãõ/î < "¦ôJì§ëeAìñót¦ô

(48) Údðt <ô«S éxð S<îSþñÿÍtxÿ¢£¦m¹ S6¨ÿ

(49) ¦È¾Hx*x«t¦xH»xÌ*<xõ_pîHö<d÷H ømì ù`ëg¦dótør¬¦tþñÿ ¢Úm«*õpîHö<÷HxømHì ù`ëeÃìñ

(50) ótô ¡J`t÷ î<mí<îpþeÿ 5m«¦t*¢Útx¡ xÿ

(51) xH¹* ¦dÿ v¦dp Aÿ

(52) <°ÁJH

(53) *¡¬¦d p* »x¡m»_<¹vxÆ5E¡<ÿ

(54) ¬ÿ tS ¬¦¢"tx¡»x<Í¡x¦dtx

(55) p¡xtx¦

(56) ¨/¯A5H©¨¡<<H° \¦dHq¦d¦tA¢=¦x<<¨ Sÿ «`*¨vÍ¡tx (¡ÿÍ¬<«A¤(tx¯J ¡\H®¾<x¦d.x.¦¾°ÁJ¦d¦¢L<®¾p¬ÿ*¹ »Jpp_x¿Àq¦x<*ÃH°t¦d»x¦drvp¦¥¡x<d¡

(57) ¹p

(58) ÍtJptxx t¬ÿ

(59) ¤d*«t½<td_J ¬¡¬¬ÿ ¦S¦d*Hv¹=«S¿grª¡\33±(²3Hx¦d³ª´

(60) Hµ©¶ÌS¦ ¬

(61) 3J¦t¥¢{©x¦d<dS ¡dtt¬¢£¦=¦¨H.¦d±(d¦**±(¯<»*²""³ªþ

(62) ´

(63) ± ¯¾µp¶Ç¤

(64) ¡v

(65) <<¥¢£<¦¯A<<x ©"<¤¾

(66) ¦A¢Ú¦t±(«S¢§¨v©²"¨5¡³ªt ´ ¡ d<t_¬Í¢£»Çx© 5¡x\t ¡»° <¹ »x ¡Mx¦Íq_pt_tL ¨ª ¡¼¦d<(xtx«Í<ttE¦x«`<¯JS¦t¡EÍ¯¡»*q*¡x<H¤6*¦d¦<*µg¦dt¬¦{«`Ãd»x x¡Ep Y¢£¦t¢»±(²"³H®¾´

(67) µ© ¶6HþL¦{x¹«`t!xH¹H¦dxp»x¡S»J.¦{ « "#%$'&)(%*+$,#%&)(-$/.10324-$)56,&).7-!08:9;<*0>=6?-$'$)*@'AB-!0=%*0%?*C&)-DE FHG

(68) E%DI,J0%KML DE FHG

(69) EDN,J0K38POQF56,J.7RS8Q(5 (,J0%KMTN??!E 0%?+&)#UE *V=3#UE &HWCX3YZ*+R1*+A(-J0*!8[9]\J\!^_La`bFHc!dJ`<eV\J^3e!X"<f/g8>[9]\!\!^!La`FHc!dJhJ`!hJ\!`!i!cJdJ`3eVdJj<e "E FHk:EBk(>,J0%K%8POlF 56,.7R]8Q#\!\<e!eV\J`!`!TN??!E 0?+&)#E *V=%#E & W DE FHk:ED:#>,J0%K%8mOlF56,J.7RS8P(<#,J0KJ(BTN??JE 0%?+&)#UE *V=3#UE &HW.

(70) ¦¡¨5¦3µgÃtÃ<_,¢£Y¦¢£»xqx¦rm¹*

(71) ¦dpx<q«L"p»Jt ¬¡&t¬dp¢£\t¦dxp¤*p»x¡xtv <¡ ¦\¨/±(t5²"J±(³´

(72) ²"x³ªµ©¶Ç´

(73) ¯xµp¶H¬H*¦d¦ =¡H"¦¡x¦r ¹r*¯xÆ5Ãp¡ ¦d¤m<Ã¦dt¦»x¤S¤dJ<t=¢£_¨v»xt¡¦d_¤»*vªtxH¦dp.x¥tH¯¦dx¬*\¡`¬¦<¢`5<¦d¡S ¡d<¦¤.°<¡.¬<,¦¦dJ<¦Sp¡\«dH®*¨M<»*v ¡¡<q«¾t x¡x<Ã¾¬<¨þñ¡xt / ¡Y< _ ªx Ç_Y©/Ã¦¢£_»JL¢£¦¯°©t¤=¦¯¾¤¡Ã¾5»xt_©JÃ¾¯J_W¨ª¹ ,¦¾¦<¹ ¦x« feature extraction. standard description. search engine. ¹ ;<?-!AB*C-2mGPO:FHd x¡rÆ5¦t¡xS¢§©Ç¨5xt¦dJÇ Í¡¦*_dmH»¯J½<_¦tE¢

(74) ¡x¾¢£\¦_m_¦¹¨/x¹¹ ¾¡_m¢£_¹<Yx*¤_<¦t¯Ap¢£H¦d

(75) ®qt¡¹¬Æ5¡¦trÍÃ*t<t¦<S¯J_p¡¤*pJ <¾_¡m*_Ç¹x*¹ ¦&ü©¾t_mxm__¹ ¹¾t_ < m¦¡_¹x<YH»x»¦

(76) A¦d¡µ JtA<_¹ , Ù Ý( Û Û Ý Ü ±Et¥¾»x¤° `<<&Sr©t¤¾ A ¡·¬<¦x¢\Y©¤¾<¦dx¤·r<¡xd¸¯J¦*¨v<Ãd<¦ A¡Â¯xYdp_¦d¦dSÂt¡½<E±(²"x³ª´

(77) µp¶&¦*HJ__HxÁJ<t¡x¦x¹ H xµÀ¦ H®¹tÆ5¡ « ¡H*¬¦dx¤.Ì<¦x¦A<¥ <Ã¦J<«ÚÚpxtJ¡t &qÿ

(78) ¦(ÍtÃxE»Jÿ*«`¡¯<»*ÌÍA°Í<¢£

(79) ¦¬Ètx¤<¡J¹

(80) ¨¥*x<<»x(¦Y<_<_«{t¡xr<±(²"¦d³ª*´

(81) µÀpµpA¶ <

(82) °ÁJ± ¬ÇrH¦d¤¦dHStÃ½<p_¦q¢§©¨¦(*ÌH¦d_¹xp °¡¦»d¡x¡<Í®¾x Hm»x*¦d_"

(83) !r¬¢£t<¨2 ¡¯JYÇ¦¾»¦Í/¦t¡x¢»xÇ<t.Exx*<¦ÃSJ*¦d»xt"ÿ

(84) Ì¬x<þe¨2txÿÍ"!

(85) ¦\xÿ*ÿ

(86) *<«Wx

(87) ° ¡J=¦\ ¡t»¯xJ¦Spv_p<»«x¨J5¦dp_<_¹LÆ5

(88) ¡/xxtp¢£¦¯x 5¡xp»=xJ¦¦d"p"¦=¤Ì<¦*S*»xtH¾_¢£,¦d"t ¦©¤¾¡< ¦d¥»*»x°»«¯»*\3t¦Í¯x¡<x=»x=xt¤¾¦d{½<¹ #

(89) x¡¦ Av<*¢£¦Ã<¬¦txx<

(90) ¦¥¢~xt<q¨6t*_¦d<¡x*.¦d¹LtÍJdr¦d»v¬H¦d¡\x±(t²"¦³ªY´

(91) Hµp®¾¶¥ Ht¦YY_xpY_t¬ t¡ ¡¦d5Sd¦¦¥°©¨¡¬¦% $S¡<

(92) ¦d¦¡¹ 5

(93) 5x*ÍÃ<¦x¦d¤ x<¨z¦d{«*¨v¡ ¡.vH¦dA¦d¦.¦t¢,H®*p¬*_<*¦Jxqt¦d¡¬¹ ¦d" Hx!¦¬*Çt¦d (¨I¡*_ ¬<d©¦*»x°H¦¡»ã*<JvÃd<px¢£¦¦dq¬t¹\d¦d_¿g«W\¨v¡Í¬¡x¡5Ç_¨*¢£»x=¤t¹ª°¢3¨\Í¡x¡Ã¦Ã¨2»J»xtEÇH¢£»¡¾,ÃSÌ¡¦¬¨v*¤.<SH*