手機(jī)電視(DVB-H)軟件接收器

1、 簡介

手持式數(shù)字電視DVB-H(DigitalVideoBroadcasting-Handheld)系統(tǒng)標(biāo)準(zhǔn)規(guī)范[1]主要以地面廣播系統(tǒng)DVB-T(DigitalVideoBroadcasting-Terrestrial)的架構(gòu)為核心，再附加新的技術(shù)標(biāo)準(zhǔn)以進(jìn)行規(guī)格制定。由于DVB-T系統(tǒng)系利用編碼正交分頻多任務(wù)(CodedOrthogonalFrequencyDivisionMultiplexing，COFDM)之多載波調(diào)變技術(shù)，對于多重路徑(Multi-path)反射效應(yīng)所衍生出的干擾及衰減問題，能提供有效的處理與抑制能力，因此非常適合使用于行動應(yīng)用。此外，DVB-H系統(tǒng)標(biāo)準(zhǔn)另外新增的功能與改進(jìn)的技術(shù)有：DVB-H傳輸參數(shù)信號(TransmissionParameterSignaling，TPS)、分時(shí)切片(TimeSlicing)、軟式交遞(SoftHandover)算法、4K模式、深度符號內(nèi)間插(In-depthsymbolinterleaver)與多協(xié)定封裝前向糾錯(cuò)機(jī)制(Multi-ProtocolEncapsulationForwardErrorCorrection，MPE-FEC)等技術(shù)，用來提升手持裝置之移動接收性能并克服耗電問題，更透過行動電視條件接收(ConditionAccess，CA)之應(yīng)用與電子服務(wù)指南(ElectricServiceGuide，ESG)等功能來使得所提供的服務(wù)內(nèi)容更為完備并更具保障。

2、 相關(guān)技術(shù)研究

最近對于DVB-H之MPE-FEC機(jī)制的研究文章，主要著重于接收端于解封裝時(shí)，如何對傳輸串流中的數(shù)據(jù)進(jìn)行錯(cuò)誤偵測判斷、如何提供糾錯(cuò)譯碼運(yùn)算時(shí)所需的錯(cuò)誤信息與如何改善增強(qiáng)MPE-FEC機(jī)制對錯(cuò)誤的檢測修復(fù)能力。

目前對于接收端接收數(shù)據(jù)進(jìn)行錯(cuò)誤偵測與判斷的方式，主要能夠分為兩類，這兩類的主要差異點(diǎn)是在于不同層次的封裝格式上進(jìn)行錯(cuò)誤偵測與判斷，其中一種判斷方式是在解傳輸串流封包時(shí)進(jìn)行，另一種則是在進(jìn)一步解多協(xié)議封裝(Multi-ProtocolEncapsulation，MPE)格式時(shí)進(jìn)行，而在DVB-H規(guī)范中的建議方式是采用后者，主要是利用循環(huán)冗贅核對(CyclicRedundancyCheck，CRC)來對數(shù)據(jù)進(jìn)行錯(cuò)誤偵測與判斷。

另外，對于提供糾錯(cuò)譯碼運(yùn)算時(shí)所需的錯(cuò)誤信息方面，則會根據(jù)所提供的錯(cuò)誤信息形式上的不同而有不同的糾錯(cuò)譯碼方式。以上兩種方面的各種規(guī)劃設(shè)計(jì)概念大多已被整合介紹于一篇研究文章內(nèi)[2]并主要被分成五種架構(gòu)，而本研究考慮設(shè)計(jì)與實(shí)作上的便利，故采用所謂的TSE(TransportStreamErasure)的錯(cuò)誤偵測方式(即根據(jù)TS封包標(biāo)頭內(nèi)的錯(cuò)誤指標(biāo)字段來進(jìn)行正確性判斷)，而于RS譯碼部分則是采用歐幾里得(Euclid)方式來進(jìn)行RS糾錯(cuò)譯碼。

3、 數(shù)字電視廣播系統(tǒng)核心技術(shù)簡介

3.1DVB-H傳輸系統(tǒng)結(jié)構(gòu)與封裝格式

DVB-H傳輸IP服務(wù)的傳輸系統(tǒng)如圖1所示。DVB-H的服務(wù)數(shù)據(jù)封裝成IP封包之后，再透過MPE機(jī)制封裝于傳輸串流之中，并同時(shí)加入Time-Slicing信息后與其它DVB-T的電視節(jié)目(MPEG-2TVService)經(jīng)由多任務(wù)器多任務(wù)成一個(gè)更大的傳輸串流(又稱復(fù)合節(jié)目串流，MultipleProgramTransportStream)，再調(diào)變成無線信號送出，其中在發(fā)送端的MPE、MPE-FEC與Time-Slicing機(jī)制合稱為DVB-HIP封裝器(IP-Encapsulator)，而在接收端的反向解回部份則稱為DVB-HIP解封裝器(IP-Decapsulator)，而整個(gè)DVB-H的封裝格式則如同圖2所示。

圖1 DVB-H傳輸IP服務(wù)的傳輸系統(tǒng)[3]

當(dāng)影音壓縮與其它服務(wù)數(shù)據(jù)經(jīng)過一連串的封裝之后，最后將被封裝成傳輸串流(TransportStream)的封包格式，而在接收端將再其遞送給底層硬件進(jìn)一次所羅門編碼后，才將封包調(diào)變成無線訊號送出。相對地在接端接收到封包時(shí)，將先進(jìn)行一次所羅門譯碼，而將譯碼的結(jié)果記錄在封包標(biāo)頭中。

圖2DVB-H數(shù)據(jù)封裝格式

3.2Time-Slicing傳輸機(jī)制與時(shí)間參數(shù)

Time-Slicing傳輸機(jī)制的目的在于降低手持式終端設(shè)備的平均能源消耗與實(shí)現(xiàn)SoftHandover機(jī)制在基地臺間平滑交接。Time-Slicing傳輸機(jī)制如圖3所示，系以瞬間高流量脈波傳輸(Burst)的方式傳輸數(shù)據(jù)。

圖3Time-Slicing傳輸機(jī)制的Burst傳輸方

 

另外，為了讓接收端設(shè)備能正確地接收每一個(gè)Burst數(shù)據(jù)，故在Burst中夾帶時(shí)間卷標(biāo)(Delta-T)信息來指出下一個(gè)Burst到達(dá)的時(shí)間(如圖4)，而接收端則預(yù)先提早Delta-TJitter的時(shí)間來打開接收器，以便能正確地接收數(shù)據(jù)，介于兩個(gè)Burst中間的OffTime時(shí)間則不傳輸任何數(shù)據(jù)，藉由此種頻寬分享方式來傳遞其它不同服務(wù)的數(shù)據(jù)。整個(gè)Burst在傳輸數(shù)據(jù)時(shí)有個(gè)最大持續(xù)時(shí)間(MaxBurstDuration)而這個(gè)信息也一并被夾帶于整個(gè)傳輸流中傳送。

圖4時(shí)間參數(shù)Delta-T示意圖

3.3MPE-FEC機(jī)制原理與運(yùn)作

MPE-FEC機(jī)制在DVB-H系統(tǒng)中負(fù)責(zé)進(jìn)行錯(cuò)誤數(shù)據(jù)修復(fù)動作，整體技術(shù)是建構(gòu)于一個(gè)名為MPE-FEC框架的方形內(nèi)存裝置之中。如圖5，此框架又被定義成兩部份稱為：ApplicationDataTable與RSDataTable，其分別用來存放DVB-H系統(tǒng)中傳送的服務(wù)數(shù)據(jù)與糾錯(cuò)冗余編碼數(shù)據(jù)。

圖5MPE-FEC框架

如圖6，在發(fā)送端透過縱向填入數(shù)據(jù)與橫向糾錯(cuò)編碼來完成交織編碼的編碼方式再進(jìn)行封裝傳送。而在接收端接收后則進(jìn)行反向的糾錯(cuò)譯碼動作，藉此來修復(fù)因傳輸所發(fā)生的數(shù)據(jù)錯(cuò)誤。

[!--empirenews.page--]

圖6 MPE-FEC框架交織編碼方式

4、 DVB-H軟件接收器系統(tǒng)設(shè)計(jì)

DVB-H接收器的詳細(xì)軟件架構(gòu)如圖7所呈現(xiàn)，主要由傳輸串流分派器(TransportStreamDispatcher)、子譯碼器(SubDecoder)組件、控制器(Controller)對象與MPE-FEC運(yùn)算單元(MPE-FECOperationUnit)所組成。

圖7DVB-H接收器軟件架構(gòu)

4.1傳輸串流分派器

傳輸串流分派器主要負(fù)責(zé)將DVB-H傳輸串流中各種類型的封包轉(zhuǎn)遞給不同的子譯碼器進(jìn)行處理并從封包中過濾使用者所欲觀看的節(jié)目傳遞給DVB-H終端裝置。若在Burst傳輸期間，封包數(shù)據(jù)因噪聲干擾而損毀，或者傳送端于傳送時(shí)為符合服務(wù)的傳輸位率而添加一些填塞封包，因此為減少封包的處理時(shí)間，故在傳輸串流分派器取得封包之后，便先檢查此流封包是否發(fā)生錯(cuò)誤與是否為填塞封包，若發(fā)生錯(cuò)誤，則將封包丟棄，而整個(gè)執(zhí)行程序?qū)⑦M(jìn)入到錯(cuò)誤分類機(jī)制(ErrorCategorizationmechanism)中，若為填塞封包則即早丟棄，避免填塞封包送入子譯碼器中花費(fèi)不必要的處理時(shí)間。為簡化子譯碼器的復(fù)雜度，傳輸串流分派器系使用分派表方式來注冊欲譯碼的封包子譯碼器類型，并藉此分離各個(gè)子譯碼器之間的相依關(guān)系。分派表系采用雜湊表(Hashtable)的一種應(yīng)用，使用雜湊表的優(yōu)點(diǎn)在于不論注冊數(shù)量的多寡，查詢時(shí)間花費(fèi)永遠(yuǎn)固定為常數(shù)值，因此將可廣泛支持未來規(guī)范中新增的窗體或電視臺所自訂的私有窗體。而整個(gè)傳輸串流分派器的分派處理動作則如表1的虛擬程序代碼(Pseudocode)所示。

表1 傳輸串流分派器之虛擬程序代碼

If System Start then

Set Buffer to receive TS packet

If ErrorIndicator is equal to 1

Drop this TS packet

Start Error Categorization mechanism

else if PID is equal to 8191

Drop this TS packet

else if PayloadUnitStartIndicator is equal to 1

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

If sub-decoder is not found

Drop this unknown TS packet

else

Call the sub-decoder to decode

else

If ContinueSection is not equal to Null

Call the sub-decoder to continue decode

else

Drop this TS packet

 

4.2子譯碼器組件

于初始化時(shí)期，子譯碼器必須向傳輸串流分派器注冊封包類型，以便從傳輸串流分派器中得到相對應(yīng)的封包。

表2子譯碼器共通虛擬程序代碼

Function：DecodeFunction

從傳輸串流分派器中取得section中的第一個(gè)封包并譯碼。

Set PayloadBuffer to receive the section data

Set PaylaodLength equal to PacketPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

else

Set ReceiveLength equal to PayloadLength

Set ContinueSection to this sub-decoder

Function：ContinueFunction

從傳輸串流分派器中取得接續(xù)的section封包資料。

Set PayloadBuffer to receive the section data

Set PayloadLength equal to PayloadLength add

ReceiveSectionPayloadLength

If SectionHeaderLength is equal to 12

Decode the section header

If section payload is not equal to Null

Output section payload to

SectionPayloadCottectionUnit

If PayloadLength is equal to SectionLength

Set ContinueSection to Null

else

Set ContinueSection to this sub-decoder

子譯碼器共通的虛擬程序代碼如表2所示，傳輸串流分派器則根據(jù)分派表中已經(jīng)注冊的子譯碼器信息來遞送封包給特定子譯碼器，子譯碼器則根據(jù)封包中所傳達(dá)的數(shù)據(jù)將訊息或組態(tài)釋出，并傳遞給控制器對象。當(dāng)子譯碼器藉由解讀section的長度字段得知該section數(shù)據(jù)長度超過一個(gè)封包所能承載的數(shù)量時(shí)，會將接續(xù)片段指針對象設(shè)定指向自己。此后，當(dāng)傳輸串流分派器接收到封包后，將會檢視接續(xù)片段指針對象是否為空對象，若為空對象則從分派表中尋找負(fù)責(zé)解碼此封包的子譯碼器。若非空對象，則將封包傳送給欲接續(xù)接收的子譯碼器，直到整個(gè)section數(shù)據(jù)接收完成之后，子譯碼器才會將接續(xù)片段指針對象重設(shè)為空對象，而從下一個(gè)封包開始，將以正常程序?qū)ふ曳獍幼g碼器。

4.3控制器對象

控制器對象為DVB-H軟件接收器與使用者互動的接口?？刂破鞯闹饕δ艹藬X取使用者的輸入訊息之外，也實(shí)作訊息輸出接口。在控制行為部分，控制器僅與子譯碼器互動，在訊息輸出方面，則是與整個(gè)DVB-H軟件接收器中的所有組件連結(jié)在一起。另外，在實(shí)作設(shè)計(jì)上則不同于傳統(tǒng)將控制接口嵌入于播放器的作法，藉由此方式達(dá)到DVB-H軟件接收器與播放裝置各別獨(dú)立的能力。

4.4MPE-FEC運(yùn)算單元

MPE-FEC運(yùn)算單元主要負(fù)責(zé)進(jìn)行整個(gè)MPE-FEC機(jī)制的運(yùn)作，如圖8而其又可分為三個(gè)運(yùn)作單元，分別為：MPEsection數(shù)據(jù)收集單元、FECsection數(shù)據(jù)收集單元與所羅門譯碼單元(RSDecodingUnit)。

其中MPE與FECsection數(shù)據(jù)收集單元主要負(fù)責(zé)收集從子譯碼器解讀取出的section數(shù)據(jù)，當(dāng)完成section數(shù)據(jù)收集后即填入位于所羅門譯碼單元中的MPE-FEC框架中，直到整個(gè)框架的所有section數(shù)據(jù)均已收集完成，則立即進(jìn)行每列的所羅門糾錯(cuò)譯碼，藉此來修復(fù)于傳輸時(shí)因噪聲干擾所造成的數(shù)據(jù)錯(cuò)誤。[!--empirenews.page--]

4.5錯(cuò)誤產(chǎn)生、偵測與分類機(jī)制

當(dāng)接收端硬件接收到由傳送端所傳送的傳輸串流封包時(shí)，硬件會先對封包進(jìn)行一次所羅門譯碼，若是超出其糾錯(cuò)解碼能力時(shí)，將會把封包標(biāo)頭內(nèi)的錯(cuò)誤指標(biāo)字段(ErrorIndicator)設(shè)定為1，藉此來標(biāo)示發(fā)生錯(cuò)誤的封包，而本研究于錯(cuò)誤偵測判斷時(shí)，即是根據(jù)此標(biāo)頭字段值，并透過設(shè)定此字段值來產(chǎn)生顯著的錯(cuò)誤數(shù)據(jù)，以突顯MPE-FEC機(jī)制的運(yùn)作。當(dāng)發(fā)現(xiàn)錯(cuò)誤封包之后，將立即執(zhí)行錯(cuò)誤分類機(jī)制來找出錯(cuò)誤發(fā)生在整個(gè)section的哪個(gè)區(qū)段并在一個(gè)與MPE-FEC框架相同大小的ErrorBit-mapBuffer(EBB)中的相對應(yīng)位置設(shè)成1來表示其在框架中的錯(cuò)誤位置，以便提供往后所羅門譯碼所需的錯(cuò)誤位置數(shù)據(jù)，而整個(gè)錯(cuò)誤分類機(jī)制的虛擬程序代碼如表3所示。

表3 錯(cuò)誤分類機(jī)制虛擬程序代碼

If ErrorIndicator is equal to 1

If HeaderDecoded is true

If error at middle of section

Set 1 in EBB according to the TS payload

region of this section in MPE-FEC frame

Drop this TS packet

else

If packet carry part of next section header

Set 1 in EBB according to the TS payload

region of this section and whole the next

section payload region in MPE-FEC

frame

Drop this TS packet and drop all TS

packets of next section

else

Set 1 in EBB according to the TS

payload region of this section in

MPE-FEC frame

Drop this packet

else

Set 1 in EBB at whole section payload

region in MPE-FEC frame

Drop all TS packets of this section

當(dāng)傳輸串流分派器收到封包并立即偵測與判斷封包標(biāo)頭中的錯(cuò)誤指標(biāo)字段是否為1，若為1則表示發(fā)生錯(cuò)誤而進(jìn)一步開始找出此錯(cuò)誤封包所載送的數(shù)據(jù)是位于整個(gè)section的哪個(gè)區(qū)段位置，若是發(fā)生在section標(biāo)頭部位，由于標(biāo)頭是載送整個(gè)section最重要的信息來源位置，因此為了能正確地接收往后的section，故當(dāng)發(fā)生錯(cuò)誤的封包包含任一字節(jié)的標(biāo)頭信息時(shí)，將會將整個(gè)section數(shù)據(jù)完全丟棄而等待下一個(gè)正確載送section標(biāo)頭的封包進(jìn)來。如果發(fā)生錯(cuò)誤的封包是載送標(biāo)頭信息之外的部份時(shí)，則再進(jìn)一步判斷封包中載送的數(shù)據(jù)范圍是位于整個(gè)section數(shù)據(jù)的哪個(gè)區(qū)段，若僅是中間部位，則只丟棄該封包而等待下一個(gè)正確封包即可，但若是section末端數(shù)據(jù)的話，則需再進(jìn)一步的判斷是否包含到下一個(gè)section標(biāo)頭信息，如果有的話，則一并把載送下一個(gè)section數(shù)據(jù)的所有封包丟棄而等待下一個(gè)正確載送section標(biāo)頭的封包進(jìn)來，反之則一樣僅丟棄該封包即可。

4.6Time-Slicing傳輸機(jī)制設(shè)計(jì)

DVB-H傳送數(shù)據(jù)的方式是采用Burst傳輸方式，采用此種方式時(shí)，則必須精確地得知下一個(gè)Burst的抵達(dá)時(shí)間與傳輸該Burst數(shù)據(jù)的最大傳輸時(shí)間，才能讓硬件能于正確時(shí)間點(diǎn)開關(guān)接收器來接收數(shù)據(jù)，而接收端在接收數(shù)據(jù)時(shí)，必須滿足兩個(gè)時(shí)間要求：

(1) 當(dāng)Burst到來，并接收到第一個(gè)MPEsection進(jìn)行解讀時(shí)，section標(biāo)頭必須在Delta-TJitter時(shí)間內(nèi)解碼并將Delta-T值回傳到實(shí)體層。

(2) IP解封裝器必須于Delta-T時(shí)間內(nèi)完成所有section的譯碼與MPE-FEC機(jī)制的運(yùn)作，并將數(shù)據(jù)輸出到終端。

由于未必能在Burst的最大維持時(shí)間內(nèi)將所有section數(shù)據(jù)解讀完成，故接收端必須以緩沖器暫存整個(gè)Burst時(shí)間內(nèi)的所有section封包，而封包的譯碼工作在剩余的Delta-T時(shí)間內(nèi)完成即可。

 

除此之外，由于在處理的過程中使用緩沖器來暫存section封包數(shù)據(jù)，而再取出解讀時(shí)，其標(biāo)頭中所挾帶的實(shí)時(shí)性Delta-T信息已失效，僅有解讀第一個(gè)MPEsection所造成的延遲時(shí)間最為短暫。

因此，在實(shí)作上即采用第一個(gè)MPEsection標(biāo)頭所挾帶的Delta-T信息來告知實(shí)體層下一個(gè)Burst的到來時(shí)間，而其余section標(biāo)頭內(nèi)的Delta-T信息將不被讀取采用。整個(gè)section封包處理延遲時(shí)間示意圖即以圖9呈現(xiàn)。

圖9 section封包處理延遲時(shí)間示意圖

5、 實(shí)驗(yàn)?zāi)M結(jié)果

本研究整個(gè)實(shí)驗(yàn)?zāi)M結(jié)果均是利用個(gè)人計(jì)算機(jī)(PC)進(jìn)行測試，個(gè)人計(jì)算機(jī)的配備如表4所呈現(xiàn)，并以公視試播計(jì)劃所提供的傳輸串流當(dāng)作是播放測試檔案，而表5則是從公視所提的串流檔案擷取出來的信息。

5.1正確性驗(yàn)證

本研究糾錯(cuò)后的數(shù)據(jù)驗(yàn)證是利用文字處理軟件Ultra-Edit所提供的二進(jìn)制檔案比對來完成，分別將添加錯(cuò)誤的每個(gè)Burst數(shù)據(jù)與修正后的數(shù)據(jù)存成檔案后再與驗(yàn)證檔案進(jìn)行比對。

5.2效能評估

本文的MPE架構(gòu)與Time-Slicing傳輸機(jī)制設(shè)計(jì)主要采用[4]的觀實(shí)作觀念與架構(gòu)，[4]中對每個(gè)Burst數(shù)據(jù)(僅有針對MPEsection)的處理時(shí)間已有相當(dāng)完整的分析信息，故本論文即針對主要設(shè)計(jì)的MPE-FEC糾錯(cuò)機(jī)制做實(shí)作上的效能分析與探討。

表4個(gè)人計(jì)算機(jī)基本配備表

處理器廠牌規(guī)格

Intel Pentium 4

處理器處理速度

3.0 GHz

硬盤大小

80 GBytes

內(nèi)存容量

512 MBytes

表5公視影像來源參數(shù)數(shù)據(jù)

參數(shù)

數(shù)值

檔案大小

755,605,652(bytes)

封包總數(shù)

4,019,179(封包以188個(gè)bytes為單位)

MPE-FEC框架總列數(shù)

512列

Delta-T

1250 ms

Delta-T Jitter

7.5 ms

最大Burst持續(xù)時(shí)間

200 ms

省電效率

79.7%

每秒畫面更新速率

15 (frame per second,

整個(gè)傳輸流檔案中，每個(gè)Burst所挾帶的框架大小為255×512，而框架資料量大小為1Mbits(128kBytes)，每個(gè)MPE-FEC框架執(zhí)行的RS糾錯(cuò)運(yùn)算次數(shù)為512次(即每一列執(zhí)行一次RS糾錯(cuò)運(yùn)算)，編碼率(coderate)為2/3的情況條件下，10個(gè)Burst、50個(gè)Burst與100個(gè)Burst單純使用Java以及RS譯碼采用Euclid算法在Windows上的完整MPE-FEC糾錯(cuò)機(jī)制與單純RS譯碼的平均執(zhí)行時(shí)間如圖13所示。[!--empirenews.page--]

圖13完整MPE-FEC機(jī)制運(yùn)作與單純RS解碼的平均執(zhí)行時(shí)間

由圖13可知整個(gè)MPE-FEC機(jī)制的運(yùn)作時(shí)間大多花費(fèi)在RS譯碼上，因此本研究進(jìn)一步將RS譯碼使用C/C++并且使用RS內(nèi)部不同的譯碼算法透過Java的JNI(JavaNativeInterface)呼叫在Windows上執(zhí)行完整的MPE-FEC機(jī)制，其執(zhí)行解果如圖14所呈現(xiàn)。

圖14Java與C/C++以及不同算法在Windows上的平均執(zhí)行時(shí)間

 

雖然就執(zhí)行時(shí)間上來看，使用C/C++并采用BM算法的譯碼時(shí)間較短，但對于表5所擷取到的Delta-T時(shí)間(1250毫秒)而言，仍無法達(dá)到DVB-H接收端的實(shí)時(shí)播放。因此，再進(jìn)一步測試在Linux系統(tǒng)上不同算法的C/C++語言執(zhí)行時(shí)間并與Windows的執(zhí)行時(shí)間匯整而得到圖15。

圖15不同操作系統(tǒng)下，C/C++使用不同算法的執(zhí)行時(shí)間

在Linux操作系統(tǒng)上執(zhí)行完整的MPE-FEC機(jī)制運(yùn)作后所得到的平均執(zhí)行時(shí)間均小于在Windows上的執(zhí)行時(shí)間。此外，使用BM算法在Linux與Windows上的執(zhí)行時(shí)間更相差約略2.5秒，并且已能符合DVB-H接收端實(shí)時(shí)播放的時(shí)間要求。

最后在Windows將測試檔案加入錯(cuò)誤后，再透過本研究所設(shè)計(jì)的軟件系統(tǒng)進(jìn)行糾錯(cuò)之后所得的數(shù)據(jù)存成檔案再進(jìn)行播放。

6、結(jié)論

本研究利用純軟件的方式來仿真實(shí)作DVB-HMPE-FEC糾錯(cuò)機(jī)制，并確實(shí)能修復(fù)還原添加于測試檔案中的錯(cuò)誤，雖然于Windows操作系統(tǒng)上的數(shù)據(jù)處理時(shí)間已超過實(shí)時(shí)播放的時(shí)間要求，但在Linux上采用BM算法的RS譯碼測試實(shí)驗(yàn)結(jié)果，卻已符合實(shí)時(shí)播放的限制條件。因此，以系統(tǒng)的執(zhí)行時(shí)間及實(shí)時(shí)播放的角度來看，對于往后的軟件設(shè)計(jì)實(shí)作，在Linux上實(shí)現(xiàn)，或許會比在Windows上更為理想。