专利名称：音频和/或视频资料的传输和接收的制作方法
技术领域：
本发明涉及通过远程通信链路对数字编码资料进行传输，从而呈示给用户。
背景技术：
在已知的此类型的系统中，通常称为“流服务器(streamer)”的专用服务器控制将信号传输到用户终端。通常，在该服务器中，将所要传输的资料项目存储在一个文件中；而美国专利5,610,841描述了一种视频服务器，其对分割为“媒体段文件”的信号进行存储。在已经公布的欧洲专利申请EP-A-669,587中，描述了另外一种此类系统，其中终端对其接收缓存器内容进行监视，并在合适的时候，请求服务器对其视频数据率进行调整，从而应对网络拥塞。
发明内容
根据本发明的一个方面，提供了一种用于播放音频或者视频资料的终端，该资料作为表示所述资料的连续时间部分的文件集而存储在远程服务器上，该终端包括远程通信接口，用于与服务器进行通信；缓存器，用于从远程通信接口接收文件；用于播放缓存器内容的装置；以及控制装置，对缓存器的状态作出反应，以生成请求消息，请求对缓存器进行补充的更多文件。
另一方面，本发明提供了一种对数字编码的音频或者视频资料进行传输的方法，包括
将该资料分为多个离散的文件，每一个文件均代表所述资料的连续时间部分；在第一站点，对文件进行存储；在第二站点a)向第一站点发送请求，请求连续的各个文件；b)接收文件；以及c)对文件进行解码，以播放资料。
在权利要求中，指出了本发明的其它的、可选的方面。
下面参照附图对本发明的一些实施例进行描述，附图中图1显示的是所要描述的系统的总体结构；图2显示的是用于此类系统中的终端的方框图；图3显示的是典型的索引文件的内容；图4是一个时序图，解释了一种改进的子文件生成方法；图5显示的是一种改进的结构。
具体实施例方式
图1所示系统的目标是通过远程通信网络向用户传输数字编码音频信号(例如，所记录的音乐或者语音)，传输给用户终端，在此处，将相应的声音播放给用户。但是，如同将在下面将要详细描述的，该系统可以用于传输视频信号，而不是，或者附加于音频信号。在本例中，网络是互联网或者根据超文本传输协议(请参考RFCs 1945/2068)进行操作的其它分组网络，虽然在原理上，也能够使用其它的数字链路或者网络。同时假设音频信号是使用ISO MPEG-1第三层标准(“MP3标准”)以压缩形式进行记录的。然而，也不必要使用此特别的格式。实际上，也不必使用该压缩形式，虽然事实上其是很可取的，尤其是如果可用的比特率有限，或者存储空间有限。在图1中，通过互联网2将服务器1连接到用户终端3，仅显示了其中之一。服务器1的功能是存储数据文件，从用户终端接收传输所要求数据文件的请求，响应于此请求，通过网络将文件传输到用户终端。通常，此类请求的第一部分指示网络传输机制(例如，对于超文本传输协议或者文件传输协议分别是http//或者file//)，后面跟着服务器的网络地址(例如，www.serverl.com)，后面为所请求文件的名称。注意，在给出的实例中，由于打字的原因，此类名称中由“\\”代替“//”。
在这些实例中，假设使用超文本传输协议；这并非是必要的，但是有益于允许使用由该协议所提供的验证和安全特征(诸如安全套接层)。
通常，用于传输MP3文件的服务器采用所谓的流服务器的形式，其包括根据用户终端处的播放要求对数据传输速率进行动态控制、掩蔽由于分组丢失所导致的错误、以及如果允许用户交互操作，则控制服务器和客户机之间的数据流的处理机制。但是此处，服务器1无需具有这些。因此，其仅仅是一个普通的“网络服务器”。
现在描述数据文件在服务器1上的存储方式。假设已经创建了MP3格式的文件，并且要存储在服务器上。假设其是D小调的J.S.巴赫的Toccata(BWV 565)的录音，其通常的演奏时间为9分钟。最初，将其创建为一个单独的数据文件，在普通的流服务器上存储为一个单独的文件。但是，此处，在将其存储到服务器1上之前，将该文件分割为多个较小的文件。我们希望这些较小文件中的每一个都具有与可能是4秒的固定演奏时间相对应的大小。使用诸如MP3的压缩格式，这可能意味着这些文件实际包含不同大小的比特数目。因此，将9分钟时间的巴赫文件分为135个小的文件，每一个具有4秒钟的演奏时间。在本实例中，这些文件的名称包括用于指示其在原始文件中的顺序的序号，例如000000.bin000001.bin000002.bin000003.bin.\.\
000134.bin将文件分为这些较小的子文件的操作，通常由准备将该文件装载到网络服务器1上的人员来完成。(这里使用术语“子文件”，以将其与包含整个记录的原始文件区分开来，然而必须强调的是，对于服务器而言，各个“子文件”就是一个与任何其它文件一样的文件)。下面将更为详尽的对其精确的生成方式进行描述。一旦创建完毕，就以通常的方式将这些子文件上载到服务器上去，就像上载到网络服务器上的任何其它文件一样。当然，文件名也可以包含用于识别特定记录的字符(子文件也可以使用附加信息进行“标签”——当你播放MP3文件时，你能够得到关于作者、版权等的信息)，但是在此实例中，将这些子文件存储在服务器上的专用于该特定记录的目录或者文件夹中，例如，mp3_bwv565。因此，当需要的时候，可以以下面的形式请求子文件http\\www.serverl.com/mp3_bwv565/000003.bin其中，www.serverl.com是服务器1的URL。
对于准备将子文件上载到服务器上的人员而言，针对各个记录，创建一个同样存储在服务器上的链接页面(通常是HTML格式的)也是很方便的(或许其文件名为mp3_wv565/link.htm)。将在后面对其结构和目的进行描述。
对于网络服务器而言，存储一个或多个包含可用记录列表的(html)菜单页面(例如，menu.htm)也是很方便的，其具有到相应链接页面的超级链接。
对于终端，其通常是传统的台式计算机，但是具有用于处理接收所讨论的音频文件的附加软件。如果需要，终端也可以是便携计算机，或者甚至可以嵌入到移动电话中。因此，图2显示了这样的一个终端，其具有中央处理器30，存储器31，磁盘存储器32，键盘33，视频显示器34，通信接口35，以及音频接口(“声卡”)36。对于视频传输，可以使用视频卡代替卡36，或者在其基础之上进行添加。以通常的方式，程序存储在磁盘存储器中，能够由存储器31进行读取，由处理器30运行。这些程序包括通信程序37，用于对html页面进行调用和显示，即诸如NetscapeNavigator或者Microsoft Explorer的“网络浏览器”；还有程序38，此处称为“播放器程序”，其提供了播放根据本发明实施例的音频文件所需的功能。同样，还显示了存储器31的区域39，其用作缓存器。这是一个解码音频缓存器，包含等待播放的数据(通常，缓存器的播放时间为10秒)。音频接口或声卡36可以是通常的板卡，仅用于接收PCM音频，并且将其转换成为模拟音频信号，例如，用于通过扬声器进行播放。首先，我们对使用HTTP和嵌入式或“插入式”客户机时终端读取和播放所需记录的操作进行概述。
1、用户使用浏览器，从服务器1上对菜单页面menu.htm进行读取和显示；2、用户在菜单页面中选择一个超级链接，其使得浏览器从服务器上读取所需记录的链接页面，并且进行显示，在本例中，该文件是mp3_bwv565_link.htm。该页面的实际显示并不重要(除了其可能会包含消息，用于使用户放心，系统正在正常工作)。对此页面，重要的是其包含一个命令(或者“嵌入标签”)，用于在处理器30中调用次级进程，在其中运行播放器程序37。以此方式对次级进程进行调用是众所周知的(此类进程在Netscape系统中称为“plug-in”，而在Microsoft系统中称为“ActiveX”)。此命令还可以包含要传递到次级进程的参数，而在图1中的系统中，该命令包含记录的服务器URL，对于巴赫的记录，其为http\\www.serverl/mp3_bwv565。
3、播放器程序37包括MP3解码器，其操作本身采用通常的方式。这里更重要的其控制功能，如下所述。
4、接收到URL的播放器程序将第一个子文件的文件名添加到该URL，以生成子文件的完整地址，例如，www.serverl/mp3_bwv565/000000.bin。注意到，本系统是基于以上述方式对子文件进行命名而构建的，从而不必将文件名通知给终端。该程序构建对具有此URL的文件的请求消息，并且通过通信接口35和互联网2，将其传输给服务器1。(将URL翻译为IP地址，以及对无效、不完整或者不可用URL的错误报告的处理，采用通常方式，此处不再赘述)。我们设想播放器程序将请求直接发送到通信接口，而不是通过浏览器。服务器通过传输所请求的子文件而进行响应。
5、播放器程序从文件中确定此子文件中使用的音频编码，并且根据相关的标准(在本例中为MP3)，将文件解码还原为最初的PCM值，对此子文件的播放时间作出标记。通常，音频文件在文件的开始包含标识符，其说明所使用的编码方式。然后将解码的音频数据存储在音频缓存器38。
6、播放器程序具有称为播放时间Tp的参数。在本实例中，将其设定为10秒(如果需要，可以由用户进行选择)。其决定了终端所执行的缓冲级别。
7、播放器程序将文件名递增为000001.bin，并且按照上述(4)、(5)步骤，对此第二个子文件进行请求、接收、解码和存储。其重复此处理，直到缓存器的内容到达或者超过播放时间Tp。注意，不必要在缓存器之前进行解码，但是这样简化了处理，因为在将音频解码还原为PCM之后，缓存部分的持续时间就会很清楚。如果各个子文件都是相同的音频播放规格，则可以简化音频缓存器的控制。
8、当到达播放阈值Tp后，将解码的数据从缓存器发送到音频接口36，其通过扬声器(未显示)而播放声音。
9、当在上述的(8)中播放声音时，播放器程序连续地对缓存器的满存状态进行检测，当其低于Tp时，其再次递增文件名，并且从服务器获得下一个子文件。重复这个过程，直到返回“错误未找到文件”。
10、在此过程中，如果缓存器变空，则播放器程序停止播放，直到又有数据到达。
此处优选使用的命名规则是从零开始的固定长度的序号，原因是易于实现，但是只要播放器程序包含(或者被传送了)第一个子文件的名称和能够使其计算后续子文件的算法，或者被传送了文件名的列表，就可以使用任意的命名规则。
注意到，上述的系统没有为用户提供在播放过程中进行干预的机会。也没有提供对缓存器下溢(例如，由于网络拥塞)的补救。因此，现在描述本发明的第二个更为完善的实施例，其提供了下述更多的特征
a)服务器存储两个或者更多版本的记录，其以不同的压缩率进行记录(例如，分别以8、16、24、和32KB/s的(连续)数据率进行压缩)，而播放器程序能够自动地在它们之间进行切换。
b)播放器程序为用户提供控制面板，从而用户可以开始播放，暂停，重新播放(从开始，或者从其暂停处开始)，或者跳转到该记录的不同点(向前或者向后)。
注意，由于无需数据率切换即可进行用户控制，反之亦然，所以这些功能不是相互依赖的。
为了提供数据率切换，准备将文件装载到服务器上的人员通过以不同的数据率对同一个PCM文件进行多次编码，从而准备好数个源文件。然后，他按照前面的方式，将各个源文件分为子文件。可以将这些子文件装载到服务器对应于不同数据率的单独目录中，在下面的示例结构中，目录名中的“008k”、“024k”指的是8KB/s和24KB/s的数据率，其它依此类推。
他也可以创建索引文件(例如，index.htm)，其主要目的是提供可用数据率的列表。
注意，如上所述，由于子文件的长度对应于固定的时间长度，所以各个目录的子文件数目相同。子目录名称包括以KB/s为单位的数据率(三位数字)，加上字母“k”；在本例中，附加了音频采样率(11.025kHz)和单/双声道标记，用于验证。
索引文件包括下面格式的语句<！--Audio＝“024k_ll_s 032k_ll_s 018k_ll_s 016k_ll_m008k_ll_m”-->
(在html文件中(或者可以使用简单的文本文件)，<！--…-->指的是语句作为注释而嵌入)。在图3中显示了典型的索引文件，其中包含了其它的信息LFI是最大子文件数目(即，有45个子文件)，而SL是总播放时间(178秒)。“Mode(模式)”指的是“recorded(录制)”(如此处所示)或者“live(现场)”(将在下面进行描述)。其它的条目或者是不需加以说明的，或者是标准的html命令。
开始，播放器程序从链接文件所指定的目录中请求索引文件，并且将可用数据率的列表进行本地存储，以备将来之用。(其可以清楚地请求此文件，或者仅仅指定目录如果没有指定文件名，则大多数服务器缺省指向index.htm)。然后，其按照前面所述的方式，从索引文件中第一个提到的“数据率”目录—即024k_ll_s中，开始请求音频子文件(或者通过将其修改为该终端指定的缺省数据率，该终端能够越过此步骤)。从此开始，播放器程序对从服务器获得的实际数据率进行测量，对一段时间进行平均(例如，30秒)。其通过对每一个URL请求进行计时而实现这一功能；确定客户端和服务器之间所达到的传输率(每秒钟的比特数目)。随着请求数目的增加，此数字的精确度也得到提高。播放器保持两个所存储的参数，其分别指示当前数据率和测量的数据率。
下列情况会引发数据率的改变a)如果缓存器为空并且测量数据率小于当前数据率，并且测量的缓存器低百分比大于下调阈值(如下所述)，则降低当前数据率；(在缓存器已经为空时，进行改变是有利的，因为声卡没有播放任何声音，并且如果改变了音频采样率、双/单声道或者比特宽度(每个采样中的比特数目)，则有必要进行重新配置)。
b)如果测量的数据率不仅大于当前数据率，而且在给定的时间段中(例如，120秒如果需要，这可以由用户进行调整)，也大于后面的较高的数据率，则提高当前数据率。
缓存器低百分比指的是缓存器容量所占时间小于播放时间的25％(即，缓存器接近于空)的时间百分比。如果将下调阈值设定为0％，则当缓存器为空时，当满足其它条件的时候，系统总是下调。将下调阈值设定为5％(这是我们优选的缺省值)，表示如果缓存器为空，而所测量的缓存器低百分比大于5％时，不进行下调。进一步的缓存器空显然将导致提高所测量的数据率，并且如果不能保持该数据率，则最终缓存器会再次为空，同时缓存器低百分比大于5％。将该值设定为100％表示客户端将永不下调。
播放器程序改变子文件地址的相关部分会影响实际数据率的改变，例如，将“008k”改变为“024k”，以将数据率从8增加到24KB/s，并且改变当前的数据率参数以进行匹配。结果，下一个对服务器的请求就变为请求更高的(或者更低的)数据率，并且从新的目录中读取子文件，进行解码，并且输入到缓存器。在下面的流程图中总结了上述的过程
用户控制由用户通过在屏幕上所提供的下列选项而实现，用户可以通过键盘或者诸如鼠标的其它输入设备进行选择a)开始从步骤4开始，执行上述指定数目的步骤。开始选择了一个记录时，是自动播放，还是需要用户的“开始”指令，这是可选的；实际上，如果需要，可以通过链接文件中附加的“自动播放”参数的方式作出选择。
b)暂停由对MP3解码器的指令实现，用于暂停从缓存器读取数据；c)恢复由对MP3解码器的指令实现，用于恢复从缓存器读取数据；d)跳转由用户实现，指出他希望跳转到记录的哪一部分，例如，通过将光标移动到代表记录总持续时间的显示条上的预定点；然后，播放器确定该点为显示条方向上的x％，并且计算所需的下一个子文件的数目，将其用于下一个请求。在具有125个子文件的巴赫实例中，请求播放记录的20％点，导致请求第26个子文件——即000025.bin。很明显，如果各个子文件均对应于同样的固定持续时间，则此计算就相当简单。我们希望，对于跳转的情况，要暂停解码，并且清空缓存器，从而能够立即发送新的请求，但是这并不是很必要的。
可选的，可以向用户显示文本标签或者索引的列表，用户可以选择(例如，使用鼠标)以进行跳转。这可以通过如下方式实现在终端的存储器中所保留的index.htm文件包含以下形式的行(假设将该信息作为注释嵌入到文档中)<--！OdbitsIndex＝”0:01:44 Wireless”-->.
其中”Odbits”是关键字，用于告诉播放器程序，下面的文本要由程序进行处理；”Index”指示播放器程序所要执行的功能；而引号内的文本包括时间(小时:分钟:秒)，该时间是从开始播放的记录开始。
播放器程序读取index.htm文件，如果其识别出索引命令，则在所显示页面的预定位置显示标签，从而向link.htm页面生成一个消息(“事件”)，其包含处理该事件的命令(通常用Javascript写)，以生成对播放器程序的跳转(包含相应的时间)，而对这些命令的选择进行响应。
下面对将原始文件分割为子文件的处理作进一步的讨论。首先，应该说明的是，如果子文件之后跟着的子文件不会超出原始顺序(如上所述)，则子文件之间的边界位置并不重要。在此情况下，子文件的大小可以是固定的比特数目，或者是固定的播放时间长度(或者二者皆非)，真正的决定仅仅是子文件的大小。当需要考虑跳转时(在时间上，或者在不同的数据率之间)，则有其它的考虑。其中，如同很多类型的语音或者音频编码(包括MP3)一样，按照帧对信号进行编码，子文件应当包含完整数目的帧。对于数据率切换的情况，如果确实不必要，很希望对于各个数据率子文件的边界是相同的，从而所接收到的用于新数据率的第一个子文件，在记录中，是从旧的数据率结束处的最后一个子文件处继续的。为了使得各个子文件播放相同的固定时间间隔(例如，上面提到的4秒)，这并不是实现此目的的唯一方法，但是其的确是最方便的。需要说明的是，根据所使用的编码系统，子文件应当包含完整数目的帧意味着子文件的播放时间会稍有不同。说明，在本发明的实施例中，尽管可用的数据率使用不同的量化级别，并且根据是否以单声道或者双声道进行编码而有所不同，但是所有的数据率均使用相同的音频采样率，从而具有相同的帧规格。下面对使用不同的帧规格时需要说明的问题进行描述。
对于实际的子文件长度，最好应当避免过短的子文件，原因是(a)它们导致更多的请求，从而产生额外的网络业务量；(b)在某些类型的分组网络中(包括IP网络)，由于它们需要由更小的分组来进行传输，从而使得请求处理所占用的系统开销和分组报头相应较大，从而导致浪费。另一方面，在开始播放和/或调用跳转或数据率改变时，过大的子文件需要较大的缓存器，产生额外的延迟，所以也是不利的。介于播放时间的30％到130％之间的子文件大小，或者优选的为播放时间的一半的子文件大小是令人满意的。
根据所讨论的标准，使用计算机编程的方式，能够实现转换子文件的实际处理。或许在单独的计算机上进行这个操作是比较方便的，从该计算机上可以将子文件上载到服务器。
另外一个能够添加的改进是使用更加复杂的子文件命名规则，使未授权人员更难于对子文件进行拷贝并在另一台服务器上提供这些子文件，从而提高安全性。一个例子是通过使用伪随机序码发生器，例如，生成下列形式的文件名称01302546134643677534543134.bin94543452345434533452134565.bin在此情况下，播放器程序将包含相同的伪随机序码发生器。服务器发送第一个文件名，或者可能为4位的“种子”，而播放器中的发生器能够使其同步，并且以正确的序列生成所需要的子文件名。
在数据率切换的上述例子中，所使用的索引数据率具有相同的帧规格，具体而言，他们使用11.025KHz下采样的PCM音频的MP3编码以及1152个采样的(PCM)帧规格。如果要在具有不同帧规格的MP3(或者其它)记录之间实现数据率切换，由于要求子文件应该包含完整数目的帧，从而会引发问题，原因是此时的帧边界不一致。通过下面改进的创建子文件的处理，能够解决此问题。尤其应当说明的是，此处理能够用于需要数据率切换的任何情况，并且不限于上述讨论的特定的传输方法。
图4示意地显示了音频采样序列，基于此，通过边界标记(在图中)B1、B2等，对连续的4秒段进行划分。在11.025KHz的采样率下，在各个段中有44,100个采样。
1.对音频进行编码，在边界B1处开始，逐帧进行，以创建MP3子文件，连续进行，直到对具有至少4秒的总持续时间的完整数目的帧编码完毕。使用1152个采样的帧规格，4秒对应于38.3个帧，所以实际上对代表39个帧的子文件S1进行编码，代表总的持续时间为4.075秒。
2、从边界B2开始，以相同的方式，对音频进行编码。
3、每次从4秒边界开始重复上述操作，从而，以此方式，为所要编码的整个音频序列生成一组重叠的子文件。最后的段(其将短于4秒)之后当然不跟随任何东西，所以填入零(即静音)。
以相同的方式，对使用不同帧规格的其它数据率进行编码处理。
在终端，控制机理不变，但是对解码和缓存处理进行修改1、接收子文件S1；2、对子文件S1进行解码；3、仅将解码音频采样的第一个四秒写入缓存器(丢弃其它的)；4、接收子文件S1；5、对子文件S1进行解码；6、仅将解码音频采样的第一个四秒写入缓存器；7、继续对子文件S3等进行处理。
以此方式，确保所有数据率的子文件集的子文件边界对应于原始PCM采样序列的相同点。
因此，在进行编码之前，除了最后一个4秒之外，利用后续4秒的音频采样对每个4秒进行填充，从而使子文件大小变成完整数目的MP3帧。如果需要，所填充的采样可以从前一个4秒的末端取，而不是(或者同时)从下一个4秒的开始取。
注意，MP3标准允许将某些信息从一个音频帧转移到另外一个音频帧(通过众所周知的“比特蓄积(bit reservoir)”方案)。在此，即使在子文件内部可以接受该方法，而在子文件之间就不可接受了。然而，由于该标准本质上不允许在记录末尾或者开始进行这样的转移，所以通过分别对各个子文件进行单独编码，就好像其是单个的记录一样，可以很容易地解决此问题。
对于音频接口36的操作而言，采样率的改变(以及在单声道和双声道之间的切换)具有一些实际的意义。尽管很多通常的声卡能够在不同的设定范围内进行操作，但是需要重新设定，以改变采样率，从而这必然会引起音频输出的中断。因此，在进一步的改进中，我们认为声卡能够在所期望的最高采样率下连续工作。当播放器程序在较低的采样率下为缓存器提供数据时，在缓存器之前或者之后，将此数据上采样为此最高数据率。类似的，如果通常以双声道模式对声卡进行操作，则并行地输入解码单声道信号，以为声卡输入端的左、右信道同时提供信号。还有，如果解码信号的每个采样中的比特数目低于声卡所期望的，则通过插入零而增加比特的数目。
前面早时所讨论的用于将数据率自动向下转换的标准，仅在缓存器下溢的时候才引起数据率的降低(从而引起输出中断)，我们注意到，在这个改进中能够避免此类中断，最好有一种标准，能够预测下溢并在大多数情况下避免下溢。在此情况下，将忽略上面提到的三个“与”条件中的第一个(即，缓存器为空)。
在所描述的系统环境中，所提供的另外一个特征是，对诸如副标题或者静态图像(实质是放映幻灯片)之类的可视信息的显示是伴有声音的。
可以通过如下方法进行实现(a)所要显示的文档(index.htm)包含格式化信息，该信息指明了该可视信息要在页面上出现的位置。
(b)index.htm文件包含以下形式的行(假设该信息是作为注释嵌入到文档中)<！--OdbitsSubtitle＝″0:1:01 Subtitle text″-->.
<！--OdbitsImage＝″0:2:04 http//………/picture.jpg″-->.其中″Odbits″是关键字，用于告诉播放器程序，下面的文本要由程序进行处理；″Subtitle″或″Image″指示播放器程序所要执行的功能；而引号内的文本包括时间(小时:分钟:秒)，该时间是从开始播放的记录开始，如有可能，后面跟着预定图像的实际副标题或者URL。
(c)播放器程序计算实际时间，为当前子文件索引和子文件长度之积，以当前子文件所播放的时间进行递增。
(d)播放器程序对实际时间和嵌入到index.htm文件中的时间进行比较，当相互匹配时，返回一条消息到link.htm页面(其调用播放器)。将此消息称为“事件”。link.htm页面如何处理该事件由书写link.htm页面的人决定。
(e)对于副标题，link.htm页面包含可执行命令(通常以Javascript进行书写)，其从index.htm文件读取副标题文本，并且将其在预定位置进行显示，从而对事件做出响应。
(f)对于图像，link.htm页面包含命令，以对事件做出响应，该命令从index.htm文件中读取图像的URL，生成请求消息，请求对具有该URL的图像进行下载，并且在页面的预定位置进行显示。此下载在请求了该图像时进行，可选的，可以为用户提供具有预先上载的图像文件的选项。如果用户接收了此选项，则在播放任何音频之前，播放器程序将对所列的所有图像文件进行下载，并且将其存储在本地高速缓存中。
可以将相同的原则应用于视频记录的传输，或者，具有伴随声道的视频记录。在较为简单的情况下，当只有一个记录时，该系统与音频情况有所不同，仅仅在于该文件为视频文件(例如，H.261或者MPEG格式)，并且播放器程序包含视频解码器。将文件分割为子文件的方式没有改变。
对于音频的情况，与不同的数据率相对应，有两个或者更多的记录，由上述的控制机制进行选择。同样，可以提供另外的记录，对应于诸如快进和快退之类的不同重放模式，该模式可以由上述的用户控制程序的扩展进行选择。同时，可以遵循文件和目录命名的系统惯例，例如，使得播放器程序能够通过修改子文件地址而对快进命令作出反应。
然而，如果允许切换或者跳转，那么对于文件分割而言，视频记录的传输具有更多的含义。对于对图像的各个帧单独进行编码的记录情况，子文件包含完整数目的图像帧就足够了。但是，如果使用了涉及帧间技术的压缩方法，情况就更加复杂了。一些此类系统(例如，MPEG标准)生成独立编码帧(“内帧”)和预测编码帧的混合帧；在此情况下，各个子文件应当优选的以内帧开始。
对于诸如ITUH.261标准的帧间编码系统(其不包含频繁的、规律的内帧)，这是不可能的。这是因为，以数据率切换为例，如果某人要请求较高比特率记录的子文件n，其后紧跟较低比特率记录的子文件n+1，则较低比特率子文件的第一个帧会在帧间的基础上，利用较低数据率记录的子文件n的最后一个解码帧进行编码，但终端当然不会有这个解码帧，其具有较高数据率记录的子文件n的最后一个解码帧。从而，会产生解码器的严重错误跟踪。
对于在正常播放和快放模式之间进行转换的情况，事实上情况有所不同。例如，在以正常速度的5倍进行快放时，每隔5帧进行解码。从而，大大降低了帧间的相关性，而帧间编码就毫无吸引力了，所以通常把快放序列编码为内帧。所以，从正常播放到快放进行转换没有问题，原因是可以很容易地对内帧进行解码。但是，当转换到正常播放时，会再次出现错误跟踪问题，原因是此时终端以预测编码帧进行工作，而其不具有先前帧。
在任一情况下，通过利用在我们的国际专利申请WO 98/26604(在美国授权为6,002,440)中记载的原理，能够解决这个问题。这包括对帧的中间序列进行编码，该中间序列在前一序列的最后一帧和新序列的第一帧之间起到了联系作用。
现在，以快进操作(快退操作与此类似，但是恰恰相反)为例对本操作进行描述。在本实例中，假设根据H.261标准，以96KB/s，对9分钟的视频序列进行编码，同时，全部按照H.261内帧，以正常数据率的5倍进行编码，并且将文件分为4秒的子文件。此处，4秒指的是原始视频信号的播放时间，而不是快进播放时间。使用与上面所使用的命名规则类似的命名规则，这些子文件为
其中，“name(名称)”指的是用于识别特定记录的名称，“x1”指的是正常数据率，而“x5”指的是正常数据率的5倍，即快进。
对于播放器程序，为了从正常播放转换到快进，所必需的仅仅是将子文件地址修改为指向快进序列，例如Request mpg_name/096k_x1/000055.bin后面跟着Request mpg_name/096k_x1/000056.bin为了构建用于转换回正常播放的连接序列，有必要为每一个可能的转换构建一个连接子文件。如同在上面提到的，在我们的国际专利申请中，对于连接而言，三个或者四个帧的序列通常就足够了，所以简单的实现方法就是，构建仅有4帧时间长度的连接子文件，例如
从而，通过一系列的请求而实现切换，例如Request mpg_name/096k_x5/000099.binRequest mpg_name/096k_5＞1/000099.binRequest mpg_name/096k_x1/000100.bin按照如下方式生成连接子文件
●对快进序列进行解码，以获得子文件99的最后一帧的解码版本，(每秒25帧，这将成为原始视频信号的第100,000帧)。
●对正常序列进行解码，以获得子文件100的第一帧(即，第100,001帧)的解码版本。基于所解码的帧100,000，利用H.261帧间编码将这一帧重新编码4次，作为初始的参考帧。
●因此，当解码器已经对快进子文件进行解码时，后面紧跟连接子文件，其将正确地重新构建帧100,000，并且能够对正常(x1)帧进行解码。顺便提及，将同一帧进行数次编码是因为如果仅作一次，那么会由于H.261的量化特性而导致生成很差的图像质量。
可以将同样的处理用于数据率切换(虽然现在在两个方向上均需要连接子文件)。然而，注意到，如上所述，连接子文件将导致四帧时间的图像冻结，即(以每秒25帧)160ms。在从快进转换到正常播放时，这是可以接受的，事实上，此时可能正要选择清空缓存器。对于数据率切换，这可能会，也可能不会被主动的接受。因此也可以构建4秒的连接序列。此时请求序列如下mpg_name/096k_x1/000099.binmpg_name/096/128_x1/000100.binmpg_name/128k_x1/000101.bin在该情况下，可以通过以解码的96KB/s帧100,000作为参考帧，对解码的128KB/s序列的第五个解码帧进行四次重新编码，而构建连接子文件；或者以解码的96KB/s帧100,000作为参考帧，对解码的128KB/s序列的前4帧进行编码，而构建连接子文件。在两种情况下，连接子文件的其余96帧将是128KB/s子文件的拷贝。
所要传输的文件称为“记录”。然而，在开始传输之前，对所有的音频或者视频序列进行编码，或者所有的音频或者视频序列均已存在是不必要的。因此，需要计算机，用于接收有效输入，使用选定的编码方法对其进行编码，并且不停地生成子文件，将其上载到服务器，从而，当在服务器上有子文件时，就可以开始传输。
本传输系统的一个应用是语音消息系统，如图5所示，其中再次显示了服务器1，网络2，和终端3。语音消息接口4用于接收电话呼叫，例如，通过公共交换电话网络(PSTN)5，以对消息进行记录、编码，并且将其分割为子文件，并且将子文件上载到服务器1，在此，能够通过上述的方式对其进行访问。可以选择的是，可以使用第二接口6，其以与终端3类似的方式进行操作，但是由远程电话5通过PSTN进行远程控制，然后，将要播放的音频信号发送给该接口。
可以将同样的系统用于实时音频(或者视频)输入。在某种程度上，这也是一种“记录”，差别主要是在结束记录之前，就开始了传输和播放，尽管实际上，由于在对至少一个子文件进行记录并且上载到服务器1之前，必须进行等待，从而造成了固有延迟。
该系统能够以上述方式进行工作，除了不能满足用户所希望的从现在开始进行播放，即从最新创建的子文件开始播放，而是从开始处进行播放之外，还是很令人满意的。
对于长的音频序列，可以选择删除旧的子文件，以节省存储空间对于连续的输入(即，每天24小时)，这将是不可避免的，不仅如此，还需要对子文件名进行重新使用(在我们的原型系统中，使用000000.bin到009768.bin，然后重新从000000.bin开始)，从而使用新的子文件连续地覆盖旧的子文件。确保从最新的子文件进行传输的一个简单方法是，在索引文件中包含附加命令，用于引导播放器程序通过请求合适的子文件而开始播放。然而，这也有缺点，即必须对索引文件进行频繁的修改，理论上，每生成一个新的子文件，就修改一次。因此，我们提出了一种方法，其中，播放器程序按照下面的方式对服务器进行扫描，以寻找开始的子文件。在索引文件中，将“Mode(模式)”参数设定为“live(实时)”，以触发播放器程序调用此方法。对LFI进行设定，以指示所可以存储的子文件的最大数目，即9678。该方法包括下面的步骤，并假定(约定的)已经确定了各个子文件的“最后修改的”时间和日期。当使用HTTP协议时，可以通过使用HEAD请求实现此目的，其不会导致对所请求的子文件进行传输，而是仅仅对用于指示将子文件写入服务器的时间的HEAD(报头)信息进行传输，如果不存在，则为零。将此时间表示为GetURL(LiveIndex)，其中LiveIndex是所述的子文件的序号。在“//”之后是注释。
<pre listing-type="program-listing">1 LFI＝9768//从index.htm文件中读取 liveIndex＝LFI/2 StepSize＝LFI/2 LiveIndexModifiedAt＝0；//开始时间10ThisIndexWasModifiedAt＝GetURL(LiveIndex)；20If(StepSize＝1) { //LiveIndexModifiedAt包含文件写入时间，如果没有文件，则为零。LiveIndex包含索引。
goto 30 } StepSize＝StepSize/2 If(ThisIndexWasModifiedAt＞LiveIndexModifiedAt) {LiveIndexModifiedAt＝ThisIndexWasModifiedAt；LiveIndex＝LiveIndex+StepSize }else { LiveIndex＝LiveIndex-StepSize } Goto 10<!-- SIPO <DP n="22"> --><dp n="d22"/>30FINISH</pre>在找到LiveIndex之后，就要跳返Tp(播放时间)，开始作出请求，以从该处填充音频缓存器。以正常方式开始进行播放。
一旦结束记录，如果需要，对索引文件进行修改，以将“Mode(模式)”设定为“recorded(记录)”，以及任意的长度参数。
如果需要，播放器程序能够周期性地进行检查，以查看索引文件是否从“live(实时)”改变为“recorded(记录)”，如果经过改变，则转换到“recorded(记录)”播放模式。
现在，对一种更为简单和快速的对“最新的”子文件进行识别的方法进行描述，首先假设单一连续的子文件编号序列。
1.终端对第一个子文件(例如000000.bin)发出HEAD(报头)请求；2.服务器通过发送该文件的报头而作出应答，并且包含该文件最后修改的日期和时间(MODTIME)，以及发送应答的日期和时间(REPLYTIME)(这两者均为标准的http字段)。
3.终端通过对两个时间进行相减(ELTIME＝REPLYTIME-MODTIME)，而对经过时间(ELTIME)进行计算，并且根据子文件的播放时间(在这些实例中，为4秒)，对其进行分割，以得到LIVEINDEX＝ELTIME/4。
4.终端计算具有此索引的子文件的文件名。
5.终端发送具有此文件名的HEAD(报头)请求，如果需要，则接着请求各个文件名，直到其接收到零(未找到文件)，基于此，则认为已经找到了最新的子文件，即“当前子文件”。
6.终端开始从点J1(在前面的流程图中所给出的)开始，开始请求文件。
本方法比上述用于循环计数的子文件的方法要快。注意，只要保存了开始的子文件，则可以删除旧的子文件，以降低存储要求。然而，能够对本方法进行修改，以适应重新使用的文件名(循环地址)，但是需要
(i)不重新使用开始的子文件名(例如，000000.bin)，从而，总能够在步骤2提供报头信息。因此，对于子文件009768.bin的情况，子文件009768.bin后面跟的是子文件000001.bin。
(ii)在步骤3所计算的LIVEINDEX采用模9768(即ELTIME/4的值除以9768的余数)。
(iii)删除子文件后总会生成新的子文件，从而，在最新的子文件和最早删除的子文件之间不存在新的子文件名，从而在步骤5会发生所期望的“未找到文件”应答。
当以比记录操作稍快或者慢的速度对播放进行操作时，可能会有危险。为了防止前面所说的危险，可以安排播放器程序对其所接收的各个子文件进行检查，以确认其是否具有比其前一个子文件更新的时间，如果不是，则丢弃该子文件，并且重复进行请求(或许3次)。如果这些请求不成功，则检查索引文件。
如果播放滞后于记录，这可以通过播放器对服务器进行随机的检查，以确认存在大量的比当前所请求的子文件更新的子文件而进行识别，而如果存在这样的子文件，则启动“紧追”处理，即有规律地丢弃少量的数据。
权利要求
1.一种用于播放音频或者视频资料的终端，该资料以表示所述资料的连续时间部分的文件集的形式存储在远程服务器中，该终端包括远程通信接口，用于与服务器进行通信；缓存器，用于从远程通信接口接收文件；以及用于播放缓存器的内容的装置；所述终端的特征在于控制装置，其确定所要请求的更多文件的地址，并且响应于缓存器的状态生成包含这些地址的请求消息，以请求对缓存器进行补充的更多文件。
2.根据权利要求1的终端，其在操作上安排为在将文件存储在缓存器之前对其进行解码。
3.根据权利要求1或2的终端，包括用于生成一系列试请求，以识别最新的文件，并且从所识别的子文件开始解码的装置。
4.根据权利要求1、2或3的终端，其与存储了多个文件集的服务器一起使用，这些文件集对应于不同的传输模式，该终端包括装置，其规定后续的请求消息应该从不同于正在进行的请求所涉及的文件集的文件集中请求文件，从而影响模式切换。
5.根据权利要求4的终端，其与服务器一起使用，其中所述文件集中的至少一些对应于不同的数据率，其中终端包括用于监视所接收数据率的装置；在所测量的数据率低于当前所请求文件所属的文件集所需的数据率时，模式切换装置规定后续的所述请求消息应该从对应于较低数据率的文件集中请求文件。
6.根据权利要求4或5的终端，其与服务器一起使用，其中所述文件集的至少一些对应于不同的数据率，其中终端包括用于监视所接收数据率的装置；与当前所请求的文件所属的文件集的数据率相比，当所测量的数据率能够支持对具有更高数据率的文件进行传输时，切换装置规定后续的所述请求消息应该从对应于较高数据率的文件集中请求文件。
7.根据权利要求4、5或6的终端，其与服务器一起使用，其中所述文件集中的至少一些对应于不同的播放模式，其中终端包括从终端的用户处接收命令的装置，以执行从当前播放模式到对应于该命令的预期播放模式的所述模式切换；以及当接收到命令时，模式切换装置规定后面的所述请求消息应该从对应于所述预期播放模式的文件集中请求文件。
8.根据权利要求1到7中任何一项的终端，用于在根据权利要求19到22中任何一项所述的方法中使用，其中，当接收到文件时，终端对文件进行解码，并且丢弃所解码资料中对应于后续部分的所述开头部分。
9.根据权利要求4到7中任何一项的终端，其与服务器一起使用，该服务器以视频记录的形式对所述资料进行存储，至少一些所述文件的至少一些帧已经利用帧间编码进行了编码，其中，在生成从不同文件集中请求文件的请求消息之前，终端生成一个请求消息，请求用于解码器跟踪校正的文件。
10.根据上述权利要求中任何一项的终端，其中，根据预定的算法为文件分配地址，并且对于所述的请求消息，该终端包括用于根据所述算法计算包含在请求消息中的地址的装置。
11.一种对数字编码的音频或者视频资料进行传输的方法，包括将该资料分割为多个离散的文件，每一个文件均代表所述资料的连续时间部分；在第一站点对文件进行存储；在第二站点a)向第一站点发送请求，请求连续的各个文件；b)接收文件；以及c)对文件进行解码，以播放资料。
12.根据权利要求11的方法，其中将资料存储在缓存器中，并且根据缓存器的状态生成请求消息。
13.根据权利要求12的方法，其中，在解码之后，将资料存储在缓存器中。
14.根据权利要求11、12或13的方法，包括在第二站点处生成对第一文件的试请求，从第一站点接收应答，该应答包括表示第一文件的初始时间和所述应答的时间的数据，并且由这些数据估计第一终端中最新文件的估计身份。
15.根据权利要求11、12、13或14的方法，包括在第二站点处生成一系列试请求，以识别第一终端的最新文件，并且从所识别的文件开始所述的解码。
16.根据权利要求11到15中任何一项的方法，包括存储多个文件集，这些文件集对应于不同的传输模式，并且包括在第二站点处规定后面的请求消息应该从与正在进行的请求所涉及的文件集不同的文件集中请求文件，从而影响模式切换。
17.根据权利要求16的方法，其中，至少某些所述的文件集对应于不同的数据率，包括在第二站点处对所接收的数据率进行监视；当所测量的数据率低于当前请求的文件所属的文件集所需的数据率时，执行模式切换，规定后面的所述请求消息应该从对应于较低数据率的文件集中请求文件。
18.根据权利要求16或17的方法，其中，至少某些所述的文件集对应于不同的数据率，包括在第二站点处对所接收的数据率进行监视；与当前所请求的文件所属的文件集的数据率相比，当所测量的数据率能够支持对具有较高数据率的文件进行传输时，执行模式切换，规定后面的所述请求消息应该从对应于较高数据率的文件集中请求文件。
19.根据权利要求16、17或18的方法，其中，至少某些所述的文件集对应于不同的播放模式，其中第二站点包括从第二站点的用户处接收命令，以执行从当前播放模式到与该命令所对应的预期播放模式的所述模式切换的装置；以及当接收到命令时，模式切换装置规定后面的所述请求消息应该从与所述预期播放模式相对应的文件集中请求文件。
20.根据权利要求11到19中任何一项的方法，其中，所述的资料为音频资料，其中a)使用具有帧结构的音频编码方法对文件进行编码；b)将资料分割为多个离散文件的步骤包括在概念上将资料分为多个时间部分，并且通过对各个时间部分及其后续部分的开头部分进行编码，生成除最后一个之外的各个所述文件，这些部分一起表示完整数目的帧；c)在解码之后，丢弃对应于后续部分的所述开头部分的解码资料部分。
21.根据权利要求11到19中任何一项的方法，其中，所述的资料为音频资料，其中a)使用具有帧结构的音频编码方法对文件进行编码；b)将资料分割为多个离散文件的步骤包括在概念上将资料分为多个时间部分，并且通过对各个时间部分和紧接在前的时间部分的末尾和/或紧接在后的时间部分的开头进行编码，从而生成所述文件中的至少一些，这些末尾和/或开头部分与所述的一个时间部分一起构成了完整数目的所述帧结构的帧；以及c)在解码之后，抛弃对应于所述紧接在前时间部分的末尾和/或所述紧接在后时间部分的开头的解码资料部分。
22.根据权利要求20或21的方法，其中，所述的文件集包括第一文件集和第二文件集，第一文件集的帧长度与用于对第二文件集进行编码的帧长度不同，而对两者而言，时间部分的划分是相同的。
23.根据权利要求20、21或22的方法，当从属于权利要求13时，对应于所述后续部分的所述开头部分的解码资料部分不存储在缓存器中。
24.根据权利要求16的方法、或者权利要求17到23中任何一项从属于权利要求16时，其中，所述资料是视频记录的形式，至少某些所述的文件的至少某些帧已经使用帧间编码进行了编码，并且包括在生成从不同的文件集中请求文件的请求消息之前，在第二站点处生成一个请求消息，请求用于解码器跟踪校正的文件。
25.根据权利要求11到24中任何一项的方法，其中，根据预定的算法为文件分配地址，并且该方法包括根据所述的算法，在第二站点处计算要包含在请求消息中的地址。
26.根据权利要求25的方法，其中，所述的算法根据关键码生成地址，该方法包括将关键码传输到第二站点的步骤，以供用户计算地址。
27.根据权利要求26的方法，其中，所述的算法根据伪随机序列而生成地址。
28.根据权利要求27的方法，其中，所述的算法根据伪随机序列而生成地址，而所述关键码是用于设定伪随机序列起始点的“种子值”。
29.根据权利要求11到28中任何一项的方法，其中在第二站点包括如下步骤(a)从第一站点接收一个列表，该列表包含时间和定义要在这些时间执行的动作的数据；(b)计算相对于资料开始的时间，该时间由当前播放点表示；(c)对所计算的时间和列表中的时间进行比较，在匹配时，生成包含用于启动所述动作的各个数据的命令。
30.根据权利要求29的方法，其中，该动作包括显示子标题。
31.根据权利要求29或30的方法，其中，该动作包括显示图像。
32.根据权利要求31的方法，包括向第一站点发送一个请求，请求由所述数据标识的图像，并且将图像存储在第二站点处，直到用于显示。
全文摘要
通过将资料分割为一系列的子文件，终端独立地请求每一个子文件，通过远程通信链路(2)把记录的音频或者视频资料从服务器(1)传输到终端(3)，从而能够控制传输的速率。可以对在代表不同数据率的传输模式的不同子文件集之间进行切换做出规定。
文档编号H04N7/24GK1481643SQ0182055
公开日2004年3月10日 申请日期2001年12月14日 优先权日2000年12月15日
发明者安东尼·理查德·列尼, 安东尼 理查德 列尼, 詹姆士 怀廷, 理查德·詹姆士·怀廷 申请人:英国电讯有限公司