丁玲　王孟陽

摘 要： 為了應(yīng)對遠(yuǎn)程教育中微格錄播系統(tǒng)數(shù)據(jù)傳輸過程中產(chǎn)生沖突導(dǎo)致數(shù)據(jù)中斷的問題，保證系統(tǒng)工作的流暢進(jìn)行，設(shè)計了沖突監(jiān)測方案和備保切換模塊，可實(shí)現(xiàn)實(shí)時監(jiān)測系統(tǒng)，在產(chǎn)生沖突后快速切換至備保服務(wù)器繼續(xù)傳輸數(shù)據(jù)。通過仿真證實(shí)系統(tǒng)可快速切換備保服務(wù)器，且切換時間與主機(jī)程序重啟時間較短，可在保證用戶錄播視頻質(zhì)量的同時使微格錄播系統(tǒng)滿足數(shù)據(jù)傳輸要求。

關(guān)鍵詞： 錄播； 數(shù)據(jù)傳輸； 沖突識別； 備保切換

中圖分類號： TN919?34； TP23 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2014）10?0073?04

Abstract： In order to solve the problem of data interruption caused by conflict produced during data transfer of microformat record/play?back system in remote education to ensure smooth working of the system， the conflict monitoring scheme and protection switching module was designed to achieve the real?time monitoring system， which can quickly switch to the backup server to continue the data transmission when conflict occurs. The simulation result confirms that the system can quickly switch to the backup security server， and the switching time is short same as the host program restart time. It can ensure the users′ video record/play?back quality while the microformat record/play?back system meets the data transmission requirements.

Keywords： record and play back； data transmission； conflict recognition； protection switching

0 引 言

時代發(fā)展日新月異，各行各業(yè)對于多媒體的依靠也越來越多，其中錄播系統(tǒng)作為一種新型的展示平臺，因其具有快速傳遞信息的能力而被廣泛接受。錄播系統(tǒng)指以具有特定需求的人為對象，將制錄像修改、濃縮成短時間內(nèi)的展示內(nèi)容，以課堂形式展現(xiàn)給觀眾。錄播系統(tǒng)對配套軟硬件設(shè)備要求較高。通過硬件如攝像錄音設(shè)備，以及軟件如視頻處理和音頻處理軟件將授課錄制成的數(shù)字視頻通常較大，而錄播的展示平臺要求具有連續(xù)性和時效性，要保證每個用戶均可享受服務(wù)，就務(wù)必保證數(shù)字信號傳輸?shù)姆€(wěn)定性以及足夠帶寬。但往往硬件條件滿足時，亦會出現(xiàn)多用戶分段傳輸過程中，沖突情況的出現(xiàn)，造成網(wǎng)絡(luò)傳輸沖突。為網(wǎng)絡(luò)傳輸沖突，必須針對特定的硬件條件配合具體算法來對系統(tǒng)進(jìn)行優(yōu)化。

1 錄播系統(tǒng)系統(tǒng)構(gòu)成介紹

錄播系統(tǒng)由大量軟件及硬件構(gòu)成，根據(jù)不同的需求也有不同的定制方案，但就完整的錄播系統(tǒng)應(yīng)該具有輸入輸出，過程監(jiān)控，品質(zhì)保障以及備份等功能。就硬件來說錄播系統(tǒng)包括控制間以及展示室兩部分。

控制間里布置了大量設(shè)備，這些設(shè)備包括服務(wù)器、主控計算機(jī)、高清攝像頭、錄像機(jī)、監(jiān)控臺、監(jiān)視器以及功放設(shè)備等[1]。主控室對展示室設(shè)備工作進(jìn)行監(jiān)視和控制。通過安裝在展示室的攝像裝置，采集環(huán)境情況。并實(shí)現(xiàn)播放。

展示室包括主要包括監(jiān)控攝像頭，視頻音頻設(shè)備，用戶分控器等。展示室內(nèi)計算機(jī)可上傳請求給主控室，亦可呼叫主控室，并與主控室進(jìn)行溝通。展示室也可以自行控制位于本區(qū)域的監(jiān)控設(shè)備，音頻視頻設(shè)備，收集錄制展示室的聲音和圖像，作為后續(xù)的分析和評估資料。 分控機(jī)可以選擇數(shù)據(jù)庫課程資源，并控制顯示設(shè)備，音頻設(shè)備的播放、暫停、停止、速度調(diào)節(jié)等功能[2]。

2 展示室錄播系統(tǒng)沖突分析

因?yàn)檎故臼忆洸ゾ哂羞h(yuǎn)程控制，傳輸數(shù)據(jù)量大以及節(jié)點(diǎn)多等特點(diǎn)，使得其系統(tǒng)較為復(fù)雜，為保證多個任務(wù)同時工作，需采用同步和多線程技術(shù)[3]。但多線程工作容易產(chǎn)生阻塞形成沖突，影響系統(tǒng)工作效率。

沖突是數(shù)據(jù)傳輸過程中數(shù)個等待進(jìn)程下載服務(wù)器共享資源產(chǎn)生沖突而形成的互相等待現(xiàn)象，這種等待使得進(jìn)程請求阻塞，需借助其他程序或認(rèn)為控制解除。由于服務(wù)器CPU工作的分時性，所以節(jié)點(diǎn)請求資源傳輸是互斥操作，為了提高系統(tǒng)性能和數(shù)據(jù)傳輸吞吐量需引入防沖突機(jī)制[4]，鎖也對系統(tǒng)高效和安全運(yùn)行具有明顯作用，但產(chǎn)生沖突后，節(jié)點(diǎn)請求無法滿足會產(chǎn)生停滯反而會影響系統(tǒng)工作。數(shù)據(jù)傳輸沖突原理圖如圖1所示。

通信沖突是一種程序錯誤，是大系統(tǒng)工作很難避免的現(xiàn)象。沖突的種類非藏多，操作系統(tǒng)內(nèi)核源碼有上千萬行，沖突具有大量產(chǎn)生點(diǎn)，在現(xiàn)有技術(shù)條件下，不可能避免沖突的產(chǎn)生[5]。所以在數(shù)據(jù)傳輸中應(yīng)采用有效方式，應(yīng)對沖突。

3 備保傳輸系統(tǒng)設(shè)計

為了避免傳輸過程中沖突影響播放流暢性，在此設(shè)計了沖突的識別模塊，提出一種快速地沖突識別機(jī)制。當(dāng)識別到?jīng)_突后，系統(tǒng)即使報告檢測信息。由于解沖突過程較為困難，會導(dǎo)致系統(tǒng)無法傳輸信息，此處構(gòu)建備保服務(wù)器進(jìn)行數(shù)據(jù)傳輸，克服了沖突以及解沖困難。下面分工作流程以及沖突識別模塊兩方面介紹分析系統(tǒng)。

3.1 備保系統(tǒng)的設(shè)計

首先，控制系統(tǒng)會將目標(biāo)視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務(wù)器與用戶網(wǎng)絡(luò)傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設(shè)置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設(shè)置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應(yīng)，數(shù)據(jù)包同時也被嚴(yán)格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設(shè)置與主機(jī)功能相近的服務(wù)器作為主機(jī)的備保，在主機(jī)工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進(jìn)行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機(jī)程序，從而消沖突，重啟程序后的主機(jī)為備保，交替工作。

此時備保機(jī)為達(dá)到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機(jī)工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經(jīng)重啟的主機(jī)繼續(xù)傳輸。

3.2 沖突識別算法的設(shè)計

互斥進(jìn)程同時請求服務(wù)器服務(wù)時，在同一時刻只能有一個線程訪問該對象。如果一個進(jìn)程已經(jīng)將資源鎖定，就會使傳輸序列沖突，導(dǎo)致了另外的用戶服務(wù)請求進(jìn)程不停地循環(huán)，無法獲取服務(wù)，進(jìn)而產(chǎn)生沖突。

如圖3所示，主機(jī)傳輸停止并重啟傳輸程序后產(chǎn)生短暫數(shù)據(jù)傳輸中斷，備保機(jī)正常工作后數(shù)據(jù)傳輸恢復(fù)正常，由于2個服務(wù)器配置相同帶寬不變，視頻傳輸質(zhì)量未受影響。證明系統(tǒng)可正常進(jìn)行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關(guān)注識別到?jīng)_突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質(zhì)量的影響。表1為6次備保切換的用時，沖突機(jī)的傳輸程序重啟時間，和切換時間用戶最小視頻質(zhì)量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機(jī)期間最小播放質(zhì)量為1 024 Kb/s。備保切換與服務(wù)器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質(zhì)參數(shù)表

5 結(jié) 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產(chǎn)生沖突導(dǎo)致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構(gòu)成，并設(shè)計與之配套的沖突識別方案，同時設(shè)計了備保傳輸系統(tǒng)，可在產(chǎn)生沖突后切換至備保服務(wù)器傳輸數(shù)據(jù)。最后通過仿真證實(shí)系統(tǒng)工作正常，并在短時間內(nèi)完成備保切換和主機(jī)程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻(xiàn)

[1] 李晉，葛敬國.Linux下互斥機(jī)制及其分析[J].計算機(jī)應(yīng)用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內(nèi)核自旋鎖分析[J].江西師范學(xué)院學(xué)報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術(shù)在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應(yīng)用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關(guān)聯(lián)規(guī)則的Web挖掘技術(shù)研究[J].現(xiàn)代電子技術(shù)，2011，34（16）：100?102.

首先，控制系統(tǒng)會將目標(biāo)視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務(wù)器與用戶網(wǎng)絡(luò)傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設(shè)置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設(shè)置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應(yīng)，數(shù)據(jù)包同時也被嚴(yán)格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設(shè)置與主機(jī)功能相近的服務(wù)器作為主機(jī)的備保，在主機(jī)工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進(jìn)行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機(jī)程序，從而消沖突，重啟程序后的主機(jī)為備保，交替工作。

此時備保機(jī)為達(dá)到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機(jī)工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經(jīng)重啟的主機(jī)繼續(xù)傳輸。

3.2 沖突識別算法的設(shè)計

互斥進(jìn)程同時請求服務(wù)器服務(wù)時，在同一時刻只能有一個線程訪問該對象。如果一個進(jìn)程已經(jīng)將資源鎖定，就會使傳輸序列沖突，導(dǎo)致了另外的用戶服務(wù)請求進(jìn)程不停地循環(huán)，無法獲取服務(wù)，進(jìn)而產(chǎn)生沖突。

如圖3所示，主機(jī)傳輸停止并重啟傳輸程序后產(chǎn)生短暫數(shù)據(jù)傳輸中斷，備保機(jī)正常工作后數(shù)據(jù)傳輸恢復(fù)正常，由于2個服務(wù)器配置相同帶寬不變，視頻傳輸質(zhì)量未受影響。證明系統(tǒng)可正常進(jìn)行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關(guān)注識別到?jīng)_突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質(zhì)量的影響。表1為6次備保切換的用時，沖突機(jī)的傳輸程序重啟時間，和切換時間用戶最小視頻質(zhì)量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機(jī)期間最小播放質(zhì)量為1 024 Kb/s。備保切換與服務(wù)器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質(zhì)參數(shù)表

5 結(jié) 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產(chǎn)生沖突導(dǎo)致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構(gòu)成，并設(shè)計與之配套的沖突識別方案，同時設(shè)計了備保傳輸系統(tǒng)，可在產(chǎn)生沖突后切換至備保服務(wù)器傳輸數(shù)據(jù)。最后通過仿真證實(shí)系統(tǒng)工作正常，并在短時間內(nèi)完成備保切換和主機(jī)程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻(xiàn)

[1] 李晉，葛敬國.Linux下互斥機(jī)制及其分析[J].計算機(jī)應(yīng)用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內(nèi)核自旋鎖分析[J].江西師范學(xué)院學(xué)報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術(shù)在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應(yīng)用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關(guān)聯(lián)規(guī)則的Web挖掘技術(shù)研究[J].現(xiàn)代電子技術(shù)，2011，34（16）：100?102.

首先，控制系統(tǒng)會將目標(biāo)視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務(wù)器與用戶網(wǎng)絡(luò)傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設(shè)置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設(shè)置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應(yīng)，數(shù)據(jù)包同時也被嚴(yán)格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設(shè)置與主機(jī)功能相近的服務(wù)器作為主機(jī)的備保，在主機(jī)工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進(jìn)行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機(jī)程序，從而消沖突，重啟程序后的主機(jī)為備保，交替工作。

此時備保機(jī)為達(dá)到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機(jī)工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經(jīng)重啟的主機(jī)繼續(xù)傳輸。

3.2 沖突識別算法的設(shè)計

互斥進(jìn)程同時請求服務(wù)器服務(wù)時，在同一時刻只能有一個線程訪問該對象。如果一個進(jìn)程已經(jīng)將資源鎖定，就會使傳輸序列沖突，導(dǎo)致了另外的用戶服務(wù)請求進(jìn)程不停地循環(huán)，無法獲取服務(wù)，進(jìn)而產(chǎn)生沖突。

如圖3所示，主機(jī)傳輸停止并重啟傳輸程序后產(chǎn)生短暫數(shù)據(jù)傳輸中斷，備保機(jī)正常工作后數(shù)據(jù)傳輸恢復(fù)正常，由于2個服務(wù)器配置相同帶寬不變，視頻傳輸質(zhì)量未受影響。證明系統(tǒng)可正常進(jìn)行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關(guān)注識別到?jīng)_突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質(zhì)量的影響。表1為6次備保切換的用時，沖突機(jī)的傳輸程序重啟時間，和切換時間用戶最小視頻質(zhì)量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機(jī)期間最小播放質(zhì)量為1 024 Kb/s。備保切換與服務(wù)器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質(zhì)參數(shù)表

5 結(jié) 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產(chǎn)生沖突導(dǎo)致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構(gòu)成，并設(shè)計與之配套的沖突識別方案，同時設(shè)計了備保傳輸系統(tǒng)，可在產(chǎn)生沖突后切換至備保服務(wù)器傳輸數(shù)據(jù)。最后通過仿真證實(shí)系統(tǒng)工作正常，并在短時間內(nèi)完成備保切換和主機(jī)程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻(xiàn)

[1] 李晉，葛敬國.Linux下互斥機(jī)制及其分析[J].計算機(jī)應(yīng)用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內(nèi)核自旋鎖分析[J].江西師范學(xué)院學(xué)報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術(shù)在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應(yīng)用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關(guān)聯(lián)規(guī)則的Web挖掘技術(shù)研究[J].現(xiàn)代電子技術(shù)，2011，34（16）：100?102.