Non-Specific Application Sharing in Access Grid

Non-Specific Application Sharing in Access Grid

Reen-Cheng Wang, Yao-Chung Chang

1

, Ruay-Shiung Chang, and Hsin-Chou Chi

Computer Science & Information Engineering

National Dong Hwa University, Taiwan

1

Information Management

National Taitung University, Taiwan

E-mail：{rcwang, rschang, hcchi}@mail.ndhu.edu.tw; ycc@nttu.edu.tw

摘要

Access Grid 超級視訊格網是一套普遍應用於 多人視訊、遠距教學等用途的網格應用程式，由於 它具有高畫質、操作便利、高互動性，再加上屬於 公眾軟體可免費取得，在全球的使用上十分普及。 然而，由於受限於軟體本身的限制，官方版本迄今 只支援三種應用程式分享，實在不足以因應當前一 般人在多種軟體協同合作上的需求。本文提出數種 新的架構，可以針對使用者非特定的應用程式的分 享需求，提供合理的解決方案。 關鍵詞：超級視訊格網、非特定應用程式分享。

Abstract

The Access Grid is used for large-scale distributed meetings, collaborative work, and training. It is an ensemble of resources including large-format multimedia displays and interactive environments, and interfaces to Grid middleware and to visualization environments. Owing to it is a public domain software and with many convenient features, it is very popular on the Internet. However, the limit functions of the software restrict the application sharing under collaborative working. In this paper, we proposed three new architectures for providing non-specific application sharing in Access Grid.

Keywords: Access Grid, Application Sharing.

1. 前言

隨著網路技術的不斷更新與頻寬的倍增，新一 代視訊會議系統 Access Grid[1] 也成了應用的熱 門話題。相較於傳統視訊會議系統在進行多點會議 時，需建置高價之 MCU(Multi-point Control Unit) 設備，而且有採用低頻寬壓縮技術導致視訊及音訊 品質不佳，或因 MCU 的集中式連線，導致網路頻 寬壅塞等問題；在新一代寬頻網路建置完成後，網 路頻寬不足的問題解決了，Access Grid 系統更能以 最經濟實用的設備完成建置，達到同時間多人多點 的視訊會議應用，並且支援高品質影像及聲音傳輸 技術，整合了視訊、音訊及簡報資料等傳輸功能， 進而達到未來視訊會議或是遠距教學應用之需求。 Access Grid 在多人視訊連線上有諸多的優 點，但是，如果要把它應用在遠距協同工作的領域 上，雖然大體上可行，卻仍然有些不足夠。要利用 Access Grid 進行協同工作，最重要的是除了視訊、 語音之外，還要讓參與者能夠共享他們所需要的程 式或軟體。然而，受限於 Access Grid 軟體本身的限 制，目前的版本只支援三種應用程式分享，包括 Share Browser 、 Share Question Tool 、 Share Presentation，如圖 1 所示。 圖 1 Access Grid 內建可分享的應用程式 舉例而言，內建的 Share Presentation，可以用 來分享 PowerPoint 製作的簡報檔，它可以做到基 本的簡報翻頁、跳頁操作，然而，由於是早期的設 計，比起現階段的功能自然多有不足，像是動畫頁 面、內嵌元件等都無法順利控制，而且頁面切換不 夠順暢。同樣的，在 Share Browser 與 Share Question Tool 也有類似功能不足的問題存在。在 Rich Media 豐富媒體盛行的今日，我們常用的 Office、Acrobat 等軟體，或是各式的影音瀏覽器、專業軟體等等， 都無法在上面應用，實在不足以因應當前一般人在 多種軟體協同合作上的需求。 幫 Access Grid 去開發更多常用的協同工作 套件是最直覺的解決途徑，然而，由於軟體業快速 的發展，版本與功能不斷的更新，要針對每一種應 用程式都開發一種共享工具，再根據最新的版本不 斷修正，似乎是太過繁複且不切實際，因此，透過 單一整合的介面，來進行所有種類的應用程式分 享，便成了 Access Grid 發展的趨勢。有鑒於此， 一個針對 AGTk 2.3 版本的分享程式 VenueVNC[2] 在 2005 年正式發佈。 然而，根據我們多次的實驗，卻發現它仍然無 法滿足真正應用上的所有需求。因此，我們在分析 了既有 Access Grid 的相關功能後，根據其不足處， 再 設 計 出 多種 適 合 不 同環 境 的 應 用程 式 分 享 方 式，提出三種新的架構，可以針對使用者非特定的 應用程式的分享需求，提供合理的解決方案。 文 章 的 主 要 結 構 如 下 ： 第 二 節 首 先 對 VenueVNC 實測並分析，第三節提出三種新的非特 定應用程式分享架構，第四節比較新架構的特性與 適合的應用環境，第五節舉例說明其混何應用模 式，第六節是結論，而最後是致謝與參考文獻。

2. Access Grid 的 VenueVNC

VenueVNC 是透過軟體桌面共享方式，將使用 者端的應用程式分享給其他使用者。由於是利用桌 面共享的原理，只要是分享端的電腦有安裝的應用 程式，理論上都可以達到協同工作的目的。對於遠 端使用者而言，操作上也十分容易，唯一的缺點是 需另行加裝程式。 2.1 Server 端 (分享者) 分享者必須使用 VenueVNCServer.py 這支程式 [2]建立分享通道。由於它本身不具備 VNC Server 功能，只是一個溝通的介面，除了這個程式外，仍 必須先行安裝合適的 VNC Server，並於背景中執 行。根據官方網站建議，VNC Server 於 Windows 環境下建議使用 RealVNC[3]；於 Linux 環境下則 建議安裝 TightVNC[4]。 z Linux 1. 開啟內建之 VNC Server 服務已執行。 2. 修改~/.venuevnc/xstartup，加入如圖 2 所 示文字，以便分享 XWindow 圖型介面。 圖 2 xstartup 內容 z Windows 1. 安裝 VNC Server，且將服務開啟。 安裝完畢後，執行 VenueVNCServer.py 命令， 便會透過 Application Session 通道，在 VenueServer 中加入 VenueVNC 的共享服務。舉例而言，分享 VenueVNC 服務到 venue.ndhu.edu.tw 的預設大廳 指令如圖 3。 圖 3 分享 VenueVNC 圖 4 開啟 VenueVNC 操作 圖 5 左：Linux 畫面；右：Windows XP 畫面 2.2 Client 端 (使用者) 使用者端僅需依一般的 sessions 方式如圖 4 操 作即可。經 VenueVNC 分享之 Linux 桌面及 Windows XP 桌面結果如圖 5 所示。 2.3 測試與分析 為了確認此外掛程式是否充分利用 Access Grid Multicast 的特性，我們架設不同的網路架構， 來進行的流量與可用性測試分析。 z 測試一 網路架構如圖 6，中間的 Pserver 為一台 NAT [5] 機器，以 Static NAT 方式對映橋接，agtest1 為分享 者，負責在 Venue Server 上開啟 VenueVNC 共享 服務，並提供自身資源共享；agtest2 為使用者，由 遠端控制 agtest1 的共享軟體，並由 Pserver 擷取通 透流量分析。操作順序如下：

圖 6 測試一網路架構

1. 以 RAT (Robust Audio Tool，Access Grid 內建的聲音軟體) [6]分享聲音。 2. 開啟 VenueVNC/移動視窗。 3. 開啟網頁/切換網頁。 4. 開啟圖片(450K)/切換圖片。 5. 開啟影片檔(AniCAM[7]錄製之 avi 檔)/ 關閉影片檔。 6. 開啟簡報檔/切換頁次。 7. 關閉 VenueVNC。 z 測試二 將上一個環境中，agtest1 移出至 NAT 外，另 一台 agtest2 留在 NAT 內，網路架構如圖 7 所示， 由 Pserver 主機抓取流量分析。操作順序同測試一。 圖 7 測試二網路架構 z 測試三 我們針對各種不同的軟體，分成一般圖文操作 (Office、Acrobat 等)、聲音播放(WinAMP、iTune 等)、及影音播放(Media Player、Real Player 等)進行 可用性測試分析。

> python VenueVNCServer.py –venueUrl https://venue.ndhu.edu.tw:8000/Venues/default

z 測試結果分析： 0.00 500.00 1000.00 1500.00 2000.00 2500.00 08:31: 30 08:33: 31 08:39: 31 08:45: 31 08:47: 31 08:48: 31 08:49: 31 08:52: 31 08:55: 31 08:58: 31 09:04: 30 09:09: 31 134.208.10.238 To 192.168.2.5 192.168.2.5 To 134.208.10.238 圖 8 測試一流量分析 測試一的流量分析如圖 8，分享開始後，Pserver 幾乎看不到流量，這代表封包僅在 agtest1 與 agtest2 兩端點間互相傳遞，與 VenueServer 無直接關係。 0.00 5000.00 10000.00 15000.00 20000.00 25000.00 30000.00 09:44 :11 09:52: 11 09:54 :10 09:56: 11 09:58 :11 10:00: 10 10:02: 11 10:04: 10 192.168.2.5 To 134.208.9.151 134.208.9.151 To 192.168.2.5 圖 9 測試二流量分析 測試二的流量分析如圖 9，可以看到封包由 agtest1 大量流入 agtest2，如果我們改用 Dynamic NAT 方式，將 agtest2 放在 Private IP domain，並 設為分享端；再由 agtest1 設法取得分享資源時，會 發現 agtest1 無法正常連入，由此推斷 VenueVNC 程式僅在 VenueServer 中加入 session identifier，此 ID 僅代為記憶開放分享之端點資訊。 表 1 測試三結果 軟 體 形 式 測 試 結 果 一般圖文操作 正常，但高動態文件會跳格。 聲音播放 正常 影音播放 除傳統 AVI 格式可正常播放 外，其餘均無法正確運作。 測試三結果如表 1 所示，其中一般圖文操作執 行高動態文件會有跳格現象，分析原因為大多數的 CPU 資源已經被原 Access Grid 程式佔據(因為使 用軟體進行影音編碼的緣故)，同為軟體的 VNC Server 無法得到足夠的資源；而影片播放部份視窗 呈現黑幕：如 WMV、MPEG，分析原因在於這些 格 式 的 影 片 會 直 接 驅 動 硬 體 加 速 ， 導 致 VNC Server 無法於 VGA Buffer 中取得正確影像。

測試結果發現 VenueServer 並未以群播協定代 為發送封包，資料仍然是由分享端點直接提供給各 使用端點。因此，VenueVNC 雖然提供了一個可用 的方式，但由於他還是利用 Unicast 傳播，當多人 使用時所消耗的頻寬必定倍增，並不適合做大規模 使用。另外，需多開啟 VNC 的必要 port，有安全 性上的疑慮，再加上由於有硬體資源耗盡、及加速 顯示的問題，促使我們便進一步規劃不同的分享方 式與架構。

3. 新的非特定應用程式分享架構

鑑於先前所提到的問題，我們提出了三種新的 架構方式，來使非特定應用程式分享可以更完備。 3.1 獨立的 VNC Server Venue Server Bridge Server Venue Client

Venue Client Venue Client Venue Client VNC Server 圖 10 獨立 VNC Server 架構 為解決 CPU 資源不足的問題，第一個想法便 是將 VNC Server 獨立出來，架構如圖 10。在 OS 上單純只跑 VNC Service 與分享的應用程式。如此 一來，負載便降低了，同時可以共享的人數就增加 了，但因為每一個連線點仍然是一個 Unicast 通道， 取決於編碼速度以及頻寬的問題，同時上線人數還 是有一定的限制，硬體加速顯示的問題依然存在。 在這個架構中，我們測試各種不同應用程式共享結 果如表 2 所示。 表 2 獨立 VNC Server 的測試結果 軟 體 形 式 測 試 結 果 一般圖文操作 正常。 聲音播放 正常 影片播放 除傳統 AVI 格式可正常播放 外，其餘均無法正確運作。 3.2 增設 VIC Encoder Venue Server Bridge Server

VIC Encoder Operator

Venue Client Venue Client Venue Client

圖 11 增設 VIC Encoder 為 了 提 供 更 多 人 同 時 分 享 文 件 ， 以 及 解 決 Share Video 的問題，我們自行設計了一個稱為 VIC Encoder 的伺服器。設計的主要構想，是要利 用 VenueServer Multicast 的 功 能 ， 減 低 VNC Server 的負載，同時透過 NTSC[8] 影像的轉換， 解決影片的無法分享問題，架構如圖 11。 透過 VIC Encoder 的幫忙，我們可以將 VNC Server 的影像訊號，轉成 VIC(Videoconferencing Tool，Access Grid 的內建視訊軟體) [9] 的輸入，

傳遞到 VenueServer 上；同時，聲音也可以透過 RAT 轉 換 ， 同 步 傳 遞 ， 再 由 VenueServer 透 過 multicast 傳送給所有人，如此一來，整個瓶頸就解 除了，應用程式分享功能可以達到 VenueServer 可 以容納的人數上限。不過，由於是使用影音轉換方 式，協同工作的能力便遭受限制，仍必須透過連接 VNC Server 的方式來進行。好在大部分的情況 下，多人協同操作一般仍然是由少數人控制(比方說 遠距教學的老師及助教)，大多數的人(學生)只需看 (聽)的到就可以了，所以這問題並不嚴重，因為在 我們把 VNC Server 獨立出來後，一台 Pentium4 2.6GHz 的電腦已經可以容納超過十個人協同操作 (實際測試結果，受限於測試環境，並未測試到極 限)，大多數環境下是足夠了。在這個架構中，我們 測試各種不同應用程式共享結果如表 3 所示。 表 3 增設 VIC Encoder 的測試結果 軟 體 形 式 測 試 結 果 一般圖文操作 正常，但無互動能力。 聲音播放 正常 影片播放 所有格式均正常。 在設計 VIC Encoder 時，為了維持最佳的使用 者相容性，我們儘可能在現有的版本中壓榨出最佳 的效果，其中也做了一些取捨。首先，由於 VIC 程 式已多年未改版，以目前 AGTk 2.4 版的 VIC v2.8ucl-1.1.3-AG 為 例 ， 原 先 的 設 計 是 針 對 CIF (Common Intermediate Format)規格規劃的，預設的 編碼尺寸也只有 352*288 (h.261, normal)，對於目 前動輒 800*600、1024*768 甚至更高的解晰度操 作桌面而言，不到 1/4 的壓縮影像代表極大的失 真。分享 VCD 格式影片還可以，拿來分享桌面的 應用程式，簡直是慘不忍睹，以 Microsoft word 為 例，幾乎無法用肉眼辨識出每個字的意義。經過測 試及分析所有內建的編碼器，得到如表 4 的結果。 表 4 編碼器的最佳效果 Size Encoder

Small Normal Large H.261 176*144 352*288 不支援 H.263 176*144 352*288 不支援 H.263+ 176*144 352*288 不支援 nv/nvdct 160*112 320*240 640*480 JPEG 160*112 320*240 640*480 註一：實際編碼串流格式 640*480 註二：忽略使用 raw 等無法執行的編碼方式 為求減少失真，JPEG 及 nv/nvdct 的 Large mode 似乎是我們最好的選擇。但由於 VIC 採純軟 體編碼，最大頻寬又被軟體限制於 6mbps，諸多限 制造成了實測結果並不佳。舉例而言，motion JPEG 每一個 frame 是一張單獨照片，如果採用 Large mode 不失真壓縮，以一台一般 P4 2.6G 的機器來 運算，I/O 速度根本來不及，會導致影像的最後 10% 左右無法完成編碼，而無法顯示。即便採用失真壓 縮 quality < 90%，仍只能提供到約 15-17fps 的更新 頻率，在分享的是動態影片時效果並不理想。 同樣的 nv (network video)雖然是使用漸進式 編碼，在 Quality = 100%時，仍受限於 6mbps 的頻 寬管制，也只能顯示 8-18fps 的更新頻率。當我們 把 Quality 降到 90%，就可以顯示 22-25fps 的更新 頻率(頻寬約 3.8mbps)，才算的上可以接受的範圍， 同時 nv 的 Harr 區塊編碼在高動態時容易產生馬 賽克，最後我們選擇 dct 編碼的 nv 格式(Access Grid 中稱為 nvdct)，作為我們的最佳選擇，雖然略 有失真，但還在一般狀況可以接受的範圍。 除此之外，在硬體介接上也有諸多的限制，像 是在 VNC Server 與 VIC Encoder 互連上，由於 PC 影像輸出訊號一般為 DB15 或是 DVI 介面，而市面 上這類規格的 Frame Grabber 並不多見，且動輒數 萬至數十萬不等，非我們所能負擔，因為成本考 量，我們在 VNC Server 端裝設 HDTV 規格的顯 示卡，1080i 的規格可以減少一般 1024*768 以下 畫面輸出的失真，並在 Encoder 端安裝支援 mpeg2 的 Frame Grabber，以減少傳送到 VIC 軟體前的不 必要失真，來達成最佳效果。目前達成的最佳實用 設定如圖 12 所示。 圖 12 實驗結果最低失真模式 3.3 使用 IP 遠端控制器 雖然上述的解決方案已經解決掉大多數應用 程式分享的問題，可是，在我們架構及測試的過程 當中，仍然發現有以下問題的存在。 利用 AGTk 所提供的 VenueVNC 服務，雖然 很方便，但是因為 Venue Client 內建的 Application Session 模式，並無法帶入任何參數，以至於在 VNC Server 端，必須把所有安全性設定(包括加密 編碼、基本密碼認證等)全部關掉，才能順利使用。 這也就導致了 VNC Server 等於無設防的暴露在 網際網路的公開環境中，任何人只要知道 IP 位 址，都可以連進去當做跳板，做他想做的事。 如果要進行基本的密碼認證，以做到最基本的 安全條件，在使用者端就必須另外安裝圖形化的 VNC Client，並自行啟動；或是利用 DOS 視窗， 以文字模式將所需參數帶給內建的 vncviewer。這 兩種方式對於使用者來說都是不方便的，特別是如 果要將 Access Grid 對大眾推廣，一般人還必須透 過額外的學習才能知曉要如何使用。 再者，即使打開了密碼認證，使用者也知道了 VIC Encoder AG Client VNC Server 原始影像 800*600 Frame Grabber 640*480 第一次失真 HDTV 輸出，略有類 比訊號線材訊號失真 VIC nvdct Large 640*480 Quality=90% 第二次失真 使用者解碼 Large Display 570*420 第三次失真 VNC Server Venue Server

用法，由於 VNC Server 原先的設計是給管理者連 線管理伺服器使用，也因此，他能接受的帳號密碼 只有一組，這在多人的環境中，會造成無法識別使 用者的問題。舉例而言，在一個 Access Grid 多人 視訊會議中，為了讓參與者能連上 VNC Server， 我們可能會在會議前或文字交談視窗中公佈相關 的連線資料(IP, Account, Password)。因為每個人取 得的資料都一樣，作為 VNC Server 主控端，我們 便無法辨識連線者。如果這是一個內部會議還好， 但如果這是一個對外公開的論壇會議，任何人都可 以參加的話，那風險就如同未設密碼一樣。 Venue Server Bridge Server Venue Client

Venue Client Venue Client Venue Client KVM over IP Shared Client 圖 13 使用 IP 遠端控制器架構 因此，我們嘗試利用 IP 遠端控制器(KVM over IP)設備，來解決掉安全性的疑慮，架構如圖 13。 在測試的過程中，也發現到它的一些額外優點。 z User Friendly 的登入與操控 遠端控制器的登入管控介面是 Web 型式，由 於 Venue Client 不支援密碼輸入，Web 介面成了 最佳的第二選擇，操控端是直接由 java 帶起的， 不但跨平台，對使用者來說也無須任何設定。 z 良好的使用者管控 以我們目前測試的設備為例，它支援到 35 個 內建使用者帳號，更支援 RADIUS[10]，我們可以 為每一個使用者建立一個獨立帳號，也可以為匿名 者建立唯讀的不同權限帳號。同時，可以使用內建 的紀錄檔或是外掛 log server 的方式，詳細記錄每 位使用者的登出入時間。 z 具有可擴充性 目前一台遠端控制器可同時容納 15 位線上 使用者，但由於它是可串聯的，隨時要擴充只需再 串接，就可以達到 N*15 位協同操控的效果。 z 更好的互動模式 先前利用 VNC Server 做協同工作時，遭遇了 一個問題。因為是多人同時在操作一台電腦，大家 操作的是同一支虛擬滑鼠，容易造成搶滑鼠的問 題，導致控制上並不順暢。在遠端控制器的 java 介 面上，由於可以利用熱鍵(HotKey)切換模式，非操 控者可以跳離 single mouse mode，繼續操控自有的 桌面(比方說 Access Grid 的 RAT 或 VIC 等)，必 須操控時再點入視窗內，自動取得操控權。如此一 來，相互的干擾就減少了，工作起來也就更順暢。 當然，遠端控制器模式也並非完全沒有缺點， 因為是用內建的 SoC 進行編碼與模擬鍵盤滑鼠功 能，部份情況下編碼速度會不盡理想。另外，由於 目前的硬體尚無支援聲音混音編碼，所以此種方式 仍只能用於影像環境，在必要情況下，我們可以透 過 AGTk 的 RAT 來解決。在這個架構中，我們測 試各種不同應用程式共享結果如表 5 所示。 表 5 IP 遠端控制器的測試結果 軟 體 形 式 測 試 結 果 一般圖文操作 正常。 聲音播放 無法運作。 影片播放 影像正常，聲音無法運作。

4. 新架構的適用環境分析與應用

這三種新的模式各有優缺點，彼此之間也都可 以組合應用，我們針對個別差異比較如表 6 所示， 並分析如下。 表 6 三種新架構特性比較表 獨立 VNC Server VIC Encoder 遠端控 制器 安全性 低 高 高 建置成本 低 最高 高 使用者方便性 佳 優 佳 原系統整合度 高 高 低 協同工作 佳 無 可 靜態畫面分享 高 中 高 多媒體支援 低 佳 中 可攜程度 中 低 高 z 獨立 VNC Server 由於建置成本低廉，只需用一台 PC 安裝並設 定好免費的 VNC Server 軟體即可，使得它最適用 於大部份環境。然而，由於多媒體的支援不足，如 果要進行線上影片分享就全然不適用。另外，缺乏 安全性也是它的一大隱憂。 z VIC Encoder 因為需要獨立的編碼機器、擷取卡等設備，建 置成本最高，缺乏互動性，影像也略為會失真，但 對各種文件格式分享，包括影像及聲音均不會有問 題，再加上可以充分利用 multicast 節省頻寬的特 性，可同時分享給最多的使用者端，特別適用於線 上影片分享，或是大規模環境上。 z 遠端控制器 相較於另外兩種的極端特性，利用遠端控制器 來進行應用程式分享就顯得中庸許多。兼顧安全性 與使用性的用途讓它很方便應用，但由於硬體的延 遲仍無法單獨適用於大規模環境。缺乏聲音編碼的 支援是他目前最大的缺點，需配合 RAT 來同時並 用。除此之外，它的可攜性(體積僅約一台光碟機大 小)更可以為它帶來特別的應用，舉例如下節說明。

5. 非特定應用程式分享架構混何應用案例

先前，在我們進行 Access Grid 遠距教學時， 有一次的活動，因為參與人數眾多，安排在一個大 講堂進行，同時規劃利用 Access Grid 進行現場轉 播。由於該講堂非 Access Grid 專用教室，原先並

無任何轉播設備。如同一般傳統的講堂一樣，講堂 左前方有演講台、電源、網路，正前方是單槍及投 影布幕，右前方架設次投影布幕與單槍投影機，講 堂的後方有一主控式，控制講堂的燈光、音響等設 備，主控室內也有網路接點，前後距離超過十公 尺。由於只是轉播兩個小時的活動，為了方便性， 我們使用筆記型電腦作為 Access Grid 轉播設備， 外接數位攝影機拍攝影像。 在配置轉播設備時，由於所有的聲音控制都是 集結到主控室，我們必須要安排一台筆記型電腦於 後方，負責聲音收送，同時，加掛一台數位攝影機 負責攝影。主講人用自行攜帶的筆記型電腦進行簡 報，為取得投影資料，我們必須用攝影的方式拍 攝。但因為講堂的主投影幕超過 200 吋，如果我 們要拍攝主講人的投影資料，那勢必主講人就無法 入鏡；反之如果要拍攝主講人，遠端參與者就看不 到投影資料。唯一的解決途徑就是使用兩台筆記型 電腦加上兩台數位攝影機，第一組針對主講人及聲 音，第二組針對投影資料各傳送獨立訊號。試播時 發現，由於現場的環境光源太過明亮，以數位攝影 機拍攝投影資料仍有白平衡失真問題，不盡理想。 同時，為避免拍攝的投影資料被聽眾阻擋，以及階 梯講堂後方的高俯角的問題，我們必須把第二組設 備儘可能向前移動，也讓我們必須增加第二位操作 者來操作現場 Access Grid 轉播。 在進行本研究之後，我們規劃出了一個更佳的 轉播架構如圖 14。 圖 14 大型環境混何應用 我們預先於遠端機房設定好 VIC Encoder 及 Remote Client 兩組設備，Remote Client 是一台一 般的 PC，作為演講者投影資料的中介；同時外接 遠端控制器，以方便操作員進行遠端操作。 轉播前我們僅需攜帶一台遠端控制器、一台筆 記型電腦、以及一台數位攝影機和相關線材到現 場，將遠端控制器直接串接於演講者的筆記型電腦 與單槍投影機之間；操作員只需坐在主控室，遠端 啟動機房內 Remote Client 的程式及 VIC Encoder 後，專心負責現場音控及主講者攝影即可。 這樣的規劃，使得我們所需的人力減少了(由兩 人減為一人)，雖然要多帶一台電腦光碟機大小的遠 端控制器，但可以少帶一台筆記型電腦、一組數位 攝影機及腳架，還有許多線材，可攜性相對提高了 許多，更重要的是，主講人的投影資料變的十分清 晰(從主講人到遠端參與者收看的畫面，都是透過直 接轉換，失真較少)，也不用擔心主講者的各種應用 程式問題。用在臨時性的轉播上，效果相當良好。

6. 結論

Access Grid 是一個完善的寬頻多人視訊會議 系統，未來隨著網路骨幹、接取端頻寬的不斷提 升，他將能吸引更多的使用者；也隨著他本身系統 的不斷擴充加值，未來的用途也將更加寬廣。 在它本身已提供的功能上，我們在此文章中另 外 提 出 了 三 種 新 的 應 用 架 構 ， 包 括 獨 立 VNC Server、VIC Encoder、及遠端控制器，讓非特定應 用程式，得以根據其需求，架構適合的方式，配合 Access Grid 來達到多人共享的模式。加上彼此之間 的組合，在實際的環境中，我們已經可以讓幾乎所 有的環境與應用程式，達到便利性共享的目的。 目前的應用程式分享架構，仍然有一個缺點， 就是沒有中央控管的機制，來控制分享時的操控 權，如何加強協同工作的互動性與操控性，並加強 影像品質(比如說透過 mpeg4 或是 H.264 傳遞)， 是值得我們未來再花心力關注的地方。

7. 致謝

感謝財團法人國家實驗研究院國家高速網路 與 計 算 中 心 超 級 視 訊 格 網 計 畫 委 託 研 究 (93A2067701)的贊助，使得本研究得以順利進行。

參考文獻

[1] Access Grid: http://www.accessgrid.org/. [2] VenueVNC: http://www.mcs.anl.gov/fl/research/accessgrid/ software/releases/2.3/patches/VenueVNCServe r.py. [3] RealVNC : http://www.realvnc.com/, [4] TightVNC: http://www.tightvnc.com/. [5] K. Egevang, P. Francis, “The IP Network

Address Translator”, IETF RFC 1631, May 1994.

[6] Robust Audio Tool:

http://www-mice.cs.ucl.ac.uk/multimedia/softw are/rat/. [7] AniCAM: http://anicam.learnbank.com.tw/new_page/intr o/index.html. [8] “Recommendation ITU-R BT.470-6, Conventional Television Systems”, ITU, November 1998。

[9] Videoconferencing Tool, http://www-nrg.ee.lbl.gov/vic/

[10] C. Rigney, S. Willens, A. Rubens, W. Simpson, “Remote Authentication Dial In User Service”, IETF RFC 2865, June 2000.

VIC Encoder Venue Server

Bridge Server Remote Client KVM over IP 演講者 Venue Client Venue Client Venue Client 視訊設備 音控設備 操作員 2 Portable Venue Client 演講台 主控室 遠端機房 AG遠端參與者