现的多个块来定义视频"剪辑"。
[0059]如在以上引用的共同未决申请中所述，事件标记之前和之后的多个"±夬"每个被分 配一个各自的叙述兴趣值(NIV)。事件标记本身被分配为1的NIV，其它的块被分配与其距事 件标记的距离成比例的NIVJIV可以按照通过由与事件标记相关联的元数据定义的"前/后 事件比率(PPER)"确定的比例在事件标记之前和之后以不同的速率增加。因此，例如，对于1 :1的PPER，将在事件标记之前和之后以相同的速率按照升序为块分配NIV。对于2:1的PPER， 针对后面的每个块，将在EM之前分配两个块。类似地，对于3:1的PPER，针对紧随EM之后的每 个快，在EM之前下载三个块。
[0060]在共同未决申请中，序列中的每个块具有唯一的NIV。这是因为在那些早期的发明 中，NIV确定视频块将被下载的顺序。在本发明中，追赶序列要被立即观看，所以下载的顺序 通常将是描述事件的时间顺序，并且NIV被用于不同的目的。因此，有可能对于与单个事件 标记相关联的多个块，所有的块被分配相同的NIV。然而，在该实施方式中，唯一的NIV被分 配给给定序列的每个块。这允许将相同NIV分配过程被用于更早的发明。然后，相同的NIV可 以被用于下载和回放两者。
[0061]本发明允许该书签数据被用于以可变速率下载视频包，现在将对此进行描述。返 回到图1的讨论，该图描绘了具有到电视40或其它监视设备的输出以及通过通信网络到媒 体服务器42和内容服务器420的连接的客户端设备41。媒体服务器42具有多个相关联的数 据存储器43、44、45、46，这些存储器存储事件标记和与视频数据相关联的其它元数据以及 指定视频数据的哪些部分将被传递到个人客户端以及按照什么顺序的清单文件。一些清单 文件46可以被预先准备，使得它们可以按请求被下载，但是针对作为本发明的主题的追赶 服务，清单是响应于来自客户端的特定请求69被动态地创建，因为每个清单需要覆盖在进 行请求的瞬间结束的时段内所记录的事件。
[0062]客户端服务器41具有用于所下载的清单文件46的存储器，并且还可以具有用于修 改清单文件的个性化优先级47的存储器，以便准备对于视频内容的传递的请求48。在其它 实施方式中使用媒体服务器中的代理470完成个性化。
[0063]服务器内容平台420具有视频内容49的存储器，从该存储器检索请求48中指定的 用于传送到客户端设备41的内容490。
[0064] 传送过程中的步骤如下：
[0065]客户端41从服务器42请求追赶清单文件46(步骤69)。该文件可组成多个部分，每 个部分包含一系列的"±夬"。例如，单独的部分可以由播放中的中断或预定断点限定，使得追 赶序列跳过这些断点，而不是以快进速度通过他们（即使在16x的速度，英式足球中的标准 15分钟中场休息也将需要花费近60秒来播放）。
[0066]清单文件根据EM和NIV的数据被编译（图2中的步骤70)。对于追赶设施，序列视频 的长度由服务器考虑迄今已被标记的感兴趣事件的数目、观众的个人资料(这可能影响这 些事件中的哪个预计是该特定观众最感兴趣的）、以及在直播时间表中的任何固定点（例 如，当将期望返回到现场直播时的预定中断(例如，中场休息）的结束)来定义。例如，追赶视 频的长度可以被设置为标准持续时间，但是如果该追赶视频将在自然中断期间结束，则能 够被延长到这样的中断的结束。
[0067]为了达到来自客户端的这样的请求69,媒体服务器42使用与每个事件标记相关联 的数据44、45(步骤701、702)来确定优先级列表(步骤703)。该列表可以朝着用户的喜好进 行定制，例如，在足球比赛中，用户可以优先观看他支持球队的进球而不是对手的进球，并 且可以把进球优先于其它事件(诸如，围绕球员的警告或驱逐的事件），并且生成指定所需 要的片段和每个片段将被呈现的速度的清单文件46。
[0068] 参考图6A和图6B，下面将描述可编译清单文件46的过程。
[0069]服务器42将清单文件46传送到客户端41 (步骤72)。客户端41读取清单文件46(步 骤73)，并对其进行解释以生成视频块列表48。这是所需的视频块将被从其下载的文件地址 的列表。客户端41将该块列表48发送到内容服务器420(步骤76)。
[0070] 媒体服务器42和内容服务器420在实践中可以在单个平台相关联，或如所示的，与 清单文件46的生成和将被清单文件需要、位于分布式系统的不同部分42、420的视频块49的 位置相关联。
[0071] 服务器420检索视频块49,并以请求中指定的顺序发送它们(步骤77)。
[0072]客户端41接收视频块49并对被处理(缓存、解压缩等）以用于显示的视频块进行复 制490。
[0073] 通过将特定字段包括进MPEGDASH(使用HTTP的动态自适应流传输)ΜΗ)文件中，清 单文件可以包括NIV数据。DASH客户端将使用以下步骤检索并播放视频内容：
[0074] 1、客户端下载和读取MPD文件以获得诸如内容位置、片段编码、分辨率、最小和最 大带宽、类似隐藏字幕和内容限制的辅助功能(诸如，DRM)的重要信息。
[0075] 2、客户端选择适当的片段编码，并通过一系列HTTP请求开始对内容进行流传输。 服务器按每个请求的要求创建和编码来自相同的源的每个片段。
[0076] 3、客户端缓存正在下载的数据，同时还跟踪连接带宽的波动。如果需要，客户端自 动改变为与当前比特率更兼容的不同的片段编码(来自MPD文件中列出的那些片段编码）。 这确保客户端在视频中始终保持足够的缓冲区，而无需下载比实际需要更多的数据。
[0077]图5示出了根据本发明的存储在服务器中的NIV数据如何被用于改变回放速度。它 描绘了具有14个片段20a-20n的序列20。两个事件标记EM1、EM2分别与片段20g、20j相关联。 这些分别具有导致NIV的不同序列的1: 2和2:1的PPER，如参照211、212所指出的。以由该序 列的相应的PPER确定的比例，按时间顺序为事件标记之后的块分配具有递增值的NIV，并且 按相反的时间顺序为事件标记之前的块分配具有递增值的NIV。通过取针对每个片段的NIV 21U212的最小值为该每个片段生成组合NIV。组合NIV的序列与从其推导出每个NIV的标记 (EMl、EM2) -起参照210 (EMl2的EM值是相同的）被描述。
[0078]设置最大NIV，在该示例中为11，比具有最大NIV的片段更远的任何片段被指定为 空的NIV，如参照200所示。
[0079]CNIV被用于确定回放速度。在图5所示的示例中，回放速度被选择如下。
[0081] 如在220所示，给出了回放速度，并且每个块的实际持续时间在230被示出。在该示 例中，分配给各个速度的NIV的数目随着速度而增加，使得速度的改变实时地发生在大致相 等的间隔。
[0082] 当使用从用户生成的书签推导出的CNIV时，通过使用归于事件标记的用户生成事 件的相对数量作为加权因子来修改CNIV，可以通过相应的事件流行度来修改CNIV。
[0083] 为了避免能够分散精力的速度的太多变化，平滑函数可以被应用于回放速度。例 如，速度控制单元可以被布置成如果第一块具有与第一速度相关联的CNIV，其前面和后面 都是具有与"正常"速度相关联的CNIV的块，则所有的三个块均以正常速度播放，如在222所 不。
[0084] 现在将描述多个过程，通过这些过程可变速度的追赶序列将被传送给观众。在这 些实施方式中，NIV值被存储在媒体服务器42中作为元数据(例如，将参照图7在后面所描述 的，将字段添加到MPEGDASH(动态自适应流传输Http)文件），并且用来控制回放速度。在一 些实施方式中，客户端设备41包括速度控制系统50,该速度控制系统50可由与从内容服务 器420流传输的视频块49相关联的NIV数据来控制。
[0085] 为了提供将被执行的一些级别的带宽节省，可以使用ABR，使得低比特率的视频块 将被提供用于将以高速(例如，xl6)回放的部分。同样，当回放速度例如是xl时，则可以选择 更高的比特率。一般不可能保留比特/帧的速率，I帧需要比B帧和P帧更多的比特，因此，如 果仅省略了B帧和P帧，留下更高比例的I帧，则比特/帧的平均数目将增加。然而，每秒传输 的比特数目将小于如果所有帧都将以足以保持加快回放的速度被发送的情况。
[0086]在优选的实施方式中，也在图1中描述，可变速度是由服务器42编码。这允许客户 端终端41进行常规的操作，并且还降低了需要从服务器42流传输到客户端41的数据量。视 频编码单元499以多个预定回放速度对实时视频流409进行编码。这可以使用任何自适应比 特率技术(诸如，HLS(HTTP实时流传输)和MPEGDASH)来完成。不同的块49以在其被下载之 前已经包含在块中的所需的速度被生成499以便存储在内容服务器420中。
[0087]在一个实施方式中，如图5所示，单个流20被存储，并且服务器420(或客户端设备 41)修改各个块20a、20b等，以允许它们以所需要的速度显示。这可以通过从每个块中省略 各个帧来完成，以将播放长度减少为所需要的播放长度。标准MPEG压缩系统需要一些帧 ("B"帧和"P"帧）参考彼此来定义，并且独立地定义了 "Γ帧，这些帧应当被省略，使得只有 当其定义取决于一个帧的所有其它帧也被省略时，才应当省略这个帧，在实践中，这意味 着，B帧和P帧通常将在I帧之前被省略。
[0088]为了维持合理的下载速度，在具有较高速