传输数据的方法以及网络订户站点.pdf

当在其中根据因特网协议控制网络订户站点的分布式站点(10，20)的网络中正在传送数据流时，通常可以利用HTTP－GET方法来传输资源(例如文件)。然而，在视频电影的技巧模式(搜索处理)的情况下，这并不支持如所需的、部分地不连续传输数据。本发明描述了对已知的HTTP－GET方法的扩展，从而使该应用同样是可能的。为此目的，在HTTP－GET请求中，将与所需搜索相关的附加参数传送到源设备(10)。然后，所述源设备(10)针对该搜索，发送相应的数据部分。

1.  一种在分布式站点的网络中，部分地不连续传输第一网络订户站点(10)和第二网络订户站点(20)之间的数据的方法，包括以下步骤：
-创建声明了所需参数的HTTP-GET请求，所述参数诸如文件名、文件类型、路径、回放速度、回放方向和初始位置；
-将HTTP-GET请求传送到源设备(10)；
-在HTTP响应中，部分地不连续传输从源设备(10)到目的地设备(20)的数据。

2.  根据权利要求1所述的方法，其特征在于：利用HTTP分块传送编码模式来传输所述数据。

3.  根据权利要求1或2所述的方法，其特征在于：在针对所请求的数据传输的响应中返回特定的状态码，信号通知已经能够正确地解译HTTP-GET请求中的所需参数。

4.  根据权利要求1到3任一个所述的方法，其特征在于：在针对所请求的数据传输的响应中，重复来自HTTP-GET请求的所需一个或多个参数，作为得知已经能够正确地解译HTTP-GET请求中的所需一个或多个参数的知识。

5.  根据权利要求1到4任一个所述的方法，其特征在于：在请求快速搜索的情况下，利用数据的部分地不连续传输。

6.  根据权利要求1到5任一个所述的方法，其特征在于：所述数据涉及多媒体数据，特别是音频或视频数据。

7.  根据权利要求2到6任一个所述的方法，其特征在于：利用HTTP分块传送编码模式，部分地传送在所有情况下的视频数据的部分，特别是用于视频帧的数据，作为用于不连续传输的块。

8.  根据权利要求7所述的方法，其特征在于：作为MPEG2编码视频电影的数据部分，传送在所有情况下针对内部编码视频帧或针对单向编码视频帧的数据。

9.  根据前述权利要求任一个所述的方法，其特征在于：分布式站点的网络是根据因特网协议控制的网络。

10.  根据权利要求9所述的方法，其特征在于：将网络订户站点(10，20)设计为根据UPnP规范来控制，其中UPnP表示通用即插即用。

11.  一种作为执行如前述权利要求任一个所述的方法的请求设备的网络订户站点，包括程序装置，用于在请求时，利用部分地不连续传输数据所需参数的详情，创建HTTP-GET请求，所需参数诸如文件名、文件类型、路径、回放速度、回放方向、初始位置。

12.  根据权利要求11所述的网络订户站点，其特征在于具有：接收用于执行快速搜索处理的命令的装置；以及激活程序装置以响应于此来创建HTTP-GET请求的装置。

13.  一种作为执行如权利要求1到10任一个所述的方法的源设备的网络订户站点，包括：用于评估来自目的地设备(20)的接收到的HTTP-GET请求的程序装置，以便利用所需参数的详情，部分地不连续传输数据，所需参数诸如文件名、文件类型、路径、回放速度、回放方向、初始位置；以及用于将所请求的数据传送到目的地设备(20)的传输装置。

14.  根据权利要求13所述的网络订户站点，其特征在于所述传输装置利用HTTP分块传送编码模式来传送所请求的数据。

15.  根据权利要求14所述的网络订户站点，其特征在于设置用于传输MPEG视频数据的装置，其中，在HTTP分块传送编码的过程中，作为单独的数据部分，传送MPEG视频数据流中针对内部编码视频帧和/或针对单向编码视频帧的数据。

16.  根据权利要求14或15所述的网络订户站点，其特征在于用于在所有情况下部分地不连续传输数据的装置还添加指示数据部分在数据流中的位置的位置详情。

17.  根据权利要求13到16任一个所述的网络订户站点，其特征在于设置了格式化装置，在针对所请求的数据传输的响应中，返回特定状态码，信号通知已经能够正确地解译HTTP-GET请求中的所需参数。

18.  根据权利要求13到17任一个所述的网络订户站点，其特征在于设置了格式化装置，在针对所请求的数据传输的响应中，重复来自HTTP-GET请求的所需一个或多个参数，作为得知已经能够正确地解译HTTP-GET请求中的所需一个或多个参数的知识。

传输数据的方法以及网络订户站点
技术领域
本发明涉及在分布式站点的网络中的数据传输的技术领域，具体地，涉及一种所谓的家庭网络。在这种情况下，部分地不连续地传输数据。
背景技术
近来，各种家庭网络标准已经可用于家庭区域中的设备的联网。
合作的公司，特别是由微软领导的计算机行业的公司，已经开始首创基于现有的因特网协议(IP)的网络控制软件的规范。该网络系统已经公知为缩写UPnP(通用即插即用)。在该系统中，规范并不主要涉及娱乐电子设备，事实上，其他设备也可以集成在网络中，特别是个人计算机、诸如电冰箱、微波炉、洗衣机等大型家用电器范围内的家用设备、以及加热控制器、发光控制器、警报系统等。
UPnP论坛的工作组已经制订了UPnP-AV规范，建立于通用UPnP规范之上，并且对其进行扩展，以便将UPnP方法应用于AV设备。为了在诸如此类的家庭网络中，在所谓的服务器(源设备)和所谓的再现设备(目的地设备)之间传送AV数据(音频/视频数据)，UPnP-AV规范规定了应该将公知的传输协议用于数据的传输。除了所谓的HTTP-GET方法(超文本传输协议的HTTP标准)之外，在规范中也提到了作为公知协议的所谓RTP方法(实时传输协议的RTP标准)。当网络订户站点通过以太网总线连接彼此相连时，这两个传输机制是可用的。
该HTTP-GET基于作为基本的面向连接传输协议的TCP方法(传输控制协议)，其中，出现了保护数据传输(具有纠错)。结果，TCP方法建立于因特网协议(IP)之上。特别是针对从万维网服务器到万维网浏览器的文件(例如，HTML网页)传输，开发了该HTTP-GET方法。结果，其不适合于部分的实时数据传输，例如，当发生在传输音频或视频数据流上时。另一方面，HTTP-GET方法得到广泛使用，并且设计为对于应用编程器而言非常简单，从而广为流行。
根据RTP方法的传输机制基于同样建立于因特网协议上的UDP方法(用户数据报协议)，无任何连接地操作，并且不使用纠错，从而当使用该方法来传输数据时可能会发生干扰。另一方面，RTP方法更好地适合于实时数据传输，因为其使用了中间缓冲器、附加时标和序列号。因此，在这一点上，更适合于音频或视频数据的传输，特别是在以大量瓶颈为特征的因特网上。
在UPnP规范中，基于HTTP-GET方法的传输机制推荐用于AV数据流的传输。HTTP-GET方法主要用于请求网络中可得到的资源，这在多数情况下为现有文件，然后整块地将其全部传送到目的地设备。另外，在HTTP版本1.1中引入了所谓的分块传送编码方法，无论何时当传送在开始传输时其整个长度还未完全已知的资源时，需要使用该方法。在这种情况下，应该部分地传输该资源，而不是连续地(即，无任何间隔)。
发明内容
针对所述现有技术的背景技术，本发明的目的是扩展基于HTTP-GET方法的传输机制，从而还能够在数据流的传输中实现所谓的技巧模式(trick mode)。诸如此类的技巧模式包括：诸如在AV数据流的情况下，快进(前向搜索)和快退(后向搜索)。本发明通过定义针对HTTP-GET方法的附加参数来解决该问题，例如，所述参数涉及回放速度和回放方向、以及针对回放处理的初始位置。
通常，在诸如此类的技巧模式的回放处理中仅需要单独的数据块，例如，在视频电影的快速前向搜索中仅再现单独的视频帧，而抑制了再现的帧之间的其他视频帧。因此，有效地，这导致了从一个视频帧N到视频帧N+X(前向)或N-X(反向)的重复跳跃。为了执行该部分地不连续传输数据，能够利用附加参数来发出新的类型的HTTP-GET请求，所述参数诸如回放速度和回放方向、以及针对回放处理的初始位置。源设备利用HTTP-GET响应，发送回针对所请求的技巧模式的所请求的数据部分。
本发明还能够使用简单的传输机制HTTP-GET，用于实现实时数据传输的技巧模式，特别是针对AV数据。本发明同样能够实现所谓的导航命令，例如，允许故意跳跃到数据流中在特定时间或特定时间之后出现的位置，例如，比当前播放时间晚15分钟。
在丛属权利要求中所指定的措施实现了根据本发明的方法的有效应用和改进。
本发明的一个有效实施例是在HTTP-GET方法中使用分块传输编码模式。具体地，总是作为块来传送要再现地数据部分。另外，在这种情况下，没有连续地(即无间隔)传送数据，而存在各个传输的数据部分之间已省略的其他区域，即，这表示部分地不连续数据传输。每一个块的时间位置还可以指示在注释行中。这具有以下优点：当由新类型的技巧模式请求来停止或中断当前技巧模式时，具有更好的时间精度。
当知道已经能够根据本发明正确地解译HTTP-GET请求中的参数时，或者能够返回同意的特殊状态码，或者可以在响应中再次重复这些参数。在未根据本发明而设计的设备的情况下，响应将会不同，从而如果所寻址的设备不支持这样的技巧模式再现，则请求设备可以向操作员发送适当的信息。
在权利要求11和12中列出了用于作为执行根据本发明的方法的请求设备的网络订户站点的相应有利措施。
相应地，在权利要求13到18中列出了用于作为执行根据本发明的方法的源设备的网络订户站点的相应有利措施。
附图说明
在以下描述中，将更详细地解释本发明的典型实施例，并且在附图中示出了这些实施例，其中：
图1示出了在分布式站点的网络中的源设备和目的地设备的粗略方框图；
图2示出了根据本发明的从目的地设备发送到源设备的HTTP-GET请求的格式；
图3示出了通用遥控器的示例；
图4作为示例，示出了在MPEG2编码视频数据的前向上三倍速度搜索的示意图；
图5示出了根据本发明的HTTP-GET响应的格式；
图6示出了一程序流程图，利用其来创建HTTP-GET请求，并将其发送到源设备；
图7示出了在源设备中处理的程序的流程图，用于利用分块传送编码模式来创建并传送HTTP-GET响应；以及
图8示出了利用绝对URL的详情，将HTTP-GET请求从目的地设备传送到源设备，所述绝对URL由问号分隔，并且同样包含针对所请求的回放处理的所需参数。
具体实施方式
图1示出了在分布式站点的网络中的源设备10和目的地设备20。如图所示，将各个网络订户站点设计为通过以太网总线连接15彼此相连。还假定将各个网络订户站点设计为UPnP标准。从微软公司可以获得该UPnP规范。
另外的信息还可在针对UPnP系统的官方因特网址上得到。为此目的，应该参考因特网址WWW.UPnP.org。
针对源设备的术语对应于在服务器中针对UPnP系统的术语。针对UPnP系统中的目的地设备20的术语对应于针对与目的地设备相对应的再现设备的术语。在图1所示的示例中，源设备10的两个主要组件是单独强调的存储设备12和HTTP服务器11。例如，针对音频/视频数据的典型源设备是DVD播放器、DVD记录器、硬盘记录器、DVHS记录器、CD播放器、MP3播放器、视频摄像机或其他个人计算机。将能够回放的AV数据存储在源设备10的存储设备13中。HTTP服务器11需要用于UPnP设备，诸如根据UPnP规范的该类设备，并且可以是软件的形式。相应的程序方法在现有技术中是公知的，并且对于这些组件的公开，特别应该参考UPnP规范。
在目的地设备20中的主要组件是HTTP发射机/接收机22、HTTP服务器21、缓冲存储器23、和解码逻辑电路24。例如，目的地设备20可以是数字电视，也可以是机顶盒、DVD播放器和MP3播放器或个人计算机等形式。必须将解码单元24设计为MPEG2解码器，以便传输MPEG2编码视频信息。优选地，缓冲存储器23应该是RAM存储单元形式。
以下文字基于在源设备和目的地设备之间已经建立了针对AV数据的数据传输的连接的假定。还假定了源设备10正在以正常速度播放视频电影，并且正在通过已经建立的连接，向目的地设备20连续地传输相关的AV数据流。然后，用户对目的地设备20请求快速前向搜索。如图3所示，这可以通过使用遥控器30来实现。作为示例，图3示出了配备有触摸屏显示器31的通用遥控器，在显示器上，显示针对数字视频记录器的控制功能。诸如此类的通用遥控器在现有技术中是公知的。作为示例，参考欧洲专利申请EP-A-0 780 990中的现有技术。在显示器31上所示出的按钮是停止按钮32、重放按钮33、暂停按钮34、记录按钮35、快退按钮36、快进按钮37、前向标题跳跃按钮38和反向标题跳跃按钮39。操作员已经按下了目的地设备20上的按钮37，以便请求快速前向搜索。然后，由目的地设备20将该命令转换为适当的HTTP-GET请求，通过网络电缆15将其传送到源设备。图2示出了HTTP-GET请求的结构的详情。在这里所示的示例中，关键字GET之后跟随的是所请求的文件名。这由参数名ITEM信号表示。例如，文件名是MenInBlack.MPG，对应于视频电影的典型名称。在相同行的HTTP版本详情之后，在下一行跟随的是其中可以找到该文件的设备的详情。为了识别该参数，表达式HOST处于第二行的服务器名之前。在该示例中所示的服务器名是www.my.server。在此行的下一行的下一个参数是回放速度的详情。参数名相应地为AV_SPEED。然而，同时，该参数还包括回放方向。在所示的示例中，参数详情包括表达式Forward_3，表示需要以三倍正常速度来执行快速前向搜索。然而，针对回放方向，可能已经另外引入了单独的参数。
HTTP-GET请求的第四行还包括针对所请求的搜索的初始位置的参数详情。针对其的参数名是AV_STARTTIME。该参数名之后跟随的是位置详情01.02.03.02，表示当前的播放时间位置，具体地，1小时，2分钟，3秒，帧02。在目的地设备20中设置适当的程序，以便创建HTTP-GET请求，通过按下按钮37，由请求搜索处理来发起该请求。在以下的文字中将更详细地对此进行解释。
现在，图4更具体地示出了在前向上以三倍播放速度的所请求的搜索处理。该图示示出了数字编码视频帧的显示序列，其中根据MPEG2标准对数字视频帧进行编码。该标准指定了内部编码帧(I帧)、双向编码帧(B帧)和单向编码帧(P帧)之间的区别。最高数据压缩速率用于之后是P帧的B帧。至少对内部编码帧进行压缩，但是所述内部编码帧也可以用作支持帧，即，可以重新构造其帧内容，而无需知道前面或后面的帧。将MPEG2标准中的帧序列推荐为所谓的画面组(GOP)，具有形式IBBPBBPBBPBB。图4示出了诸如此类的三个连续的画面组。现在，用于执行三倍速度前向搜索的过程如下所述：仅再现画面组中的I帧和P帧。因此，可以根据具有12个帧的画面组来显示四个不同的帧，从而总共引起了三倍速度前向搜索。因此，跳跃发生在数据流中从I帧到P帧、从P帧到P帧和从P帧到I帧的搜索处理期间。
对于涉及如何能够实现针对MPEG-2编码视频帧的技巧模式的技术的另外的细节，应该参考文章：“Entwicklung eines DVD-Players：problem und Lsungen”[Development of the DVD player：problemsand solutions]，由Ingo Hütter和Dirk Adolph所写，在FKT No.11/1999的第664页以及下列等。
图5示出了一旦已经请求了快速搜索时，从源设备10中发出的HTTP响应的格式。在第一行中产生针对成功接收到的HTTP-GET请求的状态消息。这还包括与HTTP方法有关的版本详情。在响应的第二行中声明日期和时钟时间。
在第三行中，使用关键字CONTENT-TYPE来信号表示随后将要传送的数据类型。在所引用的示例中，这是使用MPEG2格式编码的视频数据。然后，使用第四行来信号表示随后的传输将使用分块传输编码模式。然后，传送第一数据部分。这处于利用十六进制数字的相关数据部分的长度的详情之前。由于如已经结合图4所解释的那样，仅传送针对I帧和P帧的数据来进行搜索，在所有情况下，这之后跟随的是针对I帧的视频数据，作为数据部分。针对标准视频帧的一个这样的I帧的数据量大约为120千字节。当然，这从一个帧内容向下一个帧内容会发生波动。在相同的行上，在传输视频帧中的各个时间详情跟随其后，由分号与长度详情相分隔。在开始时间01:02:03:02处请求该搜索，见图2。从此时开始，源设备10搜索下一个I帧，这在时间01:02:03:04处找到。在HTTP-GET响应的第五行中的时间因而精确地对应于该值。然后，针对所通知的I帧的视频数据跟随在接下来的行中。一旦已经传送了该视频帧，在下一行中是针对要传送的下一个视频帧的长度详情与在该处已经将该帧定位在视频电影中的适当时间和位置。这之后跟随的是相关的视频数据。然后，图5还示出了针对跳跃到其的第三P帧的相应详情，然后对其进行传送。该处理继续，直到该搜索由用户控制器结束，或达到了视频电影的结尾为止。在分块传输编码模式下的数据传输的结尾由仅传送值0作为该值的行来表示。同样，这在图4中已示出。
如所述的，根据本发明，这包括部分地不连续传输视频数据。由于仅传送针对视频帧(在这种情况下的I和P帧)的视频数据，而相反，不传送针对其间的帧的视频数据，因此，这是不连续的。
由于能够极好地将根据本发明的HTTP请求发送到不支持所述类型的技巧模式的设备，因此，来自不支持技巧模式的设备的响应应该使请求已经得到理解并且数据流将符合请求中的参数变得显而易见。这可以通过响应中的指定HTTP状态码来实现(例如，“210”，“技巧模式OK”)，如图5所示。
可选地，还可以在响应中重复技巧模式参数，以便对此进行指示。将按照如下方式形成该响应：
HTTP/1.1 200 OK
Date：Fri.31 Dec 2003 17:59:59 GMT
Content-Type：video/mpeg
Transfer-Encoding：chunked
AV_SPEED：forward_3
AV_STARTTIME：01.02.03.04
IEAEO；time＝01:02:03:04
·
·
·
在该响应中简单地使用了已知状态码200 OK。然而，事实上，出于该目的来重复技巧模式参数，如果其不能够解译技巧模式参数，标准设备将不会动作。在参数AV_STARTTIME的详情中，已经使时间与和第一传输视频帧相关的值相匹配。这是可选的。还能够仅简单地重复请求的时间。
图6示出了一旦由用户已经请求了快速搜索处理，在目的地设备20中处理的程序的流程图的示例。一旦操作员已经操作了前向搜索按钮37，则程序以程序步骤40开始。由于已经以正常速度回放了视频电影，在接下来的程序步骤41中，还可以从正在播放的视频电影中提取用于搜索处理的所需参数。这些参数首先是当前播放时间的时间、正在演出的电影的文件名、在其上存储了视频电影的服务器名。还记录了针对新操作模式的参数。在简单的情况下，该参数可以永久地与搜索按钮37的操作相关联。然后，使该按钮永久地与前向搜索(三倍速度)参数相关联。
在接下来的程序步骤42中，使正在观看的视频电影的正常重放停止。在接下来的程序步骤43中，删除可能仍然包含针对进一步的视频帧的数据的缓存存储器23。该措施表示发生了从正常重放到搜索再现的专用转换，是精确的而无任何显著的时延，可能会发现这是干扰。
在接下来的程序步骤44，该程序创建针对快速搜索处理的所需HTTP-GET请求。图2示出了要创建的请求的格式。在程序步骤45中，将该HTTP-GET请求发送到源设备10。然后，在程序步骤46中，结束该程序部分。
图7示出了在接收到所述的HTTP-GET请求之后，在源设备中所处理的程序流程示例。由程序步骤50来标识程序的开始。这通过接收先前所述的HTTP-GET请求来发起。在程序步骤51中，评估已经接收到的HTTP-GET请求。从HTTP-GET请求中提取在该请求中传输的参数，特别是针对新回放处理的初始位置、文件名、服务器名和操作模式，即，在前向或反向上的何种速度的搜索。在程序步骤42中，在由现有的TCP/IP连接传送HTTP-GET请求之后，自动地结束当前正在观看的回放。从传送的初始位置开始，在接下来的程序步骤52中，搜索跟随在此之后的I帧。然后，在按照该方式找到的I帧处，开始新的回放处理。将用于该目的而读取的视频数据包括在HTTP响应消息中。图5示出了HTTP响应消息的格式。因此，使用HTTP分块传输编码模式。在图7的程序中，由参考数字53来标识该步骤。一旦已经传送了针对所选的I帧的视频数据，则针对源设备10的驱动器跳跃到视频数据文件中的接下来后续I帧的位置。根据MPEG2标准，为此目的，将单独的指针信息项包括在视频数据流中。然后，将针对下一个I帧的数据作为下一项传送到目的地设备20。连续地重复该处理，直到从目的地设备的连接已经中断为止，或者直到视频电影的结尾为止。然后，终止图7所示的无限循环。
图8示出了根据本发明的针对HTTP-GET请求的可选实施例。根据本发明，这里所示的路径名不仅包括文件名，而且包括用于现在要开始的搜索的其他所有所需参数。设计该示例，以便在问号之后列出路径中所有所需的参数。所示的参数是文件名、回放速度和方向、以及初始位置。该问号符号允许专门定义的参数通过URL(统一资源定位符)中的&符号，被单独地传送到服务器。在因特网技术RFC1738(针对请求注释的RFC标准)中更详细地描述了该方法。
本发明不仅能够用于实现针对AV数据的传输的技巧模式(搜索)。诸如此类的搜索利用其他多媒体数据也是可能的。提到了其中存储了表册的内容的文件，作为一个示例。
另外，本发明不仅仅局限于用于执行技巧模式(搜索)的应用。因此，还能够执行典型的导航处理，例如，跳到文档中所指示的位置(例如，跳到数据流中15分钟之后的位置)。在这种情况下，在HTTP-GET请求中针对重放的速度详情将指示为正常重放，尽管新的开始位置将对应于数据流中15分钟之后的位置。
另外，所需参数的数量和特性将根据实施例而发生变化。例如，如果永久地预设了特定的初始位置，则不需要总是将该初始位置作为参数传送。在较短项的情况下，能够提供总是从绝对开始位置开始的前向搜索。