CN1155199C - 万维网浏览器中顺序链接的热对象及连续流视频浏览方法 - Google Patents

Abstract

本发明提供了一种浏览器，它接收称作URL列表的数据类型，该URL列表由一个URL序列组成。该浏览器根据该列表提出URL请求。该浏览器获得关于对URL请求的响应时间的统计数据，并相应地对序列中逐个URL的相继调用进行定时，从而使被链接数据的到达几乎仿真实际的连续流。

Description

万维网浏览器中顺序链接的热对象 及连续流视频浏览方法

技术领域

本发明涉及一种浏览器(browser)，更具体地说，涉及配备有自动处理URL请示序列的功能的浏览器。这种能力允许处理过程把一个非连续流(non-spreeming)服务器仿真成一个连续流服务器。

背景技术

超文本文件(document)是通过超链接与其他文件链接起来的文件。超链接经常作为一段高亮度文本出现在超文本文件中。这段文本通常是一个词或短语，用以描述使用者希望得到的进一步信息的某些信息。当使用者激活超链接时，通常做法是使用鼠标点击它，于是使用者的显示画面被改变，从而显示出被链接的文件，该链接文件通常包含关于所关心的高亮度词或短语的更多信息。超链接使得跟踪各文件间的相互参考变得容易了。超媒体文件是具有多媒体能力的超文本文件。在屏面上的被激活的超链接区域被称作热链(hot-link)。

当今，许多人熟悉超文本的应用，例如通过使用鼠标去点击因特网上的万维网(Web)的主页在计算机显示器上显示的热链。在万维网上的数据是通过URL表确定所在地的。URL代表“统一资源定位器(UniformResource Locator)”。它是用于指定因特网上的对象的标准方法。它指定访问方法和文件(file)的位置(参考：http：//WWW/W3/org/pub/WWW/Addressing)。在万维网上的文件用称作“HTML”的简单的置标语言写成，HTML意思是“超文本置标语言”。在万维网上数据文件(file)格式被指定为MIME格式，MIME代表“多目的因特网邮件扩展”(参考：http：//www.oac.uci.edu/indiv/ehood/MIME/MIME.html)。万维网上的文件格式的一些实例是：.au(可能是最通用的音频格式)，.html(HTML文件)，.jpg(JPEG编码图像)，.mid(Midi音乐格式)，.mpg(MPEG编码视频)，以及.ps(postcript文件)。浏览器是为便于观看和调度万维网上的HTML文件所用的计算机程序。两种最普及的浏览器是网景(Netscape)公司的导航者(Navigator)(参考：http：//www.netscape.com)和微软公司的因特网探路者(Internet Explorer)(参考：http：//www.microsoft.com/ie/default.esp)。它们提供图形用户界面和标准的点击导航方法，并支持HTML文件。

HTML文件中的热对象(hot object)是每个与一唯一的URL链接的对象。例如，一个演示(presentation)可能由一个HTML文件系列组成，其中的每个文件由一个URL链接。演示者可能希望把这个HTML系列顺序地显示出来，每一个HTML文件持续一个预先确定的时间长度。另一个例子出现在一系列视频节目段位于多个URL的情况，这种系列当被链接在一起时组成一段连续的视频节目。于是观看者希望以连续的方式观看这个视频段系列，从而好象观看来自一个服务器的被构成连续流的整个视频节目。

所以，本发明的目的在于向使用者提供一个热对象，它会自动地把请求顺序指向多个URL，这种请求或者是自动地或者是由观看者手工地加以定时。

视频是娱乐方面最主要的主要介质，并迅速地在计算环境中流行起来，且成为计算中的一个关键部分。活动图像具有非常强的信息运载能力，被广泛用于抓取和传递各种复杂场景，如新闻事件、现场采访、科学实验、游览胜地及许多其他场景。但是，视频数据的量通常是很大的。视频文件在计算机中占据大量的存贮空间。举个例子来说，即使采用诸如MPEG-1、Indeo、OuickTime-MOV.及Cinepack等压缩视频格式，存储1分钟视频数据仍然需要大约10MB的存贮空间。

传统的非连续流服务器对等时性请求一般不太敏感。通常，它被设计成最小传输等待，而没有保证等时性的机制。向浏览器发送的速率是不规则的，易造成在用户机器中的重放质量劣化。为避免错误地重放视频文件，通常做法是在开始视频重放开始之前下载全部文件。但这样会给大多数视频文件(通常都很大)带来不可接受的延迟。例如，即使传递速率高达1.5Mb/s，对一个1分钟的视频片段而言，开始播放前的延迟高达60秒。当通道带宽太低而不能支持特定视频的位速率时，对这种做法进行修正是不可避免的。一种这类修正做法是获取下载速率的统计资料，并与视频的位速率一起计算出一个合理的重放起始时间，从而保证整个视频节目在重放时不出现突跳。这种解决方案在一定程度上减小了视频节目请求和重放开始之间的等待时间。当通道带宽大于实时重放所需时间时，非连续流服务器可能会重叠正在接收的播放器的存储器。连续流视频主要是对付这种情况。

与非连续流服务器相反，连续流服务器等时地发送视频流，从而当带宽足够高时能保证视频重放具有平滑的活动画面和声音。连续流服务器发送视频数据时控制其位速率与被编码视频的位速率相匹配。但是，为了协调视频数据的传送，用户计算机中的浏览器必须事先指定一个数据缓冲区，并且需持续地与服务器进行交互操作，以避免缓冲器发生溢出。此外，连续流服务器以顺序方式发送视频数据，故连续流视频文件的缺点在于接收重放系统不能支持随机查导。观看连续流视频节目的使用者必须总是从文件开头看起，最好的情况也只是从缓存区中的那部分文件开始。例如当查导位置之前的全部视频数据都作为连续流发送一遍，当访问的是一个大的视频文件时，这将占用太多的带宽。

发明内容

本发明提供了一种用于接收称作URL序列的数据类型的浏览方法，所述URL序列包括一系列URL，各URL所代表的被分成连续的时间段的视频数据以及重放所述视频数据的预计持续时间，以及一个头段，所述头段中含有关于所述URL的内容的数据类型的信息，所述浏览方法包括下列步骤：发出对URL序列中的URL的请求；根据所述URL序列的所述定时数据对这些请求定时。

本发明还提供了一种用于接受称作URL列表的数据类型的浏览方法，所述URL列表包括一系列URL，所述浏览方法包括下列步骤：根据所述URL列表发出URL请求，得出对上述URL请求的响应时间的统计数据，以及相应地确定调用列表中下一URL的时刻，使链接数据的到达近似地与实际的连续流相仿。

此外，本发明还提供了一种用于将一个非连续流服务器模拟成一个连续流服务器的方法，该方法包括以下步骤：根据URL列表发出URL请求，得出对URL请求的响应时间的统计信息，以及相应地确定调用序列中后续URL的时刻，使链接数据的到达所似地与实际的连续流相仿。

鉴于上述情况，本发明的目的在于提供这样一个浏览器，该浏览器能够将一个非连续流服务器模拟成一个连续流服务器。

本发明的另一个目的在于提供一种将非连续流服务器模拟成一个连续流服务器的方法。

本发明的另一个目的在于扩展一个标准的HTML浏览器的功能，以支持一个新的数据类型URLS(统一资源定位器序列)。

本发明的上述目的和其他目的是这样来实现的：在本发明中，将要作为连续流发送的数据被依次分成许多个段；建立一个URL列表，该URL列表中含有顺序列出的许多个URL；再构筑一个能够从URL列表中的数据自动地产生一系列URL请求的浏览器。

在本发明中，浏览器顺序地访问组成URLS的各个URL，根据通道带宽和URLS中的数据所提供的各种参数来不时地发出各请求。当各URL构成来自视频序列的各连续段而且对各请求的定时适当时，其效果是对连续流视频的仿真。

本发明的浏览器还获取从服务器到来的数据的统计数据，从而确定在哪个时间点上发出下一个URL请求。

举例来说，一个视频连续流被分成许多个长度为1分钟的片段，编码后的视频数据的速率为100Kbps，自服务器至浏览器的带宽为1Mbps。浏览器在播放中的视频在需要用到下一段数据之前200ms就发出URL请求，这样，只有100ms的数据(10Kb)需要进行缓存。本发明中的播放器被编程成这样，即在播放完每一个文件段后，它可以被再次调用，用于继续播放下一片段。这样，浏览器就不必为每一个到来的片段启动一个新的播放器。

本发明中的播放器还支持对每一段的起始位置的随机搜索。另外，该播放器还可以一开始就被打开或从任何段开始播放，但可能要必须先读包含必需的头信息的第一个片段。

为了更完全地描述本发明及其优点，应该阅读下面结合附图所做的详细描述。这些附图是：

附图说明

图1显示出了一个URL的结构；

图2显示出了一个URLS的一个URLS(j)分量的结构；

图3显示出实现最佳实施例所利用的计算机处理系统；

图4是本发明的一个最佳实施例的流程图。

图5示出了本发明的视频浏览器的模块结构。

图6示出了本发明的最佳实施方法中控制模块的执行流程图。

具体实施方式

本发明对一个标准的HTML浏览器的功能进行扩展，以支持一个新的数据类型URLS(统一资源定位器序列)。URLS数据类型的结构由图1给出。它包括URL的一个顺序列表URLS(j)及附加辅助信息，其中脚标j的范围是从1到n，再加上含有头文件的初始头段。头段文件包括关于URL内容的一般特性的数据，其中涉及关于各个后续URL中所含的数据类型的信息。这些数据可以是文本、图像、音频、视频以及其他类型的数据。头段中还包含处理各后续URL中的数据时需要哪种插件(plug-in)或外接件(extra)以及是否需要仿真连续流等信息。本领域技术人员应当知道头段文件中所包含的内容是应用特定的，这些关于URL内容的一般特性的数据可以在具体实现中进行各种改变；并且这些改变不会超出本发明的实质和范围。仿真连续流的浏览器将被描述成是处于连续流方式；否则将称为通常方式。每个URLS(j)包含一个URL，即URL(j)，一个持续时间参数T(j)以及一个代表相应数据量大小的值B(j)。典型情况是，持续时间参数T(j)表示浏览器显示URL(j)处的URL内容的时间长度为T(j)。图2示出了URLS(j)的结构。

本发明可以在任何计算机处理系统(包括例如个人计算机或工作站)上实现。如图3所示，可以被本发明利用的计算机处理系统一般包括存储器101、至少一个中央处理器(CPU)103(只画出一个)、以及至少一个用户输入装置107(例如键盘、鼠标、游戏棒、语音识别系统、或手写识别系统)。此外，该计算机处理系统还包括一个非易失存储器(如ROM)和/或其它非易失存储器装置108(如硬盘)，用于存储操作系统和一个或多个应用程序，这些应用程序被加载到存储器101中并由CPU 103执行。在执行操作系统和应用程序过程中，CPU可以使用存储在非易失存储器装置108和/或存储器101中的数据。此外，该计算机处理系统包括一个连接在CPU 103和显示装置105(例如CRT显示器或LCD显示器)之间的图形适配器104。由CPU 103执行的应用程序和/或操作系统产生图形命令，(例如，画一个图框(或窗口)的命令，显示一个位图图像的命令，变为3维模式的命令或显示视频文件的命令)。这些命令可以由CPU 103执行的应用程序/操作系统来处理，或者由与CPU 103执行的应用程序/操作系统联合工作的硬件来处理，产生适当的象素数据，并使显示装置105相应地被刷新。

此外，该计算机处理系统包括一个与CPU 103相连的通信链路109(如网络适配器或调制解调器)，它允许CPU 103通过通信链路(例如因特网)与其他计算机处理系统进行通信。CPU 103可以通过通信链路109接收CPU 103在执行操作系统和应用程序过程中使用的部分操作系统、部分应用程序或部分数据。

应该指出，由CPU 103执行的应用程序/操作系统也可以完成下面将要描述的本发明的方法。下述方法的一部分或者全部可以被嵌入到与CPU 103所执行的应用程序/操作系统结合工作的硬件中。此外，下文描述的方法可以嵌入到一个分布式处理系统中，从而使这种方法的各部分分布在经由通信链路109链接在一起的二个或多个处理系统之中。

图4显示的是本发明的最佳实施例的流程图。当使用者点击浏览器中出现的HTML页中的一个热对象时，该对象有一个到某个URLS的链接，于是该浏览器调用“读头段”去从该URLS的头段部分提取必要的信息。这一信息被传送到“初始化”模块，该模块基于该头段文件中的信息，使浏览器开始实施为执行这个希望的应用程序所必须的适当功能。例如，如果在URL中的数据是由来自视频连续流的各段组成时，则浏览器将产生出适当的视频解码器和播放器。部分头段信息用于指出是否要按连续流方式重放数据，或者是否要由使用者选择连续流方式或人工方式。例如，一个Lotus Freelance演示可以以二种方式中的任何一种来执行；一个视频演示的建立者可能希望只用连续流方式。在“何种方式”模块中，如果头段指示为连续流方式，则重放方式自动设定为连续流方式；否则，浏览器向计算机屏输出一个询问，提示使用者输入希望执行两种方式中的哪一种来进行重放。使用者的响应是以标准方式用鼠标激活的游标去指定适当的选择并点击鼠标。

当浏览器处于连续流方式时，在不同URL的各段数据之间的传输定时是至关重要的。例如，当各URL包含来自一视频序列的各连续段时，便是这种情况。只有当TD(j+1)+A(j+1)＜T(j)时，连续流才能继续下去，这里

·TD(j)是浏览器发起一个对URL(j)的请求的时刻和来自URL(j)的第一个数据包到达该浏览器的时刻之间的时间延迟；

·A(j)是来自URL(j)的全部数据到达该包的持续时间；即从第一个数据包到达之时至最后一包到达之时之间的持续时间。

在“参数”模块中，浏览器使使用者能选择连续流数据不间断显示的最短持续时间。使用者被提示去选择一个持续时间值T，使得在不可能显示整个节目的连续流时，将持续地显示若干段，每段的持续时间至少为T。构成URLS的各URL被分成段(URL(1)，…URL(A1))，(URL(A1+1)，…，URL(A2))，(URL(A2+1)，…，URL(A3))，等等，从而使T(1)+…+T(A1-1)＜T和T(1)+…+T(A1)＞T，T(A1+1)+…+T(A2-1)＜T和T(A1+1)+…+T(A2)＞T，等等。一般不能保证最后一段的显示满足要求。利用URLS中的数据B(j)，浏览器也确定为存储数据量最大的段所需要的缓存器BUFF的大小；即BUFF＝B(AK+1)+B(AK+2)+…+B(A(k+1))的最大值。然后它分配两个缓存器BUFF1和BUFF，每个的大小都是BUFF。

然后，浏览器取来第一段数据并把它存储在BUFF中。这涉及按顺序请求URL(1)，然后URL(2)，如此下去直至URL(A1)。一旦第一段的全部数据到达，浏览器便开始取来第二段并把它存储在BUFF中。与此同时，浏览器开始显示来自第一段的解码输出，这第一段原先是存在BUFF中的。“等待-自动”模块连续地监视系统中取来段数据的结束和段显示的结束。如果满足连续流约束条件，即TD(j+1)+A(j+1)＜T(j)，则将在显示之前取来数据；否则就不需要这样。当取来数据和显示都已做完时，如果仍然有要取回的段，则浏览器开始取回第3段，它将被存储在BUFF1，并开始显示来自第二段的解码输出，这一段已经存储在BUFF2中。这一处理过程继续下去，两个缓存器交替使用(在一个缓存器中进行存贮，从另一个中进行重放)，直至再没有剩余段要取来为止。然后显示最后一段。

显然，如果连续流条件能满足，那么组成URLS的所有URL的全部内容将按照内容创建者所描述的适当时间顺序显示出来。如果URL的内容组成一个视频序列，那么视频将会从头到尾以连续方式显示出来，就象当使用连续流服务器和能显示连续流的播放器时的典型情况那样。播放器被编程为在显示每段之后，它可以再次被调用去继续显示后续的一段。以这种方式，浏览器不需要对每个要到来的段产生一个新的播放器。

如果浏览器是处于人工方式，则“参数”模块分配两个缓存器BUFF1和BUFF，每个的大小等于最大B(j)。于是浏览器取来在URL(1)中的数据，并将其存入缓存器BUFF。一旦来自URL(1)的全部数据已经到达，则浏览器开始从URL(2)中取来数据，并将其存储在缓存器BUFF中。与此同时，开始显示从URL(1)取来的数据的解码输出。“等待-人工”模块连续监视系统中来自使用者的信号，以开始读取URL(3)的数据，并开始显示从URL(2)取来的数据的解码输出。这个信号通常是这样输入的：当游标位于计算机屏上某适当位置时，用鼠标点击。当检测到这个信号时，如果URL(2)的内容已全部到达，则浏览器真正开始从URL(3)取来数据，并把它们放入BUFF1，同时开始显示从URL(2)取来的数据的解码输出。否则，它一直等待，直至URL(2)的内容全部到达，然后开始从URL(3)取来数据并把它们放入BUFF1，同时开始显示从URL(2)取来的数据的解码输出。这个处理过程继续下去，两个缓存器交替使用，直至再没有剩余段要取为止。然后显示从最后一个URL取来的数据的解码输出。

本发明能很好地适用于观看其压缩数据从服务器传输来的视频节目，而不需事先把全部数据存于本地站点，也不需服务器具有连续流能力。将成为连续流的视频数据被分为构成序列的若干段，建立起了一个URLS，其中每个URL包含一个这样的段。例如，一个60分钟的MPEG编码视频流被分成各1分钟的段。编码视频节目的数据速率是1.5Mbps；所以每个1分钟段被编码成90 Mb(10⁶位)，而整个视频节目被编码成5.4Gb(10⁹位)(或675MB(兆字节))数据。从服务器到浏览器的带宽是3Mbps。浏览器能确定从它请求数据到数据到达之间的时间延迟为20秒。通过通信通道传送1分钟视频节目的时间为30秒。这样，从开始请求1分钟数据段到该段数据全部到达所需全部时间小于50秒，这当然小于1分钟，而1分钟是一段的播放时间。因此满足连续流数据。浏览器分配2个存储器缓存区，每个为12MB，用于暂时存储到达的视频数据，并以交替方式利用它们。

本发明的一个实施方式是可以做成传统浏览器(如网景公司的Navgator)的插件，用来接收URL列表数据。这种URL列表中描述的视频的详细信息，包括视频的大小、时间及每秒的帧数等等。为了访问该视频的随机位置，我们需要将该视频分成一系列小视频文件，这可以由许多视频编辑工具来实现。因此，URL列表中还包括所有视频片段的名称清单及每一段的大小及时间。下面是一个典型的URL列表。

原视频名：         test.mpg

文件大小：         20MB

电影持续时间：     105s

每秒帧速：         30

………

视频段1

文件名：          test1.mpg

文件大小：        1MB

电影持续时间：    5s

视频段2

文件名：          test2.mpg

文件大小：        1MB

电影持续时间：    5s

………

图5示出了本发明的视频浏览器的模块结构。本发明的视频浏览器主要包括4个模块：控制模块、URL列表解析模块、统计模块及视频解码模块。其中，URL列表解析模块被用来读取URL列表文件，得到视频信息；统计模块用于计算各视频段的平均达到时间；视频解码模块则用于进行视频显示。

控制模块是最复杂的部分，它负责列出URL列表，并且控制从网络服务器下载视频的顺序。

图6示出了控制模块的工作流程图。得到URL列表后，控制模块即调用URL列表解析模块来对URL列表进行分析，并且根据每个视频段的大小分配一个数据缓冲器。该数据缓冲器的大小通常与视频段的大小相同。接着，控制模块开始下载第1个视频段，并调用统计模块对到达时间进行计算。当第1个视频段下载完之后，控制模块即调用视频解码模块来播放该视频，并根据URL列表准备下载下一个视频段。如果用户希望从一随机位置开始播放视频，控制模块将进行视频搜索，得到相应的视频段。不行的话它将获得下一视频段。

由于各视频段的到达时间是不可预测的，因此，控制模块将对视频解码器的速度进行控制。如果播放一个视频段的时间要短于下载一个视频段的时间，视频解码模块将有益地减慢播放视频的速度。显然，这样可以在进行视频播放时避免出现不规则的暂停现象。

上面详细描述了本发明的优选实施例，本技术领域内的熟练人员可以不花费创造性劳动在本发明的精神和范围内对本发明进行修改、改进和变形。我们认为这些修改、改进和变型都落入了后面的权利要求书所定义的范围之内。

Claims (4)

1.一种浏览方法，用于接收称作URL序列的类型的数据，所述URL序列包括一系列URL、表示各URL所代表的被分成连续的时间段的视频数据的大小的数据、表示重放所述视频数据的预计持续时间的数据以及一个头段，所述头段中含有关于所述URL的内容的一般特性的数据，其特征在于所述浏览方法包括下列步骤：

发出对URL序列中的URL的请求；

根据所述URL序列的所述表示重放所述视频数据的预计持续时间的数据对这些请求定时。

2.如权利要求1所述的浏览方法，其中发出对URL序列中的URL的请求的步骤包括根据一个所提供的方案自动定时并依赖于URL序列的持续时间数据。

3.如权利要求1所述的浏览方法，其中使用者手工发出对组成URL序列的各URL的请求。

4.一种用于接收称作URL列表的类型的数据浏览方法，所述URL列表包括一系列URL，其特征在于所述浏览方法包括下列步骤：

根据所述URL列表发出URL请求，

得出对上述URL请求的响应时间的统计数据，以及

相应地确定调用列表中下一URL的时刻，使链接数据的到达近似地与实际的连续流相仿。

Images