• 沒有找到結果。

中 華 大 學

N/A
N/A
Protected

Academic year: 2022

Share "中 華 大 學"

Copied!
60
0
0

加載中.... (立即查看全文)

全文

(1)

中 華 大 學 碩 士 論 文

應用通用型隨插即用技術於數位家庭網路之 影音同步控制

To Apply UPnP Technology in Synchronization between Separated Video and Audio Players

系 所 別:資訊工程學系碩士班 學號姓名:M09502057 黃昱翔 指導教授:劉懷仁 博士

中 華 民 國 九十九 年 八 月

(2)

 

摘要

近年來隨著寬頻網路的普遍以及資訊家電的興起,數位家庭的應用與服務也逐漸開 始呈現快速的成長,尤其是家庭影音娛樂方面,利用有線或無線的軟硬體裝置在家庭網 路中建置播放影音的娛樂環境,目前數位家庭網路應用技術方面,多數的消費性電子廠 商皆以微軟及 Intel 大力推動的通用型隨插即用協定(Universal Plug and Play)為主 要的關鍵技術,讓不同廠牌間的軟硬體設備不需要額外的設定就可以互相搭配及支援多 媒體影音的播放。

以傳統的家庭式劇院播放模式為例,影像及聲音其實是利用同一個光學儲存媒體作 為資料存取媒介,播放時會經由多媒體播放裝置,如:VCD、LD、DVD 及最新的藍光播放 器…等,把影像及聲音分離出來,其後再交由專門的影像及聲音處理器呈現到螢幕及喇 叭,而現今及未來的數位家庭網路環境中,聲音及影像來源可能分別由不同的有線或無 線裝置提供,以因應不同的播放需求,其影像及聲音裝置可能因為使用者有快進或是倒 轉的行為模式影響,進而導致影像及聲音裝置在傳輸播放的期間產生不同步的現象,讓 整個播放的過程不順暢。

因此我們提出以維持原有多媒體網路播放架構為前提,且不需額外的硬體建置成 本,加入我們的影像及聲音裝置同步校正方法,應用通用型隨插即用協定作為同步資訊 的溝通協定;在多媒體內容播放的期間,影像播放裝置能夠會週期性的主動檢測聲音播 放裝置是否有不同步的情況發生,在短時間內快速的改善並降低由使用者行為產生的影 音不同步現象。

關鍵字: 通用型隨插即用協定、同步校正、數位家庭多媒體網路

(3)

ABSTRACT

On Multimedia Digital Home Networks, an audio player may be separated from the video player. Due to forward or rewind a video, it makes the video player and the audio player asynchronous. Based on the original UPnP AV architecture, a synchronous mechanism is proposed in this paper. With exchanging both status of the video player and the audio player in UPnP messages, the synchronization is accomplished.

Keywords: Multimedia Digital Home Networks、UPnP、synchronization

(4)

 

致謝

 

首先感謝我的指導教授劉懷仁博士,在求學期間讓我學習到無論大小事都需 要以嚴謹的態度去面對,小心的求證假設以及推求合理的解釋,也讓我學習到對 問題追根究底及多方思考的態度。

感謝實驗室的學長們,不論在學業及日常課業上都能夠互相討論,也特別感 謝彭炳衡學長,在我求學期間的照顧,教導我許多在實做方面的相關技巧及經 驗,當遇到困難時並不會直接告訴我該怎麼做,而是提出一些經驗及關鍵字讓我 去思考如何解決或是搜尋相關資料,讓我養成對於實做方面有一定程度的問題解 決能力。

也感謝家人及朋友在這段時間對我的支持與鼓勵,讓我在求學期間能無後顧 之憂的專心的做研究,也向其他有幫助過我的人,致上最高的敬意。

(5)

目錄

摘要 ... i 

ABSTRACT ... ii 

致謝 ... iii 

圖目錄 ... v 

表目錄 ... vii 

第一章  簡介 ... 1 

第二章  背景知識與相關研究 ... 5 

2.1.  通用型隨插即用協定( UPnP) ... 6 

2.1.1.  通用隨插即用協定元件關係 ... 7 

2.1.2.  通用型隨插即用協定堆疊結構 ... 8 

2.1.3.  通用隨插即用運作流程 ... 11 

2.2.  通用型隨插即用影音(UPnP AV) ... 18 

2.3.  多媒體串流技術簡介 ... 20 

2.4.  相關研究論文及軟體應用 ... 22 

第三章  研究情境與研究方法 ... 27 

第四章  系統實做與結果分析 ... 34 

4.1.  系統架構 ... 34 

4.2.  實驗方法 ... 38 

4.3.  實驗結果及說明 ... 39 

第五章  結論 ... 49 

參考文獻 ... 50 

(6)

圖目錄

 

圖 1.1、多媒體數位家庭網路播放環境圖 ... 2

圖 1.2、多媒體裝置播放簡易原理 ... 3

圖 2.1、UPnP 元件圖 ... 7

圖 2.2、 UPnP 協定堆疊結構圖 ... 8

圖 2.3、 UPnP 運作流程圖 ... 11

圖 2.4、探索-Device Advertisement ... 12

圖 2.5、探索- Control Point Solicitation ... 13

圖 2.6、描述-Description ... 14

圖 2.7、控制-Control ... 15

圖 2.8、控制-Event ... 16

圖 2.9、介面呈現- Presentation ... 17

圖 2.10、通用隨插即用架構 ... 19

圖 2.11、通用隨插即用 A/V 架構 ... 19

圖 2.12、PTP 訊息交換流程 ... 23

圖 2.13、隨插即用裝置並行控制流程 ... 24

圖 2.14、通用型隨插即用技術內容同步交換流程 ... 25

圖 2.15、Cidero-Default Configuration ... 26

圖 2.16、Cidero-Preferred Configuration ... 26

圖 3.1、數位家庭網路情境示意圖 ... 28

圖 3.2、UPnP AV 3-Box 架構 ... 29

圖 3.3、進階 UPnP AV 3-Box 架構 ... 30

圖 3.4、通用型隨插即用影音同步控制校正流程圖 ... 32

圖 3.5、通用型隨插即用影音同步控制校正狀態機 ... 33

圖 4.1、影音播放同步系統第一階段 ... 35

圖 4.2、影音播放同步系統第二階段 ... 37

圖 4.3、實驗環境拓樸圖 ... 38

圖 4.4、無模擬使用者行為模式的播放行為(無 forward/backward) ... 39

圖 4.5、快進模式 ... 40

圖 4.6、介於 23829~23859ms 間快進 5 秒同步花費速度放大圖 ... 41

圖 4.7、介於 47630~47678ms 間快進 10 秒同步花費速度放大圖 ... 41

圖 4.8、介於 71457~71517ms 間快進 30 秒同步花費速度放大圖 ... 41

圖 4.9、介於 98000~98487ms 間快進 1 分鐘同步花費速度放大圖 ... 42

圖 4.10、介於 98000~98487ms 間快進 5 分鐘同步花費速度放大圖 ... 42

(7)

圖 4.11、介於 98000~98487ms 間快進 10 分鐘同步花費速度放大圖 ... 42

圖 4.12、介於 98000~98487ms 間快進 15 分鐘同步花費速度放大圖 ... 43

圖 4.13、介於 98000~98487ms 間快進 30 分鐘同步花費速度放大圖 ... 43

圖 4.14、八種快進機率分佈 ... 43

圖 4.15、模擬使用者隨機倒轉模式 ... 44

圖 4.16、第一次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 45

圖 4.17、第二次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 45

圖 4.18、第三次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 45

圖 4.19、第四次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 46

圖 4.20、第五次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 46

圖 4.21、第六次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 46

圖 4.22、第七次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 47

圖 4.23、第八次模擬使用者隨機倒轉模式同步花費速度放大圖 ... 47

圖 4.24、八次倒轉模式機率分佈 ... 47

                                             

(8)

 

表目錄

表 2.1、Advertisement Protocol Stack ... 12

表 2.2、 Solicitation Protocol Stack ... 13

表 2.3、Description Protocol Stack ... 14

表 2.4、Action Protocol Stack ... 15

表 2.5、Eventing Protocol Stack ... 17

表 2.6、Presentation Protocol Stack ... 18

表 2.7、HTTP Streaming 與 RTP Streaming 比較 ... 21

     

(9)

 

第一章 簡介

 

隨著寬頻網路的普遍、資訊家電的興起及消費性電子市場蓬勃化的發展,數位家 庭的應用與服務也逐漸開始呈現快速的成長,這樣的趨勢也造就了越來越多的資訊家 電產品融入我們日常生活的家庭空間,較常見的應用產品偏向於家庭影音娛樂方面,

例如:無線耳機、無線音響、數位相框、家用多媒體伺服器、PDA、MP3、印表機…

等,這些利用有線或無線的軟硬體裝置,在家庭網路中建置具有播放影像及聲音的娛 樂環境,但是消費者購買回家以後大部分都需要經由安裝驅動程式以及初始化設定以 後才能夠開始使用這些消費性電子,要如何簡化這些裝置安裝及設定的技術將成為主 要市場的重要關鍵。由微軟及 Intel 等公司發表的通用型隨插即用(Universal Plug and Play)[1]技術就是為了解決使用者在裝置設定方面的問題,而制定出的一套介面互通 操作標準,此標準可以架構在不同的實體傳輸介面上,如: Ethernet、Wireless Ethernet、Bluetooth、USB 或是未來的 WiMAX 等,支援此標準的裝置皆可以自動的 搜尋、連接及做初始化的動作,這個標準主要是由延伸個人電腦中的硬體 Plug and Play[2]的概念,直接應用在網路通訊應用上,其特點是大大地降低使用者在操作設 定上的困難度,相對的也提昇了一定程度的便利性。

現在市面上有許多符合通用型隨插即用協定規範的多媒體網路播放裝置被發 表,在數位家庭網路的多媒體播放環境中,也有越來越多的多媒體資訊家電加入,我 們不難想像未來在我們生活的家庭空間與室內環境裡,有著多組的無線聲音播放裝置 及具有顯示器功能的無線裝置分佈在整個居家環境中,更有可能利用智慧型手機 (Smart Phone)、個人數位助理(PDA)、行動連網裝置(Mobile Internet Device ,MID)及超 小型行動電腦(Ultra Mobile PC ,UMPC)等手持式裝置播放影像搭配使用無線的音響 或是無線藍芽耳機播放音樂…等,也可能是播放藍光畫質影片[3]搭配無線的家庭劇 院組音響,多種不同用途的排列組合的裝置搭配使用,或是由遠端的家庭網路或是遠

(10)

端的多媒體伺服器將多媒體內容利用寬頻網路傳送至家庭內部的多媒體播放裝置上 [4][5][6]等,最後將這些影像及聲音順利的傳送至我們想要享受影音的各種不同組 合裝置上如圖 1.1 所示,這些裝置分別有不同的播放品質需求。

圖 1.1、多媒體數位家庭網路播放環境圖

在選取裝置搭配的方式上,通用型隨插即用協定本身就具有隨插即用的功能,可 以讓使用者只需要選取有興趣的裝置搭配用來達到多媒體播放的目的,但是要讓影像 及聲音輸出利用網路傳送至播放裝置上,並且能夠順利的同步做播放的動作是一個重 要的課題。以影音播放裝置為例,如圖 1.2 所示,影音播放器利用讀取頭將視訊及音 訊的二進制資料分別讀取至不同的解碼過程,其中利用專職的視訊及音訊解碼晶片分 別為視訊及音訊進行該資料的解碼,最後輸出至各自的輸出介面並經由有線或無線網 路傳至對應之播放設備,在整個播放過程中,因為影像及聲音裝置為各自獨立的裝 置,所以可能因為使用者快進或是倒轉播放影像部分,使得影像及聲音裝置相對的產 生誤差,進而導致多媒體影像及聲音裝置在播放期間會有不同步的現象發生,以現階 段的多媒體數位家庭播放裝置為例,越來越多的裝置是採用網路傳輸多媒體訊號,而 各個撥放裝置皆是獨立運作,以單獨的音訊傳輸處理過程為例,會出現 5.1 聲道各個

(11)

介面彼此溝通皆是透過無線網路傳輸處理播放等應用,而這種應用可能皆會受到使用 者在撥放多媒體時的行為影響,造成各個多媒體播放裝置產生不同步的播放情況,所 以在此環境中多媒體同步處理儼然是一個很重要且必須達到的目標。

圖 1.2、多媒體裝置播放簡易原理

本論文主要提出一個在多媒體數位家庭網路中,利用原有通用型隨插即用協定的 架構及其協定特性,針對多媒體視訊資料及音訊資料做一個同步校正的處理,透過這 個同步校正的構想可以讓整個多媒體影像及聲音播放的環境更加的完整及提昇整體 播放的品質。本論文將會以一個多媒體播放環境的實際應用來說明同步校正的情境,

及探討同步校正應用於實際建構上的考量,並且以開放原始碼組織 VideoLAN VLC Media Player[7]為主要播放解碼裝置,加入本論文實做的多媒體同步裝置,結合這兩 者的特性實現並且展示如何降低視訊資料及音訊資料在解碼或是傳輸過程中所造成 的不同步現象,藉由此架構希望可以提昇播放的品質,使得使用者在符合通用型隨插 即用協定的多媒體網路傳輸播放過程中能夠享受一定品質的多媒體播放過程。

本論文主要分成五章,第一章已經簡介現今多媒體數位家庭網路發展的一些情況

(12)

與其應用模式,以及敘述本論文的研究動機。接著後續的章節內容編排如下,第二章 會介紹的通用型隨插即用協定相關知識背景、應用技術介紹及相關研究。第三章為本 篇提出之研究情境、研究方法等。第四章為實驗環境、實驗參數說明、實驗方法及實 驗結果分析。最後第五章為本篇論文做一個總結。

(13)

第二章 背景知識與相關研究

在這個章節我們將介紹本論文中觸及到的相關領域知識背景、關鍵技術介紹及相 關研究探討。在數位家庭網路應用技術中有許多不同的標準,例如:通用型隨插即用 (Universal Plug and Play , UPnP)[1]、數位生活網路聯盟(Digital Living Network Alliance, DLNA)[8]、開放式服務性閘道器標準組織(Open Services Gateway Initiative, OSGi)[9]等,其中以由 Microsoft、Intel 等公司在 1999 年發表及大力推廣的通用型隨 插即用(Universal Plug and Play)為主要的技術標準,旨在提供一個免費的國際共通標 準,以便用來實現裝置間的相互發現和控制,希望對於資訊家電及網路通訊設備間能 夠制定一個共通的標準介面,達到一個裝置互通及智慧型裝置連結與自動化設定的標 準機制,只要任何支援通用隨插即用的裝置進入網路即可自動化的連結及安裝設定,

讓使用者不需要額外做特別的操作就可以驅動通用型隨插即用的設備在數位家庭網 路環境中運作,並且相容於其它的通用型隨插即用裝置,在此網路架構下的設備彼此 之間皆能夠進行控制及資料的傳輸。

在通用型隨插即用協定之後又訂定了通用型隨插即用影音(UPnP AV) [10]的延伸 協定,主要是將通用型隨插即用原有的協定規範群組化後,專門為了音訊及視訊服務 提出的應用協定,成為家庭影音設備協同運作的重要技術,此外,UPnP AV 也成為數 位生活網路聯盟(DLNA)架構中的核心部份,數位生活網路聯盟主要是以 UPnP AV 為 主要底層核心技術,此聯盟的任務是制定一個統一的傳輸規範,讓各種不同廠牌、類 型的多媒體播放裝置能相互溝通。因此,只要是符合 DLNA 的多媒體播放裝置,就 能在不需驅動程式、轉接裝置下直接連結、同步動作,甚至是傳輸資料。

(14)

2.1.   通用型隨插即用協定( UPnP) 

UPnP 全名是Universal Plug and Play,即通用型隨插即用。最先在1999年1月由微 軟正式發表,其後由微軟、Intel等公司發起組織UPnP論壇(The Universal Plug and Play Forum),旨在提供一個免費的國際標準,以實現裝置間的相互發現和控制。UPnP論 壇目前全球有超過700家企業和組織加盟,其核心成員是Sony、Cannon、Samsung、

LG、TCL (Thomson)、Nokia、Panasonic、Siemens、IBM、HP及Intel等19家公司,

架構是在2000年6月由美國微軟公司及其他25家公司於1999年1月所成立的一個非營 利性組織,即UPnP論壇提出之規範,用以發展一套結合既有的TCP/IP、HTTP及XML 等Internet協定的通用型IP網路通訊技術,以實現於IP網路上的產品即插即用、點對點 (Peer to Peer)等網路通訊功能。

通用型隨插即用協定是一個讓任何形式的無線裝置、個人電腦、數位家電等都能 達到點對點網路連線的架構,也是一個公開且分散的網路架構,架構在現有標準 TCP/IP 和網際網路通訊協定傳輸技術之上,讓家庭、公司或是其他的網路應用環境 都可傳送資料及控制資訊,也可以使得 UPnP 適用於許多已有的研究及開發實務技術 上,此外通用型隨插即用協定,不受任何特定作業系統、程式設計語言、或實體媒體 的影響,所以在各類型的裝置上皆有很高的移植性。通用型隨插即用協定與硬體隨插 即用皆由微軟所倡導,強調隨插即用的特性;冠上Universal的字眼,正意味著微軟意 圖將原來的Plug and Play擴大到任意裝置上的概念,實現在IP網路的環境中,且具有 零設定(Zero-Configuration)、自動探索(Auto Discovery)其他裝置存在的特性。在此 架構下,設備可以動態加入或離開一個網路、自動取得IP位址、發佈自身裝置功能和 搜尋其他裝置的存在及服務,完全不需要使用者介入操作裝置組態。

(15)

2.1.1. 通用隨插即用協定元件關係

通用型隨插即用協定各元件之間的關係如圖 2.1 所示,主要的組件有受控制設備 (Controlled Device)、控制點(Control Point)以及服務(Service)。

圖 2.1、UPnP 元件圖

A. 服務(Service):服務是通用型隨插即用協定架構中最小的單位,主要功能為提供 操作動作、改變狀態及提供一組狀態變數紀錄目前此服務的狀態。

B. 裝置(Controlled Devices or Devices):裝置是包含服務及內嵌裝置的設備,通常為 硬體裝置。不同種類的 UPnP 裝置針對其功能需求不同,所提供的服務也不盡相 同,在一個裝置上面也可以有多個不同的服務。

(16)

C. 控制點(Control Point):控制點可以在 UPnP 網路架構中尋找及控制有興趣的裝 置,主要負責的功能範疇為:

 取得裝置描述與取得相關服務列表。

 針對有興趣的服務取得該服務的描述。

 下達控制指令訊息以便控制該服務。

 針對有興趣的服務做狀態監控的訂閱動作,設備隨時回傳狀態改變訊息給控制 點,告知已訂閱的服務狀態變數更動為何。

2.1.2. 通用型隨插即用協定堆疊結構

在通用型隨插即用網路的架構中定義了裝置及控制點,而圖 2.2 為這兩種通用型 隨插即用網路元件溝通時會應用的一些通訊協定,為了能夠相容於目前的網路環境,

通用隨插即用採用廣泛應用的既有標準通訊協定,如 TCP,UDP,IP,HTTP 等,作 為通用型隨插即用協定中組件間溝通的依據及建立其堆疊結構。以下將介紹其他通用 型隨插即用網路架構中會使用到的通訊協定:

圖 2.2、 UPnP 協定堆疊結構圖

(17)

 HTTPU/HTTPMU [11]

    TCP/IP 藉著基本通訊協定堆疊,提供通用隨插即用裝置之間的網路連線。

而在我們日常生活中常使用的網頁瀏覽使用的 HTTP 通訊協定,也是通用隨插即 用的主要部份。在通用隨插即用架構中的每一個層面,都是以 HTTP 或其延伸使 用協定為主要架構。以 HTTPU 及 HTTPMU 為例,這兩者皆是 HTTP 的延伸使用 協定,其目的是透過 UDP/IP(而不是 TCP/IP) 傳遞訊息。這些通訊協定都是由 SSDP 所使用,這些通訊協定所用的基本訊息格式皆與 HTTP 的格式相關,在進行 多點傳輸時,以及當訊息傳輸過程中不需要為了加強可靠性而增加額外負荷時,都 須採用這個格式。

 SSDP ( Simple Service Discovery Protocol )[12]

「簡式服務探索通訊協定」(Simple Service Discovery Protocol,SSDP),主要是 定義如何在網路上探索網路服務。SSDP 是以 HTTPU 和 HTTPMU 為根據,讓控制點 在網路上尋找有興趣的資源,並且讓裝置主動宣告它們在網路上的可用性,且 SSDP 是以定義搜尋要求和存在宣告的方式為主,控制點和裝置都是採用 SSDP。通用型隨 插即用控制點在啟動時,會傳送一個 SSDP 搜尋要求(透過 HTTPMU),來探索網路 上可用的裝置和服務。控制點可以縮小搜尋範圍,只尋找某種類型的裝置(如音響)、

某種類型的服務(如提供播放音樂的服務),或者甚至是某一種特殊用途的裝置。在通 用型隨插即用網路中,裝置會接聽多點傳送連接埠,只要收到搜尋要求,該裝置便會 檢查其搜尋條件,判斷是否相符,如果找到相符的項目,便會傳送 SSDP 訊息(透過 HTTPU)回應給控制點。同樣的,裝置在連接網路之後,也會送出多個 SSDP,告知 其它節點該裝置支援哪些服務。存在宣告和單點傳送裝置回應訊息,其訊息內容都含 有一個指標,指向該裝置說明文件的位置,這份文件含有該裝置所支援的內容和服務 集合等相關資訊,除了探索功能之外,SSDP 也讓裝置和相關服務得以優雅的離開網 路(提供離線通知),並且加上快取逾時資訊,以便刪除老舊的資訊,進行裝置更新的 動作。

(18)

 SOAP ( Simple Object Access Protocol )[13]

簡式物件存取通訊協定」(Simple Object Access Protocol,SOAP)定義了「可延 伸標記語言 」(Extensible Markup Language,XML) 和 HTTP 執行遠端程序呼叫的 方式。通用隨插即用與遠端程序呼叫很類似,都是使用 SOAP 來傳遞控制訊息給裝 置,並且將結果或錯誤傳回控制點,每一個通用隨插即用控制要求都是一個 SOAP 訊 息,其中含有與一組參數共同啟動的動作。回應也是一個 SOAP 訊息,含有狀態、

傳回值、以及任何傳回參數

 GENA ( Generic Event Notification Architecture )[14]

「一般事件通知架構」(Generic Event Notification Architecture,GENA)主要利用 HTTP 收送通知,通用型隨插即用主要使用 GENA 格式來建立存在宣告,並且在服 務狀態變更時發送通知,以進行通用隨插即用事件(Eventing)的階段,其次在通用型 隨插即用網路中有意接收事件通知的控制點,會以傳送要求的方式訂閱事件來源,該 要求的內容包括有興趣的服務、傳送事件的目的地、以及事件通知的訂閱時間,訂閱 必須定期更新以便繼續接收通知,同時也可以利用 GENA 加以取消。

 XML ( Extensible Markup Language )[15]

根據 W3C 定義,「可延伸標記語言」(Extensible Markup Language,XML)是一種 網路結構化資料通用的格式。從另一方面看來,XML 幾乎可以把任何種類的結構化資 料置於文字檔中。XML 在通用隨插即用網路中主要應用於裝置和服務說明、控制訊息 和事件作業,是整個通用隨插即用通訊協定的一個重要的部份。

(19)

2.1.3. 通用隨插即用運作流程

上一小節已經大略的介紹過通用隨插即用各元件如何連結彼此與基本訊息溝通 後,接著會更深入的介紹通用隨插即用通訊協定主要的運作流程,見圖 2.3,主要分 成 6 個階段:

圖 2.3、 UPnP 運作流程圖

包括定址(Addressing)、探索(Discovery)、描述(Description)、控制(Control)、事件 (Eventing)、介面呈現(Presentation)。

首先階段零(定址- Addressing)是在支援通用隨插即用功能的設備加入一個區域 網路時,會自動的去尋找DHCP (Dynamic Host Configuration Protocol)伺服器是否存 在,如果有,會透過DHCP 伺服器分配到IP位址。如果區域網路內找不到DHCP伺服 器時會採用Auto-IP的方式達到定址的目的。Auto-IP 主要在定義裝置如何從一組保留 的私人位址(169.254/16)當中,以智慧方式選擇 IP 位址,以及如何在管理和不受管 理的網路之間切換,即持續監看網路上有無DHCP server 出現,如果有則定址部份就 會改用DHCP伺服器配發的IP位址。

(20)

接著階段一(探索-Discovery)是通知區域網路內其他設備該裝置以加入網路。這 個步驟是採用 UDP 方式透過多點傳送(Multicast)向區域網路內所有支援通用隨插即 用的裝置發送通知訊息,此階段可視裝置及控制點兩種設備加入而有不同的回應方 式,主要可以分成兩種模式,第一種是裝置加入網路時會發送通知訊息告知網路上的 其他裝置自身的存在(Device Advertisement),如圖 2.4 所示,圖中的 LCD 螢幕發送 裝置存在訊息給屬於同一個通用隨插即用網路中的其他裝置,告知其他裝置自身的存 在。

圖 2.4、探索-Device Advertisement

同時,在 Device Advertisement 期間的 Advertisement Protocol Stack 為表 2.1 所 示,SSDP 訊息利用 HTTPMU 格式發送至群播位址 239.255.255.250 及連接埠 1900,

告知其他的裝置自身裝置的存在。

表 2.1、Advertisement Protocol Stack UPnP Vendor   

UPnP Forum 

UPnP Device Architecture SSDP 

HTTPMU(Multicast)  UDP 

IP 

(21)

第二種是控制點加入網路時會去主動搜尋有哪些感興趣的裝置在該網路內 (Control Point Solicitation),並且被搜尋到的裝置會回傳一個訊息回報控制點,如圖 2.5 所示, 圖中的 PDA 裝置扮演通用隨插即用控制點的角色,主動發送搜尋要求的 訊息給屬於同一個通用隨插即用網路中的其他裝置,藉此得到其他裝置回覆的相關資 訊。

圖 2.5、探索- Control Point Solicitation

同時,在 Control Point Solicitation 期間的 Solicitation Protocol Stack 為表 2.2 所 示,SSDP 訊息會先利用 HTTPMU 格式發送搜尋訊息至群播位址 239.255.255.250 及 連接埠 1900,搜尋有興趣的通用型隨插即用裝置,接著這些被搜尋的裝置會以 HTTPU 的訊息格式回傳回應給控制點。

表 2.2、 Solicitation Protocol Stack UPnP Vendor   

UPnP Forum 

UPnP Device Architecture  SSDP 

HTTPU (Unicast)  HTTPMU(Multicast)  UDP 

IP 

(22)

階段二(描述-Description)是進入控制點取得裝置詳細描述資料的階段,在此階 段會根據前一階段(探索)中所取得的裝置描述資料位址,去該位址取回詳細的裝置描 述文件及後續的服務描述文件。這些文件皆以 XML 表示,文件內部包含的資訊有:

裝置名稱、製造商、序號、裝置提供的功能變數及相對應的一些動作…等,透過解析 這些 XML 檔案主要可以了解各裝置所提供的服務,以及如何操作此裝置的一些訊息,

如圖 2.6 所示,圖中的電腦藉由前一個步驟所取得的裝置位址,發送一個 Get Device Description 的訊息給 LCD 螢幕,要求 LCD 螢幕所屬的裝置描述及相關服務列表描述 相關資料。

圖 2.6、描述-Description

在 Description 期間的 Solicitation Protocol Stack 為表 2.3 所示,控制點會利用 HTTP-GET 的方式去取回有興趣的裝置所屬的描述資料。

表 2.3、Description Protocol Stack UPnP Vendor   

UPnP Forum 

UPnP Device Architecture 

HTTP  TCP  IP 

(23)

階段三(控制-Control)是透過解析裝置的 XML 檔案後,可以得知該裝置的操作 方式,讓控制點可以利用這些資訊去操作裝置,控制點產生的控制訊息也會透過 SOAP 傳送給被控制的裝置。當收到訊息後,裝置會將針對訊息做出預設的動作及回 傳更動後的狀態變數給控制點,如果失敗會傳回錯誤碼,如圖 2.7 所示,圖中的電腦 藉由前一步驟取的裝置的描述及相關屬性文件後,利用其裝置提供的屬性去下達特定 的 Action,LCD 螢幕收到 Action 會針對此要求做出相對應的動作,無論完成與否都 會回傳相關的訊息給發送 Action 請求的電腦。

圖 2.7、控制-Control

在 Control 期間的 Action Protocol Stack 為表 2.4 所示,控制點會藉由 HTTP 傳遞 SOAP 的方式針對通用隨插即用裝置進行不同的控制動作,例如打開電視機電源,或 是切換收視頻道等動作。

表 2.4、Action Protocol Stack UPnP Vendor   

UPnP Forum 

UPnP Device Architecture SOAP 

HTTP  TCP  IP 

(24)

階段四(事件-Event)中,控制點可以針對有興趣的裝置的狀態變數去做一個訂閱 的動作,每當裝置上的狀態變數發生更動,裝置就會發出一個 XML 格式的事件訊息,

利用 GENA 傳送給控制點,如圖 2.8 所示,圖中的 PDA 控制點會訂閱 LCD 螢幕,

希望得知 LCD 螢幕的相關訊息,接著圖中的電腦發送 Power On 的請求訊息給 LCD 螢幕,使 LCD 螢幕收到請求後開啟電源,並且回傳 Notify 的訊息給訂閱的 PDA 控制 點。

圖 2.8、控制-Event

在事件階段的 Eventing Protocol Stack 為表五所示,主要是將 GENA 訊息利用 HTTP 傳遞至訂閱者(Subscriber)或是發行者(Publisher),主要功能為發送訂閱、重新 訂閱、取消訂閱及事件異動訊息等。

(25)

表 2.5、Eventing Protocol Stack UPnP Vendor   

UPnP Forum 

UPnP Device Architecture GENA 

HTTP  TCP  IP 

最後階段五(介面呈現- Presentation),如果裝置有提供呈現資訊的網頁服務介 面,使用者可以利用該介面去監看裝置在線上運作的一些狀態,也可利用該介面去控 制裝置,如圖 2.9 所示,圖中的電腦會發送 Get Presentation 的訊息給 LCD 螢幕,接 著電腦可以利用 Web Browser 去瀏覽 LCD 螢幕提供的介面及其相關資訊。

圖 2.9、介面呈現- Presentation

在 Presentation 階段的 Presentation Protocol Stack 為表 2.6 所示,主要是將控制點 將整個通用隨插即用裝置的介面藉由 HTTP-GET 的方式取得 Presentation 介面後,以 網頁瀏覽的方式去讀取 UPnP 裝置的狀態。

(26)

表 2.6、Presentation Protocol Stack UPnP Vendor   

UPnP Device Architecture

HTTP  TCP  IP 

2.2. 通用型隨插即用影音(UPnP AV) 

 

 

隨著技術的發展,家中的多媒體裝置越來越多樣化,如何讓這些裝置構成一 個完整且便利性高的多媒體家庭網路,讓不同的裝置互相溝通並且達到最佳效用是一 個重要的議題。

通用型隨插即用論壇(Universal Plug and Play Forum)針對多媒體應用方面有做延 伸的規範,稱為通用型隨插即用影音(UPnP AV),主要的目的是規範消費性電子產品 為主軸,家庭影音與生活息息相關,而 UPnP AV 的制訂,成為家庭影音設備協同運 作的重要技術,使這些產品能夠統一透過通用隨插即用的方式加入多媒體數位家庭網 路中,在規範中定義了三種主要的組件:

 控制點(Control Point)

 媒體伺服器(Media Server)

 播放器(Media Renderer)。

(27)

通用隨插即用(UPnP)如圖 2.10 與通用隨插即用影音(UPnP AV)如圖 2.11,兩者 最大的差異在於傳統的通用隨插即用運作是全部由控制點(Control Point)來操控裝置 (Device),在 UPnP AV 中雖然大部分的運作還是透過控制點觸發下指令給裝置端,

但還是出現了裝置與裝置間不需透過控制點的運作程序(Out-of-Band Transfer),是專 門用來傳送影音的資料串流。

圖 2.10、通用隨插即用架構

圖 2.11、通用隨插即用 A/V 架構

(28)

2.3. 多媒體串流技術簡介 

 

隨著網路時代的開啟及寬頻網路的普及化,人們可以利用個人電腦、智慧型手 機、個人數位助理、數位機上盒等裝置輕易的存取網際網路上的資源,從簡易的文字 訊息至現在的影音多媒體檔案傳輸等,都確實的改變傳統使用者在電腦及網際網路的 使用習慣,在有線、無線或是在電信網路上傳輸多媒體檔案已經成為網路時代中眾多 的重要應用之一。

接著介紹目前較常被使用的串流技術有兩種[16][17],第一種串流技術是利用標 準的網頁伺服器將多媒體資料傳送至使用者的媒體播放器上播放,此種串流類型主要 是以 HTTP(Hyper Text Transfer Protocol)為主要的傳輸格式,所以將這種串流稱為 HTTP Streaming,優點為不需要額外的專屬伺服器去處理多媒體串流,只需要一台支 援標準網頁的伺服器即可,所以也稱為 Sever-less Streaming,而其缺點為 HTTP 通訊 協定本身設計在播放時不同頻寬的網路環境的適應性不良,所以需要準備許多不同播 放速率的資料以因應不同的網路環境,其次因為 HTTP 底層為 TCP(Transmission Control Protocol)通訊協定,所以在有資料在傳輸過程中遺失,就必須將先前的封包重 傳,因此容易造成延遲,而目前 UPnP AV 中主要的傳輸就是以 HTTP Streaming 為主,

所以會有延遲現象產生。

第 二 種 串 流 技 術 因 為 是 遵 循 RTP(Real Time Protocol) , 所 以 稱 之 為 RTP Streaming,它需要專屬的伺服器才能將多媒體串流資料播放至使用者端,主要是針對 即時串流播放的需求而設計,RTP Streaming 在串流播放時會以一定速率產生一條資 料流向使用者端的播放器播放,不會佔用使用者端的磁碟儲存空間,播放完後,資料 就會消失不見,不過在 RTP 的底層是以 UDP(User Datagram Protocol)通訊協定而不是 TCP,因為沒有 TCP 之 acknowledgement 與 retransmission,所以在資料傳輸方面

(29)

會比 TCP 快速且也較有效率,所以可以有效避免部分延遲(Delay)現象發生,除此之 外 RTP 可以搭配 RTCP(Real Time Control Protocol)與 RTSP(Real Time Streaming Protocol)一起使用,達到可自動偵測頻寬及控制播放動作,如:快轉、播放、暫停、

倒帶等,也就是可以達成與串流伺服器雙向溝通的功能,但是因為 UDP 本身協定的 設計,所以如果發生遺失的資料的情況,UDP 不會回報任何訊息告知串流伺服器並 要求重傳,RTP streaming 在無線網路環境或是網際網路傳輸過程中幾乎都會發生資 料遺失的狀況,也直接影響到串流的品質,另外也因為目前許多公司或是家庭網路幾 乎都會阻擋 UDP,在防火牆的阻隔下可能無法傳遞 UDP 封包達到 RTP Streaming 的 技術,需要額外的技術的輔助才能順利達成串流播放,造成處理的成本增加。

接著下面將 HTTP Streaming 及 RTP Streaming 這兩種主流的串流技術大略歸納,

提出其串流技術優缺點, 根據串流伺服器建置成本、串流品質、開發成本效益等提 出優缺點比較[18],如表 2.7 所示。

表 2.7、HTTP Streaming 與 RTP Streaming 比較

HTTP Streaming RTP Streaming

需要建置額外伺服器

不需要,標準 Web Server 即可

需要,RTP 串流伺服器建置 不易

串流播放品質 使用 TCP,品質佳

使用 UDP,資料容易遺失造 成播放品質下降

串流傳輸品質

使用 TCP,資料遺失會要求 重傳,易造成延遲現象發生

使用 UDP,傳輸速度較快

開發成本效益

標準 Web Server 可支援媒 體播放檔案即可

開發者需要對 RTP 及 RTSP 等協定有一定程度熟悉

(30)

HTTP Streaming RTP Streaming

使用者互動

不支援伺服器與播放器雙 向溝通

支援伺服器與播放器雙向 溝通,較容易控制播放動作  

2.4. 相關研究論文及軟體應用 

在多媒體家庭網路的相關研究領域及軟體應用中,多媒體播放的同步處理儼然已 是一個值得探討的主題,如何讓多媒體播放在家庭網路中播放的順暢及如何處理多媒 體內容在串流播放時產生的非同步現象都是很值得研究的議題,以目前的多媒體家庭 網路來說,以通用隨插即用的應用較為多數人所使用,所以使用既有的通用型隨插即 用通訊協定也可以達成我們希望達到同步功能的目的。

利用通用型隨插即用通訊協定作為同步的相關研究文獻[19]中,作者提出 Reservation-Based Concurrency Control 的概念將不同的通用型隨插即用通訊裝置 進行同步控制,其中結合精確時間同步協定,Precision Timing Protocol (IEEE 1588),簡稱 PTP,此協定原為讓各個不同的網路裝置能夠互相同步校正並且達到基 於相同時間基礎的概念,作者將其概念延伸至家庭網路當中,讓不同的通用型隨插即 用裝置能夠在同一個時間基準點上提供服務,主要架構是將通用型隨插即用通訊協定 中的 UPnP Control Point 設定為 PTP 協定中 Master 的角色、UPnP Device 為 PTP 協定中的 Slave,對時的依據為 PTP 協定中的 Best Master Clock 演算法,在 Master 與 Slave 利 用 UDP 交 換 訊 息 的 過 程 中 如 圖 2.12 所 示 。

(31)

圖 2.12、PTP 訊息交換流程

其中傳輸的延遲時間(Delay)及兩個裝置間的時間誤差(Offset),經由圖 2.12 之 流程,可以推得交換流程中兩個階段的時間關係,分別為 A:master-to-slave 及 B:

slave-to-master。

A = T2 – T1 = Delay + Offset B = T4 – T3 = Delay - Offset Delay = (A + B ) / 2 Offset = (A –B ) / 2

利用 A、B 之間的關係可以求出 Master 與 Slave 兩個裝置間的 Delay 及 Offset,

Master 即可利用求出的兩個時間參數以通用型隨插即用中的 Control 及 Eventing 方式,調整及告知目前並行且提供通用型隨插即用服務的多個 Slave 裝置,執行服務 時共同的基準點為何,如圖 2.13 所示,此參考文獻利用 PTP 的概念做為時間校正的 方法,又因 PTP 主要設計是兩個設備彼此間校正時間用,與本論文探討的週期性同步 偵測情境並不相同,但 PTP 的概念可以加以應用在 Video 與 Audio 一開始撥放前的時 間同步,且由於參考文獻[19]校正過程需要蒐集彼此的訊息發送時間及接收時間,再

(32)

加以計算傳輸延遲時間及裝置間彼此的誤差時間,其後再以通用型隨插即用協定通知 其他裝置進行校正的動作,整個流程較為複雜,若應用在本篇論文所探討的週期性同 步偵測上,會增加整個系統同步偵測的時間耗損及加重系統負擔,故本篇論文並無將 PTP 的概念應用至系統實做中。

圖 2.13、隨插即用裝置並行控制流程

其後在相關研究文獻[20]中,作者提出了一個符合通用隨插即用標準的多媒體內 容同步處理方法,在 UPnP AV 的模式下利用內容目錄服務(Content Directory Service) 及 多 個 通 用 隨 插 即 用 動 作 , 其 中 定 義 了 同 步 內 容 操 作 (Content Sync Service)、同步節點控管及同步節點群組控管等不同的通用隨插即用動作,主要是達 成多個不同的多媒體伺服器都可以同步彼此間的內容目錄為目的,可以降低使用者在 操作上的便利性,此研究提出了一個以通用型隨插即用通訊協定為主要控制內容同步 交換的技術及應用,如圖 2.14。

(33)

圖 2.14、通用型隨插即用技術內容同步交換流程

接著在相關軟體應用上已經有支援多個媒體播放器利用通用隨插即用技術,達到 內容同步處理的應用[21],這套軟體的作者提出兩種模式在多個媒體播放器同步播放 處理的情境,第一種是將代理伺服器內建在控制端電腦上,如圖 2.15,所有媒體播 放器的播放處理,都會先透過代理伺服器扮演中介者的角色,接收由媒體伺服器端發 送出的多媒體內容,再由代理伺服器統一向數個媒體播放器統一播放,第二種模式是 代理伺服器內建在媒體伺服器端,如圖 2.16,由控制端電腦要求媒體伺服器端播放 後,再由內建於媒體伺服器端中的代理伺服器統一播放串流內容至多個媒體播放器,

此軟體是以播放同樣類型的檔案達到類似廣播的功能,軟體作者是以播放音樂專輯為 例,在數個媒體播放器播放同首曲目,然而作者也提出了不同裝置間會產生些許的時 間漂移現象,作者提出了一個在歌曲與歌曲間空白無聲的時間重新同步時間的方式,

同步且協調每個播放裝置間的播放差異。

(34)

圖 2.15、Cidero-Default Configuration

  圖 2.16、Cidero-Preferred Configuration

根據前述的相關研究後,我們可以驗證在多媒體數位家庭網路中的多個裝置間如 果要做出播放同步處理是一個非常值得研究的題目,並且以目前多媒體家庭網路發展 的趨勢來看,多個視訊或是音訊播放裝置的組合方式漸漸的變成一種應用情境,在此 種情境下要怎麼在這些裝置間達到同步處理,要利用何種通訊協定可以達到我們要求 的功能目標,都是本篇論文接下來會提出的重點。

(35)

 

第三章 研究情境與研究方法

 

本章將會繼續介紹本篇論文研究的主題,配合研究模擬情境及本論文的研究方法 針對多媒體數位家庭網路中聲音及影像同步播放校正的方法做深入的探討及研究。

在我們生活的家庭空間裡有著越來越多的多媒體資訊家電加入如圖 3.1 所示,在 客廳當中可能會有電視及家庭劇院音響,可以利用通用型隨插即用的技術去存取家庭 內部的多媒體伺服器,享受高畫質解析度的影片及 5.1 聲道的環繞音效,但是如果場 景移到臥室,就有可能會希望在不打擾人休息的情況下,有利用數位相框及無線耳機 透過通用隨插即用去欣賞影片及聆聽配樂,同時在小朋友的遊戲空間裡,可能有著現 在非常流行的移動式遊戲機(Sony Play Station Portable,PSP)或可攜式多媒體播 放器(Portable Media Player,PMP )等,搭配固定式的音響,都可以透過通用隨插 即用的環境去存取同一來源的多媒體影像跟聲音或是不同來源的影像及聲音訊號,也 或許是多媒體來源存在於外部的網路上,在這種多重的影像及聲音來源的不同組合及 不同的影像聲音傳輸模式之下,一般使用者皆可能有快進或是倒轉影片的行為模式發 生,在本篇論文模擬研究情境當中就會發生影像及聲音不同步的現象,會有聲音比影 像先播放或是影像比聲音先播放的情形發生,當延遲過久及不同步差異過大的情況產 生時,人類的感官可以很容易感覺出來影像及聲音在播放上產生不協調的現象。所以 本篇論文為了解決播放速率不同步的問題,提出一個應用數位家庭中既有的通用型隨 插即用協定當作控制訊號,及加入配合的同步對應解決方法。

(36)

圖 3.1、數位家庭網路情境示意圖

為了解決研究情境中的問題,我們延伸傳統 UPnP AV 中定義的 3-Box 實做架 構,如圖 3.2, Control Point 會先利用內容目錄服務(Content Directory Service ,CDS) 訊息去搜尋此架構中的播放器,及瀏覽多媒體伺服器(Media Server)上的多媒體檔案 目錄,選取有興趣的項目播放,並將播放的相關資訊傳送至 Media Renderer,接著 Media Renderer 會向多媒體伺服器請求,多媒體內容會以 Out-of-Band 的方式傳輸及 播放,我們以此簡易實做架構為基礎,加入主從式概念,將影像及聲音裝置分類定義 為 Master Device 及 Slave Device,以便後續針對影像及聲音裝置有不同的相對應處理 規則。

(37)

圖 3.2、UPnP AV 3-Box 架構

對於此情境中的操作,如圖 3.3 所示。在我們的研究情境中,影像播放裝置也就 是 Control Pointer with Video Decoder 扮演整個架構中 Master Device 的角色,主要的 功能是去訂閱多媒體伺服器上的多媒體影像,以及告知聲音播放裝置也就是 Slave Device (Media Renderer with Audio Decoder )指定配合的音訊檔案,接著 Master Device 及 Slave Device 同時開始播放關連的多媒體影像及聲音檔案,此同時我們也加入了同 步校正的偵測方法,利用 Master Device 主動且週期性的偵測 Slave Device 播放音訊 的狀態資訊,經由比對狀態資訊後,可以解決及同步校正 Master/Slave Devices 間播 放時產生的不同步現象。

(38)

圖 3.3、進階 UPnP AV 3-Box 架構

同步校正主要流程如圖 3.4 所示:

Step1:Master Device 會訂閱 Slave Device 的播放狀態,若不成功會重新訂閱。

Step2:使用者會利用 Master Device 對多媒體伺服器上有興趣的影片檔案作瀏 覽及搜尋的動作,接著選取想要播放的影像檔案。

Step3:Master Device 會利用通用型隨插即用協定主動告知 Slave Device,使 用者已經選定了特定的檔案,要求 Slave Device 也播放相對應的音訊 檔案。

Step4:開始播放,在播放的同時,偵測同步流程也隨之開始動作,Slave Device 會以固定頻率去發送通用型隨插即用事件訊息告知 Master Device 播放 的進度資訊。

(39)

Step5:待 Master Device 收到相關資訊後,Master Device 會比對兩者的相對 播放進度是否有產生不同步的情況。

Step6:若是播放進度發生不同步的現象產生時,則進行同步處理,若無不同步 現象產生,則檢查是否已經播放完畢或是繼續播放及繼續偵測是否產生 不同步現象。

我們可由圖 3.5 的狀態機瞭解整個同步處理的機制,處理過程中會以 Master Device 為主要比較依據,如果影像播放進度較快,則聲音播放進度會停止並且跳躍 至欲同步的同步點後,重新開始播放,若是影像播放進度較慢,聲音播放較快,則聲 音會跳躍至與影像相同播放進度位置,始開始播放。

(40)

Start

Step1:

Master Device Subscribe to Slave Device

Check Subscribe State

Step2:

Browse and Search Content on Media Server

Step3:

Send Audio File Path

Step4:

Play and Slave Send CurrentPlayTime to Master

Synchronization Step6:

Synchronization check Step5:

Comparsion With both CurrentPlayTime

Finish Check

Finish Success

No Need Sync

Finish Failed

Continuous Play

Sync

圖 3.4、通用型隨插即用影音同步控制校正流程圖

(41)

圖 3.5、通用型隨插即用影音同步控制校正狀態機

在整個方法的流程中皆是以數位家庭中既有的通用型隨插即用協定作為主要的 溝通媒介,藉此當作 Master Device、Slave Device 以及多媒體伺服器的主要的訊息 資訊交換及控制訊號。

在下一章節中我們將針對整個情境模擬做一個實際的簡易應用,搭配整合現有的 開放原始碼多媒體播放軟體 VideoLAN –VLC Media Player,加入我們的方法實做出整 個情境的應用。

(42)

第四章 系統實做與結果分析

 

  本章延續第三章,將整個多媒體數位家庭中的播放情境以桌上型電腦模擬並且加 入我們實作的同步方法,接著會利用 VLC Media Player 模擬因為使用者的快進及倒 轉這兩種行為,造成的影音播放不同步情況發生,以便驗證同步模組的精準度,接著 下面將介紹整個系統的架構、運作流程及驗證模組精準度的實驗結果及分析。

 

4.1. 系統架構

在整個實驗環境建制的過程中,我們利用 Video LAN 的 VLC Media Player 作為 整個系統 Video 與 Audio 的媒體解碼器,VLC Media Player 本身設計具有良好的開 放式架構,可供開發者自行修改外部模組及透過其應用程式介面可取得撥放器的相關 資訊,在此我們利用 Linux SDK for UPnP Devices[22] [23]開發多媒體同步的通用 隨插即用模組,再與 VLC Media Player 整合,實做進階 UPnP AV 3-Box Pull 架構及 進行整個系統的通用隨插即用的影音播放同步實驗。在 VLC Media Player 中,可經 由播放畫面顯示或經由應用程式介面取得當前媒體播放時間(Current Play Time),

在影音播放同步實驗系統的第二階段中,將比較 Master Device(Video)與 Slave Device(Audio)兩者間的當前媒體播放時間,做為同步校正的依據。

(43)

在影音播放同步實驗系統開始的第一階段,如圖 4.1 所示,主要包括以下的五個 流程操作:

1. Master Device 及 Slave Device 啟動後會透過通用隨插即用通訊協定發送 搜尋訊息。

2. 從多媒體伺服器取回播放清單。

3. 使用者可以根據播放清單選擇有興趣的播放項目,此時 Master Device 會以 通用隨插即用訊息告知 Slave Device 應該播放的曲目相關資訊

4. Master Device 及 Slave Device 內的通用隨插即用 模組會將播放曲目訊息 告知相互對應的 Video Decoder 及 Audio Decoder。

5. 接著 Master Device 及 Slave Device 開始向媒體伺服器(Media Server)進 行 Pull-mode 串流。

圖 4.1、影音播放同步系統第一階段

(44)

經過這 5 個步驟後完成整個系統實做的第一階段流程,接著開始第二階段的同步 處理流程,如圖 4.2 所示,主要包含以下五個步驟的操作:

1. 接續第一階段的串流播放開始後,Master Device 接收位於媒體伺服器 (Media Server)上的視訊檔案交由 Master Device 內的視訊解碼器(Video Decoder)處理,Slave Device 與 Master Device 不同的地方是處理音訊檔 案的部份。

2. 接著播放期間 Master Device 與 Slave Device 會從本身的 VLC Player 中,

得到串流已經處理的目前播放處理時間點相關資訊。

3. Slave Device 會透過通用隨插即用提示(Notify)訊息週期性且主動的告知 Master Device 目前 Slave Device 播放處理時間點相關訊息,且交由 Master Device 去判斷是否需要同步處理。

4. Master Device 如果判斷需要同步處理,會利用通用隨插即用通訊協定發出 動作訊息告知 Slave Device,根據兩者比對的結果會有不同的對應處理方 式。

5. Slave Device 收到訊息以後會針對相對的訊息做出回應動作處理,如同步 聲音裝置。

6. Slave Device 回報 Master Device,動作完成。

(45)

圖 4.2、影音播放同步系統第二階段

其中在同步系統第二階段的第三步驟中,將比較 Master Device 之 VLC Media Player 當前媒體播放時間值與 Slave Device 週期性發送的 VLC Media Player 之當 前媒體播放時間值,再將兩者比較後的時間差與參考文獻[24]中定義人類能分辨出之 影音誤差基準值參考值 80ms 做比較,若兩個裝置的時間差大於 80ms,Master Device 隨即會發送同步處理動作,如同步系統第二階段的第四及第五步驟,若小於 80ms 則 同步系統第二階段只會執行第一至第四之偵測部分而不執行第五至第六之同步處理 動作。 

(46)

4.2. 實驗方法

為了降低實驗中不必要的干擾播放因素,如 CPU 時脈差異等,我們的實驗環境採 用兩台相同等級硬體及作業系統的個人電腦代表 Master Device 及 Slave Device,

在 Media Server 的部份我們採用 ZyXEL 的 NSA-220 網路儲存設備作為 UPnP AV 播放 的多媒體檔案來源,除此之外,我們為了模擬情境中會有 Video 與 Audio 分別播放及 來自不同的來源的情況,所以我們在 NAS 上存放了預先分離過的影像及聲音檔案,以 便模擬影音不同串流播放至不同裝置的模式,接著在控制變因的部份採用 VLC Media Player 提供的快進模式及倒轉模式實際驗證同步系統的精確度,實驗環境拓墣如圖 4.3 所示,整個系統會以 Master Device 的播放進度為主,週期性的偵測 Slave Device 的播放進度且動態的調整播放進度,達到同步的目的。

圖 4.3、實驗環境拓樸圖

(47)

4.3. 實驗結果及說明

在同步測試中,將同步時判定誤差的臨界值定為 80ms,根據文獻[24]可得知此 時間參數為一般人可以非常明顯的判斷出影像及聲音不同步的誤差時間估計值,在誤 差產生的部分我們使用 VLC Media Player 提供的快捷鍵模式控制快進及倒轉這兩種 行為,快進部份實驗參數為固定時間間隔、倒轉部分使用動態隨機時間間隔,另外也 加入開啟同步功能但無模擬使用者行為模式(forward/backward)的播放行為作為實 驗對照組。實驗當中的影像與聲音的誤差值(Offset)定義是以 Master Device 收到 第一筆 Slave Device,利用 UPnP 協定 Eventing 的第一筆資料為基準點開始,記算 兩者間的相對誤差值。

我們可以經由實驗結果得知,模擬播放過程中,影像及聲音相對誤差時間大部分 皆維持在 0~160ms 的區間,如圖 4.4 所示,可以讓始用者不會有難以忍受的撥放時間 誤差, 雖然在播放起始的時候需要第一次同步校正 Master Device 與 Slave Device 的誤差,除此之外我們還可以觀察到在加入同步模組後,整個撥放過程中還是有許多 的不同步現象產生,但我們的同步模組將不同步現象快速的校正,使得撥放不同步現 象之差異不會越漸擴大。

  圖 4.4、無模擬使用者行為模式的播放行為(無 forward/backward)

(48)

從圖 4.5 可以得知,使用者快進影片時,同步系統偵測到 8 個階段的不同步,分 別為 5 秒、10 秒、30 秒、60 秒、5 分鐘、10 分鐘、15 分鐘及 30 分鐘等參數,當 Master Device 偵測到 Slave Device 有不同步情況發生,立刻就會計算誤差值並且通知 Slave Device 需要同步的位置,由圖 4.6~圖 4.13 可以看到同步所需要花費的時間大約是 75~250ms 之間,即可完成影像及聲音同步的動作;我們可以從圖 4.14 看出模擬快進 的機率分佈圖,大部分的時間誤差值幾乎都不超過 80ms,只有約 0.03%的誤差值是大 於 160ms,有超過 99.23%的時間誤差值是低於 50ms,遠低於人類能分辨出誤差的基 準值參考值 80ms。

 

圖 4.5、快進模式

(49)

  圖 4.6、介於 23829~23859ms 間快進 5 秒同步花費速度放大圖

  圖 4.7、介於 47630~47678ms 間快進 10 秒同步花費速度放大圖

  圖 4.8、介於 71457~71517ms 間快進 30 秒同步花費速度放大圖

(50)

  圖 4.9、介於 98000~98487ms 間快進 1 分鐘同步花費速度放大圖

  圖 4.10、介於 98000~98487ms 間快進 5 分鐘同步花費速度放大圖

  圖 4.11、介於 98000~98487ms 間快進 10 分鐘同步花費速度放大圖

(51)

  圖 4.12、介於 98000~98487ms 間快進 15 分鐘同步花費速度放大圖

  圖 4.13、介於 98000~98487ms 間快進 30 分鐘同步花費速度放大圖

  圖 4.14、八種快進機率分佈

(52)

倒轉部分實驗,採用隨機動態倒轉方式,模擬使用者在觀賞影片時,可能會想動 態的回顧先前的影片劇情,進而隨機點選倒轉影片,故本實驗旨在驗證使用者在此情 境中隨意的倒轉會讓影音產生不同步現象,而本論文實做的同步模組可以發揮其功 效,實驗結果如圖 4.15 所示,在這 8 次模擬,其相對應的處理速度大約為 75ms,就 可以達到同步並且恢復至常態範圍內,如圖 4.16~圖 4.23 所示,從圖 4.24 可知大 約有 1.62%的誤差值是大於 160ms,有超過 97.68%的時間誤差值是低於 75ms,低於人 類能分辨出誤差的基準值參考值 80ms。

   

  圖 4.15、模擬使用者隨機倒轉模式

   

  在圖 4.16~4.23 中可以觀察到每一次模擬使用者倒轉,都有可能會出現一次以上 的倒轉產生之不同步現象及出現一次快轉的情形發生,這是使用者以滑鼠點擊播放器 介面時所產生之影響,在此現象發生時,同步模組會快速的偵測並且重新校正 Slave Device 之 VLC Current Play Time,與 Master Device 之 VLC Current Play Time 同步,並且接續播放.

     

(53)

 

 

圖 4.16、第一次模擬使用者隨機倒轉模式同步花費速度放大圖

 

圖 4.17、第二次模擬使用者隨機倒轉模式同步花費速度放大圖

 

圖 4.18、第三次模擬使用者隨機倒轉模式同步花費速度放大圖

(54)

 

圖 4.19、第四次模擬使用者隨機倒轉模式同步花費速度放大圖

  圖 4.20、第五次模擬使用者隨機倒轉模式同步花費速度放大圖

  圖 4.21、第六次模擬使用者隨機倒轉模式同步花費速度放大圖

(55)

  圖 4.22、第七次模擬使用者隨機倒轉模式同步花費速度放大圖

  圖 4.23、第八次模擬使用者隨機倒轉模式同步花費速度放大圖

  圖 4.24、八次倒轉模式機率分佈

(56)

在本系統進行同步處理過程中,會有些許數值因為多媒體播放器提供的介面及處 理速度無法百分之百符合實驗參數要求,由系統模擬時觀察到,取值通訊介面因為要 求存取速度太快,導致數值存取會有些許震盪情況發生,以及牽涉到媒體撥放器存取 網路串流的實作方式,會造成如實驗數據圖 4.6 至圖 4.13 所示 Master 之 Current Play Time 及 Slave 之 Current Play Time 皆有 1~2 次的播放時間震盪現象發生,但 此現象並不影響本論文欲實作之同步校正的理念。

                                                           

(57)

 

第五章 結論

 

隨著多媒體數位家庭網路的發展,未來一定有越來越多的多媒體播放需求及相關 軟硬體會以不同影像及聲音設備來搭配播放,而這些影像及聲音裝置可能因為使用者 的行為模式快進及倒轉,進而導致影像及聲音裝置在播放期間產生不同步的現象,讓 整個播放的過程不順暢,這些都是影響播放同步的因素之一。

在多媒體數位家庭網路的環境中,以通用隨插即用為主要技術的同步處理經過實 驗後,證明具有可以讓聲音裝置及影像裝置的同步播放情況做出一定程度的改善,雖 然通用隨插即用不是一個強調高度即時性的通訊協定,但是應用在多媒體數位家庭網 路中處理些微的播放不同步情況卻是綽綽有餘,在我們的實作中,同步模組,可以在 很小的時間範圍內做到影像及聲音同步且讓時間誤差值回復到常態的範圍內,使用本 論文提出的同步模組也可以維持原有的多媒體家庭網路播放架構,不需要額外的硬體 建置成本,也可以讓被使用者行為影響的影音播放狀態重新達到同步的位置,且平順 的繼續撥放。

未來會有更多的影音設備網路化,所以影音同步問題必然是一個迫切解決的問 題,如何做到更有效率的偵測同步及更平順的播放都是一些很值得去研究及探討的研 究方向。

     

(58)

 

參考文獻

 

[1]. UPnP Forum, UPnP Device Architecture 1.0.1, July 20, 2006.

[2]. Microsoft, Plug and Play - Architecture and Driver Support, Available : 

http://www.microsoft.com/whdc/system/pnppwr/pnp/default.mspx [Accessed:

Oct.2008]

[3]. Chun-Yi Tsai and Tzao-Lin Lee, “Real-time Video Recording on Blue-ray Discs for UPnP Streaming,” in Proceedings of the Third Communications and Networking Conference, China, Aug 2008.

[4]. J. Sung, D. Kim, H. Song, J. Kim, S. Y. Lim, and J. S. Choi, “UPnP Based Intelligent Multimedia Service Architecture for Digital Home Network,” in Proceedings of the Fourth IEEE SEUS- WCCIA, Seoul, April 2006, pages 157-162.

[5]. Yeon-Joo Oh, Hoon-Ki Lee, Jung-Tae Kim, Eui-Hyun Paik, and Kwang-Roh Park,

“Design of an Extended Architecture for Sharing DLNA Compliant Home Media from Outside the Home,” IEEE Trans. on Consumer Electronics,Vol.53, No.2, pp.542-547, May 2007.

[6]. Taein Hwang, Hojin Park, and Jinwook Chung, “Personal Mobile A/V Control Point for Home-to-Home Media Streaming,”IEEE Trans. on Consumer Electronics, Vol.54, No1, pp.87-92, Feb 2008.

[7]. The VideoLAN Project Team, “VideoLAN - VLC Media Player,” Available : http://www.videolan.org/ [Accessed: Jan. 2008]

[8]. Digital Living Network Alliance, DLNA Networked Device Interoperability Guidelines, Oct .2006

[9]. OSGi Alliance Open Service Gateway Initiative, Available : http://www.osgi.org/

[Accessed: Feb.2008 ]

(59)

[10]. UPnP Forum, UPnP AV Architecture:1,1.1, September 30 ,2008.

[11]. Yaron Y. Goland, “Multicast and Unicast UDP HTTP Messages,”

draft-goland-http-udp-01, IETF, Expired April 2000.

[12]. Yaron Y. Goland,  Ting Cai,  Paul Leach and Ye Gu, “Simple Service Discovery Protocol/1.0,” draft-cai-ssdp-v1-03, IETF, Expired April 2000.

[13]. Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, Anish Karmarkar, and Yves Lafon, “SOAP Version 1.2 Specification,” Available :  http://www.w3.org/TR/soap12-part1/ [Accessed: Oct.

2008]

[14]. J. Cohen and S. Aggarwal, “General Event Notification Architecture Base,”draft-cohen-gena-p-base-01, IETF, Expired July 9, 1998.

[15]. XML Working Groups,  “Extensible Markup Language ,XML,” Available :  http://www.w3.org/XML/ [Accessed: Oct.2008]

[16]. R. Fielding,  J. Gettys,  J. Mogul,  H. Frystyk, and Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,”RFC 2068, IETF, January 1997.

[17]. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 1889, IETF, January 1996.

[18]. 經 濟 部 工 業 局 , “2003 台 灣 數 位 內 容 產 業 年 鑑 ,” Available :  http://www.digitalcontent.org.tw/files/top_3/1/3.1.pdf [Accessed: Feb.2008]

[19]. Jeong-Seok Kang, Sang-Woo Maeng, and Hong-Seong Park, “RBCC : Reservation-Based Concurrency Control for Distributed UPnP Devices,” in Proceedings of International Conference on Control, Automation and Systems ,

COEX, Seoul, Korea, Oct. 14-17, 2008.

(60)

[20]. Wonseok Kwon , “Introduction to Universal Plug and Play Content Synchronization Service,” in Proceedings of Symposium of the 12th IEEE International Annual on Consumer Electronics, Algarve, Portugal , April 14-16, 2008.

[21]. The Cidero Project Team, “Cidero-Synchronization of Multiple UPnP Media Renderers,” Available: http://www.cidero.com/multiRendererSync.html [Accessed:

Jul.2008]

[22]. The Linux SDK for UPnP Devices Project, “Linux SDK for UPnP Devices (libupnp),” Available : http://upnp.sourceforge.net/ [Accessed: Jul.2007]

[23]. Michael Jeronimo, Jack Weast, UPnP Design by Example: A Software Developer's Guide to Universal Plug and Play, Intel Press, May 1, 2003.

[24]. Ralf Steinmetz, Senior Member, “IEEE, Human Perception of Jitter and Media Synchronization,” IEEE Journal on Selected Areas in Communications, Vol. 14, No. 1, pp61-72, Jan 1996.

參考文獻

相關文件

運用想像力、形式/技巧表現一個 的夢境 回憶 的一刻,以形式/技巧,表達 的情 景/情緒。. 從評賞

• 也就是 ”我的dp是n^3”這句話本身不夠表示你的dp演算法,必須 要說“我的dp是個狀態n^2,轉移n”才夠精確. •

„ „ 利用電腦來安排與整合多種媒體,可產生 利用電腦來 更多樣化的作品。如某一段背景配樂在影 片中的哪個時間點開始播放、新聞播報中 子母畫面的相對位置、文字字幕出現在畫

如圖,空間中所有平行的直線,投影在 image 上面,必會相交於一點(圖中的 v 點),此點即為 Vanishing Point。由同一個平面上的兩組平行線會得到兩個

2.「情境」創設對非華語學生學中文的影響 3.應用「調適架構」配合情境訂立教學目標 二、 第二語言教學流派..

其硬體架構如圖 9.3 所示。本實驗最主要的目的是要將之前學長所做的 GPS/INS 整合 部分中的加速儀用

下圖為本研究的主架構設計。透過 Master MCU 控制裝置的按鍵選擇,選擇所需 要控制的 Slave ID 編號及欲控制的命令,透過 Master MCU 將命令送給

然而此電路最大的問題在於中間 Buffer 的困難度,因此我們使用了如圖 3.8 的架 構[5],圖 3.8 中我們將電流源設在內側,而 UP、DOWN 兩個開關設在外側,和圖 3.7