一種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)。該系統(tǒng)主要包括服務(wù)質(zhì)量監(jiān)測(cè)模塊、服務(wù)質(zhì)量分析模塊及質(zhì)量監(jiān)測(cè)控制模塊。服務(wù)質(zhì)量監(jiān)測(cè)模塊負(fù)責(zé)無差別地抓取所有經(jīng)過網(wǎng)絡(luò)端口的數(shù)據(jù)包，進(jìn)行丟包、端到端時(shí)延的計(jì)算和流媒體協(xié)議解析，進(jìn)行服務(wù)服務(wù)質(zhì)量監(jiān)測(cè)實(shí)現(xiàn)按節(jié)目流的計(jì)算和監(jiān)測(cè)。服務(wù)質(zhì)量分析模塊收集從其他模塊傳送過來的參數(shù)進(jìn)行分析并定時(shí)上報(bào)業(yè)務(wù)商的服務(wù)器。質(zhì)量監(jiān)測(cè)控制模塊負(fù)責(zé)接收來自控制服務(wù)器的信令以調(diào)整監(jiān)測(cè)策略，如改變上報(bào)周期、統(tǒng)計(jì)周期、ftp服務(wù)器地址等等。該系統(tǒng)具有實(shí)時(shí)性，對(duì)CPU和內(nèi)存的消耗少，獲得的服務(wù)質(zhì)量參數(shù)更加接近于播放的實(shí)際效果。
【專利說明】-種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及視頻點(diǎn)播【技術(shù)領(lǐng)域】，特別涉及一種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè) 系統(tǒng)。

【背景技術(shù)】
[0002] 隨著中國數(shù)字電視產(chǎn)業(yè)的飛速發(fā)展，有線數(shù)字電視用戶繼續(xù)保持大幅增長，雙向 改造及網(wǎng)絡(luò)整合正在快速推進(jìn)，基于有線網(wǎng)絡(luò)的增值服務(wù)也有了較大的應(yīng)用推廣；電信運(yùn) 營商加大交互式網(wǎng)絡(luò)電視（International Protocol Television, IPTV)用戶發(fā)展力度，帶 寬提升也促進(jìn)了用戶數(shù)量的增長。在廣電、電信等運(yùn)營商的大力推動(dòng)下，數(shù)字電視、交互式 網(wǎng)絡(luò)電視等業(yè)務(wù)的覆蓋范圍也越來越廣，這也對(duì)網(wǎng)絡(luò)的服務(wù)質(zhì)量提出了更高的要求。
[0003] 目前對(duì)于普通網(wǎng)絡(luò)應(yīng)用所使用的諸如丟包、時(shí)延等離散的服務(wù)質(zhì)量（QoS)評(píng)估難 以完整刻畫視頻業(yè)務(wù)質(zhì)量是否滿足需要。一方面，對(duì)于網(wǎng)絡(luò)服務(wù)質(zhì)量監(jiān)測(cè)往往采用網(wǎng)絡(luò)數(shù) 據(jù)包的抓取與分析，而現(xiàn)有的網(wǎng)絡(luò)服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)是以解碼器輸出的數(shù)據(jù)作為網(wǎng)絡(luò)數(shù)據(jù) 進(jìn)行分析，如果解碼器包含流媒體數(shù)據(jù)的糾錯(cuò)功能，就會(huì)使得評(píng)估不準(zhǔn)確。另一方面，相比 于客觀的服務(wù)質(zhì)量（QoS)參數(shù)，用戶體驗(yàn)質(zhì)量（QoE)能夠從用戶的角度有效地反應(yīng)視頻質(zhì) 量的表現(xiàn)，從而為服務(wù)商提供可靠的監(jiān)測(cè)數(shù)據(jù)。QoE是基于用戶的體驗(yàn)來進(jìn)行衡量的，主要 采用主觀評(píng)測(cè)方法，即利用觀看人員對(duì)圖像質(zhì)量進(jìn)行主觀計(jì)分，然而由于主觀評(píng)測(cè)需要有 大量人員參與且實(shí)時(shí)反饋性較差，所以近年來逐步被實(shí)時(shí)性能較好的無參考客觀評(píng)測(cè)方式 所替代?？陀^評(píng)測(cè)是一種將監(jiān)測(cè)質(zhì)量的軟探針集成到接收端測(cè)試設(shè)備中，收集相關(guān)參數(shù)進(jìn) 行分析的單端評(píng)測(cè)方法，但是這種方式一般需要復(fù)雜的計(jì)算，很難集成到智能電視這種弱 終端。同時(shí)機(jī)頂盒或者智能電視作為視頻業(yè)務(wù)的載體，內(nèi)存和CPU的性能遠(yuǎn)遠(yuǎn)不及PC，導(dǎo)致 現(xiàn)有的PC抓包軟件無法直接在機(jī)頂盒上運(yùn)行。


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

[0004] 為了克服上述現(xiàn)有技述的不足，本發(fā)明的目的在于提供一種可在智能電視用戶的 終端接收設(shè)備上評(píng)測(cè)用戶體驗(yàn)質(zhì)量的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)。該系統(tǒng)具有實(shí)時(shí)性，對(duì)CPU和內(nèi) 存的消耗少，獲得的服務(wù)質(zhì)量參數(shù)更加接近于播放的實(shí)際效果。
[0005] 本發(fā)明中，作為流媒體業(yè)務(wù)中間件的可選插件之一，服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)通過實(shí)時(shí) 監(jiān)測(cè)設(shè)備上的解碼緩存的狀態(tài)以及緩存中的媒體丟失率作為參數(shù)，并基于統(tǒng)計(jì)和實(shí)驗(yàn)數(shù)據(jù) 建立收集的參數(shù)和用戶體驗(yàn)質(zhì)量的函數(shù)關(guān)系，最終給出推算公式來量化當(dāng)前流媒體視頻的 用戶體驗(yàn)質(zhì)量等級(jí)（平均意見得分，Mean Opinion Sc〇re，M0S值），為服務(wù)器進(jìn)行服務(wù)質(zhì)量 的改進(jìn)提供了參考。本發(fā)明針對(duì)將來數(shù)字電視業(yè)務(wù)所要面臨的復(fù)雜網(wǎng)絡(luò)環(huán)境提供了一種可 行的實(shí)時(shí)監(jiān)測(cè)客戶端視頻質(zhì)量的系統(tǒng)。通過在流媒體中間件中嵌入服務(wù)質(zhì)量監(jiān)測(cè)模塊，封 裝了質(zhì)量監(jiān)控的調(diào)用接口，方便開發(fā)人員在開發(fā)播放程序時(shí)使用質(zhì)量監(jiān)測(cè)模塊。同時(shí)也屏 蔽了機(jī)頂盒硬件的差異性，方便移植。
[0006] 本發(fā)明提供的一種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，主要包括服務(wù)質(zhì)量監(jiān) 測(cè)模塊、服務(wù)質(zhì)量分析模塊及質(zhì)量監(jiān)測(cè)控制模塊。
[0007] 本發(fā)明的技術(shù)方案具體介紹如下。
[0008] 一、模塊組成與功能劃分
[0009] 1、服務(wù)質(zhì)量監(jiān)測(cè)模塊
[0010] 服務(wù)質(zhì)量監(jiān)測(cè)模塊主要負(fù)責(zé)監(jiān)聽網(wǎng)口，無差別地抓取所有經(jīng)過網(wǎng)口的數(shù)據(jù)包以進(jìn) 行服務(wù)質(zhì)量信息的收集；其通過對(duì)抓取的包按照控制協(xié)議進(jìn)行歸類，分別統(tǒng)計(jì)組播、點(diǎn)播不 同點(diǎn)播類型及播放、暫停、快進(jìn)及快退不同播放狀態(tài)下流媒體數(shù)據(jù)包的傳輸情況。具體如 下：
[0011] (1)首先將網(wǎng)卡設(shè)置為混雜模式，然后根據(jù)IP地址在抓取到的數(shù)據(jù)包中篩選出和 本機(jī)相關(guān)的包進(jìn)行分析。
[0012] (2)流媒體協(xié)議的解析。對(duì)抓取的包按照控制協(xié)議進(jìn)行歸類，如圖1所示。其 中Internet組管理協(xié)議（Internet Group Management Protocol)包用來傳輸組播命 令；傳輸控制協(xié)議（Transmission Control Protocol, TCP)包根據(jù)不同的控制協(xié)議又分 為超文本傳送協(xié)議（Hypertext Transport Protocol, HTTP)和實(shí)時(shí)流傳輸協(xié)議（(Real Time Streaming Protocol, RTSP)包，超文本傳送協(xié)議用來傳輸認(rèn)證信息和網(wǎng)頁請(qǐng)求，實(shí) 時(shí)流傳輸協(xié)議包用來傳輸點(diǎn)播命令；用戶數(shù)據(jù)報(bào)協(xié)議（UDP)包中只對(duì)使用實(shí)時(shí)傳輸協(xié)議 (Real-time Transport Protocol, RTP)協(xié)議的流媒體數(shù)據(jù)包進(jìn)行分析。即如果是實(shí)時(shí)傳 輸協(xié)議/用戶數(shù)據(jù)報(bào)協(xié)議（RTP/UDP)的流則進(jìn)行服務(wù)質(zhì)量參數(shù)統(tǒng)計(jì)，如果是實(shí)時(shí)流傳輸協(xié) 議/傳輸控制協(xié)議（RTSP/TCP)則進(jìn)行節(jié)目流的識(shí)別。然后將按流識(shí)別的服務(wù)質(zhì)量信息打 上時(shí)間戳交給服務(wù)質(zhì)量分析模塊處理。
[0013] (3)丟包計(jì)算。通過實(shí)時(shí)傳輸協(xié)議（RTP)包的序列號(hào)來判斷單位時(shí)間內(nèi)流媒體數(shù) 據(jù)包的連續(xù)性并定量計(jì)算出當(dāng)前網(wǎng)絡(luò)環(huán)境下數(shù)據(jù)包的丟失率。每隔一定周期，以5秒為例， 服務(wù)質(zhì)量監(jiān)測(cè)模塊分別統(tǒng)計(jì)組播、點(diǎn)播不同點(diǎn)播類型及播放、暫停、快進(jìn)及快退等不同播放 狀態(tài)下流媒體數(shù)據(jù)包的傳輸情況，轉(zhuǎn)發(fā)給服務(wù)質(zhì)量分析模塊。只有在點(diǎn)播狀態(tài)下，發(fā)送該 周期統(tǒng)計(jì)數(shù)據(jù)，包括周期開始和結(jié)束時(shí)間、收到的數(shù)據(jù)包數(shù)、丟包數(shù)、數(shù)據(jù)量等；如果處于暫 停、快進(jìn)、快退狀態(tài)，則發(fā)送一個(gè)填充包。如果一個(gè)統(tǒng)計(jì)周期內(nèi)既有正常播放也有暫停、快進(jìn) 或快退操作，則舍棄該周期內(nèi)的統(tǒng)計(jì)數(shù)據(jù)，只發(fā)送一個(gè)填充包。
[0014] (4)時(shí)延統(tǒng)計(jì)。對(duì)每一路視頻流，記錄其類型（組播或點(diǎn)播）及請(qǐng)求響應(yīng)時(shí)間 (RRT)。組播請(qǐng)求響應(yīng)時(shí)間從發(fā)送Internet組管理協(xié)議（IGMP)開始，到收到第一個(gè)視頻包 結(jié)束。點(diǎn)播請(qǐng)求響應(yīng)時(shí)間從發(fā)實(shí)時(shí)流傳輸協(xié)議（RTP)請(qǐng)求開始，到收到第一個(gè)視頻包結(jié)束。 對(duì)于時(shí)移電視情況則不進(jìn)行統(tǒng)計(jì)。端到端的時(shí)延則是通過編碼時(shí)間戳和相鄰數(shù)據(jù)包的到達(dá) 時(shí)間來計(jì)算。
[0015] (5)統(tǒng)計(jì)HTTP請(qǐng)求次數(shù)、HTTP請(qǐng)求失敗次數(shù)、認(rèn)證次數(shù)、認(rèn)證失敗次數(shù)。
[0016] 2、服務(wù)質(zhì)量分析模塊
[0017] 服務(wù)質(zhì)量分析模塊收集和分析服務(wù)質(zhì)量監(jiān)測(cè)模塊傳送的服務(wù)質(zhì)量（QoS)參數(shù)，對(duì) 播放終端緩沖區(qū)的統(tǒng)計(jì)信息作出基于用戶體驗(yàn)質(zhì)量（QoE)的評(píng)測(cè)。再將整理后的用戶體驗(yàn) 質(zhì)量（QoE)和服務(wù)質(zhì)量（QoS)信息寫入日志文件，并上報(bào)服務(wù)器。具體介紹如下：
[0018] (1)服務(wù)質(zhì)量（Q0S)參數(shù)的統(tǒng)計(jì)與分析。依賴于網(wǎng)絡(luò)參數(shù)偵測(cè)模塊提供的丟包和 時(shí)延信息來計(jì)算媒體傳輸指標(biāo)（Media Deliver Index，MDI)。媒體傳輸指標(biāo)對(duì)視頻流的 傳輸質(zhì)量標(biāo)識(shí)為延遲因素 （Delay Factor，DF)和媒體丟失速率（Media Loss Rate，MLR)。 延遲因素表明被測(cè)視頻流的延遲和抖動(dòng)情況，媒體丟失速率表明被測(cè)視頻流的傳輸丟包速 率。另外為了真實(shí)體現(xiàn)不同片源碼率下丟包與時(shí)延對(duì)于視頻質(zhì)量的損傷，服務(wù)質(zhì)量參數(shù)還 對(duì)單位時(shí)間內(nèi)網(wǎng)絡(luò)實(shí)時(shí)速率與編碼速率的比值進(jìn)行統(tǒng)計(jì)和記錄。
[0019] (2)用戶體驗(yàn)質(zhì)量（QoE)的評(píng)測(cè)。通過解碼緩沖區(qū)內(nèi)的媒體丟失率和緩沖區(qū)下溢 時(shí)長在整個(gè)統(tǒng)計(jì)周期內(nèi)的占比兩項(xiàng)信息獲得，最后擬合為平均意見得分（MOS)。
[0020] ①基于緩沖區(qū)獲取服務(wù)質(zhì)量信息取代基于網(wǎng)絡(luò)端口的信息
[0021] 近年來隨著智能電視及機(jī)頂盒等流媒體終端設(shè)備處理能力的上升，用戶端在對(duì)接 收到的媒體包進(jìn)行解碼播放前會(huì)進(jìn)行一些損傷修復(fù)的處理。如機(jī)頂盒會(huì)提供一定大小的解 碼緩沖區(qū)用于緩沖當(dāng)前的視頻流，緩沖的存在可以吸收掉一部分因網(wǎng)絡(luò)抖動(dòng)而造成的視頻 質(zhì)量損傷。有些終端設(shè)備除了抑制抖動(dòng)的功能以外，還可以對(duì)一定程度的網(wǎng)絡(luò)丟包進(jìn)行修 復(fù)，比如可以使用前向糾錯(cuò)（FEC)策略在編解碼標(biāo)準(zhǔn)中加入容錯(cuò)邏輯，這樣在網(wǎng)絡(luò)傳輸時(shí) 如果存在丟包，那么接收端可以通過冗余信息恢復(fù)部分丟失的數(shù)據(jù)。以上這些損傷恢復(fù)機(jī) 制的出現(xiàn)使得原有的服務(wù)質(zhì)量（QoS)-用戶體驗(yàn)質(zhì)量（QoE)關(guān)聯(lián)模型會(huì)和預(yù)期的效果有所 偏差。因?yàn)榉?wù)質(zhì)量相關(guān)的參數(shù)是在接收端的網(wǎng)口部分探測(cè)到的，而網(wǎng)絡(luò)數(shù)據(jù)在經(jīng)過網(wǎng)口 后進(jìn)入解碼芯片前還有相應(yīng)的損傷處理過程，如圖2所示，其中有向?qū)嵕€表示業(yè)務(wù)流程，有 向虛線表示質(zhì)量損傷的傳遞。所以我們將探測(cè)點(diǎn)從損傷修復(fù)環(huán)節(jié)前的網(wǎng)絡(luò)端口移到損傷修 復(fù)環(huán)節(jié)之后的解碼緩沖區(qū)。
[0022] ②終端解碼緩沖區(qū)信息的獲取
[0023] 為了保持客戶端視頻的正常播放，在網(wǎng)絡(luò)環(huán)境理想的狀況下解碼緩存中的數(shù)據(jù)量 原則上應(yīng)該相對(duì)穩(wěn)定且完整的，此時(shí)用戶的體驗(yàn)是最佳的。一旦緩存中的數(shù)據(jù)量出現(xiàn)波動(dòng) 或缺失，那么可以認(rèn)為是網(wǎng)絡(luò)傳輸不穩(wěn)定造成的。比如傳輸信道的損傷造成了視頻流的丟 包，而存在丟包的視頻流在經(jīng)過機(jī)頂盒的糾錯(cuò)機(jī)制后未被完全修復(fù)，就會(huì)造成緩存中媒體 丟失率的上升。除了丟包以外，數(shù)據(jù)包的時(shí)延抖動(dòng)也會(huì)造成用戶體驗(yàn)質(zhì)量的下降。由于流媒 體業(yè)務(wù)對(duì)與實(shí)時(shí)性要求較高，即使不存在丟包，當(dāng)網(wǎng)絡(luò)抖動(dòng)過于劇烈而緩沖區(qū)發(fā)生下溢時(shí)， 用戶會(huì)明顯感到畫面的卡頓，同樣會(huì)影響用戶的體驗(yàn)質(zhì)量。為此我們選擇解碼緩沖區(qū)的媒 體丟失率及緩沖區(qū)下溢時(shí)間占比兩項(xiàng)參數(shù)來衡量用戶體驗(yàn)質(zhì)量。這兩項(xiàng)參數(shù)相對(duì)獨(dú)立，可 以分別獲取，并在一個(gè)統(tǒng)計(jì)周期內(nèi)將收集到的信息匯報(bào)給服務(wù)質(zhì)量分析模塊。終端解碼緩 沖信息的獲取需要調(diào)用底層解碼芯片的播放接口，這部分的代碼段以動(dòng)態(tài)庫的形式封裝在 中間件播放器框架內(nèi)，供播放器適時(shí)調(diào)用。
[0024] (a)媒體丟失率的監(jiān)測(cè)
[0025] 媒體播放器每將一組實(shí)時(shí)傳輸協(xié)議的傳輸流載荷放入緩沖時(shí)，需調(diào)用接口 ：
[0026] 獲取傳輸流服務(wù)質(zhì)量（傳輸流的地址指針，傳輸流的長度）；
[0027] 由于每個(gè)傳輸流包的長度固定為188字節(jié)，因此傳輸流的長度應(yīng)為188的整數(shù)倍， 播放器在串行調(diào)用了該函數(shù)后才可繼續(xù)執(zhí)行接下來的播放操作。
[0028] 首先獲取緩沖區(qū)中每個(gè)傳輸流包頭的控制域的信息（一般復(fù)制前40字節(jié)），然后 將這組包頭序列放入一個(gè)環(huán)形緩沖區(qū)中備用，而模塊中的媒體丟失監(jiān)測(cè)線程會(huì)從同一個(gè)環(huán) 形緩沖中讀取這些包頭進(jìn)行丟失率分析。由于填充環(huán)形緩沖的函數(shù)由播放線程調(diào)用，而讀 取緩沖的函數(shù)由統(tǒng)計(jì)線程調(diào)用，所以在代碼中需要用到線程庫的條件變量和線程鎖來進(jìn)行 線程同步和互斥，這樣當(dāng)緩沖為空時(shí)統(tǒng)計(jì)線程會(huì)休眠直到有數(shù)據(jù)可讀時(shí)才被喚醒。
[0029] 在對(duì)傳輸流進(jìn)行丟失率統(tǒng)計(jì)時(shí)由于傳輸流包頭域的計(jì)數(shù)字段（continuity_ counter)只有4位，因此每隔16個(gè)傳輸流包其序列號(hào)會(huì)回環(huán)。如果單純依賴計(jì)數(shù)字段判斷 丟包的話，那么連續(xù)丟失16個(gè)整數(shù)倍的數(shù)據(jù)包的情況將不會(huì)被納入丟失統(tǒng)計(jì)。
[0030] 因此這里對(duì)于媒體丟失率的統(tǒng)計(jì)還需要依賴節(jié)目時(shí)鐘基準(zhǔn)（Programe Clock ReferenCe，PCR)。如前所述我們定義緩沖區(qū)中的媒體丟失率為傳輸流序列的丟包率，那么 可以用如下公式進(jìn)行定量計(jì)算：

【權(quán)利要求】
1. 一種用于智能電視終端的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，其特征在于，其包括服務(wù)質(zhì)量監(jiān)測(cè) 模塊、服務(wù)質(zhì)量分析模塊及質(zhì)量監(jiān)測(cè)控制模塊；其中： 所述服務(wù)質(zhì)量監(jiān)測(cè)模塊負(fù)責(zé)收集服務(wù)質(zhì)量信息，其無差別地抓取所有經(jīng)過網(wǎng)絡(luò)端口的 數(shù)據(jù)包，進(jìn)行丟包、端到端時(shí)延計(jì)算和流媒體協(xié)議解析，以實(shí)現(xiàn)按節(jié)目流的計(jì)算和監(jiān)測(cè)； 所述服務(wù)質(zhì)量分析模塊分析服務(wù)質(zhì)量監(jiān)測(cè)模塊傳送的服務(wù)質(zhì)量參數(shù)，對(duì)播放終端緩沖 區(qū)的統(tǒng)計(jì)信息作出基于用戶體驗(yàn)質(zhì)量的評(píng)測(cè)，再將整理后的用戶體驗(yàn)質(zhì)量和服務(wù)質(zhì)量信息 寫入日志文件，并定時(shí)上報(bào)業(yè)務(wù)商的服務(wù)器； 所述質(zhì)量監(jiān)測(cè)控制模塊接收遠(yuǎn)程服務(wù)器的控制信令，對(duì)質(zhì)量監(jiān)測(cè)模塊的運(yùn)行模式和相 關(guān)參數(shù)進(jìn)行更改，如改變上報(bào)周期、統(tǒng)計(jì)周期、文件傳輸協(xié)議FTP服務(wù)器地址；此外，該模塊 還獲取當(dāng)前統(tǒng)計(jì)周期內(nèi)的實(shí)時(shí)質(zhì)量信息通過超文本傳輸協(xié)議HTTP上報(bào)給服務(wù)端。
2. 根據(jù)權(quán)利要求1所述的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，其特征在于，所述服務(wù)質(zhì)量監(jiān)測(cè)模塊進(jìn) 行服務(wù)質(zhì)量信息收集時(shí)，其對(duì)抓取的包按照控制協(xié)議進(jìn)行歸類，分別統(tǒng)計(jì)組播、點(diǎn)播不同點(diǎn) 播類型及播放、暫停、快進(jìn)及快退不同播放狀態(tài)下流媒體數(shù)據(jù)包的傳輸情況；具體流程如 下： (1) 將網(wǎng)卡設(shè)置為混雜模式； (2) 根據(jù)IP地址在抓取到的數(shù)據(jù)包中篩選出和本機(jī)相關(guān)的包進(jìn)行篩選； (3) 流媒體協(xié)議的解析：對(duì)抓取的包按照控制協(xié)議進(jìn)行歸類；其中Internet組管理協(xié) 議包用來傳輸組播命令，傳輸控制協(xié)議TCP包根據(jù)不同的控制協(xié)議又分為超文本傳送協(xié)議 HTTP和實(shí)時(shí)流傳輸協(xié)議RTSP包，超文本傳送協(xié)議用來傳輸認(rèn)證信息和網(wǎng)頁請(qǐng)求，實(shí)時(shí)流傳 輸協(xié)議包用來傳輸點(diǎn)播命令，M)P包中我們只對(duì)使用實(shí)時(shí)傳輸協(xié)議RTP協(xié)議的流媒體數(shù)據(jù) 包進(jìn)行分析； (4) 丟包計(jì)算：只有在點(diǎn)播狀態(tài)下，發(fā)送該周期統(tǒng)計(jì)數(shù)據(jù)，包括周期開始和結(jié)束時(shí)間、收 到的數(shù)據(jù)包數(shù)、丟包數(shù)和數(shù)據(jù)量；如果處于暫停、快進(jìn)、快退狀態(tài)，則發(fā)送一個(gè)填充包；如 果一個(gè)統(tǒng)計(jì)周期內(nèi)既有正常播放也有暫停、快進(jìn)或快退操作，則舍棄該周期內(nèi)的統(tǒng)計(jì)數(shù)據(jù)， 只發(fā)送一個(gè)填充包； (5) 時(shí)延統(tǒng)計(jì)：對(duì)每一路視頻流，記錄其類型及請(qǐng)求響應(yīng)時(shí)間RRT，其類型為組播或點(diǎn) 播，組播請(qǐng)求響應(yīng)時(shí)間從發(fā)送Internet組管理協(xié)議開始，到收到第一個(gè)視頻包結(jié)束，點(diǎn)播 請(qǐng)求響應(yīng)時(shí)間從發(fā)實(shí)時(shí)流傳輸協(xié)議請(qǐng)求開始，到收到第一個(gè)視頻包結(jié)束； (6) 統(tǒng)計(jì)HTTP請(qǐng)求次數(shù)、HTTP請(qǐng)求失敗次數(shù)、認(rèn)證次數(shù)、認(rèn)證失敗次數(shù)。
3. 根據(jù)權(quán)利要求1所述的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，其特征在于，所述服務(wù)質(zhì)量分析模塊中， 將由網(wǎng)口探測(cè)的丟包率服務(wù)質(zhì)量參數(shù)模式改進(jìn)為播放器端解碼緩沖區(qū)探測(cè)方式；同時(shí)建立 了緩沖區(qū)探測(cè)信息與用戶體驗(yàn)質(zhì)量的映射關(guān)系，采用緩存中的媒體丟失率和緩沖區(qū)的下溢 時(shí)長作為影響用戶體驗(yàn)質(zhì)量的輸入。
4. 根據(jù)權(quán)利要求1所述的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，其特征在于：所述質(zhì)量監(jiān)測(cè)控制模塊中 采用定時(shí)向控制服務(wù)器發(fā)送心跳包的方式確保網(wǎng)絡(luò)的正常連接，以便控制服務(wù)器獲得網(wǎng)絡(luò) 中活躍的智能電視終端的數(shù)量。
5. 根據(jù)權(quán)利要求1所述的服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)，其特征在于：所述服務(wù)質(zhì)量監(jiān)測(cè)系統(tǒng)中 進(jìn)程采用內(nèi)存共享通信機(jī)制及外部接口的定義方式。
【文檔編號(hào)】H04N21/442GK104349220SQ201410690342
【公開日】2015年2月11日 申請(qǐng)日期:2014年11月25日 優(yōu)先權(quán)日:2014年11月25日
【發(fā)明者】劉新, 裘樹民, 葉德建 申請(qǐng)人:復(fù)旦大學(xué)