选择经由通信网络传送的多媒体内容的片段的代表的方法
【技术领域】
[0001] 本发明涉及一种用于选择经由通信网络传送的多媒体内容的片段的代表的方法。
[0002] 多媒体内容旨在于指任何音频或视频内容，或者更宽泛来说指任何其他数字内 容。
[0003] 本发明尤其涉及经由网络传送和接收多媒体内容，尤其是经由网络连续下载，即 所谓的流传输多媒体内容。
[0004] 其更确切而言涉及利用内容的通用地址进行通信。
[0005] 其尤其适用于能够经由电信网络进行通信以经由通用地址，即所谓的URI (表示 Uniform Resource Identifier，统一资源标示符）访问多媒体内容的任何客户终端（此后 简称为终端）。
[0006] 内容的代表在此旨在于指创建代表内容的数据流的一种特定方式。以某个编码比 特率创建的数据流是该内容的特定代表的一个示例。
【背景技术】
[0007] 为了访问多媒体内容，客户终端通常利用通用地址，或URI。这种地址提供了在同 一时间对于内容和与用于消费其（消费理解为例如在视频内容的情况下，下载/接收该内 容，和之后可选地解码和观看其）的相关联的协议有关的指示的访问。
[0008] URI地址是标识物理或抽象资源的字符串。URI地址的语法遵从由IETF (Internet Engineering Task Force，国际互联网工程任务组）颁布的一组标准，并且尤其遵从规范 RFC3986(规范：通用资源标识符（URI):泛型语法）。诸如此的通用地址将采取例如dvb:// contentl、rtsp://content2、HTTP: //content3、ftp://content4 等的形式。
[0009] 对多媒体内容的访问由请求经由URI地址触发。其常规表现是点播视频服务：
[0010] -第一步骤，对于终端在于经由 HTTP 协议（Hyper Text Transport Protocol 超文本传输协议）下载描述了用于对该服务的访问的参数的文件（SDP，代表Session Description Protocol，会话描述协议），HTTP协议是为因特网，尤其是网络而开发的客户 端服务器通信协议；
[0011]-在第二步骤期间，服务实际上开始，也就是说，客户终端可以借助所述文件（在 该示例中是SDP)中提供的信息接收和显示视频。将注意到的是，该文件可以是描述在特定 地址可以访问的内容的计算机文档或者一组信息。
[0012] 此后，将根据上下文而采用表述"描述文档"或"文件"。将注意到的是，该类型的 对服务的访问可以要求（尤其在点对点或者"单播"通信的情况下）或者不要求（在"广 播"或"多播"类型的一点对多点通信的情况下）服务器的存在。尤其，HTTP协议是点对点 ("单播"）类型的，并且因此涉及服务器的存在以便处理客户端，所谓的HTTP客户端的请 求。
[0013] 在该HTTP协议的上下文中常常为了在客户端和服务器之间交换数据而诉诸 "HTTP自适应流传输"类型的技术。该类型的技术使得能够尤其在考虑例如客户终端和内 容服务器之间的链路的带宽变化的情况下提供良好的用户体验。常规地，例如对应于变化 的比特率而可以对于同一视频编码不同的质量。每个比特率自行划分为时间片段（或者内 容的"碎片"）。使得对于这些变化的比特率的描述和通常这些片段以及内容的碎片对于服 务平台上的客户终端可用。为了能够访问完整的内容，因此有必要知道与多个片段对应的 多个地址（URI)。
[0014] 存在用于协助这种内容流传输模式的分布的数个解决方案。这些方案提出了，向 客户端提供包含多媒体内容的不同质量的不同片段的地址的一个或多个中间描述文档，也 称为文件或单据或资源。这些方案的基本原理是制作具有不同的比特率变型的可用内容， 这些变型中的每个都以媒体数据的连续片段的形式可用，这些片段可以由客户端借助HTTP 协议来下载。
[0015] 对于给定的客户终端而言，根据"HTTP自适应流传输"技术读取内容在于：
[0016] -下载和分析对内容进行描述的描述性文件，比特率的变型可用，并且访问用于每 个比特率变型的数据片段的装置可用；
[0017] -下载数据片段，并且对于每个片段选择特定的代表，尤其是选择用于编码待下载 的片段的比特率；以及
[0018] -分析和聚束（bundle)数据片段，以便为了读取内容而对它们解码。
[0019] 存在两种选择（或者自适应）片段的代表的模式。
[0020] 根据第一模式，选择是客户终端的责任。在该模式中，由客户终端决定选择对于 媒体数据的每个片段的代表，来作为客户端内部的参数的函数（例如，所测带宽、终端的容 量，等等）；尤其，客户终端对于每个片段选择给定的编码比特率。如果客户端测量的带宽 是足够的，则客户端通常选择高编码比特率。然而，将该自适应决定仅留给客户端阻止了 内容分发器对平台（服务器）、其网络和服务的掌控。对于分发器而言，主要风险是需要服 务过高数目的、对于具有高编码比特率的片段进行访问的请求。结果将会是网络带宽或者 HTTP服务器的饱和。这还会造成客户终端上重放质量的下降，表现例如是图像冻结。
[0021] 根据第二模式，选择是经由网络广播（或分发）内容的服务器的责任。在该配置 中，解决方案包括将与要求修改代表，例如要求降低编码比特率相关的信息项插入到广播 片段的数据中。该信息可以被包括到在MPEG DASH标准中描述的名为"事件"的字段中。 IS0/IEC标准化组织的MPEGDASH(代表经由HTTP - IS0/IEC标准23009-1:2012 (E)的动态 自适应流传输）专用于经由网络对多媒体内容进行流传输；与第二模式相关的问题是执行 适应客户侧的反应时间。事实上，客户端完整地接收数据片段，在认识包括对修改片段的代 表的要求的新单据之前完整地分析它。问题是包括修改要求的单据对于在与该修改请求相 同的流中接收的当前片段而言未被考虑。因此，该解决方案不仅涉及在所接收的片段中提 取新单据的操作，而且涉及以差的质量重放该所接收的片段。
[0022] 本发明提出了一种不显示出现有技术的缺陷的解决方案。
【发明内容】
[0023] 为了该目的，根据一个功能性方面，本发明的一个主题是一种用于管理由终端从 服务器接收的内容的数据片段的代表的方法，该方法包括获取文件的步骤，基于该文件生 成通用地址，其中一个地址与由终端从该文件中描述的多个代表中选择的感兴趣片段的代 表相关联，该片段能够根据该所选的代表从服务器接收，其特征在于，该方法包括在终端水 平上的如下步骤：
[0024] -第一步骤，根据第一所选代表传送对于访问第一片段的请求，
[0025] -第一步骤，接收对该请求的响应，该请求包括对于修改第一代表的要求；
[0026] -第二步骤，根据第二代表传送对于访问第一片段的请求；
[0027] -第二步骤，根据第二代表从服务器接收第一片段。
[0028] 因此，由服务器传送的片段的代表总是服务器所期望的代表。如果接收到具有并 非服务器所期望的代表的代表接收了片段，则服务器不传送感兴趣的片段，而是通过修改 要求的方式请求客户终端从终端传送具有另一代表的片段。服务器接收具有新的所期望的 代表的URI地址；仅在此时服务器才向具有新的代表的终端传送感兴趣的片段。
[0029] 上面设想的修改要求在与传递片段的数据流不同的消息中被传送。因此，不影响 所接收的片段的质量。
[0030] 因此，参考现有技术中采用的解决方案，本发明避免了分析包含数据片段的数据 流以从中提取新的描述性文档。
[0031] 根据第一实施例，代表包括用于片段的编码比特率值。在该配置中，第一和第二代 表包括不同的值。
[0032] 根据第二实施例，终端对于给定的持续时间考虑修改第一代表的要求。对于终端 而言，对于给定的时间间隔考虑修改要求的事实避免了内容服务器连续几次发送修改要 求。
[0033] 根据第三实施例，修改要求是根据HTTP协议传送的。该特征避免了完全更新该描 述文档。HTTP协议的使用允许快速写入修改要求。这些片段由服务器例如每2秒发送一次， 该特征避免了等待新的单据，其从服务器传送的频率更可观，通常为30秒。更具体而言，该 要求是包括RFC标准2616中限定类型的数字码的http消息。数字码由客户终端接收，该 客户终端借助对应表从中推导出信息项，在我们的示例中，与片段的代表有关的设置。
[0034] 根据硬件方面，本发明涉及能够接收内容的片段的终端，该终端能够访问文件，基 于该文件生成通用地址，其中一个地址与由终端从该文件中描述的多个代表中选择的感兴 趣片段的代表相关联，其特征在于，该终端包括：
[0035] -第一模块，用于根据第一所选代表传送访问第一片段的请求，
[0036] -第一模块，用于接收对该请求的响