用于将媒体数据流式传送的定向广告插入的制作方法

技术领域

本公开内容涉及媒体数据的传输，例如，通过使用广播传输服务对媒体数据进行流式传送(streaming)。

背景技术：

数字视频能力可以被并入到包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上型电脑或台式机、数码相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频电话会议设备等的各种设备中。数字视频设备实施视频压缩技术(诸如在由MPEG-2、MPEG-4、ITU-T H.263或ITU-T H.264/MPEG-4、Part 10、高级视频编码(AVC)定义的标准以及这些标准的扩展中描述的那些视频压缩技术)以较高效地发送和接收数字视频信息。

视频压缩技术执行空间预测和/或时间预测以减少或去除视频序列中固有的冗余。对于基于块的视频编码，视频帧或者片(slice)可以被划分成宏块。每个宏块可以被进一步划分。帧内编码(I)帧或片中的宏块是通过使用相对于相邻宏块的空间预测来编码的。帧间编码(P或B)帧或片中的宏块可以使用相对于相同的帧或片中的相邻宏块的空间预测或者相对于其它参考帧的时间预测。

在视频数据(和/或其它媒体数据，诸如视频和/或定时文本数据)被编码后，媒体数据可以被分组化用于发送或存储。经分组化的媒体数据可以是通过使用诸如超文本传输协议(HTTP)的单播协议或者诸如增强多媒体广播多播服务(eMBMS)的多播协议来发送的。

技术实现要素：

概括而言，本公开内容描述与将定向广告插入媒体数据有关的技术。具体而言，媒体应用可以提供用户细节和/或用户数据(例如，对用户偏好的选择)给流式传送客户端，诸如基于HTTP的动态自适应流式传送(dynamic adaptive streaming over HTTP，DASH)客户端。流式传送客户端可以提供对应的数据给广播或多播中间件单元。中间件单元可以从广播或多播服务器接收针对一个或多个广告组的数据，并随后基于来自流式传送客户端的数据选择所述广告组中的一个广告组。替代地，流式传送客户端可以提供针对所述广告组中的一个广告组的标识符给中间件单元，例如，这发生在激活(即，解引用)包括与针对一广告组的标识符对应的替换属性的链接时通过将该标识符作为针对该属性的值插入该链接中来实现。

在一个例子中，一种用于获取媒体数据的方法，包括，通过基于HTTP的动态自适应流式传送(DASH)客户端：确定与多个广告组的广告媒体数据相关联的广告组标识符集合，其中，所述广告媒体数据将被播放在针对主媒体内容的广告插播期间，其中，所述主媒体数据是与清单文件相关联的，获取对所述清单文件的更新，其中，所述更新定义与所述广告媒体数据对应的远程时段，其中，对所述清单文件的所述更新指定用于包括标识符属性的可扩展标记语言(XML)链接语言(Xlink)统一资源定位符(URL)的模板，至少部分地基于所述DASH客户端的用户的特性，从所述集合中选择所述广告组中的一个广告组，根据所述模板，分配与所选择的广告组对应的标识符值给根据所述模板的所述Xlink URL的所述标识符属性，解引用包括与所选择的广告组对应的所述标识符值的所述Xlink URL，以从所述远程时段获取所选择的广告组的广告媒体数据，以及提供所述广告媒体数据给媒体应用。

在另一个例子中，一种获取媒体数据的方法包括，通过客户端设备的多媒体广播多播服务(MBMS)客户端：接收一个或多个广告组的广告媒体数据，从所述客户端设备的基于HTTP的动态自适应流式传送(DASH)客户端接收包括针对所述广告组中的一个广告组的标识符值的可扩展标记语言(XML)链接语言(Xlink)统一资源定位符(URL)，提取与所述标识符值对应的该个广告组的所述广告媒体数据，以及提供所提取的广告媒体数据给所述DASH客户端。

在另一个例子中，一种计算机可读存储介质其上已存储的指令当被执行时使得客户端设备的处理器：确定与多个广告组的广告媒体数据相关联的广告组标识符集合，其中，所述广告媒体数据将被播放在针对主媒体内容的广告插播期间，其中，所述主媒体数据是与清单文件相关联的，获取对所述清单文件的更新，其中，所述更新定义与所述广告媒体数据对应的远程时段，其中，对所述清单文件的所述更新指定用于包括标识符属性的可扩展标记语言(XML)链接语言(Xlink)统一资源定位符(URL)的模板，至少部分地基于所述客户端设备的用户的特性，从所述集合中选择所述广告组中的一个广告组，根据所述模板，分配与所选择的广告组对应的标识符值给根据所述模板的所述Xlink URL的所述标识符属性，解引用包括与所选择的广告组对应的所述标识符值的所述Xlink URL，以从所述远程时段获取所选择的广告组的广告媒体数据，以及提供所述广告媒体数据给媒体应用。

在另一个例子中，一种计算机可读存储介质其上已存储的指令当被执行时使得客户端设备的处理器：接收一个或多个广告组的广告媒体数据，从所述客户端设备的基于HTTP的动态自适应流式传送(DASH)客户端接收包括针对所述广告组中的一个广告组的标识符值的可扩展标记语言(XML)链接语言(Xlink)统一资源定位符(URL)，提取与所述标识符值对应的该个广告组的所述广告媒体数据，以及提供所提取的广告媒体数据给所述DASH客户端。

在另一个例子中，一种获取媒体数据的方法包括，通过客户端设备的多媒体广播多播服务(MBMS)客户端：从所述客户端设备的基于HTTP的动态自适应流式传送(DASH)客户端接收包括针对与广告媒体数据对应的远程时段的标识符属性的可扩展标记语言(XML)链接语言(Xlink)统一资源定位符(URL)，经由广播传输或多播传输接收针对所述远程时段的数据(例如，文件传送表(FDT)或过滤器描述片段，其包括groupIDFilter语法元素)，当所述广播传输或所述多播传输的数据包括与所述XLink URL的标识符值匹配的标识符值时，确定针对所述远程时段的数据匹配所述XLink URL，响应于确定针对所述远程时段的数据匹配所述XLink URL，递送针对所述远程时段的数据给所述DASH客户端。

一个或多个例子的细节是在附图和下面的说明书中阐述的。根据说明书和附图并根据权利要求书，其它特征、对象和益处将是显而易见的。

附图说明

图1是示出实施了用于在网络上对媒体数据进行流式传送的技术的示例系统的框图。

图2是具体地示出图1的获取单元的示例组件集合的框图。

图3是示出示例多媒体内容中的各元素的概念图。

图4是示出可以实施本公开内容的技术的另一示例系统的框图。

图5是示出可以实施本公开内容的技术的另一示例系统的框图。

图6A-8B是示出多种示例方法的序列图，其中，DASH客户端确保对适当的广告内容的接收。

图9是示出当前被定义的用以携带位置过滤器数据的示例过滤器描述片段的概念图。

图10是示出用以携带用户偏好&简档(UP/P)数据的对过滤器描述片段的扩展的概念图。

图11A和11B是示出根据本公开内容的技术用于MBMS客户端协助的广告选择的示例方法的序列图。

图12是示出根据本公开内容的技术用于针对实时传输协议(RTP)的MBMS客户端协助的广告选择与插入的示例方法的序列图。

图13A到13D是示出对文件传送表(FDT)文件元素的示例扩展的概念图。

图14是示出可以执行本公开内容的技术的另一示例系统300的框图。

图15A和15B是示出根据本公开内容的技术的示例方法的序列图。

具体实施方式

概括而言，本公开内容描述了用于定向广告(ad)插入的技术。这些技术可以被用在例如根据单播、广播或者诸如增强多媒体广播多播服务(eMBMS)的多播服务对媒体数据进行流式传送时。例如，本公开内容的这些技术可以结合或者MBMS改进-增强MBMS操作(MI-EMO)。MI-EMO被描述在例如在http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-12_description_20131224.zip处可获得的2013年12月的3GPP版本12V0.1.1的概述中。这些技术也可以被用在增强MBMS(eMBMS)中，eMBMS被描述在例如在www.3gpp.org/ftp/Specs/archive/26_series/26.848/26848-c00.zip处可获得的3GPP TR 26.848v.12.0.0(2014年12月)中的增强MBMS操作和/或在www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-c40.zip处可获得的3GPP TS 26.346v.12.4.0(2014年12月)中的MBMS协议和编译码器中。

本公开内容的技术可以根据下面的对MI-EMO的示例使用情形来使用：居住城市的两大足球队相互间将在周末进行德比比赛。由于该赛事被期望在球迷当中产生广大兴趣，所以组织方计划在MBMS上提供服务给其订户。组织方计划递送不同的定向广告集合给俱乐部球迷，即，以便在赛事间歇期间播放等，以便推广来自每个足球俱乐部的球迷商店的产品、分享俱乐部相关的新闻等。

本公开内容的技术可以支持MBMS和eMBMS中的定向广告插入。本公开内容的技术可以被用以广播主要内容和广告，并使得能够在下载客户端元素(例如，软件元素、硬件元素或者硬件和软件的组合)的支持下插入定向广告。对于现场事件(即，在捕获、编码以及分组化后尽可能快地进行流式传送的现场捕获的媒体内容)，本公开内容的技术可以允许调度对定向广告的递送使得这些广告可以被实时插入到主要内容中。本公开内容的技术还可以允许MBMS客户端根据用户特点选择性地接收通过MBMS递送的广告。这类用户特点可以对应于在例如在客户端设备中存储的用户偏好/简档数据存储库中存储的信息。

本公开内容的技术可以当存在下面的限制时被应用：在MBMS上的定向广告内容递送可以仅通过在相同的单向传输的文件递送(FLUTE)会话上在相同的临时移动组标识(TMGI)上发送全部广告相关的资源来进行。随后，由于可能不能够将广告内容关联于由特定的用户特点标识的特定组，接收可以用如在TS 26.346的第7.2节中定义的混杂方法来进行。TS 26.346被描述在在http://www.3gpp.org/DynaReport/26234.htm处可获得的2013年12月的第三代合作伙伴计划；技术规范组服务和系统方面；多媒体广播/多播服务(MBMS)；协议和编解码器(版本12)；V12.0.0中。同样，本公开内容的技术可以当存在下面的额外或替代的限制时被应用：可能不能允许MBMS客户端根据用户特点选择性地接收通过MBMS递送的广告内容，以便使得能够进行一副本操作(one-copy operation)以指令FLUTE接收(由fileURI标识的或者由其它模式潜在标识的)一个或多个特定文件的副本。本公开内容的技术还可以被应用于提供用于在MBMS上进行实时传输协议(RTP)流式传送的定向广告插入。

概括而言，本公开内容描述了用于支持定向广告插入的三个例子。第一示例技术是针对基于应用的广告选择。第二示例技术是针对基于服务器的广告选择，例如，包括基于HTTP的动态自适应流式传送(DASH)客户端。在第三示例技术中，MBMS客户端协助广告选择。这些示例技术的额外细节及其种类、组合和子组合在下面被详细描述。

在一些示例中，当通过使用广播或多播接收媒体内容时，MBMS客户端或eMBMS客户端可以接收媒体内容，随后使得媒体内容可用于流式传送客户端，诸如DASH客户端。DASH客户端可以通过使用例如HTTP获取操作来从MBMS客户端获取媒体内容。在诸如DASH的HTTP流式传送中，频繁使用的操作包括HEAD、GET和部分GET。HEAD操作获取与给定的统一资源定位符(URL)或者统一资源名(URN)相关联的文件的头部，而不获取与该URL或URN相关联的有效载荷。GET操作获取与给定的URL或URN相关联的整个文件。部分GET操作接收字节范围作为输入参数并获取文件的连续数量的字节，其中，字节的数量对应于所接收的字节范围。因而，电影片段可以被提供用于HTTP流式传送，这是因为部分GET操作可以获得一个或多个个体电影片段。在电影片段中，可以具有不同轨道的若干轨道片段。在HTTP流式传送中，媒体呈现可以是客户端可访问的结构化的数据集合。客户端可以请求并下载媒体数据信息以呈现流式传送服务给用户。

在使用HTTP流式传送对3GPP数据进行流式传送的示例中，可以有用于多媒体内容的视频和/或音频数据的多个表示。如下所解释地，不同的表示可以对应于不同的编码特性(例如，视频编码标准的不同简档或等级)、不同的编码标准或编码标准的扩展(诸如多视图和/或可伸缩扩展)或者不同的比特率。这种表示的清单可以被定义在媒体呈现描述(MPD)数据结构中。媒体呈现可以对应于HTTP流式传送客户端设备可访问的结构化的数据集。HTTP流式传送客户端设备可以请求并下载媒体数据信息以呈现流式传送服务给该客户端设备的用户。媒体呈现可以被描述在MPD数据结构中，该MPD数据结构可以包括对MPD的更新。

媒体呈现可以包含一个或多个时段的序列。时段可以由MPD中的Period(时段)元素来定义。每个时段在MPD中可以具有属性start(开始)。MPD可以包括针对每个时段的start属性和availableStartTime(可用开始时间)属性。对于实时服务，该时段的start属性与MPD属性availableStartTime的和可以指定UTC格式中该时段的可用时间，特别是对应的时段中的每个表示的第一媒体段。对于按需服务，第一时段的start属性可以是0。对于任何其它时段，start属性可以指定在对应的时段的开始时间相对于第一时段的开始时间之间的时间偏移。每个时段可以延长直到下一时段的开始为止，或者在最后时段的情形中直到媒体呈现的结束为止。时段开始时间可以是精确的。时段开始时间可以反映由播放所有在前时段的媒体产生的真实定时。

每个时段可以包含针对相同的媒体内容的一个或多个表示。表示可以是音频或视频数据的多个替代编码版本中的一个。表示可以由于编码类型(例如，由于针对视频数据的比特率、分辨率和/或编解码器以及针对音频数据的比特率、语言和/或编解码器)而不同。术语表示可以被用以指代编码音频或视频数据中与多媒体内容的特定时段对应的并以特定方式编码的部分。

特定时段的表示可以被分配给由MPD中对该表示属于的适配集合的属性进行指示的组。相同的适配集合中的表示通常相互间被视作是替代物，这是因为客户端设备可以动态且无缝地在这些表示之间切换，以例如执行带宽适配。例如，针对特定时段的视频数据的每个表示可以被分配给相同的适配集合，使得这些表示中的任何表示都可以被选择用于解码以呈现针对对应的时段的多媒体内容的诸如视频数据或音频数据的媒体数据。在一些示例中，一个时段内的媒体内容可以由来自组0(如果存在的话)的一个表示或者来自每个非零组的至多一个表示的组合来表示。针对一时段的每个表示的定时数据可以相对于该时段的开始时间来表达。

表示可以包括一个或多个段。每个表示可以包括初始化段，或者表示的每个段可以是自初始化的。当存在时，初始化段可以包含用于访问该表示的初始化信息。通常，初始化段不包含媒体数据。段可以是由诸如统一资源定位符(URL)、统一资源名(URN)或者统一资源标识符(URI)的标识符来唯一引用的。MPD可以提供用于每个段的标识符。在一些示例中，MPD还可以以range(范围)属性的形式提供字节范围，range属性可以对应于针对由URL、URN或URI可访问的文件内的段的数据。

不同的表示可以被选择用于基本上同时获取不同类型的媒体数据。例如，客户端设备可以选择要从其获取段的音频表示、视频表示以及定时文本表示。在一些示例中，客户端设备可以选择特定的适配集合用于执行带宽适配。也即，客户端设备可以选择包括视频表示的适配集合、包括音频表示的适配集合和/或包括定时文本的适配集合。替代地，客户端设备可以选择针对特定类型的媒体(例如，视频)的适配集合，以及直接选择针对其它类型的媒体(例如，音频和/或定时文本)的适配集合。

图1是示出实施了用于在网络上对媒体数据进行流式传送的技术的示例系统10的框图。在此示例中，系统10包括内容准备设备20、服务器设备60以及客户端设备40。客户端设备40和服务器设备60通过可以包括因特网的网络74而被通信地耦合。在一些示例中，内容准备设备20以及服务器设备60还可以通过网络74或者另一网络而被耦合，或者可以被直接通信地耦合。在一些示例中，内容准备设备20以及服务器设备60可以包括相同的设备。

图1的示例中的内容准备设备20包括音频源22和视频源24。音频源22可以包括例如麦克风，其生成对要由音频编码器26编码的经捕获的音频数据表示的电信号。替代地，音频源22可以包括用于存储先前记录的音频数据的存储介质、诸如计算机合成器的音频数据产生器或者任何其它音频数据源。视频源24可以包括用于生成要由视频编码器28编码的视频数据的视频相机、编码有先前记录的视频数据的存储介质、诸如计算机图形源的视频数据产生单元或者任何其它视频数据源。内容准备设备20不必在所有的示例中都被通信地耦合到服务器设备60，而是可以将多媒体内容存储到由服务器设备60读取的单独介质。

原始音频和视频数据可以包括模拟或数字数据。模拟数据可以在由音频编码器26和/或视频编码器28编码前被数字化。音频源22可以在谈话参与方正在讲话时获得来自谈话参与方的音频数据，而视频源24可以同时获得谈话参与方的视频数据。在其它示例中，音频源22可以包括包含经存储的音频数据的计算机可读存储介质，而视频源24可以包括包含经存储的视频数据的计算机可读存储介质。以此方式，在本公开内容中描述的技术可以被应用到现场流式传送实时音频和视频数据，或者被应用到经归档的、预先记录的音频和视频数据。

与视频帧对应的音频帧通常为包含由音频源22捕获了的(或者产生了的)与由视频源24捕获了的(或者产生了的)的包含在视频帧内的视频数据同时存在的音频数据的音频帧。例如，当谈话参与方通常通过谈话生成音频数据时，音频源22捕获音频数据，而在同时(也即，当音频源22正捕获音频数据时)视频源24捕获谈话参与方的视频数据。因此，音频帧可以在时间上对应于一个或多个特定的视频帧。相应地，与视频帧对应的音频帧通常对应于这样的情况：在该情况中，音频数据和视频数据被同时捕获，且针对该情况，音频帧和视频帧分别包括被同时捕获的音频数据和视频数据。

在一些示例中，音频编码器26可以在每个经编码的音频帧中编码时间戳，在该时间戳表示的时间处经编码的音频帧的音频数据被记录，并且同样地，视频编码器28可以在每个经编码的视频帧中编码时间戳，在该时间戳表示的时间处经编码的视频帧的视频数据被记录。在这样的示例中，对应于视频帧的音频帧可以包括包含时间戳的音频帧和包含相同时间戳的视频帧。内容准备设备20可以包括内部时钟，音频编码器26和/或视频编码器28根据该内部时钟可以产生时间戳，或者音频源22和视频源24可以使用该内部时钟以将音频和视频数据分别与时间戳关联。

在一些示例中，音频源22可以发送与音频数据被记录时的时间对应的数据给音频编码器26，而视频源24可以发送与视频数据被记录时的时间对应的数据给视频编码器28。在一些示例中，音频编码器26可以在经编码的音频数据中编码序列标识符以指示经编码的音频数据的相对时间排序，而不必表示音频数据被记录时的绝对时间，并且同样地，视频编码器28也可以使用序列标识符以指示经编码的视频数据的相对时间排序。同样地，在一些示例中，序列标识符可以被映射或以其它方式被相关于时间戳。

音频编码器26通常生成经编码的音频数据的流，而视频编码器28生成经编码的视频数据的流。每个个体数据流(无论是音频或视频)可以被称为基本流。基本流是表示中的单个的、经数字编码的(可能是经压缩的)组分。例如，该表示的经编码的视频或音频部分可以是基本流。基本流可以在被封装在视频文件内前被转换成分组化基本流(PES)。在相同的表示内，流ID可以被用以将属于一个基本流的PES-分组与其它分组区分开。基本流的数据的基本单元是分组化基本流(PES)分组。因此，经编码的视频数据通常对应于基本视频流。同样，音频数据对应于一个或多个相应的基本流。

许多视频编码标准(如ITU-T H.264/AVC和即将到来的高效视频编码(HEVC)标准)定义了语法、语义和用于无差错比特流的解码过程，其中语法、语义和用于无差错比特流的解码过程中的任意者符合特定的简档或等级。虽然视频编码标准通常不指定编码器，但编码器的任务有保证所产生的比特流对于解码器而言是标准兼容的。在视频编码标准的背景下，“简档”对应于算法、特征或工具以及向它们施加的约束的子集合。如H.264标准所定义地，例如，“简档”是由H.264标准指定的整个比特流语法的子集合。“等级”对应于解码器资源消耗的限制(诸如，例如，解码器的存储和计算)，其是与图像的分辨率、比特率和块处理率相关的。简档可以以profile_idc(简档指示符)值用信号进行发送，而等级可以以level_idc(等级指示符)值通过信号进行发送。

H.264标准例如认识到：在由给定简档的语法施加的界限内，还可能需要编码器和解码器的性能的较大变化，这取决于由比特流中的诸如解码图像的指定大小的语法元素采用的值。H.264标准进一步认识到：在许多应用中，去实施能够处理对特定的简档内的语法的所有假设使用的解码器是既不现实也不经济的。因此，H.264标准定义了“等级”作为对比特流中的语法元素的值施加的约束的指定集合。这些约束可能是对值的简单限制。替代地，这些约束可以采取对值的算术组合的约束的形式(例如，图片的宽度乘以图片的高度乘以每秒解码的图像数)。H.264标准进一步规定了个体实现方案可以针对每个支持的简档支持不同的等级。

符合一简档的解码器通常支持在该简档中定义的所有特征。例如，作为编码特征，B-图像编码未在H.264/AVC的基线简档中获得支持，而在H.264/AVC的其它简档中获得支持。符合一等级的解码器应该能够解码不需要超过在该等级中定义的限制的资源的任何比特流。简档和等级的定义可以有助于可解释性。例如，在视频传输期间，一对简档和等级的定义可以经协商并被同意用于整个传输会话。更具体地说，在H.264/AVC中，等级可以定义对需要被处理的宏块的数目、解码图像缓冲区(DPB)大小、编码图像缓冲区(CPB)的大小、垂直运动矢量范围、每两个连续的MB的运动矢量的最大数量、以及B-块是否可以具有小于8x8像素的子宏块分区的限制。以此方式，解码器可以确定解码器是否能够正确解码该比特流。

在图1的示例中，内容准备设备20的封装单元30接收包括来自视频编码器28的经编码的视频数据的基本流以及包括来自音频编码器26的经编码的音频数据的基本流。在一些示例中，视频编码器28和音频编码器26中的每个可以包括用于根据经编码的数据形成PES分组的分组化器。在其它的示例中，视频编码器28和音频编码器26中的每个可以与根据经编码的数据形成PES分组的相应分组化器通过接口进行连接。在其它的示例中，封装单元30可以包括用于根据经编码的音频和视频数据形成PES分组的分组化器。

视频编码器28可以以多种方式编码多媒体内容的视频数据，以生成处于多种比特率的并具有多种特性(诸如像素分辨率、帧速率、对多种编码标准的符合性、对针对多种编码标准的多种简档和/或简档等级的符合性、具有一个或多个视图(例如，用于二维或三维回放)的表示或者其它这类特性)的对该多媒体内容的不同表示。如在本公开内容中使用的表示可以包括音频数据、视频数据、文本数据(例如，用于隐蔽式字幕)或者其它这类数据。该表示可以包括基本流，诸如音频基本流或视频基本流。每个PES分组可以包括stream_id用于标识该PES分组所属的基本流。封装单元30负责将基本流组装成具有不同表示的视频文件(例如，段)。

封装单元30接收来自音频编码器26和视频编码器28的表示的基本流的PES分组并根据PES分组形成对应的网络抽象层(NAL)单元。在H.264/AVC(高级视频编码)的示例中，经编码的视频段被组织成NAL单元，NAL单元提供了“网络友好的”视频表示寻址应用，诸如视频电话、存储、广播或流式传送。NAL单元可以被分类成视频编码层(VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎，并可以包括块、宏块和/或片级数据。其它的NAL单元可以是非VCL NAL单元。在一些示例中，处在一个时刻中的编码图像(通常作为主编码图像来呈现)可以被包含在访问单元中，该访问单元可以包括一个或多个NAL单元。

除了其它之外，非VCL NAL单元可以包括参数集合NAL单元和SEI NAL单元。参数集合可以包含序列级报头信息(在序列参数集合(SPS)中)和变化不频繁的图片级报头信息(在图像参数集合(PPS)中)。利用参数集合(例如，PPS和SPS)，变化不频繁的信息不需要被重复用于每个序列或图片，因此编码效率可以被提升。此外，对参数集合的使用可以使得能够对重要报头信息的带外传输，这避免了需要针对错误恢复的冗余传输。在带外传输的例子中，参数集合NAL单元可以被发送在与诸如SEI NAL单元的其它NAL单元相比而言不同的信道上。

补充增强信息(SEI)可以包含不必需用于解码来自VCL NAL单元的编码图像样本的信息，但可以协助与解码、显示、错误恢复以及其它用途相关的过程。SEI消息可以被包含在非VCL NAL单元中。SEI消息是一些标准规范的规范性部分，并因而并不总是被强制用于标准兼容的解码器实现方案。SEI消息可以是序列级SEI消息或图像级SEI消息。一些序列级信息可以被包含在诸如SVC示例中的可放缩性信息SEI消息以及MVC中的视图可放缩性信息SEI消息的SEI消息中。这些示例SEI消息可以传达关于例如对操作点的提取和操作点的特性的信息。另外，封装单元30可以形成清单文件，诸如用于对表现的特性进行描述的媒体呈现描述符(MPD)。封装单元30可以根据可扩展标记语言(XML)格式化MPD。

封装单元30可以提供针对多媒体内容的一个或多个表示的数据连同清单文件(例如，MPD)给输出接口32。输出接口32可以包含网络接口或用于向存储介质进行写入的接口，诸如通用串行总线(USB)接口、CD或DVD刻录器或刻录机、对磁或闪存存储介质的接口或者用于存储或发送媒体数据的其它接口。封装单元30可以提供多媒体内容的每一个表示的数据给输出接口32，输出接口32可以经由网络传输或存储介质将该数据发送给服务器设备60。在图1的示例中，服务器设备60包括用于存储多种多媒体内容64的存储介质62，多种多媒体内容64中的每个包括相应的清单文件66以及一个或多个表示68A–68N(表示68)。在一些示例中，输出接口32也可以直接发送数据给网络74。

在一些示例中，表示68可以被分成适配集合。也即，表示68的多个子集合可以包括特性的相应公共集合，诸如编解码器、简档和等级、分辨率、视图数量、用于段的文件格式、文本类型信息(其可以标识要以表示来显示的文本的语言或其它特性和/或要被解码并例如通过扬声器被表示的音频数据)、相机角度信息(其可以描述针对适配集合中的表示的场景的相机角度或真实世界相机视角)、用于描述针对特定观众的内容适宜性的评级信息等。

清单文件66可以包括对与特定适配集合对应的表示68的子集合进行指示的数据、以及针对这些适配集合的公共特性。清单文件66还可以包括对用于适配集合中的个体表示的诸如比特率的个体特性进行表示的数据。以此方式，适配集合可以支持简化的网络带宽适配。适配集合中的表示可以是使用清单文件66的适配集合元素的孩元素来指示的。

服务器设备60包括请求处理单元70和网络接口72。在一些示例中，服务器设备60可以包括多个网络接口。此外，服务器设备60的任何或所有特征可以被实现在内容递送网络的诸如路由器、网桥、代理设备、交换机或其它设备的其它设备上。在一些示例中，内容递送网络的中间设备可以将多媒体内容64的数据高速缓存，并包括基本上符合服务器设备60的那些组件的组件。概括而言，网络接口72被配置为经由网络74发送和接收数据。

请求处理单元70被配置为接收来自诸如客户端设备40的客户端设备的针对存储介质62中的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(HTTP)1.1版，如在RFC 2616中描述地，由R.Fielding等人在IETF的网络工作组在1999年6月提出的“超文本传输协议–HTTP/1.1(Hypertext Transfer Protocol–HTTP/1.1)”。也即，请求处理单元70可以被配置为接收HTTP GET或部分GET请求并响应于这些请求而提供多媒体内容64的数据。这些请求可以指定表示68中的一个表示的段，例如这通过使用该段的URL来实现。在一些示例中，这些请求还可以指定该段的一个或多个字节范围，从而包括部分获取请求。请求处理单元70还可以被配置为服务HTTP HEAD请求以提供表示68中的一个表示的段的报头数据。在任意情形中，请求处理单元70可以被配置为处理这些请求，以向诸如客户端设备40的请求设备提供请求的数据。

另外或者替代地，请求处理单元70可以被配置为经由广播或多播协议(诸如eMBMS)递送媒体数据。内容准备设备20可以与如所描述的方式大致相同的方式创建DASH段和/或子段，而服务器设备60可以通过使用eMBMS或者另一广播或多播网络传输协议来递送这些段或子段。例如，请求处理单元70可以被配置为接收来自客户端设备40的多播组加入请求。也就是说，服务器设备60可以在与同特定的媒体内容(例如，现场事件的广播)相关联的多播组相关联的互联网协议(IP)地址广告给包括客户端设备40的客户端设备。客户端设备40既而可以提交要加入多播组的请求。这个请求可以通过诸如路由器构成网络74的网络74来传播，使得路由器能够将要发往与多播组相关联的IP地址的业务导向诸如客户端设备40的订阅客户端设备。

如在图1的示例中示出地，多媒体内容64包含清单文件66，清单文件66可以对应于媒体呈现描述(MPD)。清单文件66可以包含对不同的替代表示68的描述(例如，具有不同质量的视频服务)并且该描述可以包括例如编解码器信息、简档值、等级值、比特率以及表示68的其它描述性特性。客户端设备40可以获取媒体呈现的MPD以确定如何访问表示68的段。

特别而言，获取单元52(其可以实现本公开内容的技术)可以获取客户端设备40的配置数据(未显示)，以确定视频解码器48的解码能力和视频输出44的渲染能力。配置数据还可以包括由客户端设备40的用户选择的语言偏好、与由客户端设备40的用户设置的深度偏好对应的一个或多个相机视角和/或由客户端设备40的用户选择的评级偏好中的任一者或全部。获取单元52可以包括例如网页浏览器或媒体客户端，其被配置为提交HTTP GET和部分GET请求。获取单元52可以对应于由客户端设备40的一个或多个处理器或处理单元(未显示)执行的软件指令。在一些示例中，相对于获取单元52所描述的全部或部分功能可以以硬件或硬件、软件和/或固件的组合实现，其中，必要的硬件可以被提供以执行针对软件或固件的指令。

获取单元52可以将客户端设备40的解码和渲染能力与由清单文件66的信息指示的表示68的特性进行比较。获取单元52可以首先获取清单文件66的至少一部分，以确定表示68的特性。例如，获取单元52可以请求清单文件66的对一个或多个适配集合的特性进行描述的一部分。获取单元52可以选择表示68的子集合(例如，适配集合)，其具有可以由客户设备40的编码和渲染能力满足的特性。获取单元52随后可以确定针对适配集合中的表示的比特率，确定当前可用的网络带宽量，并获取来自具有可以由网络带宽满足的比特率的表示中的一个表示的段。

一般而言，较高比特率的表示可以取得较高质量的视频回放，而在可用的网络带宽降低时，较低比特率的表示可以提供足够质量的视频回放。因此，当可用的网络带宽相对较高时，获取单元52可以获取来自相对较高比特率的表示的数据，而当可用的网络带宽较低时，获取单元52可以获取来自相对较低比特率的表示的数据。以这种方式，客户端设备40可以在网络74上将多媒体数据流式传送，同时也适应于网络74的变化的网络带宽可用性。

另外或者替代地，获取单元52可以被配置为根据诸如eMBMS或IP多播的广播或多播网络协议来接收数据。在这样的示例中，获取单元52可以提交要加入与特定的媒体内容相关联的多播网络组的请求。在加入多播组后，获取单元52可以接收多播组的数据，而不需要向服务器设备60或内容准备设备20发出进一步请求。当多播组的数据不再被需要时，获取单元52可以提交要离开多播组的请求，以例如停止回放或者以改变信道到不同的多播组。

在本公开内容的第一示例技术(基于应用的广告选择)中，获取单元52(或诸如DASH客户端的客户端应用之类的客户端设备40的另一个元素，其可以构成获取单元52的部分)可以执行定向广告选择，而不用来自DASH客户端或来自MBMS服务层的协助。在这个示例中，用于选择广告的智能在于这个应用的责任或是这个应用的责任，这可以涉及到与未由诸如3GPP TS 26.346(多媒体广播/组播业务(MBMS)，协议和编解码器)的可适用标准指定的其它服务使能器交互。这个示例可以使能实现不同的基于HTTP的递送技术，例如，对高速缓存和/或cookies的使用。在这个示例中，MBMS服务层可以仅提供广告递送。DASH客户端可以仅取得如所述应用所指令的MPD。这个示例可以在由DASH-IF(DASH产业论坛)设计的广告插入框架后被建模。这个第一示例技术的进一步细节在下面参照图4来描述。

在本公开内容的第二示例技术集(基于服务器的广告选择，包括DASH客户端)，获取单元52包括DASH客户端，该DASH客户端在来自网络74的设备(例如，服务器设备60、内容准备设备20、或在图1中未示出的另一设备)协助下执行定向广告选择。一般来说，网络74包括一设备，该设备使用DASH事件机制以触发获取单元52的DASH客户端取得更新的MPD，该更新的MPD包含元数据以影响广告确定。关于获取单元52的MBMS客户端是下载所有广告还是只下载选择的广告，标称模式和增强模式两者都可以被采用。这种技术可以在由DASH-IF设计的广告插入框架后被建模。根据这个第二示例的技术的各个方面参照图5-8B来描述。

虽然出于示例的目的，用于更新MPD的DASH事件机制已被描述，但是应当明白，DASH事件机制的使用不是被强制用以使能实现对更新的MPD的递送/采集(其中更新的MPD包含远程周期元素，该远程周期元素描述要在节目中的插入/接合点期间取得的广告(ad)段)。等效的功能还可以通过以足够高的频率将周期性期望MPD更新(其通过MPD@minimumUpdatePeriod用信号进行发送)用信号进行发送来提供，使得DASH客户端通过保持对MPD更新的检查而将不会错过广告插播的动态发生。对这种最小化的更新周期的使用的示例在下面参照图15A-15B的方法来描述。

在本公开内容的第三示例技术(MBMS客户端协助的广告选择)中，获取单元52的MBMS客户端基于对用户服务描述(USD)中包含的元数据的处理来执行广告选择。在这个示例中，广告选择智能与控制可以被假定仅存在于获取单元52的MBMS客户端。MBMS客户端可以在流式传送节目递送前选择性地下载并预先高速缓存广告。这个示例将不被限于DASH的内容个性化机制表示为应用服务。因此，这个第三示例技术可以同等适用于并以公共方式工作用于基于实时传输协议(RTP)的流式传送服务递送。根据这个第三示例的技术的各个方面是参照图9-11B来描述的。

网络接口54可以接收并提供选择的表示的段的数据给获取单元52，该获取单元52既而提供段给解封装单元50。解封装单元50可以将视频文件的元素解封装成组成的PES流，将PES流解分组化以获取经编码的数据，以及将经编码的数据发送给音频解码器46或视频解码器48，这取决于经编码的数据是音频流还是视频流的部分，例如，如通过该流的PES分组报头所指示地。音频解码器46解码经编码的音频数据并将经解码的音频数据发送给音频输出42，而视频解码器48解码经编码的视频数据并将可以包括流的多个视图的经解码的视频数据发送给视频输出44。

视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52以及解封装单元50中的每个都可以当适用时被实现成多种合适的处理电路中任一种，诸如一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、分立逻辑电路、软件、硬件、固件或其任何组合。视频编码器28和视频解码器48中的每个可以被包括在一个或多个编码器或解码器中，该一个或多个编码器或解码器中的任一者可以被集成作为经组合的视频编码器/解码器(编解码器)的一部分。同样地，音频编码器26和音频解码器46中的每个可以被包括在一个或多个编码器或解码器中，该一个或多个编码器或解码器中的任一者可以被集成作为经组合的编解码器的一部分。一种包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和/或封装单元50的装置可以包括集成电路、微处理器和/或无线通信设备，诸如蜂窝电话。

客户端设备40、服务器设备60和/或内容准备设备20可以被配置为根据本公开内容的技术来工作。为了示例的目的，本公开内容围绕客户端设备40和服务器设备60描述了这些技术。然而，应该明白，内容准备设备20可以被配置为执行这些技术，而不是(或除了)服务器设备60。

封装单元30可以形成NAL单元，该NAL单元包含用于标识NAL单元所属于的节目的报头以及有效载荷，例如音频数据、视频数据或对NAL单元对应的传输流或节目流进行描述的数据。例如，在H.264/AVC中，NAL单元包括1字节的报头以及可变大小的有效载荷。NAL单元在其有效载荷中包括视频数据，该NAL单元可以包括多种粒度级别的视频数据。例如，NAL单元可以包括视频数据块、多个块、视频数据片或者视频数据的整个画面。封装单元30可以以基本流的PES分组形式从视频编码器28接收经编码的视频数据。封装单元30可以将每个基本流与对应的节目相关联。

封装单元30也可以从多个NAL单元组装访问单元。一般来说，访问单元可以包括一个或多个NAL单元，用于表示视频数据帧以及在该帧对应的音频数据可用时用于表示这种音频数据。访问单元通常包括针对一个输出时间实例的全部NAL单元，例如，针对一个时间实例的全部音频和视频数据。例如，如果每个视图有每秒20帧的帧速率(fps)，那么每个时间实例可以对应于0.05秒的时间间隔。在这个时间间隔期间，相同的访问单元(相同的时间实例)的所有视图的特定帧可以被同时渲染。在一个示例中，访问单元可以包括在一个时间实例中的编码图像，该编码图像可以被呈现为主编码图像。

相应地，接入单元可以包含公共时间实例的全部音频和视频帧，例如，对应于时间X的所有视图。本公开内容还将特定视图的编码图像称为“视图组件”。也即，视图组件可以包括特定时间处的针对特定视图的编码图像(或帧)。因此，访问单元可以被定义为包括公共时间实例的所有视图组件。访问单元的解码顺序不必与输出或显示顺序相同。

媒体呈现可以包括媒体呈现描述(MPD)，该MPD可以包含对不同的替代表示的描述(例如，具有不同质量的视频服务)，并且该描述可以包括例如编解码器信息、简档值以及等级值。MPD是清单文件的一个示例，诸如清单文件66。客户端设备40可以获取对媒体呈现的MPD以确定如何访问多种呈现的电影片段。电影片段可以位于视频文件的电影片段盒(moof盒)。

清单文件66(其可以包括例如MPD)可以广告表示68的段的可用性。也即，MPD可以包括用于指示挂钟时间(表示68中的一个表示的第一段在该挂钟时间处变得可用)的信息以及用于指示表示68内的段的持续时间的信息。以这种方式，客户机设备40的获取单元52可以基于在特定的段之前的段的持续时间以及开始时间来确定每个段何时可用。

在封装单元30已将NAL单元和/或访问单元组装成基于接收的数据的视频文件后，封装单元30将视频文件传递给输出接口32进行输出。在一些示例中，封装单元30可以将视频文件存储在本地或经由输出接口32将视频文件发送给远程服务器，而不是将视频文件直接发送给客户端设备40。输出接口32可以包括例如发射机、收发机、用于写数据到计算机可读介质的设备(诸如例如光驱)、磁介质驱动器(例如软驱)、通用串行总线(USB)端口、网络接口或其它输出接口。输出接口32输出视频文件给计算机可读介质34，诸如例如传输信号、磁介质、光学介质、闪存驱动器或其它计算机可读介质。

网络接口54可以经由网络74接收NAL单元或访问单元，并经由获取单元52提供NAL单元或访问单元给解封装单元50。解封装单元50可以将视频文件的元素解封装成组成的PES流，将PES流解分组化以获取经编码的数据，以及将经编码的数据发送给音频解码器46或视频解码器48，这取决于经编码的数据是音频流还是视频流的部分，例如，如通过该流的PES分组报头所指示地。音频解码器46解码经编码的音频数据并将经解码的音频数据发送给音频输出42，而视频解码器48解码经编码的视频数据并将可以包括流的多个视图的经解码的视频数据发送给视频输出44。

图2是具体地示出图1的获取单元52的示例组件集合的框图。在这个例子中，获取单元52包括eMBMS中间件单元100、DASH客户端110以及媒体应用112。

eMBMS中间件单元100还包括eMBMS接收单元106、高速缓存104和代理服务器102。在这个例子中，eMBMS接收单元106被配置为根据例如单向传输的文件递送(FLUTE)经由eMBMS接收数据，其中单向传输的文件递送(FLUTE)被描述在由T.Paila等人描述在RFC 6726的网络工作组在2012年11月提出的“FLUTE—单向传输的文件递送(File Delivery over Unidirectional Transport)”并可在获得于http://tools.ietf.org/html/rfc6726。也即，eMBMS接收单元106可以经由广播从例如可以用作BM-SC的服务器设备60接收文件。

当eMBMS中间件单元100接收文件的数据时，eMBMS中间件单元可以在高速缓存104中存储所接收的数据。高速缓存104可以包含计算机可读存储介质，诸如闪存、硬盘、RAM或任何其它合适的存储介质。

代理服务器102可以用作针对DASH客户端110的代理服务器。例如，代理服务器102可以向DASH客户端110提供MPD文件或其它清单文件。代理服务器102可以广告针对MPD文件中的段的可用时间以及可以从其获取这些段的超链接。这些超链接可以包括与客户端设备40对应的本地主机(localhost)地址前缀(例如，针对IPv4的127.0.0.1)。以此方式，DASH客户端110可以通过使用HTTP GET或部分GET请求来从代理服务器102请求段。例如，对于从链接http://127.0.0.1/rep1/seg3可用的段，DASH客户端110可以构建包括针对http://127.0.0.1/rep1/seg3的请求的HTTP GET请求，并提交该请求给代理服务器102。代理服务器102可以从高速缓存104中获取请求的数据，并响应于这些请求而提供该数据给DASH客户端110。

在接收到一段后，DASH客户端110可以将该段的数据传递给媒体应用112，而无论该段是完全还是部分接收的。DASH客户端110可以处理该段，例如以从该段提取媒体数据和/或以丢弃媒体应用112不可用的数据。

根据本公开内容的技术，如在下面更详细解释地，eMBMS中间件单元100可以接收一个或多个广告组并向DASH客户端110提供针对这些广告组中的一个广告组的数据。例如，DASH客户端110可以识别这些广告组中的一个广告组，或者可以向eMBMS中间件单元100提供针对用户的数据，使得eMBMS中间件单元100可以选择这些广告组中的一个广告组。

图3是示出示例多媒体内容120中的各元素的概念图。多媒体内容120可以对应于多媒体内容64(图1)或存储在存储介质62中的另一多媒体内容。在图3的示例中，多媒体内容120包括媒体呈现描述(MPD)124和多个表示130-140。表示130包括可选的报头数据132和段134A-134N(段134)，而表示140包括可选的报头数据142和段144A-144N(段144)。出于方便，字母N被用来指定在表示130、140中的每个表示中的最后电影片段。在一些示例中，在表示130、140之间可以有不同数量的电影片段。

MPD 124可以包括与表示130-140分开的数据结构。MPD 124可以对应于图1中的清单文件66。同样，表示130-140可以对应于图1中的表示68。一般来说，MPD 124可以包括对表示130-140的特性进行概括描述的数据，诸如编码和渲染特性、适配集合、MPD 124对应的简档、文本类型信息、相机角度信息、评级信息、特技模式信息(例如，对包括时间子序列的表示进行指示的信息)和/或用于获取远程时段的信息(例如，针对在回放期间到媒体内容中的定向广告插入)。

报头数据132当存在时可以描述段134的特性，例如随机接入点(RAP，也被称为流接入点(SAP))的时间位置，段134的特性包括随机接入点、对段134内的随机接入点的字节偏移、段134的统一资源定位器(URL)或段134的其它方面。报头数据142当存在时可以描述段144的类似特征。另外或者替代地，这样的特性可以完全包括在MPD 124内。

段134、144包括一个或多个经编码的视频样本，每一个经编码的视频样本可以包括视频数据的帧或片。段134的经编码的视频样本中的每个可以有类似的特性，例如，高度、宽度和带宽要求。这种特性可以通过MPD 124的数据来描述，尽管这样的数据未示出在图3的示例中。MPD 124可以包括由3GPP规范描述的特性，另外添加了与在本公开内容中描述的用信号发送的信息中的任何或所有信息。

段134、144中的每个可以与唯一的统一资源定位器(URL)相关联。因此，段134、144中的每个可以是通过使用诸如DASH的流式传送网络协议而可独立获取的。以此方式，诸如客户端设备40的目的地设备可以使用HTTP GET请求以获取段134或124。在一些例子中，客户端设备40可以使用HTTP部分GET请求以获取段134或124的特定的字节范围。

图4是示出可以实施本公开内容的技术的另一示例系统150的框图。图4中的系统150的元素可以通常对应于图1的元素。例如，系统150包括广告(ad)决策服务器154、内容分发系统180和客户端设备152。内容分发系统180的元素可以通常对应于图1的内容准备设备20和/或服务器设备60，而客户端设备152的元素可以对应于图1的客户端设备40。在一些示例中，客户端设备152的元素可以对应于图1的获取单元52。

在这个示例中，内容分发系统180包括MPD产生器156、打包器158和源服务器160。MPD产生器156产生针对主媒体内容的MPD 162(例如，针对用户想要观看的节目的媒体数据)以及针对广告的一个或多个MPD，如MPD 164。MPD 162描述了媒体内容166A-166C，而MPD 164描述了广告数据168A-168C。打包器158将媒体内容166A–166C和广告数据168A–168C进行组装。打包器158可以通常对应于封装单元30(图1)。

客户端设备152包括媒体应用170，其本身包括广告管理服务172。客户端设备152还包括用于获取主媒体内容的DASH客户端176和用于获取广告数据的DASH客户端174。应用170经由广告管理服务172从广告决策服务器154获取MPD URL，并提供MPD URL给DASH客户端176和DASH客户端174。DASH客户端174和DASH客户端176中的一方或者双方可以对应于图2的DASH客户端110。广告管理服务172可以根据本公开内容的技术来选择用于广告的MPD，如下面更详细地讨论。DASH客户端174可以使用用于广告的MPD以从源服务器160获取广告数据(例如，广告数据168A-168C中的一个或多个)。DASH客户端176可以从源服务器160获取主内容(例如，主内容166A-166C中的一个或多个)。

根据本公开内容的第一示例技术，特定于应用的事件可以被传递给应用170，该应用170与外部的广告决策服务器154交互以给DASH客户端174提供MPD URL，该MPD URL指向广告内容，例如，广告数据168A–168C。在广告内容被获得并被播出的同时，应用170暂停主节目。在广告插入后，应用170恢复主节目的播出。

广告管理服务172可以(单独地或以任何组合)采用用户简档/偏好(“UP/P”)信息、内容消费历史、广告推荐引擎等，以支持定向广告插入。通常的网络技术可以被用于此目的。另外或者替代地，诸如由IAB(互动广告局)定义的VMAP(视频多广告播放列表)也可以被使用。

在这个示例中，MBMS服务层(未示出)为DASH客户端174、176提供严格的递送功能。例如，MBMS服务层可以递送并提供被指定用于目标用户组或简档的广告内容数据，其中每个类别可以被映射到唯一的URL。MBMS客户端可以代表应用170下载并高速缓存针对DASH客户端176的选择性请求的所有广播广告。

应用170、DASH客户端174、176、MPD产生器156和打包器158可以以硬件或软件实现。当以软件实现时，假定诸如一个或多个处理单元和一个或多个计算机可读存储介质的必要硬件也被提供。计算机可读存储介质可以存储用于软件的指令，并且处理单元可以执行用以执行上述功能的指令。

图5是示出可以实施本公开内容的技术的另一示例系统200的框图。图5中的系统200的元素通常可以对应于对应于图1的元素。例如，系统200包括广告(ad)决策服务器208、内容分发系统212和客户端设备206。内容分发系统212的元素通常可以对应于图1的内容准备设备20和/或服务器设备60，而客户端设备206的元素可以对应于图1的客户端设备40。在一些示例中，客户端设备206的元素可以对应于图1的获取单元52。

在这个示例中，客户端设备206包括媒体引擎202和DASH访问客户端204。DASH访问客户端204可以对应于图2的DASH客户端110，而媒体引擎202可以对应于图2的媒体应用112。内容分发系统212包括MPD生成器214、打包器216和内容分发网络(CDN)/源服务器218。源服务器218存储MPD 220、主内容222A-222C和广告数据224A–224C。

图5的示例表示本公开内容的第二示例技术集的可能实现方案。在这个第二示例技术集中，基本概念是DASH访问客户端204，而HTTP协议栈是“负责”用于获得适当的广告。在MPD 220中描述的远程时段可以通过Period@xlink:href的恰当格式化来引用广告内容(例如，广告数据224A–224C)，该广告内容可以被定向到特定的用户组/简档。因此，当DASH访问客户端204将XLink(也即，XML链接语言数据)指向XLink解析器210时，XLink解析器210获取对来自广告决策服务器208的适当的远程时段进行描述的数据。CDN/源服务器218可以提前发送包含远程时段的MPD 220，如果广告插播时间在当MPD产生器214产生MPD 220时的时间处得知的话。替代地，CDN/源服务器218可以通过使用特定于DASH的事件动态地发送远程时段数据以触发DASH访问客户端204获得对MPD 220的更新。

用于选择广告的技术可以类似于上面参照图4描述的那些技术。例如，UP/P信息、内容消费历史、广告推荐引擎等可以被用以支持定向广告插入。

如上所述，第二示例包括技术集。也就是说，(单独使用的或以任何组合使用的)多种选择方案是可行的。在第一选择方案中，MBMS服务层(未示出)执行非选择性广告接收。MBMS服务层可以递送并提供被指定用于目标用户组或简档的广告内容，其中每个类别可以被映射到唯一的URL。MBMS客户端可以下载并高速缓存针对DASH访问客户端204和/或媒体引擎202的选择性请求的所有广播广告。

在第二选择方案中，MBMS服务层执行选择性广告接收。广播多播业务中心(BM-SC)可以将元数据附加到每个广告(如广告数据224A–224C)，并且DASH访问客户端204可以向MBMS客户端通告广告数据的优先类别以进行选择性下载和高速缓存，使得MBMS客户端选择性地下载并高速缓存广播广告(例如，广告数据224A–224C中的一个)。

媒体引擎202、DASH访问客户端204、MPD产生器214以及打包器216可以以硬件或软件实现。当以软件实现时，假定诸如一个或多个处理单元和一个或多个计算机可读存储介质的必要硬件也被提供。计算机可读存储介质可以存储用于软件的指令，并且处理单元可以执行用以执行上述功能的指令。

图6A-8B是示出多种示例方法的序列图，其中，DASH客户端(例如，DASH访问客户端204)确保对适当的广告内容的接收。图6A-8B的多种方法与参照图5在上描述的本公开内容的第二示例技术集是一致的。

在图6A-8B中，多种元素被描述为执行多种任务。这些元素包括应用(例如，媒体引擎202)、DASH客户端(例如，DASH访问客户端204)、MBMS客户(其可以包括本地HTTP代理和XLink解析器210)、BM-SC(如CDN/源服务器218)、广告决策服务器(例如，广告决策服务器208)、内容提供方(例如，其包括MPD产生器214和打包器216)和广告提供方(未示出在图5中)。

图6A和6B示出了根据针对本公开内容的第二示例技术集在上面描述的第一选择方案的方法的示例。此外，图6A和6B的示例对应于这样的情况：在该情况中，广告插播开始时间在MPD被产生(例如，用于现场事件)时是未知的。图6A和6B示出由包括如下各项的多种元素执行的动作：应用(例如，图2的媒体应用112)、DASH客户端(例如，图2的DASH客户端110)、MBMS客户端(例如，图2的eMBMS中间件单元100)、BM-SC、广告决策服务器、内容提供方和广告提供方。

在图6A和6B的示例中，假定DASH客户端知道本地groupID等于“B”。还假定MBMS运营方、内容提供方和广告提供方之间有对于内容/广告设定和MPD格式的业务协定。在图6A和6B的示例中，起初，BM-SC用MPD片段将USD递送给MBMS客户端，该MBMS客户端将该MPD转发给DASH客户端。BM-SC随后可以经由广播递送与具有例如1)http://adserver.com/ad1？id＝“A”、2)http://adserver.com/ad1？id＝“B”、3)http://adserver.com/ad1？id＝“C”的BaseURL的远程时段元素对应的三个文件，每个文件的时段开始时间在将来的时间T1。MBMS客户端下载并高速缓存所有远程时段元素。

在未来某一时间处，作为接收来自广告提供方的提示消息(这指示即将发生的广告插入)的结果，BM-SC用信号发送特定于DASH的事件(例如，经由MPD事件或带内事件消息)以触发获得更新的MPD，MBMS客户端接收和转发该更新的MPD给DASH客户端。随后，BM-SC广播更新的MPD、USBD和调度片段，其中USBD包含deliveryMethod(递送方法)，该deliveryMethod引用FLUTE会话，该FLUTE会话在远程时段中携带广告内容，而调度声明即将到来的广告传输。作为响应，DASH客户端取得更新的MPD(其中，在这个示例中，MPD指示Period@xlink:href＝http://adserver.com/ad1？id＝$groupID$且@xlink:actuate＝“onRequest”的远程时段。在这种情形下，虽然DASH客户端不立即尝试解引用针对远程时段的链接，而是推迟这样的解引用动作直到相关联的内容的播放时间被预期进入该时段为止。

BM-SC随后广播由远程时段元素引用的广告内容文件，其中每个广告由定向groupID标记(例如，作为文件递送表(FDT)'文件'元素扩展属性”$groupID$”，例如，如在下面参照图13A和13B所讨论地)。另外或者替代地，如下面所讨论地，过滤器描述片段的groupIDFilter可以识别广告数据。在这个示例中，MBMS客户端下载和高速缓存所有的广告。随着时间T1接近，DASH客户端通过发出针对在@xlink:href中出现的URL的HTTP请求来请求解引用远程时段元素，并向MBMS客户端提供本地groupID值“B”。作为响应，MBMS客户端记录groupID＝“B”用于应要求的适当的广告递送，并将与BaseURL＝“http://adserver.com/ad1？id＝“B””相关联的时段递送给DASH客户端。随后，DASH客户端向应用提供了此广告的段。该过程一直持续到广告数据已完全播放为止，随后主内容的普通广播可以恢复。

图7A和7B示出了在其中广告可用性(ad avail)时间在当MPD被产生(例如，用于现场事件)时的时间处未知的示例。图7A和7B的示例对应于如上所述的选择方案二，其中，由MBMS客户端进行选择性的广告接收。在这个示例中，广播广告递送正好发生在ad avail时间前。图7A和7B示出由多种元素执行的动作，该多种元素包括应用(例如，图2的媒体应用112)、DASH客户端(例如，图2的DASH客户端110)、MBMS客户端(例如，图2的eMBMS中间件单元100)、BM-SC、广告决策服务器、内容提供方和广告提供方。

在图7A和7B的示例中，假定状态信息(诸如cookies、订阅信息、使用历史等)位于用户装置(UE)上，并且可由DASH客户端在HTTP请求中递送给网络的设备。同样，在这个示例中，假定MBMS运营方、内容提供方和广告提供方之间有对于内容/广告设定和MPD的格式的业务协定。

起初，BM-SC用MPD片段将USD递送给MBMS客户端，并且该MBMS客户端将该MPD转发给DASH客户端。BM-SC随后可以经由广播递送与具有例如1)http://adserver.com/ad1？id＝“A”、2)http://adserver.com/ad1？id＝“B”、3)http://adserver.com/ad1？id＝“C”的BaseURL的远程时段元素对应的三个文件，每个文件的时段开始时间在将来的时间T1。MBMS客户端下载并高速缓存所有远程时段元素。MBMS客户端下载和缓存所有远程周期元素。在未来某一时间处，作为接收来自广告提供方的提示消息(这指示即将发生的广告插入)的结果，BM-SC用信号发送特定于DASH的事件(例如，经由MPD事件或带内事件消息)以触发获得更新的MPD，MBMS客户端接收和转发该更新的MPD给DASH客户端。随后，BM-SC广播更新的MPD、USBD和调度片段，其中USBD包含deliveryMethod(递送方法)，该deliveryMethod引用FLUTE会话，该FLUTE会话在远程时段中携带广告内容，而调度声明即将到来的广告传输。

作为响应，DASH客户端取得更新的MPD(其中，在这个示例中，MPD指示Period@xlink:href＝http://adserver.com/ad1？id＝$groupID$and@xlink:actuate＝“onRequest”的远程时段。在这种情形下，DASH客户端一加载MPD就将立即解引用针对远程时段的链接，并且将传递如上所述的UE状态信息给用作Xlink解析器的MBMS客户端。MBMS客户端随后将状态信息映射到用于后续定向广告下载的一个广告组。在这个示例中，假定MBMS客户端将状态信息映射到groupID＝“B”。

DASH客户端随后通过发出针对在@xlink:href中出现的URL的HTTP GET来请求解引用远程时段元素。在这个示例中，MBMS客户端通过递送与BaseURL＝“http://adserver.com/ad1？id＝“B””相关联的时段元素来作出响应。BM-SC随后广播由远程时段元素引用的广告内容文件，其中每个广告由定向groupID标记(例如，作为FDT扩展属性，诸如在下面参照图13A和13B所讨论的)。另外或者替代地，如下面所讨论地，过滤器描述片段的groupIDFilter可以识别广告数据。

在这个示例中，MBMS随后可以选择性地下载和高速缓存具有groupID＝“B”的广告。随着时间T1接近，DASH客户端通过发出针对在@xlink:href中出现的URL的HTTP请求来请求解引用远程时段元素，并向MBMS客户端提供本地groupID值“B”。作为响应，MBMS客户端记录groupID＝“B”用于应要求的适当的广告递送，并将与BaseURL＝“http://adserver.com/ad1？id＝“B””相关联的时段递送给DASH客户端。随后，DASH客户端向应用提供了此广告的段。该过程一直持续到广告数据被全部播放为止，并且随后主内容的普通广播可以恢复。

图8A和8B示出了在其中广告可用性(ad avail)时间在当MPD被产生(例如，用于现场事件)时的时间处未知的示例。图7A和7B的示例对应于如上所述的选择方案二，其中，广告刚好被广播在由MBMS客户端进行选择性的广告接收前。在图8A和8B的这个示例中，广播广告递送正好发生在ad avail时间前，并被选择性地高速缓存直到到了广告播放的时间为止。图8A和8B示出由多种元素执行的动作，该多种元素包括应用(例如，图2的媒体应用112)、DASH客户端(例如，图2的DASH客户端110)、MBMS客户端(例如，图2的eMBMS中间件单元100)、BM-SC、广告决策服务器、内容提供方和广告提供方。

在图8A和8B的示例中，假定状态信息(诸如cookies、订阅信息、使用历史等)位于用户装置(UE)上。相比图7A和7B的示例而言，DASH客户端在针对DASH内容的初始HTTP请求期间将状态信息传递给MBMS客户端。与图7A和7B的示例类似地，假定MBMS运营方、内容提供方和广告提供方之间有对于内容/广告设定和MPD的格式的业务协定。

因此，在这个示例中，MBMS客户端可以一早将客户端设备(UE)的状态信息映射到groupID(例如groupID＝“B”)，用于后续的定向广告下载。BM-SC随后可以根据在USD片段中递送的调度来广播广告内容文件，USD片段可以刚好发生在初始的ad avail成为可能前。广告内容由远程时段元素引用，每个广告由目标groupID标记(例如，作为FDT扩展属性，诸如在下面参照图13A和13B所讨论的)。另外或者替代地，如下面所讨论地，过滤器描述片段的groupIDFilter可以识别广告数据。在这个示例中，MBMS客户端随后选择性下载和缓存广告groupID＝“B”。

接下来，BM-SC用MPD片段将USD递送给MBMS客户端，并且该MBMS客户端将该MPD转发给DASH客户端。BM-SC随后可以经由广播递送与具有例如1)http://adserver.com/ad1？id＝“A”、2)http://adserver.com/ad1？id＝“B”、3)http://adserver.com/ad1？id＝“C”的BaseURL的远程时段元素对应的三个文件，每个文件的时段开始时间在将来的时间T1。MBMS客户端下载并高速缓存所有远程时段元素。由于MBMS客户端已确定与用户相关联的groupID值(在这个示例中，groupID＝“B”)，所以其可以下载并高速缓存Base URL http://adserver.com/ad1？id＝”B”相关联的远程时段元素。在未来某一时间处，作为接收来自广告提供方的提示消息(这指示即将发生的广告插入)的结果，BM-SC用信号发送特定于DASH的事件(例如，经由MPD事件或带内事件消息)以触发获得更新的MPD，MBMS客户端接收和转发该更新的MPD给DASH客户端。随后，BM-SC广播MBMS客户端接收的更新的MPD片段。

DASH客户端取得更新的MPD(其中，MPD指示Period@xlink:href＝http://adserver.com/ad1？id＝B和@xlink:actuate＝“onLoad的远程时段。在这种情况下，DASH客户端将解引用针对远程时段的链路。同样，在这个示例中，DASH客户端不需要替代XLink URL中的参数的值，这是因为MPD本身指定针对广告组的指示(在这个示例中为B)。在这个示例中，MBMS客户端通过递送与BaseURL＝“http://adserver.com/ad1？id＝“B””相关联的时段元素做出响应。也即，在这个示例中，MBMS客户端将仅具有与广告组“B”相关联的经高速缓存的数据，如上面所讨论地。

随着时间T1接近，DASH客户端从MBMS客户端请求并接收与先前接收的时段元素有关联的内容(即，定向广告)的第一段。随后，该DASH客户端将该广告的此段的媒体内容提供给应用。这个过程一直持续到广告数据被完全播放为止，并在随后主内容的普通广播可以恢复。

图6A-8B表示根据本公开内容的技术的仅部分可能示例。针对基于服务器的方法的其它呼叫流变体也是可能的。例如，在广播广告投放正好发生广告可用性前的情况下，在MPD更新中携带的Period@xlink:actuate的值可以被设为“onRequest”(而不是“onLoad”)。因为定向广告已被选择性地下载并被高速缓存在UE上，所以没有为解析xLink的时间紧迫性，只要其出现在ad avail前。如果处于某些原因，在ad avail出现时没有定向广告可用在设备上，那么默认的预存储的广告可以被播出在其位置中。

还存在不同的可行机制，通过该不同的可行机制，MBMS客户端根据由DASH客户端提供的UE状态信息导出是恰当的“groupID”。作为一个例子，可以访问UE驻留的使能器，诸如本地UP/P数据库、内容推荐引擎或使用本地存储的使用历史记录执行推理。作为另一个例子，可以访问网络侧的使能器，例如外部UP/P数据库或内容推荐引擎。

本公开内容的技术的第三示例是参照图9-11B来描述的，其中第三示例涉及MBMS客户端辅助广告选择。第三个示例的基本概念在于MBMS客户端基于在USD中包含的元数据和/或过滤规则来选择性地下载并高速缓存广播广告。该过滤器描述片段可以被扩展到以携带过滤数据。这个示例假定使能器的诸如UP/P信息、内容消费历史等的可用性到MBMS客户端。例如，使能器可以包括MBMS客户端可访问的设备驻留的UP/P信息。虽然特定的UP/P数据和交互没有被描述，但可以由那些熟练的艺术确定。

此外，MBMS服务层提供广告过滤/选择功能。广播广告被假设被递送在节目(例如，DASH媒体呈现)之前，以供MBMS客户端选择性下载和高速缓存。MBMS客户端的广告选择机制可以是特定的实现方案。

图9是示出如当前定义的示例过滤器描述片段以携带位置滤波数据的概念图。图10是示出过滤器描述片段的扩展以携带用户偏好&简档(UP/P)的概念图。在图10的示例中，userPrefProfData元素包含属性-值对(例如，用户的人口统计资料、内容类别、评级、人气等)用于广告选择。userPrefProfRule元素包含过滤规则(特定的条件和逻辑)用于广告选择。

图11A和11B是示出根据本公开内容的技术用于MBMS客户端协助的广告选择的示例方法的序列图。在这个示例中，广告插播开始时间在MPD被产生的时间处得知。图11A和11B的活动单元基本上类似于图6A-8B中的那些。图11A和11B示出了由包括如下的多种元素执行的操作：应用(例如，图2的媒体应用112)、DASH客户端(例如，图2的DASH客户端110)、MBMS客户端(例如，图2的eMBMS中间件单元100)、BM-SC、广告决策服务器、内容提供方和广告提供方。

在图11A和11B的示例中，假定MBMS客户端具有对UP/P数据的访问，并且在MBMS运营方、内容提供方和广告提供方之间对于内容/广告设定和MPD格式有业务协定。起初，BM-SC提供USD，USD包括MPD和例如根据图10的示例的过滤器描述。应用发送MPD URL给DASH客户端，DASH客户端随后从URL取得MPD。MPD被假设包括针对常规内容的时段_1、具有到广告内容的XLink的远程时段_2(属性xlink:actuate＝"onRequest")和具有更多的常规内容的时段_3。也就是说，在这个示例中，时段_2表示预定的广告插播。内容提供方提供常规(或主)内容给BM-SC，而广告提供方提供广告内容给BM-SC。

BM-SC广播广告(对应于由时段_2中的XLink引用的内容)给MBMS客户端。MBMS客户端根据例如过滤器描述的UP/P数据或规则来选择性地下载并高速缓存广告。BM-SC随后广播时段_1的段给MBMS客户端。随着时段_2的开始接近，DASH客户端通过发出针对在@xlink:href中出现的URL的HTTP请求来请求解引用远程时段元素(其在这个例子中对应于时段_2)。随后，MBMS客户端递送由@xlink:href引用的时段元素(对应于时段_2)。DASH客户端取得时段_1的段(例如，段URL的为：“http://example.com/per-1/rep-512/seg-i.3gp”,其中i∈{1,99})。

随后，DASH客户端发送时段_1的段(节目内容)给应用。DASH客户端还从MBMS客户端请求(由xLink引用的)时段_2的段。MBMS客户端通过使用例如HTTP 303响应将DASH客户端重定向到本地主机地址，以便从本地高速缓存中取得时段_2的段。随后，DASH客户端取得经高速缓存的广告内容的时段_2的段(例如，段URL的为：“http://localhost.com/per-2/rep-512/seg-j.3gp”,其中j∈{100,129})。

随后，DASH客户端发送时段_2的段(广告内容)给应用。BM-SC还广播时段_3的段给MBMS客户端。DASH客户端还从MBMS客户端请求时段_3的段(例如，段URL的为：“http://example.com/per-3/rep-512/seg-k.3gp”,其中k∈{130,200})。随后，DASH客户端发送时段_3的段(节目内容)给应用。

图12是示出根据本公开内容的技术用于针对实时传输协议(RTP)的MBMS客户端协助的广告选择与插入的示例方法的序列图。在这个示例中，用户简档是对MBMS客户端已知的。当广告被发送时，FDT可以包括针对广告的元数据。基于用户简档和过滤器描述，MBMS客户端可以选择性地下载和高速缓存广告。可选地，客户端设备(UE)可以决定是否插入广告在由简档数据指定的位置区域内。图12示出了由多种元素执行的操作，包括应用(例如，图2的媒体应用112)、DASH客户端(例如，图2的DASH客户端110)、MBMS客户端(例如，图2的eMBMS中间件单元100)、BM-SC、广告决策服务器、内容提供方和广告提供方。

在图12的示例中，假定MBMS客户端具有对UP/P数据的访问，并且在MBMS运营方、内容提供方和广告提供方之间对于内容/广告设定有业务协定。起初，BM-SC提供USD，USD包括例如根据图10的示例的过滤器描述。应用发送URL给DASH客户端，DASH客户端随后根据RTP执行建立和播放。内容提供方提供常规(或主)内容给BM-SC，而广告提供方提供广告内容给BM-SC。

随后，BM-SC开始广告(具有元数据)的广播。MBMS客户端根据过滤器描述中的UP/P和规则来选择性地下载和高速缓存广告。BM-SC采用RTP发送视频和音频数据。MBMS客户端随后判断客户端设备(UE)是否在所需的位置内以逐简档数据插入广告。假设客户端设备在这样的位置中，MBMS客户端逐元数据向广告插入RTP视频和音频分组。MBMS客户端随后逐元数据删除到期的广告。

图13A到13D是示出对文件传送表(FDT)文件元素的示例扩展的概念图。在这个示例中，文件元素被扩展成包括组属性，组属性可以对应于如上所讨论的groupID值。特别而言，在这个示例中，文件元素250已被扩展成包括组属性252，其被命名为“mbms2014:groupID”具有类型xs:string。

应当明白，在一些示例中，客户端设备可以被配置为执行上面描述的第一示例、第二示例和第三示例的任何或全部技术。例如，不同的内容分发网络可以支持针对定向广告插入的不同机制，而客户端设备可以实现第一示例、第二示例和/或第三示例的任何或所有技术。作为另一个例子，内容分发网络可以支持上面描述的第一示例、第二示例和/或第三示例的任何或所有技术。此外，上面描述的第一示例、第二示例和/或第三示例的技术可以以任何组合一起执行。

在图13A到13D中示出的“groupID”的FDT扩展参数只是一例。其它技术可以根据本公开内容的技术来使用。例如，除了或者替代使用FDT扩展参数(“groupID”)作为针对相关联的广告文件的元数据以使MBMS客户端能够过滤针对用户的仅专门合适的广告，另一种可能性是要扩展现有的USD。例如，新的元素“groupIDFilter”可以被添加到过滤器描述片段(其中，过滤器描述片段由调度描述片段中的文件调度实例引用；文件调度提供针对广告文件的传输调度)。

图14是示出可以执行本公开内容的技术的另一示例系统300的框图。系统300的组件包括参与发起、调度以及递送DASH格式化的媒体内容和定向广告经由BM-SC从内容提供方和广告源给用户装置(UE)的功能实体。在这个示例中，系统300包括客户端设备302、内容提供方314、广告决策服务器316、广告提供方318以及广播多播服务中心(BM-SC)320。客户端设备302包括媒体引擎304、DASH客户端306和MBMS客户端308。客户端设备302表示UE的示例。MBMS客户端308还包括XLink解析器310和HTTP代理高速缓存312。BM-SC 320包括USBD 322、MPD 324、内容326A–326C(内容326)以及广告(ads)328A–328C(ads 328)。

通常，内容提供方314提供内容326给BM-SC 320。广告决策服务器316用信号通告广告何时将被插入(使用广告插入提示)并设定针对广告的远程时段。广告提供方318提供广告328给BM-SC 320。广告328A–328C中的每个可以对应于不同组的用户，以便将广告定向到用户，如上面所讨论地。

MBMS客户端308订阅广播或多播组以便从一个或多个内容326接收数据。此外，如在下参照图15A和15B详细解释地，MBMS客户端308可以选择性地接收将被插入到广告插播中的广告328A–328C中的一个。MBMS客户端308在HTTP代理缓存的内容和广告数据312。以此方式，DASH客户端306可以通过提交HTTP请求给MBMS客户端308来获取媒体数据(例如，主内容数据和广告数据)，MBMS客户端308既而将MPD数据和段发送给DASH客户端306。为了选择合适的广告数据，DASH客户端306可以发送XLink给MBMS用户308。XLink解析器310可以解析XLink，以便确定要接收的广告数据。

在图14的示例建筑中，广告相关的信息可以使用MPD 324和内容326的段来声明，并广告决策可以由DASH客户端306的针对MPD和其描述的资源(即，远程时段元素和段)的请求来发起。如果广告插播的发生时间是在MPD产生的时间处得知，那么包含远程时段元素的MPD可以在广告插播前被发送给DASH客户端。否则，可能需要依靠MPD更新功能(例如，基于具有由MPD@minimumUpdatePeriod定义的周期性的同步MPD更新)，以用信号发送针对定向广告插入的即将到来的机会。不可预测的广告插播的工作场景将在下面的讨论中采用。

虽然用于获得最新的MPD的DASH客户端306与MPD服务器之间的标称相互作用(其中，后者被假定位于UE(即，客户端设备302)中以及p/o MBMS客户端308，p/o MBMS客户端308包括本地HTTP代理和高速缓存312)是周期性的，但是广告插播的发生可能是纯异步的，例如，发生在一场足球比赛伤停期间。取决于广告插播的预期建立时间-从触发广告插播的事件开始到广告插入的实际接合时间，MPD@minimumUpdatePeriod值可以被相应调整，使得这种动态事件将不会被DASH客户端306错过。极可能经由条件GET的针对MPD更新的HTTP交互可以在本地发生在UE内，使得没有单播网络业务发生，并且多数时候，DASH客户端306先前获得的MPD仍然有效。当被更新时，MPD可以经由Period@xlink:href携带指向外部时段元素的指针。

作为与MBMS客户端308的HTTP交互的部分，DASH客户端306可以将关于UE/本地用户的状态信息传递给MBMS客户端308。这样的状态信息的示例包括cookies、订阅信息和内容消费历史数据。状态信息可以在针对MPD或媒体段的标称请求/响应期间或者在Xlink解析过程期间被提供给MBMS用户308。MBMS客户端308可以利用TS 26.346的范围(例如，对本地用户简档/偏好信息的访问、内容消费历史或内容推荐引擎)外的一些机制，以确定针对该用户的特定的组或简档标识符。这种“groupID”可以用作针对该用户的合适的或优选的广告内容的指示符。当广告内容被广播(其中多种广告文件被定向到不同的用户)时，MBMS客户端使用groupID作为过滤器以下载和高速缓存将稍后应请求而被提供给DASH客户端的一个或多个特定的广告。对广告的广播递送可能正发生广告插播前(例如，在第二天的足球比赛前的前一晚)或发生在接近实际的广告插播之前的时间。

只要MBMS客户端308已获得本地状态信息并映射该数据到用户的groupID值，MBMS客户端308便能对广告进行选择性下载和高速缓存。不同的方式能用以将groupID作为针对相关联的广告的元数据来传达，以使得MBMS客户端能够进行选择性的广告接收。例如，FLUTE FDT扩展属性groupID可以被指定用于由TOI和内容-位置标识的广告文件。也可通过在filterData元素下添加新的子元素groupIDfilter作为针对对应的广告文件的标识符，来扩展现有的过滤器描述片段，其中该对应的广告文件的递送调度是由文件调度的实例宣布的。

在对XLink的解析中，MBMS客户端308可以返回(例如，通过groupID)定制的远程时段元素给用户。该时段元素包含对针对该时段的期间的广告内容的引用，包括段URL信息。随后，在广告中断的适当时间段中，DASH客户端306可以使用该信息在广告插播的恰当时间处取得针对广告内容的段。因为对应的广告内容已被下载并被MBMS客户端308高速缓存(被高速缓存在HTTP代理高速缓存312内)，它可以被返回给DASH客户端306、既而到媒体播放器/应用(例如，媒体引擎304)用于在广告插播期间进行渲染。

图15A和15B是示出根据本公开内容的技术的示例方法的序列图。图15A和15B的方法可以由图14的系统300的组件来执行，尽管其它系统也可以使用这种方法。假定MBMS运营方、内容提供方314和广告提供方318之间有关于内容和广告设定以及MPD 324的格式的业务协定。图15A和15B示出由包括如下各项的多种元素执行的动作：应用(例如，图2的媒体应用112或图14的媒体引擎304)、DASH客户端(例如，图2的DASH客户端110或图14的DASH客户端306)、MBMS客户端(例如，图2的eMBMS中间件单元100或者图14的MBMS客户端308)、BM-SC(例如，图14的BM-SC320)、广告决策服务器(例如，图14的广告决策服务器316)、内容提供方(例如，图14的内容提供方314)和广告提供方(例如，图14的广告提供方318)。

起初，BM-SC 320可以广播对USD(包括MPD片段)的递送到MBMS客户端308。媒体应用(例如，媒体引擎304)可以请求发送MPD URL到DASH客户端306，DASH客户端306既而可以从MBMS客户端308(其可以在HTTP代理高速缓存312中高速缓存MPD)获得MPD(例如，MPD 324)。DASH客户端306也可以传递状态信息给MBMS客户端308，MBMS客户端308可以指示要被获得用于客户端设备302的用户的广告数据集合(例如，广告组)。DASH客户端306可以根据MPD@minimumUpdatePeriod轮询MPD更新，其可以在原MPD中用信号来发送。在这个示例中，MBMS客户端308随后将状态信息映射到组标识符，例如，groupID＝“B”，用于后续的定向广告下载。

对于主内容，可以有普通的广播递送以及基于MBMS的DASH(DASH-over-MBMS)媒体呈现的消耗。接着，广告提供方318可以提供广告给BM-SC 320。BM-SC 320可以根据在USD片段中递送的调度来广播广告内容文件，如上面所讨论地。广告内容(例如，广告328)可以通过远程时段元素被引用，每个广告由定向groupID标记。基于在上讨论的映射，MBMS客户端308可以选择性地下载和(在HTTP代理高速缓存312中)高速缓存用groupID＝“B”标记的广告。

广告决策服务器316可以向BM-SC 320提供与具有例如1)http://adserver.com/ad1？id＝“A”、2)http://adserver.com/ad1？id＝“B”、3)http://adserver.com/ad1？id＝“C”的BaseURL的远程时段元素对应的三个文件，每个文件的时段开始时间在将来的时间T1。BM-SC 320随后可以播放这些三个远程时段元素文件。MBMS客户端308可以基于上面讨论的映射，下载并高速缓存只与BaseURL http://adserver.com/ad1？id＝”B”相关联的远程时段元素。BM-SC 320还可以带内递送针对媒体呈现的更新的MPD。

根据MPD最小更新时段，DASH客户端306可以从MBMS客户端308请求更新的MPD。该更新的MPD可以用Period@xlink:href＝“http://adserver.com/ad1？id＝”B”以及@xlink:actuate＝“onLoad”用信号发送远程时段。DASH客户端306可以通过针对在@xlink:href中出现的URL的HTTP GET请求来进一步请求解引用远程时段元素。MBMS客户端308可以递送与BaseURL＝“http://adserver.com/ad1？id＝“B”相关联的时段元素。随着时间T1接近，DASH客户端306可以从MBMS客户端308(其已在HTTP代理高速缓存312中高速缓存了段)取得由远程时段元素描述的广告内容的段，并随后提供这些段给媒体应用(例如，媒体引擎304)。

以这种方式，图15A和15B表示了一种方法的示例，包括，通过DASH客户端：确定与多个广告组的广告媒体数据相关联的广告组标识符集合，其中，所述广告媒体数据将被播放在针对主媒体内容的广告插播期间，至少部分地基于所述DASH客户端的用户的特性，从所述集合中选择所述广告组中的一个广告组，获取所选择的广告组的广告媒体数据，以及提供所述广告媒体数据给媒体应用。

同样，图15A和15B表示了一种方法的示例，包括，通过MBMS中间件单元：接收一个或多个广告组的广告媒体数据，从所述客户端设备的基于HTTP的动态自适应流式传送(DASH)客户端接收针对所述广告组中的一个广告组的标识符值，提取与所述标识符值对应的该个广告组的所述广告媒体数据，以及提供所提取的广告媒体数据给所述DASH客户端。

在一个或多个示例中，所描述的功能可以以硬件、软件、固件或其任何组合实现。如果以软件实现，所述功能可以被存储或被传输作为计算机可读介质上的一个或多个指令或代码并由基于硬件的处理单元执行。计算机可读介质可以包括计算机可读存储介质，计算机可读存储介质对应于有形媒介，诸如数据存储媒体或通信媒体，其包括例如根据通信协议便于计算机程序从一个地方到另一个转移的任何介质。在这种方式下，计算机可读介质通常可对应于(1)有形的计算机可读存储介质，其是非暂时性或(2)诸如信号或载波的通信介质。数据存储媒体可以是可以由一个或多个计算机或一个或多个处理器访问以获取指令、代码和/或数据结构用于实现在本公开内容中描述的技术的任何可用媒体。计算机程序产品可以包括计算机可读介质。

通过举例的方式，而不是限制，这样的计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储装置、闪存或可以被用以以指令或数据结构的形式存储所需的程序代码并可以由计算机访问的任何其它介质。另外，任何连接被适当称为计算机可读介质。例如，如果指令是从网站、服务器或其它远程源使用同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或无线技术(如红外、无线电、微波)发送的，那么同轴电缆、光纤电缆、双绞线、DSL和无线技术(如红外、无线电、微波)都包含在介质的定义中。然而应当明白，虽然计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它暂时性媒体，但是针对非暂时性的有形的存储介质。在本文所使用的磁盘和光盘包括光盘(CD)、激光光盘、光盘、数字多功能光盘(光盘)、软盘和Blu-ray光盘，其中，磁盘通常用磁性地重生数据，而光盘用激光光学地重生数据。上述的组合也应包含在计算机可读介质范围内。

指令可以由一个或多个处理器执行，所述一个或多个处理器诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其它等效集成或分立逻辑电路。因此，本文所使用的术语“处理器”可以指适用于实现本文所描述的技术的任何上述结构或任何其它结构。此外，在某些方面，在本文所述的功能可以在被配置用于编码和解码的专用硬件和/或软件模块中提供，或在组合的编解码器中合并。此外，这些技术可以完全实现在一个或多个电路或逻辑元件中。

本公开内容的技术可以实现于各种各样的设备或装置，包括无线手机、集成电路(IC)或IC集合(例如，芯片组)。虽然在本公开内容中描述的多种组件、模块或单元强调被配置以执行所公开的技术的设备的功能方面，但不一定需要通过不同的硬件单元实现。而是，如上所述，多个单元可以被结合在编解码器硬件单元中或由互操作的硬件单元的集合提供，该互操作的硬件单元的集合包括如上所述的一个或多个处理器结合合适的软件和/或硬件。

多个示例已被描述。这些和其它示例都在下面的权利要求书的保护范围内。