王 濤

(綿陽叁吉網(wǎng)絡(luò)科技有限公司，四川 綿陽 621000)

數(shù)字電視在我國經(jīng)過十多年的發(fā)展，目前已經(jīng)形成了從衛(wèi)星到有線再到地面無線的全方位多方面的發(fā)展態(tài)勢，同時隨著國務(wù)院關(guān)于推進三網(wǎng)融合試點工作的進一步開展，IPTV，OTT等網(wǎng)絡(luò)新媒體也在各地大力發(fā)展了起來。在衛(wèi)星、地面和有線數(shù)字電視廣播領(lǐng)域，通常為了節(jié)約寶貴的信號帶寬和頻率資源，都會將編碼好的單個數(shù)字電視節(jié)目復(fù)用成多節(jié)目傳輸流(MPTS)的形式再傳輸?shù)浇K端用戶。IPTV和OTT網(wǎng)絡(luò)新媒體通常也會采用衛(wèi)星、地面或有線數(shù)字電視網(wǎng)絡(luò)中傳輸?shù)倪@些信號作為直播源。但是，由于IP網(wǎng)絡(luò)的帶寬是共享帶寬，而且往往都非常有限，如果將MPTS通過IP傳送到用戶終端將會非常浪費帶寬并且會產(chǎn)生擁塞，同時也不便于IPTV核心設(shè)備對節(jié)目的管理，不利于實現(xiàn)節(jié)目點播和節(jié)目的時移、快進快退等功能。因此，就需要一種將復(fù)用的多節(jié)目傳輸流中的多個節(jié)目分別輸出到不同IP端口的設(shè)備，本文介紹了實現(xiàn)這種MPTS轉(zhuǎn)多路SPTS(單節(jié)目傳輸流)的IP輸出的方法。

1 MPTS概述

多節(jié)目傳輸流(MPTS)由多個節(jié)目復(fù)用而成，它包含了多套節(jié)目的音視頻PES和相應(yīng)的PSI、SI信息，如節(jié)目關(guān)聯(lián)表(PAT)、節(jié)目映射表(PMT)、服務(wù)描述表(SDT)、網(wǎng)絡(luò)信息表(NIT)等。為了獲得每個節(jié)目的音視頻PID、PCR PID等信息，首先需要解析MPTS的PSI、SI信息，在得到每一路節(jié)目的PID信息之后，只需要分別進行簡單的PID過濾就可以把每路節(jié)目的音視頻傳輸小包分別開來，同時由于原來的PSI、SI信息已經(jīng)不能直接用于SPTS中，所以也一起被過濾掉。單節(jié)目的傳輸流要讓終端能正確解碼至少必須要具備PAT表和PMT表，因此作為最簡系統(tǒng)，必須要實現(xiàn)PAT和PMT的重構(gòu)。

從MPTS中通過PID過濾和重構(gòu)PAT/PMT表以后得到SPTS，經(jīng)過IP輸出，雖然通過VLC播放器等工具完全可以正常播放，但是由于其傳輸包減少等變化，造成原來的PCR字段相對位置發(fā)生變化，從而必然引起了PCR的抖動，因此必須對PCR字段進行相應(yīng)修正。然而，由于單個節(jié)目的傳輸流小包在原來MPTS中位置的隨機性和突發(fā)性，使得過濾后的SPTS在傳輸速率上變得突發(fā)和不均勻，這樣就無法對PCR進行修正。因此，需要采用FIFO和插空包的機制來平滑碼率，使得在勻速傳輸?shù)腟PTS上實現(xiàn)PCR修正成為可能。

多個獨立的SPTS傳輸流分別進入幀緩存，同時FEC發(fā)生器產(chǎn)生FEC包，它們一道經(jīng)過通道選擇邏輯被分時送往RTP/UDP/IP封包，然后經(jīng)過千兆以太網(wǎng)MAC送PHY輸出。整個系統(tǒng)實現(xiàn)的邏輯框圖如圖1所示。

2 PSI解析

圖1 系統(tǒng)框圖

對于完成MPTS到SPTS的功能來說，有兩種方法可以實現(xiàn)。一是采用解復(fù)用的方法，把輸入的傳送流解復(fù)用為PES流，同時記錄時序信息，然后在保持原來時序關(guān)系的基礎(chǔ)上重新組合各路PES流。二是直接利用原傳送流小包結(jié)構(gòu)的方法，由于輸入的傳送流為已經(jīng)打好的188 byte長的小包，因此考慮直接利用原打好的小包結(jié)構(gòu)，扔掉原傳送流中其他節(jié)目的各小包和全部空包及無關(guān)包，并修改其中需要修改的PSI信息(主要是重構(gòu)PAT和PMT表)來保證碼流語法結(jié)構(gòu)的正確。第一種方法在理論上可以實現(xiàn)，但在系統(tǒng)實現(xiàn)上非常繁瑣。在這里采用了第二種方法。

在整個系統(tǒng)的輸入端應(yīng)該包括一個傳送流包解析功能，根據(jù)碼流中的節(jié)目特殊信息表和PID值分離復(fù)用在一起的視頻、音頻、輔助數(shù)據(jù)等，但這個過程和傳送流解復(fù)用不同。解復(fù)用需要把傳送流解碼到PES甚至ES層，解碼器解復(fù)用時還必須利用PCR進行時鐘的恢復(fù)。在這里稱為解傳送流包，而不稱為解復(fù)用，因為只需要把每個節(jié)目的音頻視頻及PCR小包保留不動，其他的包過濾掉即可。解傳送流包的過程實際上是一個PSI信息處理器對碼流中PSI信息的處理。首先從輸入節(jié)目中獲得PID為0x0000的PAT表，根據(jù)PAT表找到PMT表的PID值，然后根據(jù)PMT找到節(jié)目中音視頻和輔助數(shù)據(jù)等的PID值，然后根據(jù)PID從輸入的傳送流中分離出不同的數(shù)據(jù)流。同時根據(jù)PMT表中的PCR_PID值確定攜帶有PCR的PID號。PSI信息解析以后被丟棄，同時為了對帶有自適應(yīng)域的傳送流包處理方便，解傳送流包后暫時保留原來的自適應(yīng)域，而不是完全解成PES流，這樣在重打傳送流包時只要直接引用原來的傳輸流包即可，而不必再考慮PES包的對齊等工作，從而大大加快處理的速度。圖2顯示了如上所述的PSI解析過程［1］。

圖2 TS流的PSI解析

根據(jù)圖2所示關(guān)系，分別解析出個節(jié)目的音頻、視頻和PCR PID等信息，就可以根據(jù)標(biāo)準(zhǔn)語法重構(gòu)PAT和PMT表了。動態(tài)生成的節(jié)目特殊信息表PAT，PMT等要滿足MPEG-2及DVB標(biāo)準(zhǔn)語法的規(guī)范，并且32位的CRC需要動態(tài)地在線生成。關(guān)于PAT，PMT表的具體語法在ISO13818-1(MPEG-2系統(tǒng)層標(biāo)準(zhǔn))中有詳細敘述，篇幅有限，本文不再贅述。

本部分的功能由ST公司的嵌入式解碼控制芯片STi7105實現(xiàn)。

3 PCR校正

針對單節(jié)目碼流的突發(fā)性和間歇性，采用FIFO緩存和插空包的機制來平滑碼率，使得在勻速傳輸?shù)腟PTS上實現(xiàn)PCR修正成為可能。由于之前的MPTS中所有空包和無用信息都已經(jīng)被過濾掉了，所以必須采用碼率上變換的方法把SPTS的輸出勻速碼率調(diào)整到比平均碼率稍大一些的速率，具體大小需要根據(jù)FIFO緩存的深度和SPTS最大突發(fā)碼率的大小來確定，前提是保證FIFO不發(fā)生向上溢出，而在FIFO下溢讀空時則填以空包。

由SPTS生成策略可以看出，由于PSI信息的更新必然造成本節(jié)目PCR字段到達解碼器時間的變化，因此必須將此時間抖動轉(zhuǎn)化為PCR值的修正，即

式中:PCRnew為新的PCR，替換原來的PCR值;ΔPCR表示多余節(jié)目過濾和PSI信息修改引入的PCR抖動值。這樣經(jīng)過了校正后的PCR不再有抖動。注意式(1)中的校正通常應(yīng)該為負數(shù)，因為由于空包和PSI及多余包的丟棄將導(dǎo)致PCR的超前，所以本質(zhì)上應(yīng)為減，在實際設(shè)計中，可能會發(fā)生如圖3所示的PCR抖動的極端情況。由于PCR最大的超前是在原兩個PCR之間全為空包時的情況下發(fā)生的，所以其PCR的校正應(yīng)為30 ms×90000=2700 s(假設(shè)PCR插入間隔為30 ms)。由于PCR只對相對值有效，故而對每一個PCR加減一個常數(shù)不產(chǎn)生任何其他影響，dconst即為該常數(shù)。采用PCR修正的優(yōu)點是處理較為簡單，但是需要消耗的硬件資源較大，并且有一定的誤差，因為PCR修正以后雖然基本上消除了傳送流包變化引起的PCR抖動，但是相對于每一路節(jié)目而言，抖動除了在需要插入PSI信息和極少量空包時發(fā)生，另外引起PCR的抖動誤差是在單傳送流緩存中，而PCR的修正則正好消除了該誤差［2］。本部分的功能由FPGA實現(xiàn)。

圖3 PCR改變的一種極端情況

4 TS OVER IP輸出

TS OVER IP是一種將數(shù)字音視頻傳輸流加以一定的協(xié)議封裝后在IP網(wǎng)絡(luò)媒介上傳輸?shù)募夹g(shù)。由于視頻傳輸?shù)奶匦裕瑐鬏斶^程中丟失個別包被允許，故通常采用面向非連接的UDP協(xié)議，在需要FEC前向糾錯的時候也采用RTP協(xié)議(Real-time Transport Protocol，實時傳輸協(xié)議)來傳輸。RTP協(xié)議提供包序列的檢測、排序等UDP協(xié)議不能完成的功能。同時，Pro-MPEG Code of Practice#3是設(shè)計用來提供FEC糾錯編碼的國際標(biāo)準(zhǔn)，用以保證實時傳輸?shù)目煽啃浴?/p>

在TS OVER IP中，TS流最終被封裝為IP幀，按照以太網(wǎng)協(xié)議，默認的最大傳輸單元(MTU)為1500，為了保證含有TS包的IP幀不被分片傳輸，就需要每個IP幀傳輸?shù)腡S字節(jié)數(shù)少于1500，因此每個IP幀傳輸?shù)腡S包個數(shù)為1～7個TS包(7×204=1428＜1500)。具體封包個數(shù)可以根據(jù)需要而定，每個IP幀封裝的TS包個數(shù)越多，載荷效率就越高，只是萬一丟包后丟失的TS包個數(shù)更多。在IP封裝以前按先后順序需要進行FEC包頭(如果需要FEC功能)、RTP包頭及UDP包頭的封裝，具體封裝示意圖見圖4 所示［3］。

圖4 TS OVER IP封裝示意圖

4.1 RTP模塊

RTP是在RFC3550中規(guī)定的。RTP協(xié)議建立在UDP用戶數(shù)據(jù)報協(xié)議之上，詳細規(guī)定了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。如果要對包進行FEC糾錯編碼，就需要用到RTP協(xié)議，實現(xiàn)FEC糾錯編碼的原理框圖如圖5所示。

圖5 RTP協(xié)議封裝

FEC包是基于矩陣運算產(chǎn)生的。矩陣的大小由參數(shù)L和D決定。L是用于產(chǎn)生幀的非連續(xù)TS包的長度，D是矩陣深度。通常情況下，含TS包的幀和含行、列FEC包的幀用不同的目的端口區(qū)分開來，分別為m，m+1和m+2［4］。

4.2 UDP/IP模塊

UDP協(xié)議的傳輸過程不需要來回確認，當(dāng)它和RTP協(xié)議一起使用時特別適合傳輸高帶寬的音視頻數(shù)據(jù)。

UDP/IP模塊對RTP模塊封裝后的數(shù)據(jù)包加上相應(yīng)的UDP頭部和IP頭部，并送往MAC模塊，原理框圖如圖6所示。同時，該模塊還要對接收到的幀進行解析，以響應(yīng)ARP協(xié)議等，用以獲取目的IP的MAC地址。

圖6 UDP/IP模塊

4.3 以太網(wǎng)MAC

MAC層實現(xiàn)IP層和PHY層的互連，本例使用FPGA器件廠家提供的IP核，在此不再贅述。本部分的TS OVER IP功能全部由FPGA實現(xiàn)。

5 結(jié)束語

本文所述技術(shù)過程全部在Xilinx公司的FPGA芯片XC6SLX16-2FTG256C上實現(xiàn)，結(jié)合ST公司的嵌入式解碼控制芯片STi7105實現(xiàn)了6路IP輸出的接收解碼器。該產(chǎn)品已經(jīng)成功應(yīng)用于湖北省網(wǎng)絡(luò)電視臺，并被以色列、泰國等地IPTV集成商選用。

［1］鐘玉琢.MPEG-2運動圖像壓縮編碼國際標(biāo)準(zhǔn)及MPEG的新進展［M］.北京:清華大學(xué)出版社，2002.

［2］金盛.數(shù)字電視系統(tǒng)層傳送流復(fù)用及相關(guān)問題研究［D］.上海:上海交通大學(xué)，2002.

［3］Xilinx.UG463:Video Over IP User Guide［EB/OL］.［2012-05-10］.http://wenku.baidu.com/view/f3a1564d2b160b4e767fcffa.html.

［4］Pro-MPEG Code of Practice#3 release 2，Transmission of professional MPEG-2 transport streams over IP networks［S］.2004.