- 相關推薦
采用集中上載方式的非線性制作網(wǎng)的若干細節(jié)歸納
采用集中上載方式的非線性制作網(wǎng)的若干細節(jié)歸納
2004年度河南省廣播電視優(yōu)秀科技論文二等獎一、概述
目前，非線性制作網(wǎng)絡在電視行業(yè)中已大量應用，以 FC+ 以太網(wǎng)的雙網(wǎng)結構是最為普遍的做法。由于前期的節(jié)目采集中，仍在大量使用磁帶這一傳統(tǒng)的線性方式作為記錄的主體，在后期的節(jié)目制作前，素材的上載成為不可避免的步驟與環(huán)節(jié)�，F(xiàn)在流行的方式是在配有視音頻處理卡的工作站上加掛放機，以分散的上載工作站承擔素材上載的工作。這種方式由于其流程簡單、使用靈活而在早期的網(wǎng)絡中大量存在，但在中小型的網(wǎng)絡中，由于工作站點的不足，經(jīng)常會出現(xiàn)素材上載人員與節(jié)目編輯人員爭用站點的現(xiàn)象。為避免這種情況的出現(xiàn)，將節(jié)目制作站點從素材上載中解放出來，河南電視臺都市頻道在 2003 年底建成的節(jié)目制作網(wǎng)以集中上載來代替原先新聞制作網(wǎng)中的分散上載方式。
二 、網(wǎng)絡分析
由于上載部分的獨立，從而使網(wǎng)絡的結構在功能上產(chǎn)生了分解、細化，使得原先作為整體的、基于標準 C/S 構架的、功能集成的網(wǎng)絡，演變成為多個功能專一的、獨立的子網(wǎng)。如圖 1 、 2 所示：
注：箭頭代表數(shù)據(jù)流向
從以上兩圖的比較當中可以看出，在原先的網(wǎng)絡中，素材上載、節(jié)目制作、素材存儲、以及網(wǎng)絡的管理等功能，都是通過各站點獨立在網(wǎng)絡中進行交互的，而各站點之間是一種對等、并列的關系，它們之間不存在根本性的功能差異，這就在簡潔、明了的背后掩蓋了各功能間不確定的、潛在的沖突（即在用機繁忙時，素材上載人員與節(jié)目編輯人員爭用站點的現(xiàn)象時有發(fā)生；而在更多的時間中，大部分站點又處于閑置狀態(tài)）。在新的網(wǎng)絡中，各功能相對獨立，更有利于網(wǎng)絡的管理與維護。并且，對于功能的擴充（如加入播出網(wǎng)），也由原來的網(wǎng)間連接變?yōu)閮炔孔泳W(wǎng)的擴展，在理解上更加容易、操作上更加可行。
三、網(wǎng)絡結構
下面筆者就以圖二的功能子網(wǎng)模式，對都市頻道的非線性節(jié)目制作網(wǎng)進行結構上的分析。
• 上載子網(wǎng)
從物理上該部分由兩臺轉碼工作站（ ZMS-01 和 ZMS-02 ）、一臺轉碼調度服務器站（ ZMC ）、一臺上載控制站（ SZC ）、一臺視頻服務器（ MAV70 ）及該視頻服務器的網(wǎng)關（ GateWay ）所組成；從邏輯上分為上載、存儲與轉碼三部分。
在 SZC 上運行著集中上載主程序 MAV70Upload.exe 和定時收錄任務 Uploadsvr.exe 兩個程序， MAV70Upload.exe 是集中上載系統(tǒng)的主程序，記載了整個上載部分的路由信息， 負責素材的采集、將采集的條目寫入專有的上載數(shù)據(jù)庫、并向素材管理 DispClip.exe 發(fā)送上載信息，它 也是上載人員操控的主界面；而 Uploadsvr.exe 功能較為單一，只進行衛(wèi)星的定時收錄任務。同時， SZC 通過 MOXA 卡及其連接盒與各放機和 MAV70 的控制口相連，對其進行各種操作的控制。
ZMC 包含素材管理 DispClip.exe 和轉碼調度服務器 SbRemoteSvr .exe 兩個程序，素材管理 DispClip.exe 接收到來自主程序的上載信息， 檢查數(shù)據(jù)庫，將新增的條目生成轉碼任務并提交， 并將其發(fā)送于轉碼部分，待轉碼完成后將信息（轉碼成功、失敗或因未找到轉碼素材而沒有轉碼）返回于主程序；當素材管理 DispClip.exe 收到 轉碼任務成功時，還要將素材信息寫入整個網(wǎng)絡的主數(shù)據(jù)庫。而轉碼調度服務器 SbRemoteSvr.exe 的作用是接受來自于素材管理 DispClip.exe 的任務，并根據(jù)當前的任務量對轉碼工作站集群進行任務調度和分配，待轉碼站完成任務后，向素材管理 DispClip.exe 返回完成信息。
兩臺 ZMS 組成了轉碼工作站的群集，在其上的本地轉碼 SbTrLocalSvr.exe 程序根據(jù)從轉碼調度服務器站發(fā)來任務，通過網(wǎng)關從 MAV70 中找到相應的素材文件的位置，將其轉為制作網(wǎng)所識別的高（低）質量的視音頻文件，并存放于為該用戶指定的相應位置；在轉碼工作站上另有一手動提交軟件 TaskSubmit.exe ，該軟件可將各類 MPEG-II 視音頻（如 DVD ），網(wǎng)絡中各種流行的視頻格式（如 rmvb 、 wmv 、 asf 、 mp3 等）及其他公司的視音頻文件（如 SEACHANGE 、 GVG GXF ）轉為制作網(wǎng)中可識別的格式，它的功能相當于一手動提交任務的“萬能轉碼”軟件。
MAV70 用來臨時存放采集的視、音頻文件，由于其不能直接將視、音頻流轉為制作網(wǎng)所識別的格式文件，也就使得轉碼成為必須的步驟；而且 MAV70 是視頻服務器，無法以高速的 I/O 吞吐能力直接與網(wǎng)絡進行交互，因此為其配一專用的網(wǎng)關，解決網(wǎng)絡中的高數(shù)據(jù)流量。
SZC 上的 MAV70Upload.exe 和 Uploadsvr.exe 兩個程序與 ZMC 上的素材管理 DispClip.exe 組成了上載部分，它們之間相互獨立，互相配合。用戶通過主程序進行操作，在登錄時申請供上載用的空閑通道，并從網(wǎng)絡中的主數(shù)據(jù)庫中讀出相應的用戶信息（上載的權限、有效的使用空間、用戶需求的視頻文件的碼率類型及要存放的位置等），待錄制（素材上載）完成后，將相應的素材信息寫入上載數(shù)據(jù)庫，并發(fā)送信息給素材管理 DispClip.exe 。素材管理 DispClip.exe 接收到主程序發(fā)送的素材信息后，檢查上載數(shù)據(jù)庫，將其中的新增條目生成轉碼任務并向轉碼調度服務器提交。當素材管理 DispClip.exe 接收到從轉碼調度服務器發(fā)送的轉碼完成的返回信息后，將該條目的所有相應信息寫入制作網(wǎng)主數(shù)據(jù)庫，并且向主上載程序發(fā)送轉碼成功信息。主程序在得到轉碼任務成功的信息后，向上載數(shù)據(jù)庫寫入完成信息，并于一小時后自動從 MAV70 中釋放已完成轉碼的素材所占用的空間；若返回的是失敗信息，素材管理 DispClip.exe 將不進行寫入主數(shù)據(jù)庫的操作，同時返回給主程序，由主程序向上載數(shù)據(jù)庫寫入失敗信息，并將素材一直存放在 MAV70 內，成為“垃圾”文件。管理人員若發(fā)現(xiàn)轉碼任務失敗，可通過該任務在轉碼調度服務器中的執(zhí)行信息進行判斷，如果是任務意外中止，可在轉碼調度服務器中手動重作該任務，若錄入的素材有問題，則應通過上載主程序的管理界面刪除該任務。用戶還可進行衛(wèi)星定時收錄工作，與人工上載不同的是定時上載不需要手工去操作，只需要在第一次上載前，由用戶對錄制起止時間、錄制期數(shù)進行預先設定，在錄制的前兩分鐘，定時上載程序會自動向上載主程序發(fā)送錄制申請。由于定時上載在設計時即被定義了較高的優(yōu)先級，因此在定時上載發(fā)送錄制申請后，如果設備已被占用，主程序會強行終止該任務，釋放通道，供定時上載程序使用。
轉碼調度服務器、轉碼工作站群集與手動任務提交組成了轉碼部分。轉碼調度服務器與轉碼工作站群集組成了正常的上載模式，轉碼調度服務器根據(jù)當前轉碼站的忙閑狀態(tài)進行任務分配。在有空閑的轉碼工作站時，轉碼調度服務器向其發(fā)送任務與相關素材信息；若所有轉碼站的通道均被占用時，轉碼調度服務器則將任務以 FIFO （先進先出）的方式建立一任務隊列，依序進行任務分配。
作為存儲部分的 MAV70 及其網(wǎng)關，只是用來臨時存放素材文件的場所，等轉碼成功一小時后，其所占用的空間將被自動釋放；網(wǎng)關只作為供轉碼站與 MAV70 交互的一個平臺。
• 存儲子網(wǎng)
雙網(wǎng)結構中以 FC 環(huán)境構成的 SAN （存儲區(qū)域網(wǎng)）則成為了存儲子網(wǎng)的主要構成部分。節(jié)目素材通過轉碼工作站，分別經(jīng)光纖和以太網(wǎng)連接，以高低兩種畫質存儲在 FC 網(wǎng)的共享海量存儲磁盤陣列和以太網(wǎng)域主服務器的共享 SCSI 硬盤塔進行存儲，供帶有視音頻編解碼板的有卡工作站使用，所以存儲子網(wǎng)也就由海量存儲磁盤陣列、磁盤控制器、 MDC 服務器及與域主服務器相連的 SCSI 硬盤塔組成。素材文件由經(jīng)轉碼工作站的轉碼，送入網(wǎng)絡的相應存儲體中，低質量素材存放在 SCSI 硬盤塔中，相對應的高質量素材存放在海量存儲磁盤陣列中。
對于 SCSI 硬盤塔而言，域主服務器與其關系就如同 MAV70 與其網(wǎng)關的關系相似，只是域主服務器并不是單為 SCSI 硬盤塔共享存儲而配，做為域主服務器、網(wǎng)絡的核心，它還發(fā)揮著更為重要的維持整個網(wǎng)絡運行的作用。在 SCSI 硬盤塔上分別存放有數(shù)據(jù)庫群集、制作網(wǎng)低質量素材和節(jié)目的所有信息。
海量存儲磁盤陣列是全網(wǎng)的主要存儲設備，與以往不同之處在于它并不直接連入 SAN 中，而是配有專門的磁盤控制器，這樣可以更加安全可靠地管理磁盤陣列。目前，都市頻道制作網(wǎng)中使用的磁盤控制器為使用了單控制器的 S2A3000 ，它管理著磁盤陣列中的全部十六塊硬盤，并將其分為六通道的三個“ tier ”（ S2A3000 對磁盤的一種邏輯表示方式），如圖 3 顯示的是磁盤陣列中，各物理盤的對應關系。
其實， S2A 控制器對磁盤陣列采用了較特殊的管理方式（ DirectRAID 技術），尚未公布對外細節(jié)，我們無法十分準確地對其進行了解、掌握，只能通過概念進行邏輯上的理解。在這里，每一個 tier 可以簡單地看作是一帶奇偶校驗的帶區(qū)集。例如： tier1 是由 1A 、 1B 、 1C 、 1D 、 1P 、 1S 組成，其中標號是 A 、 B 、 C 、 D 為數(shù)據(jù)盤， P 為奇偶校驗盤， S 為空閑熱備盤，但是它可以替換陣列中的任一塊故障盤，既便它們不屬于同一 tier 。但實際情況是每塊盤上都有專用于奇偶校驗的區(qū)塊，而不是使用單獨的奇偶校驗盤。
此時如果一塊數(shù)據(jù)硬盤出現(xiàn)故障，例如 disk 2A 故障，則該盤所在的 Tier 中的其他 5 塊數(shù)據(jù)盤會自動將數(shù)據(jù) Rebuild 到熱備盤上，即 1S ；當故障硬盤被新盤替換，并且 S2A 控制器檢測到新硬盤上線后，系統(tǒng)會將備份盤（如 1S ）上的數(shù)據(jù)拷貝到新硬盤中。如果新硬盤上線時，系統(tǒng)對熱備盤的 rebuild 尚未結束，則系統(tǒng)會先將熱備盤的 rebuild 過程完成，然后再將熱備盤上的恢復完整的數(shù)據(jù)拷貝到新硬盤上。
S2A 控制器以雙通道的方式與 FC 交換機連接，占用了 FC 交換機的兩個端口，分擔各結點與存儲陣列之間的 通訊量，盡量做到數(shù)據(jù)吞吐量的負載平衡。
SAN 的優(yōu)勢在于提供了工作站點通過光纖通道（ FC ）對共享存儲體（海量存儲磁盤陣列）的直接訪問，而基于 SAN 結構的 SANergy 文件共享系統(tǒng)則提供了多個站點對存儲體的實時共享。 元數(shù)據(jù)控制器 （ MDC ） 服務器是共享存儲體的所有者，是專用于對共享存儲體進行管理的服務器，通過 SANergy 軟件對共享存儲體進行設備和卷的分配，使得共享存儲體成為 SAN 中的每臺工作站點都可以識別的資源，客戶端正是通過它對共享存儲體進行訪問的。
從 MDC 服務器的角度來看，共享存儲體就是它的本地磁盤，可由操作系統(tǒng)自帶的磁盤管理軟件進行管理和配置，網(wǎng)絡中的其他工作站點則通過以太網(wǎng)路由將 MDC 服務器管理的共享存儲體進行磁盤映射、進行訪問的。當工作站通過以太網(wǎng)以邏輯卷的方式訪問共享存儲體時，它從 MDC 服務器得到邏輯卷的相關元數(shù)據(jù)，如文件名稱、數(shù)據(jù)結構、文件大小等，而實際數(shù)據(jù)則經(jīng)由 FC 直接進行傳輸。
• 制作子網(wǎng)
該部分與傳統(tǒng)的制作網(wǎng)絡無異，因此不加贅述。
• 管理子網(wǎng)
管理子網(wǎng)由域控制器（主服務器）群集、數(shù)據(jù)庫群集、制作網(wǎng)網(wǎng)管軟件組成，也包括 FC 控制軟件 SANergy 、 FC 交換機的管理軟件 SANinsite 、 MAV70 及 S2A 磁盤控制器的管理程序。
域控制器群集是網(wǎng)絡運行的核心部分，擔負了主域控制器的所有工作。它是將兩臺硬件配置相同的服務器，通過服務器編組，由一根心跳線相連，使其虛擬成一臺單獨的服務器，。其中一臺作為主控機，另一臺為作為它的鏡像，當主控機故障時，鏡像機會立時接替原主控機，資源的所有者，例如磁盤驅動器和 IP 地址，將自動從故障的服務器轉到可用的服務器上。工作負荷可在幸存的服務器上重新啟動失效的應用程序，或是直接被分配過來，對于用戶而言，只是覺得服務暫時停頓了一下。
數(shù)據(jù)庫群集與域控制器群集類似，它是在域控制器群集安裝完成之后，在域控制器群集和各節(jié)點上裝入并配置的。有所不同的是，進行群集切換時，正在執(zhí)行的數(shù)據(jù)庫查詢將不會重新啟動，數(shù)據(jù)庫的重啟也會較其他工作慢一些 。
現(xiàn)有的網(wǎng)絡中運行著兩個數(shù)據(jù)庫，一個是記錄主要制作信息的主數(shù)據(jù)庫，一個是專用于記錄集中上載信息的上載數(shù)據(jù)庫。這兩個數(shù)據(jù)庫是相互獨立、互無影響的。
網(wǎng)管軟件是對針對制作網(wǎng)的專用管理軟件，它要對網(wǎng)絡中各工作站進行設備登記，通過對主數(shù)據(jù)庫進行操作，來創(chuàng)建制作網(wǎng)的用戶、分配權限、監(jiān)測用戶空間，它還對每個用戶的各種操作加以記錄。
對于其他的管理軟件，都是針對各自的專用對象、實現(xiàn)特定的功能。
四、典型問題
對于一個涉及多環(huán)節(jié)的網(wǎng)絡，會出現(xiàn)各式各樣的問題，想列舉所有會出現(xiàn)的問題也不可能，現(xiàn)將筆者在值班時遇到的一些認為較為典型的問題作一歸納、分析。
• SZC 長時間運轉，集中上載控制主程序一直工作正常，然后出現(xiàn)某一用戶在使用時，做任何正常的上載操作（如登錄主程序、登錄后遙控放機回放素材等），系統(tǒng)均發(fā)生異常（主程序異常終止、操作無響應、鼠標箭頭消失等），即使重新啟動主機，問題依舊。不使用集中上載控制主程序，則主機系統(tǒng)運行良好，加載之后則不能正常工作，終止程序后，主機系統(tǒng)依舊運行良好。主程序經(jīng)過長時間的使用，操作界面功能單一，沒有任何修改配置信息的操作（管理功能不對上載用戶開放，普通用戶無修改權限），即使是程序自身的問題，在重啟主機系統(tǒng)后仍不能正常工作。這就說明了問題的原因有兩種可能，集中上載主程序與主機系統(tǒng)發(fā)生沖突或與其他應用軟件產(chǎn)生了沖突。專機專用，一直工作正常，且不做任何系統(tǒng)修改，與主機系統(tǒng)發(fā)生沖突的可能性不大；未再加入任何額外程序，說明集中上載控制主程序相關的其他上載程序發(fā)生了沖突。與集中上載控制主程序相關的只有定時上載任務和兩個程序，定時上載任務功能單一，且與發(fā)生的現(xiàn)象無太大關系，也可做出排除。此時可基本確定問題的根源在集中上載控制主程序與素材管理之間的信息交互出現(xiàn)問題，待終止并重新加載素材管理程序后，集中上載控制主程序各功能恢復正常。
• 集中上載控制主程序故障，會出現(xiàn)另一種情況，用戶上載操作完全正常，可無論如何錄制，該條目一直沒有轉碼。與上述情況剛好相反，這是主程序影響了素材管理程序，需將集中上載控制主程序終止并重新加載即可。
• 由于 MAV70 錄入的最短素材文件至少為 10 秒，總會有用戶錄入少于十秒的素材，或是做了其他的非法上載操作，使得 MAV70 將這些上載的素材文件作為“垃圾”文件，而不作處理，一些轉碼失敗的素材也會堆積起來，久之，這樣的素材條目不僅占用了 MAV70 相當?shù)目臻g容量，還會在上載數(shù)據(jù)庫中產(chǎn)生許多“垃圾”信息，對于今后管理人員查找、整理信息也會是個不大不小的麻煩。所以管理人員應定期通過集中上載主程序進行管理和清除。
• MAV70 視頻服務器作為傳統(tǒng)的視頻設備，同步源的輸入是其能夠正常工作的前提，因此在素材上載前，特別是定時任務執(zhí)行前，一定要保證正確的同步輸入。
• 記得一次， MAV70 的 PU 板（位于 MAV70 系統(tǒng)內部，專用于磁盤校驗工作的板卡）報“日志已滿，日志錯誤”的警告，當然這對于 MAV70 而言，只是一個并不影響正常工作的警告，筆者通過專用軟件可以看到，確實報該板的日志錯誤。但無論筆者如何想將該 PU 板的錯誤日志清除，均告失敗，管理工具提供的所有清除命令無任何效果。不得已，筆者趁一次周末夜間，無上載工作時，將 MAV70 的磁盤帶區(qū)集進行了重建，重建完成后原先的所有磁盤信息全部清除，錯誤日志自然也不復存在了。
• 某次值夜班時，有編輯來告之筆者，說他在上載時報一打不開數(shù)據(jù)庫的對話框，初聽以為是他的誤操作或集中上載部分出現(xiàn)了故障造成的。在筆者進入機房后，幾個在線的編輯也說正在做節(jié)目時也彈出一數(shù)據(jù)庫連接失敗的對話框。既然是集中上載與制作網(wǎng)同時報與數(shù)據(jù)庫有關的故障信息，筆者的第一判斷就是數(shù)據(jù)庫可能出現(xiàn)了問題。筆者在中心服務器機房發(fā)現(xiàn)，域控制器群集已做了自行切換，但數(shù)據(jù)庫服務并未啟動�？磥韱栴}不大，筆者手動將域控制器群集切回原有的服務器（筆者的習慣），手動啟動了數(shù)據(jù)庫服務，一切似乎已經(jīng)正常，事情看起來不是很復雜。就在我還正想著怎么會無故發(fā)生自動切換這種“怪事”時，編輯又來找我了……現(xiàn)象依舊，唯有所不同的是群集的切換在群集管理器判定原鏡像機也出現(xiàn)故障后，重新試圖啟動原主控機。此時數(shù)據(jù)庫也在時斷時續(xù)地響應著網(wǎng)絡中的請求。這是一個比較少見的現(xiàn)像，無論我如何重啟整個網(wǎng)絡、修復數(shù)據(jù)庫、還原已備份的數(shù)據(jù)庫，所有嘗試均告失敗。這時我將注意力放至了數(shù)據(jù)庫群集，也許就是這里的原因。在備份了現(xiàn)有的數(shù)據(jù)庫后（雖然它已經(jīng)沒什么用了），卸載并重新安裝了數(shù)據(jù)庫群集，運轉正常了。筆者重建了所有的網(wǎng)絡用戶的信息。當時是在網(wǎng)絡的試運行期間，也幸好是在試運行期間，現(xiàn)在筆者又要到哪里去找這樣一個環(huán)境來做這樣一個“實驗”？但是為什么出現(xiàn)了數(shù)據(jù)庫群集的崩潰，筆者至今也未能找出恰當?shù)慕忉尅?
• 一次，在重啟一臺帶光卡（ FC 卡）的工作站時，在開機時報磁盤（為 MDC 服務器的卷標）故障，磁盤進行掃描，并報錯。由于當時有某種原因，該工作站連續(xù)重啟數(shù)次，每次均正常關機，每次均檢測。報錯的同時要求對卷進行 CHKDSK.exe 操作。這引起了筆者的注意，對其他帶光卡的工作站重啟，出現(xiàn)同樣的現(xiàn)象。通過 SANergy 軟件對磁盤陣列測試后，未發(fā)現(xiàn)任何問題。分析后認為，造成故障的原因應與 MDC 服務器操作系統(tǒng)下的卷數(shù)據(jù)結構有關，重啟 MDC 服務器后，問題不再出現(xiàn)。
• 另一個和 MDC 有關的問題是，在原先的新聞制作網(wǎng)中，主域控制器與 MDC 服務器合在一起，所有的網(wǎng)絡控制均由主域控制器發(fā)出。由 MDC 服務器的工作原理可知，這是性質比較特殊的一類服務器，一方面它的地位非常重要，另一方面它的 I/O 流量相對較小。因此，是否有必要將其分開呢？在這次建網(wǎng)的過程中，對原有的新聞網(wǎng)進行了部分升級，其中就包括了加入獨立的 MDC 服務器。事實證明，獨立的 MDC 服務器可以使穩(wěn)定性有很大的提高。由此可見，雖然 MDC 服務器的 I/O 流量相對較小，但主域控制器的網(wǎng)絡負擔任何的加重，都會對全網(wǎng)產(chǎn)生很大的影響。
• 和大存儲量的數(shù)據(jù)關系越密切，磁盤故障的也就在所難免。 MAV70 、海量磁盤存儲陣列和 SCSI 硬盤塔，每種存儲體都會有硬盤更換的可能。在這個每款存儲設備都標明可以熱插拔的今天，磁盤的更換命令雖然各有不同，但更換步驟卻是大同小異： 1 ）停止要更換的磁盤運轉； 2 ）卸下硬盤，并更換新盤； 3 ）加載新盤； 4 ）自動或手動重建帶區(qū)信息。
五、總結
制作網(wǎng)在功能被細分后使得網(wǎng)絡的架構更加清晰，更容易對網(wǎng)絡分析。應當指出的是，這種劃分并不是完全的基于純粹的軟件層或是硬件層的劃分，若在尚未完全搞清網(wǎng)絡結構前生硬的對網(wǎng)絡各部分進行比照，還有產(chǎn)生誤導的可能。但它必竟給我們提供了一種新的思路，對今后越來越復雜的網(wǎng)絡的理解有很大的幫助。
【采用集中上載方式的非線性制作網(wǎng)的若干細節(jié)歸納】相關文章：
集中識字的主要方式08-08
學習方式組織操作的若干思考08-24
采用視頻方式的點坐標測量方法08-06
采用“小單元集中識字”的方法進行課文教學08-08
淺析非線性編輯系統(tǒng)在節(jié)目制作中所遇到的問題08-06
采用加密網(wǎng)卡實現(xiàn)內部網(wǎng)的信息安全08-06
非線性編輯系統(tǒng)的關鍵：專業(yè)非線性編輯板卡08-06
簡歷制作：細節(jié)是魔鬼08-15