數(shù)字電視應急信息廣播系統(tǒng)發(fā)送端設計

潘明照 賈大偉

（作者單位：平度市融媒體中心）

為了實現(xiàn)在突發(fā)公共事件中盡快發(fā)布群眾所需信息，提升政府在處理突發(fā)性危機事件中的指揮調度能力，中國共產(chǎn)黨的十七屆六中全會就提出建立統(tǒng)一聯(lián)動、安全可靠的國家應急廣播體系，并致力于推動該體系的建設。隨著數(shù)字電視技術、計算機技術在廣播電視行業(yè)的普及和推廣，利用數(shù)字電視廣播業(yè)務發(fā)布應急信息成為應急廣播體系建設的重要內容之一，引起相關領域專家與學者的廣泛研究[1-2]，如使用數(shù)字廣播應急預警系統(tǒng)（DVB-EWS）等。進入數(shù)字時代，通過數(shù)字電視開展增值業(yè)務成為可能。

由于數(shù)字壓縮技術的使用，數(shù)字電視可以在一個原模擬電視頻道中播出6～8套高質量的標清電視節(jié)目（或者2套左右的高清電視節(jié)目），隨著傳輸節(jié)目套數(shù)的增加，用戶如何在眾多電視節(jié)目中快速找到想要觀看的電視節(jié)目就成為一個問題。為幫助用戶了解相關的節(jié)目信息，DVB-C（有線數(shù)字視頻廣播）制定了相關的電子節(jié)目指南（Electrical Program Guide, EPG），即一種電視節(jié)目信息導航系統(tǒng)，我國也制定了相應的EPG標準[3]。通過EPG，用戶可以了解待播或正在播出節(jié)目的相關信息，包括節(jié)目名稱、時間、內容介紹等。EPG的播發(fā)需要在節(jié)目播出前端將符合數(shù)字視頻廣播（Digital Video Broadcasting, DVB）標準的業(yè)務信息（Service Information, SI）插入傳送流（Transport Stream, TS）中。SI不僅攜帶了EPG所需的全部數(shù)據(jù)，還規(guī)定了一些可以由用戶定義的結構。通過這些結構，就可以開發(fā)一些基于SI的增值業(yè)務。本文設計的應急信息廣播系統(tǒng)就是一個基于SI的自定義結構開發(fā)的業(yè)務信息系統(tǒng)。

數(shù)字電視應急信息廣播系統(tǒng)包括信息編輯、信息發(fā)送和信息接收三個部分。信息編輯指信息編輯工作站對各類應急信息進行編輯制作，并將編輯制作好的信息保存到數(shù)據(jù)庫服務器中。信息發(fā)送是指信息播發(fā)服務器將編輯好的各種（應急）信息從數(shù)據(jù)庫服務器中取出，并按照SI的自定義結構的要求進行打包，插入數(shù)字電視的播出碼流中，經(jīng)復用調制后送到數(shù)字發(fā)射機播出或者送入有線電視系統(tǒng)進行播出。信息接收是指數(shù)字電視機頂盒從解碼后的TS流中取出相應的（應急）信息，在用戶的電視機上進行顯示、提醒。本文內容主要針對數(shù)字電視應急信息廣播系統(tǒng)的信息發(fā)送端展開。

1 系統(tǒng)發(fā)送端的基本原理

發(fā)送端的任務是把需要播發(fā)的各種信息按順序以一定的碼率進行打包，然后發(fā)送出去。信息播發(fā)服務器能夠定時查看數(shù)據(jù)庫服務器要發(fā)送的信息，并將這些信息打包，借助碼流播發(fā)卡輸出，經(jīng)異步串行接口（Asynchronous Serial Interface, ASI）智能切換器（冗余設計，防止某臺信息播發(fā)服務器出現(xiàn)故障）后選擇最優(yōu)一路進入碼流分配器，將打包的碼流分配，然后送到要插入信息的復用器。各復用器從打包的碼流中取出本復用器要插入的信息，與視音頻節(jié)目等其他業(yè)務信息進行復用，形成復用的碼流，進入加擾調制等后續(xù)處理部分。其基本原理如圖1所示。

圖1 數(shù)字電視應急信息廣播系統(tǒng)發(fā)送端基本原理

進行發(fā)送端設計時，首先要確定需要發(fā)送的信息內容，明確這些信息在終端如何顯示，并規(guī)劃好這些信息是在全頻點發(fā)送還是只在某些頻點發(fā)送。確定了要發(fā)送的信息和所在的頻點后，還需確定要發(fā)送的各類信息的碼率。（有線）數(shù)字電視一般采用正交振幅調制（Quadrature Amplitude Modulation, QAM），分為16QAM、64QAM、256QAM等多種調制方式，數(shù)字越大，頻帶利用率越高，但抗干擾能力也隨之降低。不同的QAM調制方式能夠傳輸?shù)拇a率是不同的，如64QAM的有效數(shù)據(jù)傳輸速率大約是38 Mb/s。除去音視頻節(jié)目和其他業(yè)務占用的碼率，剩余的才是可用于應急信息發(fā)布的碼率。如果超過這個碼率，就會出現(xiàn)丟包現(xiàn)象，造成音視頻節(jié)目的卡頓。為不影響節(jié)目的正常播出，碼率應小于該值，并留有一定余量。

確定好各類信息的碼率，就可以進行打包播發(fā)了。打好包的數(shù)據(jù)的發(fā)送比較簡單，使用無窮循環(huán)就可以實現(xiàn)連續(xù)不斷地發(fā)送數(shù)據(jù)。但是，各類信息的播出碼率是不同的，在打包各類信息時的數(shù)據(jù)量也是不一樣的，因而打包過程比較復雜。

2 應急信息及其處理

2.1 應急信息的播發(fā)途徑

應急信息既可以是文字形式也可以是圖片形式，甚至可以是音頻形式或視音頻形式。本文設計的應急信息廣播系統(tǒng)可以在數(shù)字電視顯示終端上通過各種方式顯示各種等級的應急信息。當應急信息等級較高時，可在顯示畫面的同時播出聲音信號，甚至可以強制切換到應急頻道進行信息播發(fā)。應急信息的播發(fā)途徑分為以下幾種：

（1）開機畫面。這是機頂盒加電后顯示的第一幅畫面。在機頂盒加電啟動過程中需要一定的時間，可以利用這段時間的開機畫面進行應急信息的播發(fā)。

（2）EPG搭載。在顯示主菜單、頻道列表、頻道導航條時，利用空余版面加載或疊加顯示要播發(fā)的應急信息。此外，節(jié)目切換時一般會顯示換臺后節(jié)目的正播和待播信息，也可以同時加載要播發(fā)的應急信息。

（3）音量調整。利用調整音量時電視機上的音量顯示的空余版面顯示應急信息。

（4）游動字幕。這是應急信息播發(fā)最靈活、最有效的一種途徑。比如在播發(fā)各類預警信息時，如果在每個頻點都插入應急信息，則可以做到顯示全覆蓋，即所有收看電視節(jié)目的用戶不論在收看什么節(jié)目都可以接收得到應急信息。

（5）基于特殊業(yè)務信息加載應急信息。比如利用天氣預報顯示界面加載應急信息，用戶可通過遙控器按鍵，在查詢天氣預報的同時獲取應急信息內容。

（6）其他途徑。比如掛角信息發(fā)布，在數(shù)字電視終端畫面的某角顯示應急信息。

為了簡單實用，將其做如下簡化：

播發(fā)游動字幕時停止其他信息的播發(fā)。即游動字幕的播發(fā)具有較高的優(yōu)先級，可用于重大應急信息的即時播發(fā)。此外，高級別的緊急信息可以強制在數(shù)字電視的所有節(jié)目中顯示播出。而其他信息的更新播發(fā)只在每天的一個固定時間，比如每天晚上8點重新讀取數(shù)據(jù)庫服務器的記錄，將查詢更新后的記錄重新打包播發(fā)。

由于這樣的簡化，系統(tǒng)需應對正在播發(fā)的信息中存在錯誤需要立即更新的情況。針對這種情況，編輯制作端將更正后的信息編輯好并存入數(shù)據(jù)庫服務器后通知發(fā)送端，發(fā)送端接收到此信息后重新讀取數(shù)據(jù)庫服務器的記錄，并重新打包播發(fā)。

2.2 應急信息的打包描述

信息的打包發(fā)布需要按照DVB-C的SI信息的標準，并最終打包成188字節(jié)的TS包。其中包含的信息圖片、文字及與本信息相關的其他結構是其凈負載。

在DVB-C中，所有的SI/節(jié)目特定信息（Program Specific Information, PSI）都以表的形式進行傳輸，表中包含了整個節(jié)目信息和業(yè)務信息，這些表在傳輸時，被封裝在大小固定的被稱為段（section）的數(shù)據(jù)塊中。本系統(tǒng)的發(fā)送端采用私有段結構（見圖2），即ISO/IEC 13818-1:2019規(guī)定的私有段結構中將section syntax indicator置為1時的結構[4]，它包括段頭(從table id到last section number)、私有數(shù)據(jù)（N privata data）和一個32位的循環(huán)冗余校驗碼（CRC32）。

圖2 私有段結構示意圖

除了封裝要發(fā)布信息的私有段外，還有一種私有段表，稱為描述符私有段表。本系統(tǒng)設計了缺省信息版本號描述符、天氣預報描述符、取消描述符、游動字幕屬性描述符等各種描述符。

每一個具體的信息基本上是以圖片的形式進行發(fā)布的。在封裝這種私有段時，需在段頭后加入一個描述該圖片的相關描述符，如圖片類型描述符（這個描述符是必有的）、鏈接描述符（這個描述符是可選的）等。圖片類型描述符能夠描述該圖片屬于哪個類型的信息、圖片本身的文件類型（如png、jpg、gif等）信息，以便接收端解碼。在這些描述符之后是該圖片的具體數(shù)據(jù)。

也就是說，系統(tǒng)發(fā)送端會將每一個信息封裝成一個段或多個段。對每一個段都要計算其循環(huán)冗余校驗碼CRC32。

將各信息封裝到段后，就可以進入TS打包環(huán)節(jié)。TS包的大小固定為188字節(jié)，TS層分為三個部分：TSHeader（TS包頭）、Adaptation Field（調整字段）、Payload（負載）。其中，包頭結構中的有效凈荷單元開始指示為payload_unit_start_indicator，標志此TS包中帶有SI數(shù)據(jù)分段的第一個字節(jié)，即這個包是一個段的起始包。

在循環(huán)播出時，雖然根據(jù)業(yè)務信息封裝生成的段是不變的，但是在每次定時處理時根據(jù)段生成的TS包卻是不同的，這是因為TS包中有連續(xù)計數(shù)（continuity_conunter）字段。為保證連續(xù)計數(shù)器的連續(xù)，需要在每次播發(fā)時將生成的TS包的continuity_conunter字段重新修改，以保證continuity_conunter字段的連續(xù)。

也就是說，打包有兩個層次：第一個層次是先把凈負載封裝成多個段，第二個層次是將生成的段打包成一個個的TS包。

將所有的業(yè)務信息都打包成連續(xù)的TS包后，還需要生成一個具有一定時間間隔（如0.5 s）的總的數(shù)據(jù)包，按照各業(yè)務信息設定的發(fā)送速率，計算在這個時間間隔內各業(yè)務信息需要發(fā)送的TS包的數(shù)目，并按一定順序將其插入緩沖區(qū)（TS Buffer）中，利用定時函數(shù)將此緩沖區(qū)的內容通過播發(fā)卡發(fā)送出去。

2.3 應急信息數(shù)據(jù)和輔助信息的讀取加密及打包成段

制作完成的應急信息或者從上級部門傳送過來的應急信息通過制作端上傳到服務器的數(shù)據(jù)庫中，發(fā)送端定時讀取要播出的應急信息。

應急廣播信息事關人民生命財產(chǎn)的安全，因此必須采取措施保證信息內容的真實性、完整性、權威性[5]。為保證應急信息的安全，需要對業(yè)務（應急）信息進行加密、數(shù)字簽名等處理，實現(xiàn)應急廣播消息和指令的安全。假定這些處理已經(jīng)在編輯制作端完成，發(fā)送端負責這些已經(jīng)完成處理的信息的發(fā)送。本系統(tǒng)應急信息的存取采用ADO編程方式。通過數(shù)據(jù)庫，選出要播發(fā)的數(shù)據(jù)記錄，對每一條這樣的記錄，通過其組ID找出其組ID此時對應的版本號gidvernum，并更新其下一個數(shù)據(jù)記錄對應的版本號。再根據(jù)這條記錄的包ID找到對應的連續(xù)記數(shù)（continuity_conunter）信息。有了這些信息就可以生成一個針對此記錄的InfoGroupDataRecord對象。根據(jù)InfoGroupDataRecord中的一個類InfoContentSectionTable的指針對象pinfopicture，在類InfoContentSectionTable中封裝各種與段生成相關的函數(shù)和信息，在makeupsections函數(shù)中將本數(shù)據(jù)記錄的應急信息封裝成段。

需注意正確設置最后一個段的大小。在生成段時，要設置段頭信息。如果段表有描述符，則要首先封裝描述符，描述符之后才是含有加密后的業(yè)務圖片的信息結構數(shù)據(jù)。在每個段的最后計算其CRC32。生成段表之后就可以進行TS包的打包了。

2.4 打包信息的發(fā)送

以一定速率重復發(fā)送這些信息的基本方法是利用定時器。只需要注意發(fā)送的速率不要太高使得復用器的碼率超載，定時器的精度倒不是特別重要。當然作為系統(tǒng)來說，應盡可能地讓碼率精確一些。對本文設計的系統(tǒng)來說，可以考慮使用多媒體定時器。即用timeSetEvent函數(shù)，該函數(shù)可以達到1 ms的分辨率。

本系統(tǒng)假定游動字幕形式的應急信息在一個固定的時間點（如每晚8∶00）進行播發(fā)（不太緊急的應急信息的播出，如天氣災害預報等），需在定時器的回調函數(shù)中設置一個變量m_loop，在每次調用時其值增加1，以此模擬回調函數(shù)調用的次數(shù)。通過監(jiān)視這個變量，看是否到達預定的時間，到時間后即啟動游動信息的播發(fā)。如果沒有到達預定的時間，則回調函數(shù)更新將要播發(fā)的數(shù)據(jù)的continuity_conunter字段，并將此數(shù)據(jù)發(fā)至播發(fā)卡播出。

用比較m_loop的次數(shù)來判斷是否到達定時時間，是因為定時間隔是一個常數(shù)（如0.5 s一次）。通過當前時間與下次定時時間的差就可以知道要循環(huán)多少次能夠到達下次定時時間，該方式可能不太精確，但對于本文設計的系統(tǒng)來說是足夠的，因為不太緊急的應急信息并不一定需要太精確的定時播出。

游動字幕的播出與其他應急信息的播出不同，它不需要一直循環(huán)播出，其在顯示端的游動一般只需要兩次即可。也就是說，發(fā)送端的一條游動字幕信息只需播發(fā)2～3次即可（多播發(fā)幾次可以保證接收端軟件能夠完整收到此信息）。在所有游動字幕信息播發(fā)完成后就可以重新讀取其他應急信息進行播發(fā)了。

2.5 緊急信息的播發(fā)

除上述應急信息的播發(fā)外，對某些緊急消息必須實現(xiàn)即時播發(fā)。這意味著對緊急信息需要立即響應。為此，在發(fā)送端和編輯制作端需使用網(wǎng)絡編程。在編輯制作端將需要即時播發(fā)的信息編輯好后通知發(fā)送端，發(fā)送端接收到有緊急信息需要播出的消息后，停止當前信息的播發(fā)，轉為播發(fā)此緊急信息。緊急信息既可以設定播出次數(shù)或到期時間，也可以設置為無窮（即一直播出）。若為一直播出，則需要通過制作端發(fā)送停止緊急信息播發(fā)的消息以停止此緊急信息的播發(fā)。

3 調試

調試是編程開發(fā)重要的一個方面，通過調試找出并改正編程錯誤是開發(fā)人員的一項基本技能。本系統(tǒng)需要通過網(wǎng)絡傳輸，因此要注意字節(jié)序問題。字節(jié)序錯誤，就會產(chǎn)生錯誤的結果。所以，如果接收到的數(shù)據(jù)有問題，就要查看字節(jié)序是否存在問題。另外，系統(tǒng)對每一個段都要計算循環(huán)冗余校驗碼CRC32，在計算CRC32時需注意段長的計算問題。

除開發(fā)環(huán)境提供的調試手段外，程序開發(fā)人員還可以將打包數(shù)據(jù)寫入文件進行分析，看數(shù)據(jù)是否正確及哪里出了問題。同時，還可以寫出相應的解析程序，對打包的數(shù)據(jù)進行分析。解析程序既可以用于打包數(shù)據(jù)的測試，也可以直接用于接收端軟件，或者使用接收端的解析軟件對打包的數(shù)據(jù)進行解析，兩者可互相驗證。

然而，打包數(shù)據(jù)正確、接收解析正確也并不意味著所有都正常。在測試調試過程中發(fā)現(xiàn)，如果每個PID（Packet ID，包ID）只在有應急信息圖片數(shù)據(jù)的時候才發(fā)送數(shù)據(jù)，反之不發(fā)送數(shù)據(jù)，則如果某個PID不存在應急信息數(shù)據(jù)，在剛沒有數(shù)據(jù)時，接收到的碼流中其他PID的碼流也會出現(xiàn)錯誤，TS計數(shù)不連續(xù)，即會出現(xiàn)丟TS包的情況，一般每個PID會丟一個包。出現(xiàn)這種現(xiàn)象的原因沒有得到解釋，但估計很大程度上與復用器有關。所以讓每個PID在沒有數(shù)據(jù)時發(fā)送缺省的應急信息數(shù)據(jù)，以免引起丟包。以上是在播出碼流中隨時添加、刪除應急信息時可能發(fā)生的情況，如果規(guī)定播發(fā)時不在播出的碼流中添加、刪除應急信息則不會存在上述問題。

4 結語

發(fā)送端軟件是一個打包程序，它將打包的數(shù)據(jù)通過播發(fā)卡發(fā)送出去。這是一個循環(huán)播發(fā)的系統(tǒng)，應急信息播發(fā)完一遍后從頭繼續(xù)重新播發(fā)。發(fā)送端對定時精度要求并不嚴格，只需注意發(fā)送的速率不要超過其上限即可。如果某個頻點的總碼率超過了上限，則有可能引起該頻點的節(jié)目出現(xiàn)馬賽克的現(xiàn)象。一般說來，開機畫面、節(jié)目指南附加信息等在主頻點播發(fā)時使用的碼率較大，所以電視系統(tǒng)在主頻點的節(jié)目安排應該使其碼流有較大的余量。