账号:
密码:
最新动态
产业快讯
CTIMES / 文章 /
视讯串流系统技术探微
 

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

浏览人次:【9447】

视讯串流(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和qtssRTSPRequest ObjectType的资料型态分别是QTSS_Object和QTSS_ObjectType,它们的定义如下:


type得分void* QTSS_Object;


type得分 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请求角色」的处理流程》

RSA程式码

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的两个子系统:


公共工具(CommonUtilities Lib)

公共工具是一套管理「执行绪(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版中,RTCP Utilities Lib是独立子系统。这些类别负责组合和拆解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数位媒体处理器提供高画质视讯串流处理能力」一文为你做了相关的评析。

  相关新闻
» 美光针对用户端和资料中心等市场 推出232层QLC NAND
» 摩尔斯微电子在台湾设立新办公室 为进军亚太写下新里程碑
» 爱德万测试与东丽签订Micro LED显示屏制造战略夥伴关系
» 格斯科技携手生态系夥伴产学合作 推出油电转纯电示范车
» 宜鼎独创MIPI over Type-C解决方案突破技术局限,改写嵌入式相机模组市场样貌


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

Copyright ©1999-2024 远播信息股份有限公司版权所有 Powered by O3  v3.20.1.HK84S717IY8STACUKH
地址:台北数位产业园区(digiBlock Taipei) 103台北市大同区承德路三段287-2号A栋204室
电话 (02)2585-5526 #0 转接至总机 /  E-Mail: webmaster@ctimes.com.tw