清鶴數(shù)字電視頭端獲取電信清流的應(yīng)用軟件的制作方法
【專利摘要】本發(fā)明公開了一種用于現(xiàn)有數(shù)字電視行業(yè)的清流獲取的解決方案，以構(gòu)建一個綜合、健壯的清流獲取平臺。該方案充分利用了現(xiàn)有的網(wǎng)絡(luò)數(shù)據(jù)獲取技術(shù)和電信運營商所提供的數(shù)字電視接入設(shè)備，同時具有提供靈活和健壯的數(shù)字電視服務(wù)的優(yōu)點。該平臺不僅可以幫助業(yè)務(wù)合作伙伴能夠快速開發(fā)，靈活的整合各種數(shù)字電視數(shù)據(jù)資源和應(yīng)用；同時還可以適應(yīng)各種數(shù)字電視信號源和網(wǎng)絡(luò)環(huán)境，并能夠以較低的成本靈活的在各種方案之間進行切換，在提供較好的擴展性的同時使得對終端用戶的使用影響降到最低。
【專利說明】
清鶴數(shù)字電視頭端獲取電信清流的應(yīng)用軟件
技術(shù)領(lǐng)域
[0001 ]本發(fā)明涉及新媒體技術(shù)領(lǐng)域，特別是涉及云與大數(shù)據(jù)分析。
【背景技術(shù)】
[0002]電視技術(shù)服務(wù)的形式已經(jīng)從模擬電視發(fā)展到數(shù)字電視，從廣播電視服務(wù)到互動視頻服務(wù)。電視的使用范圍早已超越了廣播娛樂界，并深深地擴展到文化教育、科研管理、工礦企業(yè)、醫(yī)療衛(wèi)生、公安交通、軍事宇航等各個重要部門。數(shù)字電視節(jié)目源，無論是點播、直播還是交互式視頻服務(wù)，都通過傳輸流的形式進行服用和傳輸。傳輸流在解決了傳輸和封裝的問題，同時也給各種應(yīng)用平臺和第三方服務(wù)提供商與數(shù)字電視信號交互提供了可能。一般的數(shù)字電視技術(shù)大都采用DVB-T、DVB_S信號源，接收機，編碼器，交換機，數(shù)字電視機的解決方案，如圖1所示。有些國家和地區(qū)，由于版權(quán)和媒體管理的限制，信號源通常是由政府指定的運營商控制和管理，用戶和第三方服務(wù)提供商只能從這些指定的運營商那里獲取信號，或者必須從運營商那里獲取授權(quán)許可。
[0003]我們從現(xiàn)有的數(shù)字電視運營商對數(shù)字電視服務(wù)所提供的服務(wù)開始，通常最初獲得的數(shù)字電視信號時模擬信號，是不能夠直接使用的，要經(jīng)過衛(wèi)星接收機、編碼器或網(wǎng)絡(luò)適配器等硬件設(shè)備進行轉(zhuǎn)換或處理，然后才可以輸出到用戶和第三方數(shù)字電視服務(wù)提供商使用。這些處理主要分為三類:I)針對衛(wèi)星電視信號，通常使用衛(wèi)星接收機進行模擬-數(shù)字的轉(zhuǎn)換，以供在本地使用，這種方式靈活性較差，用戶可定制性較低，衛(wèi)星接收機的成本較高。
2)對于光纖傳輸?shù)碾娨曅盘枺仨毥?jīng)過網(wǎng)絡(luò)適配器，進行光電轉(zhuǎn)換，這樣的專用線路和設(shè)備優(yōu)點是，信號穩(wěn)定、頻率資源豐富。缺點是成本非常高，只有運營商級別的用戶才會采用這種方式。3)對于地面網(wǎng)絡(luò)傳輸?shù)碾娨曅盘枺ㄓ芯€電視電纜和家庭寬帶網(wǎng)絡(luò)，都需要通過編碼器對電視信號進行碼率控制和編碼格式的轉(zhuǎn)換，一般的第三方數(shù)字電視服務(wù)提供商和集成商會采用這種方式。我國也是采用這種操作模式，其中電信作為唯一的互聯(lián)網(wǎng)和有線電視服務(wù)供應(yīng)商，擁有獨一無二的地面信號傳輸網(wǎng)絡(luò)和平臺，而其他軟件公司、內(nèi)容提供商和設(shè)備供應(yīng)商作為數(shù)字電視服務(wù)提供商合作伙伴，開發(fā)和提供基于該網(wǎng)絡(luò)的視頻處理服務(wù)和客戶端管理接口。這種操作模式的優(yōu)點是:他以相對合理的成本提供較高的靈活性;它允許除了電信提供商之外的第三方集成商和服務(wù)提供商能夠進入數(shù)字電視業(yè)務(wù)中，并通過各種中間設(shè)備和接口對數(shù)字電視業(yè)務(wù)進行集成和處理，最終能夠為用戶提供靈活的性能和低廉的價格。用戶可以享受由數(shù)字電視提供商提供的基本數(shù)字電視服務(wù)和訂制的數(shù)字電視服務(wù)并且可以與不同的行業(yè)融合，這有利于促進數(shù)字電視服務(wù)的發(fā)展和推廣。
[0004]新型交互式數(shù)字電視業(yè)務(wù)的出現(xiàn)和發(fā)展，進一步推動了數(shù)字電視業(yè)務(wù)的發(fā)展，增強了對于數(shù)字電視服務(wù)的靈活性的需求。數(shù)字電視節(jié)目的直播方案中，以蘋果的HLS(HTTPLive Streaming)技術(shù)最具代表性。如圖2所示，HLS技術(shù)主要基于TS的視頻流或文件進行封裝傳輸，HLS類似一個容器封裝MPEG TS傳輸格式，而TS格式正是數(shù)字電視標準領(lǐng)域里最普遍的一種視頻傳輸標準，HLS視頻編解碼采用MPEG-4或H.264，音頻采用AAC，將其應(yīng)用在數(shù)字電視技術(shù)方案上幾乎不需要改動。也正因如此，基于HLS的數(shù)字電視直播方案得到了廣泛的應(yīng)用。但是無論是其它的直播方案還是基于HLS技術(shù)的數(shù)字電視直播方案，前提是已經(jīng)獲取到了未經(jīng)加密或加擾的視頻流，即電信清流。最初的數(shù)字電視直播方案通常無法應(yīng)對電信行業(yè)中多變的視頻格式。這是因為，電信運營商或數(shù)字電視信號提供商為了鑒權(quán)、認證和計費等接入需要，通常都不會將TS碼流直接放在網(wǎng)絡(luò)中進行傳輸，而是對TS流再次進行封裝，例如，采用UDP傳輸?shù)腡S流會通過RTP對TS流進行封裝，采用TCP傳輸?shù)腡S流會通過RTSP對TS流進行封裝。這對于單純采用硬件技術(shù)進行數(shù)字電視直播的解決方案是一個挑戰(zhàn)，并且不利于第三方數(shù)字電視服務(wù)集成商的介入。
[0005]因此，現(xiàn)有的數(shù)字電視直播方案中，第三方數(shù)字電視服務(wù)集成商和企業(yè)用戶通過電信運營商的硬件設(shè)備獲取到多媒體數(shù)據(jù)和信令流后，要通過硬件編碼器或適配器來進行數(shù)據(jù)流和業(yè)務(wù)流的分離，以及視頻數(shù)據(jù)的處理。這樣所帶來的操作上的不靈活性，以及不健壯性等問題是顯而易見的。首先，對于多媒體數(shù)據(jù)的格式轉(zhuǎn)換和其它操作會受限于硬件設(shè)備的功能，一旦需求發(fā)生變化，就必須更新或升級硬件設(shè)備。其次，單純的硬件設(shè)備方案，不能很好的適應(yīng)于實際電信業(yè)的發(fā)展和變化，多媒體的編解碼技術(shù)和標準都在不斷更新和變化，一旦電信業(yè)采用了新的標準和新的傳輸格式，那么也需要通過更新和升級硬件設(shè)備才能繼續(xù)適應(yīng)行業(yè)的變化。這樣多帶來的運營成本和業(yè)務(wù)上的不連續(xù)性還是頗為顯著的。
[0006]基于以上原因，本發(fā)明的目的在于提出一種用于現(xiàn)有數(shù)字電視行業(yè)的清流獲取解決方案，以構(gòu)建一個綜合、健壯的清流獲取平臺。該方案充分利用了現(xiàn)有的網(wǎng)絡(luò)數(shù)據(jù)獲取技術(shù)和電信運營商所提供的數(shù)字電視接入設(shè)備，同時具有提供靈活和健壯的數(shù)字電視服務(wù)的優(yōu)點。有了這個技術(shù)平臺可以幫助業(yè)務(wù)合作伙伴能夠快速開發(fā)，靈活的整合各種數(shù)字電視數(shù)據(jù)資源和應(yīng)用。同時，最新的交互式網(wǎng)絡(luò)電視也可以很容易的利用該方案獲取用戶所關(guān)心的內(nèi)容，并最終獲得較高的客戶滿意度和市場占有率。終端用戶可以獲取并透明的盡享數(shù)字電視應(yīng)用所帶來的感官體驗。更重要的是，這個平臺可以適應(yīng)各種數(shù)字電視信號源和網(wǎng)絡(luò)環(huán)境，并能夠以較低的成本靈活的在各種方案之間進行切換，在提供較好的擴展性的同時使得對終端用戶的使用影響降到最低。

【發(fā)明內(nèi)容】

[0007]為了克服上述現(xiàn)有技術(shù)的不足，本發(fā)明提出了一種數(shù)字電視清流獲取的技術(shù)方案，構(gòu)建了一個適應(yīng)于各種應(yīng)用環(huán)境的電信數(shù)字電視清流的獲取平臺。
[0008]本發(fā)明所采用的技術(shù)方案是:基于中國電信在不同地區(qū)所提供的數(shù)字電視網(wǎng)絡(luò)，為電信用戶創(chuàng)建一整套在不同網(wǎng)絡(luò)環(huán)境、不同應(yīng)用需求、不同集成策略下均可獲取到電信清流的應(yīng)用軟件。該應(yīng)用軟件在不增加額外的網(wǎng)絡(luò)設(shè)備，不增加網(wǎng)絡(luò)拓撲的復(fù)雜性的前提下，向數(shù)字電視的企業(yè)用戶和數(shù)字電視集成商提供穩(wěn)定的電信清流。不僅如此，還可以根據(jù)網(wǎng)絡(luò)環(huán)境的變化，啟用本地視頻發(fā)送機制，避免因網(wǎng)絡(luò)異常情況導(dǎo)致終端用戶的娛樂體驗收到較大影響。本發(fā)明所提供的電信數(shù)字電視清流獲取方案，共有4部分構(gòu)成:正常組播收流并轉(zhuǎn)發(fā)、基于以太網(wǎng)層抓包的獲取方式、硬件編碼器方式、網(wǎng)絡(luò)異常時本地文件發(fā)送。第一部分，在數(shù)字電視節(jié)目未經(jīng)電信進行額外的封裝協(xié)議進行處理的條件下，數(shù)字電視節(jié)目是以MPEG傳輸流的方式在網(wǎng)絡(luò)上傳輸，任何能夠兼容傳輸流格式的播放器和電視機都可以直接解碼并播放該節(jié)目。在這種網(wǎng)絡(luò)環(huán)境下，直接將電信清流從交換機轉(zhuǎn)發(fā)到用戶的媒體服務(wù)器上，以便進行轉(zhuǎn)碼和EPG服務(wù)處理。第二部分，當(dāng)電信的數(shù)字電視節(jié)目的MPEG傳輸流是經(jīng)過其它協(xié)議進行封裝后，再次使用網(wǎng)絡(luò)協(xié)議進行傳輸?shù)?，無法直接使用網(wǎng)絡(luò)協(xié)議棧對傳輸流進行解析得到節(jié)目數(shù)據(jù)，可以在以太網(wǎng)層進行抓包，然后根據(jù)不同的網(wǎng)絡(luò)協(xié)議(UDP或TCP)逐層解析，并最終獲得電視節(jié)目清流。第三部分，對于以上兩種網(wǎng)絡(luò)環(huán)境下，當(dāng)研發(fā)能力不足或追求更簡單的解決方案，可以采用硬件編碼器方案來進行節(jié)目清流的提取。第四部分，當(dāng)網(wǎng)絡(luò)發(fā)生異常，或者其它原因造成無法獲取節(jié)目流時，采用轉(zhuǎn)發(fā)本地文件來生成清流的方式，避免了因數(shù)字電視節(jié)目的缺失而導(dǎo)致節(jié)目不可用，影響終端客戶的滿意度。以上四部分考慮了不同網(wǎng)絡(luò)環(huán)境和客戶自身的需求，針對特定節(jié)目源可以僅采用一種方案，也可以在不同方案之間調(diào)整或動態(tài)切換，因此提供了一種健壯的頭端電信清流獲取方案。
[0009]與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是:(I)該方法充分考慮到各種不同的網(wǎng)絡(luò)環(huán)境和用戶的實際需求，利用電信數(shù)字電視節(jié)目進行直播給出了高效的解決方案。該方案在網(wǎng)絡(luò)傳輸環(huán)境較好且簡單時，采用了傳統(tǒng)的編碼器方案和直接轉(zhuǎn)發(fā)方案，在網(wǎng)絡(luò)環(huán)境和傳輸流封裝較為復(fù)雜時，創(chuàng)新型的采用了底層抓包技術(shù)和本地文件發(fā)送的策略，從而具備了更高的靈活性和冗余性，可以在硬件成本和研發(fā)成本之間進行權(quán)衡，這些都是現(xiàn)有的電信清流獲取方案所不具備的。
[0010](2)以上所述的方案針對現(xiàn)有電信數(shù)字電視節(jié)目的傳輸格式和協(xié)議進行處理，并且可以很靈活方便的對傳輸流進行其它操作，為用戶提供了靈活性。更重要的是該方案具有較好的可擴展性，即使將來電信的數(shù)字電視節(jié)目傳輸流改變了流封裝格式，抑或增加了封裝復(fù)雜度，該方案可以通過增加相應(yīng)改變部分的處理技術(shù)，從而使得該方案仍能正常工作?？偠灾谠摲桨傅膽?yīng)用軟件是健壯的、靈活的并且是可擴展的。
【附圖說明】
[0011 ]圖1為傳統(tǒng)的電視節(jié)目前端和客戶端示意圖
[0012]圖2為HLS切片技術(shù)的基本原理
[0013]圖3為本發(fā)明系統(tǒng)框架圖
[0014]圖4為本發(fā)明軟件協(xié)議層
[0015]圖5為本發(fā)明的邏輯流程圖
[0016]圖6為本發(fā)明中各部分關(guān)系和可擴展性示意圖
【具體實施方式】
[0017]下面結(jié)合附圖和實施案例，對本發(fā)明的【具體實施方式】進一步詳細描述。以下實施案例用于說明本發(fā)明，但是不用于限制本發(fā)明的使用范圍。
[0018]本發(fā)明提出了一種數(shù)字電視清流獲取的技術(shù)方案，構(gòu)建了一個適應(yīng)于各種應(yīng)用環(huán)境的電信數(shù)字電視清流的獲取平臺。該方案的特點是可以適應(yīng)各種數(shù)字電視信號源和網(wǎng)絡(luò)環(huán)境，并能夠以較低的成本靈活的在各種方案之間進行切換，在提供較好的擴展性的同時使得對終端用戶的使用影響降到最低。
[0019]圖3中給出了本發(fā)明的適用場景，本發(fā)明主要適用于中國電信的數(shù)字電視業(yè)務(wù)所提供的電視節(jié)目。通常網(wǎng)絡(luò)是通過光纖入戶，連接光貓，光貓上可以直接連機頂盒或者通過交換機再連接機頂盒。通常在數(shù)字電視業(yè)務(wù)中的用戶級光纖每根帶寬為100Mbps，可以同時傳輸7個標清頻道的電視節(jié)目。若需要40個標清頻道，則需要6個光貓，40個機頂盒。
[0020]本發(fā)明用于部署的單一的互聯(lián)網(wǎng)服務(wù)供應(yīng)商的網(wǎng)絡(luò)上，在不增加網(wǎng)絡(luò)拓撲復(fù)雜性的前提下，從機頂盒前端獲取頭端清流。如圖3(a)中所示:101為系統(tǒng)所需提取的電視節(jié)目信號入口，即電信光貓;連接光貓的102為L2層交換機;連接交換機的103是電信所提供的機頂盒，若為終端用戶就可以通過HDMI線纜直接連到電視機即可。而對于數(shù)字電視前端系統(tǒng)來說，需要在光貓之后到機頂盒之前獲取電信清流。
[0021 ]本發(fā)明的第一個應(yīng)用案例是:上海電信的清流獲取方案。如圖3 (b)所示:110為光貓，經(jīng)過光貓我們的HLS切片服務(wù)器112就可以直接獲取到10個頻道以傳輸流格式傳輸?shù)碾娨暪?jié)目，若需要30個頻道，只需要申請3個光貓即可，即將另外2個光貓也連接到交換機111上。HLS可以將電視節(jié)目切片供用戶觀看直播。顯然，從光貓輸出的電視節(jié)目即為清流，如果需要對傳輸流進行其它操作，可以在112上進行操作后直接發(fā)給HLS服務(wù)器。
[0022]本發(fā)明的第二個應(yīng)用案例是:廣東電信的電視節(jié)目清流獲取方案。圖3(c)所示:201和202為光貓，連接光纖輸入，然后光貓的輸出連接到交換機的鏡像端口中，相對應(yīng)的另一側(cè)連接的203和204為Hub，也連接在交換機的鏡像端口上，機頂盒205和206連接在Hub上，服務(wù)器207連接在交換機的監(jiān)控端口上，監(jiān)控端口可以收到所有鏡像端口的數(shù)據(jù)包，因此，服務(wù)器就可以抓取到所有的數(shù)字電視節(jié)目數(shù)據(jù)包，經(jīng)過解析獲得TS數(shù)據(jù)流并轉(zhuǎn)發(fā)給HLS月艮務(wù)器，再通過web服務(wù)器發(fā)布出來，用戶就可以觀看到數(shù)字電視節(jié)目的直播。
[0023]本發(fā)明的第三個應(yīng)用案例是:武漢地鐵的清流獲取方案。圖3(d)所示:其中301為光貓，交換機304接在光貓上，同時，電信機頂盒302和服務(wù)器303也連接在電信機頂盒上，當(dāng)有多播數(shù)字電視節(jié)目清流傳過來，則直接將多播流轉(zhuǎn)發(fā)到HLS服務(wù)器或者機頂盒上，當(dāng)來自于301的多播視頻傳輸流發(fā)生中斷，那么則轉(zhuǎn)發(fā)本地傳輸流文件到HLS服務(wù)器或者是機頂盒，從而保證數(shù)字電視節(jié)目清流的連續(xù)性，提高用戶體驗的滿意度。
[0024]本發(fā)明的第四個應(yīng)用案例是:某酒店的清流獲取方案，該酒店的項目技術(shù)支持力量薄弱，并且在相當(dāng)長的一段時間內(nèi)不會改觀，因此采用的是編碼器獲取清流的方案。圖3(e)所示:其中401為光貓，402為機頂盒，輸出直接送到編碼器404，編碼器的輸出為MPEG傳輸流格式的數(shù)字電視節(jié)目數(shù)據(jù)，通過交換機402可以直接送到終端用戶的機頂盒或者是先發(fā)送給HLS服務(wù)器，然后再發(fā)布給端用戶播放。
[0025]圖4顯示了這個應(yīng)用軟件平臺的協(xié)議層，不同網(wǎng)絡(luò)環(huán)境下，不同的封裝格式，獲取清流的位置有所不同。
[0026]對應(yīng)于以上所述的第一個應(yīng)用場景，即上海電信清流的獲取方案，直接可以在網(wǎng)絡(luò)協(xié)議棧的應(yīng)用層101獲取到MPEG傳輸流數(shù)據(jù)，即為數(shù)字電視節(jié)目的清流，根據(jù)應(yīng)用需要，可以直接發(fā)送給機頂盒，也可以先發(fā)送給HLS服務(wù)器，經(jīng)過切片分段后經(jīng)web服務(wù)器發(fā)布出去，以供機頂盒進行直播服務(wù)。
[0027]對于以上所述的第二個應(yīng)用場景，廣東電信清流的獲取方案，數(shù)據(jù)解析過程如下:
[0028]I)步驟201:從網(wǎng)絡(luò)協(xié)議棧的第二層數(shù)據(jù)鏈路層抓取到MAC數(shù)據(jù)幀。
[0029]2)步驟202:對MAC協(xié)議幀進行解析，取出負載即PPPoE數(shù)據(jù)幀。
[0030]3)步驟203:再對PPPoE數(shù)據(jù)幀進行PPPoE協(xié)議解析，去除PPPoE頭部，取得其負載也就是IP數(shù)據(jù)包。
[0031]4)步驟204:接下來進行IP協(xié)議的解析，IP協(xié)議頭部的長度也是可變的，需要用總長度減去頭部長度獲得負載的起始位置，進而取得IP數(shù)據(jù)包的負載，TCP數(shù)據(jù)段或UDP數(shù)據(jù)段。
[0032]5)步驟205:對于廣東電信來說，標清數(shù)字電視節(jié)目是通過UDP協(xié)議傳輸?shù)模咔鍞?shù)字電視節(jié)目是通過TCP協(xié)議傳輸?shù)?。因此還要進行UDP協(xié)議或者TCP協(xié)議的解析，UDP協(xié)議的解析較為簡單，只需去除固定長度的UDP頭部，即可獲得最終的MPEG傳輸流數(shù)據(jù)。TCP協(xié)議的解析稍為復(fù)雜，這是因為TCP協(xié)議的頭部長度是可變的。
[0033]6)步驟206:對于高清電視節(jié)目，完成TCP協(xié)議段的解析后，獲取到負載數(shù)據(jù)后，還需要進行最后一次協(xié)議解析，即RTSP協(xié)議解析。RTSP協(xié)議實際上是將信令和數(shù)據(jù)放在同一個邏輯信道中傳輸，即都通過TCP協(xié)議所建立的連接。也就是說，MPEG傳輸流是經(jīng)過RTSP協(xié)議封裝的。其中數(shù)據(jù)的其實4個字節(jié)都是“0x24000524”，也就是說所有開始四個字節(jié)的值不為“0x24000524”的數(shù)據(jù)包都是信令包，都可以直接丟棄。
[0034]7)至此，就獲得到了完整的MPEG傳輸流數(shù)據(jù)，這時可以將數(shù)據(jù)直接發(fā)送給HLS服務(wù)器，或者發(fā)送給端用戶機頂盒使用。
[0035]對于以上所述的第三個應(yīng)用場景，武漢地鐵的電信清流獲取步驟如下:
[0036]I)首先在應(yīng)用層檢查是否能夠接收到多播MPEG傳輸流，如果能夠接收到數(shù)據(jù)流，則直接將數(shù)據(jù)流轉(zhuǎn)發(fā)給HLS服務(wù)器，或者某個多播IP地址。
[0037]2)如果未能接收到多播MPEG傳輸流，如果不能夠接收到數(shù)據(jù)流，則開始啟動本地TS文件轉(zhuǎn)發(fā)以形成清流發(fā)送給HLS服務(wù)器，或者某個多播IP地址。
[0038]3)在本地文件的轉(zhuǎn)發(fā)過程中，不斷在應(yīng)用層檢測是否有來自于網(wǎng)絡(luò)的多播流出現(xiàn)，一旦出現(xiàn)立即停止本地文件發(fā)送，開始進行多播傳輸流的轉(zhuǎn)發(fā)。
[0039]對于以上所述的第四個應(yīng)用場景，某酒店的電信清流獲取方案，是在應(yīng)用層對獲取到的原始YUV視頻信號和原始音頻信號進行編碼封裝處理，并最終輸出MPEG傳輸流格式的輸出，這種清流可以直接傳輸給HLS服務(wù)器或者機頂盒使用。
[0040]總之，與傳統(tǒng)的數(shù)字電視頭端清流獲取方法相比，本發(fā)明提供了更多的選擇，提供了更加靈活的清流獲取技術(shù);不需要額外的硬件設(shè)備支持，降低了用戶的投入負擔(dān)，同時可以應(yīng)對各種網(wǎng)絡(luò)環(huán)境狀況;此外，很明顯的一個優(yōu)勢就是，我們直接在網(wǎng)絡(luò)協(xié)議棧的第二層抓包，這樣不僅可以處理目前的傳輸流封裝格式或協(xié)議，還可以通過增加插件類的形式對其進行擴展，以支持新的封裝格式或協(xié)議。
[0041]圖5給出了該發(fā)明的邏輯流程，在圖5中，包括網(wǎng)絡(luò)協(xié)議棧501和清流獲取軟件502，，以及端用戶503。離線數(shù)據(jù)文件、HLS服務(wù)器也都在502中。清流獲取軟件從網(wǎng)絡(luò)協(xié)議棧中獲取數(shù)據(jù)，經(jīng)過處理后，將數(shù)據(jù)發(fā)送給HLS服務(wù)器，最后發(fā)布給端用戶503使用。從網(wǎng)絡(luò)協(xié)議棧獲取數(shù)據(jù)并進行處理的方法如下:
[0042]I)第一步，打開網(wǎng)絡(luò)設(shè)備，并進行相應(yīng)配置，以便進行數(shù)據(jù)的抓取。
[0043]2)第二步，檢測是否能夠獲取到數(shù)據(jù)，若能夠獲取到數(shù)據(jù)，就進行相應(yīng)的數(shù)據(jù)處理。如果在MAC層經(jīng)過PPPoE封裝，則需要進行PPPoE協(xié)議的解析。如果在傳輸層經(jīng)過RTSP協(xié)議的封裝，還要進行RTSP協(xié)議的解析，并最終獲取有效負載。
[0044]3)第三步，獲取到純凈的MPEG傳輸流后，直接將其轉(zhuǎn)發(fā)給HLS服務(wù)器。
[0045]4)第四步，HLS服務(wù)器對MPEG傳輸流進行切片和分段處理，然后通過web服務(wù)器發(fā)布出去。
[0046]5)第五步，用戶可以通過點播獲得到實時傳輸?shù)腗PEG傳輸流，即數(shù)字電視節(jié)目清流。
[0047]其中的第四步，HLS服務(wù)器對MPEG傳輸流的處理方法如下:
[0048]I)第一步，對每一個頻道啟動一個線程，首先初始化接收soket和各種配置信息
[0049]2)第二步，檢查是否有有效的MPEG傳輸流接收到
[0050]3)第三步，在接收到的MPEG傳輸流中尋找PMT和PAT信息，并重建PMT和PAT表。
[0051]4)第四步，初始化m3u8文件，包括文件命名以及文件標簽的生成。
[0052]5)第五步，在接收到的MPEG傳輸流中，尋找完整的數(shù)據(jù)包，并將其放入ts文件中。
[0053]6)第六步，查看是否到達分片時間，如果到達，就在MPEG傳輸流中尋找I幀。
[0054]7)第七步，一旦發(fā)現(xiàn)I幀，就立即將從I幀開始的數(shù)據(jù)寫入下一個ts文件中，并在I幀之前寫入PMT和PAT表，同時還需要更新m3u8文件。
[0055]8)第八步，將超時或到期到一定門限的ts文件刪除。
[0056]9)第八步，不斷重復(fù)以上的第五步到第八步。
[0057]該方法的一個特點是:它可以保證的整個前端清流獲取系統(tǒng)的服務(wù)質(zhì)量，其它的相關(guān)應(yīng)用都可以從該應(yīng)用軟件獲取清流。服務(wù)功能是質(zhì)量是通過以下措施實現(xiàn):
[0058]I)使用一個電信提供的數(shù)字電視節(jié)目服務(wù)供應(yīng)商專用的傳輸網(wǎng)絡(luò)。大多數(shù)的視頻和音頻采用的時多播的方式來提高傳輸效率，減少了骨干網(wǎng)絡(luò)擁塞的可能性。保證了網(wǎng)絡(luò)傳輸?shù)姆?wù)質(zhì)量。
[0059]2)最終保證服務(wù)的整體質(zhì)量被配置到生產(chǎn)網(wǎng)絡(luò)環(huán)境，實現(xiàn)了服務(wù)質(zhì)量整體的管理和調(diào)度機制。“端到端”的服務(wù)機制，質(zhì)量包括錯誤控制(如前向糾錯)，的客戶端狀態(tài)云的實時監(jiān)控和服務(wù)質(zhì)量，及時調(diào)整服務(wù)方式，服務(wù)器使用流緩沖區(qū)可以解決傳輸不穩(wěn)定帶來的性能降級。
[0060]3)在上述兩種方式傳輸?shù)乃械那辶鲾?shù)據(jù)，都可以通過多個技術(shù)策略進行實現(xiàn)，這使得他們的服務(wù)質(zhì)量有保證。這些客戶端代碼和服務(wù)器端的計算結(jié)果，根據(jù)用相同的參考時鐘的時間軸進行同步協(xié)同工作，以形成完整的網(wǎng)絡(luò)視頻的應(yīng)用，所以服務(wù)功能的網(wǎng)絡(luò)視頻應(yīng)用的質(zhì)量來實現(xiàn)。
[0061]該方法所使用的集中技術(shù)策略以及他們之間的關(guān)系，如圖6所示。I)直接轉(zhuǎn)發(fā)服務(wù)和本地文件發(fā)送服務(wù):這兩種技術(shù)策略通常需要配合工作，當(dāng)有多播數(shù)據(jù)流并且該多播數(shù)據(jù)流未經(jīng)特殊的協(xié)議封裝的前提下，可以直接對數(shù)據(jù)流進行轉(zhuǎn)發(fā);當(dāng)網(wǎng)絡(luò)發(fā)生異常，無多播數(shù)據(jù)流或者無法使用多播數(shù)據(jù)流時，可以發(fā)送本地文件，這樣可以保證清流輸出的連續(xù)性，保證了用戶的數(shù)字電視節(jié)目的可用性，提高用戶的滿意度。2)數(shù)據(jù)鏈路層的抓包服務(wù)和直接轉(zhuǎn)發(fā)服務(wù):當(dāng)網(wǎng)絡(luò)上有多播數(shù)據(jù)流可用，并且多播數(shù)據(jù)流沒有經(jīng)過復(fù)雜協(xié)議的封裝的前提下，可以直接通過轉(zhuǎn)發(fā)服務(wù)獲得頭端清流;但是當(dāng)多播數(shù)據(jù)流是經(jīng)過復(fù)雜的網(wǎng)絡(luò)協(xié)議封裝過，那么就必須對這些網(wǎng)絡(luò)協(xié)議解封裝，就只能通過數(shù)據(jù)鏈路成的抓包服務(wù)來獲取頭端清流。3)編碼器方案和其它三種服務(wù)的關(guān)系:當(dāng)網(wǎng)絡(luò)上傳輸?shù)亩嗖?shù)據(jù)流或TCP數(shù)據(jù)流可以識別，并且沒有緊急情況的時候，完全可以不采用編碼器方案來解決，畢竟采用了編碼器方案就意味著成本的增加。但是，編碼器方案可以當(dāng)作應(yīng)急處理手段，當(dāng)緊急情況發(fā)生時，或者當(dāng)其他的服務(wù)不可使用時，就可以采用這種方式來對數(shù)字電視節(jié)目編碼，并輸出頭端清流。3)四種清流獲取技術(shù)和HLS服務(wù)器的關(guān)系:以上所述的四種清流獲取策略都是為了向端用戶提供數(shù)字電視直播清流，傳統(tǒng)的直播方案都是通過流媒體方案來提供服務(wù)的，r而HLS服務(wù)器則是一種非流媒體服務(wù)器的電視節(jié)目直播解決方案。HLS服務(wù)器作為清流獲取技術(shù)的重要配合組件，可以完美實現(xiàn)從頭端清流到數(shù)字電視節(jié)目的直播。
[0062]上述四種清流獲取技術(shù)互為補充，各有所長，最終使得客戶的服務(wù)質(zhì)量有保證。作為一個可執(zhí)行的平臺，與不同的應(yīng)用集成和各種資源配合，其可靠性是有保障在以下幾個方面:
[0063]I)平臺所部署的環(huán)境都為企業(yè)級Linux服務(wù)器，具有較高的可靠性和穩(wěn)定性。
[0064]2)平臺所依賴的庫均為業(yè)內(nèi)知名庫，其穩(wěn)定性和可靠性具有普遍的認可度。
[0065]3)平臺所采用的技術(shù)都是在其它場合使用較為可靠的技術(shù)方案。
[0066]4)平臺具有在不同網(wǎng)絡(luò)環(huán)境的適應(yīng)性:基于數(shù)據(jù)鏈路層抓包的服務(wù)也可以替代直接轉(zhuǎn)發(fā)服務(wù)來進行工作，在網(wǎng)絡(luò)多播流不可用時，還可以通過發(fā)送本地文件的方式來保證清流的輸出，這就使得整個系統(tǒng)維持較高的穩(wěn)定性和可靠性。
[0067]該平臺的可擴展性部署的便利顯示如下:它提供的服務(wù)的集成接口便于新功能的添加，而不會影響其他人；只有內(nèi)核平臺上的客戶端預(yù)裝，易于部署;應(yīng)用程序下載到緩沖區(qū)每次執(zhí)行，以保證其及時更新;部署在云計算的形式可以應(yīng)付平臺的擴充在服務(wù)器;該平臺在時間收集客戶機和服務(wù)器的信息，以確保負載平衡，從而有利于用戶的管理。
【主權(quán)項】
1.一種用于現(xiàn)有數(shù)字電視行業(yè)的清流獲取解決方案，以構(gòu)建一個綜合、健壯的清流獲取平臺，其特征在于: 1)該方案充分利用了現(xiàn)有的網(wǎng)絡(luò)數(shù)據(jù)獲取技術(shù)和電信運營商所提供的數(shù)字電視接入設(shè)備，同時具有提供靈活和健壯的數(shù)字電視服務(wù)的優(yōu)點； 2)針對現(xiàn)有電信數(shù)字電視節(jié)目的傳輸格式和協(xié)議進行處理，可以很靈活方便的對傳輸流進行其它操作，為用戶提供了靈活性和擴展性； 3)該方法充分考慮到各種不同的網(wǎng)絡(luò)環(huán)境和用戶的實際需求，利用電信數(shù)字電視節(jié)目進行直播給出了高效的解決方案； 4)可以適應(yīng)各種數(shù)字電視信號源和網(wǎng)絡(luò)環(huán)境，并能夠以較低的成本靈活的在各種方案之間進行切換，在提供較好的擴展性的同時使得對終端用戶的使用影響降到最低；2.根據(jù)權(quán)利要求1所述的方案，其特征在于:充分利用現(xiàn)有網(wǎng)絡(luò)數(shù)據(jù)獲取技術(shù)和電信運營商所提供的數(shù)字電視接入設(shè)備，網(wǎng)絡(luò)數(shù)據(jù)獲取技術(shù)包括正常的通過網(wǎng)絡(luò)協(xié)議棧在傳輸層獲取應(yīng)用數(shù)據(jù)的技術(shù)，以及在數(shù)據(jù)鏈路層獲取MAC幀數(shù)據(jù)的技術(shù)。電信運營商所提供的數(shù)字電視接入設(shè)備包括光貓、機頂盒等接入設(shè)備。3.根據(jù)權(quán)利要求1所述的靈活的整合各種數(shù)字電視數(shù)據(jù)資源和應(yīng)用，其中的數(shù)字電視資源包括直播數(shù)據(jù)資源，以及一些訂制的非直播數(shù)據(jù)資源，具體可以分為如下三種: 1)實時直播的通過UDP多播傳輸?shù)臉饲咫娨暪?jié)目資源； 2)實時直播的通過TCP單播傳輸?shù)母咔咫娨暪?jié)目資源； 3)離線傳輸流文件格式的節(jié)目資源；4.根據(jù)權(quán)利要求1所述的各種數(shù)字電視信號源和網(wǎng)絡(luò)環(huán)境，其中所述的信號源包括: 1)以PPPoE協(xié)議在MAC層對數(shù)據(jù)幀進行封裝后的數(shù)據(jù)幀； 2)以UDP協(xié)議傳輸?shù)臄?shù)據(jù)段有效載荷是經(jīng)過RTP協(xié)議封裝的； 3)通過TCP協(xié)議傳輸?shù)臄?shù)據(jù)段的有效載荷是經(jīng)過RTSP協(xié)議封裝的； 4)通過TCP協(xié)議傳輸?shù)臄?shù)據(jù)段的有效載荷是TS流數(shù)據(jù)和信令混合傳輸?shù)模?5)以TS傳輸流的形式直接存儲的多媒體文件數(shù)據(jù)；5.根據(jù)權(quán)利要求1所述的技術(shù)方案包括以下幾種: 1)在數(shù)字電視節(jié)目未經(jīng)電信進行額外的封裝協(xié)議進行處理的條件下，數(shù)字電視節(jié)目是以MPEG傳輸流的方式在網(wǎng)絡(luò)上傳輸，在這種網(wǎng)絡(luò)環(huán)境下，直接將電信清流從交換機轉(zhuǎn)發(fā)到用戶的媒體服務(wù)器上； 2)當(dāng)電信的數(shù)字電視節(jié)目的MPEG傳輸流是經(jīng)過其它協(xié)議進行封裝后，再次使用網(wǎng)絡(luò)協(xié)議進行傳輸?shù)?，無法直接使用網(wǎng)絡(luò)協(xié)議棧對傳輸流進行解析得到節(jié)目數(shù)據(jù)，可以在以太網(wǎng)層進行抓包，然后根據(jù)不同的網(wǎng)絡(luò)協(xié)議(UDP或TCP)逐層解析，并最終獲得電視節(jié)目清流； 3)對于以上兩種網(wǎng)絡(luò)環(huán)境下，當(dāng)研發(fā)能力不足或追求更簡單的解決方案，可以采用硬件編碼器方案來進行節(jié)目清流的提取； 4)當(dāng)網(wǎng)絡(luò)發(fā)生異常，或者其它原因造成無法獲取節(jié)目流時，采用轉(zhuǎn)發(fā)本地文件來生成清流的方式，避免了因數(shù)字電視節(jié)目的缺失而導(dǎo)致節(jié)目清流的不可用； 5)獲得清流之后，為了實現(xiàn)直播可以采用基于HLS技術(shù)的直播技術(shù)方案。6.根據(jù)權(quán)利要求1所述的網(wǎng)絡(luò)環(huán)境包括多播流正常傳輸，以及當(dāng)網(wǎng)絡(luò)不可用而導(dǎo)致的無多播流可用的環(huán)境。7.根據(jù)權(quán)利要求3所述的節(jié)目資源，其特征在于: 1)通過UDP傳輸?shù)亩嗖ス?jié)目流封裝包括PPPoE協(xié)議和PPP協(xié)議； 2)通過TCP傳輸?shù)母咔骞?jié)目流封裝包括PPPoE協(xié)議、PPP協(xié)議和RTSP協(xié)議，8.根據(jù)權(quán)利要求5所述的第一種技術(shù)的方法，其特征在于:提供了較低的運行成本以及計算開銷。9.根據(jù)權(quán)利要求5所述的第二種技術(shù)，即采用數(shù)據(jù)鏈路層抓取MAC幀來獲取標清數(shù)字電視節(jié)目清流的具體步驟如下: 1)將網(wǎng)卡設(shè)置為混雜模式，抓取符合條件的數(shù)據(jù)幀，即以太網(wǎng)幀頭部的幀類型字段值符合下一層數(shù)據(jù)封裝類型； 2)將獲取到的以太網(wǎng)幀頭部去除，獲得有效載荷部分，S卩PPPoE幀； 3)根據(jù)PPPoE協(xié)議的規(guī)定，去除PPPoE頭部，獲取其有效載荷部分； 4)將上一步所獲取到的數(shù)據(jù)幀，去除固定長度的PPP協(xié)議頭部； 5)對數(shù)據(jù)包進行IP協(xié)議解析，根據(jù)IP協(xié)議包頭部的尺寸和有效載荷偏移來判斷數(shù)據(jù)包的有效性，若有效，則記錄目的多播IP地址，并去除掉IP包頭部； 6)對數(shù)據(jù)包進行UDP協(xié)議解析，根據(jù)目的IP地址和目的端口號判斷是否是需要的數(shù)據(jù)段，若是，則去除UDP頭部； 7)將所獲得的傳輸流數(shù)據(jù)轉(zhuǎn)發(fā)到HLS服務(wù)器處理以提供直播服務(wù)。10.根據(jù)權(quán)利要求5所述的第二種技術(shù)，即采用數(shù)據(jù)鏈路層抓取MAC幀來獲取高清數(shù)字電視節(jié)目清流的具體步驟如下: 1)將網(wǎng)卡設(shè)置為混雜模式，抓取符合條件的數(shù)據(jù)幀，即以太網(wǎng)幀頭部的幀類型字段值符合下一層數(shù)據(jù)封裝類型； 2)將獲取到的以太網(wǎng)幀頭部去除，獲得有效載荷部分，S卩PPPoE幀； 3)根據(jù)PPPoE協(xié)議的規(guī)定，去除PPPoE頭部，獲取其有效載荷部分； 4)將上一步所獲取到的數(shù)據(jù)幀，去除固定長度的PPP協(xié)議頭部； 5)對數(shù)據(jù)包進行IP協(xié)議解析，根據(jù)IP協(xié)議包頭部的尺寸和有效載荷偏移來判斷數(shù)據(jù)包的有效性，若有效，則記錄目的單播IP地址，并去除掉IP包頭部； 6)對數(shù)據(jù)包進行TCP協(xié)議解析，根據(jù)目的IP地址和目的端口號判斷是否是需要的數(shù)據(jù)段，若是，則去除掉TCP頭部，獲得TCP的有效載荷部分； 7)判斷TCP協(xié)議段的有效載荷部分第I個字節(jié)是否為0x24，若是0x24則將頭部4個字節(jié)去除; 8)將最終所獲得的傳輸流數(shù)據(jù)轉(zhuǎn)發(fā)到HLS服務(wù)器處理以提供直播服務(wù)。11.根據(jù)權(quán)利要求5所述的第三種技術(shù)，其特征在于:以較為簡便的方式實現(xiàn)了電信清流的生成，可以在一定程度上規(guī)避技術(shù)風(fēng)險，加速部署進度。12.根據(jù)權(quán)利要求5所述的第四種技術(shù)，具體步驟如下: 1)當(dāng)能夠從網(wǎng)絡(luò)獲取到電信節(jié)目多播流時，直接進行多播數(shù)據(jù)流的轉(zhuǎn)發(fā)； 2)當(dāng)網(wǎng)絡(luò)出現(xiàn)異常或多播節(jié)目流不可用時，打開本地傳輸流文件，并按照時間戳進行發(fā)送； 3)當(dāng)本地文件發(fā)送結(jié)束后，再次重復(fù)進行發(fā)送； 4)在文件的發(fā)送過程中，不斷檢測網(wǎng)絡(luò)多播流的狀態(tài)，一旦發(fā)現(xiàn)可以接收到多播流，則立即停止本地文件的發(fā)送，繼續(xù)進行多播流的轉(zhuǎn)發(fā)；13.根據(jù)權(quán)利要求9和10所述的方法，其特征在于:采用了數(shù)據(jù)鏈路層數(shù)據(jù)幀抓取的方式獲取原始的頭端信號。是通過將運行抓取程序的服務(wù)器連接到交換機的監(jiān)控端口來具體實現(xiàn)的。14.根據(jù)權(quán)利12所述的方法，其特征是:不僅可以實現(xiàn)無間斷的頭端清流獲取，還可以實現(xiàn)節(jié)目的插播。15.根據(jù)權(quán)利15所述的節(jié)目插播實現(xiàn)方式如下: 1)可以在多個多播流之間進行切換，實現(xiàn)插播； 2)可以在多播流和多個本地傳輸流文件之間進行插播； 3)可以在多個本地傳輸文件之間進行插播； 4)可以在多播流和本地傳輸流文件之間進行周期性的插播。16.根據(jù)權(quán)利要求5所述的解決方案，其特征在于:針對不同的傳輸流封裝格式和封裝協(xié)議，可以很容易進行擴展，從而支持其它的封裝格式和封裝協(xié)議。
【文檔編號】H04N21/443GK105872779SQ201610242969
【公開日】2016年8月17日
【申請日】2016年4月20日
【發(fā)明人】葉德建
【申請人】上海清鶴科技股份有限公司