帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
視訊串流系統技術探微
 

【作者: 誠君】   2005年12月05日 星期一

瀏覽人次:【9425】

視訊串流(video streaming)是數位家庭技術中不可或缺的一部份。不過,由於它牽涉到許多複雜的新技術,以及不同的應用區隔和商業利益,所以,以它為基礎所建構的「數位視訊網路系統(digital video network system)」至今仍然還未普及。本文將介紹新一代的社區視訊系統,以及在進行即時(real time)視訊傳輸時,所必需的RTP、RTCP及RTSP串流伺服器技術。因為這種系統可以同時支援數據、語音和視訊傳輸,所以,它是「三合一(triple play)」的多媒體網路系統。


新一代的社區視訊系統

在目前的公寓社區中,常使用的視訊系統有兩種:一種是監視系統,它比較像資料蒐集(data collection)系統,從每個數位相機處收集影像,並儲存在伺服器的硬碟中。過去,它被稱作「閉錄電視(CCTV)」,現在它數位化了,所以有人改稱它為「數位硬碟錄影機(Digital video recorder;DVR)」。另一種就是纜線電視(CATV)。由於CATV的興起,現在的公寓大樓幾乎再也看不到平面電視所使用的八木天線了。不過,也由於CATV的「獨大」,使得類比


平面電視、數位電視、衛星電視、網路電視或網路廣播很難出頭天。


新一代的社區用視訊系統將會包含:視訊伺服器(video server)、視訊從屬器(video client)和視訊閘道器(video gateway)。而且,它會將監視系統和各種電視視訊系統包含在內。(圖一)是新一代社區用的視訊系統架構。



《圖一 新一代社區用的視訊系統架構》
《圖一 新一代社區用的視訊系統架構》

這套新系統至少具有下列幾個優點:


採用DSP技術,可以縮短運算時間

在電視視訊網路內的閘道器中,可能具有MPEG-2編碼器,而在視訊從屬器中,會有MPEG-2解碼器。由於來自類比平面電視和CATV的訊號是屬於類比的,所以必須先經過數位調變,再將訊號轉換成MPEG-2視訊。若DSP是和CPU整合在一起的,則可以使視訊閘道器和從屬器的體積縮小。而在監視系統中,在視訊從屬器裡面,可能會有MPEG-4編碼器,閘道器則負責將這些MPEG-4視訊傳遞給視訊伺服器解碼。視訊伺服器可能是一台電腦,它也許不使用硬體的MPEG-4編碼器,而是以軟體的方式來解MPEG-4的碼。


即時傳輸,沒有延遲

由於使用RTP、RTCP和RTSP通訊協定,所以視訊是連續傳輸的,不會像TCP因為需要重傳而造成影像延遲。這對過去使用M-JPEG傳送監視畫面的舊系統而言,無疑是一大革新。此外,電視視訊對延遲的要求很嚴苛,這需要軟體的RTP、RTCP和RTSP通訊協定以外,還需要硬體配合。例如:電視的聲音訊號和影像訊號必須永遠同步,而且,必須在離開視訊閘道器之後,仍能維持同步。這對視訊處理器而言,是一大挑戰。


功能可以擴充,軟體可以隨時升級

作業系統和應用軟體都可以利用網路來升級。而且,可以隨著用戶的增加,來增加視訊從屬器的數量。因為電視視訊閘道器有支援「一對多的播放(multicast)」,所以用戶端的環境參數設定很簡單。


整合了數位式機上盒(STB)的功能

就功能而言,視訊閘道器具備了IP STB的功能,但是IP STB並不完全具備此視訊閘道器的功能。視訊從屬器內可以安裝MHP和OCAP中介軟體(middleware),藉此具有互動電視的功能。此外,在保護視訊內容方面,視訊閘道器可以藉由外插「條件存取(conditional access;CA)」的記憶卡,達到開碼和鎖碼的功能。而且,在視訊從屬器的解碼器內部,可以加入「數位版權管理(digital right management;DRM)」的機制,徹底防止盜拷的行為。


(圖二)是典型的IP網路監視系統的架構。其中視訊編碼器可以是MPEG-2或MPEG-4編碼器。


《圖二 IP網路監視系統》
《圖二 IP網路監視系統》

視訊串流伺服器

前面介紹的社區用視訊系統閘道器,也可能是一種視訊串流伺服器(video streaming server)。底下舉Apple的Quick Time串流伺服器(QTSS)和Darwin 串流伺服器(DSS)的程式碼為例來說明。


QTSS內部有許多模組。它會呼叫相對應的模組,來處理從屬端的請求。因此,串流伺服器可以依需要扮演不同的角色,而且,每一個角色負責執行一個特殊工作,所以,可以將「角色」看成一個「方法(method)」。底下將介紹串流伺服器在開機和關機時,以及處理從屬端的請求時,所扮演的不同角色。


(圖三)是QTSS串流伺服器在開機和關機時,


《圖三 QTSS串流伺服器在開機和關機時的工作流程》
《圖三 QTSS串流伺服器在開機和關機時的工作流程》

所執行的工作流程。當串流伺服器開機時,會先載入(load)動態模組(dynamic modules),然後載入靜態模組。之後,呼叫「註冊(Register)」模式(角色)的所有模組,每一個模組都必須支援這個「註冊」角色。如果某個模組有支援其它角色,則它可以在「註冊」模式下,使用AddRole( )函式來增加此新角色。這與Linux的載入新模組的觀念類似。


最後,串流伺服器呼叫「初始化」模式下的所有模組,這些模組都是註冊在此模式中。初始化工作包含:配置記憶體、使廣域的資料結構初始化等。


當串流伺服器關機時,它會呼叫「關機」模式下的所有模組,這些模組都是註冊在此模式中。此時,這些模組必須清除「執行緒(tasks)」,並將廣域的資料結構所使用的記憶體釋放出來。


RTSP請求

當QTSS串流伺服器呼叫「初始化」模式下的所有模組之後,它就準備接受從屬端的請求。這種請求稱為「RTSP請求(request)」。(圖四)為一個RTSP請求的範例。


《圖四 一個RTSP請求》
《圖四 一個RTSP請求》

當串流伺服器收到一個RTSP請求,它會產生一個「RTSP請求物件(QTSS_RTSPRequestObject)」,此物件包含了與這個請求相關的所有屬性(attributes),其中包括qtssRTSPReqFullRequest。之後,它會按照(圖五)的RTSP請求之處理程序,呼叫相關的模組。


qtssRTSPRequestObjectType是一個UINT32的值,代表一個特定的物件型態(object type),此型態包含了許多可以描述RTP串流或RTSP請求的屬性。


QTSS_RTSPRequestObject是一個物件,它的「型態」就是qtssRTSPRequestObjectType。qtssRTSPRequestObjectType的值是固定的,所以可以說:前者是後者的一個「實例(instance)」。在開機時,註冊角色已經將qtssRTSPRequestObjectType加入,表示「RTSP請求」這種物件是被串流伺服器接受的,所以當QTSS_RTSPRequestObject產生時,它就具備了應該要有的所有屬性了。因此,也可以說:qtssRTSPRequestObjectType的屬性就是QTSS_RTSPRequestObject的屬性。QTSS_RTSPRequestObject和qtssRTSPRequestObjectType的資料型態分別是QTSS_Object和QTSS_ObjectType,它們的定義如下:


typedef void* QTSS_Object;


typedef UInt32 QTSS_ObjectType;


當這個RTSP請求被回應之後,此「實例」(QTSS_RTSPRequestObject)就會消失。這「實例」必須和唯一的「RTSP對話物件(QTSS_RTSPSessionObject)」,在特定的連接條件下產生關聯。


除了「RTSP過濾角色」以外,其餘角色在處理QTSS_RTSPRequestObject時,每個屬性都可以分別得到一個值。但當「RTSP過濾角色」接收到QTSS_RTSPRequestObject之後,只有qtssRTSPReqFullRequest能得到值。qtssRTSPReqFullRequest的值包含了RTSP請求的完整內容。


當處理一個RTSP請求時,串流伺服器首先呼叫「RTSP過濾角色」。它會呼叫屬於這個角色的所有模組,並將「RTSP請求物件」傳送給它們。每一個模組的「RTSP過濾角色」可以改變qtssRTSPReqFullRequest的值。例如:一個RTSP過濾角色可能將/foo/foo.mov更改為/bar/bar.mov,所以,這也需要更改目錄來配合這個請求。


在屬於「RTSP過濾角色」的模組中,若有一個模組回應,則串流伺服器會直接呼叫「RTSP後處理(Postprocessor)角色」。「回應從屬端」的意思是指:該模組可能有資料要傳送給從屬端。


《圖五 RTSP請求  之處理》
《圖五 RTSP請求 之處理》

當所有屬於「RTSP過濾角色」的模組都被呼叫以後,串流伺服器會分析RTSP請求內容。此分析包含:將RTSP物件的剩餘屬性填滿,以及產生下列兩種「對話(session)」:


  • * 一個RTSP對話:它和這個特定的請求產生關聯。而且,當從屬端關閉它的RTSP連結時,此對話也會結束;


  • * 一個從屬端對話:它和從屬端連結產生關聯。RTSP請求是由從屬端發出的,之後,從屬端維持原狀,直到從屬端的串流展示(streaming presentation) 完成為止。



當串流伺服器分析完RTSP請求以後,它呼叫「RTSP路由角色」,並傳送RTSP物件給它們。每一個「RTSP路由角色」可以藉由使用某些屬性的值,來決定是否要改變qtssRTSPReqRootDir屬性的值。因此,在處理此RTSP請求時,會改變根目錄。例如:如果選擇的語言型態是法文,則模組會改變一個包含有法文版本的被請求檔案之qtssRTSPReqRootDir屬性。


qtssRTSPReqRootDir是QTSS_StandardRTSP_Params資料結構成員中的QTSS_RTSPRequestObject的屬性之一。它們的關係可以用下式來描述:QTSS_StandardRTSP_Params~QTSS_RTSPRequestObject~qtssRTSPReqRootDir


當所有的「RTSP路由角色」都被呼叫,而且沒有一個模組回應之後,串流伺服器會呼叫「RTSP前置處理(Preprocessor)角色」。「RTSP前置處理」通常會使用qtssRTSPReqAbsoluteURL屬性,來得出「RTSP請求」是與哪一個模組所處理的請求型態相符合。qtssRTSPReqAbsoluteURL的資料型態是字元陣列(char array),表示從rtsp://開始的URL網址。


如果請求型態相符合,「RTSP前置處理角色」會呼叫QTSS_Write或QTSS_WriteV來回應這個請求,並送出資料給從屬端。若要送出一個標準的回應,模組可以呼叫QTSS_SendStandardRTSPResponse或QTSS_AppendRTSPHeader和QTSS_SendRTSPHeaders。


任何處理「RTSP前置處理角色」的模組若能對從屬端做出回應,則後續的模組和角色都會被省略,串流伺服器會直接呼叫這個模組的「RTSP後處理角色」。


如果「RTSP前置處理角色」沒有對RTSP請求做回應,則串流伺服器會呼叫「RTSP請求角色」。註冊為「RTSP請求角色」的模組只有一個。「RTSP前置處理角色」無法處理的所有請求,都是由「RTSP請求角色」負責回應。當「RTSP請求角色」處理完「RTSP請求」之後,串流伺服器會呼叫「RTSP後處理角色」。「RTSP後處理角色」通常是負責帳目的工作,譬如:登錄(logging)的統計資訊。


處理「RTSP前置處理角色」或「RTSP請求角色」的模組,可能需要產生媒體資料給一個特定的從屬對話使用。此模組是呼叫QTSS_Play來產生媒體資料的。QTSS_Play會使此模組在「RTP傳送封包角色(RTP Send Packets role)」中被呼叫。如(圖六)所示。


「RTP傳送封包角色」呼叫QTSS_Write或QTSS_WriteV,並經過RTP對話來傳送資料至從屬端。當「RTP傳送封包角色」已經送出一些封包之後,如果還有封包需要繼續傳送,則會持續呼叫「RTP傳送封包角色」,直到全部封包被傳送完畢為止。如果從屬端中斷或暫停從屬對話,則傳送作業也會停止。


《圖六 「RTSP前置處理角色」和「RTSP請求角色」的處理流程》
《圖六 「RTSP前置處理角色」和「RTSP請求角色」的處理流程》

DSS程式碼

Darwin串流伺服器(DSS)的程式碼是Quick Time串流伺服器的公開版本(可以從http://developer.apple.com/darwin/projects/streaming下載)。據統計,目前Quick Time在電信設備市場上的使用率超過Windows Media Services和RealNetworks的RealSystem。Windows Media Service在PC市場領先;RealSystem伺服器則是在行動通訊裝置上領先。現在國外有許多公司都使用或參考Darwin串流伺服器的程式碼,來設計自家的產品。這也算是Apple行銷策略成功之處。所以,理解Darwin串流伺服器的程式碼似乎是工程師必修的功課。


DSS實現了四個標準的IETF通訊協定:RTSP(RFC 2326)、RTP(RFC 1889)、RTCP(RFC 1889)和SDP(RFC 2327)。在修改DSS的原始程式碼之前,最好能先熟悉這些RFC規格。


DSS是完全以C++設計的,並且採用了物件導向的觀念,譬如:繼承、多種型態(polymorphism)。幾乎每一對.h檔和.cpp檔就有一個C++類別(class),而且這些檔案的名稱和類別的名稱是一樣的。DSS子系統的程式碼是分開的,分別位於不同的目錄中。底下介紹DSS的兩個子系統:


公共工具(CommonUtilitiesLib)

公共工具是一套管理「執行緒(thread)」、資料結構、網路、文字分析的工具。DSS使用這些工具和類別來達到下列的目的:


  • * 使用抽象的方法,避免同樣的程式碼重覆出現;


  • * 利用封裝的技巧,使屬於比較上層的程式碼簡單易懂;


  • * 將任何與作業系統相關的程式碼區隔開來。



屬於公共工具的類別有:


OS類別

與作業系統相關的抽象程式碼,例如:計時、條件變數、互斥訊號(mutexes)和執行緒,這包含:OS、OSCond、OSMutex、OSThread、OSFileSource。還有資料結構:OSQueue、OSHashTable、OSHeap、OSRef。


插座(Sockets)

在TCP和UDP上層的程式,這些類別通常是非同步的(asynchronous)或非阻塞的(non-blocking),並能將「事件」傳送給「工作物件(Task objects)」進行處理。這些類別包含:EventContext、Socket、UDPSocket、UDPDemuxer、UDPSocketPool、TCPSocket、TCPListenerSocket。


分析工具

這些類別是文字分析和格式化的工具。包括:StringParser、StringFormatter、StrPtrLen、StringTranslator。


工作(Tasks)

這些類別為串流伺服器提供了非同步的事件處理機制。包括:Task、TimeoutTask和IdleTask。


RTCPUtilitiesLib

在DSS 5.5版中,RTCPUtilitiesLib是獨立子系統。這些類別負責組合和拆解RTCP封包。


QTFileLib

在DSS 5.5版中,QTFileLib是獨立子系統。提供簡單的程式介面函式(API),可以分析「提示軌跡(Hint Track)」 的格式與產生封包。由DSS播放的網路電影必須要有「提示資訊」,也就是說:每一個可以串流的媒體軌跡(或通道)都要有一個「提示軌跡」。「提示軌跡」負責告訴串流伺服器要如何將網路上的媒體資料封裝起來。請詳見http://www.apple.com/quicktime/tutorials/hinttracks.html。


伺服器核心(Server.tproj)

這個目錄包含了伺服器核心的程式碼,可以區分為三類:伺服器核心、與RTSP相關的子系統、與RTP相關的子系統。


RTSP子系統

這些類別負責分析和處理「RTSP請求」,並提供QTSS模組的RTSP程式介面函式。其中,有些類別直接對QTSS程式介面函式的元素做回應,例如:RTSPRequestInterface是一個QTSS_RTSPRequestObject物件。每一個RTSP TCP連結就有一個RTSP對話物件。RTSPSession物件是一個「工作」物件,負責處理與RTSP相關的事件。


RTP子系統

這些類別負責處理媒體資料的傳送。RTPSession物件包含了與RTSP對話編號(session ID)相關的資料。每一個RTPSession是一個「工作」物件,它可以按照排定的次序來傳送RTP封包。RTPStream物件代表一個單一的RTP串流。任何數量的RTPStream物件可以與唯一的RTPSession產生關聯。這兩個物件提供了QTSS模組的RTP程式介面函式。


伺服器核心

這些類別的名稱都以QTSS開頭。QTSServer負責處理開機和關機。QTSServerInterface負責儲存串流伺服器的廣域變數和統計數據。QTSSPrefs是一個資料儲存器,負責儲存串流伺服器的最喜好參數。QTSSModule、QTSSModuleInterface和QTSSCallbacks類別的唯一目的就是支援QTSS模組的程式介面函式。


結語

若想安裝QTSS或DSS 5.5,則需要一台PowerPC G5、G4或G3的迷你電腦,內有Mac OS X Server v10.4以上的作業系統、128 MB至256 MB的RAM、內建USB和4 GB的硬碟空間。此外,DSS的程式碼是完全使用C++設計的,所以,它並不適合在嵌入式系統中使用。但是,和Windows Media Server一樣,QTSS已經成為許多串流伺服器業者經常採用的服務平台,因此,無論如何視訊從屬器必須能與這兩種串流伺服器相容。


至於視訊從屬器裡面的串流播放器則可以參考live、ffmpeg、mpeg4ip,這些軟體都有支援MPEG-4和RTSP,而且程式碼是公開的;或者參考Helix、VLC、fenice和nemesi,這些軟體具有全部或部份的串流伺服器與串流播放器的功能。


延 伸 閱 讀
未來智慧手機的電源管理技術

在802.11無線區域網路(WLAN)上傳送視訊訊號面臨著時延管理方面的艱鉅挑戰,在IP上傳送視訊訊號一直沒有成功達到真正的廣播級QoS品質。本文首先介紹與已有WLAN QoS技術相關的問題,然後詳細解釋緩衝/速率自適應技術如何透過有效的QoS機制支援802.11a WLAN。相關介紹請見「 如何提高無線視訊串流的端到端QoS品質」一文。

多視訊串流在無線區域網路之傳輸最佳化研究. 摘要. 近年來,由於無線網路技術的蓬勃發展,加上多媒體應用快速普及與資料編解碼技術成熟,使得無線網路結合影音多媒體以提供各式多樣化服務已是通訊技術中一項重要的必然趨勢。你可在「 多視訊串流在無線區域網路之傳輸最佳化研究 」一文中得到進一步的介紹。

無線網路使用多種接取技術(例如:WLAN/WMAN、2G/2.5G/3G)。由於在有線、無線網路上的視訊串流的應用越來越廣泛,其重要性也日以俱增。在「 異質無線網路環境下MPEG-4 FGS 視訊串流服務之自適性接收端設計」一文為你做了相關的評析。

市場動態

希捷CE硬碟機係根據業界標準基礎研發,而非另闢蹊徑的專屬性解決方案,它從設計之初即遵循相容於新的ATA/7串流指令集標準。基於希捷過往得自客戶的反應,消費性電子製造商希望能不必再於多種不相容的方法中進行抉擇,以確保DVR產品中視訊串流的可靠性。相關介紹請見「第一台建置新視訊串流業界標準的硬碟機」一文。

搶攻數位家庭市場大餅,資訊業者力拱以個人電腦(PC)為核心,家電大廠堅持將以電視為中心,半導體業者則提出以閘道器(Gateway)為核心,廣達董事長林百里甚至提出「數位家庭將以內容為中心」。這場「中心」大戰正方興未艾。你可在「 數位家庭英特爾想號令天下 有得拚」一文中得到進一步的介紹。

TI) 宣佈推出新的720 MHz數位媒體處理器,其強大效能可以讓消費性電子和機上盒製造商提供高畫質的串流視訊。這顆數位媒體處理器是以TI的TMS320DM642 DSP為基礎,它能在720p解析度下產生多種格式的高畫質視訊串流。在「 TI新型720 MHz數位媒體處理器提供高畫質視訊串流處理能力」一文為你做了相關的評析。

  相關新聞
» TI創新車用解決方案 加速實現智慧行車的安全未來
» AMD擴展商用AI PC產品陣容 為專業行動與桌上型系統挹注效能
» 豪威汽車影像感測器高通數位底盤 可用於次代ADAS系統
» 意法半導體擴大3D深度感測布局 打造新一代時間飛行感測器
» AMD第2代Versal系列擴展自調適SoC組合 為AI驅動型系統提供端對端加速


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.18.118.12.101
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw