CN102014143A - 数据接收/发送终端、装置、方法及机顶盒 - Google Patents
数据接收/发送终端、装置、方法及机顶盒 Download PDFInfo
- Publication number
- CN102014143A CN102014143A CN2009101710717A CN200910171071A CN102014143A CN 102014143 A CN102014143 A CN 102014143A CN 2009101710717 A CN2009101710717 A CN 2009101710717A CN 200910171071 A CN200910171071 A CN 200910171071A CN 102014143 A CN102014143 A CN 102014143A
- Authority
- CN
- China
- Prior art keywords
- data
- information
- request
- piece
- urgency
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种数据接收/发送终端、装置、方法及机顶盒,其中数据接收终端,通过P2P网络向其他终端发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从其他终端接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体,其特征在于:在所述数据请求信息中包含表示所需数据块的紧急度的信息。
Description
技术领域
本发明涉及互联网中的数据接收/发送终端、装置、方法及机顶盒,尤其涉及基于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方式的接收发送,不能能够有效利用服务器端的带宽,还能够保证尽可能多的客户端的连续数据处理,为用户使用提供了方便。
Claims (23)
1.一种数据接收终端,通过P2P网络向其他终端发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从其他终端接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体,其特征在于:
在所述数据请求信息中包含表示所需数据块的紧急度的信息。
2.如权利要求1所述的数据接收终端,其特征在于:
根据预计播放所需数据块的时刻,生成所述表示紧急度的信息。
3.如权利要求1所述的数据接收终端,其特征在于:
根据当前正在播放的数据块与所需数据块之间的数据块的数量,生成所述表示紧急度的信息。
4.如权利要求1所述的数据接收终端,其特征在于:
根据从进行数据请求的时刻开始到播放所需数据块的绝对时间,生成所述表示紧急度的信息。
5.一种数据发送终端,根据从P2P网络中的其他终端接收到的、对被划分为多个数据块的流媒体中的数据块进行请求的数据请求信息,向其他终端发送与数据请求信息对应的数据块,其特征在于:
根据所接收到的数据请求信息包含的、表示进行数据请求的其他终端所需数据块的紧急度的信息,来决定发送与该请求信息对应的数据块的优先级。
6.如权利要求5所述的数据发送终端,其特征在于:
所述表示紧急度的信息包括,进行数据请求的其他终端预计播放其所需数据块的时刻,该时刻越早优先级高。
7.如权利要求6所述的数据发送终端,其特征在于:
所述表示紧急度的信息包括,进行数据请求的终端当前正在播放的数据块与所需数据块之间的数据块的数量,该数据块的数量越少优先级越高。
8.如权利要求6所述的数据发送终端,其特征在于:
所述表示紧急度的信息包括,进行数据请求的其他终端从进行数据请求的时刻开始到播放所需数据块的绝对时间,该时间越短优先级越高。
9.一种数据接收装置,通过P2P网络向网络中的数据发送装置发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从数据发送装置接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体,其特征在于,包括:
向数据发送装置发送数据请求信息的请求发送单元;
从数据发送装置接收数据的数据接收单元;
存储接收到的流媒体的数据的存储单元;
播放接收到的流媒体数据的数据播放单元;以及
获取所需数据块的信息和数据播放单元正在播放的数据块的信息,生成表示所需数据块的紧急度的信息,并将所述紧急度的信息附加在数据请求信息中的请求信息生成部。
10.如权利要求9所述的数据接收装置,其特征在于:
在所述请求信息生成单元,根据所需数据块的信息和正在播放的数据块的信息,计算预计播放所需数据块的时刻,或当前正在播放的数据块与所需数据块之间的数据块的数量,或从进行数据请求的时刻开始到播放所需数据块的绝对时间而生成所述紧急度的信息。
11.一种数据发送装置,通过P2P网络从数据接收装置接收对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,并向数据接收装置发送与数据请求信息对应的数据块,其特征在于,包括:
从数据接收装置接收数据请求信息的请求接收单元;
向数据接收装置发送数据的数据发送单元;
从接收到的数据请求信息中解析表示数据接收装置所需数据块的紧急度的信息,并根据该表示所需数据块的紧急度的信息决定向所述数据接收装置发送所需数据块的优先级的请求信息管理单元,
所述表示所需数据块的紧急度的信息包括,数据接收装置所请求的数据块与该数据接收装置正在播放的数据块的信息。
12.如权利要求11所述的数据发送装置,其特征在于:
所述请求信息管理单元,根据所述表示所需数据块的紧急度的信息中包括的预计播放所需数据块的时刻、当前正在播放的数据块与所需数据块之间的数据块的数量、或从进行数据请求的时刻开始到播放所需数据块的时间,来决定向所述数据接收装置发送所需数据块的优先级。
13.一种数据接收方法,是通过P2P网络向网络中的数据发送装置发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从数据发送装置接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体的数据接收装置中使用的数据接收方法,其特征在于,
在进行数据请求时包括如下步骤:
获取所需数据块的信息;
获取正在播放的数据块的信息;
根据所需数据块的信息和正在播放的数据块的信息生成表示所需数据块的紧急度的信息;
根据将所述紧急度的信息附加在数据请求信息中;
向数据发送装置发送所述数据请求信息。
14.如权利要求13所述的数据接收方法,其特征在于:
根据所需数据块的信息和正在播放的数据块的信息,计算预计播放所需数据块的时刻,或当前正在播放的数据块与所需数据块之间的数据块的数量,或从进行数据请求的时刻开始到播放所需数据块的时间而生成所述紧急度的信息。
15.一种数据发送方法,是通过P2P网络从数据接收装置接收对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,并向数据接收装置发送与数据请求信息对应的数据块的数据发送装置中使用的数据发送方法,其特征在于,包括如下步骤:
接收来自数据接收装置的数据请求信息,该数据请求信息中包括表示数据接收装置所需数据块的紧急度的信息,
根据所述表示紧急度的信息决定发送与该请求信息对应的数据块的优先级,
按照优先级的顺序,并向数据接收装置发送与请求信息对应的数据块。
16.如权利要求15所述的数据发送方法,其特征在于:
根据所述表示所需数据块的紧急度的信息中包括的所述预计播放所需数据块的时刻、当前正在播放的数据块与所需数据块之间的数据块的数量、或从进行数据请求的时刻开始到播放所需数据块的时间,决定向所述数据接收装置发送所需数据块的优先级。
17.一种数据接收发送终端,通过P2P网络向网络中的其他终端发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从其他终端接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体,并且,从其他终端接收对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,并向其他终端发送与数据请求信息对应的数据块,其特征在于:
包括如权利要求9所述的数据接收装置和如权利要求11所述的数据发送装置。
18.如权利要求17所述的数据接收发送终端,其特征在于:
在所述请求信息生成单元,根据所需数据块的信息和正在播放的数据块的信息,计算预计播放所需数据块的时刻,或当前正在播放的数据块与所需数据块之间的数据块的数量,或从进行数据请求的时刻开始到播放所需数据块的时间而生成所述紧急度的信息。
19.如权利要求17所述的数据接收发送终端,其特征在于:
所述请求信息管理单元,根据所述表示所需数据块的紧急度的信息中包括的所述预计播放所需数据块的时刻、当前正在播放的数据块与所需数据块之间的数据块的数量、或从进行数据请求的时刻开始到播放所需数据块的时间,来决定向所述数据接收装置发送所需数据块的优先级。
20.一种机顶盒,通过P2P网络向其他机顶盒发送对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,从其他机顶盒接收与数据请求信息对应的数据块,在接收流媒体数据的同时播放该流媒体,其特征在于,具有:
向其他机顶盒发送数据请求信息的请求发送单元;
从其他机顶盒接收数据的数据接收单元;
存储接收到的流媒体的数据的存储单元;
播放接收到的流媒体数据的数据播放单元;以及
获取所需数据块的信息和数据播放单元正在播放的数据块的信息,生成表示所需数据块的紧急度的信息,并将所述紧急度的信息附加在数据请求信息中的请求信息生成部。
21.如权利要求20所述的机顶盒,其特征在于:
在所述请求信息生成单元,根据所需数据块的信息和正在播放的数据块的信息,计算预计播放所需数据块的时刻,或当前正在播放的数据块与所需数据块之间的数据块的数量,或从进行数据请求的时刻开始到播放所需数据块的时间而生成所述紧急度的信息。
22.一种机顶盒,通过P2P网络从其他机顶盒接收对被划分为多个数据块的流媒体数据中的所需数据块进行数据请求的数据请求信息,并向其他机顶盒发送与数据请求信息对应的数据块,其特征在于,包括:
从其他机顶盒接收数据请求信息的请求接收单元;
向其他机顶盒发送数据的数据发送单元;
从接收到的数据请求信息中解析表示其他机顶盒所需数据块的紧急度的信息,并根据该表示所需数据块的紧急度的信息决定向其他机顶盒发送所需数据块的优先级的请求信息管理单元,
所述表示所需数据块的紧急度的信息包括,其他机顶盒所请求的数据块与该数据接收装置正在播放的数据块的信息。
23.如权利要求22所述的机顶盒,其特征在于:
所述请求信息管理单元,根据所述表示所需数据块的紧急度的信息中包括的预计播放所需数据块的时刻、当前正在播放的数据块与所需数据块之间的数据块的数量、或从进行数据请求的时刻开始到播放所需数据块的时间,来决定向所述数据接收装置发送所需数据块的优先级。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101710717A CN102014143A (zh) | 2009-09-04 | 2009-09-04 | 数据接收/发送终端、装置、方法及机顶盒 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009101710717A CN102014143A (zh) | 2009-09-04 | 2009-09-04 | 数据接收/发送终端、装置、方法及机顶盒 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102014143A true CN102014143A (zh) | 2011-04-13 |
Family
ID=43844153
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009101710717A Pending CN102014143A (zh) | 2009-09-04 | 2009-09-04 | 数据接收/发送终端、装置、方法及机顶盒 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102014143A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103684689A (zh) * | 2013-11-29 | 2014-03-26 | 重庆西信天元数据资讯有限公司 | 自检式数据传输方法 |
CN104023278A (zh) * | 2013-03-01 | 2014-09-03 | 联想(北京)有限公司 | 流媒体数据处理方法和电子设备 |
CN104506905A (zh) * | 2015-01-06 | 2015-04-08 | 四川中时代科技有限公司 | 一种内置p2p管理***的嵌入式数字机顶盒 |
CN109962948A (zh) * | 2017-12-22 | 2019-07-02 | 阿里巴巴集团控股有限公司 | 一种p2p任务的处理方法及装置 |
WO2020063381A1 (zh) * | 2018-09-30 | 2020-04-02 | 京东方科技集团股份有限公司 | 数据通信方法、服务器装置、客户端装置和介质 |
CN111385315A (zh) * | 2018-12-27 | 2020-07-07 | 阿里巴巴集团控股有限公司 | 点对点资源下载方法和装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030123460A1 (en) * | 2001-12-27 | 2003-07-03 | Mackiewich Blair T. | User priority mapping in bridged VLANS |
CN101227590A (zh) * | 2007-01-19 | 2008-07-23 | 北京风行在线技术有限公司 | 基于p2p协议的媒体文件点播控制方法及装置 |
CN101404624A (zh) * | 2007-10-03 | 2009-04-08 | 音乐会技术公司 | 对媒体项目的下载进行优先级排序的***和方法 |
CN101471919A (zh) * | 2007-12-29 | 2009-07-01 | 突触计算机***(上海)有限公司 | 基于点对点传输协议的设备中用于下载分片的方法及装置 |
-
2009
- 2009-09-04 CN CN2009101710717A patent/CN102014143A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030123460A1 (en) * | 2001-12-27 | 2003-07-03 | Mackiewich Blair T. | User priority mapping in bridged VLANS |
CN101227590A (zh) * | 2007-01-19 | 2008-07-23 | 北京风行在线技术有限公司 | 基于p2p协议的媒体文件点播控制方法及装置 |
CN101404624A (zh) * | 2007-10-03 | 2009-04-08 | 音乐会技术公司 | 对媒体项目的下载进行优先级排序的***和方法 |
CN101471919A (zh) * | 2007-12-29 | 2009-07-01 | 突触计算机***(上海)有限公司 | 基于点对点传输协议的设备中用于下载分片的方法及装置 |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104023278A (zh) * | 2013-03-01 | 2014-09-03 | 联想(北京)有限公司 | 流媒体数据处理方法和电子设备 |
CN104023278B (zh) * | 2013-03-01 | 2018-08-10 | 联想(北京)有限公司 | 流媒体数据处理方法和电子设备 |
CN103684689A (zh) * | 2013-11-29 | 2014-03-26 | 重庆西信天元数据资讯有限公司 | 自检式数据传输方法 |
CN104506905A (zh) * | 2015-01-06 | 2015-04-08 | 四川中时代科技有限公司 | 一种内置p2p管理***的嵌入式数字机顶盒 |
CN109962948A (zh) * | 2017-12-22 | 2019-07-02 | 阿里巴巴集团控股有限公司 | 一种p2p任务的处理方法及装置 |
CN109962948B (zh) * | 2017-12-22 | 2022-06-03 | 阿里巴巴集团控股有限公司 | 一种p2p任务的处理方法及装置 |
WO2020063381A1 (zh) * | 2018-09-30 | 2020-04-02 | 京东方科技集团股份有限公司 | 数据通信方法、服务器装置、客户端装置和介质 |
CN111385315A (zh) * | 2018-12-27 | 2020-07-07 | 阿里巴巴集团控股有限公司 | 点对点资源下载方法和装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10609136B2 (en) | Continuous scheduling for peer-to-peer streaming | |
US9325786B2 (en) | Peer-to-peer interactive media-on-demand | |
JP5058468B2 (ja) | ストリーミングメディアの消去耐性符号化のための方法、該方法を実行するコンピュータ実行可能命令を記録した媒体、及びシステム | |
JP4676833B2 (ja) | 拡張可能なメディアの分散ストリーミングのシステムおよび方法 | |
CN110177310A (zh) | 一种内容分发***和方法 | |
US8726327B2 (en) | System and method for peer-to-peer live streaming | |
CN109474684B (zh) | 一种获取直播视频流的方法、装置、终端设备及存储介质 | |
CN102014143A (zh) | 数据接收/发送终端、装置、方法及机顶盒 | |
CN101741890B (zh) | 一种实现速率控制的方法、***和设备 | |
CN104581374B (zh) | 一种获取切片文件和生成子m3u8文件的方法、节点及服务器 | |
US20090172179A1 (en) | Networked Transmission System And Method For Stream Data | |
JP2006079606A (ja) | ピアツーピアネットワークでの受信側主導のシステム及び方法 | |
CN102883190B (zh) | 优化分配带宽的点播方法和装置 | |
US20100198977A1 (en) | Automatic live stream trees | |
CN110392020B (zh) | 一种流媒体资源的传输方法及*** | |
FR3029376A1 (fr) | Procede de traitement d'une requete de livraison de donnees, dispositif, module proxy, terminal client et programme d'ordinateur associes | |
CN113301000A (zh) | 数据传输方法、装置、介质及设备 | |
CN101656947B (zh) | 跨异构网络业务共享建立方法、设备及*** | |
CN101964741B (zh) | 一种节点列表发送方法和设备 | |
CN112261146B (zh) | 一种基于消息通信和文件传输的边云协同通信***及方法 | |
CN109040199A (zh) | 一种分发资源数据的方法、***及存储介质 | |
KR101581678B1 (ko) | 전송 순서를 이용한 데이터 공유 시스템 | |
CN101771550A (zh) | 一种p2p网络中获取媒体内容的方法、装置及*** | |
Dan et al. | Delay asymptotics and scalability for peer-to-peer live streaming | |
Famaey et al. | Towards intelligent scheduling of multimedia content in future access networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20110413 |