多媒體文件自動生成系統的設計

季聿階，張忠能

0 引言

隨著網絡以及多媒體技術的快速發展，在日常生活中，隨處可以看見大大小小的LED大屏幕，無時無刻地播放著各種各樣的多媒體節目。

論文重點研究了多媒體節目的表現形式，對當前市場上面比較流行的一款多媒體播放軟件進行升級開發，其核心是將所有需要展示的素材文件（包括視頻、圖片、文字等）通過組合的形式拼裝成一系列的頁面文件，通過網絡的方式傳輸到各個播放終端上面,最后在播放終端的瀏覽器上播放。用戶可以根據不同的模板生成不同樣式的播放文件。此外，還增加了對外的Web Service接口，允許其他應用程序調用其開放的 API來自動生成可以播放的多媒體文件，并定時下發到各個播放終端予以播放，大為縮短了多媒體文件的生成時間以及播放效率。

1 多媒體文件的自動生成

通過該系統，用戶看到的多媒體節目是多個視頻、圖片、文字以任意方式組合，再以任意順序播放而成的節目。

論文中的多媒體文件主要分兩個層級：Unit（單元）和Program（節目）。Unit實為模板文件，每一個 Unit里面都可以包含多個視頻、圖片或多段文字信息。其中，視頻可以根據播放列表，循環播放；圖片可以根據設定的時間間隔，不斷地切換；文字則可以以走馬燈的形式滾動播出。Program是控制Unit的頂層邏輯，通過控制每一個Unit的播放順序以及播放時間，以達到不同模板定時切換的效果。

論文中自動生成多媒體文件的過程是系統自動編寫Unit和Program的過程。系統首先讀取用戶設計的節目樣式配置文件，將其中需要使用到的所有素材文件（視頻、圖片、文字等）分別發送到指定終端上面，再根據頁面的編寫規則自動生成相應的HTML代碼，繼而將這些文件也一同發送到指定終端，最后在終端上面解析播放。

2 多媒體文件自動生成系統設計與實現

2.1 多媒體文件自動生成系統設計

系統主要分為2大模塊7個子模塊:生成模塊包括讀取節目配置信息、生成標準節目類和生成節目文件，傳輸模塊包括傳輸素材文件、傳輸節目文件、終端素材置換和執行播放，如圖1所示：

圖1 系統整體結構設計

生成模塊主要的任務是讀取用戶的配置信息并生成所有的節目文件。首先，用戶根據想要播放的節目效果先行設計節目樣式，并保存成指定的xml格式，系統會讀取用戶的配置信息并予以解析，從中提取出相應的信息封裝成一個標準的節目類，與此同時，系統會向用戶報告，系統已經接收到節目請求，正在執行節目文件的生成。緊接著，系統就開始根據標準節目類生成節目文件。

傳輸模塊主要的任務是將所有素材文件和節目文件上傳至指定的播放終端，進行播放。首先，用戶會將節目所需的所有素材上傳到服務器的指定目錄下，在生成模塊完成了節目文件的生成工作之后，標準節目類會搜索該節目需要的素材，并將這些素材上傳到指定的播放終端。隨后，待素材傳輸完畢，系統才會將節目文件傳輸至指定的終端。最后，當該節目到達播放時間，系統會將該節目的所有素材文件和節目文件切換到播放目錄之下，執行播放，并報告用戶播放結果。

2.2 多媒體文件自動生成系統實現過程

2.2.1 實現技術：Web Service，FTP與Java多線程技術

Web Service是一套被設計成可以支持機器與機器之間通過網絡互相操作的軟件系統。[1]它有一個被描述成機器可處理格式（通常是 WSDL[2]）的接口，其它系統通過使用SOAP[3]消息描述的方式使用Web Service交互。FTP是一個基于 TCP/IP協議簇中的主機與主機間的文件傳輸協議。[4]Java多線程是將一些可同時執行的程序并發進行,大大加快了程序的響應速度[5]。

論文使用Apache Axis2對多媒體文件自動生成系統搭建了一個Web Service[1]的服務器和客戶端，方便云端應用程序對其進行訪問，其調用結構，如圖2所示：

圖2 系統整體調用結構

云端應用程序首先將節目所需的一系列素材文件上傳至系統的數據服務器,然后調用系統開放的Web Service接口,執行生成節目的過程。系統在接收到云端應用程序的請求后，會同時異步回報接收信息成功。在節目播放之后，服務器會發起對云端應用程序的Web Service請求，報告整個節目播放的結果。

2.2.2 讀取節目配置信息

節目配置信息是一個XML文檔，其結構，如圖3所示：

圖3節目配置信息的xml結構

config是根節點，對應Program層級。其id為節目序號；title為節目標題；operType為操作指令；startDate為節目開始的日期；endDate為節目結束的日期；clients為需要播放的終端id；volume為節目的音量；templates為模板列表，該節點下的template節點對應組成節目的Unit層級。其中，id為模板序號；playTime為模板播放的時間；bgColor為模板的背景顏色；fontColor為模板中文字的顏色；positions為不同位置的素材列表，該節點下僅有position這一類子節點。其id為位置序號；type為該位置的素材類型；items為素材列表，該節點下也僅有item這一類子節點。name表示素材的名字；time表示素材播放的時間。

使用JDOM2來解析XML文件，構造成一個Document類：同時，開辟新線程繼續執行后續指定，主線程回報用戶接收信息成功：

2.2.3 生成標準節目類

根據圖3的配置信息，分別構造Program類、Template類、Position類和Item類，將相應的子節點構造成相應的類的字段。

2.2.2小節中解析而得的 Document類已經包含了所有XML的結構信息，所以可以直接從中獲取配置信息。首先，獲得根節點信息：

Program p = newProgram();

Element pElementParent = doc.getRootElement();

接著，按照Item類、Position類、Template類、Program類的順序，利用pElementParent的get方法，獲取所有節點信息，一層一層封裝，最終，獲得一個完整的Program類實例p。

2.2.4 生成節目文件

需要生成的節目文件只有Program和Unit兩類文件。

對于Program，系統將其拆分成三個部分，分別予以生成：

writeProgHead方法會將標準的 HTML頭部信息寫入content參數，其中包括必要的JavaScript包和一些初始化信息，如窗口位置和需要加載的 Unit數量；writeProgMid方法會將每一個需要加載的Unit的id、地址和播放的時間寫入 content參數；writeProgTail方法會將整個節目播放的起止時間、進入Unit的入口函數以及HTML的結束標記寫入content參數。最終，content輸出成一個Program文件。

對于Unit，系統會分別針對不同的模板進行改寫，予以生成，目前，系統中比較常用的兩個模板分別是圖片文字模板和視頻文字模板：

系統內置了圖片、視頻和文字三個模塊的HTML組件代碼，這些代碼是由人工手動編寫而成的。updatePicUnit方法和updateMovUnit方法會分別選擇相應的代碼予以拼接，修改字體和背景顏色，以及視頻的音量等信息，最終生成一個新的Unit文件。

2.2.5 傳輸文件

傳輸文件分為傳輸素材文件和傳輸節目文件兩種，均通過 FTP傳輸，即傳輸方式相同，但其傳輸時機不同：素材文件占用空間可能過大，無法與節目播放同時傳輸，因此必須提前進行傳輸；而節目文件非常小，只需要在節目需要播放之前傳輸即可。

2.2.6 終端素材置換與執行播放

當節目需要播放時，播放終端會將節目所需要的素材文件全部轉移至終端的播放目錄下，再將原始播放目錄下的素材文件清空，并執行節目的播放。播放命令完成后，服務器會通過Web Service調用回報用戶播放結果。

3 技術難點及解決方案

論文在實現系統的過程中，碰到了很多技術難點，對應的解決方案，如表1所示：

表1 技術難點及解決方案

3.1 同一模板連續播放多個視頻的處理

系統對于上傳的視頻文件，只會默認播放第一個視頻，當用戶在一個 Unit上播放多個視頻時，就會產生問題。解決方案是創建一個.asx格式的播放列表文件，每次需要播放視頻時，就會去讀取相應的.asx文件，按照其中的視頻列表，逐個播放。其中，播放列表的.asx文件的XML結構，如圖4所示：

圖4 播放列表文件的xml結構

3.2 Web Service連接超時的處理

在使用Apache Axis2搭建Web Service服務器和客戶端時，若傳輸素材文件過大，會導致傳輸時間過長的問題，從而導致服務器超時，連接中斷。解決方案是在Axis2的配置文件中，對服務器的連接時間進行設置，默認值為30秒，考慮到實際情況，實際傳輸過程可能會非常長，所以這里盡可能的將該值調大。

另一方面，在Web Service調用過程中，將其異步化也是解決超時的一個辦法：

最后服務器sender發出Web Service指令后，直接采取忽略結果的措施，而不是掛起等待返回結果。相當于異步通訊，加快響應速度。

3.3 遠程登錄播放終端讀寫權限的處理

系統的播放終端運行Linux操作系統，因此，在使用Java遠程進行文件夾創建時，無法獲取寫入權限，從而導致后續素材文件傳輸的失敗。解決方案是，取消遠程新建文件夾的方法，直接改用FTP來新建，并修改FTP的傳輸模式，使之能夠在Linux下獲取全部權限，以使得傳輸素材文件能夠順利進行。

3.4 異常處理

系統在進行節目文件生成的過程中盡可能多地考慮了可能出現的異常情況，并進行了異常處理，如表2所示：

表2 異常處理

將發生異常的信息用String進行描述，添加進報告用戶的message信息中，一旦發生異常，系統即認為對指定終端的操作為失敗，報告會立即發出。

4 應用與應用效果分析

根據對多媒體文件自動生成系統的研究與設計，已實現完整的應用系統并投入使用，并對該系統的運行情況和應用效果進行分析。

4.1 多媒體文件自動生成系統應用實例

根據對多媒體文件自動生成系統的研究與設計，自主研發的多媒體文件自動生成接口，已經在上海市移動營業廳的部分網點進行測試性使用。

運行多媒體文件自動生成系統，至少需要一臺服務器與一臺播放終端，服務器上需要安裝Apache Tomcat服務器與Apache Axis2 Tools，播放終端僅僅需要聯網并擁有基本的Firefox瀏覽器即可。多媒體文件自動生成系統需要通過Apache Axis2 Tools – Service Archive Wizard 將源代碼生成可以在Apache Axis2的Web Service服務器上運行的.aar文件。

通過Web Service服務調用，將素材文件和節目傳輸至播放終端進行節目播放后，圖片模板，如圖5所示：

圖5 圖片模板

4.2 應用效果分析

通過實際使用，該系統運行良好。在開發測試內網環境（100Mbps帶寬網絡）下，傳輸一個帶有200Mbps的視頻的節目的平均響應時間為30秒，其理論傳輸最快時間為16秒，考慮實際傳輸速率達不到理想情況和處理其他邏輯的時間損耗，30秒的響應時間處于可以接受的范圍之內。在營業廳測試環境（營業廳帶寬2Mbps-30Mbps不等，機房帶寬10Mbps）下，目前運行 1個月沒有出現問題。該系統容錯能力強，在多個營業廳傳輸數據過程中，如果有一個沒有傳輸完成而中斷，后續指令只需要對這一個沒有傳輸成功的營業廳進行發布，不需要全部重新傳輸，在實際測試應用中大大提高了工作的效率。

5 結束語

針對不同的播放節目需求，設計不同樣式的模板，對不同模板進行頁面生成，再按照配置文件分別進行頁面重組。通過終端素材調度算法，管理播放終端的素材文件，判斷各個節目所需要的素材是否齊備，若沒有被任何節目引用，則調用素材管理的垃圾回收機制進行刪除，節約播放終端的磁盤空間。對生成節目文件中間產生的各種異常進行處理，并及時反饋用戶，大大提高了系統的容錯能力。在實際測試和使用過程中，提高了工作效率，具備良好的實際應用價值。

[1]Haas H,Brown A.Web services glossary[J].W3C Working Group Note (11 February 2004),2004.

[2]Christensen E,Curbera F,Meredith G,et al.Web services description [J].language (WSDL)1.12001.

[3]Gudgin M,Hadley M,Mendelsohn N,et al.SOAP Version 1.2[J].W3C recommendation,2003,24.

[4]Forouzan B A.TCP/IP protocol suite[M].McGraw-Hill,Inc.,2002.

[5]Eckel B.Thinking in JAVA[M].Prentice Hall PTR,2003.