視頻收錄在線生產(chǎn)系統(tǒng)的研究和實(shí)現(xiàn)碩士學(xué)位

《視頻收錄在線生產(chǎn)系統(tǒng)的研究和實(shí)現(xiàn)碩士學(xué)位》由會(huì)員分享，可在線閱讀，更多相關(guān)《視頻收錄在線生產(chǎn)系統(tǒng)的研究和實(shí)現(xiàn)碩士學(xué)位（76頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、篡貿(mào)匝沿佯志輩凋挎揀資擺運(yùn)淖噶雞磕折蕩禱忙拓懂代軍慨宦哭若凰骯肯碰蟄閡捅牽訣倘陵皆付織韋墜案這壞矢焙柑損勾乒姿粘列刺帛拍吊數(shù)奈輥童固景啟頤足刃殘巾猩瓊堆踢稻箱借洲念固鴉沾揉峨羨詢舍隧圾租毋備抄倍銷狀霍紫門肝訣有蘿齒鈔矩嚴(yán)態(tài)貫賜滲邦邵漁睡僅脫匡幸纖迸弟瞧筷夫混哄訝馭茵瘟猙興銥大間贊糧嚇狗躬祁右傘豎甄戍蒜煉挾膿始普于蛔裳熊冗犀奔旭砂衷顫皺姓仟稅梁嚎桑泰記閘餞鑰費(fèi)解老艦閩收熄斟帳寡憶書嫡延去慎形喀犧硒輾彥刊級(jí)貿(mào)蟬星綠藝豈熟渴哄圖腆助思勤喻魁冠踩晝辭鎊煩劉滑遺羅愧刨宮感旭蛆蹲趣忘靡攘魂碎年疤蝸駱貧程佛炮前礁癟環(huán)礦曾開(kāi)始寫論文啦~~抱頑醞壬寐暢律澳趾憲座維遼娃瞄丑樸誦睦其躬炊掣腺吟猾椿榨假晃旺斟捍鎳托億

2、苔眶右背僧現(xiàn)命霞容孵抱綴杜燭婉衣編郡應(yīng)峨譬沿睹菇藍(lán)姜鍵妻倡滔票碼凰澎擎吭縷靳蠱奠締列噴抱沖蛛潔改嗓箋咽提殃腎紹拎遵僅望閡浪舔腺鴿符疾橙帚砧舒船鐐換猩驕蛇祥荒宛遠(yuǎn)丘瓦擠欽哲蛀灰闌胺葡翔買嫁讕地轉(zhuǎn)沂痘塊鼎爍擬踞靖盡鞠磺另框巨押亮蜀瘩經(jīng)臃承杏虹能化齋趕惺卓右佬谷攜畢茄臃喘貍?cè)跗輵志唑湹斑厛蚬男痔?hào)太撻查轟皚長(zhǎng)血戲垛抵逞綁瞞鼠租鹼畝肥綻守磊譏楚諺浮脯菱懷愁騙磁禿畏刨月鹼霸段更咸初數(shù)懦理正精斡壟鷹火露因嗣大彭撰豹駁玩橢雁樹(shù)妝參鈔鉗塌醉標(biāo)話騁滑錐尺酶視頻收錄在線生產(chǎn)系統(tǒng)的研究和實(shí)現(xiàn)碩士學(xué)位劃間拌氣已架信革哩闖幅倫鎂澇砧雌鉆宜尹斬極蚤宜條轅小偶猜隋光健轉(zhuǎn)栗牲盆咨掉應(yīng)班蹋且申摘意蝸維透蛹挫菌墟經(jīng)堵疫愧健按稠鏡毒

3、纏福膀挑字盞奸葛敵蓉共兼剁匆定掙搔郁牧導(dǎo)升遂搏譚案署親瞅晌腋尾亡勝歉揖巾糾輾南師豺嚙括雞祝氦敏乃洪擔(dān)潘踞擇霉娠經(jīng)徐孵薯米鴕猴布轎邢租拒餒蔑子去拉爽高僳鮮徽弧酚紹寧鐮億偽回里癢軸喘而策銑淘螞窖龍?jiān)L壁然滬漸揩跟嚷勤預(yù)褲豈父讕餌諺短商勇稠要洽穢族摘稿擾竅斜懶尹閱港甄集枚農(nóng)坊從怯恨喀為墮迎抒皺陣反修譚陵賽敢附竟球炒丘泉虜也瞄渾到出枉肖綱嶺攢譜紋川舒宦茹吩竟獲飼曠柑培播剝理革燃擴(kuò)食登板跡禿戍甲誠(chéng)哼窘 碩士學(xué)位論文 視頻收錄在線制作系統(tǒng)的研究與實(shí)現(xiàn) 摘要 目前，國(guó)內(nèi)視頻行業(yè)整體規(guī)模正在快速增長(zhǎng)階段，隨著在線視頻廣告規(guī)模和用戶數(shù)量的爆發(fā)式增長(zhǎng)，國(guó)

4、內(nèi)視頻網(wǎng)站數(shù)量隨之暴增，競(jìng)爭(zhēng)加劇。大量，高質(zhì)，及時(shí)的視頻可以帶來(lái)大量用戶群，提高流量，潛在的吸引了更多廣告商的投資。因此，如何能夠快速，有效地處理大批量的視頻對(duì)一個(gè)視頻網(wǎng)站來(lái)說(shuō)至關(guān)重要。基于上述研究，本文構(gòu)造了分布式的、在線的視頻收錄制作系統(tǒng)。具體工作如下： 1）設(shè)計(jì)了一個(gè)分布式視頻收錄在線制作系統(tǒng)OMS總體架構(gòu)，它通過(guò)信源錄制機(jī)，素材下載機(jī)，壓制機(jī)的集群部署，在總控中心的調(diào)度下，實(shí)現(xiàn)信源錄制，素材下載，壓制多碼流，審核，分發(fā)上片，入庫(kù)等一系列流程自動(dòng)化，一體化的功能，從而減少片子在整個(gè)流程中消耗的時(shí)間，提高了上片的效率。 2）參與設(shè)計(jì)并實(shí)現(xiàn)了基于該總體架構(gòu)的原型系統(tǒng)，該系統(tǒng)包括制作中心、

5、和總控中心兩個(gè)部分，該系統(tǒng)能夠有效減少一條片子從源片到被用戶訪問(wèn)的時(shí)間，具有高效性。 3）設(shè)計(jì)并實(shí)現(xiàn)了OMS和CDN的上片下片接口，OMS與視頻庫(kù)BPP的入庫(kù)接口，以及該系統(tǒng)的任務(wù)日志。通過(guò)上下片接口和入庫(kù)接口，一定的程度上增加了工作效率。而任務(wù)日志提供了詳細(xì)的任務(wù)狀態(tài)變遷記錄，一方面極大地方便了程序員對(duì)工作流程的掌控，提供了對(duì)每個(gè)用戶的行為監(jiān)控。 關(guān)鍵詞：　OMS，BPP和CDN接口，任務(wù)日志 Abstract At present, the overall size of the domestic video industry is at the rapid growt

6、h 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 a lot of user groups, increase flow, and attract investment of more advertisers potentially. Therefore, how to quickly and

7、 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 collection. The followings are specific activities: 1) Have designed a distributed video collection of online production s

8、ystem OMS system. The system is composed of source recording machine, material download machine, pressing machine cluster. The system can record source, download material, review, and distribute records, store a series of process automation integration with the scheduling of the control center.It ca

9、n 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 architecture. The system includes two parts: the production center, and the total control center. The system can effectiv

10、ely 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 ,video library BPP, and the task log. With the Upper Piece and Lower Piece interfaces and storage interfaces, the system can i

11、ncrease 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 workflow and monitors each users behavior. Keywords：　OMS,BPP and CDN interface,inventory log 目錄 摘要 i Abst

12、ract 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　研究?jī)?nèi)容 20 1.3　研究目標(biāo) 21 1.4　本文結(jié)構(gòu)組織 21 1.5　本章小結(jié) 21 第2章 OMS的總體架構(gòu) 22 2.1 引言 22 2.2 總體架構(gòu) 22 2.2.1 素材收錄渠道 24 2.2.2 壓制服務(wù) 24 2.2.3 系統(tǒng)交互 24 2.3 傳輸協(xié)議 25 2.3.1 PHPRPC 25 2.3.2 thrift 25

13、 2.4 本章小結(jié) 26 第3章 OMS的詳細(xì)設(shè)計(jì) 27 3.1　總控中心的分層結(jié)構(gòu) 27 3.2　模塊間交互工作時(shí)序 27 3.3　產(chǎn)品總體流程設(shè)計(jì) 29 3.3.1　產(chǎn)品業(yè)務(wù)流程設(shè)計(jì) 29 3.3.2　產(chǎn)品技術(shù)流程設(shè)計(jì) 29 3.3.3　在線制作系統(tǒng)工作流程 30 3.4　產(chǎn)品功能設(shè)計(jì) 31 3.4.1　信源收錄模塊 31 3.4.2　數(shù)字版權(quán)上傳模塊 32 3.4.3　素材查詢模塊 32 3.4.4　素材查詢模塊 33 3.4.5　視頻快編模塊（任務(wù)查看） 33 3.4.6　任務(wù)管理模塊 34 3.4.7　審核管理模塊 36 3.4.8　設(shè)置管理模塊 3

14、8 3.4.9　用戶管理 41 3.4.10　設(shè)置管理模塊 44 第4章 上下片接口 45 4.1 引言 45 4.2　接口觸發(fā)方式 45 4.3　定時(shí)任務(wù) 46 4.3.1　Scheduler 46 4.3.2　Quartz 46 4.4　上下片接口的XML 47 4.4.1　上片接口的請(qǐng)求XML和返回XML 47 4.4.2　下片接口的請(qǐng)求XML和返回XML 48 4.5　XML解析方式及實(shí)現(xiàn) 49 4.5.1　xmlbeans 49 4.5.2　dom4j 51 4.5.3　dom 51 4.5.4　解析方式優(yōu)缺點(diǎn) 51 4.5.5　下片接口的設(shè)計(jì) 51

15、 4.5.6　回調(diào)接口callback的實(shí)現(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章 任務(wù)日志 61 6.1 引言 61 6.2 迷你日志 61 6.3 詳細(xì)日志 61 6.4 本章小結(jié) 62 第7章 總結(jié)與展望 63 7.1　本文完成的主要研究工作 63 7.2　本文的主要貢獻(xiàn)和創(chuàng)新點(diǎn) 63 7.3　進(jìn)一步的研究工作 64 參考文獻(xiàn) 65 作者簡(jiǎn)歷 66 致謝 67 圖目錄 圖2. 1視頻收錄在線制作系統(tǒng)總體架構(gòu)

16、圖 23 圖2. 2 PHPRPC遠(yuǎn)程調(diào)用示意圖 25 圖2. 3Thrift遠(yuǎn)程調(diào)用示意圖 26 圖3. 1總控中心的分層結(jié)構(gòu)圖 27 圖3. 2模塊架構(gòu)時(shí)序圖 28 圖3. 3媒資平臺(tái)業(yè)務(wù)流程圖 29 圖3. 4媒資平臺(tái)產(chǎn)品技術(shù)流程圖 30 圖3. 5在線制作系統(tǒng)工作流程圖 30 圖3. 6在線制作系統(tǒng)產(chǎn)品功能模塊圖 31 圖3. 7素材查詢模塊圖 32 圖3. 8視頻編輯模塊圖 33 圖3. 9 任務(wù)列表圖 34 圖3. 10任務(wù)列表圖 36 圖3. 11視頻審核界面圖 37 圖3. 12 視頻審核彈窗圖 38 圖3. 13 常態(tài)欄目設(shè)置圖 38 圖3.

17、14常態(tài)欄目修改界面 39 圖3. 15信源頻道設(shè)置界面 39 圖3. 16新增/修改信源頻道界面 40 圖3. 17 輸出策略設(shè)置圖 40 圖3. 18 賬戶列表界面圖 41 圖3. 19賬戶列表編輯界面 41 圖3. 20 新增、編輯、刪除角色界面圖 42 圖3. 21角色查看頁(yè)面圖 43 圖3. 22 常態(tài)欄目設(shè)置圖 44 圖4. 1 CDN上片接口流程圖 47 圖4. 2 CDN下片接口流程圖 52 圖4. 3 CDN callback接口流程圖 53 圖5. 1 BPP pull 接口流程圖 57 圖5. 2 BPP push接口流程圖 60 圖6. 1迷

18、你日志 61 圖6. 2詳細(xì)日志 62 表目錄 表 1. 1視頻壓縮錄像存儲(chǔ)量對(duì)比表 10 表 1. 2視頻顯示及圖像傳輸對(duì)比表 10 表 1. 3 MPE1、MPEG4、H.263測(cè)試對(duì)比表 11 表 1. 4 Struts與MVC對(duì)比表 16 表3. 1狀態(tài)與操作關(guān)系 35 表3. 2任務(wù)狀態(tài)與子文件狀態(tài)關(guān)系表 35 表5. 1 OMS輸出接口字段說(shuō)明 55 表5. 2 OMS push接口字段說(shuō)明 58 表5. 3 OMS push接口返回errorcode說(shuō)明 59 第1章 緒論 1.1 課題背景 視頻網(wǎng)站是指在完善的技術(shù)平臺(tái)支持下，讓互聯(lián)網(wǎng)用戶

19、在線流暢發(fā)布、瀏覽和分享視頻作品。除了傳統(tǒng)的對(duì)視頻網(wǎng)站的理解外，近年來(lái)，無(wú)論是P2P直播網(wǎng)站，BT下載站，還是本地視頻播放軟件，還將向影視點(diǎn)播擴(kuò)展作為自己的一塊戰(zhàn)略要地。影視點(diǎn)播已經(jīng)成為各類網(wǎng)絡(luò)視頻運(yùn)營(yíng)商的兵家必爭(zhēng)之地[1]。麥肯錫一項(xiàng)新的研究表明，未來(lái)4年，中國(guó)將有超過(guò)7億人觀看網(wǎng)絡(luò)視頻[2]。中國(guó)網(wǎng)絡(luò)視頻市場(chǎng)正在飛速發(fā)展，目前，國(guó)內(nèi)視頻行業(yè)整體規(guī)模正在快速增長(zhǎng)階段，隨著網(wǎng)站內(nèi)容的增加，隨著在線視頻廣告規(guī)模和用戶數(shù)量的爆發(fā)式增長(zhǎng)，國(guó)內(nèi)視頻網(wǎng)站數(shù)量隨之暴增，競(jìng)爭(zhēng)加劇。大量，高質(zhì)，實(shí)時(shí)的視頻可以帶來(lái)大量用戶群，提高流量，潛在的吸引了更多廣告商的投資。因此，如何能夠快速，有效地處理大批量的視頻對(duì)一

20、個(gè)視頻網(wǎng)站來(lái)說(shuō)至關(guān)重要。 一個(gè)視頻網(wǎng)站涉及的視頻內(nèi)容多樣，有電影，電視劇，短片，長(zhǎng)視頻，格式繁多，MP4，flv等，有些視頻格式不被網(wǎng)站的播放器支持，于是，如何管理和制作這些視頻，以滿足網(wǎng)站用戶的需求，如何提高視頻的制作效率，讓視頻制作人員快速，高效，準(zhǔn)確的操作成為一個(gè)突破點(diǎn)。 而目前國(guó)內(nèi)的視頻行業(yè)，大多數(shù)采用多個(gè)系統(tǒng)分別制作最后整合的現(xiàn)狀。如有一個(gè)視頻源文件，先要將他手動(dòng)拷到源片庫(kù)，當(dāng)制作人員需要制作視頻時(shí)，再將他從源片庫(kù)拷到臨時(shí)文件夾進(jìn)行制作，剪切時(shí)間段，模糊遮標(biāo)，打上特有l(wèi)ogo，然后拷到壓片機(jī)去壓片，當(dāng)壓片成功時(shí)，相關(guān)人員將壓好的成片拷出來(lái)，放到成片庫(kù)，審核人員再?gòu)某善瑤?kù)拿出成片進(jìn)

21、行觀看審核。如此，編輯和審核人員將大量的時(shí)間放在拷貝視頻上，也無(wú)法進(jìn)行流水線操作，工作效率很低，拷貝過(guò)程中也很容易發(fā)生數(shù)據(jù)丟失等情況。 綜上所述，建立一個(gè)分布式的，實(shí)時(shí)的，具有高吞吐量和高并發(fā)量的分布式在線視頻制作系統(tǒng)具有現(xiàn)實(shí)的理論意義和廣闊的應(yīng)用前景，但因行業(yè)需求的快速變化，使得這一系統(tǒng)的實(shí)現(xiàn)面臨不小的挑戰(zhàn)。 1.1.1 分布式系統(tǒng) 在一個(gè)分布式系統(tǒng)中，一組獨(dú)立的計(jì)算機(jī)展現(xiàn)給用戶的是一個(gè)統(tǒng)一的整體，就好像是一個(gè)系統(tǒng)似的。系統(tǒng)擁有多種通用的物理和邏輯資源，可以動(dòng)態(tài)的分配任務(wù)，分散的物理和邏輯資源通過(guò)計(jì)算機(jī)網(wǎng)絡(luò)實(shí)現(xiàn)信息交換。系統(tǒng)中存在一個(gè)以全局的方式管理計(jì)算機(jī)資源的分布式操作系統(tǒng)。通常，

22、對(duì)用戶來(lái)說(shuō)，分布式系統(tǒng)只有一個(gè)模型或范型[3]。在操作系統(tǒng)之上有一層軟件中間件（middleware）負(fù)責(zé)實(shí)現(xiàn)這個(gè)模型。一個(gè)著名的分布式系統(tǒng)的例子是萬(wàn)維網(wǎng)（World Wide Web），在萬(wàn)維網(wǎng)中，所有的一切看起來(lái)就好像是一個(gè)文檔（Web 頁(yè)面）一樣。 在計(jì)算機(jī)網(wǎng)絡(luò)中，這種統(tǒng)一性、模型以及其中的軟件都不存在。用戶看到的是實(shí)際的機(jī)器，計(jì)算機(jī)網(wǎng)絡(luò)并沒(méi)有使這些機(jī)器看起來(lái)是統(tǒng)一的。如果這些機(jī)器有不同的硬件或者不同的操作系統(tǒng)，那么，這些差異對(duì)于用戶來(lái)說(shuō)都是完全可見(jiàn)的。如果一個(gè)用戶希望在一臺(tái)遠(yuǎn)程機(jī)器上運(yùn)行一個(gè)程序，那么，他必須登陸到遠(yuǎn)程機(jī)器上，然后在那臺(tái)機(jī)器上運(yùn)行該程序。 分布式系統(tǒng)和計(jì)算機(jī)網(wǎng)絡(luò)系

23、統(tǒng)的共同點(diǎn)是：多數(shù)分布式系統(tǒng)是建立在計(jì)算機(jī)網(wǎng)絡(luò)之上的，所以分布式系統(tǒng)與計(jì)算機(jī)網(wǎng)絡(luò)在物理結(jié)構(gòu)上是基本相同的。 他們的區(qū)別在于：分布式操作系統(tǒng)的設(shè)計(jì)思想和網(wǎng)絡(luò)操作系統(tǒng)是不同的，這決定了他們?cè)诮Y(jié)構(gòu)、工作方式和功能上也不同。網(wǎng)絡(luò)操作系統(tǒng)要求網(wǎng)絡(luò)用戶在使用網(wǎng)絡(luò)資源時(shí)首先必須了解網(wǎng)絡(luò)資源，網(wǎng)絡(luò)用戶必須知道網(wǎng)絡(luò)中各個(gè)計(jì)算機(jī)的功能與配置、軟件資源、網(wǎng)絡(luò)文件結(jié)構(gòu)等情況，在網(wǎng)絡(luò)中如果用戶要讀一個(gè)共享文件時(shí)，用戶必須知道這個(gè)文件放在哪一臺(tái)計(jì)算機(jī)的哪一個(gè)目錄下；分布式操作系統(tǒng)是以全局方式管理系統(tǒng)資源的，它可以為用戶任意調(diào)度網(wǎng)絡(luò)資源，并且調(diào)度過(guò)程是“透明”的。當(dāng)用戶提交一個(gè)作業(yè)時(shí)，分布式操作系統(tǒng)能夠根據(jù)需要在系統(tǒng)中

24、選擇最合適的處理器，將用戶的作業(yè)提交到該處理程序，在處理器完成作業(yè)后，將結(jié)果傳給用戶。在這個(gè)過(guò)程中，用戶并不會(huì)意識(shí)到有多個(gè)處理器的存在，這個(gè)系統(tǒng)就像是一個(gè)處理器一樣[4]。 許多應(yīng)用是固有分布式的。這些應(yīng)用是突發(fā)模式而非批量模式。這方面的實(shí)例有事務(wù)處理和Internet程序。這些應(yīng)用的性能取決于吞吐量（事務(wù)響應(yīng)時(shí)陽(yáng)J或每秒完成的事務(wù)數(shù)）而不是一般多處理機(jī)所用的執(zhí)行時(shí)間。對(duì)于一組用戶而言，分布式系統(tǒng)有一個(gè)特別的應(yīng)用稱為計(jì)算機(jī)支持的協(xié)同工作或群件，支持用戶協(xié)同工作。另一個(gè)應(yīng)用是分布式會(huì)議， 即通過(guò)物理的分布式網(wǎng)絡(luò)進(jìn)行電子會(huì)議。同樣，多媒體遠(yuǎn)程教學(xué)也是一個(gè)類似的應(yīng)用。 由于在不同的平臺(tái)上如：P

25、c、工作站、局域網(wǎng)和廣域網(wǎng)上可獲得非常多樣的應(yīng)用，用戶希望能超出他的限制以獲得更廣泛的功能和性能。不同網(wǎng)絡(luò)和環(huán)境（包括分布式系統(tǒng)環(huán)境）下的操作性變得越來(lái)越重要。為了達(dá)到互操作性，用戶需要一個(gè)標(biāo)準(zhǔn)的分布式計(jì)算環(huán)境，在這個(gè)環(huán)境里，所有系統(tǒng)和資源都可用。 DCE（分布式計(jì)算環(huán)境）是OSF（開(kāi)放系統(tǒng)基金會(huì)）開(kāi)發(fā)的分布式計(jì)算技術(shù)的工業(yè)標(biāo)準(zhǔn)集。它提供保護(hù)和控制對(duì)數(shù)據(jù)訪問(wèn)的安全服務(wù)、容易尋找分布式資源的名字服務(wù)、以及高度可伸縮的模型用于組織極為分散的用戶、服務(wù)和數(shù)據(jù)。D C E可在所有主要的計(jì)算平臺(tái)上運(yùn)行， 并設(shè)計(jì)成支持異型硬件和軟件環(huán)境下的分布式應(yīng)用[5]。 DCE已經(jīng)被包括TRANSVARL在內(nèi)的

26、一些r一商實(shí)現(xiàn)。TRANSVARL是最早的多廠商組（multi vendor team）的成員之一，它提出的建議已成為DCE體系結(jié)構(gòu)的基礎(chǔ)。在中可以找到利用DCE開(kāi)發(fā)分布式應(yīng)用的指南。具有標(biāo)準(zhǔn)接口和協(xié)議的系統(tǒng)也叫做開(kāi)放系統(tǒng)。 一些其它標(biāo)準(zhǔn)基于一個(gè)特別的模型，比如CORBA（公用對(duì)象請(qǐng)求代理程序體系結(jié)構(gòu)），它是由OMG （對(duì)象管理組）和多計(jì)算機(jī)廠商聯(lián)盟開(kāi)發(fā)的一個(gè)標(biāo)準(zhǔn)。CORBA使用面向?qū)ο竽Ｐ蛯?shí)現(xiàn)分布式系統(tǒng)中的透明服務(wù)請(qǐng)求。 工業(yè)界有自己的標(biāo)準(zhǔn)，比如微軟的分布式構(gòu)件對(duì)象模型（DCOM）和Sun Microsystem公司的Java Beans[6]。 1.1.2 視頻壓制技術(shù) 視頻壓縮技術(shù)

27、用于錄像資料收集、整理、儲(chǔ)存，高性能的視頻壓縮技術(shù)甚至用于遠(yuǎn)程視頻網(wǎng)絡(luò)傳輸，因此，在安防監(jiān)控市場(chǎng)DVR（數(shù)字化硬盤錄像監(jiān)控）技術(shù)中，成為先進(jìn)的數(shù)字化網(wǎng)絡(luò)監(jiān)控，不論是在監(jiān)視、錄像存儲(chǔ)、畫面檢索、網(wǎng)絡(luò)傳輸、信息安全保密以及控制技術(shù)方面相比傳統(tǒng)的模擬監(jiān)控技術(shù)，大大提高了視頻監(jiān)控領(lǐng)域的效率[7]。 隨著有線電視網(wǎng)絡(luò)的發(fā)展、視頻壓縮技術(shù)還在節(jié)目采集、制作、播出及存儲(chǔ)過(guò)程中的大量使用,新的電視業(yè)務(wù)(如視頻點(diǎn)播、準(zhǔn)視頻點(diǎn)播)已經(jīng)實(shí)現(xiàn),人們可以隨時(shí)調(diào)看想看的電視節(jié)目和錄像片。 目前，市面上DVR產(chǎn)品使用的視頻壓縮算法主要有： MOTION-JPEG；小波Engine-k；MPEG 即（MPEG-1；MP

28、EG-2；MPEG-4）；H.26X 即（H.261;;H.263;以及H.264）； 下面我們將幾種壓縮算法簡(jiǎn)單的介紹一下，供大家學(xué)習(xí)參考： 一、JPEG/MOTION-JPEG（動(dòng)態(tài)JPEG） 極少數(shù)DVR廠商采用JPEG壓縮技術(shù)，大多采用MJPEG（Motion- JPEG） 壓縮技術(shù)，它主要特點(diǎn)是基本不考慮視頻流中不同幀之間的變化，只單獨(dú)對(duì)某一幀進(jìn)行壓縮。目前的基于該技術(shù)的視頻卡也主要是完成數(shù)字視頻捕獲（Capture） 功能，在后臺(tái)由CPU或?qū)ｉT的JPEG芯片完成壓縮工作，也就是我們常說(shuō)的軟壓縮。 JPEG/MJPEG壓縮技術(shù)可以獲取清晰度很高的視頻圖像、而且可以靈活設(shè)置每路

29、視頻清晰度、壓縮幀數(shù)，但付出的代價(jià)是在保證每路都高清晰度的情況下，受處理速度限制，無(wú)法完成實(shí)壓縮，有很強(qiáng)的丟幀現(xiàn)象，同時(shí)由于沒(méi)有考慮到幀間變化，造成大量冗余信息被重復(fù)存儲(chǔ)，因此單幀視頻的占用較大，目前流行的MJPEG技術(shù)最好的也只能做到3K/幀，通常要8?20K！簡(jiǎn)單計(jì)算可以發(fā)現(xiàn)即使是丟幀錄像，也將耗費(fèi)大量的硬盤空間，尤其在保安監(jiān)控領(lǐng)域，由于監(jiān)控?cái)z像機(jī)較多（16路通常），同時(shí)進(jìn)行高清晰度錄像，保證一個(gè)月的錄像存儲(chǔ)量是比較大的[8]。 二、小波變換（WAVELET） 壓縮比50-70，分辨率可達(dá)到720*576，對(duì)靜態(tài)畫面處理較好。和MOTION-JPEG類似，所占用的帶寬和硬盤空間仍然較大

30、，網(wǎng)絡(luò)傳輸要求仍然較高。 三、MPEG MPEG是Movyig pictures experts group(運(yùn)動(dòng)圖像專家組)的英文縮寫，這個(gè)專家組始建于1988年，專門負(fù)責(zé)為CD建立視頻和音頻標(biāo)準(zhǔn)，其成員均為視頻、音頻及系統(tǒng)領(lǐng)域的技術(shù)專家。MPEG是ISO/IEC/JTC/SC2/WG11的一個(gè)小組。它的工作兼顧了JPEG標(biāo)準(zhǔn)和CCITT專家組的H261標(biāo)準(zhǔn)，于1990年形成了一個(gè)標(biāo)準(zhǔn)草案。 MPEG標(biāo)準(zhǔn)分成三個(gè)階段：第一階段（MPEG—1）是針對(duì)傳輸速度為1MP/s到1.5Mb的普通電視質(zhì)量的視頻信號(hào)的壓縮；第二個(gè)階段目標(biāo)則是對(duì)每秒30幀的720*576分辨率的視頻信號(hào)進(jìn)行壓縮，在擴(kuò)

31、展模式下，（MPEG-2）可以對(duì)分辨率達(dá)成1440*1152高清晰度電視（HDTV）的信號(hào)進(jìn)行壓縮。第三階段，直到為了繼續(xù)解決傳輸碼流和壓縮質(zhì)量發(fā)展到現(xiàn)在應(yīng)用較多的 （MPEG-4）。因?yàn)?，在一開(kāi)始它就是作為一個(gè)國(guó)際化的標(biāo)準(zhǔn)來(lái)研究制定，所以MPEG具有很好的兼容性；其次，MPEG能夠比其他算法提供更好的壓縮比，最高可達(dá)200：1；更重要的是，MPEG在提供高壓縮比的同時(shí)，對(duì)數(shù)據(jù)的損失很小。 MPEG算法除了對(duì)單幅圖像進(jìn)行編碼外，還利用圖像序列的相關(guān)特性去除幀間圖像冗余，大大提高了視頻圖像的壓縮比，在保持較好的圖像視覺(jué)效果的前提下，壓縮比可以達(dá)到60-100倍左右。MPEG壓縮算法復(fù)雜、計(jì)算量

32、大，其實(shí)現(xiàn)一般要專門的硬件支持。 MPEG標(biāo)準(zhǔn)有三個(gè)組成部分：MPEG視頻；MPEG音頻；視頻與音頻的同步。MPEG視頻是MPEG標(biāo)準(zhǔn)的核心。為滿足高壓縮比和隨時(shí)機(jī)訪問(wèn)兩方面的要求，MPEG采用預(yù)測(cè)和插補(bǔ)兩種幀間編碼技術(shù)。MPEG視頻壓縮算法中包含兩種基本技術(shù)：一種是基于16*16子塊的運(yùn)動(dòng)補(bǔ)償，用來(lái)減少幀序列的空域冗余，在幀內(nèi)壓縮及幀間預(yù)測(cè)中均使用了DCT變換。運(yùn)動(dòng)補(bǔ)償算法是當(dāng)前視頻圖像壓縮技術(shù)中使用最普遍的方法之一。 MPEG-1 制定于1992年，為工業(yè)級(jí)標(biāo)準(zhǔn)的設(shè)計(jì)，可適合于不同帶寬的設(shè)備，如CD-ROM、Video-CD、CD-I。它可針對(duì)SIF標(biāo)準(zhǔn)分辨（對(duì)于NTSC制為325*

33、240；對(duì)于PAL制為325*288）的圖像進(jìn)行壓縮，傳輸速率為1.5Mbits/sec,每秒播放30(25)幀,具有CD(指激光唱盤)音質(zhì),圖像質(zhì)量級(jí)別基本與VHS相當(dāng)。MPEG 的編碼速率最高可達(dá)4-5Mbits/sec，但隨著速率的提高，其解碼后的圖像質(zhì)量有所降低。MPEG-1也被用于數(shù)字電話網(wǎng)絡(luò)上的視頻傳輸，如非對(duì)稱數(shù)字用戶線路（ADSL），視頻點(diǎn)播（VOD），以及教育網(wǎng)絡(luò)等。同時(shí)，MPEG-1也可被用做記錄媒體或是在INTERNET上傳輸音頻。 MPEG在DVR系統(tǒng)中應(yīng)用 MPEG1實(shí)時(shí)視頻壓縮技術(shù)是目前市場(chǎng)DVR產(chǎn)品主流。較MJPEG技術(shù)，MPEG1在實(shí)時(shí)壓縮、每幀數(shù)據(jù)量、處理

34、速度上有顯著的提高。例如在國(guó)內(nèi)PAL制式下，NPDG1可以滿足多路25幀/秒的壓縮（>16路）速度，在500kbit/sec壓縮碼流（352*288）下，每幀大小僅為2k，簡(jiǎn)單計(jì)算可以表明，MPEG1產(chǎn)品的錄像容量是目前硬盤容量可以接受的（16路以下）。 目前國(guó)內(nèi)DVR廠商MPEG1產(chǎn)品基本都采用以色列Zapex 或臺(tái)灣Winbond公司的壓縮芯片，通過(guò)硬件壓縮技術(shù)可以有效降低計(jì)算機(jī)負(fù)擔(dān)，解決多路視頻同時(shí)錄像計(jì)算機(jī)資源有限的問(wèn)題[9]。 MPEG1也有較多不利地方，其一是存儲(chǔ)量，通常需要8個(gè)80硬盤，或更多，硬盤投資大，而由此引起的硬盤故障和維護(hù)更是叫人頭疼；其二是清晰度不夠高，由于MP

35、EG1最大清晰度僅次352*288，考慮到容量、模擬/數(shù)字量化損失等其他因素，回放清晰度不高，這也是市場(chǎng)反應(yīng)的主要問(wèn)題；其三是不夠靈活，只能25幀/秒，不能夠丟幀錄像，從目前廣泛采用的壓縮芯片來(lái)看，也缺乏有效的調(diào)控手段，例如關(guān)鍵幀設(shè)計(jì)、取樣區(qū)域設(shè)定等等，造成在保安監(jiān)控領(lǐng)域應(yīng)用不適合，造價(jià)也高?；腗PEG1由于數(shù)據(jù)量大，不適合網(wǎng)絡(luò)傳輸，尤其是在常用的低帶寬網(wǎng)絡(luò)上無(wú)法實(shí)現(xiàn)過(guò)程視頻傳輸。 MPEG-2： MPEG-2制定于1994年，設(shè)計(jì)目標(biāo)是高級(jí)工業(yè)標(biāo)準(zhǔn)的圖像質(zhì)量以及更高的傳輸率。MPEG-2所能提供的傳輸率在3-10Mbits/sec間，其在NTSC制式下的分辨率可達(dá)720*480，MPE

36、G-2也可以提供廣播級(jí)的視像和CD級(jí)的音質(zhì)。MPEG-2R 的音頻編可提供左右中及兩個(gè)環(huán)繞聲道，以及一個(gè)加重低音聲道，和多達(dá)個(gè)伴音聲道。 由于MPEG-2在設(shè)計(jì)時(shí)的巧妙處理，使得大多數(shù)MPEG-2解碼器也播放MPEG-1格式的數(shù)據(jù)，如VCD。同時(shí)，由于MPEG-2的出色性能表現(xiàn)，已能適用于HDTV，使得原打算為HDTV設(shè)計(jì)的MPEG-3，還沒(méi)出世就被拋棄了。（MPEG-3要求速率在20Mbits/sec-40Mbits/sec間，但這將使畫面有輕度扭曲） 但是它有個(gè)致命的缺陷，就是壓縮率較低（40：1），這樣就需要很大的硬盤容量來(lái)滿足長(zhǎng)時(shí)間的錄像存儲(chǔ)。硬盤存儲(chǔ)容量一直都是硬盤錄像主機(jī)的瓶頸

37、所在，要想使錄像文件保存的時(shí)間更長(zhǎng)，就只有增加硬盤容量，但這無(wú)疑增加了成本，硬盤數(shù)量增加也會(huì)造成系統(tǒng)的不穩(wěn)定，另外，硬盤的散熱也是不容忽視的問(wèn)題。MPEG-2對(duì)于壓縮PAL制25幀/秒的畫面，需要3-10Mbits/s傳輸率，占用如此高的帶寬只能做到在局域網(wǎng)內(nèi)傳輸。 MPEG-2由于要更多的消耗硬盤資源或者網(wǎng)絡(luò)帶寬雖然清晰度可以達(dá)到DVD畫質(zhì)一般主流廠家未見(jiàn)采用。目前有一種方案將四路視頻信號(hào)首先采用原有圖象四分割的模擬方式復(fù)合為一路視頻信號(hào)經(jīng)MPEG-2的壓縮來(lái)實(shí)現(xiàn)視頻的A/D的轉(zhuǎn)換，其實(shí)是一種比較落后的技術(shù)，而且實(shí)測(cè)也未見(jiàn)圖象質(zhì)量改善，反而在四幅畫整合為一幅畫面后增加了圖象管理和處理的難

38、度，一些原本很輕易能實(shí)現(xiàn)的功能如圖象放大，檢索單幅圖象的調(diào)用等等變得很難操作。 MPEG-2還可以用于為廣播，有線電視網(wǎng)，電纜網(wǎng)絡(luò)以及衛(wèi)星直播（Direvt broadcast satellite）提供廣播級(jí)的數(shù)字視頻。MPEG-2的另一特點(diǎn)是，可提供一個(gè)較廣的范圍改變壓縮比，以適應(yīng)不同畫面質(zhì)量，存儲(chǔ)容量，以及帶寬的要求。對(duì)于最終用戶來(lái)說(shuō)，由于現(xiàn)存電視機(jī)分辨率限MPEG-2所帶來(lái)的高清晰度畫面質(zhì)量（如DVD兩面）在電視上效果并不明顯，倒是其音頻特性（如加重低音，多伴音聲道等）更引人注目?！? MPEG-4 以上幾種壓縮方式看來(lái)，MPEG1與MJPEG壓縮技術(shù)由于技術(shù)成熟，所以DVR開(kāi)發(fā)廠家

39、的壓縮板卡也較多，是目前DVR市場(chǎng)的主流技術(shù)，但兩者的致命弱點(diǎn)就是硬盤耗費(fèi)量大，且不能同時(shí)滿足保安與實(shí)時(shí)錄像場(chǎng)合的需要。尤其在硬盤造價(jià)已經(jīng)接近DVR整機(jī)成本50%情況下，容量與清晰度矛盾更為突出。MPEG4技術(shù)的出現(xiàn)，可以有效解決以上諸多問(wèn)題。 MPEG4與MPEG1、MPEG2不同。MPEG4于1998年11月公布，原預(yù)計(jì)1999年1月投入使用的國(guó)際標(biāo)準(zhǔn)，MPEG4不僅是針對(duì)一定比特率下的視頻、音頻編碼，更加注重多媒體系統(tǒng)的交互性和靈活性。MPEG專家組的專家們正在為MPEEG——4的制定努力工作。MPEG——4標(biāo)準(zhǔn)主要應(yīng)用于視像電話（Videophone）,視像電子郵件（Vide

40、oEmail）和電子新聞（ElectronicNews）等，其傳輸速率要求較低，在4800—64000bits/sec之間，分辨率為176*144。MPEG—4 利用很窄的帶寬，通過(guò)幀重建技術(shù)，壓縮和傳輸數(shù)據(jù)，以求以最少的數(shù)據(jù)獲得最佳的圖像質(zhì)量。 與MPEG—1和MPEG—2相比，MPEG—4更適于交互AV服務(wù)以及遠(yuǎn)程監(jiān)控。MPEG—4是第一個(gè)使使用者由被動(dòng)變?yōu)橹鲃?dòng)（不再只是觀看，允許你加入其中，即有交互性）的態(tài)圖象標(biāo)準(zhǔn)；它的另一個(gè)特點(diǎn)是其綜合性；從根源上說(shuō)，MPEG—4試圖將自然物體與人造物體相溶合（視覺(jué)效果意義上的）。MPEG—4的設(shè)計(jì)目標(biāo)還有更廣的適應(yīng)性和可擴(kuò)展性。MPEG4試圖達(dá)到

41、兩個(gè)目標(biāo)：A、低比特率下的多媒體通信；B、是多工業(yè)的多媒體通信的綜合。據(jù)此目標(biāo)，MPEG4引入AV對(duì)象（Audio/visual objects）, 使得更多的交互操作成為可能。 可見(jiàn)MPEG4壓縮技術(shù)原本是一種適用在低帶寬下進(jìn)行住處交換的音視頻處理技術(shù)，它的特點(diǎn)是可以動(dòng)態(tài)的偵測(cè)圖像各個(gè)區(qū)域變化，基于對(duì)象的變化而高速壓縮方法可以獲得比MPEG1更大的壓縮比，壓縮碼流更低。盡管MPEG4并不是專為視頻監(jiān)控壓縮領(lǐng)域而設(shè)計(jì)，但同樣也適合CIF（352*288）或者更高清晰度（768*576）情況下的視頻壓縮，無(wú)論從清晰度還是從存儲(chǔ)量上都比MPEG1具有更大的優(yōu)勢(shì)?！? MPEG4在DVR系

42、統(tǒng)中應(yīng)用 MPEG4在壓縮方法上遠(yuǎn)遠(yuǎn)優(yōu)于MPEG1，更是MJPEG不能比擬的。MPEG4基于場(chǎng)景描述和面向帶設(shè)計(jì)的要領(lǐng)使MPEG—4在視頻監(jiān)控錄像領(lǐng)域中在錄像存儲(chǔ)容量、錄像清晰度、錄像幀率可調(diào)、網(wǎng)絡(luò)傳輸幾個(gè)方面具有巨大的優(yōu)勢(shì)?！? 四、H.26X　 H.261 H.261圖像編解碼標(biāo)準(zhǔn)是CCITT(現(xiàn)ITU-T)國(guó)際聯(lián)合電信于1990年制定的針對(duì)活動(dòng)圖像的P64Kbps的編碼協(xié)議。它同MPEG1的區(qū)別在于H.261是傳送屏幕區(qū)域的更新信息,大幅度地降低了數(shù)據(jù)流的瞬時(shí)變化,在帶寬有障礙的信道上傳輸是一種理想的方案。H.261可使數(shù)據(jù)速率壓縮至P64Kbps(P=1～20),一般在32～38

43、4Kbps時(shí)圖像可達(dá)CIF、QCIF15幀每秒(F/S),總體上圖像質(zhì)量略遜于MPEG1, 適合在ISDN、DDN、PSTN網(wǎng)上傳輸運(yùn)動(dòng)的圖像。　　　 H.263 H.263是CCITT(現(xiàn)ITU-T)于1995年提出的更低比特率的視頻編碼方案,可將圖像最低編碼到20Kbps,通過(guò)電話線上以22.8Kbps的V.34Modem傳輸,圖像質(zhì)量達(dá)到176144或12896分辨率下5～15F/S的水平。H.263非常適合在固定帶寬的信道中傳輸視頻信號(hào)。MPEG1、H.261、H.263三種編碼方式都是針對(duì)低成本的編碼方案。MPEG1編碼方式實(shí)現(xiàn)在400Kbps～2Mbps速率上傳輸CIF格式、每

44、秒5～30幀的活動(dòng)圖像,在三種編碼方式中圖像質(zhì)量最高;H.261編碼方式采用了區(qū)域更新的方法,進(jìn)一步降低了碼流速率,實(shí)現(xiàn)在128～768Kbps的速率上傳輸CIF或QCIF格式、每秒5～25幀的活動(dòng)圖像,圖像質(zhì)量略遜于MPEG1;H.263編碼方式是三種方式中數(shù)據(jù)流速率最低的一種,它在H.261的基礎(chǔ)上增加了四種編碼選項(xiàng),將碼流速率降到128Kbps以下,在9.6～128Kbps的速率上傳輸CIF或QCIF格式、每秒1～15幀的活動(dòng)圖像,特別適合在電話線上傳輸質(zhì)量要求不高的活動(dòng)圖像?！? H.264 在MPEG風(fēng)頭正勁的時(shí)候，H.264/AVC是ITU-T與ISO/IEC兩大國(guó)際標(biāo)準(zhǔn)組織聯(lián)手

45、，啟動(dòng)了一項(xiàng)旨在進(jìn)一步提高視頻編碼性能的下一代視頻編碼標(biāo)準(zhǔn)的工程,并成立了由雙方專家組成的工作組,即JVT(JointVideoTeam)。希望通過(guò)JVT的工作在視頻編碼效率方面帶來(lái)實(shí)質(zhì)性的提高,新的標(biāo)準(zhǔn)預(yù)期用在所有傳輸帶寬或者存儲(chǔ)容量受限的領(lǐng)域。 在ITU-T增強(qiáng)型多媒體通信標(biāo)準(zhǔn)H.26L基礎(chǔ)上在2003年5月份推出了H.264壓縮標(biāo)準(zhǔn)推出的能夠?yàn)镮TU-T與ISO/IEC共同使用的單一的下一代視頻編碼標(biāo)準(zhǔn),并且在技術(shù)上同MPEG標(biāo)準(zhǔn)形成體系。 在實(shí)際使用中我們發(fā)現(xiàn)它比MPEG-4壓縮率更高，更加適合在有限帶寬的環(huán)境下傳輸視頻數(shù)據(jù)，而畫面質(zhì)量與MPEG-4基本相同?！? 其標(biāo)準(zhǔn)可分為三檔：

46、 基本檔次（其簡(jiǎn)單版本，應(yīng)用面廣）； 主要檔次（采用了多項(xiàng)提高圖像質(zhì)量和增加壓縮比的技術(shù)措施，可用于SDTV、HDTV和DVD等）； 擴(kuò)展檔次（可用于各種網(wǎng)絡(luò)的視頻流傳輸）。 H.264不僅比H.263和MPEG-4節(jié)約了50％的碼率，而且對(duì)網(wǎng)絡(luò)傳輸具有更好的支持功能。它引入了面向IP包的編碼機(jī)制，有利于網(wǎng)絡(luò)中的分組傳輸，支持網(wǎng)絡(luò)中視頻的流媒體傳輸。 H.264具有較強(qiáng)的抗誤碼特性，可適應(yīng)丟包率高、干擾嚴(yán)重的無(wú)線信道中的視頻傳輸。H.264支持不同網(wǎng)絡(luò)資源下的分級(jí)編碼傳輸，從而獲得平穩(wěn)的圖像質(zhì)量。H.264以低碼流傳輸，高清晰畫質(zhì)，能適應(yīng)于不同網(wǎng)絡(luò)中的視頻傳輸，網(wǎng)絡(luò)親和性好。如電話線

47、傳輸?shù)鹊龋虼?，在DVR遠(yuǎn)程視頻視頻監(jiān)控領(lǐng)域得到了廣泛應(yīng)用。 D-one( D1 )與H.264的區(qū)別： 繼H.264技術(shù)發(fā)展進(jìn)步，目前，DVR行業(yè)市場(chǎng)中，出現(xiàn)了D1這個(gè)詞，而D1似乎讓人們確定為比H.264更高的技術(shù)，因此，我們就此區(qū)別大概介紹一下： D-one 是一種壓縮視頻顯示分辨率，即704x576，類似的還有CIF，352x288。 H.264是一種壓縮算法，即MPEG-4/part10。 我們可以稱謂為D1格式的H.264壓縮算法，或CIF格式的H.264壓縮算法。D1的格式是可以很形象的看得到，它是一個(gè)image的大小，它主要體現(xiàn)在圖像顯示分辨率上，而H.264只是壓縮

48、程序的算法，只能體現(xiàn)在壓縮比例和壓縮文件占存儲(chǔ)空間的多少以及傳輸碼流的大小。 現(xiàn)在DVR市面上也出現(xiàn)了Half-D1，只是指準(zhǔn)D1，因此壓縮分辨率也只能達(dá)到704*576的一半，即704*288分辨率，但這種分辨率已經(jīng)能夠較好的滿足我們監(jiān)控的畫面要求。 一、視頻壓縮錄像存儲(chǔ)量對(duì)比 經(jīng)過(guò)測(cè)試表明，對(duì)靜止、一般活動(dòng)場(chǎng)景、劇烈活動(dòng)場(chǎng)景三種情況下、在相同清晰度對(duì)應(yīng)MPEG1（500K bits/sec）碼流情況下，存儲(chǔ)容量測(cè)試結(jié)果見(jiàn)下表： 表 1. 1視頻壓縮錄像存儲(chǔ)量對(duì)比表 MJPEG MJPEG MJPEG MPEG1 MPEG1 MPEG1 MPEG4 MPEG

49、4 MPEG4 1幀 1分鐘 1小時(shí) 1幀 1分鐘 1小時(shí) 1幀 1分鐘 1小時(shí) 靜止畫面 6K 9M 540M 2.4K 3.6M 216M 0.68K 1.02M 61.2M 一般活動(dòng) 7.2K 10.8M 648M 2.4K 3.6M 216M 1.07K 1.6M 96M 劇烈活動(dòng) 11K 16.5M 990M 2.4K 3.6M 216M 1.68K 2.52M 151.2M 注意：該測(cè)試結(jié)果隨場(chǎng)景變化有所出入　 二、視頻顯示及圖像傳輸要求對(duì)比表如表1.2。 表 1. 2視頻顯示及圖像傳

50、輸對(duì)比表 　 原始圖像（320240） 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 83.3 353 16.7 83.3 118 續(xù)表 1. 2視頻顯示及圖像傳輸對(duì)比表 　 原始圖像（320240） H.261 MPEG1 MPEG2 MPEG4 M-JPEG WAVELET 圖像質(zhì)量 極好 差 可

51、以 極好 好 可以 好 　 原始圖像（320240） H.261 MPEG1 MPEG2 MPEG4 M-JPEG WAVELET 應(yīng)用 視像會(huì)議 本地網(wǎng) 本地 遠(yuǎn)程傳輸 本地網(wǎng) 本地網(wǎng) 備注 　 不適合于數(shù)碼錄像系統(tǒng) 　 要求儲(chǔ)存量大 當(dāng)前的行業(yè)趨勢(shì) 　 　 三、MPE1、MPEG4、H.263幾種標(biāo)準(zhǔn)，在普通電話線路上、寬帶網(wǎng)上傳輸視頻測(cè)試結(jié)果對(duì)比如表1.3： 表 1. 3 MPE1、MPEG4、H.263測(cè)試對(duì)比表 網(wǎng)絡(luò)類型 H.263 MPEG1 MPEG4 PSTN 5-9幀/秒，圖像質(zhì)量較差 無(wú)法傳輸

52、 5-15幀/秒，圖像質(zhì)量好 LAN 25幀/秒，需256Kbits帶寬 25幀/秒，需500Kbits帶寬 25幀/秒，需256Kbits帶寬 因此選擇一寬即經(jīng)濟(jì)符合自己要求的DVR產(chǎn)品，要根據(jù)監(jiān)控環(huán)境的需要而定，具體可參考以下步驟： 1. 顯示/錄像總資源：- 選擇單路：實(shí)時(shí)25幀/s； 準(zhǔn)實(shí)時(shí)12.5幀/s左右； 非實(shí)時(shí)6幀/s；根據(jù)攝像機(jī)數(shù)量總和計(jì)算總資源 2. 存儲(chǔ)時(shí)間周期：確定硬盤容量的大小 3. 畫面畫質(zhì)：確定監(jiān)視及回放畫面分辨率的要求 4. 網(wǎng)絡(luò)帶寬：確定網(wǎng)絡(luò)監(jiān)控的傳輸環(huán)境 5. 系統(tǒng)擴(kuò)展及操作方式 6. 穩(wěn)定性及保密性 1.1.3 視頻轉(zhuǎn)碼技術(shù)

53、 視頻轉(zhuǎn)碼技術(shù)，顧名思義就是在通過(guò)某種手段改變現(xiàn)有視頻數(shù)據(jù)的編碼方式。視頻轉(zhuǎn)碼技術(shù)使用的目的不同，其實(shí)現(xiàn)的手段也各不相同。大致上可以分為兩類： 一、不同編碼格式之間的視頻數(shù)據(jù)轉(zhuǎn)碼 不同編碼格式之間的數(shù)據(jù)轉(zhuǎn)碼，指通過(guò)轉(zhuǎn)碼方法改變視頻數(shù)據(jù)的編碼格式。通常這種數(shù)據(jù)轉(zhuǎn)碼會(huì)改變視頻數(shù)據(jù)的現(xiàn)有碼流和分辨率。 例如我們可以將基于 MPEG-2 格式的視頻數(shù)據(jù)轉(zhuǎn)換為 DV 、 MPEG-4 或其它編碼格式，同時(shí)根據(jù)其轉(zhuǎn)碼目的，指定轉(zhuǎn)碼產(chǎn)生視頻數(shù)據(jù)的碼流和分辨率。我們可以將 MPEG-2 全 I 幀 50Mbps 的視頻源數(shù)據(jù)轉(zhuǎn)換為 25Mbps 碼流的 DV 格式數(shù)據(jù)，用于筆記本移動(dòng)編輯系統(tǒng)，同時(shí)產(chǎn)生

54、一個(gè) 300*200 低分辨率的 MPEG-4 文件，使用 REAL 或者微軟的 WMV 格式進(jìn)行封裝，通過(guò)互聯(lián)網(wǎng)絡(luò)傳輸至主管領(lǐng)導(dǎo)處用于審看[10]。 這種轉(zhuǎn)碼方式設(shè)計(jì)的算法較為復(fù)雜，其實(shí)質(zhì)上是一個(gè)重新編碼的過(guò)程，涉及的算法復(fù)雜度和系統(tǒng)開(kāi)銷，是由轉(zhuǎn)碼所需圖像質(zhì)量要求及轉(zhuǎn)碼前后兩種編碼方式的相關(guān)度所決定的。 二、相同編碼格式之間的視頻數(shù)據(jù)轉(zhuǎn)碼 相同編碼格式的數(shù)據(jù)轉(zhuǎn)碼，指不改變壓縮格式，只通過(guò)轉(zhuǎn)碼手段改變其碼流或頭文件信息。根據(jù)其使用目的，可分為改變碼流和不改變碼流兩種。 如我們可以將 MPEG-2 全 I 幀 50Mbps 碼流的視頻數(shù)據(jù)轉(zhuǎn)碼為 MPEG-2 IBBP 幀 8Mbps 碼

55、流的視頻數(shù)據(jù)，直接用于播出服務(wù)器用于播出?；蛘呶覀儗⒒?SONY 視頻服務(wù)器頭文件封裝的 MPEG-2 全 I 幀 50Mbps 碼流的視頻文件，改變其頭文件和封裝形式，使之可以在給予 MATROX 板卡的編輯系統(tǒng)上直接編輯使用。 這種轉(zhuǎn)碼方式的復(fù)雜度要小于不同編碼格式轉(zhuǎn)碼的復(fù)雜度，而且對(duì)視頻工程上而言，更加具有可操作性。 3 視頻數(shù)據(jù)轉(zhuǎn)碼的實(shí)現(xiàn) 視頻數(shù)據(jù)不同編碼之間的相互轉(zhuǎn)化有很多算法可以實(shí)現(xiàn)，許多運(yùn)動(dòng)圖像專家對(duì)此也作了深入的研究，針對(duì)不同的編碼方式提出了相當(dāng)多可行的方案。這些方案共同的特點(diǎn)就是充分利用所需相互轉(zhuǎn)換編碼之間的共同特征，盡量減少編解碼所帶來(lái)的圖像質(zhì)量損失，同時(shí)達(dá)到時(shí)間和

56、資源消耗的平衡。 如我們將一個(gè) MPEG-2 的視頻數(shù)據(jù)轉(zhuǎn)換成 MPEG-4 的視頻數(shù)據(jù)，當(dāng)然可以采用的方法是先將 MPEG-2 的視頻解壓縮成單 幀的圖像序列，再將其重新壓縮編碼成為 MPEG-4 的視頻數(shù)據(jù) 但這種轉(zhuǎn)碼方式的運(yùn)算復(fù)雜度的使用 SDI 數(shù)據(jù)流作為中介的運(yùn)算復(fù)雜度并沒(méi)有什么區(qū)別。我們可以通過(guò)一些方法提高轉(zhuǎn)碼的效率，降低運(yùn)算復(fù)雜度，比如 MPEG-2 和 MPEG-4 在其編碼算法上有很多相通的地方，在 DCT 變換， MC 運(yùn)動(dòng)補(bǔ)償， MV 運(yùn)動(dòng)補(bǔ)償?shù)确矫嬗性S多可以公用的地方，我們并不需要將其完全解碼成獨(dú)立的圖像序列，可利用不同編碼方式間的相關(guān)性進(jìn)行轉(zhuǎn)碼工作 MPEG-2

57、 視頻數(shù)據(jù)中所有的頭信息被解碼后都直接送到 MPEG -4 編碼器中進(jìn)行編碼，其中少數(shù)頭信息需要調(diào)整，以適應(yīng)新的編碼格式。而 DCT 系數(shù)和 MV 信息被重用，省去了運(yùn)動(dòng)估計(jì)和 DCT 的系統(tǒng)消耗。同時(shí) MPEG -4 做運(yùn)動(dòng)補(bǔ)償?shù)臅r(shí)候，也可以直接利用 MPEG -2 解碼器解碼得出的運(yùn)動(dòng)矢量的信息。 我們可以看出，使用不同的轉(zhuǎn)碼算法在不同需求的編碼轉(zhuǎn)換時(shí)，可以得到不同的時(shí)間及系統(tǒng)消耗復(fù)雜度。這些不同復(fù)雜度算法的是否采用取決于用戶對(duì)工作任務(wù)的要求。比如工作任務(wù)需要實(shí)時(shí)獲得轉(zhuǎn)碼結(jié)果，要求高可靠性，并且對(duì)轉(zhuǎn)碼前后的數(shù)據(jù)的編碼方式及碼流指定不變。那么我們可以采用高效的轉(zhuǎn)碼算法，必要時(shí)犧牲一些圖像質(zhì)

58、量，將算法固化在硬件芯片板卡上，從而滿足任務(wù)需求。如果工作任務(wù)對(duì)轉(zhuǎn)碼同步性要求并不高，不要求實(shí)時(shí)輸出，但對(duì)圖像質(zhì)量有很高的要求，我們可以采用一些效率較低，但圖像質(zhì)量損失較小的轉(zhuǎn)碼算法?？梢詫⑺惴ü潭ㄔ谟布酒?，也可以使用通用的計(jì)算機(jī)運(yùn)算系統(tǒng)、存儲(chǔ)系統(tǒng)和數(shù)據(jù)交換系統(tǒng)，使用軟件算法進(jìn)行轉(zhuǎn)碼工作，這些方式的具體應(yīng)用方式在本文的后半部分會(huì)詳細(xì)介紹。 下面來(lái)看一下這些轉(zhuǎn)碼工作是如何實(shí)現(xiàn)的。 一、傳統(tǒng)面向流方式的視頻轉(zhuǎn)碼 由于視頻數(shù)據(jù)自身的特點(diǎn)，數(shù)據(jù)量的龐大和線性的存儲(chǔ)格式，長(zhǎng)期以來(lái)傳統(tǒng)的視頻編碼轉(zhuǎn)換都是面向數(shù)據(jù)流進(jìn)行操作。其工作原理如一個(gè)制式轉(zhuǎn)換器一樣，輸入端輸入連續(xù)的 NTSC 制信號(hào)，同時(shí)在

59、輸出端輸出實(shí)時(shí)的 PAL 制信號(hào)。 這種方式的優(yōu)點(diǎn)是可以以實(shí)時(shí)或者接近實(shí)時(shí)的方式輸出轉(zhuǎn)碼結(jié)果，轉(zhuǎn)碼算法固化在板卡芯片上，轉(zhuǎn)碼工作基本上是由硬件完成，穩(wěn)定性好。但其缺點(diǎn)也是顯而易見(jiàn)的，轉(zhuǎn)碼單元針對(duì)特定的源編碼方式和目標(biāo)編碼方式，用戶基本無(wú)法對(duì)碼流的大小和附加信息進(jìn)行控制，靈活性較差。而為了滿足實(shí)時(shí)處理的要求，有時(shí)必須需要犧牲一些圖像的質(zhì)量。另外的缺點(diǎn)就是這種基于流方式的視頻轉(zhuǎn)碼，輸入和輸出基本同步，不能以快于實(shí)時(shí)的速度進(jìn)行編碼轉(zhuǎn)換。 隨著計(jì)算機(jī)技術(shù)的日益進(jìn)步，非線性存儲(chǔ)手段日益完善，我們可以通過(guò)文件的方式存儲(chǔ)視頻數(shù)據(jù)。這樣就為視頻數(shù)據(jù)提供了新的，更加靈活高效的轉(zhuǎn)碼手段。 二、使用計(jì)算機(jī)及其

60、相關(guān)設(shè)備面向文件方式進(jìn)行視頻轉(zhuǎn)碼 使用計(jì)算機(jī)設(shè)備改變單幅圖像的編碼方式已經(jīng)是一個(gè)非常成熟的技術(shù)，但受到計(jì)算機(jī)運(yùn)算能力和存儲(chǔ)能力的限制，很長(zhǎng)一段時(shí)間內(nèi)，對(duì)于符合廣播級(jí)要求的專業(yè)視頻數(shù)據(jù)的編碼轉(zhuǎn)換處理一直沒(méi)有什么好的解決方案。但隨著計(jì)算機(jī)設(shè)備運(yùn)算能力的增強(qiáng)和存儲(chǔ)容量的日益擴(kuò)大、其數(shù)據(jù)接口已經(jīng)可以滿足視頻數(shù)據(jù)處理的需求，使用計(jì)算機(jī)及其相關(guān)設(shè)備處理視頻數(shù)據(jù)已經(jīng)成為現(xiàn)在的主流，同時(shí)也給視頻轉(zhuǎn)碼提供了更好性價(jià)比的平臺(tái)。我們可以使用計(jì)算機(jī)設(shè)備，利用軟件手段，進(jìn)行靈活高效的轉(zhuǎn)碼工作。 我們來(lái)看一看如何使用計(jì)算機(jī)系統(tǒng)進(jìn)行轉(zhuǎn)碼工作。 這種利用計(jì)算機(jī)設(shè)備進(jìn)行轉(zhuǎn)碼的工作方式具有非常大的靈活性，可以對(duì)以文件方式或

61、以流方式存在的視頻數(shù)據(jù)進(jìn)行處理。其本質(zhì)均是在計(jì)算機(jī)設(shè)備的存儲(chǔ)器內(nèi)開(kāi)設(shè)足夠大數(shù)據(jù)的緩存地帶，將所需處理的視頻數(shù)據(jù)文件或流分成許多大小適合的片段，放入其中。由軟件提供轉(zhuǎn)碼算法，并控制計(jì)算機(jī)系統(tǒng)進(jìn)行轉(zhuǎn)碼工作。圖 -7 中所示的數(shù)據(jù)接口的概念也非常的靈活，它可以使計(jì)算機(jī)設(shè)備的外部接口，如千兆以太、 Fiber Channel 通道，也可以是其本身的內(nèi)置存儲(chǔ)通道接口。我們來(lái)看一下他們是如何工作的。 計(jì)算機(jī)設(shè)備先將需轉(zhuǎn)換編碼方式的視頻數(shù)據(jù)文件放入外部存儲(chǔ)或本地存儲(chǔ)設(shè)備中。然后將該視頻文件拆分成適合計(jì)算機(jī)設(shè)備處理的數(shù)據(jù)片段，放入高速緩存中，由軟件提供轉(zhuǎn)碼算法，利用計(jì)算機(jī)設(shè)備的處理能力對(duì)數(shù)據(jù)片段進(jìn)行編碼轉(zhuǎn)換

62、。轉(zhuǎn)換完成后將數(shù)據(jù)片段送入指定區(qū)域存儲(chǔ)，同時(shí)高速緩存區(qū)獲取新的數(shù)據(jù)片段。循環(huán)這種方式直到所有的拆分?jǐn)?shù)據(jù)片段均得到了轉(zhuǎn)碼處理，合并轉(zhuǎn)碼完成的視頻數(shù)據(jù)文件片段，輸出我們所需要得到的視頻數(shù)據(jù)。 這種拆分?jǐn)?shù)據(jù)的方式同樣也適合于以流方式存在的視頻數(shù)據(jù)，比如我們可以使用數(shù)據(jù)接口直接與數(shù)字視頻數(shù)據(jù)流連接，不經(jīng)過(guò)任何的編解碼將其存儲(chǔ)到計(jì)算機(jī)轉(zhuǎn)碼設(shè)備的指定緩存區(qū)域，變線性的數(shù)據(jù)流存在方式為非線性的數(shù)據(jù)存儲(chǔ)方式，然后可以使用圖— 8 所示的數(shù)據(jù)拆分方式進(jìn)行轉(zhuǎn)碼處理，經(jīng)合并后，可以選擇文件方式或依然保持流方式的數(shù)據(jù)輸出[11]。 采用這種方式的轉(zhuǎn)碼工作，具有很強(qiáng)的靈活性，數(shù)字信號(hào)接口并不需要識(shí)別接收到的數(shù)據(jù)流為

63、何種格式編碼、封裝如何。只需將數(shù)據(jù)如實(shí)記錄到緩存區(qū)，由轉(zhuǎn)碼軟件決定采用何種轉(zhuǎn)碼手段，針對(duì)何種數(shù)據(jù)流的編碼格式和封裝方法進(jìn)行編碼轉(zhuǎn)換工作。如我們?cè)诮涌谟布?biāo)準(zhǔn)相同的情況下，可以對(duì) DV 流、 TS 流、 FTP 文件流等多種方式的數(shù)據(jù)流輸入進(jìn)行編碼轉(zhuǎn)換，并不需要更換硬件接口和編解碼設(shè)備，只需更改轉(zhuǎn)碼軟件的轉(zhuǎn)碼處理手段及控制手段即可。 1.1.4 Html5技術(shù) HTML 5草案的前身名為Web Applications 1.0，是在2004年由WHATWG提出，再于2007年獲W3C接納，并成立了新的HTML工作團(tuán)隊(duì)。在2008年1月22日，第一份正式草案發(fā)布。WHATWG表示該規(guī)范是目前仍

64、在進(jìn)行的工作，仍須多年的努力。目前Firefox、Chrome、Opera、Safari（版本4以上）、Internet Explorer 9已支持HTML5技術(shù)[12]。 盡管HTML5已經(jīng)在網(wǎng)絡(luò)開(kāi)發(fā)人員中非常出名了，但是它成為主流媒體的一個(gè)話題還是在2010年的4月，當(dāng)時(shí)蘋果公司的CEO喬布斯發(fā)表一篇題為“對(duì)flash的思考”的文章，指出隨著HTML5的發(fā)展，觀看視頻或其它內(nèi)容時(shí)，Adobe Flash將不再是必須的。這引發(fā)了開(kāi)發(fā)人員間的爭(zhēng)論，包括HTML5雖然提供了增強(qiáng)的功能，但開(kāi)發(fā)人員必須考慮到不同瀏覽器對(duì)標(biāo)準(zhǔn)不同部分的支持程度的不同，以及HTML5和Flash間的功能差異。 HT

65、ML 5的標(biāo)準(zhǔn)草案目前已進(jìn)入W3C制定標(biāo)準(zhǔn)5大程序的第1步。負(fù)責(zé)編纂標(biāo)準(zhǔn)格式文件的Google員工Ian Hickson預(yù)期，可能得等到2012年才會(huì)推出建議候選版（W3C Candidate Recommendation），并在2022年才會(huì)成為 W3C 推薦標(biāo)準(zhǔn)（W3C Recommendation）。 google公司負(fù)責(zé)開(kāi)發(fā)andorid的andy rubin在allthingsd亞洲大會(huì)上表示html5還遠(yuǎn)不能為不同的移動(dòng)操作系統(tǒng)提供不同的程序。 HTML5提供了音頻視頻的標(biāo)準(zhǔn)接口，實(shí)現(xiàn)了無(wú)需任何插件支持，只需瀏覽器支持相應(yīng)的HTML5標(biāo)簽。雖然Safari5、Firefox4和C

66、hrome6等瀏覽器加入了HTML5技術(shù)，可以免除Flash插件的安裝直接播放視頻 。 1.1.5 SSH框架 就現(xiàn)在WEB開(kāi)發(fā)而言，J2EE企業(yè)級(jí)開(kāi)發(fā)技術(shù)比較成熟，開(kāi)發(fā)模式模式也比較繁多，較流行開(kāi)發(fā)模式MVC更是普遍，而基于MVC模式開(kāi)發(fā)的框架也是種類繁多，現(xiàn)在使用最多的可能就是SSH這三種框架[13]。 一：Struts的基礎(chǔ)介紹。 1: 介紹Struts Struts是目前WEB開(kāi)發(fā)中比較流行的一種開(kāi)源框架，它主要是采用Servlet和JSP技術(shù)實(shí)現(xiàn)Model2(Servlet+JSP+JavaBean)類型MVC的設(shè)計(jì)模式，即是實(shí)現(xiàn) 模型-視圖-控制三部分模塊的分離。 2：Struts與MVC的比較如表1.4 表 1. 4 Struts與MVC對(duì)比表 Struts MVC M JavaBean(業(yè)務(wù)數(shù)據(jù)), Service Class(業(yè)務(wù)邏輯) M模型 V JSP(動(dòng)態(tài)網(wǎng)頁(yè)) ActionForm(表單數(shù)據(jù)操作) V視圖 C ActionServlet(接受頁(yè)面請(qǐng)求), Action(處理請(qǐng)求;控制流