CN105075277B

CN105075277B - 选择经由通信网络传送的多媒体内容的片段的代表的方法

Info

Publication number: CN105075277B
Application number: CN201480008758.8A
Authority: CN
Inventors: B.贝赛洛特; P.霍兹
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2013-02-13
Filing date: 2014-01-28
Publication date: 2019-02-22
Anticipated expiration: 2034-01-28
Also published as: EP2957104A1; FR3002105A1; WO2014125184A1; CN105075277A; US20150373145A1; EP2957104B1

Abstract

本发明涉及一种用于管理由终端从服务器接收的内容的数据片段(0.mp4v,180180.mp4v)的代表的方法。所述方法包括产生文件的步骤(ET2)，可以从该文件产生通用地址，由所述终端从所述文件中描述的多个代表中选出的所讨论的片段的代表与地址相关联，该片段能够根据所选的代表从服务器被接收。该方法在终端上包括如下步骤：第一步骤，根据第一所选代表传送访问第一片段的询问；第一步骤，接收对于该询问的响应，其包括修改该第一代表的请求；第二步骤，根据第二代表传送访问第一片段的询问；以及第二步骤，根据第二代表从服务器接收第一片段。

Description

选择经由通信网络传送的多媒体内容的片段的代表的方法

技术领域

本发明涉及一种用于选择经由通信网络传送的多媒体内容的片段的代表的方法。

多媒体内容旨在于指任何音频或视频内容，或者更宽泛来说指任何其他数字内容。

本发明尤其涉及经由网络传送和接收多媒体内容，尤其是经由网络连续下载，即所谓的流传输多媒体内容。

其更确切而言涉及利用内容的通用地址进行通信。

其尤其适用于能够经由电信网络进行通信以经由通用地址，即所谓的URI(表示Uniform Resource Identifier，统一资源标示符)访问多媒体内容的任何客户终端(此后简称为终端)。

内容的代表在此旨在于指创建代表内容的数据流的一种特定方式。以某个编码比特率创建的数据流是该内容的特定代表的一个示例。

背景技术

为了访问多媒体内容，客户终端通常利用通用地址，或URI。这种地址提供了在同一时间对于内容和与用于消费其(消费理解为例如在视频内容的情况下，下载/接收该内容，和之后可选地解码和观看其)的相关联的协议有关的指示的访问。

URI地址是标识物理或抽象资源的字符串。URI地址的语法遵从由IETF(InternetEngineering Task Force，国际互联网工程任务组)颁布的一组标准，并且尤其遵从规范RFC3986(规范：通用资源标识符(URI)：泛型语法)。诸如此的通用地址将采取例如dvb://content1、rtsp://content2、HTTP://content3、ftp://content4等的形式。

对多媒体内容的访问由请求经由URI地址触发。其常规表现是点播视频服务：

-第一步骤，对于终端在于经由HTTP协议(Hyper Text Transport Protocol超文本传输协议)下载描述了用于对该服务的访问的参数的文件(SDP，代表SessionDescription Protocol，会话描述协议)，HTTP协议是为因特网，尤其是网络而开发的客户端服务器通信协议；

-在第二步骤期间，服务实际上开始，也就是说，客户终端可以借助所述文件(在该示例中是SDP)中提供的信息接收和显示视频。将注意到的是，该文件可以是描述在特定地址可以访问的内容的计算机文档或者一组信息。

此后，将根据上下文而采用表述“描述文档”或“文件”。将注意到的是，该类型的对服务的访问可以要求(尤其在点对点或者“单播”通信的情况下)或者不要求(在“广播”或“多播”类型的一点对多点通信的情况下)服务器的存在。尤其，HTTP协议是点对点(“单播”)类型的，并且因此涉及服务器的存在以便处理客户端，所谓的HTTP客户端的请求。

在该HTTP协议的上下文中常常为了在客户端和服务器之间交换数据而诉诸“HTTP自适应流传输”类型的技术。该类型的技术使得能够尤其在考虑例如客户终端和内容服务器之间的链路的带宽变化的情况下提供良好的用户体验。常规地，例如对应于变化的比特率而可以对于同一视频编码不同的质量。每个比特率自行划分为时间片段(或者内容的“碎片”)。使得对于这些变化的比特率的描述和通常这些片段以及内容的碎片对于服务平台上的客户终端可用。为了能够访问完整的内容，因此有必要知道与多个片段对应的多个地址(URI)。

存在用于协助这种内容流传输模式的分布的数个解决方案。这些方案提出了，向客户端提供包含多媒体内容的不同质量的不同片段的地址的一个或多个中间描述文档，也称为文件或单据或资源。这些方案的基本原理是制作具有不同的比特率变型的可用内容，这些变型中的每个都以媒体数据的连续片段的形式可用，这些片段可以由客户端借助HTTP协议来下载。

对于给定的客户终端而言，根据“HTTP自适应流传输”技术读取内容在于：

-下载和分析对内容进行描述的描述性文件，比特率的变型可用，并且访问用于每个比特率变型的数据片段的装置可用；

-下载数据片段，并且对于每个片段选择特定的代表，尤其是选择用于编码待下载的片段的比特率；以及

-分析和聚束(bundle)数据片段，以便为了读取内容而对它们解码。

存在两种选择(或者自适应)片段的代表的模式。

根据第一模式，选择是客户终端的责任。在该模式中，由客户终端决定选择对于媒体数据的每个片段的代表，来作为客户端内部的参数的函数(例如，所测带宽、终端的容量，等等)；尤其，客户终端对于每个片段选择给定的编码比特率。如果客户端测量的带宽是足够的，则客户端通常选择高编码比特率。然而，将该自适应决定仅留给客户端阻止了内容分发器对平台(服务器)、其网络和服务的掌控。对于分发器而言，主要风险是需要服务过高数目的、对于具有高编码比特率的片段进行访问的请求。结果将会是网络带宽或者HTTP服务器的饱和。这还会造成客户终端上重放质量的下降，表现例如是图像冻结。

根据第二模式，选择是经由网络广播(或分发)内容的服务器的责任。在该配置中，解决方案包括将与要求修改代表，例如要求降低编码比特率相关的信息项插入到广播片段的数据中。该信息可以被包括到在MPEG DASH标准中描述的名为“事件”的字段中。ISO/IEC标准化组织的MPEGDASH(代表经由HTTP–ISO/IEC标准23009-1:2012(E)的动态自适应流传输)专用于经由网络对多媒体内容进行流传输；与第二模式相关的问题是执行适应客户侧的反应时间。事实上，客户端完整地接收数据片段，在认识包括对修改片段的代表的要求的新单据之前完整地分析它。问题是包括修改要求的单据对于在与该修改请求相同的流中接收的当前片段而言未被考虑。因此，该解决方案不仅涉及在所接收的片段中提取新单据的操作，而且涉及以差的质量重放该所接收的片段。

本发明提出了一种不显示出现有技术的缺陷的解决方案。

发明内容

为了该目的，根据一个功能性方面，本发明的一个主题是一种用于管理由终端从服务器接收的内容的数据片段的代表的方法，该方法包括获取文件的步骤，基于该文件生成通用地址，其中一个地址与由终端从该文件中描述的多个代表中选择的感兴趣片段的代表相关联，该片段能够根据该所选的代表从服务器接收，其特征在于，该方法包括在终端水平上的如下步骤：

-第一步骤，根据第一所选代表传送对于访问第一片段的请求，

-第一步骤，接收对该请求的响应，该请求包括对于修改第一代表的要求；

-第二步骤，根据第二代表传送对于访问第一片段的请求；

-第二步骤，根据第二代表从服务器接收第一片段。

因此，由服务器传送的片段的代表总是服务器所期望的代表。如果接收到具有并非服务器所期望的代表的代表接收了片段，则服务器不传送感兴趣的片段，而是通过修改要求的方式请求客户终端从终端传送具有另一代表的片段。服务器接收具有新的所期望的代表的URI地址；仅在此时服务器才向具有新的代表的终端传送感兴趣的片段。

上面设想的修改要求在与传递片段的数据流不同的消息中被传送。因此，不影响所接收的片段的质量。

因此，参考现有技术中采用的解决方案，本发明避免了分析包含数据片段的数据流以从中提取新的描述性文档。

根据第一实施例，代表包括用于片段的编码比特率值。在该配置中，第一和第二代表包括不同的值。

根据第二实施例，终端对于给定的持续时间考虑修改第一代表的要求。对于终端而言，对于给定的时间间隔考虑修改要求的事实避免了内容服务器连续几次发送修改要求。

根据第三实施例，修改要求是根据HTTP协议传送的。该特征避免了完全更新该描述文档。HTTP协议的使用允许快速写入修改要求。这些片段由服务器例如每2秒发送一次，该特征避免了等待新的单据，其从服务器传送的频率更可观，通常为30秒。更具体而言，该要求是包括RFC标准2616中限定类型的数字码的http消息。数字码由客户终端接收，该客户终端借助对应表从中推导出信息项，在我们的示例中，与片段的代表有关的设置。

根据硬件方面，本发明涉及能够接收内容的片段的终端，该终端能够访问文件，基于该文件生成通用地址，其中一个地址与由终端从该文件中描述的多个代表中选择的感兴趣片段的代表相关联，其特征在于，该终端包括：

-第一模块，用于根据第一所选代表传送访问第一片段的请求，

-第一模块，用于接收对该请求的响应，其包括修改第一代表的要求，

-第二模块，用于根据第二代表传送访问第一片段的请求；

-第二模块，用于根据第二代表从服务器接收第一片段。

根据另一硬件方面，本发明涉及包括计算机程序，其包括当该程序被处理器运行时执行上面所限定的步骤的代码指令。本发明还涉及由终端可读的、其上记录了该程序的记录介质。

根据另一功能方面，本发明涉及一种用于根据给定的相应代表发送内容的片段，其特征在于，该方法包括：

-第一步骤，根据第一所选代表接收访问第一片段的请求，

-第一步骤，传送对该请求的响应，其包括修改第一代表的要求；

-第二步骤，根据第二代表接收访问第一片段的请求；

-第二步骤，根据第二代表从服务器发送第一片段。

根据另一功能方面，本发明涉及一种计算机程序，其包括当该程序由处理器运行时执行在上面描述的发送方法中限定的步骤的代码指令。本发明还涉及由服务器可读的、在其上记录有该程序的记录介质。

根据另一硬件方面，本发明涉及一种服务器，其能够通过网络发送内容的片段，其特征在于，该服务器包括

-第一模块，用于根据第一所选代表接收访问第一片段的请求，

-第一模块，用于传送对该请求的响应，其包括修改第一代表的要求；

-第二模块，用于根据第二代表接收访问第一片段的请求；

-用于根据第二代表从服务器传送第一片段的模块。

附图说明

通过阅读下面通过示例方式给出和参考附图的描述，能够更好地理解本发明。

图1表示根据本发明的一个实施例的基于经由因特网HTTP协议的使用的流传输架构。

图2和3表示包括在本发明的方法中的设备的电路。

图4表示根据本发明的一个实施例的时间图。

图5也表示时间图，该时间图示出了参考图4描述的实施例的变型。

具体实施方式

图1表示计算机化的系统SYS，其包括客户终端1、服务平台3和内容服务器8，该内容服务器能够根据客户终端1的请求提供内容。在示例性实施例中，终端、平台和服务器经由因特网网络2通信。

参考图2，终端1包括物理和/或软件资源，尤其：

-处理器CPU 1，

-第一存储模块MEM 1，

-诸如屏幕ECR的重放模块，

-用于与网络2通信的第一通信模块COM 1。

上面描述的模块以及第一微处理器CPU 1通过第一总线BUS 1链接在一起。

参考图3，服务器8包括

-第二处理器CPU 2，

-第二存储模块MEM 2，其尤其存储一个或多个内容CNT，

-用于与网络2通信的第二通信模块COM 2。

包括在服务器中的第二模块通过第二总线BUS 2链接至第二处理器CPU 2。

请注意，上面描述的总线的功能是保证在经由总线连接至处理器的不同电路之间传输数字数据。在示例中，所讨论的总线包括数据总线和控制总线。

还请注意，在示例中，上面描述的存储器是例如闪存类型的可写和可读访问的永久性存储器。

终端还包括相应的随机存取存储器(未示出)，用于以非持久方式存储在执行根据实施例的方法期间使用的计算数据。这些存储器未在附图中示出，应为它们与本发明的说明无关。

在示例中，被选择示出本发明的架构也称作基于HTTP协议的使用的流传输架构。常规地，客户终端(1)希望进入与内容服务器(8)的通信以下载包括一个或多个媒体(音频、视频等)的多媒体内容。

在后文中，在示例中，如上面说明那样，采用根据MPEG DASH标准的流传输的上下文。

终端(1)询问第一服务平台(3)以获得多媒体内容(y)的描述文件4的地址(在此为URL，但是更一般地指URI类型的通用地址)；此后该文件是MPD类型的文档(y.mpd)。

服务平台(3)通过为终端提供文档4的地址来进行响应；在该示例中，其为表示mpd类型的文档y的URL“HTTP://x.com/y.mpd”，其可以从内容服务器(8)“x.com”下载。

在附件1中呈现根据MPEG/DASH标准的示例性描述文档4。本发明上下文中的使得尤其能够生成通用地址的相关字段以斜体呈现。

描述文档4使得能够生成媒体片段的地址。

该结构实现了在上面提及的RFC 3986中描述的现有技术机制，以解析通用地址(URI)。客户终端必须解释特定的字段，并用合适的方式修改它们，以构建媒体片段的第一通用地址(URL或URI)。

该URI解析根据元素BaseURL完成，其可以在文档4的不同层级上出现。

在该示例中，借助两个字段“BaseUrl”(“HTTP://x.com/”和“video/”)以及“SegmentTemplate(片段模板)”来构建URL地址。

由MPEG/DASH标准规定的“SegmentTemplate”是一种用于基于多种标识符构建中间地址(URI)的通用方法，在示例中：

·$Time$：将以媒体片段的开始时间替换。该时间由“SegmentTimeline”提供，其在此表示对于每个新片段的开始有180180的偏移；

·$Number$：将以期望的媒体片段的序列号替换；

·$Bandwidth$：将以目标代表的“带宽”属性的值替换。

因此，用于访问质量(或比特率)为500kbps(每秒千比特)的最开始两个视频片段的最开始两个URL地址为：

1.HTTP://x.com/video/500000/0.mp4v，以及

2.HTTP://x.com/video/500000/180180.mp4v

请注意，该同一片段在此可以对应于数个可能的代表。在此，对于每个代表，对应的都是各自的比特率。例如，

HTTP://x.com/video/500000/0.mp4v

HTTP://x.com/video/2000000/0.mp4v

是第二片段的两个可能的代表，一个对应于500kbps的比特率，另一个对应于300kbps的比特率。

图4是在两个终端，即平台和内容服务器之间进行的交换的示意图。

假设终端1希望接收内容(y)。还假设在传送第二片段之后，内容服务器请求降低编码比特率，并且小于2000kbps。

在第一步骤ET1期间，终端1询问服务平台3以获得多媒体内容(y)的描述文件4的地址(在此为URL，但是更一般地是URI类型的通用地址)；此后该文件是MPD类型的文档(y.mpd)。

在第二步骤ET 2期间，服务平台(3)通过为终端提供文档4的地址来进行响应，在该示例中，这是URL

“HTTP://x.com/y.mpd”

表示可以从内容服务器(8)“x.com”下载的“mpd”类型的内容“y”。

在第三步骤ET 3期间，终端请求REQ(4)从服务器8下载描述文档4。

在第四步骤ET 4期间，终端接收并存储描述文档4。

在第五步骤ET 5期间，终端(1)借助上面描述的第一URL 1访问第一片段：

HTTP://x.com/video/2000000/0.mp4v。

在第六步骤ET 6期间，服务器8传送第一数据流F1/2000k，其包括第一片段。在接收到时，终端可以重放第一片段。

在第七步骤ET 7期间，终端(1)借助上面描述的第二URL 2访问第二片段：

HTTP://x.com/video/2000000/180180.mp4v。

在第八步骤ET 8期间，接收到下载第二片段的要求时，服务器8向终端1a传送修改编码比特率的要求。在示例中，该要求被包括在与包含该片段的数据流不同的消息中。该要求是通过请求终端降低用于第二片段的编码比特率的信息项来示例的。该信息例如插入到http类型的错误消息中。

错误消息例如为如下：

假设所讨论的信息是给定的比特率值，例如500000bps。该值可以在错误消息中提供，或者由客户端从例如存储在第一存储器MEM 1中的对应库中推导出。在该情况下，与一个代码对应的不仅有修改代表的要求，而且有给定的值。在我们的示例中，与值500对应的例如是500kbps的比特率值。

在第九步骤ET 9中，终端1接收错误消息；终端解释代码“500”，并且从中推导出该消息与编码比特率修改要求相关。终端还解释该编码比特率降低/限制信息，以便随后应用该降低。

在第十步骤ET10中，终端1修改地址，以便在考虑在第九步骤中接收的信息的情况下访问第二片段。因此，在我们的示例中，所得到的新地址是HTTP://x.com/video/500000/ 180180.mp4v。

内容服务器接收到该新的访问具有200kbps的编码比特率的第二片段的要求。

在第十一步骤ET11中，内容服务器传送数据流F2/500k，其包括具有200kbps的编码比特率的片段。此后，终端接收第二片段并对它进行重放。

上面描述的方法可以形成变型的主题。

所描述的信息可以采取多种形式。其可以如在上面描述的示例中那样具有固定的值。

其还可以对应于不应被超过的最大值。在该配置中，假设该信息指示比特率不能超过1000kbps，则在第八步骤中得到的新地址将包括小于1000kbps的比特率值。

在之前的示例中，该信息包括在HTTP错误消息中。本发明非常明显地不限于HTTP协议，而是也可以延伸至任何其他协议。

该信息还可以具有有限的有效时间Δt。该变型在图5中示出。在该附图中，步骤ET1至ET 7(其未被引用)对应于参考图4描述的那些。步骤ET8至ET11(在图5中示出)也与图4中示出的那些相同。

剩下的步骤引用为ET1-1至ET1-4。

在步骤ET1-1期间，终端(1)访问第三片段。未超过持续时间Δt，终端1考虑在第八步骤接收的比特率修改要求，并且借助如下的上面描述过的第一URL传送请求：

HTTP://x.com/video/500000/360360.mp4v。

在第二步骤ET1-2期间，内容服务器8传送第三数据流F3/500k，其包括具有500kbps的编码比特率的片段。终端此后接收第三片段并对其进行重放。

在第三步骤ET1-3期间，终端(1)访问第四片段。未超过持续时间Δt，终端1不再考虑在第八步骤ET8接收的比特率修改要求。终端再次查阅描述文档，以便创建第四片段的URL地址：

HTTP://x.com/video/2000000/720720.mp4v。

在第四步骤ET1-4期间，内容服务器8传送数据流F3/2000k，其包括具有2000kbps的编码比特率的片段。终端1此后接收这些片段并对其进行重放。

在我们的示例中，错误消息包括代码，或者事实上多个代码，其指示了将要使用的比特率以及在其期间必须考虑该比特率的持续时间Δt。

在超过了持续时间Δt的情况下，随后的地址再次基于描述文档4和基于初始时在建立会话时初始可用的代表或比特率。

即使不说，上面描述的实施例也仅是纯粹按完全非限制性指示的形式给出的，并且本领域技术人员可以容易地对其做出多个修改，而不偏离本发明的范围。

请注意，为了实现本发明的方法，除了上面参考图2描述的元件之外，终端还包括：

-第二模块，用于根据第二代表传送访问第一片段的请求；

-第二模块，用于根据第二代表从服务器接收第一片段。

还请注意，为了实现本发明的方法，服务器除了上面参考图3描述的元件之外还包括：

-第一模块，用于传送对该请求的响应，其包括要求修改第一代表的要求；

-第二模块，用于根据第二代表接收访问第一片段的请求；

-用于根据第二代表传送第一片段的模块。

请注意，本文件中使用的术语“模块”可以对应于软件组件或者硬件组件，或者能够实现对于该模块所描述的功能的一组硬件和/或软件。

附件1

表1：根据MPEG/DASH的MPD类型的文档4的示例。

Claims

1.一种用于管理由终端从服务器接收的内容的数据片段(0.mp4v,180180.mp4v)的代表的方法，所述方法包括获得文件的步骤(ET2)，基于所述文件产生通用地址，其中的一个地址与由所述终端从所述文件中描述的多个代表中选出的感兴趣片段的代表相关联，该片段能够根据所选的代表从服务器被接收，其特征在于，播放第一片段在终端的水平上包括如下步骤，即，

-第一步骤：根据第一所选代表传送(ET7)对于访问第一片段的请求；

-第一步骤：代替请求的第一片段，从服务器接收(ET8)对于该请求的响应，其包括对于修改第一代表的要求；

-第二步骤：根据由终端选择的第二代表再次传送(ET10)对于访问相同第一片段的请求；

-第二步骤：根据由终端选择的第二代表从服务器接收(ET11)第一片段；

利用第二代表播放第一片段。

2.根据权利要求1所述的管理方法，其特征在于，代表包括用于片段的编码比特率值，以及第一和第二代表包括不同的值。

3.根据权利要求1所述的方法，其特征在于，终端对于给定的持续时间(Δt)考虑第一代表的修改。

4.根据权利要求1所述的管理方法，其特征在于，根据HTTP协议传送修改要求。

5.一种能够接收内容的片段的终端(1)，所述终端具有对文件(4)的访问权，基于该文件生成通用地址，其中一个地址与由所述终端从在所述文件中描述的多个代表中选择的感兴趣片段的代表相关联，其特征在于，所述终端包括：

-第一模块，用于根据第一所选代表传送对于访问第一片段的请求，

-第一模块，用于代替请求的第一片段，从服务器接收对所述请求的响应，其包括对于修改第一代表的要求，

-第二模块，用于根据由终端选择的第二代表再次传送对于访问相同第一片段的请求；

-第二模块，用于根据由终端选择的第二代表从服务器接收第一片段；

-用于利用第二代表播放第一片段的模块。

6.由服务器根据给定的相应的代表发送内容的片段的方法，其特征在于包括如下步骤：

-第一步骤，根据第一所选代表接收对于访问第一片段的请求，

-第一步骤，代替请求的第一片段，传送对该请求的响应，其包括对于修改第一代表的要求；

-第二步骤，根据第二代表再次接收对于访问相同第一片段的请求；

-第二步骤，根据第二代表从服务器发送第一片段；

-利用第二代表播放第一片段。

7.一种能够经过网络发送内容的片段的服务器(8)，其特征在于，所述服务器包括

-第一模块，用于根据第一所选代表接收对于访问第一片段的请求，

-第一模块，用于代替请求的第一片段，传送对于所述请求的响应，其包括对于修改第一代表的要求；

-第二模块，用于根据第二代表再次接收对于访问相同第一片段的请求；

-模块，用于根据第二代表传送第一片段；

-用于利用第二代表播放第一片段的模块。

8.一种可由计算机读取的记录介质，该记录介质上记录了一种计算机程序，其包括当该程序由处理器运行时执行权利要求1至4之一中限定的步骤的代码指令。

9.一种可由计算机读取的记录介质，该记录介质上记录了一种计算机程序，其包括当该程序由处理器运行时执行权利要求6中限定的步骤的代码指令。