《視頻收錄在線生產(chǎn)系統(tǒng)的研究和實現(xiàn)碩士學位論文》由會員分享，可在線閱讀，更多相關(guān)《視頻收錄在線生產(chǎn)系統(tǒng)的研究和實現(xiàn)碩士學位論文（75頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 碩士學位論文 視頻收錄在線制作系統(tǒng)的研究與實現(xiàn) ?? 66 / 75文檔可自由編輯打印 摘要 目前，國內(nèi)視頻行業(yè)整體規(guī)模正在快速增長階段，隨著在線視頻廣告規(guī)模和用戶數(shù)量的爆發(fā)式增長，國內(nèi)視頻網(wǎng)站數(shù)量隨之暴增，競爭加劇。大量，高質(zhì)，及時的視頻可以帶來大量用戶群，提高流量，潛在的吸引了更多廣告商的投資。因此，如何能夠快速，有效地處理大批量的視頻對一個視頻網(wǎng)站來說至關(guān)重要?；谏鲜鲅芯?，本文構(gòu)造了分布式的、在線的視頻收錄制作系統(tǒng)。具體工作如下： 1）設計了一個分布式視頻收錄在線制作系統(tǒng)OMS總體架構(gòu)，它通過信源錄制機，素材下載機，壓制機的

2、集群部署，在總控中心的調(diào)度下，實現(xiàn)信源錄制，素材下載，壓制多碼流，審核，分發(fā)上片，入庫等一系列流程自動化，一體化的功能，從而減少片子在整個流程中消耗的時間，提高了上片的效率。 2）參與設計并實現(xiàn)了基于該總體架構(gòu)的原型系統(tǒng)，該系統(tǒng)包括制作中心、和總控中心兩個部分，該系統(tǒng)能夠有效減少一條片子從源片到被用戶訪問的時間，具有高效性。 3）設計并實現(xiàn)了OMS和CDN的上片下片接口，OMS與視頻庫BPP的入庫接口，以及該系統(tǒng)的任務日志。通過上下片接口和入庫接口，一定的程度上增加了工作效率。而任務日志提供了詳細的任務狀態(tài)變遷記錄，一方面極大地方便了程序員對工作流程的掌控，提供了對每個用戶的行為監(jiān)控。

3、 關(guān)鍵詞：　OMS，BPP和CDN接口，任務日志 Abstract At present, the overall size of the domestic video industry is at the rapid growth phase. With the explosive growth of online video ad size and the number of users, the number of domestic video increases rapidly. Large, high-quality, timely videoes can bring

4、a lot of user groups, increase flow, and attract investment of more advertisers potentially. Therefore, how to quickly and effectively deal with large quantities of video on a video site is essential. Based on the above studies, this paper constructs a distributed production system, an online video

5、collection. The followings are specific activities: 1) Have designed a distributed video collection of online production system OMS system. The system is composed of source recording machine, material download machine, pressing machine cluster. The system can record source, download material, review

6、, and distribute records, store a series of process automation integration with the scheduling of the control center.It can reduce the time consumed by the film in the entire process and improve the efficiency. 2) Have involved in the design and realization of a prototype system based on the overall

7、 architecture. The system includes two parts: the production center, and the total control center. The system can effectively reduce the user access time to the source film, which is highly efficient. 3) Have designed and implemented OMS and CDN showings interface, storage interface for the OMS ,vid

8、eo library BPP, and the task log. With the Upper Piece and Lower Piece interfaces and storage interfaces, the system can increase a certain degree of work efficiency. The task log provides a detailed task status and changes, which greatly facilitates the programmer access to the control of the workf

9、low and monitors each user's behavior. Keywords：　OMS,BPP and CDN interface,inventory log 目錄 摘要 i Abstract ii 第1章 緒論 1 1.1 課題背景 1 1.1.1 分布式系統(tǒng) 2 1.1.2 視頻壓制技術(shù) 3 1.1.3 視頻轉(zhuǎn)碼技術(shù) 12 1.1.4 Html5技術(shù) 15 1.1.5 SSH框架 16 1.2　研究內(nèi)容 20 1.3　研究目標 21 1.4　本文結(jié)構(gòu)組織 21 1.5　本章小結(jié) 21 第2章 OMS的總體

10、架構(gòu) 22 2.1 引言 22 2.2 總體架構(gòu) 22 2.2.1 素材收錄渠道 24 2.2.2 壓制服務 24 2.2.3 系統(tǒng)交互 24 2.3 傳輸協(xié)議 25 2.3.1 PHPRPC 25 2.3.2 thrift 25 2.4 本章小結(jié) 26 第3章 OMS的詳細設計 27 3.1　總控中心的分層結(jié)構(gòu) 27 3.2　模塊間交互工作時序 27 3.3　產(chǎn)品總體流程設計 29 3.3.1　產(chǎn)品業(yè)務流程設計 29 3.3.2　產(chǎn)品技術(shù)流程設計 29 3.3.3　在線制作系統(tǒng)工作流程 30 3.4　產(chǎn)品功能設計 31 3.4.1　信源收錄模塊 31 3

11、.4.2　數(shù)字版權(quán)上傳模塊 32 3.4.3　素材查詢模塊 32 3.4.4　素材查詢模塊 33 3.4.5　視頻快編模塊（任務查看） 33 3.4.6　任務管理模塊 34 3.4.7　審核管理模塊 36 3.4.8　設置管理模塊 38 3.4.9　用戶管理 41 3.4.10　設置管理模塊 44 第4章 上下片接口 45 4.1 引言 45 4.2　接口觸發(fā)方式 45 4.3　定時任務 46 4.3.1　Scheduler 46 4.3.2　Quartz 46 4.4　上下片接口的XML 47 4.4.1　上片接口的請求XML和返回XML 47 4.4.2　

12、下片接口的請求XML和返回XML 48 4.5　XML解析方式及實現(xiàn) 49 4.5.1　xmlbeans 49 4.5.2　dom4j 51 4.5.3　dom 51 4.5.4　解析方式優(yōu)缺點 51 4.5.5　下片接口的設計 51 4.5.6　回調(diào)接口callback的實現(xiàn) 52 4.6　本章小結(jié) 54 第5章 媒資EPG輸出接口 55 5.1 引言 55 5.2 pull方式 55 5.3　push方式 57 5.4　本章小結(jié) 60 第6章 任務日志 61 6.1 引言 61 6.2 迷你日志 61 6.3 詳細日志 61 6.4 本章小結(jié) 62 第

13、7章 總結(jié)與展望 63 7.1　本文完成的主要研究工作 63 7.2　本文的主要貢獻和創(chuàng)新點 63 7.3　進一步的研究工作 64 參考文獻 65 作者簡歷 66 致謝 67 圖目錄 圖2. 1視頻收錄在線制作系統(tǒng)總體架構(gòu)圖 23 圖2. 2 PHPRPC遠程調(diào)用示意圖 25 圖2. 3Thrift遠程調(diào)用示意圖 26 圖3. 1總控中心的分層結(jié)構(gòu)圖 27 圖3. 2模塊架構(gòu)時序圖 28 圖3. 3媒資平臺業(yè)務流程圖 29 圖3. 4媒資平臺產(chǎn)品技術(shù)流程圖 30 圖3. 5在線制作系統(tǒng)工作流程圖 30 圖3. 6在線制作系統(tǒng)產(chǎn)品功能模塊圖 31 圖3.

14、 7素材查詢模塊圖 32 圖3. 8視頻編輯模塊圖 33 圖3. 9 任務列表圖 34 圖3. 10任務列表圖 36 圖3. 11視頻審核界面圖 37 圖3. 12 視頻審核彈窗圖 38 圖3. 13 常態(tài)欄目設置圖 38 圖3. 14常態(tài)欄目修改界面 39 圖3. 15信源頻道設置界面 39 圖3. 16新增/修改信源頻道界面 40 圖3. 17 輸出策略設置圖 40 圖3. 18 賬戶列表界面圖 41 圖3. 19賬戶列表編輯界面 41 圖3. 20 新增、編輯、刪除角色界面圖 42 圖3. 21角色查看頁面圖 43 圖3. 22 常態(tài)欄目設置圖 44 圖4

15、. 1 CDN上片接口流程圖 47 圖4. 2 CDN下片接口流程圖 52 圖4. 3 CDN callback接口流程圖 53 圖5. 1 BPP pull 接口流程圖 57 圖5. 2 BPP push接口流程圖 60 圖6. 1迷你日志 61 圖6. 2詳細日志 62 表目錄 表 1. 1視頻壓縮錄像存儲量對比表 10 表 1. 2視頻顯示及圖像傳輸對比表 10 表 1. 3 MPE1、MPEG4、H.263測試對比表 11 表 1. 4 Struts與MVC對比表 16 表3. 1狀態(tài)與操作關(guān)系 35 表3. 2任務狀態(tài)與子文件狀態(tài)關(guān)系表 35 表5

16、. 1 OMS輸出接口字段說明 55 表5. 2 OMS push接口字段說明 58 表5. 3 OMS push接口返回errorcode說明 59 第1章 緒論 1.1 課題背景 視頻網(wǎng)站是指在完善的技術(shù)平臺支持下，讓互聯(lián)網(wǎng)用戶在線流暢發(fā)布、瀏覽和分享視頻作品。除了傳統(tǒng)的對視頻網(wǎng)站的理解外，近年來，無論是P2P直播網(wǎng)站，BT下載站，還是本地視頻播放軟件，還將向影視點播擴展作為自己的一塊戰(zhàn)略要地。影視點播已經(jīng)成為各類網(wǎng)絡視頻運營商的兵家必爭之地[1]。麥肯錫一項新的研究表明，未來4年，中國將有超過7億人觀看網(wǎng)絡視頻[2]。中國網(wǎng)絡視頻市場正在飛速發(fā)展，目前，國內(nèi)視頻行業(yè)整體規(guī)模

17、正在快速增長階段，隨著網(wǎng)站內(nèi)容的增加，隨著在線視頻廣告規(guī)模和用戶數(shù)量的爆發(fā)式增長，國內(nèi)視頻網(wǎng)站數(shù)量隨之暴增，競爭加劇。大量，高質(zhì)，實時的視頻可以帶來大量用戶群，提高流量，潛在的吸引了更多廣告商的投資。因此，如何能夠快速，有效地處理大批量的視頻對一個視頻網(wǎng)站來說至關(guān)重要。 一個視頻網(wǎng)站涉及的視頻內(nèi)容多樣，有電影，電視劇，短片，長視頻，格式繁多，MP4，flv等，有些視頻格式不被網(wǎng)站的播放器支持，于是，如何管理和制作這些視頻，以滿足網(wǎng)站用戶的需求，如何提高視頻的制作效率，讓視頻制作人員快速，高效，準確的操作成為一個突破點。 而目前國內(nèi)的視頻行業(yè)，大多數(shù)采用多個系統(tǒng)分別制作最后整合的現(xiàn)狀。如有一

18、個視頻源文件，先要將他手動拷到源片庫，當制作人員需要制作視頻時，再將他從源片庫拷到臨時文件夾進行制作，剪切時間段，模糊遮標，打上特有l(wèi)ogo，然后拷到壓片機去壓片，當壓片成功時，相關(guān)人員將壓好的成片拷出來，放到成片庫，審核人員再從成片庫拿出成片進行觀看審核。如此，編輯和審核人員將大量的時間放在拷貝視頻上，也無法進行流水線操作，工作效率很低，拷貝過程中也很容易發(fā)生數(shù)據(jù)丟失等情況。 綜上所述，建立一個分布式的，實時的，具有高吞吐量和高并發(fā)量的分布式在線視頻制作系統(tǒng)具有現(xiàn)實的理論意義和廣闊的應用前景，但因行業(yè)需求的快速變化，使得這一系統(tǒng)的實現(xiàn)面臨不小的挑戰(zhàn)。 1.1.1 分布式系統(tǒng) 在一個分

19、布式系統(tǒng)中，一組獨立的計算機展現(xiàn)給用戶的是一個統(tǒng)一的整體，就好像是一個系統(tǒng)似的。系統(tǒng)擁有多種通用的物理和邏輯資源，可以動態(tài)的分配任務，分散的物理和邏輯資源通過計算機網(wǎng)絡實現(xiàn)信息交換。系統(tǒng)中存在一個以全局的方式管理計算機資源的分布式操作系統(tǒng)。通常，對用戶來說，分布式系統(tǒng)只有一個模型或范型[3]。在操作系統(tǒng)之上有一層軟件中間件（middleware）負責實現(xiàn)這個模型。一個著名的分布式系統(tǒng)的例子是萬維網(wǎng)（World Wide Web），在萬維網(wǎng)中，所有的一切看起來就好像是一個文檔（Web 頁面）一樣。 在計算機網(wǎng)絡中，這種統(tǒng)一性、模型以及其中的軟件都不存在。用戶看到的是實際的機器，計算機網(wǎng)絡并沒有

20、使這些機器看起來是統(tǒng)一的。如果這些機器有不同的硬件或者不同的操作系統(tǒng)，那么，這些差異對于用戶來說都是完全可見的。如果一個用戶希望在一臺遠程機器上運行一個程序，那么，他必須登陸到遠程機器上，然后在那臺機器上運行該程序。 分布式系統(tǒng)和計算機網(wǎng)絡系統(tǒng)的共同點是：多數(shù)分布式系統(tǒng)是建立在計算機網(wǎng)絡之上的，所以分布式系統(tǒng)與計算機網(wǎng)絡在物理結(jié)構(gòu)上是基本相同的。 他們的區(qū)別在于：分布式操作系統(tǒng)的設計思想和網(wǎng)絡操作系統(tǒng)是不同的，這決定了他們在結(jié)構(gòu)、工作方式和功能上也不同。網(wǎng)絡操作系統(tǒng)要求網(wǎng)絡用戶在使用網(wǎng)絡資源時首先必須了解網(wǎng)絡資源，網(wǎng)絡用戶必須知道網(wǎng)絡中各個計算機的功能與配置、軟件資源、網(wǎng)絡文件結(jié)構(gòu)等情

21、況，在網(wǎng)絡中如果用戶要讀一個共享文件時，用戶必須知道這個文件放在哪一臺計算機的哪一個目錄下；分布式操作系統(tǒng)是以全局方式管理系統(tǒng)資源的，它可以為用戶任意調(diào)度網(wǎng)絡資源，并且調(diào)度過程是“透明”的。當用戶提交一個作業(yè)時，分布式操作系統(tǒng)能夠根據(jù)需要在系統(tǒng)中選擇最合適的處理器，將用戶的作業(yè)提交到該處理程序，在處理器完成作業(yè)后，將結(jié)果傳給用戶。在這個過程中，用戶并不會意識到有多個處理器的存在，這個系統(tǒng)就像是一個處理器一樣[4]。 許多應用是固有分布式的。這些應用是突發(fā)模式而非批量模式。這方面的實例有事務處理和Internet程序。這些應用的性能取決于吞吐量（事務響應時陽J或每秒完成的事務數(shù)）而不是一般多處

22、理機所用的執(zhí)行時間。對于一組用戶而言，分布式系統(tǒng)有一個特別的應用稱為計算機支持的協(xié)同工作或群件，支持用戶協(xié)同工作。另一個應用是分布式會議， 即通過物理的分布式網(wǎng)絡進行電子會議。同樣，多媒體遠程教學也是一個類似的應用。 由于在不同的平臺上如：Pc、工作站、局域網(wǎng)和廣域網(wǎng)上可獲得非常多樣的應用，用戶希望能超出他的限制以獲得更廣泛的功能和性能。不同網(wǎng)絡和環(huán)境（包括分布式系統(tǒng)環(huán)境）下的操作性變得越來越重要。為了達到互操作性，用戶需要一個標準的分布式計算環(huán)境，在這個環(huán)境里，所有系統(tǒng)和資源都可用。 DCE（分布式計算環(huán)境）是OSF（開放系統(tǒng)基金會）開發(fā)的分布式計算技術(shù)的工業(yè)標準集。它提供保護和控制對

23、數(shù)據(jù)訪問的安全服務、容易尋找分布式資源的名字服務、以及高度可伸縮的模型用于組織極為分散的用戶、服務和數(shù)據(jù)。D C E可在所有主要的計算平臺上運行， 并設計成支持異型硬件和軟件環(huán)境下的分布式應用[5]。 DCE已經(jīng)被包括TRANSVARL在內(nèi)的一些r一商實現(xiàn)。TRANSVARL是最早的多廠商組（multi vendor team）的成員之一，它提出的建議已成為DCE體系結(jié)構(gòu)的基礎(chǔ)。在中可以找到利用DCE開發(fā)分布式應用的指南。具有標準接口和協(xié)議的系統(tǒng)也叫做開放系統(tǒng)。 一些其它標準基于一個特別的模型，比如CORBA（公用對象請求代理程序體系結(jié)構(gòu)），它是由OMG （對象管理組）和多計算機廠商聯(lián)盟開

24、發(fā)的一個標準。CORBA使用面向?qū)ο竽Ｐ蛯崿F(xiàn)分布式系統(tǒng)中的透明服務請求。 工業(yè)界有自己的標準，比如微軟的分布式構(gòu)件對象模型（DCOM）和Sun Microsystem公司的Java Beans[6]。 1.1.2 視頻壓制技術(shù) 視頻壓縮技術(shù)用于錄像資料收集、整理、儲存，高性能的視頻壓縮技術(shù)甚至用于遠程視頻網(wǎng)絡傳輸，因此，在安防監(jiān)控市場DVR（數(shù)字化硬盤錄像監(jiān)控）技術(shù)中，成為先進的數(shù)字化網(wǎng)絡監(jiān)控，不論是在監(jiān)視、錄像存儲、畫面檢索、網(wǎng)絡傳輸、信息安全保密以及控制技術(shù)方面相比傳統(tǒng)的模擬監(jiān)控技術(shù)，大大提高了視頻監(jiān)控領(lǐng)域的效率[7]。 隨著有線電視網(wǎng)絡的發(fā)展、視頻壓縮技術(shù)還在節(jié)目采集、制作、播出

25、及存儲過程中的大量使用,新的電視業(yè)務(如視頻點播、準視頻點播)已經(jīng)實現(xiàn),人們可以隨時調(diào)看想看的電視節(jié)目和錄像片。 目前，市面上DVR產(chǎn)品使用的視頻壓縮算法主要有： MOTION-JPEG；小波Engine-k；MPEG 即（MPEG-1；MPEG-2；MPEG-4）；H.26X 即（H.261;;H.263;以及H.264）； 下面我們將幾種壓縮算法簡單的介紹一下，供大家學習參考： 一、JPEG/MOTION-JPEG（動態(tài)JPEG） 極少數(shù)DVR廠商采用JPEG壓縮技術(shù)，大多采用MJPEG（Motion- JPEG） 壓縮技術(shù)，它主要特點是基本不考慮視頻流中不同幀之間的變化，只單獨

26、對某一幀進行壓縮。目前的基于該技術(shù)的視頻卡也主要是完成數(shù)字視頻捕獲（Capture） 功能，在后臺由CPU或?qū)ｉT的JPEG芯片完成壓縮工作，也就是我們常說的軟壓縮。 JPEG/MJPEG壓縮技術(shù)可以獲取清晰度很高的視頻圖像、而且可以靈活設置每路視頻清晰度、壓縮幀數(shù)，但付出的代價是在保證每路都高清晰度的情況下，受處理速度限制，無法完成實壓縮，有很強的丟幀現(xiàn)象，同時由于沒有考慮到幀間變化，造成大量冗余信息被重復存儲，因此單幀視頻的占用較大，目前流行的MJPEG技術(shù)最好的也只能做到3K/幀，通常要8?20K！簡單計算可以發(fā)現(xiàn)即使是丟幀錄像，也將耗費大量的硬盤空間，尤其在保安監(jiān)控領(lǐng)域，由于監(jiān)控攝像機

27、較多（16路通常），同時進行高清晰度錄像，保證一個月的錄像存儲量是比較大的[8]。 二、小波變換（WAVELET） 壓縮比50-70，分辨率可達到720*576，對靜態(tài)畫面處理較好。和MOTION-JPEG類似，所占用的帶寬和硬盤空間仍然較大，網(wǎng)絡傳輸要求仍然較高。 三、MPEG MPEG是Movyig pictures experts group(運動圖像專家組)的英文縮寫，這個專家組始建于1988年，專門負責為CD建立視頻和音頻標準，其成員均為視頻、音頻及系統(tǒng)領(lǐng)域的技術(shù)專家。MPEG是ISO/IEC/JTC/SC2/WG11的一個小組。它的工作兼顧了JPEG標準和CCITT專家組的

28、H261標準，于1990年形成了一個標準草案。 MPEG標準分成三個階段：第一階段（MPEG—1）是針對傳輸速度為1MP/s到1.5Mb的普通電視質(zhì)量的視頻信號的壓縮；第二個階段目標則是對每秒30幀的720*576分辨率的視頻信號進行壓縮，在擴展模式下，（MPEG-2）可以對分辨率達成1440*1152高清晰度電視（HDTV）的信號進行壓縮。第三階段，直到為了繼續(xù)解決傳輸碼流和壓縮質(zhì)量發(fā)展到現(xiàn)在應用較多的 （MPEG-4）。因為，在一開始它就是作為一個國際化的標準來研究制定，所以MPEG具有很好的兼容性；其次，MPEG能夠比其他算法提供更好的壓縮比，最高可達200：1；更重要的是，MPEG在

29、提供高壓縮比的同時，對數(shù)據(jù)的損失很小。 MPEG算法除了對單幅圖像進行編碼外，還利用圖像序列的相關(guān)特性去除幀間圖像冗余，大大提高了視頻圖像的壓縮比，在保持較好的圖像視覺效果的前提下，壓縮比可以達到60-100倍左右。MPEG壓縮算法復雜、計算量大，其實現(xiàn)一般要專門的硬件支持。 MPEG標準有三個組成部分：MPEG視頻；MPEG音頻；視頻與音頻的同步。MPEG視頻是MPEG標準的核心。為滿足高壓縮比和隨時機訪問兩方面的要求，MPEG采用預測和插補兩種幀間編碼技術(shù)。MPEG視頻壓縮算法中包含兩種基本技術(shù)：一種是基于16*16子塊的運動補償，用來減少幀序列的空域冗余，在幀內(nèi)壓縮及幀間預測中均使用

30、了DCT變換。運動補償算法是當前視頻圖像壓縮技術(shù)中使用最普遍的方法之一。 MPEG-1 制定于1992年，為工業(yè)級標準的設計，可適合于不同帶寬的設備，如CD-ROM、Video-CD、CD-I。它可針對SIF標準分辨（對于NTSC制為325*240；對于PAL制為325*288）的圖像進行壓縮，傳輸速率為1.5Mbits/sec,每秒播放30(25)幀,具有CD(指激光唱盤)音質(zhì),圖像質(zhì)量級別基本與VHS相當。MPEG 的編碼速率最高可達4-5Mbits/sec，但隨著速率的提高，其解碼后的圖像質(zhì)量有所降低。MPEG-1也被用于數(shù)字電話網(wǎng)絡上的視頻傳輸，如非對稱數(shù)字用戶線路（ADSL），視

31、頻點播（VOD），以及教育網(wǎng)絡等。同時，MPEG-1也可被用做記錄媒體或是在INTERNET上傳輸音頻。 MPEG在DVR系統(tǒng)中應用 MPEG1實時視頻壓縮技術(shù)是目前市場DVR產(chǎn)品主流。較MJPEG技術(shù)，MPEG1在實時壓縮、每幀數(shù)據(jù)量、處理速度上有顯著的提高。例如在國內(nèi)PAL制式下，NPDG1可以滿足多路25幀/秒的壓縮（>16路）速度，在500kbit/sec壓縮碼流（352*288）下，每幀大小僅為2k，簡單計算可以表明，MPEG1產(chǎn)品的錄像容量是目前硬盤容量可以接受的（16路以下）。 目前國內(nèi)DVR廠商MPEG1產(chǎn)品基本都采用以色列Zapex 或臺灣Winbond公司的壓縮芯片

32、，通過硬件壓縮技術(shù)可以有效降低計算機負擔，解決多路視頻同時錄像計算機資源有限的問題[9]。 MPEG1也有較多不利地方，其一是存儲量，通常需要8個80硬盤，或更多，硬盤投資大，而由此引起的硬盤故障和維護更是叫人頭疼；其二是清晰度不夠高，由于MPEG1最大清晰度僅次352*288，考慮到容量、模擬/數(shù)字量化損失等其他因素，回放清晰度不高，這也是市場反應的主要問題；其三是不夠靈活，只能25幀/秒，不能夠丟幀錄像，從目前廣泛采用的壓縮芯片來看，也缺乏有效的調(diào)控手段，例如關(guān)鍵幀設計、取樣區(qū)域設定等等，造成在保安監(jiān)控領(lǐng)域應用不適合，造價也高?；腗PEG1由于數(shù)據(jù)量大，不適合網(wǎng)絡傳輸，尤其是在常用的低

33、帶寬網(wǎng)絡上無法實現(xiàn)過程視頻傳輸。 MPEG-2： MPEG-2制定于1994年，設計目標是高級工業(yè)標準的圖像質(zhì)量以及更高的傳輸率。MPEG-2所能提供的傳輸率在3-10Mbits/sec間，其在NTSC制式下的分辨率可達720*480，MPEG-2也可以提供廣播級的視像和CD級的音質(zhì)。MPEG-2R 的音頻編可提供左右中及兩個環(huán)繞聲道，以及一個加重低音聲道，和多達個伴音聲道。 由于MPEG-2在設計時的巧妙處理，使得大多數(shù)MPEG-2解碼器也播放MPEG-1格式的數(shù)據(jù)，如VCD。同時，由于MPEG-2的出色性能表現(xiàn)，已能適用于HDTV，使得原打算為HDTV設計的MPEG-3，還沒出世就被

34、拋棄了。（MPEG-3要求速率在20Mbits/sec-40Mbits/sec間，但這將使畫面有輕度扭曲） 但是它有個致命的缺陷，就是壓縮率較低（40：1），這樣就需要很大的硬盤容量來滿足長時間的錄像存儲。硬盤存儲容量一直都是硬盤錄像主機的瓶頸所在，要想使錄像文件保存的時間更長，就只有增加硬盤容量，但這無疑增加了成本，硬盤數(shù)量增加也會造成系統(tǒng)的不穩(wěn)定，另外，硬盤的散熱也是不容忽視的問題。MPEG-2對于壓縮PAL制25幀/秒的畫面，需要3-10Mbits/s傳輸率，占用如此高的帶寬只能做到在局域網(wǎng)內(nèi)傳輸。 MPEG-2由于要更多的消耗硬盤資源或者網(wǎng)絡帶寬雖然清晰度可以達到DVD畫質(zhì)一般主

35、流廠家未見采用。目前有一種方案將四路視頻信號首先采用原有圖象四分割的模擬方式復合為一路視頻信號經(jīng)MPEG-2的壓縮來實現(xiàn)視頻的A/D的轉(zhuǎn)換，其實是一種比較落后的技術(shù)，而且實測也未見圖象質(zhì)量改善，反而在四幅畫整合為一幅畫面后增加了圖象管理和處理的難度，一些原本很輕易能實現(xiàn)的功能如圖象放大，檢索單幅圖象的調(diào)用等等變得很難操作。 MPEG-2還可以用于為廣播，有線電視網(wǎng)，電纜網(wǎng)絡以及衛(wèi)星直播（Direvt broadcast satellite）提供廣播級的數(shù)字視頻。MPEG-2的另一特點是，可提供一個較廣的范圍改變壓縮比，以適應不同畫面質(zhì)量，存儲容量，以及帶寬的要求。對于最終用戶來說，由于現(xiàn)存電

36、視機分辨率限MPEG-2所帶來的高清晰度畫面質(zhì)量（如DVD兩面）在電視上效果并不明顯，倒是其音頻特性（如加重低音，多伴音聲道等）更引人注目?！? MPEG-4 以上幾種壓縮方式看來，MPEG1與MJPEG壓縮技術(shù)由于技術(shù)成熟，所以DVR開發(fā)廠家的壓縮板卡也較多，是目前DVR市場的主流技術(shù)，但兩者的致命弱點就是硬盤耗費量大，且不能同時滿足保安與實時錄像場合的需要。尤其在硬盤造價已經(jīng)接近DVR整機成本50%情況下，容量與清晰度矛盾更為突出。MPEG4技術(shù)的出現(xiàn)，可以有效解決以上諸多問題。 MPEG4與MPEG1、MPEG2不同。MPEG4于1998年11月公布，原預計1999年1月投入

37、使用的國際標準，MPEG4不僅是針對一定比特率下的視頻、音頻編碼，更加注重多媒體系統(tǒng)的交互性和靈活性。MPEG專家組的專家們正在為MPEEG——4的制定努力工作。MPEG——4標準主要應用于視像電話（Videophone）,視像電子郵件（VideoEmail）和電子新聞（ElectronicNews）等，其傳輸速率要求較低，在4800—64000bits/sec之間，分辨率為176*144。MPEG—4 利用很窄的帶寬，通過幀重建技術(shù)，壓縮和傳輸數(shù)據(jù)，以求以最少的數(shù)據(jù)獲得最佳的圖像質(zhì)量。 與MPEG—1和MPEG—2相比，MPEG—4更適于交互AV服務以及遠程監(jiān)控。MPEG—4是第一個使使

38、用者由被動變?yōu)橹鲃樱ú辉僦皇怯^看，允許你加入其中，即有交互性）的態(tài)圖象標準；它的另一個特點是其綜合性；從根源上說，MPEG—4試圖將自然物體與人造物體相溶合（視覺效果意義上的）。MPEG—4的設計目標還有更廣的適應性和可擴展性。MPEG4試圖達到兩個目標：A、低比特率下的多媒體通信；B、是多工業(yè)的多媒體通信的綜合。據(jù)此目標，MPEG4引入AV對象（Audio/visual objects）, 使得更多的交互操作成為可能。 可見MPEG4壓縮技術(shù)原本是一種適用在低帶寬下進行住處交換的音視頻處理技術(shù)，它的特點是可以動態(tài)的偵測圖像各個區(qū)域變化，基于對象的變化而高速壓縮方法可以獲得比MPEG

39、1更大的壓縮比，壓縮碼流更低。盡管MPEG4并不是專為視頻監(jiān)控壓縮領(lǐng)域而設計，但同樣也適合CIF（352*288）或者更高清晰度（768*576）情況下的視頻壓縮，無論從清晰度還是從存儲量上都比MPEG1具有更大的優(yōu)勢?！? MPEG4在DVR系統(tǒng)中應用 MPEG4在壓縮方法上遠遠優(yōu)于MPEG1，更是MJPEG不能比擬的。MPEG4基于場景描述和面向帶設計的要領(lǐng)使MPEG—4在視頻監(jiān)控錄像領(lǐng)域中在錄像存儲容量、錄像清晰度、錄像幀率可調(diào)、網(wǎng)絡傳輸幾個方面具有巨大的優(yōu)勢?！? 四、H.26X　 H.261 H.261圖像編解碼標準是CCITT(現(xiàn)ITU-T)國際聯(lián)合電信于1990年制定的針對

40、活動圖像的P×64Kbps的編碼協(xié)議。它同MPEG1的區(qū)別在于H.261是傳送屏幕區(qū)域的更新信息,大幅度地降低了數(shù)據(jù)流的瞬時變化,在帶寬有障礙的信道上傳輸是一種理想的方案。H.261可使數(shù)據(jù)速率壓縮至P×64Kbps(P=1～20),一般在32～384Kbps時圖像可達CIF、QCIF15幀每秒(F/S),總體上圖像質(zhì)量略遜于MPEG1, 適合在ISDN、DDN、PSTN網(wǎng)上傳輸運動的圖像?！　　? H.263 H.263是CCITT(現(xiàn)ITU-T)于1995年提出的更低比特率的視頻編碼方案,可將圖像最低編碼到20Kbps,通過電話線上以22.8Kbps的V.34Modem傳輸,圖像質(zhì)量達到

41、176×144或128×96分辨率下5～15F/S的水平。H.263非常適合在固定帶寬的信道中傳輸視頻信號。MPEG1、H.261、H.263三種編碼方式都是針對低成本的編碼方案。MPEG1編碼方式實現(xiàn)在400Kbps～2Mbps速率上傳輸CIF格式、每秒5～30幀的活動圖像,在三種編碼方式中圖像質(zhì)量最高;H.261編碼方式采用了區(qū)域更新的方法,進一步降低了碼流速率,實現(xiàn)在128～768Kbps的速率上傳輸CIF或QCIF格式、每秒5～25幀的活動圖像,圖像質(zhì)量略遜于MPEG1;H.263編碼方式是三種方式中數(shù)據(jù)流速率最低的一種,它在H.261的基礎(chǔ)上增加了四種編碼選項,將碼流速率降到128K

42、bps以下,在9.6～128Kbps的速率上傳輸CIF或QCIF格式、每秒1～15幀的活動圖像,特別適合在電話線上傳輸質(zhì)量要求不高的活動圖像?！? H.264 在MPEG風頭正勁的時候，H.264/AVC是ITU-T與ISO/IEC兩大國際標準組織聯(lián)手，啟動了一項旨在進一步提高視頻編碼性能的下一代視頻編碼標準的工程,并成立了由雙方專家組成的工作組,即JVT(JointVideoTeam)。希望通過JVT的工作在視頻編碼效率方面帶來實質(zhì)性的提高,新的標準預期用在所有傳輸帶寬或者存儲容量受限的領(lǐng)域。 在ITU-T增強型多媒體通信標準H.26L基礎(chǔ)上在2003年5月份推出了H.264壓縮標準推出的

43、能夠為ITU-T與ISO/IEC共同使用的單一的下一代視頻編碼標準,并且在技術(shù)上同MPEG標準形成體系。 在實際使用中我們發(fā)現(xiàn)它比MPEG-4壓縮率更高，更加適合在有限帶寬的環(huán)境下傳輸視頻數(shù)據(jù)，而畫面質(zhì)量與MPEG-4基本相同?！? 其標準可分為三檔： 基本檔次（其簡單版本，應用面廣）； 主要檔次（采用了多項提高圖像質(zhì)量和增加壓縮比的技術(shù)措施，可用于SDTV、HDTV和DVD等）； 擴展檔次（可用于各種網(wǎng)絡的視頻流傳輸）。 H.264不僅比H.263和MPEG-4節(jié)約了50％的碼率，而且對網(wǎng)絡傳輸具有更好的支持功能。它引入了面向IP包的編碼機制，有利于網(wǎng)絡中的分組傳輸，支持網(wǎng)絡中視頻

44、的流媒體傳輸。 H.264具有較強的抗誤碼特性，可適應丟包率高、干擾嚴重的無線信道中的視頻傳輸。H.264支持不同網(wǎng)絡資源下的分級編碼傳輸，從而獲得平穩(wěn)的圖像質(zhì)量。H.264以低碼流傳輸，高清晰畫質(zhì)，能適應于不同網(wǎng)絡中的視頻傳輸，網(wǎng)絡親和性好。如電話線傳輸?shù)鹊?，因此，在DVR遠程視頻視頻監(jiān)控領(lǐng)域得到了廣泛應用。 D-one( D1 )與H.264的區(qū)別： 繼H.264技術(shù)發(fā)展進步，目前，DVR行業(yè)市場中，出現(xiàn)了D1這個詞，而D1似乎讓人們確定為比H.264更高的技術(shù)，因此，我們就此區(qū)別大概介紹一下： D-one 是一種壓縮視頻顯示分辨率，即704x576，類似的還有CIF，352x28

45、8。 H.264是一種壓縮算法，即MPEG-4/part10。 我們可以稱謂為D1格式的H.264壓縮算法，或CIF格式的H.264壓縮算法。D1的格式是可以很形象的看得到，它是一個image的大小，它主要體現(xiàn)在圖像顯示分辨率上，而H.264只是壓縮程序的算法，只能體現(xiàn)在壓縮比例和壓縮文件占存儲空間的多少以及傳輸碼流的大小。 現(xiàn)在DVR市面上也出現(xiàn)了Half-D1，只是指準D1，因此壓縮分辨率也只能達到704*576的一半，即704*288分辨率，但這種分辨率已經(jīng)能夠較好的滿足我們監(jiān)控的畫面要求。 一、視頻壓縮錄像存儲量對比 經(jīng)過測試表明，對靜止、一般活動場景、劇烈活動場景三種情況

46、下、在相同清晰度對應MPEG1（500K bits/sec）碼流情況下，存儲容量測試結(jié)果見下表： 表 1. 1視頻壓縮錄像存儲量對比表 MJPEG MJPEG MJPEG MPEG1 MPEG1 MPEG1 MPEG4 MPEG4 MPEG4 1幀 1分鐘 1小時 1幀 1分鐘 1小時 1幀 1分鐘 1小時 靜止畫面 6K 9M 540M 2.4K 3.6M 216M 0.68K 1.02M 61.2M 一般活動 7.2K 10.8M 648M 2.4K 3.6M 216M 1.07K 1.6M 96M

47、 劇烈活動 11K 16.5M 990M 2.4K 3.6M 216M 1.68K 2.52M 151.2M 注意：該測試結(jié)果隨場景變化有所出入　 二、視頻顯示及圖像傳輸要求對比表如表1.2。 表 1. 2視頻顯示及圖像傳輸對比表 　 原始圖像（320×240） H.261 MPEG1 MPEG2 MPEG4 M-JPEG WAVELET 壓縮比例 1 80 20 5 100 20 15 文件大小/幀/秒 230K 2.8K 11K 44K 2.2K 11K 14.7K 帶寬?K bit/秒 1,767 22

48、 83.3 353 16.7 83.3 118 續(xù)表 1. 2視頻顯示及圖像傳輸對比表 　 原始圖像（320×240） H.261 MPEG1 MPEG2 MPEG4 M-JPEG WAVELET 圖像質(zhì)量 極好 差 可以 極好 好 可以 好 　 原始圖像（320×240） H.261 MPEG1 MPEG2 MPEG4 M-JPEG WAVELET 應用 ? 視像會議 本地網(wǎng) 本地 遠程傳輸 本地網(wǎng) 本地網(wǎng) 備注 　 不適合于數(shù)碼錄像系統(tǒng) 　 要求儲存量大 當前的行業(yè)趨勢 　 　 三、MPE

49、1、MPEG4、H.263幾種標準，在普通電話線路上、寬帶網(wǎng)上傳輸視頻測試結(jié)果對比如表1.3： 表 1. 3 MPE1、MPEG4、H.263測試對比表 網(wǎng)絡類型 H.263 MPEG1 MPEG4 PSTN 5-9幀/秒，圖像質(zhì)量較差 無法傳輸 5-15幀/秒，圖像質(zhì)量好 LAN 25幀/秒，需256Kbits帶寬 25幀/秒，需500Kbits帶寬 25幀/秒，需256Kbits帶寬 因此選擇一寬即經(jīng)濟符合自己要求的DVR產(chǎn)品，要根據(jù)監(jiān)控環(huán)境的需要而定，具體可參考以下步驟： 1. 顯示/錄像總資源：- 選擇單路：實時25幀/s； 準實時12.5幀/s左右

50、； 非實時6幀/s；根據(jù)攝像機數(shù)量總和計算總資源 2. 存儲時間周期：確定硬盤容量的大小 3. 畫面畫質(zhì)：確定監(jiān)視及回放畫面分辨率的要求 4. 網(wǎng)絡帶寬：確定網(wǎng)絡監(jiān)控的傳輸環(huán)境 5. 系統(tǒng)擴展及操作方式 6. 穩(wěn)定性及保密性 1.1.3 視頻轉(zhuǎn)碼技術(shù) 視頻轉(zhuǎn)碼技術(shù)，顧名思義就是在通過某種手段改變現(xiàn)有視頻數(shù)據(jù)的編碼方式。視頻轉(zhuǎn)碼技術(shù)使用的目的不同，其實現(xiàn)的手段也各不相同。大致上可以分為兩類： 一、不同編碼格式之間的視頻數(shù)據(jù)轉(zhuǎn)碼 不同編碼格式之間的數(shù)據(jù)轉(zhuǎn)碼，指通過轉(zhuǎn)碼方法改變視頻數(shù)據(jù)的編碼格式。通常這種數(shù)據(jù)轉(zhuǎn)碼會改變視頻數(shù)據(jù)的現(xiàn)有碼流和分辨率。 例如我們可以將基于 MPEG-

51、2 格式的視頻數(shù)據(jù)轉(zhuǎn)換為 DV 、 MPEG-4 或其它編碼格式，同時根據(jù)其轉(zhuǎn)碼目的，指定轉(zhuǎn)碼產(chǎn)生視頻數(shù)據(jù)的碼流和分辨率。我們可以將 MPEG-2 全 I 幀 50Mbps 的視頻源數(shù)據(jù)轉(zhuǎn)換為 25Mbps 碼流的 DV 格式數(shù)據(jù)，用于筆記本移動編輯系統(tǒng)，同時產(chǎn)生一個 300*200 低分辨率的 MPEG-4 文件，使用 REAL 或者微軟的 WMV 格式進行封裝，通過互聯(lián)網(wǎng)絡傳輸至主管領(lǐng)導處用于審看[10]。 這種轉(zhuǎn)碼方式設計的算法較為復雜，其實質(zhì)上是一個重新編碼的過程，涉及的算法復雜度和系統(tǒng)開銷，是由轉(zhuǎn)碼所需圖像質(zhì)量要求及轉(zhuǎn)碼前后兩種編碼方式的相關(guān)度所決定的。 二、相同編碼格式之間的視

52、頻數(shù)據(jù)轉(zhuǎn)碼 相同編碼格式的數(shù)據(jù)轉(zhuǎn)碼，指不改變壓縮格式，只通過轉(zhuǎn)碼手段改變其碼流或頭文件信息。根據(jù)其使用目的，可分為改變碼流和不改變碼流兩種。 如我們可以將 MPEG-2 全 I 幀 50Mbps 碼流的視頻數(shù)據(jù)轉(zhuǎn)碼為 MPEG-2 IBBP 幀 8Mbps 碼流的視頻數(shù)據(jù)，直接用于播出服務器用于播出?；蛘呶覀儗⒒?SONY 視頻服務器頭文件封裝的 MPEG-2 全 I 幀 50Mbps 碼流的視頻文件，改變其頭文件和封裝形式，使之可以在給予 MATROX 板卡的編輯系統(tǒng)上直接編輯使用。 這種轉(zhuǎn)碼方式的復雜度要小于不同編碼格式轉(zhuǎn)碼的復雜度，而且對視頻工程上而言，更加具有可操作性。 3

53、視頻數(shù)據(jù)轉(zhuǎn)碼的實現(xiàn) 視頻數(shù)據(jù)不同編碼之間的相互轉(zhuǎn)化有很多算法可以實現(xiàn)，許多運動圖像專家對此也作了深入的研究，針對不同的編碼方式提出了相當多可行的方案。這些方案共同的特點就是充分利用所需相互轉(zhuǎn)換編碼之間的共同特征，盡量減少編解碼所帶來的圖像質(zhì)量損失，同時達到時間和資源消耗的平衡。 如我們將一個 MPEG-2 的視頻數(shù)據(jù)轉(zhuǎn)換成 MPEG-4 的視頻數(shù)據(jù)，當然可以采用的方法是先將 MPEG-2 的視頻解壓縮成單 幀的圖像序列，再將其重新壓縮編碼成為 MPEG-4 的視頻數(shù)據(jù) 但這種轉(zhuǎn)碼方式的運算復雜度的使用 SDI 數(shù)據(jù)流作為中介的運算復雜度并沒有什么區(qū)別。我們可以通過一些方法提高轉(zhuǎn)碼的效率，

54、降低運算復雜度，比如 MPEG-2 和 MPEG-4 在其編碼算法上有很多相通的地方，在 DCT 變換， MC 運動補償， MV 運動補償?shù)确矫嬗性S多可以公用的地方，我們并不需要將其完全解碼成獨立的圖像序列，可利用不同編碼方式間的相關(guān)性進行轉(zhuǎn)碼工作 MPEG-2 視頻數(shù)據(jù)中所有的頭信息被解碼后都直接送到 MPEG -4 編碼器中進行編碼，其中少數(shù)頭信息需要調(diào)整，以適應新的編碼格式。而 DCT 系數(shù)和 MV 信息被重用，省去了運動估計和 DCT 的系統(tǒng)消耗。同時 MPEG -4 做運動補償?shù)臅r候，也可以直接利用 MPEG -2 解碼器解碼得出的運動矢量的信息。 我們可以看出，使用不同的轉(zhuǎn)碼算

55、法在不同需求的編碼轉(zhuǎn)換時，可以得到不同的時間及系統(tǒng)消耗復雜度。這些不同復雜度算法的是否采用取決于用戶對工作任務的要求。比如工作任務需要實時獲得轉(zhuǎn)碼結(jié)果，要求高可靠性，并且對轉(zhuǎn)碼前后的數(shù)據(jù)的編碼方式及碼流指定不變。那么我們可以采用高效的轉(zhuǎn)碼算法，必要時犧牲一些圖像質(zhì)量，將算法固化在硬件芯片板卡上，從而滿足任務需求。如果工作任務對轉(zhuǎn)碼同步性要求并不高，不要求實時輸出，但對圖像質(zhì)量有很高的要求，我們可以采用一些效率較低，但圖像質(zhì)量損失較小的轉(zhuǎn)碼算法。可以將算法固定在硬件芯片中，也可以使用通用的計算機運算系統(tǒng)、存儲系統(tǒng)和數(shù)據(jù)交換系統(tǒng)，使用軟件算法進行轉(zhuǎn)碼工作，這些方式的具體應用方式在本文的后半部分會詳

56、細介紹。 下面來看一下這些轉(zhuǎn)碼工作是如何實現(xiàn)的。 一、傳統(tǒng)面向流方式的視頻轉(zhuǎn)碼 由于視頻數(shù)據(jù)自身的特點，數(shù)據(jù)量的龐大和線性的存儲格式，長期以來傳統(tǒng)的視頻編碼轉(zhuǎn)換都是面向數(shù)據(jù)流進行操作。其工作原理如一個制式轉(zhuǎn)換器一樣，輸入端輸入連續(xù)的 NTSC 制信號，同時在輸出端輸出實時的 PAL 制信號。 這種方式的優(yōu)點是可以以實時或者接近實時的方式輸出轉(zhuǎn)碼結(jié)果，轉(zhuǎn)碼算法固化在板卡芯片上，轉(zhuǎn)碼工作基本上是由硬件完成，穩(wěn)定性好。但其缺點也是顯而易見的，轉(zhuǎn)碼單元針對特定的源編碼方式和目標編碼方式，用戶基本無法對碼流的大小和附加信息進行控制，靈活性較差。而為了滿足實時處理的要求，有時必須需要犧牲一些圖像的

57、質(zhì)量。另外的缺點就是這種基于流方式的視頻轉(zhuǎn)碼，輸入和輸出基本同步，不能以快于實時的速度進行編碼轉(zhuǎn)換。 隨著計算機技術(shù)的日益進步，非線性存儲手段日益完善，我們可以通過文件的方式存儲視頻數(shù)據(jù)。這樣就為視頻數(shù)據(jù)提供了新的，更加靈活高效的轉(zhuǎn)碼手段。 二、使用計算機及其相關(guān)設備面向文件方式進行視頻轉(zhuǎn)碼 使用計算機設備改變單幅圖像的編碼方式已經(jīng)是一個非常成熟的技術(shù)，但受到計算機運算能力和存儲能力的限制，很長一段時間內(nèi)，對于符合廣播級要求的專業(yè)視頻數(shù)據(jù)的編碼轉(zhuǎn)換處理一直沒有什么好的解決方案。但隨著計算機設備運算能力的增強和存儲容量的日益擴大、其數(shù)據(jù)接口已經(jīng)可以滿足視頻數(shù)據(jù)處理的需求，使用計算機及其相關(guān)

58、設備處理視頻數(shù)據(jù)已經(jīng)成為現(xiàn)在的主流，同時也給視頻轉(zhuǎn)碼提供了更好性價比的平臺。我們可以使用計算機設備，利用軟件手段，進行靈活高效的轉(zhuǎn)碼工作。 我們來看一看如何使用計算機系統(tǒng)進行轉(zhuǎn)碼工作。 這種利用計算機設備進行轉(zhuǎn)碼的工作方式具有非常大的靈活性，可以對以文件方式或以流方式存在的視頻數(shù)據(jù)進行處理。其本質(zhì)均是在計算機設備的存儲器內(nèi)開設足夠大數(shù)據(jù)的緩存地帶，將所需處理的視頻數(shù)據(jù)文件或流分成許多大小適合的片段，放入其中。由軟件提供轉(zhuǎn)碼算法，并控制計算機系統(tǒng)進行轉(zhuǎn)碼工作。圖 -7 中所示的數(shù)據(jù)接口的概念也非常的靈活，它可以使計算機設備的外部接口，如千兆以太、 Fiber Channel 通道，也可以是其

59、本身的內(nèi)置存儲通道接口。我們來看一下他們是如何工作的。 計算機設備先將需轉(zhuǎn)換編碼方式的視頻數(shù)據(jù)文件放入外部存儲或本地存儲設備中。然后將該視頻文件拆分成適合計算機設備處理的數(shù)據(jù)片段，放入高速緩存中，由軟件提供轉(zhuǎn)碼算法，利用計算機設備的處理能力對數(shù)據(jù)片段進行編碼轉(zhuǎn)換。轉(zhuǎn)換完成后將數(shù)據(jù)片段送入指定區(qū)域存儲，同時高速緩存區(qū)獲取新的數(shù)據(jù)片段。循環(huán)這種方式直到所有的拆分數(shù)據(jù)片段均得到了轉(zhuǎn)碼處理，合并轉(zhuǎn)碼完成的視頻數(shù)據(jù)文件片段，輸出我們所需要得到的視頻數(shù)據(jù)。 這種拆分數(shù)據(jù)的方式同樣也適合于以流方式存在的視頻數(shù)據(jù)，比如我們可以使用數(shù)據(jù)接口直接與數(shù)字視頻數(shù)據(jù)流連接，不經(jīng)過任何的編解碼將其存儲到計算機轉(zhuǎn)碼設備

60、的指定緩存區(qū)域，變線性的數(shù)據(jù)流存在方式為非線性的數(shù)據(jù)存儲方式，然后可以使用圖— 8 所示的數(shù)據(jù)拆分方式進行轉(zhuǎn)碼處理，經(jīng)合并后，可以選擇文件方式或依然保持流方式的數(shù)據(jù)輸出[11]。 采用這種方式的轉(zhuǎn)碼工作，具有很強的靈活性，數(shù)字信號接口并不需要識別接收到的數(shù)據(jù)流為何種格式編碼、封裝如何。只需將數(shù)據(jù)如實記錄到緩存區(qū)，由轉(zhuǎn)碼軟件決定采用何種轉(zhuǎn)碼手段，針對何種數(shù)據(jù)流的編碼格式和封裝方法進行編碼轉(zhuǎn)換工作。如我們在接口硬件標準相同的情況下，可以對 DV 流、 TS 流、 FTP 文件流等多種方式的數(shù)據(jù)流輸入進行編碼轉(zhuǎn)換，并不需要更換硬件接口和編解碼設備，只需更改轉(zhuǎn)碼軟件的轉(zhuǎn)碼處理手段及控制手段即可。

61、1.1.4 Html5技術(shù) HTML 5草案的前身名為Web Applications 1.0，是在2004年由WHATWG提出，再于2007年獲W3C接納，并成立了新的HTML工作團隊。在2008年1月22日，第一份正式草案發(fā)布。WHATWG表示該規(guī)范是目前仍在進行的工作，仍須多年的努力。目前Firefox、Chrome、Opera、Safari（版本4以上）、Internet Explorer 9已支持HTML5技術(shù)[12]。 盡管HTML5已經(jīng)在網(wǎng)絡開發(fā)人員中非常出名了，但是它成為主流媒體的一個話題還是在2010年的4月，當時蘋果公司的CEO喬布斯發(fā)表一篇題為“對flash的思考”的

62、文章，指出隨著HTML5的發(fā)展，觀看視頻或其它內(nèi)容時，Adobe Flash將不再是必須的。這引發(fā)了開發(fā)人員間的爭論，包括HTML5雖然提供了增強的功能，但開發(fā)人員必須考慮到不同瀏覽器對標準不同部分的支持程度的不同，以及HTML5和Flash間的功能差異。 HTML 5的標準草案目前已進入W3C制定標準5大程序的第1步。負責編纂標準格式文件的Google員工Ian Hickson預期，可能得等到2012年才會推出建議候選版（W3C Candidate Recommendation），并在2022年才會成為 W3C 推薦標準（W3C Recommendation）。 google公司負責開發(fā)a

63、ndorid的andy rubin在allthingsd亞洲大會上表示html5還遠不能為不同的移動操作系統(tǒng)提供不同的程序。 HTML5提供了音頻視頻的標準接口，實現(xiàn)了無需任何插件支持，只需瀏覽器支持相應的HTML5標簽。雖然Safari5、Firefox4和Chrome6等瀏覽器加入了HTML5技術(shù)，可以免除Flash插件的安裝直接播放視頻 。 1.1.5 SSH框架 就現(xiàn)在WEB開發(fā)而言，J2EE企業(yè)級開發(fā)技術(shù)比較成熟，開發(fā)模式模式也比較繁多，較流行開發(fā)模式MVC更是普遍，而基于MVC模式開發(fā)的框架也是種類繁多，現(xiàn)在使用最多的可能就是SSH這三種框架[13]。 一：Struts的

64、基礎(chǔ)介紹。 1: 介紹Struts Struts是目前WEB開發(fā)中比較流行的一種開源框架，它主要是采用Servlet和JSP技術(shù)實現(xiàn)Model2(Servlet+JSP+JavaBean)類型MVC的設計模式，即是實現(xiàn) 模型-視圖-控制三部分模塊的分離。 2：Struts與MVC的比較如表1.4 表 1. 4 Struts與MVC對比表 Struts MVC M JavaBean(業(yè)務數(shù)據(jù)), Service Class(業(yè)務邏輯) M模型 V JSP(動態(tài)網(wǎng)頁) ActionForm(表單數(shù)據(jù)操作) V視圖 C ActionServlet(接受頁面請

65、求), Action(處理請求;控制流程), struts-config.xml(配置參數(shù)) C控制部分 3：Struts的基本工作流程 基本流程： (1):WEB啟動，初始化ActionServlet，讀取struts-config.xml的配置信息，作準備。 (2):用戶發(fā)出一個請求，ActionServlet接受，根據(jù)ActionMapping查找相應的Action。 (3):Action調(diào)用JavaBean，并且結(jié)合ActionForm，處理數(shù)據(jù)。 (4):處理完成后,返回ActionForward，指定轉(zhuǎn)向的地方。 二：Spring基礎(chǔ)介紹 1: 介紹Spr

66、ing Spring框架也是一個開源框架，它的核心概念是依賴注入(Dependency Injection),通過依賴注入機制，可以再運行期間將組件之間的依賴關(guān)系由Spring容器注入組件，同時spring框架還提供AOP開發(fā)以及事務管理的組件，以及對WEB層和持久層的支持，從而可以很好配合Struts和Hibernate框架。 2：Spring框架的組建構(gòu)成 Spring框架大體由七個模塊構(gòu)成： A： Core模塊。該模塊是其他模塊的功能基礎(chǔ)，在這個模塊中存在BeanFactory類，它是Spring框架的核心，它實現(xiàn)依賴注入，是系統(tǒng)中的各組件的一倆關(guān)系從代碼中獨立出來，通過配置文件來實現(xiàn)；BeanFactory也是Spring框架的核心容器，因為他管理容器中對象的生命周期。 B： Context模塊。這個模塊是通過配置文件將各個組件組合在一起，使spring成為框架。其中ApplicationContext類擴展繼承BeanFactory的功能，因此它也可以成為Spring容器。此外該模塊還提供其他的服務。 C： DAO模塊。這個模塊把JDBC代碼中的一些內(nèi)容抽象出來，