数据接收 / 发送终端、 装置、 方法及机顶盒 技术领域 本发明涉及互联网中的数据接收 / 发送终端、装置、方法及机顶盒，尤其涉及 基于 P2P 的流媒体文件传输系统。
背景技术
将 P2P 技术和流媒体应用相结合是当前研究热点之一，P2P 系统的最大优点是使 得用户能够有效的利用网络中的资源，这些资源包括数据资源、带宽资源、还包括计算 资源。 所以这使得 P2P 系统中几乎没有原来 C/S 模式的瓶颈，有着很好的可扩展性。 在 P2P 模型中，每一个节点 (Peer) 同时扮演了两种角色，既是客户端又是服务器，作为客 户端能够向其他节点查询和请求所需要的服务，作为服务器能够提供服务给其他节点。
由于具备传输速度快、带宽利用率高等特点，采用 MFTP(Multiple File Transfer Protocol ：多文件传送协议 ) 多源下载技术的 BT( 基于 BitTorrent 协议 ：比特洪流协议 )、 电骡 (eMule 协议 ) 等 P2P 应用软件如今已经在网络上广为流行。 MFTP 多源下载技术的 核心包括 ： 1) 将资源文件分割成等长的分片 (piece)，以便标记和处理 ；
2) 节点之间必须互相了解对方都有哪些分片，以便互通有无，达到边下载边上 传的目的 ；
3) 节点在收到一个分片后需要校验该分片是否正确。
在 BT 软件中，节点通过名为 “种子” (Torrent) 的文件来获得文件的整体描述 以及其中每个分片的校验码 ；电骡中，节点在下载分片的同时从其他节点出得到该分片 的校验码。
点播流媒体文件需要边下载边播放。 虽然 BT、电骡等能够实现高速的文件下 载，但其对文件的所有分片 ( 包括文件控制信息所在的控制信息分片 ) 实施乱序下载，故 无法支持媒体文件的边下载边播放，节点也就只能在完整下载该媒体文件后才可以对其 进行播放。
公开号为 “200710062866.5” 的专利申请了一种基于 P2P 协议的媒体文件点播 控制方法和装置，该装置为 P2P 网络中的接收端，它根据各个片的紧急程度 ( 距离当前播 放片的时间 ) 定义优先级，时间紧急度越高的片优先级越高，然后优先请求优先级最高 的片。 该发明通过总是优先地下载媒体文件多个数据分片中靠近播放位置的数据分片， 在 P2P 协议下实现了媒体文件的下载、播放同时进行。
上述技术虽然在一定程度上实现了边下载边播放，但却存在以下缺点 ：即，接 收端只发送所请求片的片号，而发送端可能同时收到来自多个接收端的请求，对于这些 请求，发送端不能判断紧急程度，因此不能按照这些请求的紧急程度来响应。 这可能会 引起视频点播中的延迟。
可见，目前 P2P 中还没有发送端根据接收端请求数据的紧急程度决定其响应顺 序的技术。
发明内容 为了优化 P2P 网络中的数据传输，减少点播时间的延迟，本发明提供了一种应 用于 P2P 点播中的数据传输系统和方法，该系统和方法以数据的紧急程度 ( 即该数据距离 被播放的时间 ) 作为数据传送的优先级准则，最紧急的数据将被优先传送。
本发明提供了一种应用于 P2P 点播中的数据传输系统，该系统包括一个 P2P 服 务器和多个客户端，其中客户端既是数据接收端又是数据发送端。 接收端在向发送端发 送请求数据时的同时发送代表该数据优先级的参数，所请求的数据可以是片，也可以是 帧，代表该数据优先级的参数可以但不局限于接收端正在播放的位置、被请求数据距离 被播放的时间、被请求数据即将被播放的时间、被请求数据的 ID( 片号或帧号 ) 与正在播 放数据 ID( 片号或帧号 ) 的差值、优先级级别等。
发送端根据接收端请求的数据及代表该数据优先级的参数对所接收到的请求进 行优先级排序，并按照优先级顺序进行响应，最高优先级的数据请求将被首先响应。
根据本发明的装置与方法，可以提高 P2P 网络中数据传输的效率，减少视频点 播中的等待时间。
附图说明
图 1A 为本发明中 P2P 网络的系统构成图 ； 图 1B 是本发明中 C/S 网络的系统构成图 ； 图 2A 为本发明的应用于 P2P 系统中的视频结构示意图 ； 图 2B 是本发明的应用于 C/S 系统中的视频结构示意图 ； 图 3A 为本发明的接收端的结构示意图 ； 图 3B 为本发明的发送端的结构示意图 ； 图 4A 是本发明的接收端为机顶盒的系统结构示意图 ； 图 4B 是本发明的发送端为机顶盒的系统结构示意图 ； 图 5A 为本发明的 “帧 <--> 片” 对应表的示意图 ； 图 5B 为本发明的 “帧 <--> 包” 对应表的示意图 ； 图 6 为本发明的优先级级别定义表的示意图 ； 图 7 为本发明的请求管理表的示意图 ； 图 8A 为 BitTorrent 协议中请求信息的数据格式 ； 图 8B 是本发明中请求信息的数据格式 ； 图 9 是本发明的接收端的工作流程图 ； 图 10 是本发明的发送端的工作流程图。具体实施方式
下面参考实施例对本发明的具体实施方式进行说明 ：
图 1A 是本发明的 P2P 网络的系统构成图，该系统包括 ：P2P 服务器 100，用于 提供客户端对数据内容的拥有信息 ；客户端装置 200、300、400 等，以 P2P 的方式点播视 频文件并在线观看，在从其他客户端下载数据的同时为其他客户端上载数据。图 1B 是本发明的 C/S 网络的系统构成图，该系统包括 ：C/S 服务器 100’，用 于为客户端提供视频内容 ；客户端装置 200’、300’、400’ 等，以 C/S 的方式点播视 频文件并在线观看。
图 2A 是本发明的应用于 P2P 系统中的视频结构示意图，视频文件 P 被分为大小 相等的 N 个片， P1、 P2...Pn，其中 Pc 为该视频文件 P 在接收端中的当前播放位置， Pr 为该接收端正在请求的片，其中每个片由不固定数量的一组帧组成，如 P0 包括帧 F0、 F1...Fa。
图 2B 是本发明的应用 C/S 系统中的视频结构示意图，视频文件 I 被分为大小相 等或不等的 N 个数据包， I1、 I2...In，其中 Ic 为该视频文件 I 在接收端中的当前播放位 置， Ir 为该接收端正在请求的包，其中每个数据包由不固定数量的一组帧组成，如 I0 包 括帧 F0、 F1...Fa。
图 3A 是本发明的接收端的结构示意图，包括 ：数据接收单元 301，用于接收从 发送端发送的数据 ；数据播放单元 302，用于播放视频数据 ；播放位置获取单元 303，用 于获取视频数据的当前播放数据的 ID( 片号或帧号 ) ；请求数据获取单元 304，用于获取 待请求的数据 ID( 片号或帧号 ) ；紧急度信息生成单元 305，用于根据请求数据获取单元 304 获取的待请求数据 ID( 片号或帧号 ) 以及当前播放位置获取单元 303 获取的当前播放 位置 ( 片号或帧号 ) 计算待请求数据的紧急度信息 ；请求发送单元 306，用于发送请求数 据 ID( 片号或帧号 ) 及其紧急度信息到相应发送端 ；存储单元 307，用于存储计算紧急度 信息所需的信息，如 “帧 <--> 片” 对应表图 5A 和优先级级别定义表图 6。 图 3B 是本发明的发送端的结构示意图，包括 ：请求获取单元 401，用于获取 从接收端发送的数据请求 ；请求管理单元 402，用于管理请求管理表 ；优先级计算单元 403，用于根据从接收端收到的请求信息中包含的紧急度信息计算数据请求的优先级，并 根据该优先级的计算结果由请求管理单元 402 对数据请求信息进行管理 ；数据发送单元 404，用于发送请求数据到接收端 ；存储单元 405，用于存储视频数据及后述的请求管理 表图 7。
图 4A 是本发明的接收端为机顶盒的系统结构示意图，包括 ：数据接收单元 301’，用于接收从发送端发送的数据 ；解调单元 302’，用于解调接收到的音视频数 据 ；解码单元 303’，用于解码音视频数据 ；音视频处理单元 304’，用于分离音视频数 据 ；输出单元 305’，用于将音视频数据输出给播放设备 ；存储单元 306，用于存储接 收到的音视频数据、存储紧急度信息所需的信息，如 “帧 <--> 片” 对应表图 5A 和优 先级级别定义表图 6 ；请求数据获取单元 307’，用于根据存储单元 306’ 中已下载的的 数据来获取待请求的数据 ID( 片号或帧号 ) ；播放位置获取单元 308’，用于根据输出单 元 305’ 的视频输出信息获取当前视频播放位置 ( 片号或帧号 ) ；紧急度信息生成单元 309’，用于根据请求数据获取单元 307’ 获取的待请求数据 ID( 片号或帧号 ) 以及当前 播放位置获取单元 308’获取的当前播放位置 ( 片号或帧号 ) 计算待请求数据的紧急度信 息 ；请求发送单元 3010’，用于发送请求数据 ID( 片号或帧号 ) 及其紧急度信息到相应 发送端。
图 4B 是 本 发 明 的 终 端 为 机 顶 盒 的 系 统 结 构 示 意 图， 包 括 ：数 据 接 收 单 元 401’，用于接收从发送端发送的数据 ；解调单元 402’，用于解调接收到的音视频数
据 ；解码单元 403’，用于解码音视频数据 ；音视频处理单元 404’，用于分离音视频数 据 ；输出单元 405’，用于将音视频数据输出给播放设备 ；存储单元 406’，用于存储视 频数据及请求管理表图 7 ；请求接收单元 407’，用于获取从接收端发送的数据请求 ；请 求管理单元 408’，用于管理请求管理表， ；优先级计算单元 409’，根据从其他机顶盒 接收到的请求信息中包含的紧急度信息计算数据请求的优先级，并根据该优先级计算的 结果由请求管理单元 408’ 对接收到的数据请求信息进行管理 ；数据发送单元 4010’， 用于发送请求数据到接收端。
图 5A 是本发明的 P2P 系统中的 “帧 <--> 片” 对应表，包括帧 501，片 502， 表示帧与片的对应关系。
图 5B 是本发明的 C/S 系统中的 “帧 <--> 包” 对应表，包括帧 501’，数据包 502’，表示帧与数据包的对应关系。
图 6 是本发明的优先级级别定义表的示意图，该表根据表示了片距离被播放的 时间 Tr 与优先级级别的对应关系，包括 Tr 601 和 PL 602。
图 7 是本发明的请求管理表，包括接收端 701，请求数据 702，紧急度信息 703， 优先级 704。
图 8A 是 BitTorrent 协议中接收端请求信息的数据结构，包括片号 801，块内偏移 位置 802，请求长度 803。
图 8B 是本发明的接收端请求信息的数据结构，包括片号 801’，片内偏移位置 802’，请求长度 803’ 和紧急度信息 804’。
图 9 是本发明的接收端的工作流程图。
图 10 是本发明的发送端的工作流程图。
紧急度信息生成单元 303 将 Pr 以及其优先级信息 Tr1 发送到请求发送单元 306， 请求发送单元 306 将请求 (Pr， Tr1) 发送到相应发送端。
实施例一
本实施例参照图 3A、图 5A、图 9 对 P2P 系统中接收端进行详细说明，其中请求 的数据为片，紧急度信息为当前播放时间到播放请求片播放时间的绝对时间。 所谓绝对 时间，是指请求片被播放的时刻距离发出请求时刻的时间。
图 3A 是接收端的结构示意图，该接收端工作于图 1A 所示的 P2P 网络结构中。
数据接收单元 301 接收从其他客户端 ( 发送端 ) 传来的音视频数据，数据播放单 元 302 播放音视频数据，播放位置获取单元 303 获取数据播放单元 302 正在播放的帧 Fc， 并传送到紧急度信息生成单元 305 ；请求数据获取单元 304 根据存储单元中数据的下载情 况获取要请求的片 Pr，并将 Pr 传送到紧急度信息生成单元 305 ；本实施里紧急度信息 PP 为当前播放的片距离请求片被播放的时间，因此紧急度信息生成单元 305 需要获取当前 播放时间 Tc 并根据当前播放帧 Fc 和请求片 Pr 计算请求片 Pr 的播放时间，具体计算方法 为：
紧急度信息生成单元 305 查询存储在存储单元 307 中的 “帧 <--> 片” 对应表， 如图 5A 所示，根据帧 501 和片 502 的对应关系查找到 Pr 所对应的帧为 (Fi，Fj)，即片 Pr 中首先被播放的帧为 Fi，因此 Pr 距离被播放的时间 Tw1 可以得到 ：
Tw1 ＝ (Fi-Fc)/fr，其中 fr 为接收端每秒钟播放的帧数，一般为 25 帧 /s。由此可以得到紧急度信息为 (Tw1) 为 “(15s)”。 紧急度信息生成单元 305 将 该紧急度信息 (15s)，加入到数据请求信息。
以往，例如 BitTorrent 协议中将文件划分为片，在请求数据时可能直接请求一个 片，也可能把片进一步划分为更小的 slice，以 slice 为单位进行请求。 客户端之前请求数 据时发送的请求格式为 (Pr， Begin， Length)，其中 Pr 是片号， Begin 是片内偏移地址， Length 是数据长度。 本发明专利中只讨论以片为单位请求的情况，因此片内偏移地址为 0， length 即片的长度。
因此，该生成的数据请求信息的形式可以为 (Pr，0， length， Tw1)，在生成数 据请求信息后，由请求发送单元 306 发送到发送端。
变形例一
与实施例一相同，本实施例同样对 P2P 系统中的接收端进行详细说明，其中请 求的数据为片，不同的是，紧急度信息 PP 为请求片即将被播放的时刻 Tp。
沿用实施例一中的例子，如请求的片为 Pr，当前时刻 ( 即，系统时间 ) 为 16 时 00 分，距离该请求片被播放的时间为 15s，则该片被播放的时刻为 16 时 00 分 15 秒，因 此将请求片 Pr 和紧急度信息 Tp1 “(16 时 00 分 15 秒 )” 加入到数据请求信息，此时该 数据请求信息的形式例如为 (Pr，0， length， Tp1)。 在生成数据请求信息后发送到发送 端。 在接收发送系统中，能够由发送端确定该请求片距离被播放时刻的具体时间， 接收端能够及时得到该请求片的数据。
变形例二
与实施例一相同，本实施例同样对 P2P 系统中的接收端进行详细说明，其中请 求的数据为片，不同的是，紧急度信息 PP 为接收端请求片与当前播放片的 ID 差值。 本 实施例相对于实施例一降低了请求数据紧急程度的精度，但是同时也降低了接收端关于 紧急度信息 PP 的计算量。
以下参照图 3A、图 5A 进行说明。
如图 2A 所示，视频文件 P 被分为大小相等的 N 个片。 假设接收端当前播放片 为 Pc，请求片为 Pr。 如图 3A 所示，播放位置获取单元 303 获取当前播放片 Pc，并传送 到紧急度信息生成单元 305 ；请求数据获取单元 304 获取请求片 Pr，并将 Pr 传送到紧急 度信息生成单元 305 ；由于本实施例中紧急度信息为请求片与当前播放片的 ID 差值，因 此紧急度信息生成单元 305 计算紧急度信息 PP ＝ Pr-Pc，然后将紧急度信息 PP(Pr-Pc) 加 入到数据请求信息中，该生成的数据请求信息的形式可以如 (Pr，0，length，Pr-Pc)。 然 后由请求发送单元 306 发送数据请求。
变形例三
与实施例一相同，本实施例同样选择 P2P 系统中的接收端进行详细说明，其中 请求的数据为片，不同的是，在网络协议的支持下，接收端还能够直接根据当前播放片 和请求片的信息 ( 时间或位置等 ) 来确定请求片的优先级级别，因此紧急度信息 PP 可 以是优先级级别，该优先级级别也是根据当前播放片和请求片的信息得到的。 如图 6 所 示，优先级级别为 P2P 系统根据请求数据距离被播放的时间定义的优先等级。 本实施例 相对于实施例一对请求数据的优先级进行归类，降低了请求数据的优先级级别，大大简
化了数据发送端的处理。
以下参照图 3A、图 5A、图 6 对接收端进行说明。
如图 3A 所示，播放位置获取单元 301 获取当前播放帧 Fc，并传送到紧急度信息 生成单元 305 ；请求数据获取单元获取要请求的片 Pr，并将 Pr 传送到紧急度信息生成单 元 305 ；本实施例中紧急度信息 PP 为优先级级别，紧急度信息生成单元 305 需要首先根 据当前播放帧 Fc 和请求片 Pr 计算请求片 Pr 距离被播放的时间 Tr1，具体计算方法为 ：
紧急度信息生成单元 305 查询存储在存储单元 307 中的 “帧 <--> 片” 对应表， 如图 5A 所示，根据帧 501 和片 502 的对应关系查找到 Pr 所对应的帧为 (Fi，Fj)，即片 Pr 中首先被播放的帧为 Fi，因此 Pr 距离被播放的时间 Tr1 可以得到 ：
Tr1 ＝ (Fi-Fc)/fr，其中 fr 为接收端每秒钟播放的帧数，一般为 25 帧 /s。
计算得出 Tr1 后，紧急度信息生成单元进一步查询优先级级别定义表图 6，假设 Tr1 ＝ 15s，从图 6 中可查出， Tr1 在区间 (10s ～ 30s) 的对应的优先级级别 PL ＝ 3 ；
紧急度信息生成单元 303 根据 Pr 以及其优先级级别 PL 生成请求信息 (Pr，0， length， PL)，并由请求发送单元 304 发送到相应发送端进行数据请求。
实施例二 与实施例一相同，本实施例同样选择 P2P 系统中的接收端进行详细说明，其中 请求的数据为片，紧急度信息为当前时刻距离播放被请求片的时刻的时间。 与实施例一 不同的是，本实施例中，接收端是具有 P2P 功能的机顶盒。
本实施例参照图 4A、图 5A 对 P2P 系统中接收端进行详细说明。
在本实施例中，机顶盒的数据下载是以 P2P 方式进行的。 其工作过程为 ：
数据接收单元 301’，用于接收从发送端发送的数据 ；解调单元 302’，用于 解调接收到的音视频数据 ；解码单元 303’，用于解码音视频数据 ；音视频处理单元 304’，用于分离音视频数据 ；输出单元 305’，用于将音视频数据输出给播放设备 ； 存储单元 306’，用于存储接收到的音视频数据、计算紧急度所需的信息，如 “帧 <--> 片” 对应表图 5A 和优先级级别定义表图 6 ；请求数据获取单元 307’，用于根据存储单 元 306’ 中已下载的的数据来获取待请求的片的片号 Pr，并将 Pr 传送到紧急度信息生成 单元 309’ ；播放位置获取单元 308’ 根据输出单元 305’ 正在输出的数据获取当前向显 示设备输出的帧的帧号 Fc，并传送到紧急度信息生成单元 309’；本实施例中紧急度信息 PP 为当前时刻和片距离被播放的时间，因此紧急度信息生成单元 309’ 需要获取当前时 刻 Tc 并根据当前播放帧 Fc 和请求片 Pr 计算该请求片 Pr 距离被播放的时间 Tw1，具体计 算方法为 ：
紧急度信息生成单元 309’ 查询存储在存储单元 307 中的 “帧 <--> 片” 对应 表，如图 5A 所示，根据帧 301 和片 302 的对应关系查找到 Pr 所对应的帧为 (Fi，Fj)，即 片 Pr 中首先被播放的帧为 Fi，因此 Pr 距离被播放的时间 Tw1 可以得到 ：
Tw1 ＝ (Fi-Fc)/fr，其中 fr 为接收端每秒钟播放的帧数，一般为 25 帧 /s。
由此可以得到紧急度信息 Tw1，如请求片距离被播放的时间为 15 秒，则紧急度 信息为 “(15s)”。 紧急度信息生成单元 305 将 Pr 以及其紧急度信息 “(15s)”，在数据 请求信息中加入该紧急度信息。
BitTorrent 协议中将文件划分为片，在请求数据时可能直接请求一个片，也可能
把片进一步划分为更小的 slice( 片段 )，以 slice 为单位进行请求。 客户端之前请求数据 时发送的请求格式为 (Pr， Begin， Length)，其中 Pr 是片号， Begin 是片内偏移地址， Length 是数据长度。 本发明专利中只讨论以片为单位请求的情况，因此片内偏移地址为 0， length 即片的长度。
因此，该数据请求信息的形式可以为 (Pr，0， length， Tw1)，生成数据请求信 息后，由上述请求发送单元 306 发送到发送端，。
实施例三
本实施例参考图 3A 对 P2P 系统中的接收端进行详细说明，其中请求的数据为 帧，紧急度信息 PP 为该帧距离被播放的时间，作为紧急度信息也可变化为请求帧与当前 播放帧的 ID 差值、优先级级别，同实施例一的两个变形例。
如图 3A 所示，播放位置获取单元 303 获取当前播放帧 Fc，并传送到紧急度信息 生成单元 305 ；请求数据获取单元获取要请求的帧 Fr，并将 Fr 传送到紧急度信息生成单 元 305 ；本实施例中紧急度信息为请求片距离被播放的时间，因此紧急度信息生成单元 305 需要根据当前播放帧 Fc 和请求片 Fr，计算请求片 Fr 距离被播放的时间，具体计算方 法为 ： Tr ＝ (Fr-Fc1)/fr，其中 fr 为接收端每秒钟播放的帧数，一般为 25 帧 /s。
紧急度信息生成单元 203，在根据 Fr 以及其紧急度信息 Tr 生成数据请求信息 后，由请求发送单元 304 发送到发送端，进行数据请求。
实施例四
本发明同样可以适用于 C/S 系统。 在 C/S 系统中 ( 如图 1B)，客户端为数据的 接收端， C/S 服务器为发送端，流媒体服务采用流媒体协议如 RTP 进行数据传输，在流 媒体协议中，数据按照其时间顺序被分为一个个的数据包，数据以包为单位进行传输。 如图 2B 所示，视频文件 I 被分为 n 个数据包，这些包可能大小相等也可能不等，每个数 据包包括一定数量的帧。
本实施例参照图 3A 对 C/S 系统中的客户端进行详细说明，其中请求的数据为 帧，紧急度信息 PP 为该帧距离被播放的时间 ( 紧急度信息也可变化为请求帧与当前播放 帧的 ID 差值、优先级级别，同实施例一的两个变形例 )。
如图 3A 所示，播放位置获取单元 301 获取当前播放帧 Fc，并传送到紧急度信息 生成单元 305 ；请求数据获取单元获取要请求的帧 Fr，并将 Fr 传送到紧急度信息生成单 元 303 ；本实施例中紧急度信息为请求片距离被播放的时间，因此紧急度信息生成单元 305 需要根据当前播放帧 Fc 和请求片 Fr 计算该请求片 Fr 距离被播放的时间 Tr1，具体计 算方法为 ：
Tr1 ＝ (Fr-Fc1)/fr，其中 fr 为客户端每秒钟播放的帧数，一般为 25 帧 /s。
在根据 Fr1 以及其紧急度信息 Tr1 生成数据请求信息后，由发送单元 306 发送到 相应的服务器端。
在以上的各实施例及变形例中，将请求数据获取单元 (301、307’ )，播放位置 获取单元 (302、308’ ) 和紧急度信息生成单元 (305、309’ ) 分开进行了叙述，其目的 是为了使说明更简单明了，但在实际应用中，能够由同一处理部进行当前播放片和请求 片的信息的获取，以及根据获取到的上述信息生成紧急度信息并将其加入到数据请求信
息中的全部处理。
实施例五
本实施例参考图 3B 和图 7 对 P2P 系统中发送端进行详细说明，该发送端接收来 自接收端的数据请求信息，并且在数据请求信息中包含该接收端的请求片的紧急度信息 PP，该紧急度信息 PP 为该片距离被播放的绝对时间。 所谓绝对时间，如上所述，是指在 接收端中请求片被播放的时刻距离发出请求时刻的时间。
参 考 图 7， 发 送端分别从 接 收端 R1、 R2、 R3 获取 了 请求 (Pr，0， length， Tw1)、 (Pr2，0， length， Tw2)、 (Pr3，0， length， Tw3)，以下以 (Pr，0， length， Tw1) 为例叙述发送端的工作过程。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Pr，0， length， Tw1)，并将其传送到请求管理单元 402 ；请求管理单元 402 将该请求存储于存储 单元 405 中的请求管理表图 7 中，如图，分别将 R1、Pr、Tw1 存入接收端 701、请求数据 702、紧急度信息 703，并将 (Pr，0， length， Tw1) 发送到优先级计算单元 403 ；优先级 计算单元 403 根据图 7 中的紧急度信息 703 一列对该请求进行紧急度信息排序，由于 Tw 的值越小，代表请求片距离播放时间越近，因此， Tw 越小，则优先级越高，在本例中， 假设 Tw1 ＜ Tw2 ＜ Tw3，则优先级为 Pr ＞ Pr2 ＞ Pr3， Pr 的优先级最高，因此优先级计 算单元 403 设置表 7 中 Pr 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存储单元 405 中 的请求管理表中找到优先级最高的请求，将其请求的数据发送到相应的接收端。
同时，请求管理单元 402 实时更新存储单元 405 中的请求管理表图 7，具体表示 为，随着时间的推移，紧急度信息 703(Tw) 会相应减小优先级提高。
变形例一
与实施例四相同，本实施例同样选择 P2P 系统中的发送端进行详细说明，该发 送端接收来自接收端的数据请求信息，并在数据请求信息中包含该接收端的请求片的紧 急度信息 PP，不同的是，该紧急度信息 PP 是请求片被播放的时刻 Tp，即系统时间。
参考图 7，假设发送端分别从接收端 R1、 R2、 R3 获取了请求 (Pr，0， length， Tp1)、 (Pr2，0， length， Tp2)、 (Pr3，0， length， Tp3)，以下以 (Pr，0， length， Tp4) 为例叙述发送端的工作过程。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Pr，0， length， Tp1)，并将其传送到请求管理单元 402 ；请求管理单元 402 将该请求存储于存储 单元 405 中的请求管理表图 7 中，如图，分别将 R1、 Pr、 Tp1 存入接收端 701、请求数 据 702、紧急度信息 703，并将 (Pr，0， length， Tp1) 发送到优先级计算单元 403 ；优先 级计算单元 403 根据图 7 中的紧急度信息 703 一列对紧急度信息进行排序，由于 Tp1 的值 越小，代表请求片距离播放时间越近，因此，Tp1 越小，则优先级越高，在本例中，假设 Tp1 ＜ Tp2 ＜ Tp3，则优先级为 Pr ＞ Pr2 ＞ Pr3，Pr 的优先级最高，因此优先级计算单元 403 设置表 7 中 Pr 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存储单元 405 中的请求 管理表中找到优先级最高的请求，将其请求的数据发送到相应的接收端。
同时，请求管理单元 402 实时更新存储单元 405 中的请求管理表图 7，具体表示 为，随着时间的推移，紧急度信息 703 的请求片播放时刻 Tp 不会发生变化，但因排序靠 前，使得优先级提高。 利用系统时刻请求片的播放时刻 Tp 所谓紧急度信息，能够减少发送端的运算量
变形例二
与实施例四相同，本实施例同样选择 P2P 系统中的发送端进行详细说明，该发 送端接收来自接收端的数据请求信息，并且在数据请求信息中包含该接收端的请求片的 紧急度信息 PP，不同的是，紧急度信息 PP 为接收端请求片与当前播放片的 ID 差值。 本 实施例相对于实施例四降低了请求数据紧急程度的精度，但是降低了接收端关于紧急度 信息 PP 的计算量。
以下参照图 3B 和图 7 进行说明。
参考图 7，假设发送端分别从接收端 R1、 R2、 R3 获取了请求 (Pr，0， length， Pr-Pc1)、 (Pr2，0， length， Pr2-Pc2)、 (Pr3，0， length， Pr3-Pc3)，以下以 (Pr，0， length， Pr-Pc1) 为例叙述发送端的工作过程。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Pr，0， length， Pr-Pc1)，并将其传送到请求管理单元 402 ；请求管理单元 402 将该请求存储于 存储单元 405 中的请求管理表图 7 中，如图，分别将 R1、 Pr、 Pr-Pc1 存入接收端 701、 请求数据 702、紧急度信息 703，并将 (Pr，0， length， Pr-Pc1) 发送到优先级计算单元 403 ；优先级计算单元 403 根据图 7 中的紧急度信息 703 一列对紧急度信息进行排序，由 于 Pr-Pc 的值越小，代表请求片距离播放时间越近，因此， Pr-Pc 越小，则优先级越高， 在本例中，假设 Pr-Pc1 ＜ Pr2-Pc2 ＜ Pr3-Pc3，则优先级为 Pr ＞ Pr2 ＞ Pr3， Pr 的优先 级最高，因此优先级计算单元 403 设置表 7 中 Pr 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存储单元 405 中的请求管理表中找到优先级最高的请求，将其请求的数据发送到相 应的接收端。
变形例三
与实施例四相同，本实施例同样选择 P2P 系统中的发送端进行详细说明，该发 送端接收来自接收端的数据请求信息，并且在数据请求信息中包含该接收端的请求片的 紧急度信息 PP，不同的是，紧急度信息 PP 为优先级级别。 如图 6 所示，优先级级别为 P2P 系统根据请求数据距离被播放的时间定义的优先等级。 本实施例相对于实施例一对 请求数据的优先级级别进行归类，降低了请求数据的优先级级数，大大简化了发送端的 处理。
参考图 7，发送端分别从接收端 R1、R2、R3 获取了请求 (Pr，0，length，PL)、 (Pr2，0， length， PL2)、 (Pr3，0， length， PL3)，以下以 (Pr，0， length， PL) 为例叙 述发送端的工作过程。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Pr， PL)， 并将其传送到请求管理单元 402 ；请求管理单元 402 将该请求存储于存储单元 405 中的请 求管理表图 7 中，如图，分别将 R1、 Pr、 PL 存入接收端 701、请求数据 702、紧急度信 息 703，并将 (Pr，0， length， PL) 发送到优先级计算单元 403 ；优先级计算单元 403 根 据图 7 中的紧急度信息 703 一列对紧急度信息的优先级级别 PL 进行排序，由于 PL 的值 越大，代表请求片距离播放时间越近，因此， PL 越大，则优先级越高，在本例中，假设 PL ＞ PL2 ＞ PL3，则优先级为 Pr ＞ Pr2 ＞ Pr3， Pr 的优先级最高，因此优先级计算单元 403 设置表 7 中 Pr 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存储单元 405 中的请求管理表中找到优先级最高的请求，将其请求的数据发送到相应的接收端。
实施例六
与实施例五相同，本实施例同样选择 P2P 系统中的发送端的机顶盒进行详细说 明，本实施例中的机顶盒与实施例二中的接收端机顶盒相应设置在同一网络中，其接收 来自发送端的机顶盒的数据请求信息，在所接收的数据请求信息中包含紧急度信息 PP， 在本实施例中，紧急度信息 PP 为该片距离被播放的绝对时间。 而且，发送端的具有 P2P 功能的机顶盒。 所谓绝对时间，如上所述，是指发送端中请求片被播放的时刻距离发出 请求时刻的时间。
本实施例参照图 4B，图 7 对 P2P 系统中的发送端进行详细说明。
在本实施例中，机顶盒的数据下载是以 P2P 方式进行的。 其工作过程为 ：
数据接收单元 401’，用于接收从发送端发送的数据 ；解调单元 402’，用于 解调接收到的音视频数据 ；解码单元 403’，用于解码音视频数据 ；音视频处理单元 404’，用于分离音视频数据 ；输出单元 405’，用于将音视频数据输出给播放设备 ；存 储单元 406’，用于存储视频数据及请求管理表图 7 ；请求接收单元 407’，用于获取从 接收端发送的数据请求 ；请求管理单元 408’，用于管理请求管理表 ；优先级计算单元 409’，用于计算数据请求的优先级 ；数据发送单元 4010’，用于发送请求数据到接收 端。 参考图 7，假设发送端分别从接收端 R1、 R2、 R3 获取了请求 (Pr，0， length， Tw1)、 (Pr2，0， length， Tw2)、 (Pr3，0， length， Tw3)，以下以 (Pr，0， length， Tw1) 为例叙述发送端的工作过程。
如图 3B 所示，请求获取单元 407’ 获取从接收端 R1 发送的数据请求 (Pr，0， length， Tw1)，并将其传送到请求管理单元 408’ ；请求管理单元 402 将该请求存储于存 储单元 406’中的请求管理表图 7 中，如图，分别将 R1、Pr、Tw1 存入接收端 701、请求 数据 702、紧急度信息 703，并将 (Pr，0， length， Tw1) 发送到优先级计算单元 409’ ； 优先级计算单元 409’ 根据图 7 中的紧急度信息 703 一列对紧急度信息 PP 进行排序，由 于 Tw 的值越小，代表请求片距离播放时间越近，因此， Tw 越小，则优先级越高，在本 例中，假设 Tw1 ＜ Tw2 ＜ Tw3，则优先级为 Pr ＞ Pr2 ＞ Pr3， Pr 的优先级最高，因此优 先级计算单元 409’ 设置表 7 中 Pr 的优先级 704 为 P1 ＝ 3 ；数据发送单元 4010’ 从存 储单元 406’中的请求管理表中找到优先级最高的请求，将其请求的数据发送到相应的接 收端。
同时，请求管理单元 402 实时更新存储单元 406’ 中的请求管理表图 7，具体表 示为，随着时间的推移，紧急度信息 703 的请求片播放时间 Tw 会相应减小。
实施例七
本实施例参考图 3B、图 5A 和图 7 对 P2P 系统中的发送端进行详细说明，其中接 收到的请求数据为帧，紧急度信息 PP 为该帧距离被播放的时刻 Tr，即系统时间。
参考图 7，假设发送端分别从接收端 R1、 R2、 R3 获取了请求 (Fr1， Tr1)、 (Fr2， Fr2)、 (Fr3， Tr3)，以下以 (Fr1， Tr1) 为例叙述发送端的工作过程。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Fr1，Tr1)， 并将其传送到请求管理单元 402 ；由于该请求的数据为帧，而 P2P 中数据的传输以片为单
位，需要找到该帧所对应的片数据，因此，请求管理单元 402 首先查询存储单元 405 中的 “帧 <--> 片” 对应表图 5A，找到 Fr1 对应的片数据，假设为 Pr1，然后将该请求存储于 存储单元 405 中的请求管理表图 7 中，如图，分别将 R1、 Pr1、 Tr1 存入接收端 701、请 求数据 702、紧急度信息 703，并将 (Pr1， Tr1) 发送到优先级计算单元 403 ；优先级计算 单元 403 根据图 7 中的紧急度信息 703 一列对紧急度信息的请求片播放的绝对时间进行排 序，由于 Tr 的值越小，代表请求片距离播放时间越近，因此， Tr 越小，则优先级越高， 在本例中，假设 Tr1 ＜ Tr2 ＜ Tr3，则优先级为 Pr1 ＞ Pr2 ＞ Pr3， Pr1 的优先级最高，因 此优先级计算单元 403 设置表 7 中 Pr1 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存 储单元 405 中的请求管理表中找到优先级最高的请求，将其请求的数据发送到相应的接 收端。
同时，请求管理单元 402 实时更新存储单元 405 中的请求管理表图 7，具体表示 为，随着时间的推移，紧急度信息 703Tr 不会改变，因此能够减轻发送端的运算量。
实施例八
本发明同样可以适用于 C/S 系统。 在 C/S 系统中 ( 如图 1B)，客户端为接收 端， C/S 服务器为发送端，流媒体服务采用流媒体协议如 RTP 进行数据传输，在流媒体 协议中，数据按照其时间顺序被分为一个个的数据包，数据以包为单位进行传输。 如图 2B 所示，视频文件 I 被分为 n 个数据包，这些包可能大小相等也可能不等，每个数据包包 括一定数量的帧。 本实施例参照图 3B、图 5B 和图 7 对 C/S 系统中的接收端进行详细说明，其中 请求的数据为帧，紧急度信息 PP 为该帧距离被播放的时间 ( 紧急度信息也可变化为请求 帧与当前播放帧的 ID 差值、优先级级别，同实施例一的两个变形例 )。
如图 3B 所示，请求获取单元 401 获取从接收端 R1 发送的数据请求 (Fr1，Tr1)， 并将其传送到请求管理单元 402 ；由于该请求的数据为帧，而 C/S 流媒体服务系统以数据 包为单位进行数据传输，需要找到该帧对应的数据包，因此，请求管理单元 402 首先查 询存储单元 405 中的 “帧 <--> 包” 对应表图 5B，找到 Fr1 对应的数据包，假设为 Ir1， 然后将该请求存储于存储单元 405 中的请求管理表图 7 中，如图，分别将 R1、 Pr1、 Tr1 存入接收端 701、请求数据 702、紧急度信息 703，并将请求信息中的 (Fr1， Tr1) 发送到 优先级计算单元 403 ；优先级计算单元 403 根据图 7 中的紧急度信息 703 一列对紧急度信 息排序，由于 Tr 的值越小，代表请求数据包距离播放时间越近，因此， Tr 越小，则优先 级越高，在本例中，假设 Tr1 ＜ Tr2 ＜ Tr3，则优先级为 Ir1 ＞ Ir2 ＞ Ir3， Ir1 的优先级最 高，因此优先级计算单元 403 设置表 7 中 Ir1 的优先级 704 为 P1 ＝ 3 ；数据发送单元 404 从存储单元 405 中的请求管理表中找到优先级最高的请求，将其请求的数据包发送到相 应的接收端。
同时，请求管理单元 402 实时更新存储单元 405 中的请求管理表。
以上各实施例中，将发送装置与接收装置分开进行了说明，但作为应用于网路 的接收发送装置，可以将上述发送装置和接收装置设置在同一终端中，从而实现网络上 的 P2P 文件共享。
另外，在上述实施例中为了便于实现，作为绝对时间使用了当前播放帧的时间 作为请求发出时刻，因为实现装置的处理器处理能力的提高，播放时刻和发出请求的时
刻存在的时间延迟能够被忽略。
另外，在以上各实施例及变形例中，作为紧急度信息，以播放请求片的绝对时 间、播放请求片的时刻 ( 即，系统时间 ) 以及当前片与请求片之间的位置距离为例进行了 说明，但本领域技术人员通过上述实例可知，只要得知当前片和请求片的时间或者位置 信息，能够任意地生成紧急度信息，例如将当前片和请求片的播放时间的两者、或位置 的两者作为紧急度信息，也能够达到同样的技术效果，只是作为优选，作为上述实施例 及变形例，能够进一步降低发送端的计算量，提高处理的效率。 并且，能够利用当前片 和请求片的播放时间和位置信息，生成优先级级别相关的信息，作为紧急度信息。
另外，以上实施例中都是以播放流媒体为例进行的说明，但是，对于其他流媒 体，本发明也同样适用，尤其是对于对大容量流媒体进行数据处理的系统中，例如，压 缩处理，需要连续对流媒体进行操作，因此利用本发明能够及时接收正在处理之后一段 时间内连续的数据块，从而大大提高了处理效率。
另外，在以上实施例中主要以 P2P 网络为例进行了说明，但同样适用于 C/S 方 式的接收发送，不能能够有效利用服务器端的带宽，还能够保证尽可能多的客户端的连 续数据处理，为用户使用提供了方便。