多媒体数据的处理的制作方法
【技术领域】
[0001]本公开涉及用于向用户提供多媒体服务的技术。具体地说，公开了用于向是自适应HTTP流播播放器的示例的DASH播放器传送多媒体内容的技术。
[0002]本解决方案可使用提供媒体分段传送的广播传送技术实施在网络解决方案内。具体地说，该解决方案可用在使用媒体分段的eMBMS传送或其它广播传送技术(像DSL接入系统(IPTV)中的IP多播)的情形中。进一步说，本解决方案适用于从高速缓存服务于媒体内容时。
【背景技术】
[0003]通过HTTP的DASH动态自适应流播是自适应流播技术，其将媒体流调整成当前可用的链路比特率，如在“Dynamic adaptive streaming over HTTP (DASH) 一 Part 1:Media presentat1n descript1n and segment formats，，(ISO/1EC 23009-1:2012 (E)，Vers1n 2.1c2.)中所公开的。
[0004]自适应HTTP流播技术依赖于客户端选择媒体质量。服务器或内容提供商描述了在所谓的清单文件中的所有可用质量表示，例如，媒体内容的表示可关于不同媒体比特率和从服务器访问表示的方式而不同。清单文件在流播会话开始时至少取一次，并且在会话期间可更新。Mro包括列表或生成所有媒体分段的URI的列表的构件，媒体分段属于媒体会话，并且用于取下一媒体分段。在苹果的HLS情况下，清单作为m3u8格式的播放列表文件进行格式化。在3GPP/ MPEG DASH情况下，清单是称为MPD媒体呈现描述的XML结构。
[0005]DASH被设计为客户端控制的自适应HTTP流播协议。那意味着，服务器描述了例如在MPD中的一组可用媒体质量，并且客户端根据链路比特率选择匹配链路比特率的媒体表示(即，媒体比特率)。一般而言，DASH解决方案包括:DASH服务器适合于给内容提供不同的媒体质量(所谓的表示)，并且在客户端侧，DASH客户端适合于请求具有不同质量的媒体内容。
[0006]大多数自适应HTTP流播技术都需要客户端不断从服务器取媒体分段。在媒体分段中含有某一媒体时间量(例如10秒的媒体数据)。在清单中指示的具体时间，在服务器使具体媒体表示的每个分段可用。在清单中描述了在客户端侧用于下载不同质量表示的分段的URI的创建方式。
[0007]图1描绘了在DASH环境下分段取的原理。客户端、DASH客户端与服务器、DASH服务器通信。
[0008]清单文件被作为HTTP GET清单文件消息10的应答接收，并且被处理以确定可能的质量11。在下一步骤12，客户端请求最低质量的数据、来自最低质量的HTTP GET分段#1，并且执行下载速率的测量，13。客户端不断测量链路比特率，同时接收媒体分段，14，以确定用于接收内容数据的适当质量。如果进行了改变表示的决定，15，则客户端可在任何时间改变成另一质量表示。在根据图1的实施例中，决定请求具有中等质量的媒体数据，来自中等质量的HTTP GET分段#2，16，并且继续下载速率的测量，17。
[0009]当前，还有可能通过广播系统递送DASH媒体分段，诸如eMBMS (LTE多媒体广播多播服务)。当小区或任何广播区域中的所有用户都使用相同特比流质量时，广播是有效的。那意味着，在一个区域中通常仅广播单个质量表示，并且所述区域中的客户端选择那个具体质量。
[0010]从而，通常，仅单个表示被广播到具体目标区域中，并且相同的内容流被广播到具有不同比特率约束或换句话说具有不同表示的不同广播区域中。从而，有可能，相同服务例如以较高比特率在城市区域中广播，以及在城郊区域中具有较低比特率。
[0011]DASH播放器可经由广播或单播接收内容。然而，DASH播放器没有信息，不管电话是在广播覆盖内和/或单播覆盖内。
[0012]在广播情形下，媒体分段必须首先由eMBMS客户端接收，之后可使它对DASH播放器可用。这是由于广播表示优于单播表示造成的缺点。当第一次调谐到广播DASH会话时，DASH播放器可接受附加延迟。然而，DASH播放器不知道UE是否在广播覆盖内。从而，如果电话不在广播覆盖内，则DASH播放器首先需要等待广播启动这个附加延迟的时间，才能发现广播接收是不可能的。
[0013]进一步说，因为客户端不知道它是正在从广播还是单播接收表示，所以它对两种接收以相同方式测量下载速率。在中等质量表示正在被广播的情况下，观察到良好下载速率的客户端可决定切换到未在广播的较高质量表示。一旦客户端已经切换，就有必要通过单播检索分段，然后它可能经历那个高质量表示的非常低的下载速率，因此体验的质量以及网络下载受到了负面影响。
[0014]例如由于执行的测量或由于接收到广播数据而引起的延迟导致了在用户侧的体验质量(QoE)降低，那么从QoE角度来看，在客户端侧的视频启动将尽可能快地执行。
【发明内容】
[0015]存在对于向用户有效提供媒体数据的技术的需求。具体地说，存在增加所呈现数据的体验水平的需求。
[0016]本发明在独立权利要求中实施了。在从属权利要求中描述了有利实施例。
[0017]该需求用向自适应HTTP流播播放器提供媒体内容的方法满足。所述方法包括从自适应HTTP流播播放器接收请求媒体内容的HTTP请求的步骤。在下一步骤，标识媒体内容作为在固定质量接口(S22)上可用的内容，并且然后确定在固定质量接口上提供的内容的表示偏好指示。所确定的表示偏好指示被发信号通知给自适应HTTP流播播放器。
[0018]进一步说，该需求用提供在自适应HTTP流播播放器中实现的媒体内容的方法满足。所述HTTP流播播放器向HTTP实体发送对于提供媒体内容的HTTP请求。作为对该请求的应答，自适应HTTP流播播放器从HTTP实体接收在固定质量接口上提供的媒体内容的表示偏好指示。作为下一步骤，使用接收的表示偏好指示请求在固定质量接口上提供的媒体内容。
[0019]在一个实现中，提出了适合于向自适应HTTP流播播放器提供媒体内容的HTTP实体装置。所述HTTP实体装置包括适合于从HTTP流播播放器接收请求媒体内容的HTTP请求的接收器。进一步说，存在适合于将媒体内容标识为在固定质量接口上提供的内容的标识器。进一步说，HTTP实体装置包括适合于确定在固定质量接口上提供的媒体内容的表示偏好指示的处理器和适合于向HTTP流播播放器发信号通知表示偏好指示的发送器。
[0020]在另外实施例中，提供了适合于提供媒体内容的自适应HTTP流播播放器装置。所述HTTP流播播放器装置包括适合于向HTTP实体发送对于提供媒体内容的HTTP请求的发送器。进一步说，存在适合于从HTTP实体接收表示偏好指示以便接收在固定质量接口上提供的媒体内容的接收器和适合于使用接收的表示偏好指示用于请求在固定质量接口上提供的媒体内容的处理器。
[0021]在另外实施例中，提出了适合于提供媒体内容的客户端装置，其包括自适应HTTP流播播放器装置和HTTP实体。
[0022]进一步说，装置节点适合于执行结合在对应节点中要执行的对应方法所要求保护的所有步骤。
【附图说明】
[0023]在下文，将参考在附图中例证的示范实施例进一步描述本发明，附图中:
图1示出了用于在自适应HTTP流播客户端上取分段的实施例。
[0024]图2示出了根据一个实施例的代理实体中的方法的流程图。
[0025]图3示出了根据一个实施例的自适应HTTP流播播放器中的方法的流程图。
[0026]图4示意性示出了根据一个实施例的代理实体。
[0027]图5示意性示出了根据一个实施例的自适应HTTP流播播放器。
图6示出了根据一个实施例的方法的系统。
图7示意性示出了根据一个实施例的系统。
[0028]图8示意性示出了根据一个实施例的系统。
[0029]图9示意性示出了根据一个实施例的系统。
[0030]图10示意性示出了根据一个实施例的系统。
[0031]图11示意性示出了根据一个实施例的消息交换。
【具体实施方式】
[0032]在如下描述中，为了说明而非限制，阐述了特定细节，诸如具体网络环境和通信标准等，以便提供对本发明的透彻理解。本领域技术人员将明白，本发明可以在脱离这些特定细节的其它实施例中实施。例如，本领域技术人员将认识到，本发明可用任何无线网络比如UMTS、GSM或LTE网络实施。作为另一示例，本发明还可实现在短程无线网络(诸如WLAN或蓝牙系统)或有线网络中，例如任何基于IP的网络(像IMS网络)中。
[0033]本发明可用某些(TV)广播网络