专利名称：视频点播网络的流媒体封包解包方法及系统的制作方法
技术领域：
本发明涉及视频点播网络技术领域，更具体地说，涉及视频点播网络 的流媒体封包解包方法及系统。
背景技术：
将成本较低的HFC网络(混合光纤同轴电缆网)应用到视频点播网络 中，将使运营商将更加有效地利用现有的HFC网络资源，以较低的代价在 HFC网络上实现交互数字电视业务，为扩展交互式数字电视业务提供多种 接入方案。在HFC的互动电视方案中，相对于IPTV (互联网电视)系统，引入 QAM设备(正交幅度调制转换设备)之后，STB (机顶盒)和边缘流媒体 服务引擎緩存之间的控制信息和视频流数据分别通过不同的通路传输。由 于上行的点播请求信息量极小，可以通过任何一种IP网络送到VOD (视 频点播)系统头端，下行的视频流则通过使用了 QAM设备的HFC网络送 达用户STB。QAM设备是一种能将数字媒体信号调制成射频信号在HFC网络上进 行传输的设备。QAM设备一般被部署在边缘节点，输入为IP数据，输出 为射频(RF)信号。基于HFC网络的视频点播网络与现行IPTV系统的区别是，STB的接 入认证、信息浏览等流程相同，通过IP网络交互，当用户的点播请求被重 定向到边缘流服务器后，流服务器并不直接把视频流通过IP网络传输给 STB,而是将视频流以恰当的封包形式输出至QAM设备，QAM将视频流 i周制成射步页(RF， Radio Frequency),通过HFC网纟各传^r给STB， STB 对视频流进行解调和解码。由于HFC网络是以射频RF传输信号，同时在基于HFC网络的视频 点播系统中引入了 QAM设备，为了适应QAM设备的传输特性，更好地利
用HFC网络的资源、提高带宽的利用率以及视频流播放的速度，需要对所 传输的数据格式进行定义，以最适合QAM设备和HFC网络传输的格式封 装数据。发明内容本发明的目的是提供一种适合QAM设备和HFC网络传输的数据封装 格式，具体地说，涉及在基于HFC网络的视频点播网络中的流媒体封包解 包方法及系统。根据本发明的第 一方面，提供一种视频点播网络的流媒体封包解包方 法，所述视频点播网络是基于HFC网络的视频点播网络，STB通过HFC 网络和QAM设备连接到主干网，由HFC网络向STB提供服务，所述流 媒体封包解包方法包括将通过视频/音频信号编码而成的数字信号封装成TS流(传输码流) 格式，并加上TS包头；将TS流封装成UDP4各式，并加上UDP和TCP/IP包头，通过主干网 传送给QAM设备；QAM设备将去除UDP和TCP/IP包头，从UDP格式中提取TS流， 并通过射频RF信号传输给HFC网络；HFC网络将TS流以射频RF信号的形式传输给STB;STB将TS流还原成数字信号，并有STB中的解码芯片将数字信号解 码成视频/音频信号。根据本发明的一实施例，流媒体数据为视频/音频信号通过MPEG 4编 码而成时，该方法还包括将通过视频/音频信号编码而成的数字信号封装成RTP/RTCP(实时传 输协议/实时传输控制协议)格式，加上RTP/RTCP包头，再将RTP/RTCP 包封装成TS格式；以及STB先将TS流还原成RTP/RTCP格式，再进一步还原成数字信号， 并由STB中的解码芯片将数字信号解码成视频/音频信号。较佳的，同一个RTP/RTCP包的数据被拆分到一个或数个TS包中，
所述RTP/RTCP格式中包括嵌入标示头，用于识别位于不同的TS包中的 属于同一个RTP/RTCP包的数据。根据本发明的一实施例，将视频/音频数据编码成为RTP/RTCP数据 包，长度最大不超过1416字节；所迷RTP/RTCP包中的数据分別属于不同音频和/或视频轨道，每个 RTP/RTCP包包括4个字节的嵌入标示头，用于标识RTP/RTCP包所属 的音频和/或视频轨和记录RTP/RTCP包的长度；所述RTP/RTCP包拆分到多个TS数据包中，并且在RTP/RTCP头 所在的TS数据包头上置起始标志；将TS数据包封装到UDP数据包中时，每个UDP数据包承载的TS 包为1 ~7个。较佳的，所述方法还包括，码流控制步骤，使码流趋于平滑，该步骤 包括限速控制步骤，引入一个拥塞窗口，记录当前时间片已发送的数据量， 对每个时间片内发送的数据进行限制，当新的时间片到来时，拥塞窗口将 被清空，从前开始累加发送的数据量，当某一段码流过大拥塞窗口被填满 时，将停止发包，到下一个时间片再尝试进行发送；加速控制步骤，再引入一个预緩存prebuffer，表示在发包过程中可以 提前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量 时，将在带宽允许的条件下以最大值发送，直到进度超前达到或超过 prebuffer。所述限速控制步骤优先于所述加速控制步骤，只有在限速控制步骤允 许发送的前提下才运作加速控制步骤。根据本发明的第二方面，提供一种视频点播网络的流媒体封包解包系 统，所述视频点播网络是基于HFC网络的视频点播网络，STB通过HFC 网络和QAM设备连接到主干网，由HFC网络向STB提供服务，所述流 媒体封包解包系统包括TS封包装置，将通过视频/音频信号编码而成的数字信号封装成TS流 格式，并加上TS包头；
UDP封包装置，连接于所述TS流封包装置，还连接于主干网，将TS 流封装成UDP格式，并加上UDP和TCP/IP包头，通过主干网传送给QAM 设备；UDP解包装置，位于QAM设备中，去除UDP和TCP/IP包头，从 UDP格式中提取TS流，并通过射频RF信号传输给HFC网络，HFC网 络将TS流以射频RF信号的形式传输给STB;TS解包装置，位于所述STB中，将TS流还原成数字信号，并有STB 中的解码芯片将数字信号解码成视频/音频信号。根据本发明的一实施例，所述流媒体数据为视频/音频信号通过MPEG 4编码而成时，该系统还包括RTP/RTCP封包装置，连接所述TS封包装置，将通过视频/音频信号 编码而成的数字信号封装成RTP/RTCP格式，加上RTP/RTCP包头，再 将RTP/RTCP包传输给TS封包装置封装成TS格式；以及RTP/RTCP解包装置，位于STB中，连接所述TS解包装置，先将 TS流还原成RTP/RTCP格式，再进一步传输给TS解包装置还原成数字 信号，并由STB中的解码芯片将数字信号解码成视频/音频信号。较佳的，同一个RTP/RTCP包的数据被拆分到一个或数个TS包中， 所述RTP/RTCP格式中包括嵌入标示头，用于识别位于不同的TS包中的 属于同一个RTP/RTCP包的数据。根据本发明的一实施例，RTP/RTCP封包装置将视频/音频数据编码成 为RTP/RTCP数据包，长度最大不超过1416字节；所述RTP/RTCP包中的数据分别属于不同音频和/或视频轨道，每个 RTP/RTCP包包括4个字节的嵌入标示头，用于标识RTP/RTCP包所属 的音频和/或视频轨和记录RTP/RTCP包的长度；TS封包装置将RTP/RTCP包拆分到多个TS数据包中，并且在 RTP/RTCP头所在的TS数据包头上置起始标志；UDP封包装置将TS数据包封装到UDP数据包中时，每个UDP数据 包承载的TS包为1 ~7个。较佳的，所述系统还包括，码流控制装置，使码流趋于平滑，该装置
包括限速控制装置，设定一个拥塞窗口，记录当前时间片已发送的数据量， 对每个时间片内发送的数据进行限制，当新的时间片到来时，拥塞窗口将 被清空，从前开始累加发送的数据量，当某一段码流过大拥塞窗口被填满 时，将停止发包，到下一个时间片再尝试进行发送；加速控制装置，设定一个预緩存prebuffer,表示在发包过程中可以提 前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量时， 将在带宽允许的条件下以最大值发送，直到进度超前达到或超过prebuffer;所述限速控制装置优先于所述加速控制装置，只有在限速控制装置允 许发送的前提下才运作加速控制装置。采用本发明的技术方案，充分考虑了 QAM设备和HFC网络的传输特 性，能更好地利用HFC网络的资源、提高带宽的利用率以及视频流播放的 速度。
本发明的上述的以及其他的特征、性质和优势将通过下面结合附图和 实施例的描述而变得更加明显，在附图中相同的附图标记始终表示相同的 特征，其中图1是应用本发明的流媒体封包解包技术的基于HFC网络的视频点播系统的结构框图；图2是根据本发明的 一 实施例的流媒体封包解包系统的结构框图； 图3是根据本发明的一实施例对MPEG 4格式数据的流媒体封包解包流程；图4是根据本发明的一 实施例对MPEG 2格式数据的流媒体封包解包 流程；；图5是根据本发明的一实施例对MPEG 4格式数据的流媒体封包结构图；图6是根据本发明的一实施例RTP/RTCP包中嵌入标示头的结构图； 图7是根据本发明的一实施例拆分RTP/RTCP包至不同的TS包的示
意图；图8是根据本发明的 一 实施例的流媒体封包解包流程的流程图。
具体实施方式
下面结合附图和实施例进一步说明本发明的技术方案。 基于HFC网络的视频点播系统图1是应用本发明的流媒体封包解包技术的基于HFC网络的视频点播 系统的结构框图，如图1所示，该视频点播系统100包括基于IP的主干网102,本发明的负载均衡系统就是应用于该IP的主 干网，比如CDN网络(内容分发网络)102中；边缘流媒体服务引擎104以及边缘流媒体服务引擎緩存105，连接到 基于IP的主干网102，从主干网102接收数据；QAM设备106，连接到边缘流媒体服务引擎104，接收来自边缘流媒 体服务引擎104的数据；HFC网络108,通过射频链路与QAM设备106相连；STB110，通过射频链路与HFC网络108相连；任何一种的IP网络112，连接在边缘流媒体服务引擎104和STB 110 之间，执行IP协议连接。在基于HFC网络的视频点播系统方案中，相对于IPTV系统，引入 QAM设备106之后，STB 110和边缘流媒体服务引擎104及其緩存105 之间的控制信息和视频流数据分别通过不同的通路传输。由于上行的点播 请求信息量极小，可以通过任何一种IP网络112送到VOD头端'即边缘 流媒体服务引擎104及其緩存105，下行的视频流则通过QAM设备106 和HFC网络108送达STB 110。QAM设备106是一种能将数字媒体信号调制成射频信号在HFC网络 108上进行传输的设备。QAM设备106 —般被部署在边缘节点，输入为IP 数据，输出为RF信号。该系统100与现行IPTV系统的区别是，STB的接入认证、信息浏览
等流程相同，通过IP网络交互，当用户的点播请求被重定向到边缘流服务器后，流服务器并不直接把视频流通过IP网络传输给STB,而是将视频流 以恰当的封包形式输出至QAM设备，QAM将视频流调制成射频RF(Radio Frequency),通过HFC网络传输给STB， STB对视频流进行解调和解码。 由于在该视频点播系统中增加了 QAM设备，为了适应QAM设备传输 的要求，需使用恰当的封包形式对媒体流进行传输，且对于不同编码格式 的节目需要分别考虑。通常，两种最常用的编码格式是MPEG2和MPEG 4。对于MPEG2格式节目，采用直接封装成TS流的方式传输，这样的 传输方式对终端的要求最低，只要能够收看DVB节目的STB,就可以对 节目进行接受和解码。但是考虑到节约带宽和存储， 一般不采用MPEG2 来实现视频点播。目前的情况是将MPEG 2信号封包成RTP over TS的方 式，再进行传输。对于MPEG4/H.264编码的节目，根据终端解码方式的不同，有两种 封包形式可以选择。包括采用RTP over TS的方式进行传输和采用 MPEG4/H.264 over TS的方式进行封装。目前采用的是RTP over TS的方式。流媒体封包解包系统根据本发明，首先提供一种视频点播网络的流媒体封包解包系统，该 视频点播网络是基于HFC网络的视频点播网络，STB通过HFC网络和 QAM设备连接到主干网，由HFC网络向STB提供服务，参考图2所示， 图2是根据本发明的一实施例的流媒体封包解包系统200的结构框图，该 流媒体封包解包系统200包括TS封包装置202,将通过视频/音频信号编码而成的数字信号封装成 TS流格式，并加上TS包头；TS封包装置202通常是位于提供视频/音频 节目的内容服务器上，由于该服务器通常都是连接于主干网102，因此在 图2中TS封包装置202被示为连接到主干网102 (通过下面将要描述的 UDP封包装置204)。UDP封包装置204,连接于TS流封包装置202，还连接于主干网102， 将TS流封装成UDP格式，并加上UDP和TCP/IP包头，通过主干网102 传送给QAM设备106。需要说明，通常，QAM设备106是通过边缘流媒 体服务引擎104和边缘流媒体服务引擎緩存105连接到主千网102的，在 此不详细"i兑明。UDP解包装置206，位于QAM设备106中，图2中示为连接于QAM 设备106,在实际的应用中，UDP解包装置206可以与QAM设备106集 成在一起，也可以是分开的。UDP解包装置206去除UDP和TCP/IP包 头，从UDP格式中提取TS流，并通过射频RF信号传输给HFC网络108， HFC网络108将TS流以射频RF信号的形式传输给STB 110。TS解包装置208，位于STB110中，图2中示为连接于STB 110， 在实际的应用中，TS解包装置208可以与STB 110集成在一起，也可以 是分开的，TS解包装置208将TS流还原成数字信号，并有STB 110中 的解码芯片(未示出，对于本领域技术人员来说，STB110包含解码芯片 是公知的技术)将数字信号解码成视频/音频信号。根据图2所示的实施例，对于流媒体数据为视频/音频信号通过MPEG 4编码而成的情况，该系统200还包括RTP/RTCP封包装置201，连接TS封包装置202，将通过视频/音频 信号编码而成的数字信号封装成RTP/RTCP格式，加上RTP/RTCP包头， 再将RTP/RTCP包传输给TS封包装置202封装成TS格式；以及RTP/RTCP解包装置209,位于STB110中，连接TS解包装置208， 先将TS流还原成RTP/RTCP格式，再进一步传输给TS解包装置208还 原成数字信号，并由STB 110中的解码芯片将数字信号解码成视频/音频信 号。MPEG 2和MPEG 4编码格式数据处理上面说了，两种最常用的编码格式是MPEG2和MPEG4。下面针对 这两种编码格式的数据分别进行描述。首先，对于MPEG 2编码格式，图4是根据本发明的一实施例对MPEG 2格式数据的流媒体封包解包流程。MPEG2格式节目，采用直接封装成 TS流的方式传输，这样的传输方式对终端的要求最低，只要能够收看DVB 节目的STB，就可以对节目进行接受和解码。但是考虑到节约带宽和存储， 一般不采用MPEG2来实现视频点播。目前的情况是将MPEG2信号封包 成RTP overTS的方式，再进行传输。如图4所示，封包/解包的流程大致 如下首先，在存储设备，比如内容服务器或者连接着主干网的其他设备上， 文件以MPEG 2的文件格式存放。之后，TS封包装置(比如位于流媒体服务器中)读取文件数据并封装 成TS包方式，再由UDP封包装置加上UDP包头和TCP/IP包头，并通过 主干网络发送给QAM设备。UDP解包装置(例如位于QAM设备中)进行UDP解包将TS包取出 并解调制成Radio Frequency信号通过HFC网络传输给STB,在QAM设 备处，数据又恢复成了 TS流的形式。STB接收到TS数据后由TS解包装置对其进行TS解包并进行解码播 放，在图中，STB处的数据仍然被示为TS流的形式。对于MPEG4/H.264编码的节目，根据终端解码方式的不同，有两种 封包形式可以选择。包括采用RTP over TS的方式进行传输和采用 MPEG4/H.264 over TS的方式进行封装。目前釆用的是RTP over TS的 方式。下面就以RTP over TS为例进行说明。参考图3,图3是根据本发 明的一实施例对MPEG 4格式数据的流媒体封包解包流程首先，在存储设备，比如内容服务器或者连接着主干网的其他设备上， 文件以MPEG 4文件格式存放。RTP/RTCP封包装置(比如位于流媒体服务器中)读取文件，先封装 成RTP/RTCP格式，然后传输给TS封包装置加上TS的包头，再传输给 UDP封包装置加上UDP包头和TCP/IP包头，然后通过主干网发送给QAM 设备。UDP解包装置(位于QAM设备中)进行UDP解包将TS数据取出并 调制成Radio Frequency信号通过HFC网络传输给STB; STB接收到TS数据后，由TS解包装置将TS包头数据去捽，取出 TS的承载信息也就是RTP/RTCP包数据，提供给STB中的RTP/RTCP解包装置。STB中的RTP/RTCP解包装置对RTP/RTCP包数据信息处理，解出 MPEG 4格式的数据，最后再由解码芯片对音视频数据进行解码播放。封包格式和拆分提供给QAM设备的数据包为UDP包。UDP包内承载着传输流TS数 据包，每个UDP包内TS包为1 7个不等。TS数据流内承载了 RTP/RTCP 包，RTP/RTCP包内承载经编码(MPEG 2或者MPEG 4编码)后的视频 /音频格式数据。根据本发明的一实施例，MPEG 4编码格式数据的封包格 式如下，参考图5，图5是根据本发明的一实施例对MPEG 4格式数据的 流媒体封包结构图，结构如下IP头(IP Header) 、 UDP头(UDP Header) 、 TS头部(TS Header)、 RTP/RTCP头(RTP Header) 、 MPEG 4格式信号承栽(Payload MPEG 4/H.264)。考虑到QAM设备和HFC网络的传输特性，同时在单个基本码流ES 中传输属于不同内容的音频视频的RTP/RTCP包是比较好的，比如在单个 ES传输四个流的数据包。为了区分这些分属不同内容的RTP/RTCP,在 RTP/RTCP包前加了一个嵌入标示头，比如4个字节的Embedded Binary 头，通过包括在其中的通道ID来区分这些流，并通过长度字节Length为 RTP/RTCP在重组过程提供完整性的检查。这样，同一个RTP/RTCP包的数据被拆分到一个或数个TS包中， RTP/RTCP格式中包括嵌入标示头，用于识别位于不同的TS包中的属于 同一个RTP/RTCP包的数据。上面所述的嵌入标示头的一个实例Embedded Binary头的格式如下， 如图6所示，图6是根据本发明的一实施例RTP/RTCP包中嵌入标示头， 即Embedded Binary头的结构图，该Embedded Binary头包括1个字节 的起始符"$"; 1个字节的通道ID; 2个字节的长度字节Length。由于同一个RTP/RTCP包的数据被拆分到一个或数个TS包中，就需要通过如下的处理过程RTP/RTCP封包装置将视频/音频数据编码成为RTP/RTCP数据包； RTP/RTCP包中的数据分别属于不同音频和/或视频轨道，每个RTP/RTCP包包括4个字节的嵌入标示头，比如Embedded Binary头，用于标识RTP/RTCP包所属的音频和/或视频轨和记录RTP/RTCP包的长度；TS封包装置将RTP/RTCP包拆分到多个TS数据包中，并且在 RTP/RTCP头所在的TS数据包头上置起始标志；UDP封包装置将TS数据包封装到UDP数据包中时，每个UDP数据 包承载的TS包为1 ~7个。图7是根据本发明的一实施例拆分RTP/RTCP包至不同的TS包的示 意图；参考图7所示的实施例，具体的封包步骤包括RTP/RTCP封包装置将视频/音频数据编码成为RTP/RTCP数据包长 度最大不超过1416;这些RTP/RTCP包数据分别属于不同的轨道Track (包括音频和视 频)，因此在每个RTP/RTCP数据包前加上4个字节的Embedded Binary 头，用于标识RTP/RTCP所属的Track和记录RTP/RTCP包的长度。将这些RTP/RTCP包拆分到多个TS数据包中，并且在RTP/RTCP 头所在的TS凄U居包头上置起始标志，比如Start_Unit—Indicate标志。需 要说明的是，参考图7所示，RTP/RTCP包前部的交错头部(Interleave Head)也作为RTP/RTCP包的一部分一同被拆分到多个TS数据包中。最后将TS数椐包封装到UDP数据包中，每个UDP数据包承载的TS 包为1 ~7个不等。码流控制由于QAM设备对码流变化的适应能力相对较弱，而现阶段片源的码
率变化又不太平稳。因此流媒体依靠传统以太网上的发包策略往往会导致某个时刻发包过快，QAM设备緩存不足而导致溢出(Overflow)。针对这种情况，需要在传送流媒体时对每个点播流的码流动态的进行 控制，使码流尽可能平稳，而减少或消除QAM设备的溢出(Overflow) 异常。由此，参考图2所示的系统200，在QAM设备106之前增加了如下 的两个装置限速控制装置210，限速控制装置210设定一个拥塞窗口，记录当前 时间片已发送的数据量，对每个时间片内发送的数据进行限制，当新的时 间片到来时，拥塞窗口将被清空，从前开始累加发送的数据量，当某一段 码流过大拥塞窗口被填满时，将停止发包，到下一个时间片再尝试进行发 送；加速控制装置212，设定一个预緩存prebuffer，表示在发包过程中可 以提前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量 时，将在带宽允许的条件下以最大值发送，直到进度超前达到或超过 prebuffer。限速控制装置210优先于加速控制装置212，只有在限速控制装置210 允许发送的前提下才运作加速控制装置212。这样，限速控制装置210和加速控制装置212主要从两方面入手，使 码流趋于平滑。首先是限速控制装置210的限速控制，通过引入一个拥塞 窗口，记录当前时间片已发送的数据量，对每个时间片内发送的数据进行 限制。新的时间片到来时，拥塞窗口将被清空，从前开始累加发送的数据 量。当片源某一段码流过大拥塞窗口被填满时，将停止发包，到下一个时 间片再尝试进行发送。这样就能限制住码流的峰值，不出现剧烈的码流波 动。但这种控制算法可能降低发包速率，可能使终端的緩存数量减少，甚 至消耗光。需要通过加速控制装置212的加速控制算法的配合才能防止这 类情况的出现。加速控制再引入一个预緩存prebuffer，表示在发包过程中 可以提前发送的最大数据。当发送的进度超前还没有达到prebuffer指定的 量时，将在带宽允许的条件下尽力发送(以最大值发送)，直到进度超前 达到或超过prebuffer。这样在码流不大时，可以多发送一些后续prebuffer 范围内的数据，当码流变大时，降速终端的缓存也不会很快就消耗光。同 时在点播启动阶段通过这种加速能缩短启动时间，提供较好的用户体验效 果。这两种控制，限速控制是优先考虑的，只有在限速控制允许发送的前 提下加速控制才有可能运作。通过这一对限速控制和加速控制算法，就能 在一定范围能使码流变化相对剧烈的片源输出码流相对平稳，趋向于固定 码率。流媒体封包解包方法根据本发明的第二方面，还提供一种视频点播网络的流媒体封包解包 方法，所述视频点播网络是基于HFC网络的视频点播网络，STB通过HFC 网络和QAM设备连接到主干网，由HFC网络向STB提供服务，参考图8， 图8是根据本发明的一实施例的流媒体封包解包流程的流程图，该流媒体 封包解包方法800包括802.将通过视频/音频信号编码而成的数字信号封装成TS流格式， 并加上TS包头；804.将TS流封装成UDP格式，并加上UDP和TCP/IP包头，通过 主干网传送给QAM设备；806, QAM设备将去除UDP和TCP/IP包头，从UDP格式中提取TS 流，并通过射频RF信号传输给HFC网络；808. HFC网络将TS流以射频RF信号的形式传输给STB;810. STB将TS流还原成MPEG4或MPEG2格式的数字信号，并 由STB中的解码芯片将MPEG4或MPEG 2格式的数字信号解码成视频/ 音频信号。继续参考图8,其中还包括如下的步骤，专门用于流媒体数据为视频/ 音频信号通过MPEG 4编码而成时的情况，这些步骤包括801.将通过视频/音频信号编码而成的数字信号封装成RTP/RTCP格 式，加上RTP/RTCP包头，再将RTP/RTCP包封装成TS格式；以及 809. STB先将TS流还原成RTP/RTCP格式，再进一步还原成MPEG4格式的数字信号，并由STB中的解码芯片将MPEG4格式的数字信号解码 成视频/音频信号。根据本发明的实施例，同一个RTP/RTCP包的数据被拆分到一个或数 个TS包中，RTP/RTCP格式中包括嵌入标示头，用于识别位于不同的TS 包中的属于同一个RTP/RTCP包的数据。包括如下的过程将视频/音频数据编码成为RTP/RTCP数据包，长度最大不超过1416字节；RTP/RTCP包中的数据分别属于不同音频和/或視频轨道，每个 RTP/RTCP包包括4个字节的嵌入标示头，用于标识RTP/RTCP包所属 的音频和/或视频轨和记录RTP/RTCP包的长度；RTP/RTCP包拆分到多个TS数据包中，并且在RTP/RTCP头所在的 TS数据包头上置起始标志；将TS数据包封装到UDP数据包中时，每个UDP数据包承载的TS 包为1 ~7个。为了使码流趋于平滑，本发明还包括码流控制步骤，该步骤包括 限速控制步骤，引入一个拥塞窗口，记录当前时间片已发送的数据量， 对每个时间片内发送的数据进行限制，当新的时间片到来时，拥塞窗口将 被清空，从前开始累加发送的数据量，当某一段码流过大拥塞窗口被填满时，将停止发包，到下一个时间片再尝试进行发送；加速控制步骤，再引入一个预緩存prebuffer，表示在发包过程中可以 提前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量 时，将在带宽允许的条件下以最大值发送，直到进度超前达到或超过 prebuffer;限速控制步骤优先于所述加速控制步骤，只有在限速控制步骤允许发 送的前提下才运作加速控制步骤。流媒体封包解包方法的细节部分和上述的流媒体封包解包系统一致， 因此这里就不再详细说明。
采用本发明的技术方案，充分考虑了 QAM设备和HFC网络的传输特 性，能更好地利用HFC网络的资源、提高带宽的利用率以及视频流播放的 速度。上述实施例是提供给熟悉本领域内的人员来实现或使用本发明的，熟 悉本领域的人员可在不脱离本发明的发明思想的情况下，对上述实施例做 出种种修改或变化，因而本发明的保护范围并不被上述实施例所限，而应 该是符合权利要求书提到的创新性特征的最大范围。
权利要求
1. —种^L频点4番网络的流i某体封包解包方法，其特征在于，所迷^L频 点播网络是基于HFC网络的视频点播网络，STB通过HFC网络和QAM 设备连接到主干网，由HFC网络向STB提供服务，所述流媒体封包解包 方法包括将通过视频/音频信号编码而成的数字信号封装成TS流格式，并加上 TS包头；将TS流封装成UDP格式，并加上UDP和TCP/IP包头，通过主干网 传送给QAM设备；QAM设备将去除UDP和TCP/IP包头，从UDP格式中提取TS流， 并通过射频RF信号传输给HFC网络；HFC网络将TS流以射频RF信号的形式传输给STB;STB将TS流还原成数字信号，并有STB中的解码芯片将数字信号解 码成视频/音频信号。
2. 如权利要求1所述的流媒体封包解包方法，其特征在于，所述流媒 体数据为视频/音频信号通过MPEG 4编码而成时，所述方法还包括将通过视频/音频信号编码而成的数字信号封装成RTP/RTCP格式， 加上RTP/RTCP包头，再将RTP/RTCP包封装成TS格式；以及STB先将TS流还原成RTP/RTCP格式，再进一步还原成数字信号， 并由STB中的解码芯片将数字信号解码成视频/音频信号。
3. 如权利要求2所述的流媒体封包解包方法，其特征在于，同一个 RTP/RTCP包的数据被拆分到一个或数个TS包中，所述RTP/RTCP格式 中包括嵌入标示头，用于识别位于不同的TS包中的属于同 一 个RTP/RTCP包的数据。
4. 如权利要求3所述的流媒体封包解包方法，其特征在于， 将视频/音频数据编码成为RTP/RTCP数据包，长度最大不超过1416字节；所述RTP/RTCP包中的数据分别属于不同音频和/或视频轨道，每个 RTP/RTCP包包括4个字节的嵌入标示头，用于标识RTP/RTCP包所属 的音频和/或视频轨和记录RTP/RTCP包的长度；所述RTP/RTCP包拆分到多个TS数据包中，并且在RTP/RTCP头 所在的TS数据包头上置起始标志；将TS数据包封装到UDP数据包中时，每个UDP数据包承载的TS 包为1 ~7个。
5. 如权利要求4所述的流媒体封包解包方法，其特征在于，所迷方法 还包括，码流控制步骤，使码流趋于平滑，该步骤包括限速控制步骤，引入一个拥塞窗口，记录当前时间片已发送的数据量， 对每个时间片内发送的数据进行限制，当新的时间片到来时，拥塞窗口将 被清空，从前开始累加发送的数据量，当某一段码流过大拥塞窗口被填满 时，将停止发包，到下一个时间片再尝试进行发送；加速控制步骤，再引入一个预緩存prebuffer,表示在发包过程中可以 提前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量 时，将在带宽允许的条件下以最大值发送，直到进度超前达到或超过 prebuffer;所述限速控制步骤优先于所述加速控制步骤，只有在限速控制步骤允 许发送的前提下才运作加速控制步骤。
6. —种视频点播网络的流媒体封包解包系统，其特征在于，所述视频 点播网络是基于HFC网络的视频点播网络，STB通过HFC网络和QAM 设备连接到主干网，由HFC网络向STB提供服务，所述流媒体封包解包 系统包括TS封包装置，将通过视频/音频信号编码而成的数字信号封装成TS流 格式，并加上TS包头； UDP封包装置，连接于所述TS流封包装置，还连接于主干网，将TS 流封装成UDP格式，并加上UDP和TCP/IP包头，通过主干网传送给QAM 设备；UDP解包装置，位于QAM设备中，去除UDP和TCP/IP包头，从 UDP格式中提取TS流，并通过射频RF信号传输给HFC网络，HFC网 络将TS流以射频RF信号的形式传输给STB;TS解包装置，位于所述STB中，将TS流还原成数字信号，并有STB 中的解码芯片将数字信号解码成视频/音频信号。
7. 如权利要求6所述的流媒体封包解包系统，其特征在于，所述流媒 体数据为视频/音频信号通过MPEG 4编码而成时，所述系统还包括RTP/RTCP封包装置，连接所述TS封包装置，将通过视频/音频信号 编码而成的数字信号封装成RTP/RTCP格式，力n上RTP/RTCP包头，再 将RTP/RTCP包传输给TS封包装置封装成TS格式；以及RTP/RTCP解包装置，位于STB中，连接所迷TS解包装置，先将 TS流还原成RTP/RTCP格式，再进一步传输给TS解包装置还原成数字 信号，并由STB中的解码芯片将数字信号解码成视频/音频信号。
8. 如权利要求7所述的流媒体封包解包系统，其特征在于，同一个 RTP/RTCP包的数据被拆分到一个或数个TS包中，所述RTP/RTCP格式 中包括嵌入标示头，用于识别位于不同的TS包中的属于同 一个RTP/RTCP包的数据。
9. 如权利要求8所述的流媒体封包解包系统，其特征在于， RTP/RTCP封包装置将视频/音频数据编码成为RTP/RTCP数据包，长度最大不超过1416字节；所述RTP/RTCP包中的数据分别属于不同音频和/或视频轨道，每个 RTP/RTCP包包括4个字节的嵌入标示头，用于标识RTP/RTCP包所属 的音频和/或视频轨和记录RTP/RTCP包的长度； TS封包装置将RTP/RTCP包拆分到多个TS数据包中，并且在 RTP/RTCP头所在的TS数据包头上置起始标志；UDP封包装置将TS数据包封装到UDP数据包中时，每个UDP数椐 包承载的TS包为1 ~7个。
10.如权利要求9所述的流媒体封包解包系统，其特征在于，所述系 统还包括，码流控制装置，使码流趋于平滑，该装置包括限速控制装置，设定一个拥塞窗口，记录当前时间片已发送的数据量， 对每个时间片内发送的数据进行限制，当新的时间片到来时，拥塞窗口将 被清空，从前开始累加发送的数据量，当某一段码流过大拥塞窗口被填满 时，将停止发包，到下一个时间片再尝试进行发送；加速控制装置，设定一个预緩存prebuffer,表示在发包过程中可以提 前发送的最大数据，当发送的进度超前还没有达到prebuffer指定的量时， 将在带宽允许的条件下以最大值发送，直到进度超前达到或超过prebuffer;所述限速控制装置优先于所述加速控制装置，只有在限速控制装置允 许发送的前提下才运作加速控制装置。
全文摘要
本发明揭示了一种视频点播网络的流媒体封包解包方法，该视频点播网络是基于HFC网络的视频点播网络，STB通过HFC网络和QAM设备连接到主干网，由HFC网络向STB提供服务，流媒体封包解包方法包括将通过视频/音频信号编码而成的数字信号封装成TS流格式，并加上TS包头；将TS流封装成UDP格式，并加上UDP和TCP/IP包头，通过主干网传送给QAM设备；QAM设备将去除UDP和TCP/IP包头，从UDP格式中提取TS流，并通过射频RF信号传输给HFC网络；HFC网络将TS流以射频RF信号的形式传输给STB；STB将TS流还原成数字信号，并有STB中的解码芯片将数字信号解码成视频/音频信号。本发明还揭示了一种视频点播网络的流媒体封包解包系统。
文档编号H04N7/173GK101146212SQ200610030998
公开日2008年3月19日 申请日期2006年9月11日 优先权日2006年9月11日
发明者华 何, 建 姚, 姜海曙, 李海刚, 李雪群 申请人:思华科技(上海)有限公司