分布式上載和傳統播出上載的比較和分析

李 勇，張文軍

（河南電視臺新農村頻道，河南 鄭州 450008）

目前，在以視頻服務器為核心的硬盤自動播出系統中，節目的上載播出是實現安全播出的重要前提。在播出系統和制作系統沒有實現互聯互通而僅僅作為孤島存在的情況下，磁帶上載就承擔了硬盤播出素材的全部來源。

傳統的上載方式是以分散的上載工作站來承擔頻道節目素材的上載工作，雖然結構簡單、控制靈活，但是在單一頻道的播出系統中，由于服務器所提供的板卡編解碼通道的數量限制，上載工作站點很難增加。隨著頻道節目量的增多和首播節目量的增大，上載設備資源緊張的情況日益凸現，經常出現大量磁帶排隊等機器上載的情況，而當編解碼板卡發生故障的時候，上載通道減少，剩余的上載設備就更加不能適應節目播出的需要。為此，一種不占用板卡通道的新型上載模式——分布式上載方式就成為改善目前狀況的新途徑。以下就以河南電視臺新農村頻道播出節目上載為例，具體分析新老兩種上載方式在LEITCH服務器環境下的實現和兼容。

1 采用分布式上載方式的背景

河南電視臺新農村頻道采用的是單一頻道的播出系統，除去主備播出和雙墊片占用的解碼通道，2臺LEITCH服務器提供2路VTR上載和1路矩陣上載的編碼通道。系統運行6年來，設備老化的問題逐漸增多，特別是視頻服務器的編解碼板卡老化后故障頻繁，由于過了質保期，維修或者從國外訂購新卡的周期都比較長，價格也非常昂貴，并且由于板卡內置于LEITCH服務器內部，每次操作都需要停機拆卸，相當麻煩，在操作時僅留單點播出，也會嚴重影響到播出安全。這種情況下，增加一個不依賴播出服務器的編解碼板卡的上載站點就成為了選型的重點。

考慮到原有播出系統馬上就要改造，為了避免資源的浪費和重復性建設，所采用的新上載系統將來要能適用于改造后的播出系統，按照經濟實用、安全可靠的設計思路，選用了基于文件傳輸的分布式上載方式——方正“精易”上載系統。

2 “精易”上載的工作原理以及與傳統上載的區別

2.1 “精易”上載的工作原理

傳統的上載方式主要是通過視頻服務器的上載通道，把模擬或者數字視音頻信號采集到視頻服務器中成為素材（主要是通過錄像機把磁帶上的節目采集為素材）的方式。雖然在同一個系統中的不同視頻服務器之間可以互相遷移素材，甚至可以把素材遷移到外部歸檔系統中，但這些素材無一例外都由視頻服務器自己采集得來。隨著電視臺電視技術的發展和節目量的提高，非編制作系統和媒體資產管理系統可以直接提供視音頻素材文件，以文件交換方式替代磁帶交換方式的需求也越來越多。而外部系統提供的素材要在視頻服務器中正確播出，要利用視頻服務器轉碼技術，將外部系統上的視音頻文件壓縮格式和文件打包格式都轉換為視頻服務器相同的文件格式，然后再利用視頻服務器所提供的素材遷移方法來完成素材的遷入和遷出，常見的方法是提供一個網關服務器，以FTP方式或者其他專有的方式，通過千兆以太網或者光纖把素材傳輸到服務器的存儲系統中。有的視頻服務器自帶FTP接口，可以直接將素材傳輸到服務器中播出。

轉碼網關服務器的主要功能就是將外部系統（如非編制作網或媒體資產管理系統）產生的素材通過轉碼遷移到播出系統中，成為播出系統能夠識別和播出的素材。同時，也可以將播出系統上載的素材回遷到外部系統中供編輯制作或者長期保存。典型的轉碼網關的應用場景如圖1所示。

其中，在外部系統的存儲中將開辟一塊節目緩沖區，用于存放待遷移的視音頻素材和對應的元數據文件。轉碼網關服務器需要安裝2塊千兆網卡或光纖網卡，分別連接節目緩沖區和視頻服務器存儲或者播出二級存儲，以便實現視音頻素材的交換。轉碼網關服務器訪問節目緩沖區，一般采用共享目錄的方式實現。通常情況下，轉碼網關服務器還需要安裝至少1塊百兆網卡，用于將讀到的元數據信息寫入播控系統的數據庫中，供播控系統各個模塊查詢和使用。

轉碼網關服務器上安裝了方正“精易”轉碼和遷移軟件，其主要工作流程是：

1）外部系統將準備好的視音頻素材和對應的元數據文件放到節目緩沖區，并給轉碼和遷移軟件發送通知消息；

2）轉碼和遷移軟件訪問節目緩沖區的共享目錄，讀取視音頻素材文件，通過轉碼，生成視頻服務器能夠識別的文件格式，保存到轉碼網關服務器上；

3）轉碼和遷移軟件將生成的文件通過視頻服務器的接口方法（通常是FTP方式）遷移到視頻服務器或者二級存儲系統中；

4）轉碼和遷移軟件讀取素材的元數據信息，經過處理后寫入到播控系統的數據庫中；

5）轉碼和遷移軟件記錄相應的日志信息，并把遷移結果以消息的形式通知外部系統。

“精易”上載方式就是在轉碼網關服務器的思路上，采用采集工作站的方法，通過第三方的視音頻采集卡來擴展視頻服務器的上載能力，不需要占用視頻服務器的板卡通道。在工作站上安裝專業視音頻采集卡，把錄像機信號先采集以后，以MPEG-2格式（LEITCH服務器的專用格式）進行壓縮，并封裝成視頻服務器能夠識別的格式，然后遷移到視頻服務器中。其原理如圖2所示。

2.2 “精易”上載方式與傳統上載的區別

視頻服務器的通道數量是有限的。在沒有轉碼技術之前，如果視頻服務器上載通道不夠，只能通過增加新的視頻服務器來得到足夠的上載能力，這樣往往導致系統成本的大幅提高。通過“精易”上載方式，能夠以較低的成本提供一定的素材上載能力，不占用視頻服務器的編碼通道，節約資源。

需要為廣告部等部門提供上載功能的情況下，廣告素材通常都是由廣告部人員來上載。在廣告部門離播出機房較遠的時候，直接使用視音頻信號不方便，尤其是RS-422控制線路有一定的距離限制。如果使用“精易”上載方式，只需要部署千兆以太網和百兆以太網線就可以實現素材的上載。同時，這也實現了廣告上載機房與播出機房的隔離，有益于管理。

采用傳統上載方式，效率是1∶1，即1 h的素材需要1 h的上載時間，上載完成即可以播出使用。而采用“精易”上載方式，系統效率受到工作站硬件配置和待轉碼的文件格式與視頻服務器文件格式之間的差異的限制，效率相對比較慢，必須轉碼傳輸到視頻服務器以后才能用于播出，通常情況下，從開始采集到素材遷移到服務器中，可以達到1∶1.1到1∶1.5的時間；換言之，60 h的節目，總共需要66～90 h就可以完成采集和遷移任務，傳到視頻服務器上進行播出。

3 “精易”上載的安裝步驟及數據庫環境

3.1 上載站點安裝及收錄軟件升級

原來配有2路上載，錄像機VTR1和VTR2分別用于2個上載工作站并通過422倒換開關承擔錄像機帶播任務，另外1路矩陣應急上載和上載2共用1臺上載工作站。上載1和上載2分別占用LEITCH主視頻服務器里面的CH1和CH2通道，這2個通道是由同一塊編解碼板卡提供；矩陣上載占用LEITCH備視頻服務器里的CH1通道，由另一塊編解碼板卡提供。當主視頻服務器的CH1通道出現故障后，上載1不能正常使用，上載2和矩陣上載因共用1臺工作站，只能當作1個上載使用。

拆掉上載1工作站以便在原位置安裝“精易”上載工作站，是由1臺惠普的Z400主機配1塊數字視音頻處理卡（Blackmaglc Design）組裝而成。信號調試好以后安裝“方正精易視音頻處理系統自動收錄軟件5.0版”，操作界面如圖3所示。

為了能使用新的數據庫軟件（方正精翰內容管理系統）需要將上載2和矩陣上載軟件分別從“方正無憂自動收錄系統5.0”升級為6.0版本，操作界面如圖4所示，至此工作站的安裝基本完成。

3.2 內容管理系統升級更換

由于原有的內容管理系統不能適用于新的“精易”上載，需要安裝相匹配的方正“精瀚”內容管理系統。

方正“精瀚”內容管理系統安裝分服務端和客戶端，服務端及客戶端需安裝mdac_typ.exe（Microsoft Data Access Components 2.8）及 msxmlCHS.msi（XML 分 析 程序）。服務端需安裝“啟用網絡com+訪問”組件，建議安裝“Internet信息服務（IIS）”和“ASP.NET”組件。運行“日志查詢LogViewApp”的設備還需安裝Microsoft.Net Framework 2.0或以上版本。

內容管理軟件安裝分了兩大部分，一部分是FTP服務器上的COM+組件（包括FDMFTP52，Mediaop和Taskmgr），正確安裝完成后會自動在后臺運行，另一部分是客戶端可執行程序（包括素材管理、任務察看、自動任務生成和任務執行）。組件和可執行程序都安裝在備數據庫服務器BDC上。

服務端安裝前，考慮到萬一安裝不成功可以及時恢復原來系統，不影響安全播出。創建內容管理數據庫表和基礎數據時，由于BDC是在線使用的老系統，需要先給當前PDC使用的dbas52數據庫做個完整備份（以免升級失敗無法還原老系統），然后在沒有上載、素材調度的空閑時段（至少留出3 h，選擇夜間零點進行），在原有dbas52數據庫基礎上，把“bcms20-建表語句.sql”、“bcms20-基礎數據.sql”文件先后通過SQL查詢分析器把新的數據庫表和基礎數據導入到dbas52數據庫后，對內容管理系統相關數據表進行編輯。

客戶端的安裝包括組件安裝和可執行文件的安裝。首先根據客戶端工作站的需要，把內容管理程序相應的客戶端組件運行目錄和執行文件運行目錄，分別復制到工作站的“D:Founder”目錄中，其中，客戶端組件包含“FDMFTP52”，“FDMMediaop”，“TaskMgrLib”3 個子文件夾，需要逐個安裝；客戶端執行文件包含“自動任務生成AutoTaskCreator”、“任務執行 ExecuteSvr”、“素材管理 BCMSManager”和“任務察看TaskViewEx”幾個程序，也需要分別安裝?！白詣尤蝿丈葾utoTaskCreator”程序和“自動任務執行ExecuteSvr”程序構成了內容管理系統自動任務生成和執行的核心模塊，它們通過執行一些必要的策略，承擔了素材管理的全部功能，在素材拷貝期間不能關閉，而“素材管理BCMSManager”和“任務察看TaskViewEx”程序打開或關閉并不直接影響自動任務的生成和執行。較為通用的“自動任務策略AutoTask.POL”文件主要包含了“播出準備，根據節目單從二級存儲向播出服務器遷移”、“播出準備，根據播出日期從二級存儲向播出服務器遷移”、“播出準備，根據段落包從二級存儲向播出服務器遷移”、“回遷：主備播出服務器到二級存儲”、“主備同步，主播出服務器和備播出服務器之間”、“播出服務器刪除”、“清除播出主備回收站”、“二級存儲回收站”、“二級存儲回收站清空”等任務策略，在緊急情況下也可以手動執行這些策略。

4 “精易”上載和傳統上載的兼容性分析和調試過程

“精易”上載系統是通過交換機的網線來傳輸文件的，而傳輸的實施最終還是要通過“精翰”內容管理系統的策略執行來控制。這樣的上載方式和內容管理系統主要是面向模塊化設計的新型服務器設計的，運行的環境也比較適合于新的操作系統。而原有的LEITCH服務器是已經停產2年的老款服務器，備數據庫的操作系統也僅僅是Windows 98，所以按照既定的步驟正確安裝后，還是出現了一些問題，以下就通過這些問題的解決過程來看一下軟件的兼容性。

1）“精易”上載過的部分節目，打包上傳成功并主備鏡像后，發現文件只有首幀畫面，其余全部為黑場。出現這樣的情況時，原本需要幾十秒甚至幾分鐘才能打包上傳成功的素材瞬間就能完成，上傳的文件大小也比正常的小很多，這種情況如果不能及時解決，對于安全播出將是致命的威脅。把原來“本地打包、直接上傳到視頻服務器”的方式改為“本地打包、上傳到本地、再通過策略拷貝到視頻服務器”的方式，將“精易”工作站本地的1 000 Gbyte硬盤當作二級存儲，雖然在文件傳輸環節增加了拷貝的時間，但是由于素材打包和上傳都在本地進行，減少了傳輸網絡對打包的影響。事實證明這樣的思路是對的。

2）“精翰”內容管理不能執行主備拷貝任務，通過FTP底層程序手動拷貝也沒成功。通過察看LEITCH服務器的詳細資料，得知LEITCH服務器所能提供的FTP站點是有限制的，“精易”上載、主備播出工作站和主備數據庫在工作時都要占用FTP站點，原有設備配置時剛好夠用，目前多加了1個“精易”上載后，就出現了2個設備爭1個FTP站點的現象。考慮到LEITCH服務器的FTP站點不可能增加，最終修改了播出工作站的查詢方式，由原來的主備工作站通過FTP站點都查詢主備視頻服務器改為主工作站只查詢主視頻服務器、備工作站只查詢備視頻服務器，從而可以釋放出1個FTP站點給“精易”上載使用，修改后運行1個月來，素材拷貝全部正常。

3）用“精易”上載過的節目和傳統方式上載的節目順序播出時，偶爾會在中間加1幀黑場。通過對比視頻服務器里面的素材，發現用傳統方式上載的素材GoP長度為15位，而用“精易”上載的素材GoP只有12位，通過與軟件開發人員的溝通，對“精易”上載程序5.0版本進行了修改，通過后面的觀察，情況得到了改善。

4）傳統上載方式是1∶1上載，上載結束審看通過就可以用于播出，而“精易”上載完成后，要打包上傳到本地再拷貝到視頻服務器才能用于播出，時間大于1∶1，所以對于當天緊急播出的節目，最好選用傳統上載方式，而如果必須要用“精易”上載的，則需要提前算好時間，必要時手動拷貝到主視頻服務器再播出。

5）原來的2臺上載用錄像機既可用于上載，又能通過422開關進行帶播，VTR1改為“精易”上載使用后，不再受422開關控制，如果有帶播任務只能選擇VTR2，出現2盤帶播的情況，則需要對VTR1進行手動播出，安全系數大大降低。

5 結束語

板卡上載歸屬于傳統視頻的線性思考，而分布式的上載采用了網絡的非線性思考。傳統方式上載相對穩定，直接進入播出視頻服務器，播出文件所見即所得，缺點是性價比較低，與視頻服務器板卡連接方式較死板。而分布式的上載優勢是相對于昂貴的播出視頻服務器上載板卡成本的降低，及其在部署地點靈活性和數量上的可擴展性。在電視臺播出系統上載的實際應用可以根據兩者的差異和自身生產節目的特點，同構或者異構使用，以求達到更高的播出上載的安全要求和系統配置的經濟性。