葉 楠
(福州理工學(xué)院 信息工程系,福建 福州 350506)
基于多屏互動(dòng)的OTT平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)
葉楠
(福州理工學(xué)院 信息工程系,福建 福州 350506)
摘要:為了解決傳統(tǒng)電視業(yè)務(wù)單一、傳播區(qū)域受限的問題,使電視業(yè)務(wù)運(yùn)營走向智能化和豐富化,實(shí)現(xiàn)手機(jī)、PC、電視的三屏聯(lián)動(dòng),提出了一種基于多屏互動(dòng)的OTT平臺(tái)設(shè)計(jì)方案。該方案通過搭建BO管理系統(tǒng)、Portal門戶系統(tǒng)、CDN系統(tǒng)和推流系統(tǒng),提供了面向全終端的直播、點(diǎn)播、時(shí)移和回看等收視服務(wù);通過建立移動(dòng)終端與機(jī)頂盒之間、移動(dòng)終端之間的交互協(xié)議,實(shí)現(xiàn)了收視服務(wù)的云互動(dòng),并且支持手機(jī)遙控器控制電視。OTT平臺(tái)下個(gè)性化收視服務(wù)及多屏互動(dòng)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn),不僅促進(jìn)了電視的多樣化業(yè)務(wù)傳播,也豐富了人們的智能化生活。
關(guān)鍵詞:多屏互動(dòng);OTT;移動(dòng)終端;CDN
移動(dòng)互聯(lián)網(wǎng)的蓬勃發(fā)展,刺激著智能終端市場的不斷增長。中青年用戶利用碎片化的時(shí)間,觀看視頻、玩游戲、交友以及溝通等,大大降低了電視大屏的開機(jī)使用率,這也促使廣電運(yùn)營商必須加速全面轉(zhuǎn)型[1]。以O(shè)TTTV和互聯(lián)網(wǎng)新型網(wǎng)絡(luò)服務(wù)為代表的新業(yè)務(wù)形態(tài)以互聯(lián)網(wǎng)上豐富的視頻、信息內(nèi)容,良好的用戶操作體驗(yàn)和用戶自主、便捷的溝通交流手段迎合并滿足了消費(fèi)者日益增長的精神文化需求[2]。
OTTTV和互聯(lián)網(wǎng)新型網(wǎng)絡(luò)服務(wù)近年來快速發(fā)展,逐步開始聚合視頻內(nèi)容和互聯(lián)網(wǎng)信息服務(wù),用戶所關(guān)注的屏幕逐漸從電視快速向PC、手機(jī)、Pad等拓展,多屏互動(dòng)與跨屏業(yè)務(wù)逐漸成為行業(yè)關(guān)注焦點(diǎn)[3-4]。對于有線電視運(yùn)營商而言,順應(yīng)、滿足用戶對于多屏的需求,將自己的服務(wù)從電視屏延伸到智能終端(PC,Pad,Phone)上,已經(jīng)成為增強(qiáng)用戶粘性、降低用戶離網(wǎng)率、提升行業(yè)競爭力的重要舉措[5-6]。
1總體設(shè)計(jì)
本方案采用如圖1所示的OTT平臺(tái)架構(gòu)進(jìn)行搭建,以直播組播源接入、點(diǎn)播媒資內(nèi)容注入為入口,流媒體ISS出流、統(tǒng)一面向用戶的Portal門戶為出口提供了多樣化的信息服務(wù)。OTT整體平臺(tái)按照功能可分為5個(gè)域:內(nèi)容業(yè)務(wù)域、運(yùn)營管控域、運(yùn)營支撐域、能力支撐域、終端設(shè)備域,平臺(tái)內(nèi)部架構(gòu)的具體子模塊可分為BO管理子系統(tǒng)、信息交互系統(tǒng)IS、UBA統(tǒng)計(jì)系統(tǒng)以及面向移動(dòng)終端設(shè)備域的ISS流媒體系統(tǒng)。下面對OTT平臺(tái)的各個(gè)關(guān)鍵模塊進(jìn)行詳細(xì)說明介紹[7-8]。
圖1OTT平臺(tái)總體框架
1.1BO管理子系統(tǒng)
OTT平臺(tái)BO子系統(tǒng)提供了媒資元數(shù)據(jù)的維護(hù)管理,認(rèn)證鑒權(quán)服務(wù),以及產(chǎn)品流程的生命周期管理。BO管理子系統(tǒng)包含了CMS內(nèi)容管理系統(tǒng)、OSS運(yùn)營支撐系統(tǒng)、AAA鑒權(quán)計(jì)費(fèi)模塊、PortalMS門戶發(fā)布系統(tǒng)等子模塊[9-10]。
1.2統(tǒng)一Portal門戶
統(tǒng)一Portal系統(tǒng)是業(yè)務(wù)最終展現(xiàn)的出口,是各種業(yè)務(wù)面向多終端用戶的最后一道關(guān)口,是前端系統(tǒng)與終端間的橋梁,并能夠根據(jù)地區(qū)差異提供不同的門戶信息。
1.3轉(zhuǎn)碼系統(tǒng)
轉(zhuǎn)碼系統(tǒng)分為實(shí)時(shí)轉(zhuǎn)碼系統(tǒng)和離線轉(zhuǎn)碼系統(tǒng)兩部分。直播組播源入流時(shí),經(jīng)過實(shí)時(shí)轉(zhuǎn)碼系統(tǒng),轉(zhuǎn)出需要的分辨率和碼率的直播源,以適應(yīng)不同類型終端的觀看。點(diǎn)播媒資注入后,經(jīng)過離線轉(zhuǎn)碼系統(tǒng),轉(zhuǎn)出多種碼率,在終端上可根據(jù)網(wǎng)絡(luò)環(huán)境的狀況及帶寬來選擇適合的碼率,保證了用戶端的流暢播放。
1.4ISS流服務(wù)系統(tǒng)
ISS系統(tǒng)是OTT平臺(tái)中對直播、點(diǎn)播、時(shí)移和回看數(shù)據(jù)進(jìn)行不同格式封裝后以HLS分片傳輸?shù)牧鞣?wù)系統(tǒng)[11]。通過對視頻元數(shù)據(jù)的熱點(diǎn)處理、緩存定位及HTTP傳輸,實(shí)現(xiàn)了平臺(tái)到終端設(shè)備的出流,對于設(shè)備的有效利用率、用戶的出流穩(wěn)定性上也做了關(guān)鍵性的處理。
2關(guān)鍵技術(shù)與處理流程
OTT平臺(tái)可根據(jù)運(yùn)營商的資源情況進(jìn)行靈活部署,目前初期采用集中式部署,通過對統(tǒng)一組播信源的轉(zhuǎn)碼收錄,由OTT服務(wù)器進(jìn)行切片封裝處理后,以HLS分片的形式,對外提供服務(wù)[12]。
2.1媒資內(nèi)容播發(fā)流程
如圖2所示為媒資元數(shù)據(jù)的注入及上線流程。媒資系統(tǒng)通過ADI接口同步編目信息至OTT平臺(tái),通過對ADI字段的解析處理,調(diào)用離線轉(zhuǎn)碼設(shè)備的相應(yīng)模板,即完成了媒資的注入過程。媒資文件下載完成后,由內(nèi)容播發(fā)模塊CPM對媒資來進(jìn)行上線過程的處理。
2.2CDN內(nèi)容分發(fā)子系統(tǒng)
圖3所示為CDN內(nèi)容分發(fā)系統(tǒng)的架構(gòu)圖。CDN支持集中式部署、多級部署方式。其中,中心存儲(chǔ)只做中心內(nèi)容緩存,由邊緣加速層面向終端,提供流服務(wù)。CDN中,重要模塊功能如下:
1)CI:內(nèi)容導(dǎo)入模塊,提供將媒資內(nèi)容導(dǎo)入到CDN中的接口。
圖2 CPM內(nèi)容播發(fā)流程
2)CPM:策略管理模塊,負(fù)責(zé)對CL、CG的管理。
3)CL:內(nèi)容中心存儲(chǔ),主要負(fù)責(zé)節(jié)目存儲(chǔ),同時(shí)為其他CL和CG提供下載服務(wù)。
4)CLS:內(nèi)容調(diào)度模塊,負(fù)責(zé)對CG或CL的調(diào)度管理。
5)RTCL:直播錄制模塊,負(fù)責(zé)直播流的收錄和錄制。
6)CG/ISS:邊緣緩存,對CL和RTCL中內(nèi)容進(jìn)行緩存和加速。
7)GLSB:全局負(fù)載均衡模塊,對CLS進(jìn)行全局調(diào)度。
CDN可以很方便地進(jìn)行橫向和縱向擴(kuò)容。通過在邊緣加速層,新增一個(gè)CG節(jié)點(diǎn),從而完成橫向擴(kuò)容,不影響原有緩存節(jié)點(diǎn)的服務(wù)。通過縱向擴(kuò)容,增加邊緣緩存加速的層數(shù),從而實(shí)現(xiàn)樹狀體系結(jié)構(gòu),即增加了一層CDN的分節(jié)點(diǎn)。
圖3CDN內(nèi)容分發(fā)子系統(tǒng)
2.3基于云互動(dòng)的跨屏協(xié)同平臺(tái)
如圖4所示為OTT平臺(tái)中的多屏互動(dòng)系統(tǒng)實(shí)現(xiàn)架構(gòu)[13]。為了體現(xiàn)手機(jī)與手機(jī)之間、手機(jī)與機(jī)頂盒之間的信息交互[14],通過前端中介交互時(shí),移動(dòng)終端之間分別與前端XMPP服務(wù)器交互,手機(jī)與機(jī)頂盒之間通過網(wǎng)關(guān)交互服務(wù)器傳輸互動(dòng)消息[15]。將原本發(fā)送的消息通過BASE64變換后得到字符串,作為報(bào)文消息來傳輸[16-17]。
2.4設(shè)計(jì)方案合理性及有效性
通過與國內(nèi)外主流的多屏互動(dòng)實(shí)現(xiàn)方式進(jìn)行了深入對比,本設(shè)計(jì)方案從多個(gè)角度考慮,采取了最優(yōu)的設(shè) 計(jì)方法,具體包含如下內(nèi)容:
1)推流架構(gòu)設(shè)計(jì):與傳統(tǒng)的一級推流相比,本設(shè)計(jì)方案采用分布式CDN部署,能有效解決收視業(yè)務(wù)的并發(fā)推流能力分配問題及分節(jié)點(diǎn)的建設(shè)部署。
2)移動(dòng)終端與機(jī)頂盒外交互設(shè)計(jì):本方案采用TCP
圖4 基于云互動(dòng)的跨屏協(xié)同平臺(tái)
POST請求來進(jìn)行交互信息傳遞,與傳統(tǒng)的機(jī)頂盒局域網(wǎng)內(nèi)UDP交互相比,適應(yīng)性更強(qiáng),應(yīng)用場景更廣泛。
3)移動(dòng)終端之間的交互設(shè)計(jì):通過前端XMPP實(shí)現(xiàn)移動(dòng)終端交互,可以建立用戶家庭組,后期可添加家庭成員聊天等更多互動(dòng)功能,業(yè)務(wù)及接口擴(kuò)展性較強(qiáng)。
4)業(yè)務(wù)層、協(xié)議層模塊化處理:如圖5所示,業(yè)務(wù)層只處理業(yè)務(wù)相關(guān)的工作,切拉屏消息、按鍵消息等,而協(xié)議層則只處理傳輸相關(guān)工作,例如UDP字符串序列化,外交互方式配對、JSON封裝等。本方案采用分層設(shè)計(jì)方法,方便了后續(xù)增加新的協(xié)議支持,提高了擴(kuò)展性。
圖5業(yè)務(wù)層及協(xié)議層工作流程
3系統(tǒng)冗余性設(shè)計(jì)
多屏互動(dòng)系統(tǒng)目前設(shè)備按照1臺(tái)點(diǎn)播推流(IP為192.168.12.12),3臺(tái)直播推流(IP分別為192.168.12.13、192.168.12.14和192.168.12.15)。
推流服務(wù)器采用N+1備份(N=4),使用一臺(tái)服務(wù)器(192.168.12.7)作為3臺(tái)直播和1臺(tái)點(diǎn)播服務(wù)器的備用服務(wù)器,使用浮動(dòng)IP實(shí)現(xiàn)主備部署,當(dāng)主服務(wù)器宕機(jī)后,浮動(dòng)IP會(huì)跳轉(zhuǎn)至備用服務(wù)器,備用服務(wù)器將繼續(xù)提供推流服務(wù)。各個(gè)主服務(wù)器對應(yīng)的浮動(dòng)IP見表1。
回看錄制文件及點(diǎn)播媒資存儲(chǔ)在HP2000磁陣存儲(chǔ)上,并通過FC接入到服務(wù)器上,通過NFS共享給主流媒體服務(wù)器和備流媒體服務(wù)器。各主機(jī)和備機(jī)之間通過keepalive保持心跳,當(dāng)主流媒體服務(wù)器宕機(jī)時(shí),通過keepalive可以秒級切換至備機(jī)繼續(xù)提供推流服務(wù),視頻數(shù)據(jù)也可保持一致性,保證了災(zāi)備的冗余。
表1Keepalive浮動(dòng)IP冗余備份
排序主服務(wù)器業(yè)務(wù)IP浮動(dòng)IP1192.168.12.12192.168.12.22192.168.12.13192.168.12.33192.168.12.14192.168.12.44192.168.12.15192.168.12.5
另外,通過定時(shí)任務(wù)監(jiān)測推流進(jìn)程的服務(wù)情況,當(dāng)進(jìn)程因不明故障終止運(yùn)行時(shí),通過crond即可使進(jìn)程在5min內(nèi)自動(dòng)啟動(dòng),繼續(xù)對外提供服務(wù)。
4系統(tǒng)測試與對比
為了驗(yàn)證設(shè)計(jì)方案的穩(wěn)定性,方便對系統(tǒng)性能做出評估,對OTT平臺(tái)的各項(xiàng)指標(biāo)做了如下測試。
4.1接口性能測試
ApacheJMeter作為基于Java的壓力測試工具,可針對軟件接口進(jìn)行模擬HTTP請求并發(fā)負(fù)載。本次測試主要結(jié)合終端界面,針對PORTAL服務(wù)器的幾個(gè)重要接口,測試要求達(dá)到如下幾項(xiàng)指標(biāo):1)測試機(jī)CPU不超過80%;2)接口請求的最大響應(yīng)時(shí)間不超過1 000ms(平均值一般在3ms左右);3)請求響應(yīng)的成功率保持100%;4)單接口同時(shí)并發(fā)請求達(dá)到3 000并發(fā)及以上。
終端啟動(dòng)后,接口調(diào)用順序如下:getPortalServerIP,getUpdateInfo,getSessionId,其他配置信息順序任意。
接口說明及測試結(jié)果如表2所示。
表2Portal接口性能測試
接口類型并發(fā)用戶數(shù)測試機(jī)CPU/%最大響應(yīng)時(shí)長/msError/%Portal服務(wù)獲取門戶地址getPortalServerIP獲取客戶端版本信息getUpdateInfo獲取會(huì)話IDgetSessionId獲取首頁推薦列表getWelcomeList獲取直播節(jié)目列表getChannelInfoList獲取欄目列表getColumnInfoList獲取點(diǎn)播節(jié)目列表getProgramInfoList獲取點(diǎn)播節(jié)目信息getProgramInfo3000363505521004057067218040670662810754570521210
表2給出了Portal服務(wù)的不同接口在3 000并發(fā)用戶下的響應(yīng)時(shí)延及錯(cuò)誤率的測試結(jié)果。由表2可見,通過Jmeter限定用戶數(shù)在一定時(shí)間內(nèi)增加至最高3 000時(shí),各接口的請求響應(yīng)時(shí)延最大值均小于1 000ms,符合測試參數(shù)要求。另一方面,表2中的測試機(jī)CPU在測試過程中均未達(dá)到80%,保證了測試機(jī)的性能充裕,不會(huì)對測試響應(yīng)時(shí)延值的準(zhǔn)確性造成影響。由于不同接口所請求的信息量不同,所以同樣是3 000并發(fā)下的接口請求,請求信息量大的相對時(shí)延稍長,但從用戶體驗(yàn)的角度來說,都能夠滿足指標(biāo)要求。
4.2推流并發(fā)測試
為了模擬真實(shí)用戶點(diǎn)播場景,必須采用端到端的方式來進(jìn)行測試,即保證壓力測試機(jī)的性能充裕,不會(huì)成為瓶頸,且網(wǎng)絡(luò)帶寬足夠。本次測試選取了LoadRunner作為推流并發(fā)測試軟件,并編寫創(chuàng)建了Vuser腳本來模擬并發(fā)請求;另外,在Linux下使用了nmon來采集實(shí)時(shí)監(jiān)控的數(shù)據(jù)。將直播、點(diǎn)播、時(shí)移、回看按照1∶1∶1∶1的用戶數(shù)比例進(jìn)行壓測,如表3所示。
表3收視業(yè)務(wù)用戶數(shù)分配
設(shè)備組用戶數(shù)占比/%事務(wù)數(shù)/時(shí)HLS-LIVE50025556315.2HLS-VOD50025121038.4HLS-TIMESHIFT50025281980.4HLS-BACK5002579898.4合計(jì)2000100—
用戶請求響應(yīng)的時(shí)延,實(shí)際上就取決于分片的大小,客戶端會(huì)根據(jù)m3u8索引文件不斷地下載并播放這些小文件,因此播放是否流暢,由分片是否在短時(shí)間內(nèi)成功下載來決定。本次測試分片下載基本概況為(詳見表4和圖6):
TitleTransactionResponseTimeUnderLoad
GraphTypeCorrelate
BaseGraphRunningVusers
AdditionalAverageTransactionResponseTime
Granularity1Second
表4測試數(shù)據(jù)統(tǒng)計(jì)表
顏色規(guī)格測試項(xiàng)最短時(shí)間/s平均時(shí)間/s最長時(shí)間/s紫1Action_Transaction0.2661.0886.298綠1vuser_end_Transaction000紅1vuser_init_Transaction0.0010.0010.003黃1分片下載0.0060.2132.275藍(lán)1分片列表下載0.0340.1710.908
圖6 負(fù)載下事務(wù)響應(yīng)時(shí)間測試(截圖)
分析以上測試數(shù)據(jù),可得出:1)分片下載成功率為100%;2)平均分片下載時(shí)長為0.2s。
從以上測試結(jié)果可以看到,對直播、點(diǎn)播、時(shí)移、回看業(yè)務(wù)按同比例用戶數(shù)進(jìn)行綜合測試,分片下載正常,時(shí)延在合理的范圍內(nèi),表明本系統(tǒng)具備較高的穩(wěn)定性。
5小結(jié)
本文結(jié)合廣電運(yùn)營商在面向OTT移動(dòng)終端用戶上的發(fā)展需求,提出了一種在OTT平臺(tái)上實(shí)現(xiàn)多屏互動(dòng)的設(shè)計(jì)方案。采用XMPP協(xié)議在前端中介進(jìn)行交互的形式,為直播、點(diǎn)播、時(shí)移、回看業(yè)務(wù)在移動(dòng)終端和機(jī)頂盒之間進(jìn)行信息互動(dòng)共享提供了實(shí)現(xiàn)[18]。測試表明,本設(shè)計(jì)方案對不同類型終端設(shè)備的兼容性強(qiáng),為業(yè)務(wù)的廣泛覆蓋提供了前提條件;對外圍接口的開放性高,具有良好的業(yè)務(wù)擴(kuò)展性;可流暢播放,符合實(shí)際的使用需求。在OTT平臺(tái)上實(shí)現(xiàn)多屏互動(dòng)系統(tǒng)對促進(jìn)廣電運(yùn)營商增強(qiáng)用戶群的黏度,實(shí)現(xiàn)用戶與用戶間的有效聯(lián)動(dòng),實(shí)現(xiàn)多網(wǎng)絡(luò)、多終端、多業(yè)務(wù)的智能融合具有重要的意義[19-20]。
參考文獻(xiàn):
[1]呂品.智能終端與OTT業(yè)務(wù)[J].電視技術(shù),2012,36(S1):34-36.
[2]劉明亮.OTTTV的直播解決方案[J].電視技術(shù),2014,38(20):33-36.
[3]賈云濤,趙強(qiáng).IPTV,OTTTV對有線電視運(yùn)營影響分析及應(yīng)對策略的思考[J].中國數(shù)字電視,2013(7):30-35.
[4]劉洋.三網(wǎng)融合下電信運(yùn)營商TV屏業(yè)務(wù)發(fā)展策略建議[J].電信科學(xué),2011(S1):187-190.
[5]鄭鵬思.關(guān)于三網(wǎng)融合視頻業(yè)務(wù)實(shí)現(xiàn)的研究[J].廣播與電視技術(shù),2011,38(12):82-84.
[6]王澤,屈海偉.IPTV與OTT+TV融合業(yè)務(wù)客戶端解決方案研究[J].互聯(lián)網(wǎng)天地,2015(1):36-38.
[7]黃升民.八問OTT—OTTTV對電視產(chǎn)業(yè)的影響和對策解析[J].現(xiàn)代傳播,2013(10):1-6.
[8]魏國亮.多屏互動(dòng)技術(shù)在高清互動(dòng)平臺(tái)中的應(yīng)用[J].中國有線電視,2013(10):1180-1182.
[9]吳軼群,朱亞東,王明敏.基于平臺(tái)的多屏互動(dòng)系統(tǒng)設(shè)計(jì)[J].計(jì)算機(jī)應(yīng)用與軟件,2014,31(10):234-238.
[10]鐘成軍,鄭鵬思,胡昕宇.基于多屏互動(dòng)的OTT平臺(tái)建設(shè)的研究[J].廣播與電視技術(shù),2014,41(4):40-45.
[11]董道國,李青,魏國慶.一種適用于傳統(tǒng)互動(dòng)機(jī)頂盒的多屏互動(dòng)技術(shù)方案[J].中國有線電視,2014(1):31-34.
[12]成霄,李玉軍.基于IGRS的數(shù)字電視多屏互動(dòng)關(guān)鍵技術(shù)研究[J].高新技術(shù),2013(1):1-2.
[13]萬心茹.不同終端多屏互動(dòng)平臺(tái)的交互設(shè)計(jì)研究[D].天津:天津大學(xué),2012.
[14]倪喧.融合新媒體環(huán)境下廣電OTT發(fā)展現(xiàn)狀[J].中國傳媒科技,2012(4):73-74.
[15]馬曉,馬立銘,曹三省.面向業(yè)務(wù)的智能電視系統(tǒng)架構(gòu)設(shè)計(jì)[J].電視技術(shù),2012,36(12):32-34.
[16]樊軍,曾培峰,唐莉萍.基于和的網(wǎng)絡(luò)視頻會(huì)議系統(tǒng)的研究[J].計(jì)算機(jī)應(yīng)用與軟件,2011,28(10):227-230.
[17]楊 斌.XMPP協(xié)議分析與應(yīng)用探討[J].微型機(jī)與應(yīng)用,2005(8):32-34.
[18]沈建輝,席彥彬.迎接云電視時(shí)代[J].中國有線電視,2013(1):28-30.
[19]施唯佳,蔣力,賈立鼎.和的技術(shù)比較分析[J].電信科學(xué),2014,30(5):14-19.
[20]章鹿華,王思彤,易忠林,等.面向智能用電的家庭綜合能源管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].電測與儀表,2010,47(9):35-38.
DesignandimplementationofmultiscreenonOTTplatform
YENan
(Department of Information Engineering, Fuzhou Institute of Technology, Fuzhou 350506, China)
Abstract:In order to solve the problems that traditional TV business is single and the communication area is limited, the designing project of a OTT platform based on multi screen interactive is proposed to achieve three screen linkage of mobile phones, computers and TV. The scheme through setting up by BO management system, Portal system, CDN system and plug-flow system that provides for the whole terminal live, on-demand and back to see TV service. Through the establishment of the interactive protocol between the mobile terminal and set-top boxes, as well as between mobile terminals, the service of the cloud is realized, and the remote control TV is supported. The design and implementation of personalized service and multi screen interactive system based on OTT platform not only promote the diversified business communication, but also enrich people's intelligent life.
Key words:multi screen interaction; OTT; mobile terminal; CDN
中圖分類號:TN949.2
文獻(xiàn)標(biāo)志碼:A
DOI:10.16280/j.videoe.2016.03.014
基金項(xiàng)目:福建省教育廳B類科技項(xiàng)目(JB14230)
作者簡介:
葉楠(1990— ),女,碩士,助教,主研電子信息、圖形學(xué)與通信。
責(zé)任編輯:許盈
收稿日期:2015-09-17
文獻(xiàn)引用格式:葉楠. 基于多屏互動(dòng)的OTT平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[J].電視技術(shù),2016,40(3):65-70.
YEN.DesignandimplementationofmultiscreenonOTTplatform[J].Videoengineering,2016,40(3):65-70.