一种移动流媒体的点播方法和播放器的制作方法

文档序号:7704219阅读:147来源:国知局
专利名称:一种移动流媒体的点播方法和播放器的制作方法
技术领域
本发明涉及移动通信网络的流媒体播放技术,尤其涉及一种 移动流媒体的点播方法和播放器。
背景技术
在传统的互联网中,目前流行的P2P (Point to Point点对点)
应用形式涵盖了视频、语音、搜索、下载等多种应用,已成为互联网最大核心 应用。在传统互联网技术与应用飞速发展的同时,移动互联网也不甘落后,随 着无线通信技术的日渐成熟,移动互联网的规模也正在逐步发展壮大。随着无 线带宽的增加,P2P已经自发的走向移动网内。把传统互联网P2P技术的思想 应用到移动/无线网络中来,这是移动互联网发展的必然需求。
目前GPRS的最大传输速率为171kbit/s, EDGE的可达450kbit/s, 3G网络 中的传输速率可以达到2Mbit/s,如果采用HSDPA技术,理论数据传输率最高可 达10M ~ 14Mbps,但平均只能提供2M ~ 3Mbps的下行速度。而对于WiFi( Wireless Fidelity无线宽带),最高带宽为11 Mbps,在信号较弱或有干扰的情况下,带 宽可调整为5.5Mbps、 2Mbps和lMbps,带宽的自动调整,有效地保障了网络的 稳定性和可靠性。但是,移动互联网的传输速率与固定互联网相比,还是有着 很大的差距,因此固定互联网中的P2P应用很难简单地移植到移动互联网环境 中。如图1所示是WiFiP2P网络结构示意图,在WiFi网络中有多个用户节点, 区域管理服务器也是作为一个用户节点存在,区域管理服务器是作为静态PEER 的补偿服务器,同时也是区域中心。内容源管理服务器和中心片库,以及EPG 和版本升级服务器,服务于WiFi网络。该处区域中心包括区域管理服务器和静 态PEER(静态节点),区域管理服务器是用来管理所有用户节点的,而静态节点 就是补充服务器,是用来为用户节点提供补偿服务的。
在移动通信网络中实现P2P多々某体内容共享是一项创新型业务,目前在国 内尚未发现完全一致的竟争项目,产品或服务。但在国际上存在2家较为类似 或接近的服务,分别是爱尔兰NewBay公司的Foneshare业务,美国的SplashData
4公司的SplashBlog,但是这两家公司的移动P2P业务都不支持点播业务。
对于P2P流i某体,由于移动网络的多样性和波动性,Qos ( Quality of Service
服务质量)如何保证是一个比较难解决的问题,本发明针对移动网络的特点,
在移动P2P点播业务的基础上,提出了改进点播业务的Qos的方法
发明内容
本发明的目的在于公开一种移动流媒体的点播方法和播放
器,通过新的流媒体文件内容的分块和重组方法,使得数据的传输能够适应移
动网络的多样性和波动性。
本发明公开了 一种移动流媒体的点播方法,播放器通过点对点方式播放点 播节目,所述播放器将每一个二级分片虚拟地分解成多个三级分片;持续地周 期性地发出分片请求,每次申请一个三级分片的数据,完成一个二级分片的全 部数据以后再申请另一个二级分片;所述播放器接收每个分片请求的回复数据, 并将所述分片请求的回复数据放置于临时緩沖区,每当所述临时緩冲区中的数 据组合成一个完整的二级分片以后,再将所述完整的二级分片写入播放緩冲区。
本发明公开的这种移动流媒体的点播方法,还包括如下从属技术特征 所述播放器在每次发出分片请求时,首先扫描所述临时緩沖区,并才艮据所 述临时緩冲区判断尚未发出分片请求的三级分片再从中随机抽取一个发出分片请求。
所述播放器将每一个二级分片虚拟地分解成多个三级分片时,根据所在网 络的类型和状况确定三级分片的大小,所述三级分片的大小小于或者等于所在 网络的最大传输单元。
所述播放器在每次发出分片请求时,还记录每一个所述分片请求发出的时 间并增加到请求列表中;在所述播放器接收每个分片请求的回复数据的同时, 还将收到回复的分片请求从所述请求列表中删除;所述播放器还按照设定的定 时器周期性地根据每一个分片请求发出的时间判断所述请求列表中是否有分片 请求超时,有则从所述请求列表中删除所述超时的分片请求并重新发出请求。
所述播放器维护一个比特地图,当所述播放器将所述分片请求的回复数据放置于临时緩沖区时,在所述比特地图上记录所述临时緩冲区中每个三级分片
的发出和接收情况。
GPRS网络的三级分片的大小为64个字节;EDGE网络的三级分片的大小为 128个字节;HSPDA网络的三级分片的大小为256字节;WiFi网络的三级分片的 大小为IK字节。
本发明还公开了一种移动流媒体的播放器,通过点对点方式播放点播节目, 包括分片请求发送模块、分片请求接收模块和播放緩冲区模块;还包括将每 一个二级分片虚拟地分解成多个三级分片的虚拟分解模块,和放置所述分片请
求接收模块接收到的分片请求的回复数据的临时緩冲区模块;所述虚拟分解模 块根据所在网络的类型和状况确定三级分片的大小;所述分片请求发送模块持 续地周期性地发出分片请求,每次申请一个三级分片的数据,完成一个二级分 片的全部数据以后再申请另一个二级分片;所述分片请求接收模块接收每个分 片请求的回复数据并存放于所述临时緩冲区模块,每当所述临时緩冲区模块中 的数据组合成一个完整的二级分片以后,再将所述完整的二级分片写入播放緩 冲区模块。
所述分片请求发送模块在每次发出分片请求时,首先扫描所述临时緩冲区, 并根据所述临时緩冲区判断尚未发出分片请求的三级分片再从中随机抽取一个 发出分片请求。
所述播放器还包括,请求列表维护模块,用于记录发出的分片请求以及所 述分片请求发出的时间,并且周期性地定时检查所述请求列表中的分片请求是 否超时,并且删除所述请求列表中超时的分片请求同时重新发出所述分片请求。
所述播放器还包括比特地图维护模块,维护用于记录所述临时緩冲区中每 个三级分片的发出和接收情况的比特地图。
本发明公开的 一种移动流媒体的点播方法和播放器,对流媒体文件进行三 级虚拟分片,在原有切片基础上提高了网络传输的性能。并且针对移动网络的 多样性和波动性,采用了自适应确定三级虚拟分片大小的方法,有效满足了各
6种网络状况的需要,克服了现有P2P系统切片大小固定不变,难以适应移动网 络多样性的问题。在虚拟切片的基础上,本发明还确定了相应的数据请求机制, 满足了播放的需要。


图1是无线宽带P2P网络结构示意图。
图2是本发明的i某体文件分段封装格式示意图。
图3是本发明的数据请求顺序与播放窗口的示意图。
图4是本发明的播放器的结构示意图。
具体实施方式
下面结合附图和具体实施方式
对本发明做进一步详细说明。
移动P2P的点播需要对媒体文件进行切片,切片主要出于两个方面的考虑, 一是安全的考虑,切片后的文件由于对原有文件进行了重组,因此用户难以仿 制。二是出于文件P2P分发的考虑,切片可以保证用户所接收的每个分片都是 音视频同步的,这样用户在接收到几个分片后就可以开始播放。切片过程就是 将媒体文件分割为多个片段(这里称之为一级分片),并将每个片段生成多个固 定大小的分片(这里称之为二级分片),每一分片至少包括一片头和一数据区, 片头包括块描述项和多个帧描述项,数据区用于按照时间戳顺序存放该分片对 应的音视频帧。经过分片处理后,对等节点可以从网络中多个节点取得不同分 块,拼接并恢复媒体流。对等节点是终端。
如图2所示是本发明的々某体文件分段封装格式示意图,如图中所示,每一 个片段中包括多个二级分片,每一个二级分片中包括多个三级分片。在二级分 片中包括块头、载荷区和音视频帧。在二级分片中包括块头区,块头区中的内 容包括块号、块的大小、MD5值、帧个数和帧描述项。载荷区中包括多个音视 频帧。每一个音视频帧中的描述项包括帧的类型、帧的长度、帧偏移和帧时戳。
在上述分片中,块描述项包括块号、块的大小、数据块内的音视频数据 帧的个数,块的MD5值(即块的内容经过MD5加密算法算出来的值),需要44个字节。帧描述项包括帧的类型、该数据帧的字节长度、该数据帧在所属块 内的偏移、该帧的起始播放时间、该帧的结束播放时间,需要25个字节。鉴于 一个块(一个二级分片)中可能包括多个音视频帧,这样一个块中的帧描述项 可能也会有多项,因此一个块中块头所占的字节数最少需要69个字节,因此在 该种分片机制中,二级分片的大小的确定就显得比较重要,如果二级分片过小, 则势必会造成在分片后的数据传输中产生大量的冗余数据传输,从而会增加流 量,导致移动网络中宝贵带宽的浪费,而如果分片过大,则当网络状况不好时, 会造成网络拥挤,影响传输性能。
本发明针对上述问题,提出了在分片的基础之上进行三级虚拟分片的分片 机制,从而可以有效的解决上述问题,并且能够实现根据网络的类型自适应的 进行三级虚拟分片大小的调整,使得分片大小能否与网络的最小传输单元相匹 配,从而提高传输的效率。
所谓虚拟的三级分片,其并不会对二级分片的内容进行任何修改,而是移 动P2P终端之间进行数据交互的单位,即移动终端在每次申请数据时,不再是 以二级分片为单位,而是申请二级分片的一部分数据,比如申请二级分片的前 十六分之一的数据。只有当一个二级分片的所有数据都申请到后,才可以继续 申请其他二级分片的数据。对于每一个二级分片,移动终端会记录该二级分片
分成了多少个虚拟的三级分片,其包含的三级分片的大小,有多少三级分片数 据已经发出请求以及回复了多少三级分片数据。终端就通过该记录实现虚拟分 片,而不需要对二级分片进行实际的切片操作。
一个流媒体文件包含多个一级分片, 一级分片里包含很多二级分片。 对于每个片段,其维护一个BITMAP (比特地图)(称之为一级BITMAP),用 以表示该片段内每个二级分片的存在与否情况,终端之间定期交换该信息,从 而作为数据请求的一种依据。因此,如果分片过小,势必会造成BITMAP数据量 的增加,由于终端之间的BITMAP信息在交互比较频繁,这势必又会造成带宽的 浪费。
8而对于每一个二级分片,其也维护一个BITMAP (称之为二级BITMAP),用 户表示其包括的每个三级分片的存在与否情况,该信息不在终端之间进行交互, 仅仅作为终端在进行数据请求时的依据。
如何进行三级虚拟分片以及如何根据该分片机制进行数据请求,具体实施 方案如下
对于点播节目的发布,用于点播的媒体文件首先经过分片处理器进行分片, 该分片的粒度到二级分片, 一个一级分片即是一个文件,在经过上线操作后, 存放在系统的补偿服务器上面;
终端在开始点播后,对二级分片进行虚拟三级分片,从而相应生成两级 BITMAP,终端之间定期交互一级BITMAP;
终端针对友好节点的网络类型和网络状况,确定三级分片大小。 由于移动互联网网络类型的多样性,对于每种网络类型,由于带宽的不一 样,其最佳传输单位也不一致,因此三级虚拟分片的大小也需要根据网络类型 进行调整。对于GPRS网络,如果三级分片过大,则会导致网络的堵塞,而对于 WiFi网络,如果三级分片过小,则无法充分利用WiFi的传输性能。
本发明针对GPRS, EDGE, HSPDA, WIFI等不同网络,确定了最佳传输单位 MTU (Maxma Transmission Unit最大传输单元),三级分片的大小不能超过MTU 的大小,对于GPRS,确定三级分片的大小为64个字节,EDGE为128个字节, HSPDA为256字节,而WiFi则可以达到1K。
另外,由于移动网络的波动性,有些网络状况比较好的节点在过一段时间 后网络状况可能会变为不好,这时候如果三级分片的大小不进行调整的话,则 可能会导致网络的堵塞,使得网络性能恶化。终端在向某个友好节点进行分片 请求时,会把该请求记录下来,放入到请求列表中,同时将该请求的发送时间 记录下来。终端定时检测请求列表,看请求列表中哪些请求在预设设定的超时 值内还没有返回回来。而对于已经返回的数据,则计算返回时间和请求的发送 时间之间的差值。根据这两种情况来判断网络状况的好坏。如果很多请求在发
9送出去后在超时值内都没有回复,或者回复的时间接近超时值,则说明终端与
该节点的网络状况不好,需要降低三级分片的大小,使得数据包请求的大小适 应网络状况,以免造成网络的更加拥塞。
4. 终端数据请求
如图3所示,终端在进行数据请求时,首先扫描播放緩冲区(接收到的数 据存放的临时緩冲区),看緩冲区中有哪些数据已经申请到,哪些数据发出申请 但是还没有回复,还有哪些数据还没有申请,对于还没有申请的数据,随机抽 取一个进行申请。
为了保持播放緩沖区的统一,这里先将播放緩冲区划分为大小为16K的小 块,然后再将每个16K的块划分为MTU为单位的小块。终端针对播放緩沖区维 护两个BITMAP, —级BITMAP表示16K数据块的存在情况,用于终端之间进行交 互,二级BITMAP用于表示16K分片中每个MTU分片的存在情况,该BITMAP不 进行交互。
终端在请求数据时,扫描二级BITMAP的情况,当发现某个三级分片不存在 时,进行传输请求分配,即对自己所维护的友好节点列表进行扫描,看友好节 点的一级BITMAP中是否有该三级分片的上一级分片数据。如果有,则向该友好 节点发出请求。
鉴于实际切片的块的大小是16K,播放器也是以这个大小为基础进行数据读 取和解析的,因此对于一个16K的块,在其中有几个三级分片发出请求后,则 在下一次数据申请分片过程中应该优先申请该16K中还没有请求的数据,从而 优先保证了 16K数据的完整性。按照该机制,对于一块16K的数据,终端可能 是向多个友好节点申请的。
5. 终端数据接收处理
对于每个申请的16K数据中的三级分片,在其回复后,不立即写入緩冲区, 而是开辟一个临时緩冲区进行放置,当该16K数据回复完整后,再一起写入播 放緩冲区。如图4所示是本发明的播放器的结构示意图,本发明公开的这种播放器,
包括发片请求发送模块、分片请求接收模块和播放緩冲区模块;能够通过点对 点方式播放点播节目。本发明在现有可播放P2P点播节目的播放器的基础做出 改进,还包括,将每一个二级分片虚拟地分解成多个三级分片的虚拟分解模块, 和放置所述分片请求接收模块接收到的回复数据的临时緩冲区模块;所述分片 请求发送模块持续地周期性地发出分片请求,每次申请一个三级分片的数据, 完成一个二级分片的全部数据以后再申请另一个二级分片;所述分片请求接收
模块接收每个分片请求的回复数据并存放于所述临时緩沖区模块,每当所述临 时緩冲区中的数据组合成一个完整的二级分片以后,再将所述完整的二级分片 写入播放緩冲区模块。
当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情 况下,熟悉本领域的技术人员可根据本发明作出各种相应的改变和变形,但这 些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
综上所述,本发明重点面向2. 5/2. 75/3G/WiFi等混合共存的复杂移动数据 网络环境,提供一个移动P2P里视频点播Qos改进方法,给出了三级虚拟分片 的实现方法,从而在原有切片基础上提高了网络传输的性能。还针对移动网络 的多样性和波动性,采用了自适应确定三级虛拟分片大小的方法,有效满足了 各种网络状况的需要,克服了现有P2P系统切片大小固定不变,难以适应移动 网络多样性的问题。在虚拟切片的基础上,确定了相应的数据的请求机制,从 而保证了数据请求能够满足播放的需要。
权利要求
1.一种移动流媒体的点播方法,播放器通过点对点方式播放点播节目,其特征在于,所述播放器将每一个二级分片虚拟地分解成多个三级分片;持续地周期性地发出分片请求,每次申请一个三级分片的数据,完成一个二级分片的全部数据以后再申请另一个二级分片;所述播放器接收每个分片请求的回复数据,并将所述分片请求的回复数据放置于临时缓冲区,每当所述临时缓冲区中的数据组合成一个完整的二级分片以后,再将所述完整的二级分片写入播放缓冲区。
2. 如权1所述的点播方法,其特征在于,所述播放器在每次发出分片请求 时,首先扫描所述临时緩冲区,并根据所述临时緩冲区判断尚未发出分片请求 的三级分片再从中随机抽取一个发出分片请求。
3. 如权2所述的点播方法,其特征在于,所述播放器将每一个二级分片虚 拟地分解成多个三级分片时,根据所在网络的类型和状况确定三级分片的大小, 所述三级分片的大小小于或者等于所在网络的最大传输单元。
4. 如权3所述的点播方法,其特征在于,所述播放器在每次发出分片请求 时,还记录每一个所述分片请求发出的时间并增加到请求列表中;在所述播放 器接收每个分片请求的回复数据的同时,还将收到回复的分片请求从所述请求 列表中删除;所述播放器还按照设定的定时器周期性地根据每一个分片请求发 出的时间判断所述请求列表中是否有分片请求超时,有则从所迷请求列表中删 除所述超时的分片请求并重新发出请求。
5. 如权4所述的点播方法,其特征在于,所述播放器维护一个比特地图, 当所述播放器将所述分片请求的回复数据放置于临时緩冲区时,在所述比特地 图上记录所述临时緩冲区中每个三级分片的发出和接收情况。
6. 如权3、 4或者5所述的点播方法,其特征在于,GPRS网络的三级分片的 大小为64个字节;EDGE网络的三级分片的大小为128个字节;HSTOA网络的三 级分片的大小为256字节;WiFi网络的三级分片的大小为1K字节。
7. —种移动流媒体的播放器,通过点对点方式播放点播节目,包括分片请 求发送模块、分片请求接收模块和播放緩冲区模块;其特征在于,还包括将 每一个二级分片虚拟地分解成多个三级分片的虚拟分解模块,和放置所述分片 请求接收模块接收到的分片请求的回复数据的临时緩冲区模块;所述虚拟分解 模块根据所在网络的类型和状况确定三级分片的大小;所述分片请求发送模块 持续地周期性地发出分片请求,每次申请一个三级分片的数据,完成一个二级 分片的全部数据以后再申请另一个二级分片;所述分片请求接收模块接收每个 分片请求的回复数据并存放于所述临时緩沖区模块,每当所述临时緩沖区模块 中的数据组合成一个完整的二级分片以后,再将所述完整的二级分片写入播放 緩冲区模块。
8. 如权7所述的播放器,其特征在于,所述分片请求发送模块在每次发出 分片请求时,首先扫描所述临时緩沖区,并根据所述临时緩冲区判断尚未发出 分片请求的三级分片再从中随机抽取一个发出分片请求。
9. 如权8所述的播放器,其特征在于,还包括,请求列表维护模块,用于 记录发出的分片请求以及所述分片请求发出的时间,并且周期性地定时检查所 述请求列表中的分片请求是否超时,并且删除所述请求列表中超时的分片请求 同时重新发出所述分片请求。
10. 如权7所述的播放器,其特征在于,还包括比特地图维护模块,维护 用于记录所述临时緩沖区中每个三级分片的发出和接收情况的比特地图。
全文摘要
本发明涉及一种移动流媒体的点播方法和播放器,通过点对点方式播放点播节目,所述播放器将每一个二级分片虚拟地分解成多个三级分片;持续地周期性地发出分片请求,每次申请一个三级分片的数据,完成一个二级分片的全部数据以后再申请另一个二级分片;所述播放器接收每个分片请求的回复数据,并将所述分片请求的回复数据放置于临时缓冲区,每当所述临时缓冲区中的数据组合成一个完整的二级分片以后,再将所述完整的二级分片写入播放缓冲区。本发明通过新的流媒体文件内容的分块和重组方法,使得数据的传输能够适应移动网络的多样性和波动性。
文档编号H04L12/56GK101562635SQ20091010736
公开日2009年10月21日 申请日期2009年5月15日 优先权日2009年5月15日
发明者健 季 申请人:中兴通讯股份有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1