NGB中間件標準因素簡析
數字電視中間件技術與標準,大家都非常熟悉了。自2001年,DVB推出MHP中間件技術標準以來,全世界各地都開始了中間件技術的研究與標準制定工作,而且基本上都是源自于MHP的技術體系,雖然相關國家的標準化與行業組織進行了不同程度的修改與演進,但總的框架還是基本類似、一脈相承的。
本文引用地址:http://www.104case.com/article/190034.htm中國,自2001年12月以來也一直進行數字電視中間件技術研究與標準制定工作。從工信部提交的標準文本來看,中國標準總的技術體系與MHP有一定的兼容與延續性,盡管標準目前還沒有正式官方發布,但對國內一些公司進行數字電視中間件相關產品與系統的開發起到了非常大的促進與指導作用。當前,廣電總局正在領導制定NGB 數字電視中間件技術標準,這無疑對產業是一個具有十分重要意義和鼓舞人心的大事情。從當今技術發展和運營環境的新形勢來看,我們應該如何制定新的中間件標準?其技術架構應該如何適應“三網融合”的多媒體業務?新標準與老的是否應該有所不同?諸如此類的問題,應該是值得我們考慮的。筆者本人從業務應用的環境和技術架構的角度來闡述些許看法,以起到拋磚引玉的作用。
2、數字電視中間件標準的前世
在數字電視十多年的發展歷程中,出現了許多的中間件技術標準與產品,可以說數字電視中間件是一直伴隨著數字電視業務的運營,并且不斷發展、壯大和成熟。
廣為人知的MHP是從1998年開始由DVB主導制定的,那時的數字電視運營環境基本是單向,業務應用基本是EPG、電視游戲、 PPV、美食與天氣預報信息等,基于網絡的限制,電視商務、視頻點播等還只是停留在概念和實驗階段。不同的數字電視應用都可以是獨立的、具有邊界分明的運行環境(Applicationboundary),數字電視業務應用平臺一般都是通過菜單式進行啟動的,如右圖顯示:
從模塊功能來看,MHP標準考慮了較多的與數字電視硬件平臺功能相關聯的資源模塊:
從技術細節來看,MHP標準的API比較多地關注機頂盒平臺的功能與資源的使用與控制,如定義了專門的API(Java功能包)針對解調與數據裝載(Demux)、CAS控制、調諧(Tuning)、以及媒體播放、數據解析;相反,對協議卻較少涉及(留待平臺實現著自己去處理各種網絡協議),更沒有涉及到網絡文件裝載、流媒體點播與控制等協議。上圖摘自于MHP標準文本,示意了MHP平臺的一些資源層的功能特征。
MHP的應用處理基礎是基于DSM-CC對象輪播(ObjectCarousel)的應用管理器,而且基本是立足于單向廣播通道的(MPEGSection),如下圖展示:
盡管MHP標準也列出了DVB-HTML,但對HTML和JavaScript(ECMAScript)沒有進行詳細的規定,MHP平臺的實現一般都沒有特別關注MHP標準提出的“交互檔次”,但這一部分不是MHP標準的核心部分。
很顯然,在當時的網絡與運營的歷史環境與條件下,MHP標準主要重點是為了滿足單向環境下增值業務的跨平臺的運行,它很好地規范了增值業務與應用的下載、啟動、運行、消亡等控制以及資源共享、顯示與交互特征等技術與運營范圍與條件,網絡的交互性與融合性業務并是MHP標準的核心。這些網絡、技術與運營特征決定了MHP標準以Java虛擬機為基礎的平臺架構,規范了一整套以Java語言的編程接口,系統的啟動是從Java應用開始的,應用本身和其數據可以明顯區分開來,整個應用同時下載到終端平臺才執行(Java的類庫需要進行動態鏈接后才可以執行),通過Java應用將HTML等網頁串聯起來、形成補充。
然而,數字電視、通信和互聯網行業近幾年來發生了很大的變化,過去通過廣播網傳送的音視頻業務,目前通過互聯網、移動通信網同樣可以傳送。如果我們再來規劃中間件,得我們就必須重新考慮多媒體終端的中間件平臺的技術架構與資源使用特征。在我們已經進入“三網融合”的技術與運營的環境下,我們是否仍須堅持Java是中間件平臺的基礎與核心呢?我覺得我們有必要重新審視這個問題。3、數字電視中間件標準的今生
評論