情境感知改編協調

2.1.1 情境資訊(context information)

情境(Context)［1］［2］是一可以用來描述任何抽象或具體東西的表徵 資訊。這些抽象或具體的東西可以是一個人、一個地方、或是任何的物件，只要 這些東西彼此之間都和使用者或是應用程式互相牽引著。

舉例來說以下都可以稱是情境資訊(Context information)［1］［2］［9］

:

z Identity

z Spatial information z Temporal information z Environment information z Social situation

z Activity z Resources

z Schedules and agendas

我們可以舉簡單的例子來說，對同一份多媒體內容，他可能被在不同環境的客戶 端透過網路下載觀看，然而它對客戶端使用者卻有不一樣的感受。比如有些客戶 端所在的網路環境頻寬品質很差，他必需等待很久的下載存取時間。或是兩個客 戶端他們所使用的瀏覽裝置支援程度不同，螢幕大小有顯著差別，有些可能在一

個螢幕畫面可以看到全部的多媒體內容，有些則限於螢幕太小則需藉由其他方式 看到全部(例如：縮小全部畫面、藉由 Scrollbar 拖拉)。這些影響多媒體內容品 質及使用者觀看操作等因素，都可以稱為是情境資訊。

2.1.2 情境感知(Context aware)

情境感知(Context aware)意指有能力去使用或擷取情境資訊(Context information)。最近在行動異質計算環境下，使用者有可能每天在不定時刻的 透過跨平台或跨時間的存取計算服務能力。到最後使用者的注意力可能會被分散 到幾個不同的activities 。再者計算能力的載具(Device)越來越小，而導致裝 置被使用能力的論點探討。情境感知是一個能夠顯示關於使用者、載具、環境以 及那些可以增加使用者在異質行動裝置上互動的資訊觀念。

目前情境感知計算(Context Aware Computing)仍是一個新興而且被眾 多人討論的議題。他主要的意涵在於提供一個運作模式和使用它來設計給開發情 境感知系統的工具。對於強調人機介面的系統來說，情境感知系統越來越重要及 普及。因為人機介面的系統必須將人的使用經驗、情況(user experience、

situation)納入整合到計算機的計算過程中。情況感知(situation awareness) 更可被用來減少人為輸入的繁雜動作。藉由分析情境資訊有可能減少額外的計算 工作、提供使用者更友善的介面服務。

一般情境感知的協調系統需要透過核心的原件－決策引擎(decision engine)［6］來進行處理，而大致決策的流程如下圖 1 所示：

圖 1:一般決策引擎模組

由圖1 得知一個決策引擎的行為有兩種階段簡述如下：

1. 前置處理流程(這步驟發生在使用者要求之前)所負責的定量品質分析 (quantitative analysis of quality)是以品質數值(quality value)來衡量的一 個基準，而分數評估(score evaluation )和表徵(representation)則是一個總 計分數(aggregate scores)所成的集合當作主要的輸入資訊給決策引擎，然後 決策引擎再決定最佳化的輸出版本。

2. 及時處理流程(這步驟處理使用者要求)所負責的決策邏輯(decision logic) 和分數節點選定(score node selection)、次序關係(ordered relation)是進 行決策引擎的演算法，定義一個分數節點(score node)的意思是指使用者喜好 特性的權重分數，用以捕捉所有可能的偏好值(preference values)的組合，而 決策邏輯(decision logic)幫助找出對應到一個內容呈現的最好分數節點

(scoring node)，而這個節點是依據一些特性參數所決定出的。一般而言，決 策此流程是否可獲得正確的協調畫面深受原始內容及所使用的轉譯法影響。

2.1.3 內容改編協調(Content Adaptation)

多媒體內容的轉換包括了內容形式的變化、格式的轉換、多媒體物件的轉 換，這些過程為的是能夠符合在目前行動裝置快速發展及無線網路頻寬演變下的 異質環境。基於使用目的的不同，內容改編協調(Content Adaptation) 的設 計會有所不同，有些會以Qos(Quality of Service)［3］來考慮，有些則以支 援程度來作為轉換的依據。而通常大部分的內容改編協調伺服器(Content Adaptation Server)會搭配情境感知(Context awareness)機制來做智慧型 轉換。

對於一般多媒體內容的轉換存取方法分成下列兩種類型［2］［14］：

z 靜態改編協調(Static adaptation)

在編輯內容的時候，內容將經過處理而轉出各式各樣的版本並儲存在特 定的資料庫裡。而在呈現的時候，會選擇相對應適合播放的版本。

z 動態改編協調(Dynamic adaptation)

所有的分析轉換動作皆在當客戶端有需求時才適時反應。也就是動態的 產生多媒體內容，相對於靜態改編協調來講它不需要額外的儲存空間。

下表1 是靜態改編協調和動態改編協調的優缺點分析：

表 1：靜態和動態的好壞處

本研究另外一個議題是希望結合靜態以及動態的好壞處，來較佳化轉譯時間以及 磁碟空間使用量。

而一般作改編協調的架構有下列幾種［14］：

z 伺服器為基礎的改編協調(Server-based adaptation)

媒體伺服器(Media Server)負責處理分析所有情境資訊(Context information)，選擇適當的轉換方式，而其轉換方式可以是靜態或是 動態。通常有管理介面提供管理者來改編協調，以期許轉出來的結果是 合理的。

z 客戶端為基礎的改編協調(Client-based adaptation)

客戶端基礎的轉換是考慮到裝置的支援能力，利用客戶端的轉換而選擇 最佳的呈現畫面，而選擇的可能是所有的樣板形式集合。客戶端為基礎 的好處是伺服器端不需要知道客戶端的裝置支援程度，壞處是客戶端需 要有強力的處理能力(Computing power)，不然對於複雜的多媒體內 容也許呈現會有延遲狀況。

z 代理伺服器為基礎的改編協調(Proxy-based adaptation)

類似於伺服器為基礎的改編協調，只不過比伺服器為基礎的改編協調較