• 沒有找到結果。

Web 2.0 線上多功能媒體展示系統

N/A
N/A
Protected

Academic year: 2021

Share "Web 2.0 線上多功能媒體展示系統"

Copied!
72
0
0

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

全文

(1)

國 立 交 通 大 學

多媒體工程研究所

碩 士 論 文

Web 2.0 線上多功能媒體展示系統

Web 2.0-based multi-function media display system

研 究 生:黃威人

指導教授:傅心家 教授

(2)

Web 2.0 線上多功能媒體展示系統

Web 2.0-based multi-function media display system

研 究 生:黃威人 Student: Wei-Ren Huang 指導教授:傅心家 Advisor: Prof. Hsin-Chia Fu

國 立 交 通 大 學

多 媒 體 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of MultimediaEngineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

July 2009

Hsinchu, Taiwan, Republic of China

(3)

Web 2.0 線上多功能媒體展示系統

研究生: 黃威人 指導教授: 傅心家 教授 國立交通大學多媒體工程研究所

摘要

本篇論文提出多功能資訊展示窗,是一個結合線上多媒體影片與影片相關資 訊展示的系統,基於 Web 2.0 機制下提供使用者分享平台,每個人都可以參與 資訊提供、影片上傳,而本系統整合這些使用者提供的資訊,在頁面上以互動方 式呈現。 目前少有提供教學影片播放分享的平台,能夠展示更多元的影片,因此本系 統規劃有教學影片播放功能,包含教學影片所需要的投影片展示與瀏覽功能,方 便使用者在網路上分享精心製作的影片。 本論文進一步研究如何提供更大的負載量,將系統內部功能切成許多伺服 器,組成分散式的網站架構,經負載測試後系統由原本 100 多人的負載量,提升 至可以容納每秒 500 位使用者在線上同時發出 request ,只要在系統能夠承載 的範圍內,98%的使用者對系統回應速度感到非常順暢,僅 1 秒鐘就可以完成網 頁傳輸。

(4)

Web 2.0-based multi-function media display system

Student: Wei-Ren Huang Advisor: Prof. Hsin-Chia Fu

Institute of Multimedia Engineering National Chiao Tung University

Abstract

This paper presents a multi-function information display system has a display window which combines on-line multimedia with related information. This system is a Web 2.0-based platform to provide users sharing their information, videos. This system will collect such information and display on webpage in an interactive manner. At present, there is little provision of teaching video-sharing platform. This system also provides “teaching video” play-related features, including a slide show and browsing window. Users can upload videos to the website and share experience. Finally, this paper study how to provide a greater load. Many of the system internal functions into the independent server and create a distributed system architecture. According to the load testing, the system allows from the original 100 users to 500 users on-line at the same time. Among these 500 users, 98% feels that the responding and connecting speed of the system is satisfactory. Within 1 second, the webpage transfers can be completed.

(5)

誌謝

感謝傅老師的指導和照顧,承蒙老師給予學生的鼓勵與支持並幫助我找到研 究方向,使得本論文能順利完成,在此謹向老師致上最誠摯之謝忱與敬意。同時, 感謝實驗室博士後研究以及博士班學長,永煜、岳宏、柏伸、政龍、士賢,同學 坤隆,還有學弟佑楷平常在生活上及學業上的建議與指教,也讓我的研究生生涯 多采多姿充滿歡樂。真的很感謝博士班學長們,總是在我不知所措的時候指引我 方向,讓我可以解決論文上的難題。感謝我最心愛的未來老婆婉婷,在生活中不 斷給我鼓勵與支持,在我退縮的時候幫我打氣,成為我得以進入交大就讀的推 手,也感謝婷爸、婷媽、婷哥、婷姊對我的關心與幫忙,讓我倍感窩心。最後, 感謝從小一直支持我的爸爸、媽媽、弟弟一直在背後支持我,給我無憂無慮的生 活,讓我可以專注在學業上,才得以順利完成學業。

(6)

目錄

摘要...i Abstract...ii 誌謝...iii 目錄...iv 表目錄...vi 圖目錄...vii 第 1 章 前言 ...1 1.1 研究動機...1 1.2 研究目標...3 1.3 研究方向...3 1.4 章節介紹...4 第 2 章 相關研究 ...5 2.1 何謂 Web 2.0 ...5 2.1.1 Web 2.0 的起緣...6 2.1.2 Web 2.0 特性與特色...8 2.1.3 Web 2.0 網站...9 2.1.4 社群參與及創造...13 2.2 Web 2.0 相關技術...13 2.2.1 AJAX...13 2.2.2 JavaScript...16 2.2.3 DOM...17 2.2.4 XML...18 2.3 小結...18 第 3 章 系統架構與設計 ...20 3.1 系統設計理念...20 3.2 系統架構與開發環境...20 3.2.1 影片轉檔伺服器...21 3.2.2 多媒體串流伺服器...23 3.2.4 網頁負載均衡伺服器...25 3.2.5 資料庫叢集...26 3.2.6 多語系支援...27 3.3 頁面瀏覽流程...30 3.4.1 資料表關係圖...32 3.4.2 系統資料庫設計...32 第 4 章 系統功能與操作流程 ...38 4.1 多功能資訊展示...38

(7)

4.2 影音播放器...38 4.3 相關資訊展示窗...39 4.3.1 動態地圖...40 4.3.2 關鍵畫面瀏覽...41 4.3.3 影片描述...43 4.3.4 在地資訊...44 4.3.5 使用者評語...44 4.3.6 教學畫面...45 4.4 系統功能...46 4.4.1 影片上傳與定位功能...46 4.4.2 在地資訊搜尋比對...47 4.4.3 景點定位介面與流程...48 4.4.4 影片播放流暢度改善...51 4.5 多媒體檔案標籤機制...52 4.5.1 標籤機制...52 4.5.2 影片分類...52 第 5 章 系統測試與評估 ...55 5.1 連結測試...55 5.2 負載測試...56 5.3 客戶端相容性測試...57 5.4 總結...57 第 6 章 結論與未來展望 ...58 6.1 結論...58 6.2 未來展望...59 6.3 移動式影音展示裝置...59 6.3.1 移動式裝置優點...60 6.3.2 面臨之挑戰...60 參考文獻...62

(8)

表目錄

表 2-1 WEB 1.0 與 WEB 2.0 之比較 ...6 表 2-2 WEB 2.0 的 4C 特性 ...9 表 3-1 會員資訊表 ...33 表 3-2 影片資訊表 ...34 表 3-3 景點資訊表 ...35 表 3-4 綜合評論表 ...36 表 3-5 評分記錄表 ...37 表 3-6 相關資訊表 ...37 表 4-1 相關資訊展示窗模式比較表 ...39 表 5-1 連結測試結果 ...55 表 5-2 相容性測試結果 ...57

(9)

圖目錄

圖 1-1 交通大學開放式課程頁面 ...2 圖 2-1 GOOGLE MAPS 台灣首頁 ...10 圖 2-2 YOUTUBE 台灣首頁 ...12 圖 2-3 傳統網頁技術與 AJAX 技術資料傳輸方式 ...15 圖 2-4 同步與非同步傳輸 ...16 圖 2-5 DOM 結構 ...17 圖 3-1 系統架構圖 ...21 圖 3-2 影片轉檔伺服器運作流程 ...23 圖 3-3 影片播放器切換流程 ...24 圖 3-4 系統 HAPROXY 分流架構 ...26 圖 3-5 系統資料庫叢集架構 ...27 圖 3-6 系統中文版首頁 ...28 圖 3-7 系統英文版首頁 ...29 圖 3-8 頁面瀏覽流程 ...30 圖 3-9 系統首頁快速連結區 ...30 圖 3-10 影片列表頁面 ...31 圖 3-11 資料表關係圖 ...32 圖 4-1 影音播放器 ...39 圖 4-2 相關資訊展示窗工具列 ...40 圖 4-3 動態地圖 ...41 圖 4-4 「旅遊導覽系統」中的關鍵畫面展現 ...42 圖 4-5 關鍵畫面瀏覽 ...43 圖 4-6 影片描述 ...43 圖 4-7 在地資訊 ...44 圖 4-8 使用者評語 ...45 圖 4-9 教學畫面 ...46 圖 4-10 影片上傳頁面 ...47 圖 4-11 新增景點流程 ...49 圖 4-12 新增景點功能 ...50 圖 4-13 景點編輯窗與地圖定位 ...50 圖 4-14 景點新增資料不完全警告 ...51 圖 4-15 影片播放器顯示新增景點 ...51 圖 4-16 影片分類畫面-風土文物 ...53 圖 4-17 影片分類畫面-交大尋根築夢之旅 ...54 圖 5-1 回應速度曲線 ...56

(10)

第 1章 前言

1.1 研究動機

近幾年隨著寬頻上網的普及與強調分享互動的 Web 2.0 興起,影音分享網站 如雨後春筍般出現,如 YouTube 、 Vlog 、 土豆網等,因為影片上傳分享方便, 每日上線收看網路影片已是不少網路使用者每天必做的事,也因此形成一股外出 旅遊的熱潮,但若在觀看影片後想到影片中介紹的景點去遊玩,卻因現今大部分 的影音網站都沒有提供影片拍攝的景點資訊而苦於找不出影片地點,雖然有少數 網站提供影片定位功能如: YouTube ,但其僅針對整部影片給予定位,若影片 當中有許多景點時,用此定位方式並無法將各景點的位置在地圖中標示出來,只 能給予一個定位點,可能無法滿足使用者需求。

偶然之間在觀看交通大學「開放式課程 (Open Course Ware, OCW)」平台 [11](圖 1-1)時,發覺目前少有專門提供教學影片播放的平台,因為其影片後製 需要花費許多工夫而非一般業餘人士所能勝任,並且若能將影片與關鍵畫面結 合,更可以提供給觀看的學習者豐富選擇,隨時可以播放想觀看的片段,要達到 此高互動性的功能,影音檔案需要串流伺服器並配合的關鍵畫面技術,而一般的 影音網站並沒有提供此兩者給合之服務,因此本論文提出的系統欲將本實驗室已 有之系統平台「多媒體旅遊導覽系統」[1]加以修改,使教學影片也可以利用本

(11)

系統強大的關鍵圖片與討論機制,讓眾多的使用者看到用心製作的教學影片。

圖 1-1 交通大學開放式課程頁面

(12)

了一個影片與地圖結合的平台,使用者可以自由地在影片上給予定位資訊,構想 非常不錯,但是隨著景點增加,頁面的呈現愈來愈不容易,因此希望能改進播放 頁面的呈現方式,設計一個方便使用者操作的介面,在不影響影片觀看下顯示影 片相關資訊。

1.2 研究目標

本研究為延續本實驗室李佳蓁,「Web 2.0 線上多媒體旅遊導覽系統」[1], 更改系統架構、版本呈現與增加功能之研究,為了讓更多使用者同時上線觀看影 片並豐富系統功能,本論文欲達到以下目標: (1)對 Web 2.0 相關之文獻與技術做系統性整理並實作。 (2)將原本只有單一伺服器的系統,將其功能切割,分散到多台伺服器上, 聯合運作服務使用者,並評估其效能增進。 (3) 除原有系統功能外,增加上傳教學影片功能,成為多功能媒體展示平 台,因此需將系統做些許修改,使其功能多元化以提供更多元服務。 (4)為了呈現多樣資訊,修改版播放時的呈現方式,將原本單一功能的地圖 區域,提高與使用者的互動性,置換為擁有多功能資展示的窗口,提供 在地資訊、關鍵畫面瀏覽、影片描述、綜合評論機制與教學畫面。 (5)建立以標籤分類的影片管理機制,利用多樣化的標籤描述影片。

1.3 研究方向

目前大多的相關研究都在說明與解釋 Web 2.0 的產生,與探討分析國內外新 興之創新服務網站,在技術、工具與分析上都很少提到,本論文整理 Web 2.0 相關技術並應用於網站建構。 網站除了原有功能「旅遊導覽」外,本系統欲在原有基礎下新增教學影片播 放平台,提供熱心拍攝教學影片的使用者,方便地分享用心製作的教學影片,讓 廣大的網路使用者討論並提供建議,在良性互動下,可以使更多人分享彼此熟悉

(13)

的專業。此外,為了增加系統承載力,本論文亦研究如何將系統中各功能切割獨 立出來,成為不同伺服器,使各伺服器聯合運作服務使用者。

1.4 章節介紹

在以下章節中,第2章首先介紹 Web 2.0 相關技術整合方法與相關網站之研 究,以了解各網站的服務及構建型態,進而學習各網站的優點和經驗;第3章介 紹本系統的系統架構與設計,與資料庫的設計;第4章介紹系統的功能與使用流 程,並提供實例演示;第5章為系統的測試結果,以驗證其效能;第6章是結論及 未來方向。

(14)

第 2章 相關研究

本節將彙整 Web 2.0 之相關文獻,以了解其發展起緣、主要特性與概念與相 關技術,並介紹一些目前與本論文相關的 Web 2.0 網站,如 Google Maps 、 YouTube,藉由整理這些具有代表性的網站的過程中,以了解各網站所著重的服 務項目及構建互動平台之型態,進而學習各網站的優點和經驗。

2.1 何謂Web 2.0

在維基百科[3]所定義的Web 1.0,最早的概念為「不須經常更新,甚至不用 更新的靜態頁面(Hyper Text Markup Language, HTML)」。HTML是1989年Tim Berners-Lee所創造的;在1990年被World Wide Web所開始使用,HTML是種具有 許多風格的一種語言。它透過一些特別的標籤 (Tag) 來展現各種不同的風格。 在經過網路泡沫化後,由成功的網路企業中,可發現許多極受歡迎的新應用,因 此O'Reilly Media的副總裁Dale Dougherty認為 Web 正處於演進的過程中,他 以軟體版本更新的命名方式,將過去的Web稱為Web 1.0,而新的應用特徵則統稱 為Web 2.0。

(15)

2.1.1 Web 2.0 的起緣

Web 2.0 這個觀念最早是由 O'Reilly Media 的副總裁 Dale Dougherty 和 MediaLive International 的副總裁 Craig Cline 在 2004 年某一場共同合作的 研討會中提出來的,以下列舉服務方式來比較 Web 1.0 與 Web 2.0 網站差別。

表 2-1 Web 1.0 與 Web 2.0 之比較

服務 Web 1.0 Web 2.0

廣告方式 DoubleClick Google AdSense

相簿 Ofoto Flickr

資料傳送 Akamai BitTorrent 音樂 Mp3.com Napster 百科全書 Britannica Online Wikipedia

社交軟體 Evite Upcoming.org and EVDB 個人媒體 Personal website Blogging

網站宣傳 Domain name speculation Search engine optimization 網站效益評估 Page views Cost per click

網路應用 Screen scraping Web service 互動方式 Publishing Participation 內容管理 Content management system Wikis

分類方式 Directories Tagging 聯播方式 Stickiness Syndication

資料來源:整理自 Tim O'Reilly, “What Web 2.0", 2005

O'Reilly僅提供服務比較表(表 2-1)並沒有詳細比較實質的差異,而林[5] 對此做出歸結補充,做以下特性說明:

(1)DoubleClick 與 Google Adsense 廣告方式不同,在於 Google Adsense 可以藉由使用者點擊次數搜尋排序,根據使用者搜尋時使用的關鍵字, 呈現相關的廣告。

(16)

的 Flickr 卻能夠以「標籤 (Tag) 」的方式來搜尋相片,更容易達到相 片分享的目的。 (3) BitTorrent 、 Naspter 讓使用者直接分享彼此之間的資源,形成點對 點 (P2P) 的分享方式,而不是靠經營者增加伺服器、擴增資料庫來改善 服務,是一種去中心化的架構。 (4) Wikipedia 和傳統由專家編寫百科全書的模式不同,將編輯功能開放給 使用者,每個使用者可以依自己熟知的領域提供經驗,屬於共同創作、 集體智慧模式。 (5)個人網頁與部落格最大的不同在於個人網頁中資料的撰寫與呈現,目的 是宣傳與介紹自己,而在編輯介面的操作,較少能直接在網頁介面上做 資料修改與編輯;而 Web 2.0 的部落格,使用者可以在網頁介面上快速 地直接作資料得編輯,就算沒學過網頁製作也可以輕鬆地在網路上分分 自己的生活點滴。 (6)互動方式,原本資料是由網站提供,使用者只能被動單向接收;而 Web 2.0 是使用者主動貢獻資料,資訊交流方式是雙向。 (7)內容管理是以眾多使用者用 wiki 方式共同編輯的模式,創造出集體合 作的智慧。 (8)目錄 (Directories) 是由專家及經營者來決定分類的標準與名稱;而標 籤的功能可以讓使用者自己決定項目的標準與名稱,而且同一個物件, 可以有多個標籤,達到個人化。 (9) Web 1.0 服務靠吸引使用者,讓使用者不斷地天天登入造訪網站,瀏覽 已更新的資訊,而成為網站的重度使用者;而 Web 2.0 是藉合「聚合」 或「聯播」的方式,透過訂閱有興趣的主題,讓使用者不必登入網站即 可隨時掌握更新資訊。

(17)

2.1.2 Web 2.0 特性與特色

在 Web 2.0 的特性方面,包含了許多概念,「資訊與電腦」雜誌裡認為 Web 2.0 為一個參與式的媒體,網路媒介不再只是一方發言,而是雙方面,不再是很 多人包圍一個網站的概念,是ㄧ個人輻射出的一個社群概念。 Web 2.0 的特性 應該是以「使用者貢獻內容」的概念為核心,換句話說就是提高使用者的參與度, 讓使用者貢獻內容。 根據資策會服務研究所FIND(2006)研究中心技術觀測組的研究[4],用4C簡 單說Web2.0的特性(表 2-2): (1)社群(Community) 社群概念在Web 1.0通常以加入會員為運作機制;Web2.0在各種服務上 添加社會網路,社群更多樣化,如網路書籤、書摘影評、相簿、地理位 置等…,活用人際接點,運用社會網路功能促進彼此分享,增強使用者 對於網站服務的黏性。 (2)內容(Content) 相較於Web 1.0,網站內容的提供、發佈呈現掌握在經營者手中;而Web 2.0強調雙向溝通與互動,由使用者參與且主動貢獻內容,權力由經營 者轉移到使用者手上,鼓勵使用者多多參與、互動,以創造豐富的內容。 (3)使用者經驗(Consumer Experience) 運用資訊技術,提供便利的操作介面降低使用者的學習門檻,提升其對 服務的接受度。在強調使用者為中心的概念下,良好的操作體驗是讓使 用者持續使用的基礎之一,Web 2.0大都使用AJAX讓使用者享受便利且 互動性高的使用介面。 (4)交叉服務(Cross Service) 因為技術進步與經營觀念轉變,各網站開放服務平台API,以混搭 (Mashup)的方式拓展附加價值,混搭是利用現有的服務開放介面,重新

(18)

組合創造出新服務。 表 2-2 Web 2.0 的 4C 特性 4C 特性 創新技術 典範 社群 (Community) 在各種服務上添加社會

網絡,人際接點多樣化 Social Computing Linked in 內容 (Content) 鼓勵使用者參與及互動 由使用者提供內容 Wiki、 Folksonomy、Blog 維基百科、 flickr 使用者經驗 (Consumer Experience) 便利、直覺、高度互動 性的使用介面,用戶端 不需安裝額外元件

AJAX Google Map、 UrMap 交叉服務 (Cross Service) 開放服務平台API,以混 搭方式拓展服務附加價 值

Web Service、RSS Salesforce.com 、Google Maps

2.1.3 Web 2.0 網站

本 節 將 介 紹 與 分 析 與 本 系 統 相 關 之 Web 2.0 網 站 : Google Maps 、 YouTube,以了解其受歡迎原因,並研究其使用的相關技術、網站特色,從中學 習這些網站成功的技巧。

2.1.3.1 Google Maps

Google Maps 將圖資存放在網路上,透過 JavaScript 控制地圖的移動與呈 現,其操作方式與速度,已經可以如一般桌面應用程式使用,除了一般的電子地 圖外,還有衛星地圖可以使用,加上眾多網友、商家所提供的資訊, Google Maps 資訊的數量與正確性卻不是一般地圖軟體所能提供。而 Google Maps 擔任一個 資訊交流與儲存的平台,背後還透過演算法分析相關地標,讓使用者方便且快速 的搜尋到需要的資源。

此外 Google Maps 也將其資源開放出來,透過 Google Maps API ,可以很 容易的使用這些地圖資源,製作與地圖相關之運用,本系統即是採用 Google Maps API 實作動態地圖。

(19)

圖 2-1 Google Maps 台灣首頁

「Google Maps」技術背後的文化價值,就是社區與在地的精神。雖然 Google Maps 虛擬化全球的真實空間,但相反地,更確認了真實地理空間的重要性。我 們需要虛擬的 Google Maps 帶我們到真實的空間,從路線規劃到尋找社區附近 的美食,而 Google Maps 的成功在於,拉近虛擬與真實生活的場域,說穿了, 技術的偉大不是重點,貼近生活所需才是關鍵[9]。 2.1.3.2 YouTube YouTube 僅是提供網友間線上分享的影片平台,因為其容易使用,又可 以立即地留言、討論讓 YouTube 成為當今最大的影音網站,其成功的因素還是靠 它原來的那一句話:「即時散播自己的 video」,隨上傳等待處理,然後就馬上上 線。 但值得注意的是,創業家當初並沒有盤算到這句話的威力。他們不過也只是 想解決自家拍攝的影片沒地方上傳與朋友分享的問題,才想做出一個可以「即時 散播自己的video」的網站,他們並沒有預估到今天YouTube會這麼紅火。但是, 創業家仍然讓YouTube把握「即時散播自己的video」這個創意點,以這個大創意

(20)

點為中心,所有在旁邊的功能只是在配合這個創意,堅持這個創業,最後,YouTube 就誤打誤撞的碰到一個沒人發現的秘密[10]。 YouTube 在頁面中並沒有使用太豐富的 JavaScript ,頁面呈現只使用 CSS 與 DOM ,讓播放影片的區域盡可能放大,播放器使用 Flash 製作,除播放功能 外還能與使用者互動,YouTube 除了提供影片分享平台外也努力地找尋出系統中 相關的影片。

(21)
(22)

2.1.4 社群參與及創造

Web 2.0 的概念強調社群參與及創造,而Web 2.0 網站豐富的內容大部分是 由廣大的使用者提供,這些經驗相同的人逐漸形成社群例如: Blog 、 Google Maps 、 Wikipedia 、 YouTube 等,許多創新研究和重要應用議題已逐漸受到 學術界和產業界重視[5]、[6]、[7]、[8]。

2.2 Web 2.0 相關技術

Web 2.0 除了使用者參與方面外,為了提供使用者良好的瀏覽經驗,網頁 呈現的技術與Web 1.0 改變許多,Web 2.0 的網頁應用程式是雙向互動的關係, 讓使用者可以像一般應用程式一樣地操作頁面、找到自己所要的功能,為了滿 足這些需求,本節整理目前熱門的 Web 2.0 相關的技術: AJAX (2.2.1) 、 JavaScript (2.2.2)、 DOM (2.2.3)、XML (2.2.4),並介紹各技術負責功能與 彼此間互動聯合運作的關係與方法。

2.2.1 AJAX

根據維基[3]定義Asynchronous JavaScript and XML (AJAX) 不是新技術, 卻是Web 2.0 成功不可獲缺的因素, AJAX 是將許多技術合在一起使用,這樣的 技巧被大量的應用於Google的網頁之後,如 GMail[21] 、 Google Maps[22] 和 Google Suggest[23] 等才被重視,由幾個主要部分構成: (1)使用 XHTML + CSS 來展現網頁 (2)使用 JavaScript 操作 DOM 讓網頁產生動態效果 (3)使用 XML 和 XSLT 進行傳送資訊 (4)使用 XMLHttpRequest 與伺服器進行非同步資料交換 (5)使用 JavaScript 控制所有動作觸發 使用 AJAX 技術開發的網站最大的優點就是在互動時的反應時間極為快 速,沒有過去頁面重新載入的情形,可以在不更新整個頁面的前提下維護資料,

(23)

這使得Web應用程式更為迅速地回應使用者動作,避免在網路上傳送那些沒有改 變過的資訊,大大拉近 Web 應用程式與桌面應用程式之間的距離例如: Google Docs[24] 與 Google Maps 就是以快速的互動,與便利的介面讓使用者有良好的 體驗,未來甚至可以取代一般的應用程式,因為其豐富的內容可以吸引更多使用 者的參與下,可以提供更精確的資訊,而企業也可以在這些使用者行為上做資料 探勘提供相關的連結,形成雙贏互動結果。 圖 2-3是比較傳統網站互動與AJAX網站資料的傳輸與展現方式,傳統的頁面 更新方式是在使用者按下連結或表單時,瀏覽器會向網頁伺服器送出 HTTP request ,而使用者需要等待頁面在伺服器運算完成後傳回結果,使用者端的瀏 覽器再將頁面顯示出來,這樣的架構下無法達到不換頁更新頁面的效果,而在 AJAX 中使用 XMLHttpRequest 讓使用者在不換頁更新頁面,簡單的來說, AJAX 在用戶端的瀏覽器有兩層,一層是 JavaScript 為基礎的 AJAX 引擎,另一層是 DOM 結構的網頁,使用者都是在操作 DOM。

圖 2-4是比較一般網頁的同步傳輸與 AJAX 技術下的非同步傳輸,在圖中可 以發現使用者在示同步傳輸模式下,可以一直處於主動 (activity) 的模式下與 一般的桌面應用程式操作經驗相同。

(24)

browser client

browser client user interface

AJAX engine

JavaScript call HTML+CSS data user interface

sever-side systems web server

datastores

sever-side systems web and/or XML server

datastores HTTP request HTTP request XML data HTML+CSS data AJAX

web application model classic

web application model

(25)

Classic web application model (synchronous) client server time system processing system processing user activity user activity user activity

AJAX web application model (asynchronous)

server user activity server-side processing browser UI client-side processing AJAX engine server-side processing time client 圖 2-4 同步與非同步傳輸

2.2.2 JavaScript

JavaScript 是一種廣泛用於客戶端 Web 開發的腳本語言,其在客戶端執行 時不需先經過編譯,而是將文字格式的字元代碼發送給瀏覽器由瀏覽器解釋執 行,在 Web 1.0 時期常用來給 HTML 網頁添加動態功能,在 Web 2.0 網站上配 合 XMLHttpRequest 讓 JavaScript 的功用更加強大,此技術擔任 AJAX 在瀏覽 器端的引擎,配合 JavaScript 的 XML 解釋器,可以動態的與伺服器端連繫取 得資料,使用者端的 JavaScript 處理後更新在頁面中。

(26)

大不同的是, JavaScript 沒有任何輸入或輸出的觀念。它是被設計成在一個宿 主 (host) 環境下執行的腳本 (script) 語言,所以任何與外界通訊的方式,都 是宿主環境的責任。瀏覽器是最常見的宿主環境,不過有些程式也有 JavaScript 解釋器,如 Adobe Acrobat 、 Photoshop 以及 Yahoo! Widget Engine 等…, Web 2.0 互動大部分是使用 JavaScript 的便利性與強大的 DOM 結構控制在瀏覽 器上展現,但在使用上需注意各瀏覽器 JavaScript 語法支援上有些許差別,希 望未來可以統一。

2.2.3 DOM

Document Object Model (DOM) ,是 W3C[14]組織推薦的處理可擴展置標語 言的標準介面,將網頁內所有的元件都物件化,而 JavaScript 可以動態操作DOM 結構、修改物件屬性,因此 DOM 已被廣泛地用於 Web 2.0 網站中,做為網頁呈 現的架構; DOM 通常會配合 Cascading Style Sheets (CSS) 使用, CSS 描述 物件的大小、顯示屬性,利用 CSS 管理網頁樣式可以有組織且方便地定義出網 頁的樣式或改變頁面風格,因此 DOM 可以專注於整體頁面的結構上。

圖 2-5 DOM 結構

(27)

2.2.4 XML

Extensible Markup Language (XML)是由 W3C 所制定的一種標籤語言,其 主要用途的是描述與保存資料,不是用來表現或展示資料,常應用於 web 開發 許多方面、簡化資料的存儲和共用。 XML 可自訂文件描述的標籤使其更豐富來 描述資料,透過 XML 資料能夠存儲在獨立的 XML 檔中,這樣就可以專注於使用 CSS 、 HTML 及 JavaScript 進行版面配置與展示,並確保修改底層資料不再需 要對 HTML 進行任何的改變。對開發人員來說,最費時的挑戰一直是在網際網路 上不相容系統之間的資料交換。由於 XML 可以簡化資料,通過各種不相容的應 用程式來讀取資料,所以 XML 可以在不相容的系統之間輕鬆地交換資料,降低 複雜性。 在不損失資料的情況下,也更容易擴展或升級到新的作業系統、新應用程式 或新的瀏覽器。目前被大量的使用在 RSS 機制,例如部落格有新增文章,只要 部落格有遵循 XML 1.0/2.0 的規範去發佈新增文章的 RSS 資料,就可以被任何 RSS Reader 所擷取及辨識,而不會產生不同部落格的 RSS 格式不一,造成 RSS Reader 只能適用特定少數的部落格系統。 傳統 HTML 雖然已經很廣泛地流傳,但它有個很大的缺點:沒有嚴謹的規 範,所以過去的網頁時常有不同瀏覽器顯示狀況差距很大的情形。而 XML 在這 方面就有很大的優勢,因為 XML 格式非常嚴謹,一定要有結尾 tag 、巢狀結構 該如何等,在 XML 中都有很嚴格的規範,在 AJAX 中通常伺服器回傳資料的格 式也使用 XML 進行資料傳輸。

2.3 小結

歸結這些成功的 Web 2.0 網站,都有共同的原因,就是簡單、易用、分享 容易,配合新興的網頁技術,網站操作已經不像 Web 1.0 那樣死板,需要等待 伺服器處理後換頁,透過 AJAX 技術,網站變得很容易操作,除了要上網才能使

(28)

用這些資源外,其他的介面與回應功能已經可以與桌面應用程式齊鼓相當,但也 因為連接網際網路,擁有眾多使用者提供的經驗與內容,才能有豐富的內容與應 用;而現在也有一些 Web 2.0 網站提供離線使用的功能,未來應該有與桌面應 用程式一較高下的實力。

(29)

第 3章 系統架構與設計

3.1 系統設計理念

本系統是更改李[1]所建構的「多媒體旊遊導覽」系統,在原有系統上開發 新功能:支援教學影片播放、增加多功能展示窗整合原本散置在頁面各處的相關 資訊,並增加系統負荷量而更改伺服器架構成分散式系統,容許同時間大量的使 用者觀看瀏覽網站資源。

3.2 系統架構與開發環境

此節介紹本系統所需的軟硬體及使用的開發工具。如圖 3-1所示,整個系統 採用 LAMP 架構 (Linux 、 Apache 、 MySQL 、 PHP) 為基礎,以此為基礎下 拓展成分散式系統架構。

本系統環境中,作業系統採用 Linux 為基礎的 Fedora 8[15];網站伺服器 為Apache[17] ;資料庫使用 MySQL Cluster[20],編碼為萬國碼 (UTF-8) ; 前 端 介 面 語 言 使 用 PHP[18] ; 影 片 播 放 器 為 Flash Player 配 合 ActionScript 作為多媒體播放器與系統網頁互動的語言;影片串流使用 Flash Media Server (FMS)[16];網頁前端與使用者互動採用 AJAX ,使用 CSS 樣式 表配合 DOM 結構展現網頁。

(30)

DOM, JavaScript,

Flash Player

HAProxy

MySQL

Cluster

FMS

Internet

Apache+PHP

VCS

Video

Matching

Server

Client

圖 3-1 系統架構圖 為了增加伺服器的承載力,本論文建立各伺服器負責不同事務,組成分散式 系統,利用多台伺服器,聯合運作下提供更多的資源,各伺服器功能運作流程在 下一節詳細說明。

3.2.1 影片轉檔伺服器

Video Convert Server (VCS) 影片轉檔伺服器是負責將使用者提供的影片 轉成符合方便於網路上傳輸的串流格式,本論文修改李[1]系統中所使用的線上 轉檔機制,李所提出的方式是透過 PHP 呼叫伺服器端的轉檔程式,而 PHP 需要 使用者觸發,因此在使用者上傳影片之後必需開著網頁轉檔,轉檔時間視影片長 短而有所不同,但影片轉檔所需花費不少時間,若使用者在轉檔期間將此網頁關 閉,則轉檔進度也會隨之中止,另一方面,在同一時間有多人上傳影片,所有的 轉檔工作會同時在一台伺服器上進行,造成每個人的等待時間隨之增加,加上使 用者又必需一直開啟網頁,造成使用者體驗感會下降,有違 Web 2.0 介面親切

(31)

的精神。 有鑑於此本論文更改了轉檔過程的部分架構與運作方式,將轉檔功能獨立出 來,在原系統架構中加入影片轉檔伺服器,讓使用者上傳完影片後,無須開著網 頁等待轉檔完成,只需在影片上傳後等待一段時間,影片即可在本系統上展示並 提供定位服務,影片轉檔工作由轉檔伺服器自動至資料庫尋找還未轉檔之影片, 將影片轉為 flash 串流影片檔,支援常見的影片格式,原始影片格式可以是 avi 、 mpeg 、 rmvb 、 wmv 、 flv 格式,檔案大小為 500MB 以內;此外,轉 檔工作獨立出來也利於未來伺服器的擴充。 在影片進行轉檔時需要花費大量運算,因此系統中可以多配置幾台影片轉檔 伺服器,增加同時轉檔的數量,解決多使用者同時轉檔所造成延遲之問題。圖 3-2 描述影片轉檔伺服器的運作流程,伺服器每隔一段時間會到資料庫中取得還未轉 成串流檔的新進影片,若沒有新進影片,則伺服器再等待一段時間重覆此步驟, 直到被分配新進影片,隨即進行轉檔工作,轉檔時間依檔案長度、大小所需時間 不一,轉檔完成後,伺服器會截取影片截圖,並取得影片長度,最後將這些資訊 存到資料庫中,完成一輪的轉檔工作,再回到等待狀態。

(32)

是否有未 轉檔影片 沒有 休息一段時間 將資料庫中的影片狀態 設為轉檔中 影片轉為串流格式 有 截取影片畫面與取得影 片長度 將影片截圖與影片長度 存到資料庫並將影片狀 態設為轉檔完成 轉檔伺服器啟動 圖 3-2 影片轉檔伺服器運作流程

3.2.2 多媒體串流伺服器

串流 (Streaming) 技術就是把連續的影像和聲音資訊,經過壓縮處理後放 上網站伺服器,多媒體影音的檔案容量通常都較為龐大,如果採用一般「下載檔 案」的方式進行,必須要等檔案下載後才能觀賞下載的部分,會花費過多的等待 時間,而串流技術可讓使用者可以一邊下載一邊觀看、隨時快轉影片的網路傳輸 技術,藉著多媒體串流技術,使用者不需要等候龐大檔案完成下載後才收看影像 或收聽聲音。

(33)

在本系統中使用 Flash Media Server (FMS),因為串流影片需要透過 FMS, 會佔用伺服器的連線數,因此本系統使用的影片播放器的有兩種傳輸模式,(1) 一般模式、(2)串流模式,此二模式切換過程如圖 3-3,在大部分的情況下使用 者觀看影片時不會跳來跳去,此情況下不必使用串流伺服器,因為循序播放時, 影片檔的下載速度能夠跟上播放進度,採用一般網路傳輸模式即可應付播放需 求,當使用者透過關鍵畫面瀏覽窗點選或拉動影片時間軸時,若需要播放未下 載到的影片,此時影片傳輸立刻換成串流模式,透過 FMS 採用 Reliable Multicast Transport Protocol (RMTP) 的通訊協定傳送影片串流檔至使用者 端的Flash Player。 使用一般播放器播放 拖拉時間軸 點選關鍵畫面 影片下載 狀態 使用串流播放器播放 拖拉時間軸 點選關鍵畫面 未下載到 播放處 已下載到播放處 圖 3-3 影片播放器切換流程

(34)

3.2.3 動態網頁伺服器

網路上眾多使用者提供的內容,皆運用動態網頁伺服器做接口,將資料內容 存至後端資料庫中,這是傳統 HTML 所無法達成的功能,在 HTML 下資料只能單 向且靜態的呈現網頁內容,無法和資料庫連接,在 Web 1.0 時許多的會員機制 亦是用此伺服器實作。 依據使用者瀏覽,動態網頁伺服器可以與後端資料庫連接,取出所需的資料 再透過動態網頁伺服器編排成 HTML ,最後呈現出使用者所見的頁面,並產生相 關的 JavaScript 控制相關地圖與資訊展示,本系統採用 Apache[17]搭配 PHP[18]當作動態網頁伺服器。 同時 AJAX 因為安全性問題,沒有提供直接從伺服器端連接資料庫取得資料 之方法,需經由動態網頁伺服器做連接的橋樑,故此伺服器在 Web 2.0 的架構 下不可或缺,其他常擔任此伺服器有 JSP 、 ASP。

3.2.4 網頁負載均衡伺服器

一台動態網頁伺服器能夠承載的連線數量是有一定限制,特別是在同一時間 的存取,當伺服器處理不及時會造成運算延遲,造成使用者等待頁面時間增長, 為減少此現象,本系統採用 HAProxy[19],將前端動態網頁運算分配至後端多台 伺服器做處理,在 HAProxy 可以設定後端有幾台伺服器、多久要去檢測伺服器 是否存在,若當中有伺服器當機、離線時就可以馬上將此伺服器由線上服務中抽 離,只要在後端伺服器故障排除或重新啟動後,HAProxy將會自動恢復伺服器上 線運作服務。 使用 HAProxy 雖然可以有效的將運算導到後端的伺服器計算,但後端的動 態網頁伺服器都是完整獨立運作的伺服器,使用者的 session 無法在各伺服器 間記錄,為解決此問題,本系統將後端各伺服器的 session 存到同一台伺服器 的 ramdisk ,使用 ramdisk 好處是不會有傳統硬碟的物理瓶頸,再分享到各伺

(35)

服器存取達到共享 session 。 HAProxy 只提供動態網頁運算的分流,對於靜態的部分如:圖片、js檔、css 檔,因此系統中靜態資料需要設定在另一個連接埠 (port) 上或是另外設置一台 靜態網頁的伺服器,而本系統採用另開一個連接埠的實作(圖 3-4),系統內部有 八台動態網頁伺服器。 user HAProxy Server IP:80 Apache + PHP Server IP:8080 Apache + PHP 192.168.1.2:80 Apache + PHP 192.168.1.3:80 Apache + PHP 192.168.1.4:80 Apache + PHP 192.168.1.5:80 Apache + PHP 192.168.1.6:80 Apache + PHP 192.168.1.7:80 Apache + PHP 192.168.1.9:80 .js .css .jpg .gif .php 192.168.1.8:80 Apache + PHP 圖 3-4 系統 HAProxy 分流架構

3.2.5 資料庫叢集

資料庫是專門管理資料的系統,使用資料庫好處是可以透過高階的 SQL 語 言,向資料庫系統取得指定資料,無需操心資料怎麼存放、空間如何配置,而各 資料表的欄位規格可以依需求自訂所需要的型態,資料庫系統也會維護資料表之 間的完整性,減少使用者維護的負擔,此外有提供索引鍵 (index key) 讓資料 在搜尋時更快速地被找到。 當資料庫管理、儲存的資訊量愈來愈多時,單一台伺服器的資料庫架構,在

(36)

存取時會無法負荷,造成資料取用的延遲,進而成為頁面展示的瓶頸,而資料庫 叢集 (Clustering) 為了解決此問題而開發出來的解決方案,此技術可讓一個資 料庫系統在數台伺服器上執行,利用平行運算與分散儲存的技術增進資料庫系統 的負載量,而不需要單一台昂貴的大型Unix伺服器,在本系統中採用MySQL Clustering[20] ,設定內部有 4 個資料節點與 4 個備份節點共 8 台伺服器(圖 3-5),若其中有幾台伺服器故障並不會影響整體系統的運作。

Database

圖 3-5 系統資料庫叢集架構

3.2.6 多語系支援

網路是一個無國界的地方,世界各地只要能連上網際網路 (Internet) 這個 複雜的網絡,就可以遨遊世界各地的網站,許多國際性的網站也努力地將網站做 在地化的翻譯,其採用的方式大都是透過語系包而得以支援多國語系,所謂的語 系包其實是翻譯過的字詞串列,在頁面中可以動態的替換成不同的語系,在不破 壞原本網站結構的前提下,使用語系包是最容易維護、成本最小的解決方式,只 data node backup node data node backup node data node data node backup node backup node

(37)

需先將網頁中不變的字詞提取出來,放置到伺服器端的語系包中,使用者在瀏覽 網站時,系統載入不同的語系包,頁面就可以呈現使用者熟悉的語言,在熟悉的 語言下分享彼此的資訊(圖 3-6、圖 3-7),本系統實作方式是利用 Cookies 存 放使用者使用的語系,瀏覽頁面時,先從使用者端的 Cookies 判斷要載入哪個 語系包,再呈現於網頁中。 圖 3-6 系統中文版首頁

(38)

圖 3-7 系統英文版首頁

語系包僅止於網頁介面的翻譯,使用者在網站中提供的景點資訊、留言、討 論皆無法一起轉成多國語系,這樣是對提供者的尊重,感謝使用者提供的內容, 而為了使內容呈現與保存能支援多國文字,因此本系統中所有的資料庫系統,皆 使用 UTF-8 編碼方式。

(39)

3.3 頁面瀏覽流程

圖 3-8是使用者瀏覽本系統頁面之流程,使用者在進入首頁後,隨即可以點 選首頁中快速連結區的影片觀看(圖 3-9),此區域提供十部影片,其中上方五部 是會隨機挑選其他使用者評分較高的影片,下面五部則是最新使用者上傳之影 片;或是進入影片列表挑選想觀看之影片,影片列表頁面右側有標籤可以選擇, 點選後系統會將有此標籤的影片展現出來(圖 3-10);若想上傳影片,則可以進 入上傳影片頁面在4.4.1節有詳細介紹。 圖 3-8 頁面瀏覽流程 播放頁面 影片列表 上傳影片 首頁 圖 3-9 系統首頁快速連結區

(40)

(b)

(a)

圖 3-10 影片列表頁面

(41)

3.4 資料庫設計

本節主要介紹網站所使用的資料庫系統架構,3.4.1節先介紹使用的資料表 之間的關係 (Entity Relationship Diagram, ERD) ,3.4.2節介紹各資料表詳 細的設內容。

3.4.1 資料表關係圖

member PK Account No Password Name Sex Year Month Day Email Career IP upload PK Name No file_scr Title FK1 Account Date file_size file_time starttime counter Grade recommended longitude latitude Tags State serverIP Image modify PK Filename PK Starttime No Title FK1 Modifer Longitude Latitude Date FK2 VideoNo Tags FK3 Sponsor Zoom Image Name discussion PK,FK2 Name No FK1 Account Date Pgrade discussion AppleRecord PK,FK1 Account PK,FK2 VideoNo PK,FK3 AttractionNo No Apples Date Filename Starttime sponsor PK Id Name address phone describe Web Lon Lat keyword Image 圖 3-11 資料表關係圖 圖 3-11 是 本 系 統 資 料 庫 所 設 計 的 資 料 表 關 係 圖 , 主 要 有 member 、 upload 、 modify 、 discussion 、 AppleRecord 、 sponsor 詳細欄位設定 在下一節說明。

3.4.2 系統資料庫設計

(42)

只介紹相較於李[1]「線上多媒體旅遊導覽系統」增加的部分,其他未更改的部 分與李所建構之系統使用相同,資料庫中共有六資料表,其中四個資料表(會員 資訊表、影片資訊表、景點資訊表、影片評論表)沿用原系統,只加上少許欄位, 另外兩個(景點定位討論表、討論定位內容表)因本論文所開發之新功能,置換成 所需的資料表(評分記錄表、相關資訊表),本節將說明各個資料表以及其所內所 設計的各項欄位、主鍵及外來鍵的選擇,以下表中雙線部分是系統為了增加功能 而新增之欄位。 3.4.2.1 會員資訊表 本系統設計中任何使用者都可以任意瀏覽影片與觀看相關內容,但使用者若 要上傳影片或是提供景點資訊,就需要加入會員,成為會員後系統可以記錄每個 使用者對網站的貢獻,讓會員覺得自己的付出是能被別人看見,增加會員的凝聚 力,因此資料庫中設計有會員資訊表(表 3-1),記錄每位會員的基本資料,也可 以利用此資料表設定每位會員的權限,未來可利用此資料表配合會員活動的關 係,分析每個會員間的關係,或是限定影片分享與修改景點的方式。 本系統實作加入IP這個欄位,此欄位會記錄使用者所使用之IP,方便於資訊 正確與否的判斷,及提供多語系的支援(3.2.6 p.27)。 資料表名稱:member 主鍵(Primary Key):Account 外來鍵(Foreign Key):Account 表 3-1 會員資訊表 英文名稱 PK FK 中文名稱 設定域值 IP 會員的登入的IP varchar(64) No 流水號 int(5) Account ● ● 申請的帳號 varchar(10) Password 密碼 varchar(10) Name 姓名 varchar(10)

(43)

Sex 性別 char(2) Year 出生年 int(4) Month 出生月 tinyint(4) Day 出生日 tinyint(4) Email 電子信箱 varchar(20) Career 職業 Text 3.4.2.2 影片資訊表 為了記錄每位會員上傳影片與提供的影片資訊與系統搜尋的在地資訊,資料 庫中建立一個專門儲存影片資訊的資料表:影片資訊表(表 3-2)其中新增Tags 、 State 、 ServerIP 與 Image 欄位, Tags 欄位是用來做影片的標籤,本系統 可以利用此標籤將影片分類給瀏覽的使用者, State 欄位是為了轉檔伺服器 (3.2.1 p.21)而新增,其中記錄影片目前的處理狀況, ServerIP 記錄了影片存 放何處的內部 IP , Image 是影片截圖以Blob型態儲存,將圖片交由資料庫系 統管理有助於 HAProxy 的分流。 資料表名稱:upload 主鍵(Primary Key):Name 外來鍵(Foreign Key):Tags、Name、Account 表 3-2 影片資訊表 英文名稱 PK FK 中文名稱 設定域值 Tags ● 影片的標籤 Text State 影片處理的狀態 int(2)

serverIP 影片內部存放IP varchar(12)

Image 影片縮圖 Blob No 流水號 int(10) Name ● ● 影片檔名 varchar(50) file_scr 影片的描述 Text Title 影片名稱 varchar(100) Account ● 上傳者 varchar(10) Date 上傳時間 Timestamp file_size 影片檔案大小 varchar(100)

(44)

file_time 影片總長(秒) varchar(20) starttime 影片開始時間 int(10) counter 連線次數 int(10) Grade (總)評分 int(5) recommended (總)行程推薦 varchar(6) longitude 起始點的經度 varchar(20) latitude 起始點的緯度 varchar(20) 3.4.2.3 景點資訊表 本系統最大特色之一就是能在影片中任何時間給予定位的功能,此功能的實 現需靠景點資訊表(表 3-3),此資料表包含景點所有的資訊:影片時間、經緯度、 在地資訊、提供者帳號等,新增 sponsor 欄位儲存相關在地資訊的流水號,因 為其有多個,做使用 Text 型態存放; Zoom 欄位是記錄使用者在提供此景點 時,動態地圖所在的縮放大小,當影片播放時,就以此等級的縮放大小做為動態 地圖展示的縮放等級; image 欄位存放景點所在秒數的影片截圖,在此資料表 也是使用資料庫管理截圖。 資料表名稱:modify

主鍵(Primary Key):filename 、 starttime

外來鍵(Foreign Key):VideoNo、sponsor、filename、modifier、starttime 表 3-3 景點資訊表 英文名稱 PK FK 中文名稱 設定域值 VideoNo ● 影片的流水號 int(100) Tags 景點的標籤 Text Sponsor ● 相關資訊流水號 Text Zoom map顯示的level int(2)

Image 景點截圖 Blob No 流水號 int(100) Filename ● ● 影片檔名 varchar(50) Title 景點名稱 varchar(100) Modifier ● 新增者 varchar(10) Starttime ● ● 景點開始時間(秒) int(10)

(45)

Longitude 景點經度 varchar(20) Latitude 景點緯度 varchar(20) Date 新增時間 Timestamp 3.4.2.4 綜合評論表 綜合評論表(表 3-4)存放的是使用者的討論內容,此表的結構未更改與「旅 遊導覽系統」使用相同,主要是記錄使用者對影片或是景點的討論內容,而在本 系統亦可用來給教學影片提供討論建議。 資料表名稱:discussion 主鍵(Primary Key):Name 外來鍵(Foreign Key):Name、Account 表 3-4 綜合評論表 英文名稱 PK FK 中文名稱 設定域值 No 流水號 int(100) Name ● ● 影片檔名 varchar(50) Account ● 討論者 varchar(10) Date 討論時間 timestamp Pgrade 評分紀錄 int(1) discussion 討論留言 text 3.4.2.5 評分記錄表 評分記錄表(表 3-5)可以記錄使用者對影片與景點的評分,做為影片排序之 依據,此資料表欄位有 No 、 Account 、 VideoNo 、 AttractoinNo 、 Apples 、 Date。

資料表名稱:AppleRecord

主鍵(Primary Key):Account 、 VideoNo 、 AttractionNo 外來鍵(Foreign Key):Account 、 VideoNo 、 AttractionNo

(46)

表 3-5 評分記錄表 英文名稱 PK FK 中文名稱 設定域值 No 流水號 int(100) Account ● 評分的會員帳號 varchar(10) VideoNo ● ● 評分的影片 int(100) AttractionNo ● ● 評分的景點 int(100) Apples 分數 int(5) Date 評分時間 Timestamp 3.4.2.6 相關資訊表 相關資訊表(表 3-6)記錄相關資訊的一切資料:地址、名稱、電話、描述, 更可提供連結與圖片,經度與緯度的欄位用來與影片景點計算距離,便先提供離 景點較近的資訊給瀏覽的使用者,此表未來可以持續擴增,增加相關資訊,或是 增加欄位,做更多分類選擇的運用。 資料表名稱:sponsor 主鍵(Primary Key):Id 外來鍵(Foreign Key):Id、keyword 表 3-6 相關資訊表 英文名稱 PK FK 中文名稱 設定域值 Id ● ● 流水號 int(10) Name 名稱 varchar(128) address 地址 Text phone 電話 varchar(32) describe 描述 Text Web 網站 varchar(512) Lon 所在經度 Double Lat 所在緯度 double keyword ● 關鍵字 varchar(512) image 圖片 Blob

(47)

第 4章 系統功能與操作流程

4.1 多功能資訊展示

本系統主要功能是讓使用者在觀看影片同時,根據影片位置將地圖展示出 來,讓使用者立刻知道該景點的位置,並提供相關資訊,但隨著景點的增加頁面 呈現會愈來愈困難,原系統的關鍵畫面系統會讓網頁長度大幅增加,使用者無法 在一個視窗畫面觀看影片與關鍵圖片,為了改進此點,故本論文提出「多功能資 訊展示」功能,整合影片相關資訊後作有條理呈現,此章節將依序說明各功能類 別詳細內容。

4.2 影音播放器

播放頁面左側有一個影音播放器(圖 4-1),為了讓影片能夠隨點隨播,此 播放器由 Flash 製成,可以支援一般格式與串流格式的影片資料,其切換過程 在3.2.2節已敘述,此外播放器還負責本系統最重要的部分:將影片目前播放時 間傳送給 JavaScript ,有了目前的播放時間, JavaScript 才能控制所有相關 資訊展示呈現的工作;播放器還提供播放與暫停的函數給 JavaScript ,如此才 能在關鍵畫面瀏覽時點選景點圖片而立即觀看。

(48)

圖 4-1 影音播放器

4.3 相關資訊展示窗

在影片播放時,有許多資訊要同時展示:動態地圖、在地資訊、評語等,要 在不拉動網頁下展現,因展示版面有限,呈現不易,而且使用者也不會同時看所 有的資訊,因此本論文提出相關資訊展示窗,此展示窗並排於影片播放器旁邊, 讓使用者觀看影片時,可以立即地取得相關資訊。 展示窗的下方設計一個工具列(圖 4-2),整合動態地圖、關鍵圖片、影片描 述、網友評語、教學畫面選擇的功能,而此工具列有兩種模式:影片模式與教學 模式,影片模式設計給一般影片播放使用,教學模式專門給教學影片使用,兩者 功能有些許不同如表 4-1所示。 表 4-1 相關資訊展示窗模式比較表 影片模式 教學模式 動態地圖

教學畫面

關鍵圖片

影片描述

在地資訊

評語/分

(49)

使用者在觀看影片同時,可以透過此工具列任意選擇自己所要觀看的資訊, 或是利用關鍵畫面瀏覽的功能立即地了解影片內容並觀看有興趣的內容;使用者 在使用此展示窗瀏覽相關資訊的功能時,影片仍然繼續播放不受影響。 圖 4-2 相關資訊展示窗工具列

4.3.1 動態地圖

很多影片雖然有提供遊玩的地點,但都僅止於文字敘述,若能提供地圖參考 拍攝地點,可以快速地知道確切位置,本系統使用 Google 開放的 API[13]可以 在網頁中操作Google Maps,此API基於AJAX開發,只需要會JavaScript就可以透 過API取用Google Maps豐富資訊,不必自己準備圖資,也不用自己開發地圖系 統,利用現有的資源,創造更多的附加功能與應用,這樣的調用方式稱為交叉服 務[4]。 當使用者瀏覽影片時,在影片中景點若有使用者定位過,則動態地圖可以立 即展示影片的定位資訊方便瀏覽者明確地知道景點位置與周邊環境如圖 4-3所 示,左側影片播放澎湖的吉貝,右側的地圖隨之顯示吉貝的衛星地圖,透過此機 制使用者可以立即知道吉貝的位置在何處,如果想更進一步觀看地圖,可以將指 標移到動態地圖上以拖拉方式觀看想了解的詳細地圖,亦可在在一般地圖與衛星 地圖做切換。

(50)

圖 4-3 動態地圖 如果沒有定位資訊,則使用者馬上可以擔任景點的提供者此部分在4.4.3節 有詳細操作說明,而動態地圖提供搜尋功能方便定位者找尋目的資訊,當找到定 位點後在動態地圖上點擊,即可將景點位置資訊存入資料庫中,方便之後瀏覽者 觀賞。 當景點定位過多時,動態地圖在切換景點時,需花費較多時間計算,而造成 延遲現象,此問題本論文在4.4.4節提出解決方法,實作後影片播放順暢,感覺 不出有延遲現象。

4.3.2 關鍵畫面瀏覽

在「旅遊導覽」系統有提供關鍵畫面截圖(圖 4-4),但當使用者為影片增加 更多景點時,整個網頁不好呈現這些關鍵畫面,無法在一個使用者所見的畫面內 觀看關鍵畫面與影片,使用上有些不便,有鑑於此,本論文提出關鍵畫面瀏覽視 窗,版面的編排讓關鍵畫面與影片放在平行的位置,其可以同時顯示九個關鍵畫 面(圖 4-5),使用者欲觀看更多的畫面也可以拉動頁面右邊的頁面捲軸,拉動時 只會拉動到關鍵畫面,畫面框與影片的位置不變,此窗口的也可以讓使用者不必 觀看影片即可先預覽影片內容,並依據個人喜好來點選觀看。

(51)

圖 4-4 「旅遊導覽系統」中的關鍵畫面展現

(52)

圖 4-5 關鍵畫面瀏覽

4.3.3 影片描述

圖 4-6是呈現影片描述的畫面,視窗中的文字是由影片上傳者在上傳時所提 供之影片描述,透過此機制可以讓瀏覽者概略地知道影片內容,影片描述的內容 也可以用來當做影片搜尋時的資料來源。 圖 4-6 影片描述

(53)

4.3.4 在地資訊

使用者在觀看影片時,可能會想規劃一個行程到影片中的景點參觀旅遊,因 此本論文在系統中增加在地資訊,如圖 4-7右側所顯示的資訊,是在系統先比對 後,呈現與景點相關的食宿旅遊資訊,提供瀏覽者參考,比對方法與使用時機將 在4.4.2節詳細說明。 圖 4-7 在地資訊

4.3.5 使用者評語

圖 4-8是影片播放畫面時顯示使用者評語之畫面,此功能提供使用者在觀賞 影片時可以看到其他使用者對此影片、景點的建議與分享彼此的心得或提供評 論,讓觀看使用者的使用者有參與互動的地方。

(54)

圖 4-8 使用者評語

4.3.6 教學畫面

圖 4-9為本系統播放模式採用「教學模式」播放影片的畫面,教學影片常常 會配合投影片資料,透過教學畫面視窗瀏覽者可以一邊看著簡報一邊看教學者的 教學,除此之外還可以使用本系統提供的關鍵畫面功能,馬上觀看使用者有興趣 的教學片段,解決現今網路上教學影片播放困難之問題。

(55)

圖 4-9 教學畫面

4.4 系統功能

4.4.1 影片上傳與定位功能

Web 2.0 網站強調互動分享,使用者可以將自己拍攝的影片透過上傳頁面( 圖 4-10) 上傳分享,並提供影片相關資訊:影片介紹、定位資訊…等,讓其他 使用者方便了解此影片,也便於影片搜尋。 進入上傳頁面後,使用者先從電腦中選擇要從自己電腦上傳的影片,提供影 片描述,最後再利用右側的動態地圖搜尋與點選影片定位,最後再按下「上傳影 片」按鈕,即可開始進行影片上傳動作,因為系統中設有影片轉檔伺服器(3.2.1) 使用者僅需等待影片上傳完就可以離開上傳頁面,系統完成轉檔後,所分享的影 片可以立刻地在影片列表出現。

(56)

圖 4-10 影片上傳頁面

4.4.2 在地資訊搜尋比對

當景點被建立時,本系統會將相關的在地資訊:住宿、餐聽…等與景點建立 關聯方便使用者作為旅遊的參考,在地資訊的計算是在景點第一次被瀏覽時建 立,當有使用者點選系統中影片觀看時,若影片中有景點沒有在地資訊,則系統 會到資料庫中搜尋在地資訊出來,搜尋方式是利用使用者提供的影片、景點定位 的經緯度與資料庫中在地資訊的經緯度,計算距離遠近後,由近至遠排序,為了 避免出現距離太遠的資訊,這些資訊的距離需小於門檻值,才會將這些資訊寫入 景點資料表中相關資訊欄位,而資料庫中收集的在地資訊可以透過在網際網路上 搜尋而持續增加,提供更豐富的資料給使用者。 在景點第一次被觀看時才建立在地資訊是因為相關資訊的資料表會持續更 新,為確保所搜尋的資訊是最新的,因此在第一次被觀看時,才會執行,在景點 新增至景點第一次被觀看之間若相關資訊表有更新,最新的資訊也可以顯示在網

(57)

站中。

4.4.3 景點定位介面與流程

影片景點定位功能主要有新增景點、修改景點,流程如圖 4-11,當使用者 欲新增景點時,只需以登入的狀態在觀看影片時按下「新增景點」按鈕(圖 4-12),會立即彈出景點編輯窗,並附有影片的景點截圖,此時使用者可以新增 景點名稱,並在可以在地圖輸入關鍵字搜尋可能的定位地點之後再點選景點定 位,最後按下景點編輯窗上的「確定儲存」按鈕,系統先檢測所需資料是否填寫 完全,若有缺少會出現警告訊息(圖 4-14)提醒使用者有資訊沒有填寫,資料檢 測通過後即可將資訊新增於資料庫中,景點成功新增後,影片播放器在對應的時 間軸上會顯示黃色線條(圖 4-15)讓使用者知道景點已成功地新增至資料庫中, 並可以繼續觀看影片或編輯下一個景點。此過程皆使用 AJAX 技術,操作流程中 使用者都不需要更新畫面,就可以進行一連串新增景點之功能,由伺服器取得影 片截圖並新增資訊至資料庫中。

(58)

影片播放 按下「新增景點」 登入狀態 進入登入畫面 顯示景點編輯窗 輸入景點名稱 在動態地圖點選位置 按下「確定儲存」 在動態地圖搜尋關鍵字 將資訊寫入資料庫並在 影片播放器顯示黃線 未登入 已登入 檢測欄位 通過 未通過 圖 4-11 新增景點流程

(59)

圖 4-12 新增景點功能

(60)

圖 4-14 景點新增資料不完全警告 圖 4-15 影片播放器顯示新增景點

4.4.4 影片播放流暢度改善

播放頁面除了影片外,更包含許多影片相關資訊:地圖、影片介紹、在地資 訊、評語…,這些資訊會依影片播放而產生相對應的改變,實作中這些資訊之轉 換是以 JavaScript 控制,當影片定位點增加時,頁面中的資訊也隨之增加,當 資訊過多時會造成影片撥放有停頓現象,探究其原因是由於地圖運算經緯度運算

(61)

與圖資取得延遲而產生此現象,為了解決影片播放不順暢之現象,本系統對於影 片各景點先做前處理,若使用者沒有干涉下動態地圖依影片轉換,每次展現之地 圖皆為相同位置、大小,不必每次都重新運算,可使用靜能圖片取代動態地圖, 當使用者欲詳看地圖時,系統再以切換動態地圖顯示即可,如此可以大幅改善影 片播放之流暢度。

4.5 多媒體檔案標籤機制

4.5.1 標籤機制

標籤機制 (Tagging) 是為一個東西加上某些有代表性的關鍵詞,這些關鍵 詞就是標籤,這個動作某程度上是將物件分類,但跟傳統的分類不同的地方,在 於我們可以為同一件物品加上不同的標纖,做出多重分類,從而可以從多角度去 描述物件。

4.5.2 影片分類

透過標籤機制,本系統可以將影片使用標籤來分類,讓使用者可以更快速地 找到有興趣的影片,例如圖 4-16與圖 4-17是擁有風土文物與交大尋根築夢之旅 標籤的影片。 使用標籤的分類方式,使用者可以自訂各種的標籤,因此每部影片可以擁有 許多的標籤,利用標籤分類可以更多樣化的描述影片,是傳統目錄式分類所無法 達成的效果。

(62)
(63)
(64)

第 5章 系統測試與評估

5.1 連結測試

連結測試主要測試頁面中所有的連結是否正確無誤地連到指定頁面,確保使 用者在瀏覽網站時,都可以連結到欲取得的資料。 表 5-1 連結測試結果 測試頁面 連結頁面 測試結果 首頁 影片列表 OK 首頁 登入頁面 OK 首頁 上傳頁面 OK 首頁 影片播放頁面 OK 影片列表 首頁 OK 影片列表 登入頁面 OK 影片列表 影片標籤分類 OK 影片列表 影片播放頁面 OK 影片列表 上傳頁面 OK 影片播放頁面 首頁 OK 影片播放頁面 登入頁面 OK 影片播放頁面 上傳頁面 OK 影片播放頁面 影片列表 OK 影片播放頁面 影片播放頁面 OK 上傳頁面 首頁 OK 上傳頁面 影片列表 OK

(65)

表 5-1中測試頁面中的各種連結都正確的連結到該功能,使用者瀏覽網站系 統時,不會有錯誤的連結情形發生。

5.2 負載測試

本小節性能測試採用 AB (Apache Benchmark) ,程式來測試網站的負載性 能,比較分流架構下的網站系統提升多少的承載力,測試方法是程式在 30 秒內 一直對系統發出 request ,為了讓數據更準確,在此僅測試連線失敗次數小於 總測試連線數 5%內的資料,換言之就是有 95%以上都是成功連線的資料才會列入 計算,以不斷發送 request 來測試系統可容許多少人同時上線,並測試系統的 反應速度與同時上線的人數上限。 0 1000 2000 3000 4000 5000 6000 100 200 300 400 500 600 700 800 上線數(人) 回應時間(ms) 50% 66% 75% 80% 90% 95% 98% 99% 圖 5-1 回應速度曲線 由圖 5-1可看出本系統同時負載的人數可達到每秒 500 人左右,98%人可以 在 1 秒內收到伺服器的回應,但在 500 人之後,98%曲線的等待時間就大幅增加, 但 800 人同時上線時有 90%人可以在 1 秒內收到回應,顯示系統回應速率良好, 因為同時 800 人之後連線失敗數就大於測試數的 5%會造成測試數據不精確,故 在本測試中只測試到 800 人。

(66)

5.3 客戶端相容性測試

相容性測試是為確保系統在各種作業系統、瀏覽器下都能正確的顯示版面 配置與功能的完整性,不同的瀏覽器對 JavaScript 、 CSS 、 DOM 、 plug-ins 的規格不盡相同,客戶端程式撰寫時需要特別注意不同處,以 XMLHttpReauest 來說,每個瀏覽器需要用不同的方式宣告才能使用,在 JavaScript 常用 try 、 catch 語法為不同解釋器語法達成對應之功能。 表 5-2 相容性測試結果 作業系統 瀏覽器 相容性 Windows IE 6 OK Windows IE 7 OK Windows FireFox 2 OK Windows FireFox 3 OK Windows Chrome 2 OK Windows Safari 3 OK Linux FireFox 2 OK Linux FireFox 3 OK

5.4 總結

由測試結果發現,本系統的功能多元且架構建全,頁面中的連結都有確實 指到對應之頁面,需要登入的功能也都有判斷使用者的登入狀態才予以執行,並 將登錄資訊由使用者端 cookies 移到伺服器端的 session ,使安全性提升,使 用者無法透過更改 cookies 方式暴力登入網站,而資料庫在密碼方面也做加密 處理,管理者也無法得知會員的密碼。 系統在各瀏覽器上皆能表現無誤,使用者可以使用自己熟悉的瀏覽器來使 用本系統所有的功能。經過壓力測試,分散式架構下的系統承載力可達每秒 500 人同時上線,頁面傳輸僅需 1 秒反應時間,系統負載力足以滿足多方使用者需求。

(67)

第 6章 結論與未來展望

6.1 結論

本論文參考李[1]「Web 2.0 多媒體旅遊導覽系統」,在功能與介面上做改善, 擴展成為「Web 2.0 多功能媒體展示系統」,讓網友分享的影片不僅止是旅遊類 型之影片,更可以是播放教學影片的平台,並整合各版面資訊,將影片的相關資 料與使用者討論內容,在觀看時呈現。 透過 Web 2.0 網友之間的評論建議機制,網站可以自我成長,收集資料,提 供更豐富且正確的資訊,吸引更多人參與,而本系統優點在於: (1)將豐富資訊整合於操作簡單的多能資訊展示窗,不會造成為了瀏覽資訊 而在影片與資訊間頻繁捲動頁面之困擾。 (2)提供教學影片播放平台所需要的功能,可以使分享者從眾多瀏者所提供 的討論評語得到鼓勵,分享更多的教學資源。 (3)將運作在單一機器龐大的系統依功能分割,組成分散式系統架構,可以 同時間承受 500 個使用者同時上線發出 request。 (4)建立靜態地圖快取機制,改善影片播放時延遲的現象,景點資訊更換時, 不會影響到影片的播放。

(68)

6.2 未來展望

目前系統中的景點需要人工定位,未來可以找尋自動或半自動化的方法,減 輕人力負擔,本實驗室曾坤隆同學「影音媒體之建築物圖像偵測」之研究,利用 圖像比對之方法,達到自動化定位之目的,並有不錯的研究成果。除了利用圖像 外,還可以使用影片聲音、字幕搭配一套有組織的關鍵字詞比對系統,達到自動 定位目的。 本系統主要提供影片結合地圖之服務,讓使用者觀看影片時能迅速知道景點 位置,若將此系統移植至移動式裝置,使用者可以隨時隨地觀看,並了解在地資 訊,更能展現本系統長處,將在6.3節分析說明。 現在 Web 2.0 講求開放精神,利用已有系統開發新型態網站,如本系統使 用 Google Maps 的地圖系統,整合影片與地圖、相關資訊等而成,調用這些資 源需要開放出 API 並遵尋 API 所定之規範使用,未來本系統也可以開放一些 API 給廣大的使用者使用,除了可以增加知名度外,更可以研究網站資源被使用 的情形做分析,這需要一套設計良好的 API 架構,記錄每個調用事件觸發的網 址 與 取 用 之 資 源 , 找 出 這 些 API 在 被 調 用 時 有 用 的 資 訊 , 也 需 要 解 決 JavaScript 不能跨網域之問題。

6.3 移動式影音展示裝置

移動式影音展示裝置,廣義的定義為有網路功能,並可以隨身攜帶的行動 裝 置 , 包 含 智 慧 型 手 機 (Smart Phone) 、 個 人 數 位 助 理 (Personal Digital Assistant, PDA)、超小型行動電腦 (Ultra Mobile PC, UMPC)、行動聯網裝置 (Mobile Internet Device, MID) 、 網 路 型 筆 記 型 電 腦 (Network-linkable notebook , Netbook)、筆記型電腦 (Notebook)、車載電腦 (CarPC) 等,功能 強調行動運算與續航力,因此效能方面較一般個人電腦差。

(69)

6.3.1 移動式裝置優點

相較於桌上型個人電腦,移動式裝置最大的優點就是裝置設計成可以隨身攜 帶,能提供所在地點資訊且部分配有機體感應裝置與觸控式面版,其講求的是行 動力,將本系統移植到移動式裝置有下列優點: (1)得到使用者目前的坐標資訊,使用者可以隨時隨地使用,創造更多樣化 功能的應用。 (2)搭配機體感應,可以有更多使用者狀態,系統可以針對這些偵測做出更 互動的介面。

6.3.2 面臨之挑戰

雖然結合移動式裝置可以有許多桌上型電腦無法到成的優點,但欲將本系統 在移動式裝置播放有以下困難需要克服: (1)畫面小 移動式裝置為了攜帶方便與長時間待機,通常畫面都比一般桌上型電腦 所配的螢幕小,解析度也較低,因此本系統的版面配置不適合在移動式 裝置展示,需要再研究如何在使用者觀看影片時,提供相關資訊,又不 影響影片觀賞,此外小解析度的畫面,只需提供小解析度的影片即可, 不必花費大量頻寬在影片傳輸上。 (2)畫面大小不一 移動裝置的展示面版,因設計給不同定位的使用者使用,因此畫面大 小、解析度不一,系統需要隨時偵測使用者裝置所能展示的畫面,並動 態的調整展示方式。 (3)機體動態感應偵測 新一代的移動式裝置強調與使用者的互動如:iPhone 、 HTC Phone 等, 都配有陀螺儀 (Gyroscopes) 可以動態偵測機體狀態,並提供多點觸碰

(70)

(multi-touch) 功能,如何取得這些機體資訊,並在本系統中展現出 來,提供更良好的互動介面。 (4)定位資訊取得 本系統在移動式裝置執行最大好處是結合移動式裝置所在之位置,讓使 用者立即知到目前的資訊,少數裝置提供精確 (Global Positioning System , GPS) 定位,但大都可以透過基地台三角定位 (LLC) ,取得 經緯度資訊。 (5)電池續航力 移動式裝置通常是透過電池做為電力來源,為了更長時使用,系統應該 要不影響使用者下精簡程式,或是使用對處理器更為輕量的影片編碼方 式,做為影片傳輸至移動式裝置之串流。

數據

圖 1-1 交通大學開放式課程頁面
圖 2-1 Google Maps 台灣首頁
圖 2-2 YouTube 台灣首頁
圖 2-3 傳統網頁技術與 AJAX 技術資料傳輸方式
+7

參考文獻

相關文件

Valor acrescentado bruto : Receitas do jogo e dos serviços relacionados menos compras de bens e serviços para venda, menos comissões pagas menos despesas de

Given proxies, find the optimal placement of the proxies in the network, such that the overall access cost(including both read and update costs) is minimized.. For an

2.熟 悉 Microsoft Windows Server 作 業 系 統 、 Microsoft SQL Server 資料庫伺服器及網 頁伺服器等環境。. 3.具撰寫 JAVA

(A)因為用 Terminal Services 可以不用安裝 ERP 的程式在 Client 端上可以減少 MIS 維護系 統的時間(B)沒有防毒軟體 (C)建置防火牆的系統 (D) APP-Server 與 DB

Client: Angular 、 Cordova Server: Node.js(Express) 資料庫: MySQL. 套件管理: Node Package

例如 : http ( 網頁伺服器所用的協定 ) 定義了 client 如何向 server request 網頁及 server 如何 將網頁及其中的各種內容回傳給 client 。. 提供服務給 application layer

2.TURN Server generates and sends Allocate Response

1) Ensure that you have received a password from the Indicators Section. 2) Ensure that the system clock of the ESDA server is properly set up. 3) Ensure that the ESDA server