[發(fā)明專利]一種接收處理數(shù)據(jù)的方法、裝置及視頻服務(wù)器

有效

• 申請?zhí)枺?/td>: 201210160863.6
• 申請日: 2012-05-23
• 公開（公告）號: CN102708207A
• 公開（公告）日: 2012-10-03
• 發(fā)明（設(shè)計）人: 朱江
• 申請（專利權(quán)）人: 深圳市龍視傳媒有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30;H04N21/23;H04N21/231;H04N21/238
• 代理公司: 暫無信息
• 代理人: 暫無信息

技術(shù)領(lǐng)域

本發(fā)明涉及數(shù)字電視領(lǐng)域，具體涉及一種接收處理數(shù)據(jù)的方法、裝置及視頻服務(wù)器。

背景技術(shù)

數(shù)字電視是一個從節(jié)目采集、節(jié)目制作、節(jié)目傳輸直到用戶端都以數(shù)字方式處理信號的端到端的系統(tǒng)。基于DVB（Digital?Video?Broadcasting，數(shù)字視頻廣播）技術(shù)標準的廣播式和交互式數(shù)字電視．采用先進用戶管理技術(shù)能將節(jié)目內(nèi)容的質(zhì)量和數(shù)量做得盡善盡美并為用戶帶來更多的節(jié)目選擇和更好的節(jié)目質(zhì)量效果，與模擬電視相比，數(shù)字電視具有圖像質(zhì)量高、節(jié)目容量大和伴音效果好的特點。

由于節(jié)目容量大，通常很少把媒體文件存放于VS（Video?Server，視頻服務(wù)器）上面，而是一般存放于CDN（Content?Distribute?Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）各節(jié)點中，用于提高網(wǎng)絡(luò)內(nèi)容分發(fā)質(zhì)量、降低骨干網(wǎng)絡(luò)傳輸負載以及降低節(jié)目源的訪問負載。

在目前的NGOD（Next?Generation?On?Demand，下一代視頻點播?）標準中，CDN是以chunked方式發(fā)送媒體文件數(shù)據(jù)到VS，VS接收解析chunked數(shù)據(jù)后再推流。

chunked編碼是HTTP（HyperText?Transport?Protocol，超文本傳送）/1.1?RFC里定義的一種編碼方式。通常情況下，HTTP消息頭中的Transfer-Encoding域值為chunked,表明采用chunked編碼方式來進行報文體的傳輸。消息體存放chunked編碼，Chunked編碼使用若干個Chunk串連而成，由一個標明長度為0的Chunk標示結(jié)束。每個Chunk分為頭部和正文兩部分，頭部內(nèi)容指定下一段正文的字符總數(shù)（十六進制的數(shù)字）和數(shù)量單位（一般不寫），正文部分指定長度的實際內(nèi)容，兩部分之間用回車換行(CRLF)隔開。在最后一個長度為0的Chunk中的內(nèi)容是稱為footer的內(nèi)容，是一些附加的Header信息（通常可以直接忽略）。

現(xiàn)有技術(shù)中，VS為每個點播會話申請兩塊內(nèi)存，假設(shè)為A和B。對于同一塊內(nèi)存來說，同一時刻只能進行一種操作，讀或?qū)憽S把接收到的chunked數(shù)據(jù)解析后寫入A內(nèi)存，當A內(nèi)存寫滿后，才可以對A進行讀操作。在對寫滿數(shù)據(jù)的A內(nèi)存進行讀操作時，VS把接收到的chunked數(shù)據(jù)解析后寫入B內(nèi)存。

上述方式對內(nèi)存的利用率只有50%左右，而且容易造成chunked數(shù)據(jù)的處理延遲，因為只有其中一塊內(nèi)存寫滿了或所有數(shù)據(jù)接收解析完畢，另一塊內(nèi)存才能讀出來進行處理（比如推流），導(dǎo)致VS可能處在等待的狀態(tài)。此外，目前接收并解析chunked數(shù)據(jù)是不限速的。從CDN獲取到chunked數(shù)據(jù)，邊接收邊解析，解析完畢后再讀出處理，從一定程度上來說，VS處理chunked數(shù)據(jù)的速率取決于CDN傳送數(shù)據(jù)的速率，在網(wǎng)絡(luò)不穩(wěn)定的情況下，VS推流將會很不穩(wěn)定，影響用戶體驗。

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

有鑒于此，本發(fā)明的目的在于提供一種接收處理數(shù)據(jù)的方法，該方法自定義一種內(nèi)存文件的方式在一塊內(nèi)存上既讀又寫，提高了內(nèi)存利用率，平衡了讀寫速度，使得數(shù)據(jù)處理比較平穩(wěn)，從而使推流平穩(wěn)。

本發(fā)明的目的在于提供一種接收處理數(shù)據(jù)的裝置，該裝置自定義一種內(nèi)存文件的方式在一塊內(nèi)存上既讀又寫，提高了內(nèi)存利用率，平衡了讀寫速度，使得數(shù)據(jù)處理比較平穩(wěn)，從而使推流平穩(wěn)。

本發(fā)明的目的還在于提供一種視頻服務(wù)器，該視頻服務(wù)器自定義一種內(nèi)存文件的方式在一塊內(nèi)存上既讀又寫，提高了內(nèi)存利用率，平衡了讀寫速度，使得數(shù)據(jù)處理比較平穩(wěn)，從而使推流平穩(wěn)。

為達到上述目的，本發(fā)明的技術(shù)方案具體是這樣實現(xiàn)的，提供一種接收處理數(shù)據(jù)的方法，包括：

A、預(yù)先定義內(nèi)存文件模型，所述內(nèi)存文件模型封裝有讀指針、讀查詢方法、寫指針、寫查詢方法和內(nèi)存文件長度；

B、根據(jù)所述預(yù)先義的內(nèi)存文件模型，在內(nèi)存空間上為每個點播會話創(chuàng)建一個內(nèi)存文件；

C、調(diào)用所述內(nèi)存文件的寫查詢方法獲取所述內(nèi)存文件當前的可寫數(shù)據(jù)長度，若所述可寫數(shù)據(jù)長度大于零，則轉(zhuǎn)入步驟D，否則，則轉(zhuǎn)入步驟G；

D、根據(jù)點播請求向內(nèi)容分發(fā)網(wǎng)絡(luò)發(fā)送數(shù)據(jù)請求，請求發(fā)送數(shù)據(jù)長度不大于所述可寫數(shù)據(jù)長度的數(shù)據(jù)；

E、接收所述內(nèi)容分發(fā)網(wǎng)絡(luò)返回的數(shù)據(jù)并對所述數(shù)據(jù)進行解析；

F、將解析后的數(shù)據(jù)寫入到所述內(nèi)存文件，并更新寫指針指向的位置；

G、在超過預(yù)置的等待時間后再轉(zhuǎn)到步驟C。

進一步，所述步驟B之后還包括：