Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND SYSTEM FOR SENDING MULTICAST JOIN REQUEST IN ADVANCE DURING FAST CHANNEL CHANGE
Document Type and Number:
WIPO Patent Application WO/2012/113212
Kind Code:
A1
Abstract:
Disclosed are a method and system for sending a multicast join request in advance during fast channel change, for overcoming the defect that the processing capability of the fast channel change server is wasted as the unicast/multicast change mechanism in the existing fast channel change technology does not take into account the processing time overhead of the data device in processing a multicast join request. The time for pre-sending the multicast join request during the fast channel change process is taken into account, thus shortening the time for the server to send unicast code streams, saving the processing capability, and reducing the deployment cost.

Inventors:
ZHU XIAOBIN (CN)
Application Number:
PCT/CN2011/078939
Publication Date:
August 30, 2012
Filing Date:
August 25, 2011
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ZTE CORP (CN)
ZHU XIAOBIN (CN)
International Classes:
H04N21/266
Foreign References:
CN101924910A2010-12-22
Other References:
HUAWEI TECHNOLOGIES: "Improved rapid acquisition of multicast sessions", ENGINEERING TASK FORCE, 26 October 2009 (2009-10-26), Retrieved from the Internet [retrieved on 20111112]
MICROSOFT CORPORATION.: "Unicast-Based Rapid Acquisition of Multicast RTP", ENGINEERING TASK FORCE, 18 November 2010 (2010-11-18), Retrieved from the Internet [retrieved on 20111112]
Attorney, Agent or Firm:
CHINA PAT INTELLECTUAL PROPERTY OFFICE (CN)
北京派特恩知识产权代理事务所(普通合伙) (CN)
Download PDF:
Claims:
权利要求书

1、 在快速频道切换时预先发送加入组播请求的方法, 包括: 搜集数据设备处理加入组播请求的处理时间开销, 计算单播与组播码 流同步的时间 , 计算客户端预先发出加入组播请求的时刻。

2、 根据权利要求 1所述的方法, 其中,

所述搜集方法为以下至少之一; 并且在获得多个不同的数值时, 采用 包括取最小值或平均值在内的统计学方法得到单一的数值, 作为组播请求 处理延时:

实时统计; 客户端在正常工作时, 计算其自身每次从发送加入组播请 求到接收到组播码流之间的时间间隔;

实验分析; 使用支持组播功能的网络主机进行实验, 测量其从发送加 入组播请求到接收到组播码流之间的时间间隔;

经验估算; 综合包括历史数据、 实验结果、 设备型号、 网络架构在内 的因素, 进行合理估计;

所述计算单播与组播码流同步的时间的方法为:

TSync-PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为某一时 刻服务器已发送的单播媒体包和其已接收的组播媒体包之间相隔的数据 量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为某媒体 包从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的 比例;

所述计算客户端预先发出加入组播请求的时刻的方法为: TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时。

3、 在快速频道切换时预先发送加入组播请求的方法, 包括: 将组播请求处理延时通知到服务器, 服务器计算客户端预先发送加入 组播请求的时间, 服务器控制客户端预先发出加入组播请求。

4、 根据权利要求 3所述的方法, 其中,

所述通知的方法为: 由客户端保存组播请求处理延时数值, 通过通讯 链路发送给服务器; 将组播请求处理延时作为服务器的配置参数;

所述计算客户端预先发送加入组播请求的时间的方法为:

TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时;

所述服务器控制客户端预先发出加入组播请求的方法为:

服务器将计算得到的预先加入组播组的时刻通过通讯链路通知给客户 端, 客户端在预定的时刻发出加入组播请求; 或者,

服务器在预先加入组播组的时刻到达时通知客户端, 客户端收到通知 后立即发出加入组播请求。

5、 在快速频道切换时预先发送加入组播请求的方法, 包括: 将组播请求处理延时通知到客户端, 服务器计算单播与组播码流同步 的时间, 客户端预先发送加入组播请求。

6、 根据权利要求 5所述的方法, 其中,

所述将组播请求处理延时通知到客户端的过程中, 客户端直接保存结 果; 或者, 将組播请求处理延时作为客户端的配置参数;

所述服务器计算单播与组播码流同步的时间的方法为: TSync=PDif/(RUc-RMc) 公式 1 上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播媒体包之间相隔的数据量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例;

所述客户端预先发送加入组播请求的方法为:

服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给客 户端; 客户端计算预先发出加入组播请求的时间, 并在预先发出加入组播 请求的时刻到达时发出加入组播请求。

7、 在快速频道切换时预先发送加入组播请求的系统, 包括搜集单元、 计算单元; 其中,

所述搜集单元, 用于搜集数据设备处理加入组播请求的处理时间开销; 所述计算单元, 用于计算单播与组播码流同步的时间, 计算客户端预 先发出加入组播请求的时刻。

8、 根据权利要求 7所述的系统, 其中,

所述搜集单元在进行所述搜集时, 采用的搜集方法为以下至少之一; 并且在获得多个不同的数值时, 釆用包括取最小值或平均值在内的统计学 方法得到单一的数值, 作为组播请求处理延时:

实时统计; 在客户端正常工作时, 计算客户端每次从发送加入组播请 求到接收到组播码流之间的时间间隔;

实验分析; 使用支持组播功能的网络主机进行实验, 测量其从发送加 入组播请求到接收到组播码流之间的时间间隔;

经验估算; 综合包括历史数据、 实验结果、 设备型号、 网络架构在内 的因素, 进行合理估计;

所述计算单元在计算单播与组播码流同步的时间时, 用于:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播媒体包之间相隔的数据量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例;

所述计算单元在计算客户端预先发出加入組播请求的时刻时, 用于: TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时。

9、 在快速频道切换时预先发送加入组播请求的系统, 包括通知单元、 服务器、 客户端; 其中,

所述通知单元, 用于将组播请求处理延时通知到服务器;

所述服务器, 用于计算客户端预先发送加入组播请求的时间, 并且控 制客户端预先发出加入组播请求。

10、 根据权利要求 9所述的系统, 其中,

所述通知单元进行所述通知时, 用于: 触发客户端保存组播请求处理 延时数值, 通过通讯链路发送给服务器; 将组播请求处理延时作为服务器 的配置参数;

所述服务器计算客户端预先发送加入组播请求的时间时, 用于:

TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时;

所述服务器控制客户端预先发出加入组播请求时, 用于:

将计算得到的预先加入组播组的时刻通过通讯链路通知给客户端, 触 发客户端在预定的时刻发出加入组播请求; 或者,

在预先加入组播组的时刻到达时通知客户端, 触发客户端在收到通知 后立即发出加入组播请求。

11、 在快速频道切换时预先发送加入组播请求的系统, 包括通知单元、 服务器、 客户端; 其中,

所述通知单元, 用于将组播请求处理延时通知到客户端;

所述服务器, 用于计算单播与组播码流同步的时间;

所述客户端, 用于预先发送加入组播请求。

12、 根据权利要求 11所述的系统, 其中,

所述通知单元将組播请求处理延时通知到客户端的过程中, 客户端用 于直接保存结果; 或者, 将组播请求处理延时作为客户端的配置参数; 所述服务器计算单播与组播码流同步的时间时, 用于:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播媒体包之间相隔的数据量 , RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2 上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例;

所述客户端预先发送加入组播请求时, 用于:

在服务器将单播与组播码流同步时间的计算结果通过通讯链路发送给 客户端后, 计算预先发出加入组播请求的时间, 并在预先发出加入组播请 求的时刻到达时发出加入组播请求。

Description:
在快速频道切换时预先发送加入组播请求的方 法和系统 技术领域

本发明涉及通信领域, 具体涉及一种在快速频道切换时预先发送加入 组播请求的方法和系统。 背景技术

数字视频编码技术普遍采用帧间编码来提高压 缩率, 这就导致解码端 必须接收到 I帧 ( Intra Frame, 帧内编码帧)才能开始正确显示视频画面。 在 IPTV中倾向于采用组播技术传输直播码流,所 终端都共同接收同样的 一路码流。 当终端进行频道切换时, 其开始接收直播码流的时刻是随机的, 通常需要等待一段时间才能接收到 I 帧并显示视频画面, 这严重影响了 IPTV的频道切换速度。

已经有多种快速频道切换( Fast Channel Change, FCC )方案用于提升 IPTV 的频道切换速度, 目前的主流方案是釆用快速频道切换服务器( Fast Channel Change Server, FCC Server或 FCC服务器)对频道码流进行緩存, 在频道切换时采用单播方式向终端快速发送以 I帧开头的码流,终端接收后 迅速解码显示视频画面, 随后 FCC Server停止发送单播码流, 终端开始使 用组播码流进行解码。

在上述方案中, FCC Server停止发送单播码流和终端开始使用组播码 流解码的切换(后续简称为 "单播与组播切换")时机非常关键, 过早切换 可能接收不到足够的单播数据, 无法与组播数据衔接, 导致终端播放的视 频画面受损影响用户体验; 而过晚切换虽然不必担心单播与组播数据的衔 接, 但 FCC Server要发送较长时间的单播码流, 无形中浪费了 FCC Server 的处理能力, 增加了部署成本。 本文随后部分将支持快速频道切换的终端 称为快速频道切换客户端 ( Fast Channel Change Client, FCC Client或 FCC 客户端), 在不致引起混淆的情况下直接简称为 "客户端", 与此对应, 快 速频道切换服务器可被简称为 "服务器"。

目前, 可以由服务器以较高速度发送单播码流, 在单播码流与组播码 流同步 (即实现衔接 ) 时通知客户端请求加入组播组, 客户端在接收到组 播码流之后通知服务器停止发送单播码流。 在实际的 IPTV承载网中, 数据 设备处理加入组播组的请求需要消耗一定的时 间, 这就意味着客户端从发 送加入组播请求到接收到组播码流之间存在延 时间隔, 这个时间短则

300ms, 长则 700ms甚至更长, 而上述切换机制并未考虑这个时间开销, 则 在单播与组播码流同步之后服务器还要继续发 送数百毫秒的单播码流直到 客户端真正收到组播码流, 这显然浪费了服务能力。

在 IETF ( Internet Engineering Task Force 互联网工程任务组)草案 draft-ietf-avt-rapid-acquisition-for-rtp-17中,服务器 以计算出客户端请求加 入组播组的最早时间并传递给客户端, 客户端可以参考这个数据自行确定 请求加入组播组的时间, 至于如何得到 "请求加入组播组的最早时间" 的 数据以及客户端如何使用这个数据, 该文档并未给出实质性的说明。 发明内容

有鉴于此, 本发明的主要目的在于提供一种在快速频道切 换时预先发 送加入组播请求的方法和系统, 以缩短服务器发送单播码流的时间, 节约 处理能力。 为达到上述目的, 本发明的技术方案是这样实现的:

在快速频道切换时预先发送加入组播请求的方 法, 包括: 搜集数据设 备处理加入组播诸求的处理时间开销, 计算单播与组播码流同步的时间, 计算客户端预先发出加入组播请求的时刻。

所述搜集方法为以下至少之一; 并且在获得多个不同的数值时, 釆用 包括取最小值或平均值在内的统计学方法得到 单一的数值, 作为组播请求 处理延时:

实时统计; 客户端在正常工作时, 计算其自身每次从发送加入组播请 求到接收到组播码流之间的时间间隔;

实验分析; 使用支持组播功能的网络主机进行实验, 测量其从发送加 入组播请求到接收到组播码流之间的时间间隔 ;

经验估算; 综合包括历史数据、 实验结果、 设备型号、 网络架构在内 的因素, 进行合理估计;

所述计算单播与组播码流同步的时间的方法为 :

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为某一时 刻服务器已发送的单播媒体包和其已接收的组 播媒体包之间相隔的数据 量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为某媒体 包从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的 比例;

所述计算客户端预先发出加入组播请求的时刻 的方法为:

TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播诸求的相对时 间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时。

在快速频道切换时预先发送加入组播请求的方 法, 包括: 将组播请求 处理延时通知到服务器, 服务器计算客户端预先发送加入组播请求的时 间, 服务器控制客户端预先发出加入组播请求。

所述通知的方法为: 由客户端保存组播请求处理延时数值, 通过通讯 链路发送给服务器; 将组播请求处理延时作为服务器的配置参数; 所述计算客户端预先发送加入组播请求的时间 的方法为:

TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时 间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时;

所述服务器控制客户端预先发出加入组播请求 的方法为:

服务器将计算得到的预先加入组播组的时刻通 过通讯链路通知给客户 端, 客户端在预定的时刻发出加入组播请求; 或者,

服务器在预先加入组播组的时刻到达时通知客 户端, 客户端收到通知 后立即发出加入组播请求。

在快速频道切换时预先发送加入组播请求的方 法, 包括: 将组播请求 处理延时通知到客户端, 服务器计算单播与组播码流同步的时间, 客户端 预先发送加入组播请求。

所述将组播请求处理延时通知到客户端的过程 中, 客户端直接保存结 果; 或者, 将組播请求处理延时作为客户端的配置参数;

所述服务器计算单播与组播码流同步的时间的 方法为:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播 媒体包之间相隔的数据量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例; 所述客户端预先发送加入组播请求的方法为:

服务器将单播与组播码流同步时间的计算结果 通过通讯链路发送给客 户端; 客户端计算预先发出加入组播请求的时间, 并在预先发出加入组播 请求的时刻到达时发出加入组播请求。

在快速频道切换时预先发送加入组播请求的系 统, 包括搜集单元、 计 算单元; 其中,

所述搜集单元, 用于搜集数据设备处理加入组播请求的处理时 间开销; 所述计算单元, 用于计算单播与组播码流同步的时间, 计算客户端预 先发出加入组播请求的时刻。

所述搜集单元在进行所述搜集时, 采用的搜集方法为以下至少之一; 并且在获得多个不同的数值时, 采用包括取最小值或平均值在内的统计学 方法得到单一的数值, 作为组播请求处理延时:

实时统计; 在客户端正常工作时, 计算客户端每次从发送加入组播请 求到接收到组播码流之间的时间间隔;

实验分析; 使用支持组播功能的网络主机进行实验, 测量其从发送加 入组播请求到接收到组播码流之间的时间间隔 ;

经验估算; 综合包括历史数据、 实验结果、 设备型号、 网络架构在内 的因素, 进行合理估计;

所述计算单元在计算单播与组播码流同步的时 间时, 用于:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播 媒体包之间相隔的数据量 , RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2 上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例;

所述计算单元在计算客户端预先发出加入组播 请求的时刻时, 用于:

TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播诸求的相对时 间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时。

在快速频道切换时预先发送加入组播请求的系 统, 包括通知单元、 服 务器、 客户端; 其中,

所述通知单元, 用于将组播请求处理延时通知到服务器;

所述服务器, 用于计算客户端预先发送加入组播请求的时间 , 并且控 制客户端预先发出加入组播请求。

所述通知单元进行所述通知时, 用于: 触发客户端保存组播请求处理 延时数值, 通过通讯链路发送给服务器; 将组播请求处理延时作为服务器 的配置参数;

所述服务器计算客户端预先发送加入组播请求 的时间时, 用于: TReqMc=TSync-TMcDly 公式 3

上式中, TReqMc为客户端预先发出加入组播请求的相对时 间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时;

所述服务器控制客户端预先发出加入组播请求 时, 用于:

将计算得到的预先加入组播組的时刻通过通讯 链路通知给客户端, 触 发客户端在预定的时刻发出加入组播请求; 或者,

在预先加入组播组的时刻到达时通知客户端, 触发客户端在收到通知 后立即发出加入組播请求。

在快速频道切换时预先发送加入组播请求的系 统, 包括通知单元、 服 务器、 客户端; 其中,

所述通知单元, 用于将组播请求处理延时通知到客户端;

所述服务器, 用于计算单播与组播码流同步的时间;

所述客户端, 用于预先发送加入组播请求。

所述通知单元将组播请求处理延时通知到客户 端的过程中, 客户端用 于直接保存结果; 或者, 将组播请求处理延时作为客户端的配置参数; 所述服务器计算单播与组播码流同步的时间时 , 用于:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为一时刻 服务器已发送的单播媒体包和其已接收的组播 媒体包之间相隔的数据量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率; 将公式 1左边的除数和被除数同时除以 RMc, 得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为媒体包 从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率的比 例;

所述客户端预先发送加入组播请求时, 用于:

在服务器将单播与组播码流同步时间的计算结 果通过通讯链路发送给 客户端后, 计算预先发出加入组播请求的时间, 并在预先发出加入组播请 求的时刻到达时发出加入组播请求。

可见, 本发明方法和系统, 克服了现有快速频道切换技术中单播与组 播切换机制未考虑数据设备处理加入组播请求 的处理时间开销, 导致快速 频道切换服务器浪费处理能力的缺点, 考虑在频道快速切换过程中预先发 送加入组播请求的时间, 从而缩短服务器发送单播码流的时间, 节约处理 能力, 低部署成本。 附图说明

图 1为本发明预先发送加入组播请求的时间的计 方法示意图; 图 1为本发明计算在频道快速切换过程中预先发 加入组播请求的时 间的流程简图;

图 3 为本发明一实施例的在快速频道切换过程中预 先发送加入组播请 求的流程简图;

图 4为本发明另一实施例的在快速频道切换过程 预先发送加入组播 请求的流程简图;

图 5为本发明提供的两个实施例的部署模型示意 ;

图 6为本发明实施例一快速频道切换过程的流程 ;

图 Ί为本发明实施例二快速频道切换过程的流程 。 具体实施方式

为了克服现有快速频道切换技术中单播与组播 切换机制未考虑数据设 备处理加入组播请求的处理时间开销, 导致快速频道切换服务器浪费处理 能力的缺点, 可以考虑在频道快速切换过程中预先发送加入 组播请求的时 间, 从而缩短服务器发送单播码流的时间, 节约处理能力, P 低部署成本。

本发明所述计算在频道快速切换过程中预先发 送加入组播请求的时间 的方法^口下:

第一步、 搜集数据设备处理加入组播请求的处理时间开 销 (以后简称 为 "组播请求处理延时"), 存在多种搜集方式, 包括但不限于:

实时统计; 客户端在正常工作时, 计算其自身每次从发送加入组播请 求到接收到组播码流之间的时间间隔;

实验分析; 使用支持组播功能的网络主机进行实验, 测量其从发送加 入组播请求到接收到组播码流之间的时间间隔 ;

经验估算; 综合历史数据、 实验结果、 设备型号、 网络架构等各种因 素, 进行合理的估计。

上述方式可单独使用也可组合使用, 如果获得多个不同的数值, 则采 用取最小值或平均值等统计学方法得到一个单 一的数值, 作为组播诸求处 理延时。

第二步、 计算单播与组播码流同步的时间;

服务器持续接收组播码流并进行缓存, 当客户端向服务器请求快速频 道切换服务时,服务器将从緩冲区中取出以 I帧开头的媒体包釆用单播方式 发送给客户端。

采用如下公式计算出单播与组播码流同步的时 间:

TSync=PDif/(RUc-RMc) 公式 1

上式中, TSync为估算的单播与组播码流同步的时间, PDif 为某个时 刻服务器已发送的单播媒体包和其已接收的组 播媒体包之间相隔的数据 量, RUc为服务器发送单播码流的平均码率, RMc为组播码流的平均码率。

将公式 1左边的除数和被除数同时除以 RMc, 可得到如下等价公式:

TSync=TDif/( a Uc-1) 公式 2

上式中, TSync为估算的单播与组播码流同步的时间, TDif 为某个媒 体包从被接收到被发送之间的时间间隔, a Uc为单播码率相对于组播码率 的比例, 即:

a Uc=RUc RMc

本步骤得到的结果是一个相对时间: 对于公式 1, 其计时起点是进行计 算的时刻;对于公式 2, 其计时起点是被选择用于计算的媒体包被发送 的时 刻。

第三步、 计算客户端预先发出加入组播请求的时刻;

采用下式进行计算:

TReqMc=TSync-TMcDly 公式 3 上式中, TReqMc为客户端预先发出加入组播请求的相对时 间, TSync 为单播与组播码流同步时间, TMcDly为组播请求处理延时。

可由服务器、 客户端或其它设备完成上述步驟二和步驟三的 计算, 只 要将计算所需参数传递给相应的设备即可。公 式 1、公式 2和公式 3还可表 示为绝对时间形式, 并可能还有其它的等价形式。

本发明所述在快速频道切换过程中预先发送加 入组播请求的第一种方 法如下:

第一步、 将组播请求处理延时通知到服务器, 有多种方式可供选择, 包括但不限于:

由客户端保存组播请求处理延时数值, 通过通讯链路发送给服务器; 将组播请求处理延时作为服务器的一个配置参 数。

第二步、 服务器计算客户端预先发送加入组播请求的时 间, 具体方法 已在本文前面相应部分给出。

第三步、 服务器控制客户端预先发出加入组播请求, 有几种不同的方 式, 包括但不限于:

服务器将计算得到的预先加入组播组的时刻通 过通讯链路通知给客户 端, 客户端在预定的时刻发出加入组播请求; 或者,

服务器在预先加入组播组的时刻到达时通知客 户端, 客户端收到通知 后立即发出加入组播请求。

本发明所述在快速频道切换过程中预先发送加 入组播请求的笫二种方 法如下:

第一步、 将组播请求处理延时通知到客户端, 有多种方式可供选择, 包括但不限于:

客户端直接保存结果, 这适合于采用实时统计方式获取组播请求处理 延时的情况; 将组播请求处理延时作为客户端的一个配置参 数, 这适合于采用实验 分析或经验估算方式获取组播请求处理延时的 情况。

第二步、 服务器计算单播与組播码流同步的时间, 具体过程参见本文 前面给出的计算客户端预先发送加入组播请求 的时间的方法的第二步。

第三步、 客户端预先发送加入组播请求, 这一步可分为三个子步骤: 服务器将单播与组播码流同步时间的计算结果 通过通讯链路发送给客 户端;

客户端计算预先发出加入组播请求的时间, 具体过程参见本文前面给 出的计算客户端预先发送加入组播请求的时间 的方法的第三步;

客户端在预先发出加入组播请求的时刻到达时 , 发出加入组播奇求。 下面结合附图对技术方案的实施作进一步的详 细描述:

图 1为本发明所述预先发送加入组播请求的时间 计算方法示意图: 其中, 横轴 t表示时间, 纵轴 p表示媒体包的发送进度。

直线 101 为组播码流的媒体包发送进度, 相当于服务器对组播媒体包 的接收緩存进度, 其斜率对应公式 1中的組播码流平均码率 RMc。

直线 102为服务器发出的单播码流的媒体包发送进度 , 其斜率对应公 式 1中的单播码流平均码率 RUc。

在 Tl时刻, 101和 102对应的纵坐标差值就是该时刻服务器已发送 的 单播媒体包和其已接收的组播媒体包之间相隔 的数据量, 即图 1中的 PDif。

101和 102在 T3时刻相交, 意味着单播与组播码流在 T3时刻实现同 步, 而 T3和 T1的差值就对应于公式 1中的 TSync, 对于 101和 102两条 斜率已知的直线来说, 可通过 T1时刻两者的纵坐标差值计算出 TSync, 即 公式 1。

现在换个角度, 假设服务器在 T1时刻发送出某个单播媒体包, 其发包 进度对应于直线 102在 T1时刻的纵坐标, 而直线 101上与其纵坐标相同的 点的横坐标 TO就是该媒体包在组播码流中被发送的时刻, 就是服务器接 收该媒体包的时刻, 显然, TO和 T1的差值就是公式 2中的媒体包从被接 收到被发送之间的时间间隔 TDif。

分別位于 101和 102两条直线上且纵坐标相同的两个点的横坐标 差值 已知(即 TDif ), 而直线 101和直线 102的斜率又已知, 则通过数学运算可 计算出两条直线交点的横坐标与 T1的时间间隔 TSync, 即公式 2。

假设组播请求处理延时为 TMcDly,为了保证客户端在单播与组播码流 同步时刚好接收到组播码流, 则需要相对于 TSync提前一段时间 (在图 1 中的 T2时刻)发出加入组播请求, 而这个提前的时间长度就是 TMcDly。

在图 1 中, 通过公式 1或公式 2可计算出 T1到 T3之间的时间间隔 TSync, 又已知 T2和 T1之间的时间间隔 TMcDly, 则可通过公式 3计算出 T1到 T3之间的时间间隔 TReqMc。

单播与组播码流同步时间通常以秒计, 组播请求处理延时则为数百毫 秒, 而媒体包的传输时间基本都在 10毫秒的数量级, 和前两者比较起来可 以忽略不计, 故本发明提出的计算方法忽略了媒体包在网络 上的传输时间。

前述的在频道快速切换过程中预先发送加入组 播请求的时间的操作思 路, 可以表示如图 2所示的流程, 该流程包括以下步骤:

步驟 210: 搜集数据设备处理加入组播请求的处理时间开 销, 该操作可 以通过设置搜集单元实现。

步驟 220: 计算单播与组播码流同步的时间。

步骤 230: 计算客户端预先发出加入組播请求的时刻。

步驟 220和步骤 230中的操作可以通过设置计算单元实现。

前述的在快速频道切换过程中预先发送加入组 播请求的操作思路, 可 以表示如图 3或图 4等所示的流程.

其中, 图 3所示流程包括以下步骤: 步骤 310: 将组播请求处理延时通知到服务器。

步驟 320: 服务器计算客户端预先发送加入组播请求的时 间。

步驟 330: 服务器控制客户端预先发出加入组播请求。

图 4所示流程则包括以下步骤:

步骤 410: 将组播请求处理延时通知到客户端。

步驟 420: 服务器计算单播与组播码流同步的时间。

步骤 430: 客户端预先发送加入组播请求。

图 3和图 4中的所述通知操作可以通知设置通知单元实 。

参见图 5, 图 5为本发明提供的两个实施例的部署模型, 其中所涉及到 的实体主要有数据设备 501、 服务器 502和客户端 503, 采用互联网组管理 协议 ( Internet Group Managemet Protocol, IGMP ) 来支持组播。

服务器 502可通过信道 509向数据设备 501发出 IGMP报文以加入频 道所在的组播组, 而数据设备 501则通过信道 504向服务器 502发送组播 码流。

客户端 503可通过信道 505向数据设备 501发出 IGMP报文以加入频 道所在的组播组, 数据设备 01则通过信道 506向客户端 503发送组播码 流。

服务器 502和客户端 503之间通过 RTCP建立双向通讯信道 507用于 与快速频道切换相关的消息通讯, 服务器 502通过信道 508向客户端 503 发送緩存的单播码流

信道 504和信道 506支持组播,其上码流均釆用 RTP封装,服务器 502 緩存后通过信道 508发给客户端 503的单播码流依然保持 RTP封装, 且不 修改 RTP序号字段。一旦客户端接收到的单播码流的 RTP序号能和组播码 流的 RTP序号无缝衔接, 则认为实现了单播与组播码流同步。

服务器 502启动后即通过信道 509向数据设备 501发出 IGMP报文, 加入直播频道所在的组播组, 并通过信道 504持续接收媒体包进行缓存。 客户端 503持续统计每次从发送加入组播请求到接收到 组播码流之间 的时间间隔, 将其最小值或平均值作为组播请求处理延时。

参见图 6, 图 6为实施例一快速频道切换过程的流程图, 图中以虚线分 隔的左右两侧分别为服务器和客户端的处理流 程, 纵向的实线箭头表示服 务器或客户端各自的处理步驟的先后顺序, 而横向的虛线箭头则给出了分 别作为箭头起点和终点的服务器和客户端相应 处理步驟的先后顺序。 图 6 所示流程包括以下步骤:

步骤 601、客户端向服务器请求快速频道切换服务, 在请求消息中携带 有组播请求处理延时数据;

步骤 602、服务器接收客户端的快速频道切换请求, 提取组播请求处理 延时数据加以保存;

步驟 603、 服务器从 I帧开始向客户端发送缓存的组播码流; 步骤 604、 机顶盒接收服务器发送的单播码流并加以显示 ;

步骤 605、服务器计算预先发送加入组播请求的时间 , 并在相应时刻到 达时通知客户端立即加入组播组;

步骤 606、 客户端向数据设备发出 IGMP消息, 请求加入组播组; 步驟 607、客户端接收到组播码流, 当单播与组播码流同步时切换到使 用组播码流进行解码, 并通知服务器停止发送单播码流;

步驟 608、 服务器停止发送单播码流。

参见图 7, 图 7为实施例二快速频道切换过程的流程图, 与图 6—样以 虚线分隔成左右两列, 实线箭头和虚线箭头的含义也与图 6—致。 图 7所 示流程包括以下步骤:

步骤 701、 客户端向服务器请求快速频道切换服务;

步驟 702、 服务器接收客户端的快速频道切换请求, 从 I帧开始向客户 端发送緩存的组播码流;

步驟 703、 客户端接收服务器发送的单播码流并加以显示 ;

步驟 704、服务器计算单播与组播码流同步的时间, 并将结果通知到客 户端;

步骤 705、客户端根据服务器提供的单播与组播码流 同步时间, 结合自 身保存的组播清求处理延时, 计算出预先发送加入组播请求的时间;

步骤 706、客户端根据上一步骤的计算结果在相应时 刻向数据设备发出 IGMP报文, 请求加入组播组;

步骤 707、客户端接收到组播码流, 当单播与组播码流同步时切换到使 用组播码流进行解码, 并通知服务器停止发送单播码流;

步骤 708服务器停止发送单播码流。

综上所述可见, 无论是方法还是系统, 本发明实质上是根据组播请求 处理延时控制客户端预先发送加入组播请求, 这样当单播与组播同步时, 客户端正好接收到组播码流, 既保证了单播与组播码流在客户端的衔接, 也减少了服务器发送单播码流的时间, 从而降低了快速频道切换的部署成 本。

以上所述, 仅为本发明的较佳实施例而已, 并非用于限定本发明的保 护范围。 工业实用性

本发明公开了一种在快速频道切换时预先发送 加入组播请求的方法和 系统, 能够搜集数据设备处理加入组播请求的处理时 间开销, 计算单播与 组播码流同步的时间, 计算客户端预先发出加入组播诸求的时刻; 从而缩 短服务器发送单播码流的时间, 节约处理能力, 降低部署成本。