數(shù)字視頻網絡間采用文件方式傳輸節(jié)目數(shù)據的可行性分析

數(shù)字視頻網絡間采用文件方式
傳輸節(jié)目數(shù)據的可行性分析

摘要：
    本文從節(jié)目制作網絡和硬盤播出系統(tǒng)的連接方案入手，探討了數(shù)字視頻網絡間連接的三種工作模式：采用磁帶作為介質傳輸數(shù)據，采用流方式傳輸數(shù)據和采用文件方式傳輸數(shù)據。詳細分析了這三種模式的優(yōu)缺點，進而論證了采用文件方式在數(shù)字視頻網絡間傳輸節(jié)目數(shù)據的可行性和合理性。并分析了工程中采用文件方式在數(shù)字視頻網絡間傳輸節(jié)目數(shù)據所需面對的問題及解決方案。本文還提出了使用文件方式在數(shù)字視頻網絡間傳輸節(jié)目數(shù)據的具體可行方案，同時探討了利用文件方式傳輸數(shù)據在節(jié)目集中上載和衛(wèi)星節(jié)目收錄方面的應用前景。

關鍵字：
    數(shù)字視頻網絡、節(jié)目制作網絡、硬盤播出系統(tǒng)、磁帶、流、文件、MPEG、TCP/IP、FTP、集中上載系統(tǒng)、媒體資產管理

Abstract:
    This paper described three interaction types of digital video network. Interacting by magnetic tape, by media stream and by files. We analyzed the advantages and shortages of this three interaction types of digital video network, then conclude that interacting by files is the best way in this three types. We also analyzed the problems we must face when we use this method interacting in digital video networks, and gave the solutions. This paper gave an exercisable project about interaction by files type in digital video networks, and described this method implements in other fields, just like programs upload system, satellite transmission and so on.

Keyword:
    Digital video network, Program network, Broadcast server, Magnetic tape, Media stream, File, MPEG, TCP/IP, FTP, Programs upload system, Media management system.

    數(shù)字視頻網絡給電視業(yè)者帶來的變革已經毋庸置疑了。許多電視臺都在考慮或正在使用非線性視頻編輯環(huán)境全面的替換傳統(tǒng)視頻編輯環(huán)境，使用硬盤播出系統(tǒng)取代磁帶播出的方式。媒體資產管理系統(tǒng)有著被所有人看好的前景，硬盤錄像機和藍光盤技術在攝錄設備中已經開始應用。非常明顯，很快數(shù)字非線性視頻編輯技術就會占領電視節(jié)目制作播出環(huán)境的各個環(huán)節(jié)。
    這樣會帶來一個問題，或者說是一系列問題，在一個制播環(huán)境中，不同的系統(tǒng)設備環(huán)節(jié)如何相互交換數(shù)據。
    比如我們有這樣的一個制播環(huán)境，每個橢圓代表不同的功能模塊。如圖-1所示：
該制播環(huán)境由節(jié)目源、節(jié)目制作網絡、硬盤播出系統(tǒng)、節(jié)目存檔或媒體資產管理系統(tǒng)(這里所指的媒體資產管理系統(tǒng)，主要是以媒體資產查詢管理為主，不是指包括采編播查詢一體的廣義上的媒體資產管理)以及遠程節(jié)目系統(tǒng)組成，這樣的制播環(huán)境代表了國內大部分電視臺的現(xiàn)實情況或發(fā)展方向。

    節(jié)目制作網絡是數(shù)字視頻網絡毋庸置疑。硬盤播出系統(tǒng)包括了分散的節(jié)目上載系統(tǒng)，集中的存儲單元和數(shù)據庫管理體系，視頻流輸入輸出接口，具備了一個視頻網絡幾乎所有的要素。所以從嚴格意義上來講，硬盤播出系統(tǒng)也是一種視頻網絡。利用信息技術的節(jié)目存儲系統(tǒng)和媒體資產管理系統(tǒng)也是相對獨立的數(shù)字視頻網絡。而隨著硬盤錄像機和藍光盤技術的應用，前期設備也將會脫離單機單任務操作的狀態(tài)，加入視頻網絡的環(huán)境中。
    從發(fā)展的角度來看，制播環(huán)境各個環(huán)節(jié)如何連接的問題，其本質上就是數(shù)字視頻網絡之間如何有效傳輸數(shù)據。他們之間如何連接交互數(shù)據，反映了不同類型的視頻網絡相互傳輸數(shù)據所需面對的問題。
也許有人會說，采用制播一體化網絡不就不存在這種問題了嗎？這在理論上是完全正確的。使用同一廠商的視頻網絡搭建整個電視臺的制作播出存儲系統(tǒng)，使用統(tǒng)一的硬盤存儲陣列和管理數(shù)據庫系統(tǒng)管理節(jié)目制作、播出和存儲系統(tǒng)，使用播出服務器替換原有制作網絡的下載端口，理論上的確可以節(jié)省設備投資，減少數(shù)據流環(huán)節(jié)并提高工作效率。
    但是，從實際工程角度來看，卻遠遠不是如此簡單。比如對播出安全性的高要求使得必須給于播出系統(tǒng)足夠的系統(tǒng)冗余，獨立的存儲系統(tǒng)，相對封閉的管理空間，大容量的數(shù)據吞吐能力和演播室信號的直播處理能力。完全滿足以上要求會導致一個硬盤播出系統(tǒng)的設備預算不會比具有相應支持能力的節(jié)目制作網絡低多少。同樣，一個基于信息技術，滿足要求的節(jié)目存儲查詢系統(tǒng)其本身也是一個完整的數(shù)字視頻網絡。而對于一個功能獨立的硬盤播出系統(tǒng)或節(jié)目存儲查詢系統(tǒng)而言，它和節(jié)目制作網絡的交互數(shù)據其實已經是兩個視頻網絡之間的連接了。即使這些環(huán)節(jié)是由同一廠商開發(fā)設計，也必須面對網絡間互聯(lián)的問題。除此之外，我們還必須考慮到遠程節(jié)目網絡的擴展問題。
    從另一個角度來看，廠商當然是希望做制播一體化網絡，因為可以拿到成倍金額的合同，他們甚至希望用一個統(tǒng)一的、大而全的媒體資產管理系統(tǒng)涵蓋采編播的所有環(huán)節(jié)，拿下所有的訂單。但從用戶的角度而言，大而全的網絡就意味著要對自己的設備環(huán)境進行全面的更換，并且保持一致，為了遷就某一廠商在某一領域的優(yōu)勢而忍受其在其他領域內的缺陷。同時一體化網絡所帶來的巨額設備投入也不是中小型電視臺所能夠承受的。
    從工程技術角度來看，在系統(tǒng)設計時應考慮到系統(tǒng)各個環(huán)節(jié)發(fā)展的不平衡性。分散的模塊化的設計思路比整體統(tǒng)一的設計思路更加具有靈活性和可擴展性，并可減少工程周期過長、一次性投資過大帶來的技術被動。
    所以本文希望從工程角度出發(fā)，探討如何在相對獨立的數(shù)字視頻網絡間建立連接，便捷、高效的進行數(shù)據交互。
    從工程上看，我們有三種方法可以做到相互獨立的數(shù)字視頻網絡之間的互聯(lián)，進行節(jié)目和信息的交換：一、使用磁帶或磁盤等獨立存儲物理介質作為網絡間節(jié)目和數(shù)據交換的載體；二、使用數(shù)據流作為交換的載體；三、使用文件作為交換的載體。
以下分別說明：
    第一種方法是使用磁帶或類似的記錄工具作為數(shù)據交換載體，這是最簡單方法也是現(xiàn)在最普遍的做法。在不同的視頻網絡之間以磁帶作為中轉介質。節(jié)目源使用錄像帶上載節(jié)目素材到節(jié)目制作網絡中，經過網絡編輯完成用于播出的節(jié)目成片后通過下載端口下載到錄像帶上，由專人送交到播出機房或者節(jié)目存檔系統(tǒng)。播出機房將送交的節(jié)目播出帶上載到硬盤播出服務器中，編目存儲用于播出，節(jié)目存檔系統(tǒng)或媒體資產管理系統(tǒng)將磁帶信息再次數(shù)據化。
如圖-2所示。

    此種工作方式的好處是各個環(huán)節(jié)在物理完全獨立，通過磁帶作為環(huán)節(jié)間數(shù)據傳送的媒介，不需考慮不同環(huán)節(jié)設備之間的接口協(xié)議，也不需考慮各個環(huán)節(jié)內部的文件壓縮格式和交換格式，只要統(tǒng)一磁帶格式即可。各個環(huán)節(jié)相互獨立的另一個好處是相互之間不會產生影響，安全性和可維護性較好。
    但這種工作方式的優(yōu)點卻帶來了它致命的缺陷，即節(jié)目大量上下載所帶來的時間浪費，多次壓縮解壓和設備接口帶來的信號損失。
    我們舉例說明。比如用戶編輯一小時的節(jié)目成片，需用兩個小時的節(jié)目素材，那么用戶就必須按照以下工作步驟進行節(jié)目制作：首先用戶需花費兩個小時用于節(jié)目素材上載。編輯完成后，花費一小時的時間將節(jié)目下載到磁帶上。將節(jié)目磁帶送交播出機房，由播出機房花費一小時時間將節(jié)目上載到播出服務器的存儲陣列中，編目用于播出。播出完成后的節(jié)目帶送到節(jié)目存儲系統(tǒng)中。不計編輯時間和節(jié)目磁帶送交所花費的時間，一小時的節(jié)目從制作到播出，僅僅用于上下載的時間就需要四個小時，四倍于節(jié)目時長。如果節(jié)目存儲系統(tǒng)也是基于數(shù)據存儲技術的話，那么將花費更多的時間在磁帶數(shù)據的上下載方面。
    這里需要說明的是，雖然現(xiàn)在的有的廠商推出高速上載和傳輸設備，但對這種工作方式的幫助并不大。基于SDTI接口的設備提供2~4倍的磁帶讀取速度，實現(xiàn)產品化的只有2倍速傳輸接口，同時需要板卡或視頻服務器支持。由于受到磁頭技術及工藝的限制，磁帶類設備的高速上載并無良好的前景，筆者認為在磁帶的范疇內討論高速上載其意義和前景不大。
    再來看看信號質量的損失，一個節(jié)目上載到非線性節(jié)目編輯網絡，需要進行一次編碼壓縮，比如說壓縮成MPEG-2全I幀50Mbps或30Mbps碼流的視頻文件，用于后期編輯。節(jié)目后期編輯工作完成后，需將視頻文件解壓縮成SDI或模擬分量\復合信號下載磁帶上，由專人將磁帶送交到播出機房，壓縮成MPEG-2 長GOP 8 Mbps或相近碼流的視頻文件，上載到播出服務器的存儲硬盤陣列存儲，解碼后用于播出。另外信號每過一次錄像機設備就要經過一次編解碼過程，其多次編解碼和由于上下載接口所帶來的信號質量下降不可避免。以使用SDI接口的錄像機為例，如圖-3所示。
    可以看出，在單純的制播網絡化環(huán)境中一個節(jié)目從素材到成片，從編輯到播出，需要四倍于節(jié)目時長的時間用于上下載工作，經過三次編碼和四次解碼，三次使用SDI信號傳輸數(shù)據。而這些時間、人力和設備資源投入的大量消耗，僅僅是為了實現(xiàn)視頻網絡間數(shù)據傳輸。而多次的壓縮編解碼和設備接口也會帶來信號質量不可避免的損失。以上所述還未包括節(jié)目存儲和媒體資產管理系統(tǒng)，對節(jié)目存儲和媒體資產管理系統(tǒng)媒體資產管理系統(tǒng)可能帶給整個制播環(huán)節(jié)的影響尚未考慮在內。

    從整體上來看，在這種方式下工作，數(shù)字視頻網絡所帶來的集中、共享、設備資源消耗少和高效的優(yōu)勢，在網絡間大量利用磁帶上下載的過程中幾乎消失殆盡。
    對于使用磁帶作為數(shù)字視頻網絡間數(shù)據交互的方式而言，使用數(shù)據流作為網絡間數(shù)據交互的方式更加理想一些。
    下面仍然以節(jié)目制作網絡和硬盤播出系統(tǒng)連接傳遞節(jié)目數(shù)據為例，說明如何采用流的方式進行不同數(shù)據視頻網絡之間的數(shù)據交互。
    筆者參與過這樣一個工程：為了解決非線性新聞制作網絡向播出機房傳送節(jié)目的問題，在非線性新聞節(jié)目制作網絡和播出機房的播出服務器之間，設計并架設了一條SDI通道。這其實上是視頻網絡之間交換數(shù)據的第二種方式，采用流的方式傳送數(shù)據。其拓撲結構如圖-4所示。

    在這種工作方式中，上傳工作站是網絡里的一個有卡工作站，可以回放編輯完成的節(jié)目成片。采集控制工作站是硬盤播出系統(tǒng)的一個節(jié)目上載控制站點，它可以控制視頻采集通道矩陣中某個通道的工作狀態(tài)。我們分別在上傳工作站和采集控制工作站上安裝以太網卡，使用雙絞線，利用TCP/IP協(xié)議建立了一個點對點的控制流通道。利用視頻線在上傳工作站和硬盤播出系統(tǒng)的采集工作站之間建立了一個SDI數(shù)據流通道。這種連接方式在某種意義上來說有點兒類似遠程采集系統(tǒng)。
    在節(jié)目制作完成之后，節(jié)目制作網絡通過上傳工作站的控制流通道向遠端的采集控制工作站發(fā)送上傳請求和所需上傳的節(jié)目信息，并準備開始回放制作完成的節(jié)目；采集控制工作站得到請求后檢測視頻采集通道的工作狀態(tài)是否正常，如檢測正常可以進行采集，就開啟視頻采集通道的采集功能，根據節(jié)目信息進行節(jié)目采集，同時通過控制通道返回應答信號；上傳工作站在接到應答信號后開始回放節(jié)目，通過SDI流傳送到視頻采集通道進行節(jié)目上傳；視頻采集通道結束采集工作后，采集控制工作站返回結束信號給上傳工作站，結束上傳工作。
    這種工作方式的最大好處是在工作流程中去掉了磁帶這個中間環(huán)節(jié)，節(jié)省了大量的上下載時間和送磁帶所消耗的人力物力，并且減少了編解碼環(huán)節(jié)和錄像機設備接口對信號質量的損傷。如圖-5所示。

    從圖-5可以看出，這種工作方式比使用磁帶的工作方式減少了一次節(jié)目下載時間，一次編碼過程和一次解碼過程，并且免去了磁帶的人手傳遞，減少了接口設備可能對節(jié)目數(shù)據的影響。相對與使用磁帶的方式大大提高了工作的效率。
    但這種工作方式還是具有明顯的缺陷：在這種工作方式下采集和傳送必須同時進行，其數(shù)據交換過程不可中斷，數(shù)據傳輸過程中如有錯誤必須從頭重新進行，靈活性較差；數(shù)據傳輸依然是實時進行，無法進行高速傳輸；傳輸節(jié)目時必須完全占用硬盤播出系統(tǒng)的一個視頻采集通道。
    其它使用數(shù)據流的方式在不同的數(shù)字視頻網絡間交互數(shù)據的工程，具體設備、接口和控制方式可能有所不同，但工作模式應和上述節(jié)目制作網絡和硬盤播出系統(tǒng)的連接相同或相似�？梢钥闯霾捎昧鞣绞皆跀�(shù)字視頻網絡間傳輸數(shù)據，就像使用電話一樣，首先建立握手關系，然后獨占通道和時間進行數(shù)據交互。
這種方式還有一個好處，就是使用統(tǒng)一的通道傳輸數(shù)據，不用理會通道兩端的數(shù)據結構如何。比如在SDI通道作為數(shù)據流通道的前提下，我們使用的節(jié)目制作網絡和硬盤播出系統(tǒng)可以采用完全不同的數(shù)據壓縮方式，無論是M-JPEG、MPEG-2還是DVC50，只要提供SDI接口即可進行網絡間的數(shù)據傳輸。
    這里牽扯出另外一個問題，如果兩個數(shù)字視頻網絡采用同樣的數(shù)據壓縮結構，我們還需要通過SDI這樣的接口嗎？
    這個問題可以由數(shù)字視頻網絡間交互數(shù)據的第三種方式來解答，即使用文件方式在數(shù)字視頻網絡間交互數(shù)據。
    使用文件方式傳輸節(jié)目數(shù)據，一個重要的前提是傳輸雙方的數(shù)據文件壓縮格式可以為對方所識別。這看起來并不難達到，因為大部分視頻廠商都提供M-JPEG、MPEG2、DVC25、DVC50等主流的壓縮格式，但實際在工程中不同廠商的不同產品，甚至同一廠商不同系列的產品，其文件格式都不兼容。
    下面我們先介紹如何利用文件方式在數(shù)字視頻網絡間交互數(shù)據，其優(yōu)勢和不足，然后對如何解決基于不同文件格式的數(shù)字視頻網絡之間交互數(shù)據進行分析。
    以本文開始所描述的網絡結構為例，對采用文件方式在視頻網絡間傳送節(jié)目素材進行分析。我們仍然以節(jié)目制作網絡和播出機房的連接為例，設計這樣一個工程方案，其拓撲結構如圖-6所示。
    我們假設該工程中節(jié)目制作網絡和硬盤播出服務系統(tǒng)使用的是同種壓縮格式，即均為MPEG-2或DVC50，并且節(jié)目制作網絡可以提供符合播出要求碼流的壓縮文件，例如MPEG2 8M碼流的長GOP文件（很多視頻板卡都可以根據用戶需求提供不同碼流的數(shù)據文件）。
    這種工作模式實質上是在數(shù)字視頻網絡間建立高速數(shù)據傳輸通道（光纖或千兆以太），利用TCP/IP協(xié)議組中的FTP(文件傳輸協(xié)議)在數(shù)字視頻網絡間以文件方式傳輸視頻數(shù)據。

    在我們設計的節(jié)目網和硬盤播出服務器的連接方案中，使用一臺帶有FC接口和告訴FTP接口（光纖或千兆以太接口）的計算機設備作為節(jié)目制作網絡的網關。使用光纖網卡或千兆以太接口與硬盤播出系統(tǒng)的網關設備連接。在該網關（即上傳工作站）上建立一個FTP服務器。硬盤播出系統(tǒng)通過FTP登陸的方式訪問該網關，將節(jié)目制作網絡產生的，可以為硬盤播出系統(tǒng)所識別的，滿足播出要求的視音頻文件拷貝到播出服務器的硬盤存儲陣列中，經過編目加入播出列表程序后用于播出。其數(shù)據結構流程如圖-7所示。

    由圖-7可以看出，使用文件方式進行數(shù)字視頻網絡間節(jié)目數(shù)據傳輸，實質上是將節(jié)目制作網絡中的節(jié)目數(shù)據文件直接用于播出。這種方式比采用流方式可以減少一次編碼解碼的過程，而且由于是文件到文件的傳輸方式，可以完全排除外界因素對視頻信號質量的影響。

    采用FTP文件方式傳輸數(shù)據，可以完全根據通道的數(shù)據流量來考慮傳輸時間，而不需要根據具體節(jié)目或視頻文件的時長，以千兆網卡為例，1000Mbps速度傳輸8M碼流的MPEG-2長GOP，理論狀態(tài)下滿通道占用可以達到1000/8=125倍的傳輸速度，即1小時的節(jié)目需要半分鐘左右就可以傳輸完畢。當然這是一種理論狀態(tài)，工程中涉及到網絡連接的實際傳輸速率，文件的結構、磁盤讀寫速度等因素使傳輸速度不可能達到上述理論狀態(tài)，但對于以8M碼流的視頻文件而言，至少可以達到20~30倍的傳輸速率，即1小時時長的節(jié)目在2~3分鐘之內可以傳輸完畢。同時在一個通道內可以傳輸多個節(jié)目文件。另外該方式還有一個好處，幾乎所有的FTP服務軟件均支持斷點續(xù)傳功能，這樣就可以避免出現(xiàn)流方式傳輸時遇到錯誤必須從頭重新傳輸?shù)膯栴}。

    這種工作方式在工程比使用流方式傳輸視頻更容易實現(xiàn)。流文件傳輸需要編寫建立雙方專有的通訊軟件，采用握手的方式交互數(shù)據，就像電話一樣，一方不接聽雙方就不能通話。而對于文件方式傳輸只需在發(fā)送方建立一個FTP服務器目錄，將所需要傳輸?shù)囊曨l文件放進目錄里，接受方根據需要，自由選擇時間從該文件目錄中獲取文件，這種方式和從互聯(lián)網上下載文件是完全相同的。在本文所舉工程例子中，節(jié)目制作網絡可以采用一臺普通的計算機作為FTP服務器。FTP服務器軟件幾乎所有的操作系統(tǒng)都提供支持，例如Windows 2000中就自帶IIS系列的FTP服務器。對于硬盤播出系統(tǒng)可以使用其異步接口板卡或部件作為網關，如Pinnacle MediaStream系列視頻服務器使用Mediastream connectplus部件作為其千兆異步接口,支持標準的FTP協(xié)議，而SONY的MAV-70、MAV-555系列服務器也可以通過分別加配BKMA-7045和BKMA-550板卡提供千兆異步接口，支持標準的FTP協(xié)議。在這種工作模式下，節(jié)目網絡和硬盤播出系統(tǒng)均不需要對自己內部的數(shù)據結構和管理方式進行改造，只需要通過千兆異步接口，采用文件到文件的方式傳輸視頻素材即可。

    我們下面可以采用表格的方式對上述三種數(shù)字視頻網絡間節(jié)目數(shù)據傳輸方式進行對比。我們選用三種不同壓縮碼率的節(jié)目視頻文件作為對比的參照，以上述節(jié)目制作網絡向硬盤播出系統(tǒng)傳送節(jié)目為例，從上載到播出各個環(huán)節(jié)進行比照。

    假設節(jié)目制作網絡可以提供MPEG-2 全I幀 50 Mbps碼流、MPEG-2 全I幀 30 Mbps碼流和MPEG-2 IBBP幀 8 Mbps碼流三種壓縮格式的視頻節(jié)目成品文件，以上文件均可為硬盤播出系統(tǒng)所識別和使用。

    表-1現(xiàn)顯三種傳輸方式在傳輸各個環(huán)節(jié)的特性，表-2對比了三種不同的MPEG-2壓縮方式在三種傳輸方式下各自的特性參數(shù)。

表-1：

通道類型 使用錄像機上下載次數(shù) 使用SDI信號次數(shù) 編解碼次數(shù) 傳輸速度是否可變 是否需要手工干預 可否共用傳輸通道 傳輸速度與壓縮方式是否有關 磁帶方式傳輸數(shù)據 SDI接口錄像機 3次 3次 7次 否 是 是 否 流方式傳輸數(shù)據 SDI通道 1次 2次 5次 否 否 否 否 文件方式傳輸數(shù)據 千兆以太（光纖） 1次 1次 3次 是 否 是 是

表-2 ：

壓縮方式 碼流 節(jié)目視頻文件大小/每小時 通道方式 通道帶寬 理論每小時節(jié)目傳輸時間 實際每小時節(jié)目傳輸時間 磁帶方式 流方式 文件方式 磁帶方式 流方式 文件方式 磁帶方式 流方式 文件方式 磁帶方式 流方式 文件方式 MPEG-2 全I幀 50Mbps 22.5GB 人工 SDI 千兆以太 無 270Mbps 1000Mbps 2小時 1小時 180秒 遠大于2小時 接近1小時 400秒 MPEG-2 全I幀 30 Mbps 13.5GB 人工 SDI 千兆以太 無 270Mbps 1000Mbps 2小時 1小時 180秒 遠大于2小時 接近1小時 240秒 MPEG-2 IBBP幀 8Mbps 3.6GB 人工 SDI 千兆以太 無 270Mbps 1000Mbps 2小時 1小時 29秒 遠大于2小時 接近1小時 64秒

注:1文件大小的計算方法為 文件大小≈碼流Mb/s×60s×60÷8B/b
2文件大小的計算忽略了相對數(shù)據量很小的文件包裝數(shù)據和音頻數(shù)據
3理論傳輸時間根據1000Mbps帶寬計算,實際傳輸時間根據實際450Mbps速率計算。

表-2

    由以上兩個表格可以清楚地看到這采用這三種工作方式在數(shù)字視頻網絡間傳輸節(jié)目數(shù)據的各自特點，而采用文件方式與前兩種方式對比，具有傳輸環(huán)節(jié)少、速率快、靈活性強、可以同時執(zhí)行多任務，信號損失少及工程實現(xiàn)簡單等多種優(yōu)勢。

    既然采用文件方式的優(yōu)勢如此明顯，那我們所有的所有視頻網絡都通過這種節(jié)目方式傳輸節(jié)目或視頻不就完了？但問題也并非如此簡單，我們希望再通過一個工程例子來說明采用文件方式在數(shù)字視頻網絡間交互數(shù)據所面對的問題，并探討解決方案的可行性。

    該例子是一個已經產品化的集中上載的工程。節(jié)目制作網絡規(guī)模的日益膨脹導致單機上載的工作模式已經無法滿足大電視臺的胃口了，所以集中上載作為制作網絡的一項功能需求被提了出來。該工程在本質上其實就是一個采用文件方式在數(shù)字視頻網絡間交互數(shù)據的范例，它所面對的問題和解決方案在某個層面上反映了我們想要探討的，使用文件方式在數(shù)字視頻網絡間交互數(shù)據所需解決的問題。

該工程方案如下：

    該方案的工作原理是利用帶存儲單元的多通道視頻服務器，作為集中上載的第一個環(huán)節(jié)，視頻輸入通道分別與錄像機、攝像機等傳統(tǒng)前期節(jié)目相連。錄制控制工作站通過422控制矩陣控制視頻服務器的輸入通道進行節(jié)目素材上載，以視頻服務器所提供的視頻文件格式存儲在服務器本機存儲單元內。視頻服務器利用千兆異步接口通過網關與千兆以太交換機連接，利用標準的FTP協(xié)議將服務器內的視頻文件通過轉碼工作站傳輸至節(jié)目制作網絡的硬盤存儲陣列中，提供給編輯環(huán)境進行編輯制作工作。轉碼工作站是一臺帶有千兆以太及FC接口的高性能計算機，視頻文件通過千兆以太接口進入轉碼工作站，經過處理后通過FC端口輸出至節(jié)目制作網絡的硬盤存儲陣列。轉碼工作站所做得工作是在視頻文件的拷貝過程中改變文件的格式，將視頻文件由視頻服務器所支持的文件格式轉換為編輯環(huán)境所識別和可使用的視頻文件格式。

    這種工作方式建立后，具有極強的靈活性。傳統(tǒng)使用SDI、模擬復合分量接口的設備可以使用視頻服務器連接上載，而對提供千兆以太接口的設備，如硬盤錄像機、SONY的e-VTR及基于文件系統(tǒng)的藍光盤攝錄設備，都可以通過標準的千兆以太接口和集中上載系統(tǒng)中的千兆交換機連接，通過422控制或以太網絡和控制環(huán)節(jié)連接。可以方便的利用FTP方式進行高速文件上載的工作，并且在加入這些設備時，對集中上載的系統(tǒng)配置和控制操作無需進行大的調整或更改。

    也許有人會問：如果大家都使用同樣的壓縮方式，那為什么還要使用轉碼工作站？使用文件到文件的直接拷貝，把視頻服務器的文件拿來，直接拷貝到節(jié)目存儲網絡的硬盤存儲陣列中使用不是更有效率？這個看似有點兒可笑的問題，卻引出了利用視頻服務器集中上載工程方案，或者說是使用文件方式在數(shù)字視頻網絡間進行節(jié)目數(shù)據傳輸所需面對的最大困難：即不同的廠商提供的視頻文件格式互不兼容。

    所有的視頻產品服務商都不買別人的帳，我的服務器有我自己的文件格式，你的板卡有你的專用板卡文件格，即使大家都具有相同的壓縮方式，彼此的視頻文件也互不兼容。更有甚者，有時候同一廠商不同系列的產品采用的文件格式也都互不兼容。比如上述工程如果使用的SONY的MAV系列視頻服務器，采用MPEG-2 全I幀 50 Mbps碼流壓縮方式。編輯環(huán)境使用的Matorx Digisuite DTV系列的板卡，雖然DTV板卡本身即支持MPEG-2 全I幀 50 Mbps碼流壓縮方式，我們仍然需要將SONY的文件格式轉換為Matrox 所支持的文件格式，。這種文件格式的轉化其實并不涉及到MPEG-2的重新編碼和解碼，只是將文件的包裝格式和標示標志進行改變，重新打包，使之可以為Matrox Digisuite DTV板卡所識別和使用。如圖-9所示。

    由圖可以看出，在轉碼過程中對視頻數(shù)據部分（包括音頻部分）未作任何改動，只是對視頻文件的文件包裝格式進行了改變。視頻文件依然采用的是FTP方式進行數(shù)據遷移，在數(shù)據遷移的過程中將視頻文件的一些標志性參數(shù)和格式進行了更換。這項工作從實際工程方面相當?shù)暮唵�，其面對的主要問題是廠商對自有文件包裝格式的開放問題。我們從工程上可以從兩個方面考慮努力解決這個問題：

一、 建立統(tǒng)一的視頻文件格式。

    這個方向當然是最理想的工作方式。所有的文件都采用通用的文件格式，無需轉碼就可以為不同廠商的設備所識別和使用。那么轉碼工作站就沒有存在的必要了，直接采用文件到文件拷貝的方式既可。但實際上這項工作的難度很大，涉及到標準的制定，廠商相互的利益因素，所以最理想的方式也是最難實現(xiàn)的方式。

二、 不同廠商的設備相互識別對方的文件格式。

    這是個退而求其次的方式，我們沒有統(tǒng)一的標準，但我們可以相互識別對方的標準。你的文件可以為我所用，我的文件也可以為你所用。但這種方式依然收到廠商相互利益的制約。

    所以在現(xiàn)有的環(huán)境下，轉碼作為數(shù)字視頻網絡間采用FTP交互數(shù)據的中介，是解決不同文件格式的數(shù)字視頻網絡之間節(jié)目數(shù)據交換問題比較理想的解決方案。

    很多視頻廠商也開始注意到了使用文件方式在數(shù)字視頻網絡間傳輸數(shù)據的優(yōu)越性，開始考慮文件的兼容問題，并且在硬件上提供千兆以太的接口和FTP的協(xié)議。比如SONY的MAV系列服務器均提供千兆異步接口，PINNACLE 提供MediaStream connectplus設備作為MediaStream系列服務器的千兆以太接口；MPEG IMX系列錄像機可通過加裝備卡提供千兆接口升級為網絡錄像機e-VTR，e-VTR網絡錄像機在應用中就是在網絡中使本機成為一個FTP服務器，網絡上其他的節(jié)點通過FTP的方式傳輸節(jié)目數(shù)據。

    采用文件方式在衛(wèi)星節(jié)目傳輸上也已經有了很好的應用，國內不少節(jié)目制作公司通過衛(wèi)星將已經完成的節(jié)目視頻文件傳輸給電視臺接受終端，由終端解壓縮后下載或編輯，而不是通過傳統(tǒng)的直接解碼輸出流的方式經直接錄制到錄像帶上。

    如圖-10。接收終端是一臺計算機，它帶有一塊TS流接收板卡和一塊視頻解壓縮板卡，視頻壓縮卡的種類取決于所傳輸?shù)囊曨l文件的壓縮的方式（MPEG-2、MPEG-4）。TS流接收板卡可以接受衛(wèi)星TS流，將節(jié)目視頻文件從TS流中解出后存儲在本地硬盤中。存儲完成后，用戶可以根據需要隨意選擇時間通過視頻解壓縮板卡輸出節(jié)目視頻。

    我們可以看出，這種傳輸方式實質上和本文前面所說的節(jié)目制作網絡和硬盤播出系統(tǒng)連接傳輸數(shù)據的方式是一模一樣，都是通過文件到文件的方式傳輸節(jié)目素材視頻文件。我們如果在該工作站點上加裝一塊千兆以太板卡，通過網關和其他的數(shù)字視頻網絡連接，就可以省去節(jié)目下載到磁帶這一步驟，又可以節(jié)省人力、時間和設備資源，大大的提高工作效率。

    現(xiàn)在我們可以回頭看看本文開始時所提出的問題，在一個制播環(huán)境中，不同的數(shù)字系統(tǒng)系統(tǒng)設備環(huán)節(jié)如何相互交換數(shù)據。我們可以采用以下的方式。

    通過交換機設備將各自分割、功能獨立的制播環(huán)節(jié)連接起來，使用文件到文件的方式，通過高速通道交互節(jié)目數(shù)據，在保持各個環(huán)節(jié)功能和控制獨立的情況下，達到資源的共享和系統(tǒng)擴展，提高工作效率。

總結

    千兆以太、FTP這些技術在IT業(yè)中已經研究多年，技術已經相當成熟，市場上也有了很多性能價格比非常好的產品。本文所述的幾個工程方案，在網絡連接方面的投入是非常少的，與視頻領域內動輒數(shù)十萬、上百萬的高端設備不可同日而語。而基于這種技術的采用文件方式在數(shù)字視頻網絡間傳輸節(jié)目數(shù)據的工作方式，更由于其工作方式簡單，投入少，可維護性好及具有成熟的技術支持等優(yōu)勢必將成為數(shù)字視頻網絡間交互數(shù)據的主流方式。同時我們想通過本文像讀者表明這樣一個觀點：在視頻領域技術的發(fā)展中，如何利用其它領域內已經成熟和普及的技術，如FTP技術、硬盤陣列、光盤技術等，為新興的高端數(shù)字視頻設備所利用和開發(fā)，從而達到事半功倍的效果，是一個非常值得我們認真探討的問題。

【數(shù)字視頻網絡間采用文件方式傳輸節(jié)目數(shù)據的可行性分析】相關文章：

數(shù)字視頻網絡分析08-06

藍牙基帶數(shù)據傳輸機理分析08-06

數(shù)字視頻信號的長線傳輸08-06

數(shù)字視頻網絡08-06

采用USBN9602的數(shù)據采集系統(tǒng)設計08-06

利用ColdFire uClinux實現(xiàn)數(shù)據采集和傳輸08-06

采用視頻方式的點坐標測量方法08-06

可行性分析報告08-20

數(shù)據分析報告08-20