國
立
交
通
大
學
電機學院通訊與網路科技產業研發碩士班
碩
士
論
文
遠端桌面下建構多媒體串流服務
Multimedia Streaming Services On Remote Desktop
研 究 生：鄧如宏
遠端桌面下建構多媒體串流服務
Multimedia Streaming Services On Remote Desktop
研 究 生：鄧如宏
Student：Ju-Hung Teng
指導教授：張文鐘
Advisor：Wen-Thong Chang
國 立 交 通 大 學
電機學院通訊與網路科技產業研發碩士班
碩 士 論 文
A ThesisSubmitted to College of Electrical and Computer Engineering National Chiao Tung University
in partial Fulfillment of the Requirements for the Degree of
Master in
Industrial Technology R & D Master Program on Communication Engineering
August 2009
Hsinchu, Taiwan, Republic of China
遠端桌面下建構多媒體串流服務
研究生：鄧如宏 指導教授：張文鐘 博士
國立交通大學電機學院產業研發碩士班
摘要
本論文主要是利用串流技術，解決遠端桌面程式在播放影片，造成網路流量暴增的 問題。當使用者點選影片播放，不直接在Server 端電腦執行播放程式，而是由串流伺服 器將影片串流。再由Client 端接收串流資料並且播放影片。我們採用遠端桌面程式rdesktop 和多媒體播放器 MPlayer。由於 rdesktop 和 MPlayer 兩個程式的顯示視窗是獨立分開的，而使用者僅使用rdesktop 來操作遠端電腦。所以必 須透過IPC 的方式，將 MPlayer 解碼後的影像資料傳給 rdesktop。rdesktop 在主視窗下 建立一個子視窗，將影像資料顯示在上面。由於 Windows 遠端桌面服務程式是無法更 改，所以透過外加自行撰寫的串流伺服器，完成影音控制和傳送的功能。最後將 Client 端的程式移植到以Intel XScale PXA270 為核心的嵌入式平台。
Multimedia Streaming Services on Remote Desktop
Student：Ju-Hung Teng Advisor：Dr. Wen-Thong Chang
Industrial Technology R & D Master Program of
Electrical and Computer Engineering College
National Chiao Tung University
ABSTRACT
Our research uses streaming technology to solve the data burst during video playback on remote desktop. When the user clicks a video file, the server doesn't play the video file but passes the file to a streaming server. Then the client connects to the streaming server and plays the file.
We use a remote desktop client - rdesktop and a multimedia player - MPlayer. Rdesktop and MPlayer have their own display window, but the user only uses rdesktop to control the remote computer. So MPlayer passes the decoded frames to rdesktop through IPC. Rdesktop creates a child window and displays the decoded frames on it. Because that we can't modify Windows remote desktop service, we add our own streaming server to send the control command and transmit the streaming media. In the end, we port the client program to an Intel XScale PXA270 based embedded system.
致謝
碩士生涯這兩年，首先感謝的是我的指導教授張文鐘博士，感謝老師於學業上的教 導，我才能夠順利完成碩士學位。同時也感謝范國清教授、黃仲陵教授及何文楨主任於 口試時的指導，有了您的指導才使得這篇論文更趨完善。 另外，感謝實驗室同學們，志偉、盛如、弘達、琮壹、秉謙和建民，感謝你們陪我 度過兩年碩士生涯，與你們一同修課研究的歲月裡是值得珍惜及懷念同時也感謝實驗室 學弟妹，耀葦、明穎、怡如和雅嵐在研究上給予的支持，。 最重要的要感謝我的父母，有你們的支持，讓我在經濟上、生活上沒有任何負擔， 有你們的陪伴，我才能無後顧之憂的完成學位。感謝我的女朋友姿萱，在我挫折時給我 的鼓勵，在我失敗的時候給我支持。 最後，感謝這兩年曾給我協助、給我鼓勵的朋友們，謝謝你們。 誌於2009.夏 新竹。交大 如宏目錄
摘要 ... i ABSTRACT ... ii 致謝 ... iii 目錄 ... iv 表目錄 ... vii 圖目錄 ... viii 第一章 緒論 ... 1 1.1 研究背景 ... 1 1.2 研究動機和目標 ... 1 1.3 研究方法和步驟 ... 3 1.4 論文架構 ... 4 第二章 相關知識及背景介紹 ... 5 2.1 遠端桌面系統介紹 ... 5 2.1.1 VNC ... 5 2.1.2 RDP ... 6 2.1.3 X Window ... 6 2.1.4 遠端桌面程式比較 ... 7 2.2 X Window 的 Client/Server 架構 ... 8 2.2.1 X Window 的網路透明性 ... 8 2.2.2 X Window 的視窗建立及繪圖功能 ... 9 2.2.3 XImage 和 mp_image_t 結構 ... 12 2.3 網際網路影音分享 ... 14 2.3.1 True Streaming ... 14 2.3.2 Progressive Download ... 152.3.3 Download and Play ... 15
2.4 多媒體播放器介紹 ... 15
2.4.1 VLC Media Player ... 16
2.4.2 MPlayer ... 16
2.4.4 播放器比較 ... 18
2.5 利用 Named Pipes 進行 IPC ... 19
2.5.1 建立 Named Pipe ... 20 2.5.2 開啟 Named Pipe ... 20 2.5.3 使用 Named Pipe ... 20 2.5.4 Named Pipe 的優缺點 ... 21 2.6 嵌入式系統 ... 21 2.6.1 ARM ... 22 2.6.2 Linux ... 23 2.7 開發環境 ... 24 2.7.1 硬體連接 ... 26 2.7.2 軟體架構 ... 27 2.8 開發板 ... 28 第三章 MPlayer 程式 ... 31 3.1 Open Stream 函式 ... 33 3.1.1 Open Stream 函式運作流程 ... 38 3.1.2 HTTP 模組開檔流程 ... 41 3.2 Cache2 機制 ... 43 3.2.1 HTTP Cache2 開啟流程 ... 44 3.2.2 Cache2 運作流程 ... 45 3.3 Video Filter 模組 ... 49 3.4 Video Output 模組 ... 53 3.4.1 vo Video Filter ... 57 3.5 Video Chain 開啟流程 ... 59 3.6 Video Path 資料傳遞 ... 65 3.6.1 初始化 ... 65 3.6.2 影像播放流程 ... 69 第四章 Client 端和 Server 端實作 ... 71
4.1 Rdesktop Plugin Output 模組 ... 71
4.2 Rdesktop 程式 ... 77
4.2.1 MPlayer_Control_Thread()函式 ... 78
4.2.2 MPlayer_Display_Thread()函式 ... 79
4.3 Rdesktop Media Server ... 81
4.3.1 TCP Socket Server ... 81 4.3.2 Web Server ... 82 4.3.3 運作流程 ... 87 4.3.4 程式畫面 ... 89 4.4 系統流程 ... 90 第五章 實驗結果 ... 92 5.1 TCP 封包分析 ... 92 5.1.1 播放影片封包分析 ... 92 5.1.2 播放影片流量控制 ... 94 5.1.3 播放影片時流量 ... 96 5.1.4 播放影片時 Cache2 狀態 ... 98 5.2 實驗數據比較 ... 98 5.2.1 資料量比較 ... 100 5.2.2 平均流量比較 ... 101 5.3 嵌入式平台 ... 101 第六章 結論 ... 104 6.1 結論 ... 104 6.2 未來發展 ... 105 參考文獻 ... 106 附錄一：加入rdp 影像輸出模組 ... 107
表目錄
表1-1. VNC 和 RDP 播放影片的資料量 ... 2 表1-2. VNC 和 RDP 播放影片的平均流量 ... 2 表2-1. 遠端桌面系統比較 ... 8 表2-2. 播放器比較 ... 18 表2-3. 嵌入式系統和個人電腦硬體比較 ... 22 表2-4. 嵌入式系統和個人電腦軟體比較 ... 22 表2-5. XSBase270-Module 硬體配置 ... 29 表2-6. XSBase270-EDR 硬體配置 ... 29 表2-7. EELIOD 軟體配置 ... 30 表3-1. stream_info_t 結構成員 ... 33 表3-2. stream_t 結構成員 ... 34 表3-3. streaming_ctrl_t 結構成員 ... 36 表3-4. URL_t 結構成員 ... 37 表3-5. MPlayer 內建的開檔模組 ... 40 表3-6. MPlayer MIME 表 ... 42 表3-7. cache_vars_t 結構成員 ... 43 表3-8. vf_info_t 結構成員 ... 49 表3-9. vf_instance_t 結構成員 ... 51 表3-10. vf_format_context_t 結構成員 ... 53 表3-11. vo_functions_t 結構成員 ... 54 表3-12. vo_info_t 結構成員 ... 55 表3-13. vo 影像濾波器函式對應表 ... 59 表3-14. MPlayer 內建的影像輸出模組 ... 61 表5-1. 三個解析度的影片資訊 ... 100 表5-2. 資料量比較表 ... 100 表5-3. 平均流量比較表 ... 101圖目錄
圖1-1. VNC 和 RDP 播放影片的平均流量 ... 2 圖1-2. 系統架構圖 ... 3 圖2-1. XImage 結構成員 ... 12 圖2-2. XImage data 指向的圖像資料 ... 13 圖2-3. mp_image_t 結構成員 ... 13 圖2-4. mp_image_t plane[]指向的圖像資料 ... 14 圖2-5. VLC 0.9.9 (Windows) ... 16 圖2-6. gMplayer (Linux) ... 17圖2-7. Windows Media Player 11(Windows) ... 18
圖2-8. 半雙工通訊 ... 19 圖2-9. 全雙工通訊 ... 20 圖2-10. 文字命令模式建立 Named pipe ... 20 圖2-11. 程式內建立 Named pipe ... 20 圖2-12. 軟體開發流程 ... 25 圖2-13. 開發環境硬體連接 ... 26 圖2-14. 開發環境軟體架構 ... 27 圖2-15 華亨科技 EELIOD ... 29 圖3-1. 播放流程基本架構 ... 31 圖3-2. MPlayer 播影像的基本流程 ... 32 圖3-3. HTTP 的 stream_info_t 結構資料 ... 34 圖3-4. VCD 模組 open_s()部分程式碼 ... 36 圖3-5. Open Steam 流程圖 ... 38 圖3-6. open_stream_full()的程式碼 ... 39 圖3-7. HTTP 模組開檔流程 ... 41 圖3-8. HTTP 請求訊息 ... 41 圖3-9. Web Server 回覆訊息 ... 42 圖3-10. HTTP Cache2 開啟流程 ... 45 圖3-11. Cache2 啟動流程圖 ... 45 圖3-12. Cache2 初始化的程式碼 ... 46 圖3-13. Cache2 填充資料的流程 ... 47 圖3-14. Cache2 的運作流程 ... 48
圖3-15. Cache2 cache status ... 48
圖3-16. flip 模組的 vf_info_t 結構資料 ... 50
圖3-17. vf_open_plugin()函式的部分程式碼 ... 50
圖3-18. flip 模組的 open()函式 ... 50
圖3-20.利用巨集指定 vo_functions_t 結構成員資料 ... 54 圖3-21. x11 模組的 vo_info_t 結構資料 ... 55 圖3-22. vo 影像濾波器的 open()函式 ... 57 圖3-23. vo 模組的 query_format()函式 ... 58 圖3-24. vo 模組的 get_image()函式 ... 58 圖3-25. vo 模組的 put_image()函式 ... 58 圖3-26. Video chain 架構 ... 60
圖3-27. Video Filter chain 架構 ... 60
圖3-28. Video chain 開啟流程 ... 60 圖3-29. reinit_video_chain()階段 1 和階段 2 的程式碼 ... 61 圖3-30. Video chain 階段 1 ... 62 圖3-31. vo 影像濾波器的 open()函式 ... 63 圖3-32. Video chain 階段 2 ... 63 圖3-33. reinit_video_chain()階段 3 和階段 4 的程式碼 ... 64 圖3-34. append_filters()的程式碼 ... 64 圖3-35. Video chain 階段 3 ... 65 圖3-36. Video chain 階段 4 ... 65 圖3-37. ffodivx 的 codecs.conf 訊息 ... 66 圖3-38. mpcodec_config_vo()部分程式碼... 67 圖3-39. 影像播放流程 ... 69 圖3-40. Video Chain ... 69 圖4-1. rdp 模組的 info 資訊 ... 72 圖4-2. rdp 模組的 control()函式... 72 圖4-3. rdp 模組的 config()函式第 1 部分 ... 73 圖4-4. 建立和刪除 XImage 函式 ... 73 圖4-5. rdp 模組的 config()函式第 2、3 部分 ... 73 圖4-6. rdp 模組的 draw_slice()函式... 74 圖4-7. rdp 模組的 flip_page()函式 ... 74 圖4-8. rdp 模組的 uninit()函式 ... 75 圖4-9. rdp 模組的 draw_osd()、draw_frame()、check_events()函式 ... 75 圖4-10. rdp 影像輸出模組流程 ... 76 圖4-11. 寫入資料到 fifo ... 76 圖4-12. rdesktop 的主要流程 ... 77 圖4-13. MPlayer_Control_Thread()流程圖 ... 78 圖4-14. 從 fifo 讀取資料 ... 80 圖4-15. MPlayer_Display_Thread()流程圖 ... 80
圖4-16. Rdesktop Media Server ... 81
圖4-18. IdHTTPServer 元件 ... 82 圖4-19. OnCommandGet 事件流程 ... 83 圖4-20. MPlayer 請求檔案 ... 84 圖4-21. MPlayer 請求部份檔案 ... 84 圖4-22. Web Server 200 回覆訊息 ... 84 圖4-23. Web Server 206 回覆訊息 ... 85 圖4-24. Web Server 404 回覆訊息 ... 85 圖4-25. 檔案傳送流程 ... 86
圖4-26. Rdesktop Media Server 運作流程 ... 88
圖4-27. Rdesktop Media Server 程式畫面 ... 89
圖4-28. Rdesktop Media Server 程式畫面(傳送檔案) ... 89
圖4-29. 連線流程 ... 90
圖5-1. Rdesktop Media Server 傳送 PLAY 指令 ... 92
圖5-2. MPlayer 和 Rdesktop Media Server 建立 TCP 連線 ... 93
圖5-3. MPlayer 送出 HTTP 請求訊息 ... 93
圖5-4. Rdesktop Media Server 回傳 HTTP 回應訊息 ... 94
圖5-5. Rdesktop Media Server 開始傳送影片資料 ... 94
圖5-6. Receiver window size 變小... 95
圖5-7. TCP ZeroWindow ... 95
圖5-8. TCP ZeroWindowProbe ... 95
圖5-9. TCP Window Update ... 96
圖5-10. 播放影片流量圖 ... 97
圖5-11. Client 端 TCP window size ... 97
圖5-12. 播放影片 Cache2 的狀態 ... 98 圖5-13. 資料量比較圖 ... 100 圖5-14. 平均流量比較圖 ... 101 圖5-15. 系統架構圖 ... 102 圖5-16. 嵌入式平台執行 rdesktop 的畫面 ... 103 圖5-17. 嵌入式平台播放影片的畫面 ... 103
第一章 緒論
1.1 研究背景
隨著電腦硬體技術和無線通訊技術的進步，行動上網裝置(Mobile Internet Decive) 越來越普及。現代的人們可以透過行動上網裝置，隨時隨地的上網瀏覽網頁、收發 E-mail、聊 MSN 或是分享影音資料。行動上網裝置的計算能力、儲存空間有限，可以 透過遠端桌面程式，操控家中或是辦公室的電腦，將一切的資料處理和計算留在遠端電 腦執行。行動上網裝置當成終端機，將鍵盤輸入、滑鼠操控訊息透過無線網路傳送到遠 端的電腦，遠端的電腦再將處理完成的畫面結果傳回。 現今網路技術發達，加上多媒體影音壓縮的進步，透過網路分享影音資訊越來越普 及。由於行動上網裝置的儲存空間有限，所以這些多媒體影音檔案大多存放在遠端的電 腦。如果使用者在家中或是辦公室的電腦存放了許多的多媒體影音檔案，使用者最方便 存取遠端電腦的檔案，就是透過遠端桌面程式，直接點選開啟。但是目前遠端桌面程式 共同的問題－播放影片將造成網路流量暴增！
1.2 研究動機和目標
目 前 市 面 上 有 許 多 的 遠 端 桌 面 程 式 ， 如 VNC、Microsoft 的 Remote Desktop Protocol(簡稱 RDP)、X Window…等。遠端桌面程式運作方式，是取得 Server 畫面的變 動資料，然後將這些變動的畫面資料傳送給 Client。Client 將接收到的畫面資料更新到 視窗上。對於一般操作模式，如文書處理和瀏覽網頁，並無太大問題，因為畫面更新的 頻率和資料並不大。但是如果使用者點選影片播放，這個畫面更新率最高可能到每秒30 個frame。雖然 VNC 和 RDP 對於更新的畫面採用壓縮的方式傳送，但是那些壓縮方式
表1-1. VNC 和 RDP 播放影片的資料量 解析度 320*136 480*204 848*352 檔案大小(Kbytes) 5,691 16,353 43,141 位元深度(bpp) 24 24 24 影片長度(s) 135.18 135.18 135.18 更新率(fps) 23.976 23.976 23.976 資料率(kbit/s) 339.77 986.17 2610 VNC (Mbytes) 275.75 495.09 582.99 RDP (Mbytes) 269.23 609.52 889.27 表1-1 為實際播放三種不同解析度的影片，分別為 320*136、480*204 和 848*352， 在影片長度、網路環境和電腦硬體相同情況下所需要的頻寬大小。從表可以得知，隨著 解析度的增加，所需要的頻寬越高。採用 RDP 播放解析度 848*352、長度 135.18 秒的 影片，流量竟然高達889.27Mbytes！平均每秒所需頻寬為 6.578Mbytes/s (約 53Mbps)， 以目前家庭光纖網路頻寬下載10Mbps/上傳 2Mbps，這頻寬是不能夠負荷。若是播放解 析度320*136，也是需要 1.992Mbytes/s (約 16Mbps)的速度。 表1-2. VNC 和 RDP 播放影片的平均流量 解析度 320*136 480*204 848*352 VNC (Mbytes/s) 2.040 3.662 4.313 RDP (Mbytes/s) 1.992 4.509 6.578 圖1-1. VNC 和 RDP 播放影片的平均流量
使用VNC 程式播放影片，頻寬需求比 RDP 少，但仍然很大。不論採用 RDP 或 VNC 播放影片，除了資料量暴增外，影片播放過程並不順暢。本研究主要目標是改善 RDP 遠端桌面程式播放影片的資料量暴增和順暢度的問題。最後將 Client 端程式移植到以 ARM 為核心的嵌入式平台。
1.3 研究方法和步驟
本研究提出的改善方法：利用影音串流方式，將Server 的影片傳送到 Client，並由 Client 端的多媒體播放器播放影片。因此必須要先了解播放器的運作方式、遠端桌面程 式視窗畫面運作和多媒體影音串流，如此才得以實現該系統。最後移植到以ARM 為核 心的嵌入式平台，這必須要了解將程式從x86 移植到 ARM 的過程和方式。 圖1-2. 系統架構圖 圖1-2 為本研究的系統架構，左邊為 Client 端，右邊為 Server 端，兩者以網際網路 作溝通。在Client 端採用 Linux 為作業系統，rdesktop 為 Remote Desktop Client，MPlayer 為多媒體播放器。在Server 端，Remote Desktop Services 為 Microsoft Windows 的 RDP Server，Rdesktop Media Server 為影音串流伺服器。將細節約略分為以下步驟：1.了解 MPlayer 播放器的程式架構： z MPlayer 影像播放流程
z MPlayer 影像輸出模組 2.了解 rdesktop 的視窗運作：
z Linux x11 的視窗運作模式 z 利用 Named pipe 進行 IPC 3.系統實作 z 撰寫 MPlayer 影像輸出模組 z 新增播放器控制和影像顯示到 rdesktop 程式 z 撰寫影音串流伺服器 z 系統整合 4.程式移植 z 建置 ARM 平台的開發環境 z 編譯 ARM 用的程式庫 z 移植程式
1.4 論文架構
第三章將介紹 MPlayer 的開檔模組、影像濾波器和影像輸出模組。並且說明建立 video chain 流程，這將決定影像解碼器模組、影像濾波器和影像輸出模組。最後解說解 碼後的圖像資料在模組間是如何的傳遞。第四章說明整個系統的實現，包括建立MPlayer 的 rdp 影像輸出模組、修改 rdesktop 程式和撰寫 Server 端的串流伺服器。第五章分析 Progressive Download 串流方式如何利用 TCP 封包進行流量控制。最後比較 VNC、原本 的RDP 和本研究的 RMS 系統播放三種不同解析度影片所需要的網路流量。第二章 相關知識及背景介紹
2.1 遠端桌面系統介紹
目前市面上有許多遠端桌面程式，在此就不全部介紹，僅選出較常用的三個來介 紹，並淺要地分析他們的原理，和比較各項特點。
2.1.1 VNC
Virtual Network Computing[1](VNC)是現行的遠端桌面連線系統之一，最初發展是在 1995 年由英國劍橋的 Olivetti & Oracle 實驗室發展出來，公開且免費的通訊協定，至今 已發展多種版本，為跨平台的遠端桌面連線程式。目前延伸的版本有 cotVNC、 EchoVNC、RealVNC、TightVNC 和 UltraVNC。
VNC 透過 Remote Frame Buffer (RFB) Protocol 控制遠端的電腦，VNC 為一套跨平 台的應用程式，在操作端安裝VNC Viewer 就是我們所說的 Client，在遠端的電腦安裝 VNC Server，允許多台 Clients 在同一個時間連接同一個 Server，另外，也可透過 JAVA Applet 使用網路瀏覽器連接到安裝 VNC Server 的電腦。VNC 的架構可以分為 VNC Server 和 VNC Client(Viewer)，彼此溝通的通訊協定為 RFB Protocol。
z VNC Server：負責接收 Client 傳送過來的鍵盤或是滑鼠的輸入訊號後，並提供一 套桌面分享機制，透過TCP/IP 傳送畫面改變的資料到 Client。
z VNC Client：根據收到的資料，在將 Client 端顯示 Server 的畫面，並依照接收 到的資料做更新。
z RFB Protocol：一個簡單的原則，將 Server 端某塊寬(W)、高(H)點陣圖(bitmap) 的資料，放到螢幕指定的X、Y 座標上。
2.1.2 RDP
Remote Desktop Protocol[2]，簡稱 RDP。RDP 是微軟根據 ITU T.120 協議系列所制 定的一套未公開發表的數據通訊協議。透過網路連接RDP Server 將應用程式顯示畫面 傳送到RDP Client，RDP Client 將滑鼠、鍵盤等輸入訊息傳送給 RDP Server。在畫面傳 送上，是以命令(order)為操作方式，可以分為 primary order 和 secondary order，Primary order 主要的工作在於處理線條、矩形或是出現過的點陣圖和文字，Secondary order 則 是傳遞首次出現的bitmap 和文字。在終端服務的桌面圖形傳輸上，畫面中 bitmap 的傳 送，可以說是主要的資料量。
RDP 的 bitmap 傳送方式有兩種方式：
1. RDP Server 先利用 secondary order 的 bitmap cache 將 bitmap 傳送到 RDP Client 暫存起來，隨後傳送一個 memory blt 將 cache 中 bitmap 資料，依據 cache id 和cache index 取出指定的 bitmap，顯示在螢幕對應的位置上，主要畫面傳送都是利 用這樣的方法。
2. RDP Server 直接傳送 bitmap 資料，並給予座標位置，RDP Client 收到後，直 接將資料顯示在畫面上。傳遞的bitmap 通常為視窗的外框或是工作列表邊緣線，因 此，在畫面傳送上佔很小的比例，這部份的畫面更新方式稱為bitmap updates。 2.1.3 X Window X Window 系統[3](也常稱為 X11 或 X)是一種以點陣圖方式顯示的視窗系統。最初 是1984 年麻省理工學院的研究，之後變成 UNIX、Linux 等作業系統所一致適用的標準 化軟體工具套件及顯示架構的運作協定，經過二十多年的演進，現今已成為工業標準。 X Window 與一般的作業系統不同，在設計時就是以 Client/Server 為理念，整個 X Window 可以分為幾個部份：X Server、X Client、X Protocol 和 X Library。
z X Server：負責控制顯示卡將影像畫在顯示器上，並且管理鍵盤和滑鼠的事件， 產生視窗、對應視窗及刪除視窗，這部份要特別說明，與一般的Client/Server 名 詞定義有點差異，X Server 定義為 Display Server，而應用程式端稱為 X Client。
z X Client：在 X Window 下的應用程式，要求特定的 X Server 作特定的動作。主 要的工作為：1、向 X Server 提出需求，2、接收來自 X Server 的事件訊息，3、 接收來自X Server 的錯誤訊息。
z X Protocol：X Client 和 X Server 的通訊協定，定義 Requests、Reply、Error 和 Events，2.2.1 節有詳細說明。
z X Library：簡稱 X Lib，大部分 X window 上的應用程式以 X Library 來建立 GUI 元件，例如：按鈕(bottom)、目錄(menus)等等。 2.1.4 遠端桌面程式比較 根據先前介紹的遠端桌面系統，這節將對系統特性以及更新方式做個比較。 1. 畫面更新方式 Server 和 Client 之間的畫面更新方式可以分為以下幾種： z RAW：所有的更新圖片，不經過壓縮編碼，每個 pixel 的資料依序傳送，可以想 像資料量很大，假設傳送一張640 x 480 大小的 16 位元高彩圖片，就需要 614.4K Bytes。VNC 有支援這樣的編碼方式機制。 z 2D draw primitives：利用區塊填色的方法將圖形編碼，通常是一種非失真編碼的 方式，VNC 畫面編碼主要是以這樣的方法。
z Low level graphic：除了圖形編碼的方法之外，還利用一些簡單的指令，例如：字 型、多邊形、線條等等的指令呼叫 Client 繪圖，RDP 便是利用這樣的更新方式 進行畫面更新。
z High level graphic：除了 2D draw primitives 和 Low level graphic，還支援視窗的 建立和管理，X Window 所利用的 X Protocol 就是屬於這類。
2. Server/Client 訊息傳遞方式
Server 和 Client 的訊息傳遞方式主要可以分為兩種，Server Push 就是由 Server 主 動決定何時傳送更新畫面到Client；Client Pull 就是由 Client 向 Server 要求傳送更新，
是只有在使用者輸入訊息時，才會通知Server 作畫面更新的傳送，但是其資料量較少。 瞭解了畫面編碼方式及系統更新方式，根據這些特點我們將針對這幾個系統做分析比 較，說明如表2-1。
表2-1. 遠端桌面系統比較
系統 畫面編碼方式 更新方式 壓縮方式 cache license
VNC Compressed Pixel Data Client pull 2D draw
primitives
Client frame
buffer GPL
RDP Low level graphics Server push 2D RLE YES proprietary
X window High level graphics Server push none NO GPL
2.2 X Window 的 Client/Server 架構
2.2.1 X Window 的網路透明性
由於X Window 系統採用網路訊息協定作為應用程式(X Client)和顯示介面(X Server) 的溝通管道，而不是一般作業系統常見的函式呼叫，X Client 和 X Server 之間就是夠過 可靠的位元組資料流作為溝通。一般來說，如果X Client 和 X Server 在同一台電腦，就 以內部程序通訊(IPC，InterProcess Communication)方式溝通;如果 X Client 和 X Server 在不同的機器上，利用程式介面X Lib 透過可靠的網路協定(例如：TCP/IP)進行溝通。X Protocol 定義了四種封包做為溝通的機制。[9] z 請求(Request)：客戶端請求伺服器的資訊，或者請求伺服器執行一個動作。 z 回應(Reply)：伺服器回應請求。但是並非所有的請求都會產生回覆。 z 事件(Event)：伺服器傳送事件給客戶端，例如，鍵盤或滑鼠的輸入，或移動、 調整視窗。 z 錯誤(Error)：如果請求無效時，伺服器會傳送一個錯誤封包。
當X Client 要向 X Server 發出要求(Request)時，可透過網路向執行的 X Server 發出 要求，然後交給X Server 處裡。X Server 向 X Client 通知事件(Event)時，也可以透過網 路傳送。Request 和 Reply 的封包沒有長度限制，而 Event 和 Error 則有固定 32 bytes 的 長度限制。網路透明化的性質，就是不同機器上的應用程式可以在同一台電腦上顯示結 果，這樣的特性乃是X Window 不同於其他系統的一大特點。
2.2.2 X Window 的視窗建立及繪圖功能
瞭解了X window 的架構及網路透明性，我們的重點還是視窗的建立和影像畫面的 繪製與傳遞，關於X Window 的視窗建立和繪圖功能，X Window 提供了一些原則：
z X Server 將螢幕規劃為可重疊的視窗階層(window hierarchy)，每個應用程式可 以使用多個視窗，依實際需要，重新規劃大小、位置。每個GUI 中，視窗就是 一個頂層視窗(Top Level Window)，除了根視窗(Root Window)以外，每個視窗 都有一個Parent Window，也就是說，Client 建立一個視窗就是在現存的視窗下 建立一個子視窗，所以Client 所建立的視窗都是以樹狀結構去建立的，樹狀結 構的根就是root window。 z X Server 的繪圖是立即性的，X Server 並沒有儲存繪圖序列的動作，而是收到 資料後立即繪出畫面。X Window 繪圖是以位元對映(bit-mapped)導向，所有繪 圖動作均以視窗定位，因此X Client 可以在視窗內畫出東西，而不用考慮視窗 在哪個地方。
z X Window 顯示圖片(images)，由於影像的資料量很大，X Lib 提供了一個 XImage 結構，允許使用者操作影像。
X Client 和 X Server 之間的交談，X Server 存放了資源(Resources)提供 X Client 使用 識別碼(identifiers)操作，以下對各個資源做說明。
z 視窗(window)：這項資源是工作站上的矩型面積，使用者可利用視窗來觀看輸 出結果，當應用程式產生需要顯示的圖形時，必須指定一個視窗來輸出。每個
z 繪圖環境(graphical contexts,GC)：這部份是用來追蹤圖形的屬性，例如：前景 顏色、背景顏色、線條寬度、字型等等。每一個圖形輸出的請求必須參照GC， X Window 提供 X Client 請求產生、改變或是刪除一個 GC。
z 字型(fonts)：這項資源包括了在視窗上顯示文字有關的資料，描述一組文字的 大小及樣式，這部份X Server 通常有字型可供選擇，X Client 說明字元大小、 字元空間、字體，利用編碼(ASCII、ISO Latin-1 等)由 X Server 顯示。
z 顏色對映表(color maps)：這項資源將應用程式所輸出的圖形資料轉換成視窗畫 面上可見的顏色。 z 圖素對映表(pixmaps)：這樣資源和視窗很相似，主要的差別在於使用者無法在 畫面上看到，對於X Client 和 X Server 之間複製資料相當有用。 當X Client 向 X Server 請求建立某個資源的時候，同時也指定了一個識別碼給特定 的資源，例如：建立一個視窗的時候，X Client 指定了視窗的屬性和識別碼，這個識別 碼便和這個視窗關聯。X Client 為了避免衝突，這些資源不可有相同的識別碼，資源建 立後，識別碼就成為X Client 和 X Server 溝通的特定識別。當建立資源的 X Client 關閉 和X Server 的連線後，資源就會正常解除(destroy)。 這些繪圖的功能與處理程序都交由X Library 來實現，X Lib 是建立於 C 語言的函 式，Client/Server 通訊協定都仰賴這個函式庫來完成，現行有些 X Window 高階的程式 語言(例如：GTK+)，就是建構在 X Lib 函式庫的基礎上。 建立視窗的基本流程如下： 1.初始化流程(宣告結構、抓取環境變數) Display* display; char *display_name=getenv("DISPLAY"); 2.連線到 X Server display=XOpenDisplay(display_name); 3.X 相關初始化(設定視窗大小) screen_num=DefaultScreen(display);
height, border_width, border, background) 4.開啟視窗 XMapWindow(display, win); 5.當未結束 /*程式…*/ 6.關閉視窗 XDestroyWindow(display, win); 7.關閉 X Server 的連線 XCloseDisplay(display); 8.執行清除函式 建立XImage 結構並且將影像結合到視窗上的流程如下： 1.宣告變數 XImage *myximage; 2.讀取環境變數 int depth=DefaultDepth(display,screen); Visual *visual=DefaultVisual(display,screen); 3.建立 XImage 並且宣告圖像記憶體空間
myimage=XCreateImage(display, visual, depth, format, offset, data, width, height, bitmap_pad, bytes_per_line);
myximage->data=malloc(myximage->bytes_per_line * myximage->height);
4.將 XImage 顯示於視窗上
XPutImage(display, window, myximage, source X, source Y, destination X, destination Y, width, height);
XSync(display, False);
擷取鍵盤滑鼠訊息流程如下：
1.設定擷取的訊息
int input=KeyPressMask | KeyReleaseMask | ButtonPressMask | ButtonReleaseMask;
2.註冊擷取訊息的視窗
XSelectInput(display, window, input);
3.處理訊息
XEvent an_event; while(1){
XNextEvent(display, &an_event); switch (an_event.type) {
case: KeyPress: /*處理鍵盤按鍵訊息*/ break; case: ButtonPress: /*處理滑鼠按鍵訊息*/ break; default: break; } } 2.2.3 XImage 和 mp_image_t 結構 在X11 操作影像的函式都使用 XImage 結構，在此結構中所支援的操作包括建立影 像 XCreateImage()、刪除影像 XDestoryImage()、取得圖素 XGetPixel()、儲存圖素 XPutPixel()、取得影像中的次影像 XGetSubImage()和加一常數於影像中 XAddPixel()。 XImage 資料結構的內容已定義完整，結構成員如圖 2-1。結構成員存放圖像的基本資 訊，圖像的寬度、高度、色彩深度、每個像素所佔用的位元數和紅綠藍的元素遮罩。成 員有一個指標指向圖像資料，如圖2-2。
圖2-2. XImage data 指向的圖像資料
mp_image_t 結構(簡稱 mpi)是 MPlayer 專屬存放圖像資料的結構，結構成員如 2-3。 MPlayer 的模組間傳遞圖像資料都是用這個結構。成員有三個指標分別指向 YUV 三個 圖像資料，如圖2-4。XImage 和 mp_image_t 結構的最大差別就是前者是存放 packed RGB 格式，只需要一個指標指向圖像資料；後者是存放 planar YUV 格式，需要三個指標分 別指向不同分量的資料。
……… w h stride[0] bytes Y Y planes[0] ……… w>>chroma_x_shift h>>chroma_y_shift stride[1] bytes U U planes[1] ……… w>>chroma_x_shift h>>chroma_y_shift stride[2] bytes V V planes[2] 圖2-4. mp_image_t plane[]指向的圖像資料
2.3 網際網路影音分享
近年來網路的蓬勃發展以及影音壓縮技術的進步，透過網際網路分享影音資訊已經 非常普遍。在56K Modem 時代影音分享大都是 Download and Play，將整個影片下載完， 才進行播放。到了Cable modem 和 ADSL 時代，下載速率的提升，符合影音串流服務的 頻寬。而影音串流是將一連串的影像聲音壓縮，在網際網路上將資料分段傳送，以達到 即 時 影 像 觀 賞 的 服 務 。 接 下 來 介 紹 三 種 透 過 網 際 網 路 分 享 影 音 資 訊 的 方 法 True Streaming、Progressive Download 和 Download and Play。前兩種屬於串流技術，第三種 僅是單純的下載播放。[4]2.3.1 True Streaming
利用RTSP 進行串流服務，RTSP 是種 stateful 的 protocol。從 client 第一次建立連線 到最後和 server 中斷連線，這中間的時間 server 都要追蹤 client 的狀態。client 利用 PLAY、PAUSE 和 TEARDOWN 的命令和 server 告知目前狀態。client 和 server 建立程 序後，server 才開始傳送 RTP 的影音封包。RTP 封包可以使用 UDP 或是 TCP 傳送。UDP 是非連結導向的傳輸，封包可能遺失，但是傳輸快；而 TCP 是連結導向的傳輸，封包 遺失有重新傳送的機制，是種可靠傳輸。可以因應需求選擇 UDP 或是 TCP，如有些防 火牆會濾除UDP 封包，此時就會採用 TCP 的方式傳送。
率為 384kps 的影片，傳送速度大約是 384kps。client 緩衝器的資料約 1~10 秒的影片。 當播放暫停5 分鐘，僅需下載當時 1~10 秒的影片。
2.3.2 Progressive Download
Progressive Download 是介於 True Streaming 和 Download and Play 之間的方式，主 要是採用HTTP protocol。HTTP protocol 是種 stateless 的 protocol，client 和 server 要求 資料，server 就回應所要求的資料，server 並不會知道 client 的狀態。每個 HTTP 的連線 都是獨立的程序。當播放器從server 獲得足夠的影片資訊和資料即開始播放影片，使用 者不需要等待整個影片下載完成。在播放的同時，影片資料持續的下載到播放器的快 取，而播放器再從快取取得影片資料播放。Progressive Download 和 True Streaming 有兩 個主要差別。第一點，server 並非即時的在傳送檔案，當播放器快取的資料用完，而下 載速度卻低於影片編碼率，這時候會造成畫面停格。使用者只能等待更多的資料下載完 才可以繼續播放。第二點，最後完整的影片會被下載到使用者電腦。
2.3.3 Download and Play
將整個影片檔案下載到使用者的硬碟，再進行播放。使用者可以獲得高品質和順暢 的播放效果，但是換來的是先前的等待影片下載完成。下載到使用者硬碟，這意味著無 法防止非法複製，對於影片著作權有極大傷害。另外一點就是服務提供者的頻寬成本比 較高，當使用者只觀賞20%的影片，可是服務提供者卻支付了整個檔案的頻寬。
2.4 多媒體播放器介紹
目前市面上有許多播放器，在此列出比較常用的三種，VLC Media Player、MPlayer 和Windows Media Player，並淺要描述它們的特點。2.4.1 VLC Media Player
VLC[5]多媒體播放器是由 VideoLAN 計劃撰寫的免費開放原始碼的播放器。VLC 包含播放器、編碼器和串流器，並支援許多音訊和視訊解碼器和檔案格式。它可以透過 網路將檔案串流或是將多媒體檔案轉成其他格式儲存。VLC 是 VideoLAN Client 的縮 寫，但這原始意義已經不適用了。VLC 軟體許可是在 GPL 下。VLC 支援跨平台，提供 Microsoft Windows、Mac OS X、Linux、BSD 和 Solaris 的版本。
VLC 包含了許多免費的解碼和編碼程式庫。VLC 的許多 codec 是由 FFmpeg 計劃的 libavcodec 程式庫提供。libdvdcss 程式庫用來播放加密的 DVD 影片。 圖2-5. VLC 0.9.9 (Windows) z 支援許多影音格式，包含 MPEG-1、MPEG-2、MPEG-4、DivX、DVD/VCD、數 位衛星頻道。 z 支援 RTSP、RTP、MMS 和 HTTP 協定。 z 預覽 eMule 或 BitTorrent 下載未完成的影片。
z 透過 IPv4 或 IPv6 的寬頻網路作為 unicast 或 multicast 的串流伺服器。 z 提供 telnet 或是 HTTP 操作。
z 可以錄製桌面畫面。
2.4.2 MPlayer
MPlayer[6]是個免費開放原始碼的播放器。這跨平台軟體，支援 Linux、Unix-like 系統、Microsoft Windows 和 Mac OS X。MPlayer 提供許多影音格式(MPEG-1, MPEG-2,
MPEG-4, RealVideo,WMV, AAC, AC3, MP3)，也可以將串流資料存成檔案。
MPlayer 是個系統命令模式的程式，但是有隨作業系統提供不同 GUI 版本。如 gMplayer (Unix-like 系統)、MPlayer OS X (Mac OS X)和 MPUI (Windows)。
圖2-6. gMplayer (Linux) z 支援多種驅動程式，VDPAU 、X11、OpenGL、DirectX、Quartz、VESA 和 Framefbuffer。 z tv://channel 可以顯示影像擷取卡的電視畫面。 z radio://channel 可以播放廣播。 z 支援 RTP、RTSP、HTTP、FTP、MMS 和 SMB 協定。
2.4.3 Windows Media Player
Windows Media Player[7] (簡寫 WMP)是由 Microsoft 發展的多媒體播放器。WMP 執行在Microsoft 作業系統底下，用來播放影片音樂和瀏覽圖片。WMP 可以將音樂 CD 複製到硬碟、燒錄音樂CD 或是和攜帶型音樂設備同步音樂。
圖2-7. Windows Media Player 11(Windows)
z 支援本地播放、播放串流和漸進式下載。 z 支援使用 DirectShow 濾波器的 codec。 z 多媒體管理，提供搜尋和分類功能。
z Video Smoothing 功能，對於低 frame-rate 影片使用內差法增加 frame 數。 z 提供 ActiveX 嵌入網頁，開發者可以在網頁上播放多媒體檔案。
z 提供其他平台 Windows Mobile, Mac OS, Mac OS X, Palm-size PC, Handheld PC 和 Solaris。
2.4.4 播放器比較
VLC Media Player 和 MPlayer 都有使用 FFmpeg 的函式庫。Windows Media Player 主要是用DirectShow。比較表如表2-2。
表2-2. 播放器比較 Author Cost Software
license
Based
Framework Written in VLC Media
Player VideoLAN Free GPL
FFmpeg +
MPlayer Árpád
Gereöffy Free GPL
FFmpeg +
original C99 Windows
Media Player Microsoft Free Proprietary DirectShow C++(COM)
2.5 利用 Named Pipes 進行 IPC
Named pipes 可以讓兩個不相關的程序(process)互相通訊，亦稱做 FIFO(first-in, first out)是用來做單向的資料傳輸。目前 Windows、Unix 和 Linux 作業系統都支援 named pipes，但本節就 Unix 和 Linux 作業系統的操作進行說明。Named pipes 和一般檔案一樣 有檔案名稱和路徑，都定義在存取端的檔案系統中。兩個不相關的程序可以開啟定義為 Named pipe 的檔案並且開始通訊。Named pipe 的檔案不會隨著程序結束而消失，需要透 過文字命令模式刪除。
使用named pipe 的方法，一個程序開啟 named pipe 的檔案為寫入狀態，另外一個程 序開啟為讀取狀態。Named pipe 的使用預設為 blocking 模式，也可以利用 O_NONBLOCK 旗標設定成non-blocking 模式。一個程序只能開啟為讀取或是寫入狀態，不能同時開啟 讀取和寫入，這是因為named pipe 為半雙工通訊(Half-Duplex Communication)。如果要 進行全雙工通訊(Full-Duplex Communication)，就要使用兩個 named pipe。圖 2-8 為兩個 程序使用單一named pipe 進行半雙工通訊；圖 2-9 為兩個程序使用兩個 named pipe 進行 全雙工通訊。因為named pipe 讀寫是預設為 blocking 模式，所以進行全雙工通訊要避免 死結(deadlock)產生。[8]
寫入 Pipe1 讀取
圖2-9. 全雙工通訊
2.5.1 建立 Named Pipe
建立 named pipe 方式有兩種，一種是在系統命令模式建立，另一種是在程式呼叫 mkfifo()函式。假設我們要在當前目錄底下建立一個名為 pipe 的 named pipe 檔案，圖 2-10 為使用mkfifo 或是 mknod 指令的範例。如果要在程式內建立，就要採用圖 2-11 的方式。
# mkfifo pipe 或 # mknod pipe p
圖2-10. 文字命令模式建立 Named pipe
mkfifo(“pipe”, 0666)
圖2-11. 程式內建立 Named pipe
2.5.2 開啟 Named Pipe
開啟方式和開啟一般檔案一樣，可以使用open()或是 fopen()。使用 open()會回傳檔 案描述，而使用fopen()會得到 FILE 結構的指標。從使用者觀點，建立了 named pipe 後， 操作方式和處理一般檔案一樣，可以開啟、讀取、寫入和刪除。
2.5.3 使用 Named Pipe
Named pipe 不能同時開啟為讀取或寫入模式，只能選擇其中一個模式。使用標準 C 的函式庫read()或 write()，可以用來讀取或寫入 named pipe 的檔案。這些操作都是預設 為blocking 模式，當一個程序從 named pipe 讀取資料，但是卻沒有資料在裡面，此時會 被block 住。另一方面如果要寫入而沒有另一個程序讀取資料，也是會被 block。Named pipe 的檔案不能使用搜索(seek)的操作模式。
2.5.4 Named Pipe 的優缺點
1.Named Pipe 的優點
z 可以當成一般檔案操作。
z mkfifo()是個 thread-safe 的函式。 z 使用時不需要任何同步機制。
z write()到 named pipe 保證為 atomic，開啟為 non-blocking 亦是如此。 z 有操作權限限制，可以強化安全性。
2.Named Pipe 的缺點
z 只可以在同一台電腦上操作。
z 只可以建立在本地端的檔案系統，不能建立在 NFS(Network File System)。 z 因為 blocking 的機制，雙向通訊時要避免產生死結。 z Named pipe 是以位元組為單位的資料流，沒有任何資料被儲存。
2.6 嵌入式系統
嵌入式系統(Embedded System)是特地用途的微電腦系統，即將微電腦使用在特定系 統中。例如數位相機、掌上型電視遊樂器和雷射印表機，在這類的應用中使用一般的微 處理器當作中央處理器，並配合適當的記憶體和周邊裝置，完成所需要的系統。在這個 系統中微處理器只做特定的工作，而微處理器搭配的周邊裝置，所構成的一個完整系 統，稱為嵌入式系統。 嵌入式系統是以應用層面為設計的中心，以電腦技術為基礎，並且軟硬體可以依不 同的需求做調整。該系統對功能、可靠性、成本、體積、功率消耗有嚴格要求。嵌入式 系統和個人電腦有著本質上的區別，嵌入式系統本身的成本、適用性和可靠性和個人電 腦不同。個人電腦設計上的要求是更好的處理效能和更快的處理速度。但是這不能運用 於設計嵌入式系統，很多產品的成功不在於複雜的系統是否可以運作，而是否有優越的性能價格比。 嵌入式系統受限於功能和環境，對外部事件需要在規定時間內反應，如汽車的安全 氣囊。對於體積、重量的限制，如掌上型電視遊樂器。對於功率消耗和散熱必須符合環 境要求，如MID 裝置。 表2-3 和表 2-4為嵌入式系統和個人電腦的比較。[11] 表2-3. 嵌入式系統和個人電腦硬體比較 設備名稱 嵌入式系統 個人電腦
CPU ARM、MIPS x86(Intel、AMD) RAM SDRAM SDRAM、DDR
Storage Flash 硬碟
Input Touch Screen、按鍵 KeyBoard、Mouse
Output LCD 顯示器 Sound 音效晶片 音效卡 Other USB 主機板提供或擴充卡 表2-4. 嵌入式系統和個人電腦軟體比較 嵌入式系統 個人電腦 開機程式 Bootloader 引導，需要對不 同開發板進行移植 主機板BIOS 引導，不需更 改 作業系統 WinCE、Linux、VxWork… 等，需要移植 Windows、Linux…等，不 需要移植 驅動程式 針對設備重新開發或是移 植 作業系統內建或是由第三 方提供 開發環境 交叉編譯器 本機開發 模擬器 需要 不需要 2.6.1 ARM
ARM 公司(Advanced RISC Machines Limited，簡稱為 ARM Limited)成立於 1990 年。 1985 年 4 月 26 日，第一個 ARM 原型在英國劍橋的 Acorn 電腦有限公司誕生。目前 ARM 架構處理器已在高性能、低功耗、低成本的嵌入式應用領域佔有領先地位。
2.6.2 Linux
Linux 是一種基於 Linux 核心的類似 Unix 的作業系統。Linux 是自由軟體和開放原 始碼最著名的例子。任何人遵守 GPL 的協議，都可以免費下載、重新更改或是發佈。 Linux 主要用於伺服器，但是基於現今不同的電腦硬體，Linux 支援個人電腦、嵌入式裝 置、手機甚至超級電腦，這些廣泛的電腦硬體包括x86 、Power PC、ARM、Alpha、SRARC 等處理器。
Linux 核心是由 Linux Torvalds 在 1991 年所開發的。目前已經發展出許多 Linux 套 件，最有名的是 Ubuntu。Linux 套件除了 Linux 核心還包含其他軟體如 Apache 網頁伺 服器、X Windows 系統、KDE 桌面環境、GNOME 桌面環境或是 OpenOffice。
Linux 是個 Unix-like 的作業系統，重要特點如下。[10] 1.多程序(Multitasking)： 實現了優先權排程管理。當同時間有高優先權和低優先權程序，高優先權程序 可以優先執行。 2.多使用者(Multi-user)： 提供了分時(time-sharing)多工系統，可以讓許多使用者同時使用電腦，同時提 供資料隱私保護。 3.多處理器(Multi-processing)： 支援多處理器(Symmetric Multi-Processing)。 3.記憶體保護(Protected Memory)： 每個程序擁有自己的記憶體空間，而且不能直接存取其他程序的記憶體空間。 這防止不同程序間相互破壞對方的記憶體資料。 4.檔案系統(File System)： 提供根目錄檔案系統，每個目錄和檔案都是從根目錄延伸，像是樹狀組織。除 此之外還有提供兩項特別的功能如下。 (1)連結 (Links)－連結指向真正檔案的位置，而本身不是一個檔案。
一個檔案，對於程式而言寫入資料檔案和寫入資料到印表機是相同的。 如果要將Linux 用於嵌入式環境，必須依需求做移植和修改。嵌入式 Linux 有以下 的特點。 1.開放原始碼： 程式設計者可以針對Linux 原始碼進行修改，根據實際應用對核心優化。 2.低成本： 基於GPL 協議下，可以免費下載程式碼並對 Linux 核心做更改和重新發佈。大 多數的嵌入式Linux 開發工具也是遵守 GPL 協議，同樣也是可以免費獲得。如此可 以節省大量的開發費用。 3.眾多軟體支援： Linux 是個一完整功能強大的作業系統，提供各式各樣的應用軟體。利用 Linux 提供的軟體支援，可以迅速建構嵌入式應用的軟體環境。
2.7 開發環境
首 先 必 須 了 解 開 發 嵌 入 式 系 統 所 用 到 的 兩 種 系 統 ， 一 種 是 電 腦 主 機(Host Computer)，我們在上面撰寫並偵錯程式，因為許多開發用的軟硬體工具支援通用型處 理器，此處理器是桌上型電腦的一部份；另一種為目標系統(Target System)，此系統為 開發中的嵌入式目標平台，我們在這個平台的處理器上執行我們撰寫的程式。 z 電腦主機(Host Computer)：標準(x86)平台用來開發目標系統的程式和軟體，並且 透過JTAG 線連結目標系統除錯。 z 目標系統(Target System)：開發中的嵌入式系統。z 交叉開發(Cross-development)：建立在 host computer 的開發環境，利用交叉編譯 器編譯目標系統的程式。
撰寫嵌入式系統的程式與撰寫在桌上型電腦執行的程式非常類似。一般而言，桌上 型電腦上的應用程式設計流程首要步驟為撰寫原始碼，原始碼可能分成數個檔案。原始 碼以編輯程式撰寫，再以編譯器(compiler)或組譯器(assembler)將各檔案的程式碼加以編 譯或組譯，產生對應的二元程式碼檔案，再利用連結器(linker)將二元程式碼結合為執行 檔，此為實作階段。透過偵錯程式測試該執行檔，為驗證階段。如果在驗證階段程式出 現錯誤或是效能低落，回到實作階段改進原始碼，再編譯組譯。如此反覆，直到達到預 期成效。 圖2-12. 軟體開發流程 圖 2-12 為嵌入式系統軟體的開發流程，開發嵌入式系統的程式包括編輯、編譯、
組譯和連結。我們在開發用的電腦主機上使用交叉開發(cross-development)工具，包含交 叉編譯器(cross complier)和交叉組譯器(cross assembler)來進行編譯和組譯工作。完成的 目標執行檔，我們透過 JTAG、RS-232c 或是網路傳到目標系統上執行。驗證階段的工 作會和開發桌上型電腦的程式有許多的不同。 偵錯和除錯需要透過額外的硬體電路或是連接器，將開發用的電腦主機和目標系統 連接起來。如此在偵錯程式可以透過單步執行，觀察目標系統的處理器的記憶體位置和 暫存器的值。這樣可以方便程式設計者加以除錯和改進程式。 2.7.1 硬體連接
Host Computer
Target System
JTAG RS-232 Ethernet 圖2-13. 開發環境硬體連接 圖 2-13 為開發的時侯電腦主機和目標系統的硬體連接，透過這些連接線可以操控 或是上傳檔案到目標系統。 z JTAG：用來偵錯或除錯，也可以用來燒寫目標系統的 Flash，一般是用來燒寫 Bootloader。z RS-232：在超級終端機操作目標系統。開機後，bootloader 就會透過 RS-232 傳送 文字選單，並且可以由使用者下達指令。進入Linux 後將會顯示開機訊息，輸入 登入帳號密碼就可以用命令模式操作整個目標系統。
z Ethernet：在 bootloader 的選單時，更新 Linux kernel 或是 Root Filesystem 都是透 過ethernet 傳送。
2.7.2 軟體架構
圖2-14. 開發環境軟體架構
圖2-14 為開發環境的軟體架構，目標系統通常含有三個部份，分別為 Bootloader、 Kernel 和 Root Filesystem。
z Bootloader： Bootloader 是在作業系統執行之前的一段小程式。透過這段小程式，我們可以 初始化硬體設備、建立記憶體空間的映射表，從而建立適當的系統軟硬體環境，為 最終呼叫作業系統做好準備 對於嵌入式系統，Bootloader 是建立在特定硬體平台來實現的。因此，不可能 為所有的嵌入式系統建立一個通用的Bootloader。Bootloader 依賴 CPU 的架構和嵌 入式平台的周邊設備，所以每當開發新的平台，Bootloader 需要做適當的修改和移 植。 z Kernel： Kernel 是作業系統的核心，主要是進行硬體和軟體之間的溝通和資源的管理。
程式對硬體操作的時間。直接操作硬體是非常複雜的，所以核心提供一個抽象介 面，可以讓程式更簡潔的方式操控硬體。
z Root Filesystem：
除了 kernel 之外，filesystem 是讓作業系統能順利運作的重要元素，它儲存作 業系統在運作過程中所需要的程式和資料。
Root filesystem 是構成 filesystem 的最小集合，它包含所有 Linux 開機時需 要的檔案及資料夾，如initrd、init.d 裡的各項服務，/etc、/proc、/lib 等。Filesystem 的源頭為根目錄(/)，所有檔案和目錄都是從根目錄延伸。在嵌入式系統中， root filesystem 包含了一些基本使用工具，如查詢檔案的 ls、掛載裝置的 mount 等。若 是內建的儲存空間不足，可以透過CF 卡或是 SD/MMC 卡擴充儲存空間。
2.8 開發板
本 研 究 採 用 華 亨 科 技 的 EELIOD 開發板，如圖 2-15，此開發板分兩個部份 XSBase270-Module 和 XSBase270-EDR。[12]z XSBase270-Module：採用 Intel Xscale PXA270 處理器的開發平台，可以獨立使 用。
z XSBase270-EDR：需與 XSBase270-Module 配套使用的介面擴充板，透過 2 個 120pin 排針與 XSBase270-Module 板連接一起工作，不可獨立使用。。
圖2-15 華亨科技 EELIOD
表2-5. XSBase270-Module 硬體配置 XSBase270-Module
處理器 Intel XScale PXA270 520MHz
RAM SDRAM 64MB
FLASH NAND Flash 32MB 電源管理 LP3971 乙太網路 LAN91C113 音效晶片 UCB1400BE 液晶螢幕 Sharp 8 吋 TFT 640*480 觸控螢幕 8 吋 四線式觸控 UCB1400BE 控制 RS232 1 JTAG 介面 20pin 擴充介面 2 個 120pin 表2-6. XSBase270-EDR 硬體配置 XSBase270-EDR 紅外線 1 RTC RTC4513
CF 接CF 卡或是 802.11b 無線 CF 網卡 MMC/SD 1
SIM 1 乙太網路介面 1 (和 Module 共用) 串列埠 1 個 RS485、2 個 RS232 音效介面 LINE IN/LINE OUT/MIC USB Host 2 USB Client 1 CMOS 介面 1 LED 8 七段顯示器 4 鍵盤 4*4 CAN Bus 介面 1 喇叭 2 步進馬達 1 直流馬達 1 擴充介面 120pin 可接FPGA 板 表2-7. EELIOD 軟體配置 Linux 核心 Linux Kernel 2.4.21 系統引導程式 51Board Bootloader 檔案系統 JFFS2 GUI Tiny-x
第三章
MPlayer 程式
MPlayer 的基本播放架構如圖 3-1 所示，使用者透過系統指令模式輸入開啟影音資 料的來源、指定的video/audio filter 和指定的 video/audio ouput。MPlayer 透過 Open Stream
函式選擇適當的開檔模組去讀取資料，並且放到 Cache2 緩衝器。然後透過合適的解多
工器將資料分離出video bitstream 和 audio bitstream。再利用合適的視訊解碼器和音訊解
碼器分別對video bitstream 和 audio bitstream 解碼成 video frame 和 audio frame。解碼完
成後，透過使用者選定的濾波器分別video frame 和 audio frame 做處理。最後再藉由 video
這章將介紹MPlayer 的 Open Stream、Cache2、Video Filter 和 Video Output。並且說 明MPlayer 建立 video chain 的流程，還有解碼完的一張張 frame 是怎麼通過 Video Filter 和Video Output。
Parse Command Line
Open Stream
Enable Cache2 Read Config File
Open Demux
Audio Only?
Audio Playback Only
Init Video Chain Start
N Y
End Init Video filter/output
Video Decoder Video Filter Uninit Player Video Output Y N End of file? Demuxer 圖3-2. MPlayer 播影像的基本流程
圖3-2 為 MPlayer 播放影像的基本流程。3.1 節將說明 MPlayer 如何透過 open_stream()
函式開啟檔案。開啟檔案後會依需求開啟Cache2，這是儲存影音資料的緩衝器。3.2 節
(Video Output)。影音資料經過解多工器分成視訊資料和音訊資料。MPlayer 在播放前需
要建立 video chain，這包含決定影音解碼器、影音濾波器和影音輸出模組。3.5 節說明
video chain 建立的流程。3.6 節說明 video chain 中各模組的初始化和影像資料的傳遞。
3.1 Open Stream 函式
MPlayer 開啟檔案是採用 Open Stream 函式。開啟本地硬碟或光碟機的資料，或是
透過HTTP、RTSP、FTP 的 protocol 從網路開啟遠端檔案，都是使用 Open Stream 函式
選擇合適的開檔模組。一個模組可以支援一種或多種的 protocol，如 RTSP 模組只支援 RTSP，而 HTTP 模組支援 HTTP、MMS、RTSP。目前 MPlayer 1.0rc2-4.1.2 包含 HTTP、 RTSP、RTP、UDP、FTP、VCD、DVD…等。 表3-1 為 stream_info_t 的結構成員，每個模組都要有這個結構，結構成員存放該模 組對應的參數和模組開檔的函式指標。 表3-1. stream_info_t 結構成員 變數 型態
info const char *
name const char *
author const char *
comment const char *
open 函式指標 protocols[MAX] char * opts void * opts_url int info：基本資訊。 name：模組名稱。 author：作者名字。
comment：建議事項。
open：指向模組開啟函式的指標，這個函式是模組的進入點。
protocols[]：型態為字串陣列，裡面存放模組所支援的 protocol。選擇模組會比對這
裡面的字串，來判斷支援與否。
opts_url：如果為 1，會將檔案路徑當成選項字串解析。
圖 3-3 為 HTTP 的 stream_info_t 結構資料，最重要的是 protocols[]和 open()對應的 參數。
圖3-3. HTTP 的 stream_info_t 結構資料
當 MPlayer 選定開檔模組後，利用 stream_t 結構來呼叫和使用模組內的函式和變
數。而 stream_t 的部份結構資料會在 open()模組程式進入點指定值。表 3-2 為 stream_t
結構所包含的成員。這裡將這些結構成員的函式和變數，做詳加說明與介紹。 表3-2. stream_t 結構成員 變數 型態 回傳型態 fill_buffer() 函式指標 int write_buffer() 函式指標 int seek() 函式指標 int control() 函式指標 int close() 函式指標 void fd int - type int - flags int - sector_size int -
buf_pos,buf_len unsigned int -
pos,start_pos,end_pos off_t -
eof int -
mode int -
cache_pid unsigned int -
cache_data void * -
priv void * -
url char * -
streaming_ctrl streaming_ctrl_t * -
buffer[SECTOR_SIZE] unsigned char -
fill_buffer ()：將 stream 的資料讀取到緩衝器。 write_buffer()：將緩衝器的資料寫到 stream。 seek()：搜索 stream 裡面的資料。 control()：控制介面。呼叫此函式需要傳入一個控制類別的旗標。該函式會針對被 呼叫的類別，執行該段的程式碼。 close()：關閉 stream。 fd：開啟檔案的標號或是 TCP/UDP 開啟的標號。 type：stream 的類別，種類有 FILE、VCD、STREAM、DVD、CDDA…等。 sector_size：2048 或是 2324，2324 為 VCD 播放用。搜索和 Cache2 的大小會是 sector_size 的整數倍。 buf_pos,buf_len：buffer[SECTOR_SIZE]資料所存放的位置和大小。 pos,start_pos,end_pos：。 eof：所開啟的檔案是否結束(End Of File)。
mode： STREAM_READ 或是 STREAM_WRITE 模式。
cache_pid：當 Cache2 啟動後，cache2.c::cache_fill()子程序的 PID。 cache_data：指向 Cache2 所用 cache_vars_t 結構的指標。
圖 3-4 為 VCD 模組 open_s 程式進入點的部分程式碼。stream_t 部分結構資料在此 指定，有函式操作的fill_buffer、seek、close 函式指標，fd、type、sector_size、start_pos、 end_pos 和 priv 變數資料。每個模組會依需求指定結構資料，並非所有變數都有使用。 圖3-4. VCD 模組 open_s()部分程式碼 streaming_ctrl_t 結構是專門用來處理網路資料，為stream_t 結構成員之一，HTTP、 RSTP、RTP 都有用到這個結構。streaming_ctrl_t 結構資料是在 MPlayer 選定開檔模組後 指定值。表3-3 為 streaming_ctrl_t 結構所包含的成員。這裡將這些結構成員的函式和變 數，做詳加說明與介紹。 表3-3. streaming_ctrl_t 結構成員 變數 型態 url URL_t * status streaming_status buffering int
prebuffer_size unsigned int
buffer char *
buffer_size unsigned int
buffer_pos unsigned int
bandwidth unsigned int
指定stream_t 的結構成 員，這依開檔模組而有不 同的指定參數
streaming_read 函式指標 streaming_seek 函式指標 data void * url：URL_t 的結構指標，其結構成員如表 3-4。這是存放解析網址變數，假設網址 為 url=http://user:pass@140.113.13.88:6666/Video.avi 則 解 析 出 來 的 變 數 為 protocol=http、hostname=140.113.13.88、file=/Video.avi、port=6666、username=user 、 password=pass。 表3-4. URL_t 結構成員 變數 型態 url char * protocol char * hostname char * file char *
port unsigned int
username char *
password char *
status：目前狀態為 streaming_playing_e 或是 streaming_stopped_e。 buffering：開啟 Cache2 的旗標，設定為 1 代表開啟。 prebuffer_size：預先緩衝的資料大小，單位為 byte。 buffer：緩衝器，在 HTTP 模組是用來存放回傳的 body 資料。 buffer_size：緩衝器的大小。 buffer_pos：緩衝器的位置。 bandwidth：網路頻寬。 streaming_read：指到對應模組的讀取檔案的函式。 streaming_seek：指到對應模組的搜索檔案的函式。 data：用來存放任意型態的指標，如 HTTP 用來存放 HTTP_header_t 結構指標。
3.1.1 Open Stream 函式運作流程
圖3-5 為 Open Stream 開啟的流程。當 main()要開啟檔案時，會呼叫 open_stream()
函式並且傳入檔案路徑。open_stream()只負責檢查傳入的檔案路徑是否為 NULL，如果 為NULL 返回錯誤訊息，否則繼續呼叫 open_stream_full()。open_stream_full()是利用比
對模組支援的protocol 和檔案路徑的字串，來挑選適合的開檔模組。open_stream_plugin()
是做後續的初始化和解析檔案路徑。當整個 Open Stream 函式開啟成功，會回傳一個
stream_t 結構的指標，這個 stream_t 的結構會由 main()傳給 demux_open()函式進行開啟 解多工器。
圖3-5. Open Steam 流程圖
open()是利用函式指標指到 MPlayer 所選擇開檔模組的程式進入點，名稱可能有所 不同，例如HTTP 為 open_s1()，VCD 為 open_s()。open()函式，將會指定 stream_t 部份 結構成員的資料，最重要的是指定操作函式指標到該模組的操作函式，如此可以用 stream_t 的結構直接操作該模組的函式。
圖3-6. open_stream_full()的程式碼
圖3-6 為 open_stream_full()程式碼，這邊重點分三個部份解釋如下。
第1 部分：auto_open_streams[]是 stream_info_t 的結構陣列，存放所有開檔模組的 stream_info_t 結構，利用 for 迴圈逐一讀取每個模組的 stream_info_t 結構，
由第2 部分比對。
第2 部分：利用字串比對的方式，比對檔案路徑是否包含模組支援的 protocol 字串，這
protocol 字串是 stream_info_t 的成員變數。例如 HTTP 模組支援 http 和 rtsp
的protocol，那就會比對檔案路徑開頭是否有“http://”和“rtsp://”的字串。如果
都比對失敗，那回到第1 部分讀取下一個模組的 stream_info_t 結構。如果最
後都比對不出任何protocol 字串，將由 FILE 開檔模組開啟檔案。MPlayer
1.0rc2-4.1.2 內建的開檔模組如表 3-5。
第3 部分：將檔案名稱和指定的模組交由 open_stream_plugin()處理，open_stream_plugin()
會做一些初始化，最後呼叫模組的函式open()。這時候模組做開檔動作，進
行 模 組 初 始 化 並 且 把 stream_t 結 構 的 變 數 資 料 指 派 完成 。 當 整 個 open_stream_full()開啟成功，回傳 stream_t 結構的指標。
表3-5. MPlayer 內建的開檔模組
開檔模組 protocols
stream_info_vcd "vcd",
stream_info_cdda "cdda", "cddb", stream_info_netstream "mpst",
stream_info_http1 "http", "http_proxy", "unsv",
stream_info_asf "mms", "mmsu", "mmst", "http", "http_proxy", "mmshttp", stream_info_pnm "pnm", stream_info_rtsp "rtsp", stream_info_sdp "sdp", stream_info_rtsp_sip "rtsp", "sip", stream_info_rtp "rtp", stream_info_udp "udp",
stream_info_http2 "http", "http_proxy", "pnm", "mms", "mmsu", "mmst", "rtsp", stream_info_dvb "dvb", stream_info_tv "tv", stream_info_radio "radio", stream_info_pvr "pvr", stream_info_ftp "ftp", stream_info_vstream "tivo", stream_info_smb "smb", stream_info_cue "cue", stream_info_dvd "dvd", stream_info_dvdnav "dvdnav", stream_info_null "null", stream_info_mf "mf", stream_info_file "file", "",
3.1.2 HTTP 模組開檔流程 url_new() http_streaming_start() fixup_open() nop_streaming_start() fixup_network_stream_cache() http_send_request() http_read_response() open_s1() 圖3-7. HTTP 模組開檔流程
open_s1()是 HTTP 模組程式進入點。url_new()將網址分解成 URL_t 的結構格式，這 表 3-3 有詳細說明。http_streaming_start()是重要的函式，包含了 http_send_request()和 http_read_response()。http_send_request()先建立 HTTP 請求訊息。與 Web Server 建立 TCP 連線後，發送HTTP 請求訊息給 Web Server。http_read_response()負責接收 Web Server
回覆的資料，主要處理標頭部份，而不下載檔案資料(body)。http_send_request()和 http_read_response()處理完後，http_streaming_start()會去解析回覆資料。 GET /Video HTTP/1.0 Host: 140.113.13.81:667 User-Agent: MPlayer/1.0rc2-4.1.2 Icy-MetaData: 1 Connection: close 圖3-8. HTTP 請求訊息 圖3-8 為 HTTP 模組所發送的 HTTP 請求訊息。第一行是 GET 指令請求檔案為根目
行是發送請求的程式是MPlayer1.0rc2-4.1.2。第四行是 ICY 的資料。第五行是說明這連 線在檔案傳送完畢就立即斷線。
HTTP/1.1 200 OK Accept-Ranges: bytes
Server: Rdesktop Media Server
Content-Type: application/octet-stream Content-Length: 44176206
圖3-9. Web Server 回覆訊息
圖3-9 為 Web Server 回覆的訊息。第一行是 Server 支援 HTTP 1.1，代碼 200 為請
求檔案隨回應傳送。第二行是判斷Server 是否支援中斷點下載，在 Open Stream 中代表
檔案來源是否可以快轉或倒退，也就是搜索的功能。回應bytes 代表支援，none 則否。
第三行是Server 名稱。第四行是檔案的 MIME 類型，這會決定 MPlayer 預先設定的解多
工器(demuxer)模組，application/octet-stream 是設定為 DEMUXER_TYPE_UNKNOWN， 這會讓 MPlayer 自行選擇解多工器模組。第五行為檔案的大小，單位為 bytes。這邊最 重要就三個欄位Accept-Ranges、Content-Type 和 Content-Length。 表3-6. MPlayer MIME 表 MIME 類型 audio/mpeg DEMUXER_TYPE_AUDIO video/mpeg DEMUXER_TYPE_UNKNOWN video/x-mpeg DEMUXER_TYPE_UNKNOWN video/x-mpeg2 DEMUXER_TYPE_UNKNOWN video/x-msvideo DEMUXER_TYPE_AVI video/quicktime DEMUXER_TYPE_MOV application/octet-stream DEMUXER_TYPE_UNKNOWN audio/x-pn-realaudio DEMUXER_TYPE_REAL application/x-ogg DEMUXER_TYPE_OGG video/nsv DEMUXER_TYPE_NSV video/x-flv DEMUXER_TYPE_LAVF
fixup_open() 包 含 了 兩 個 重 要 函 式 ， nop_streaming_start() 和 fixup_network_stream_cache()。nop_streaming_start()初始化 streaming_ctrl_t 結構資料， 並且指定函式指標streaming_read 和 streaming_seek。如果設定了 streaming_ctrl_t 結構的 streaming_read 函 式 指 標 就 不 會 設 定 stream_t 結 構 的 fill_buffer 函 式 指 標 。
fixup_network_stream_cache()則是用來調整 Cache2 的大小，詳細第 3.2 節將說明。
3.2 Cache2 機制
Open Stream 的模組支援很多 protocol，檔案來源可能是來自周邊設備、區域網路或 是網際網路。這些檔案來源的速度不一定很穩定，而不穩定的資料量會造成播放斷續。
播放斷斷續續會讓使用者有不好的影片欣賞經驗。Cache2 就是用來解決速度不穩定的問
題，在影片播放前預先下載資料到快取中，再開始播放。而在影片播放的同時，Cache2 會持續從來源下載資料，以提供播放器穩定的資料。
開啟Cache2 有兩種方法，第一種是在文字命令模式中加上-cache SIZE，SIZE 是任
意大於等於32 的數字，單位為 KB；第二種是 Open Stream 自動開啟，部分 Open Stream
模組有預設一個prebuffer_size 的大小，如 HTTP 的 prebuffer_size 預設為 64KB，Cache2
調整為320KB。
Cache2 為 prebuffer_size 的 5 倍大，這是因為 Cache2 會預先填滿 20%才開始播放影 片。cache_vars_t 結構是 Cache2 在使用的。表 3-7 為 cache_vars_t 結構所包含的成員。 這裡將這些結構成員的函式和變數，做詳加說明與介紹。
表3-7. cache_vars_t 結構成員
變數 型態
buffer unsigned char * buffer_size int sector_size int back_size int
fill_limit int seek_limit int eof int min_filepos off_t max_filepos off_t offset off_t read_filepos off_t stream stream_t * buffer：指向快取記憶體的指標。 buffer_size：快取的大小。 sector_size：單一區段的大小，2048 或是 2324。2324 是用於 VCD 播放。 back_size：已經播放過的資料大小，用來倒退搜索。 fill_limit：當緩衝器空間大於等於 fill_limit 才填充快取。 seek_limit：如果搜索的資料距離小於 seek_limit，繼續填充快取。 eof：檔案結束(End Of File)旗標，設定為 1 代表檔案結束。 min_filepos：快取所存的檔案的最小位置。 max_filepos：快取所存的檔案的最大位置，快取僅存放從 max_filepos–min_filepos 檔案的部分資料。 offset：快取和檔案位置的偏移量。 read_filepos：目前播放器讀取的位置。 stream：呼叫原本的 stream_t 結構變數。 3.2.1 HTTP Cache2 開啟流程 圖 3-10 為 HTTP 模組開啟檔案的程序，nop_streaming_start()預設的 prebuffer_size 為 64*1024 bytes、buffering 為 1。fixup_network_stream_cache()將 stream_cache_size 調
整為 prebuffer_size 的 5 倍。注意的是 stream_cache_size 初始值為-1。開檔完成後，
main()呼叫 stream_enable_cache()，這時候 Cache2 啟動。 圖3-10. HTTP Cache2 開啟流程 3.2.2 Cache2 運作流程 Cache2 初始化Cache2 建立子程序 Cache2填滿20%?
main open demux
Y N
Parent process Child process
Cache2
圖3-11. Cache2 啟動流程圖
圖 3-11 為 Cache2 啟動流程圖，首先會先初始化 Cache2。主要是取得 Cache2 的記
憶體空間，並且計算 fill_limit 和 back_size 兩個重要參數。當緩衝器空間小於 fill_limit
