CN105284093B - 用于取回媒体数据的方法和设备 - Google Patents

用于取回媒体数据的方法和设备 Download PDF

Info

Publication number
CN105284093B
CN105284093B CN201480004712.9A CN201480004712A CN105284093B CN 105284093 B CN105284093 B CN 105284093B CN 201480004712 A CN201480004712 A CN 201480004712A CN 105284093 B CN105284093 B CN 105284093B
Authority
CN
China
Prior art keywords
media data
request
client
map information
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201480004712.9A
Other languages
English (en)
Other versions
CN105284093A (zh
Inventor
K·R·福尔
N·奈克
T·施托克哈默
F·乌卢皮纳尔
C·M·D·帕索斯
C·N·洛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN105284093A publication Critical patent/CN105284093A/zh
Application granted granted Critical
Publication of CN105284093B publication Critical patent/CN105284093B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/91—Television signal processing therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

代理单元被配置为获取映射信息，所述映射信息基于用于取回媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。

Description

用于取回媒体数据的方法和设备
本申请要求于2013年1月15日递交的美国临时申请序列 No.61/752,456的权益以及于2013年4月8日递交的美国临时申请序列 No.61/809,871的权益。
技术领域
本公开内容涉及通信系统，并且更具体地说，涉及经由网络的内容传递。
背景技术
可以将数字多媒体(包括音频和视频以及其他媒体)能力并入到很多设备中，所述设备包括数字电视、数字直播系统、无线广播系统、个人数字助理(PDA)、膝上型或桌上型计算机、数码相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频会议设备等。数字多媒体设备实现例如在由MPEG-2、MPEG-4、ITU-TH.263或ITU-T H.264/MPEG-4第10部分、高级视频编码(AVC)定义的标准以及这些标准的扩展中描述的视频、音频和/或其他媒体压缩技术，以更有效地发射和接收数字多媒体信息。
多媒体压缩技术执行空间预测和/或时间预测以减少或移除视频序列中固有的冗余。对于基于块的视频编码，可以将视频帧或片段(slice)划分成块。每个块可以被进一步划分。在帧内编码的(I)帧或片段中的块相对于相邻块使用空间预测来编码。在帧间编码的(P或B)帧或片段中的块可以相对于同一帧或片段中的相邻块使用空间预测或相对于其它参考帧使用时间预测。
在多媒体数据已经被编码(例如，压缩)之后，可以将数据分组以进行传输或存储。可以将数据组装成符合各种标准中的任何标准的文件，所述标准例如国际标准化组织(ISO)基础媒体文件格式和其扩展，如AVC。
为了提供诸如语音、视频、分组数据、消息传递、广播等各种通信服务，广泛地部署了无线通信网络。这些无线网络可以是能够通过共享可用的网络资源来支持多个用户的多址网络。这种多址网络的例子包括码分多址(CDMA)网络、时分多址(TDMA)网络、频分多址(FDMA)网络、正交FDMA(OFDMA)网络以及单载波FDMA(SC-FDMA)网络。
作为全球系统移动通信(GSM)和通用移动电信系统(UMTS)的演进，第三代合作伙伴计划(3GPP)长期演进(LTE)表示蜂窝技术中的重大进展。LTE物理层(PHY)提供了在诸如演进节点B(eNB)的基站和诸如UE的移动设备之间来传递数据和控制信息二者的高效方式。在先前申请中，用于促进多媒体的高带宽通信的方法是单频网络(SFN)操作。 SFN利用无线发射机(例如，举例来说，eNB)与订户UE进行通信。在单播操作中，对每个eNB进行控制，以发送携带针对一个或多个特定订户UE的信息的信号。单播信令的特异性(specificity)使得能够实现人对人的服务，例如，举例来说，语音呼叫、文本消息传递或视频呼叫。
发明内容
概括地说，本公开内容描述了用于网络上的流媒体数据的技术。例如，本公开内容描述了一种用于经由不同类型的传输(例如，单播、广播和/ 或多播中的任意传输)来接收媒体数据的技术。例如，重定向器/代理单元可以使得应用服务客户端直接经由单播从互联网取回媒体数据，或者当广播或多播服务可用时，从广播或多播中间件单元取回媒体数据。可替代地，当广播或多播服务不可用时，重定向器/代理单元可以代表应用服务客户端来取回媒体数据。当多种类型的传输可用和/或用于传递媒体数据时，可以在下面使用术语“传输分集”。当提供商(媒体来源)和/或用于传递媒体的传输改变(例如，由重定向器/代理单元)时，可以在下面使用术语“重定向”或“被重定向”。
本公开内容还描述了关于缓存所取回的媒体数据的技术。例如，可以将所取回的媒体数据存储在时移缓存器(TSB)中。本公开内容描述了用于以信号形式发送TSB的大小的技术(例如，关于媒体内容的回放时间)，使得可以分配适当量的存储器用于TSB。以这种方式，可以在稍后的时间回放媒体数据和/或使用特技(trick)方式(例如快进或倒带)来回放。
在一个例子中，一种取回媒体数据的方法包括：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
在另一个例子中，一种用于取回媒体数据的设备包括代理单元，所述代理单元被配置为进行以下操作：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
在另一个例子中，一种用于取回媒体数据的设备包括用于获取映射信息的单元，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输中的至少一个；用于从应用服务客户端接收针对所述媒体数据的请求的单元；用于确定所述服务是否是可用的单元；以及用于当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据的单元，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
在另一个例子中，一种计算机可读存储介质具有存储于其上的指令，当所述指令被执行时，使得处理器来执行以下操作：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
在另一个例子中，一种处理媒体数据的方法包括：接收会话描述协议 (SDP)消息，所述SDP消息包括定义了时移缓存器(TSB)深度的属性；基于所述属性的值，确定用于所述TSB的存储器的量；分配所确定量的存储器以形成所述TSB；以及，在所述TSB中存储与所述SDP消息相关联的至少一部分媒体数据。
在另一个例子中，一种用于处理媒体数据的设备包括一个或多个处理器，所述一个或多个处理器被配置为进行以下操作：接收会话描述协议 (SDP)消息，所述SDP消息包括定义了时移缓存器(TSB)深度的属性；基于所述属性的值，确定用于所述TSB的存储器的量；分配所确定量的存储器以形成所述TSB；以及，在所述TSB中存储与所述SDP消息相关联的至少一部分媒体数据。
在另一个例子中，一种用于处理媒体数据的设备包括：用于接收会话描述协议(SDP)消息的单元，所述SDP消息包括定义了时移缓存器(TSB) 深度的属性；用于基于所述属性的值，确定用于所述TSB的存储器的量的单元；用于分配所确定量的存储器以形成所述TSB的单元；以及，用于在所述TSB中存储与所述SDP消息相关联的至少一部分媒体数据的单元。
在另一个例子中，一种计算机可读存储介质具有存储于其上的指令，当所述指令被执行时，使得处理器来执行以下操作：接收会话描述协议 (SDP)消息，所述SDP消息包括定义了时移缓存器(TSB)深度的属性；基于所述属性的值，确定用于所述TSB的存储器的量；分配所确定量的存储器以形成所述TSB；以及，在所述TSB中存储与所述SDP消息相关联的至少一部分媒体数据。
附图说明
图1示出了用于支持传输分集的示例性系统。
图2A-2B示出了包括重定向器/代理以支持传输分集的装置的可替代例子。
图3示出了使用被配置为进行重定向操作的重定向器/代理的示例性过程流的方面。
图4示出了使用被配置为进行代理操作的重定向器/代理的方法的方面。
图5示出了用于支持传输分集的方法的例子。
图6示出了用于实现图5的方法的示例性装置。
图7和图8示出了用于支持传输分集的进一步的方面。
图9和图10是示出了用于支持实时传输协议(RTP)/实时流协议 (RTSP)流式传输的示例性多播服务设备客户端(MSDC)架构的框图。
图11是示出了示例性演进的MBMS(eMBMS)用户服务描述(USD) 模式片段的概念图。
图12和13是示出了示例性组件的框图，所述示例性组件用于支持针对RTSP/RTP客户端的传输分集。
图14A和14B是示出了用于扩展USD以携带HTTP动态自适应流媒体(DASH)传输信息的示例性可扩展标记语言(XML)内容模型的概念图。
图15是示出了用于支持MBMS上的DASH的示例性架构的概念图。
图16是示出了与图15的网络架构相关联的、用于广播和单播传输上的DASH内容传送的调用流程。
图17是示出了用于支持MBMS上的DASH的另一示例性架构的概念图。
图18-23是示出了与图17的网络架构相关联的、用于广播和单播传输上的DASH内容传送的流程图。
图24是用于根据本公开内容的技术，示出了用于以信号形式发送关于时移缓存器(TSB)深度的示例性方法的流程图。
具体实施方式
一般来说，本公开内容描述了用于通过网络支持针对各种类型的流媒体数据的传输机制的技术，所述各种类型的流媒体数据如例如音频和/或视频数据。例如，应用服务客户端(其也可以被称为流式传输客户端)可以被配置为与代理单元进行交互，以根据单播协议或广播(或者多播)协议来取回媒体数据。在一些例子中，代理单元可以确定是否可以使用广播协议来取回媒体数据，例如基于客户端设备是否在用于使用广播协议来传送媒体数据的服务提供商的覆盖区域内，并基于所述客户端设备是否在覆盖区域内来选择广播协议或者单播协议。客户端设备可以执行应用服务客户端和/或包括代理单元。在一些例子中，客户端设备可以执行应用服务客户端，并且代理单元可以被包括在与客户端设备分开的设备中。
本公开内容的技术可以与针对流媒体数据的各种应用层协议一起使用。例如，本公开内容的技术可以与HTTP动态自适应流媒体(DASH) 一起使用，其利用HTTP来流式传输媒体数据。作为另一个例子，本公开内容的技术可以与实时传输协议(RTP)或实时流协议(RTSP)一起使用。在这些和其它情况下，在应用服务客户端不需要知道用于取回媒体数据的传输机制的意义上，应用服务客户端(例如，RTP客户端、RTSP客户端或DASH客户端)可能是传输不可知的。例如，应用服务客户端不需要知道底层传输机制是对应于单播协议还是广播或者多播协议。
如下面更详细讨论的，代理单元(其也可以被称为重定向器/代理单元)可以被配置为从应用服务客户端接收请求，其中所述请求指定了某些媒体数据。代理单元可以确定是否可以使用特定的传输机制(例如，广播协议或单播协议)来取回媒体数据。代理单元随后可以使得应用服务客户端使用传输机制中的一种(基于可用性、偏好、可靠性和/或其它因素) 来接收媒体数据。例如，如果广播协议比单播协议更优选，则该广播协议是可用的，代理单元可以使得应用服务客户端经由广播协议来接收媒体数据，而如果广播协议不可用，则代理单元可以使得应用服务客户端经由单播协议来接收所述媒体数据。
作为一个例子，对于DASH，媒体数据可能作为广播和/或单播服务从一个或多个服务器(例如，广播服务器和单播服务器)可用的。DASH 客户端可以从代理单元(而不是服务)接收针对媒体数据的修改的媒体表达描述(MPD)，其指示该媒体数据是可用的。当DASH客户端向代理单元发送针对媒体数据的请求时，代理单元可以确定是单播协议还是广播协议可用于取回所请求的媒体数据。如果广播协议是可用的，则广播接收单元(例如，多媒体广播多播服务(MBMS)或演进的MBMS(eMBMS) 中间件单元)可以接收媒体数据，并且代理单元可以使得DASH客户端向广播接收单元发送针对媒体数据的请求。另一方面，如果广播协议是不可用的，则代理单元可以使得DASH客户端向单播服务器发送针对媒体数据的请求，以使用单播来取回媒体数据。可替换地，代理单元可以从单播服务器取回媒体数据，然后向DASH客户端提供所取回的媒体数据。在一些例子中，单播服务器和广播服务器可以对应于相同的服务器。
作为另一个例子，对于RTP或RTSP，RTP客户端(可替代地，其可以对应于RTSP客户端)可以向代理单元提交DESCRIBE、SETUP和PLAY 命令。响应于DESCRIBE命令，代理单元可以向RTP客户端提供修改的的会话描述协议(SDP)消息。该修改的SDP消息可以指定代理单元的地址作为该媒体数据从此处可用的地址。该修改的SDP消息可以使得RTP 客户端向代理单元发送SETUP和PLAY命令。当代理单元确定了广播协议是可用的，则代理单元可以向广播接收单元(例如，MBMS或eMBMS 中间件单元)发送SETUP和PLAY命令，该广播接收单元可以接收该媒体数据并向RTP客户端转发媒体数据。另一方面，当代理单元确定了广播协议不可用，则代理单元可以从单播服务器取回媒体数据，然后向RTP 客户端提供所取回的媒体数据。
在一些例子中，用于执行本公开内容的技术的组件可以包括应用服务客户端、代理单元和广播接收单元。在各种例子中，客户端设备可以包括这些组件中的任意组件或全部组件、单独组件或其任何组合。可替代地，客户端设备可以包括应用服务客户端，而代理单元和/或广播接收单元可被包括在与客户端设备分离的一个或多个设备中。
此外，本公开内容还描述关于以信号形式发送针对时移缓存器(TSB) 的数据的技术。客户端设备(在此也称为“用户设备”)可以分配存储以形成TSB，所述TSB用于保持媒体数据，以支持各种特技模式，例如快进、倒带、重放等。在一般情况下，特技模式可以指的是媒体数据以定义的输出顺序之外的顺序或速率来回放媒体数据的回放模式。例如，在快进中，可以跳过某些媒体数据。作为另一实例，在倒带中，可以反转针对媒体数据的输出顺序，并且可以跳过某些媒体数据。例如，对于视频数据，为了跳过媒体数据，仅显示使用帧内编码模式编码的画面而跳过帧间编码图像。
根据本公开内容的技术，可以在例如，SDP消息中以信号形式发送数据，用于实例化TSB。例如，可以利用以秒为单位的值来以信号形式发送 TSB属性，所述值定义了可以存储在TSB中的媒体数据的量。客户端设备可以基于所述TSB属性的值来计算TSB所需要的存储器的量。以视频数据为例，这种计算可能涉及媒体数据中的视频数据的帧速率。客户端设备可以基于每个图像的数据的平均量、一段时间中(基于帧速率)的图片的数量和由TSB属性所定义的时间长度，来计算用于TSB的存储器大小。同样地，客户端设备还可以确定针对该时间段，音频数据、文本数据或其它数据或媒体所需的存储器的量。因此，客户端设备可以向用于存储存储媒体数据的TSB分配该数据以执行特技模式。此外，客户端设备可以针对经由广播协议(例如MBMS或eMBMS)接收到的数据来执行特技模式。
换句话说，在一些例子中，本公开内容的技术包括中间件架构，其用于支持演进的多媒体广播多播服务(eMBMS)网络上的实时协议/实时流协议(RTP/RTSP)流式传输的特征。这些功能包括时移缓存器和传输分集(例如，针对内容传递的单播对多播切换或反之亦然)。对于时移缓存器(TSB)特征，该架构可以支持会话描述协议(SDP)的扩展，以包括以信号形式发送缓存器深度的数据。作为传输分集特征的一个例子，本公开内容提出了一种架构，在所述架构中，消耗内容的应用不需要知道从单播到广播(或反之亦然)的传输切换的详细情况，因为该切换可以在中间件级别来管理。
在HTTP流式传输中，经常使用的操作包括GET和部分GET。GET 操作请求与给定的统一资源标识符(URI)(例如，URL或URN)相关联的整个文件的取回。部分GET操作请求资源的字节范围(子集)的取回。因此，针对HTTP流式传输，可以提供视频片段，这是因为GET或部分 GET操作可以取回一个或多个单独的视频片段。在视频片段中，可能存在不同轨道的若干轨道片段。在HTTP流式传输中，媒体表达可以是客户端可访问的数据的结构化集合。客户端可以请求并下载媒体数据信息以向用户表达流式传输服务。
在使用HTTP流式传输DASH数据的例子中，针对多媒体内容的视频和/或音频数据，可能存在多种表示(representation)。这种表示的清单 (manifest)可以在媒体表达描述(MPD)数据结构中定义。媒体表达可以对应于HTTP流式传输客户端可访问的、设备数据的结构化集合。HTTP 流式传输客户端设备可以请求和下载媒体数据信息，以向客户端设备的用户表达流式传输服务。可以以MPD数据结构来描述媒体表达，其可以包括MPD的动态更新。
媒体表示可以包含一个或多个时段的序列。可以在MPD中，由period 单元来定义时段。在MPD中，每个时段可以具有属性start。该MPD可以包括针对每个时段的start属性和availablityStartTime属性。对于实时服务，所述时段的start属性和MPD属性availableStartTime的总和可以以 UTC格式指定时段的可用时间，特别是每一个时段中的每个表示的第一媒体段(Segment)。对于按需服务，第一时段的start属性可能是0。对于任何其他时段，start属性可以指定对应时段的开始时间相对于第一时段的开始时间之间的时间偏移。每个时段可以延长，直到下一个时段的开始，或者在最后时段的情况下，直到媒体表达的结束。时段的开始时间可能是准确的。它们可能反映了从播放所有前期时段的媒体所造成的实际时序。
每个时段可以包含针对相同媒体内容的一个或多个表示。一种表示可以是音频、视频或其它数据的数种可替代编码版本中的一个。该表示可以由于编码类型而不同，例如，比特率、分辨率和/或针对视频数据和比特率、语言和/或针对音频数据的编解码。术语表示可以用来指编码的音频或视频数据或其它媒体或数据的段，其对应于所媒体内容的具体时段，并以具体的方式被编码。
具体段的表示可以被分配给组，所述组由MPD中的group属性所指示。同一组中的表示通常被认为是相互可替代的。例如，可以将具体时段的视频数据的每个表示分配给相同的组，使得所述表示中的任何表示可以被选择用于解码，以显示针对相应时段的多媒体内容的视频数据。在一些例子中，一个时段中的媒体内容可以由来自组0的任一种表示(如果存在的话)，或来自每个非零组的至多一个表示的组合来表示。针对时段的每个表示的时序数据可以相对于该时段的开始时间来表示。
表示可以包括一个或多个段。每一个表示可以包括初始化段，或每个表示的每个段可以自初始化。当存在时，初始化段可以包含用于访问该表示的初始化信息。在一般情况下，初始化段不包含媒体数据。段可以是使用标识符来唯一地引用的，所述标识符例如统一资源标识符(URI)(例如，统一资源定位符(URL)或统一资源名(URN))。MPD可以为每个段提供标识符。在一些例子中，MPD还可以以range属性的形式提供字节范围，通过引用相应的URI，range属性可以对应于针对可访问的资源(例如，文件)中的连续字节范围的段的数据。
每个表示还可以包括一个或多个媒体组分，其中每个媒体组分可以对应于编码版本的一个单独的媒体类型，如音频、视频或定时文本(例如，用于关闭的字幕)。在一个表示中，媒体组件可以跨越连续的媒体段的边界是时间连续的。
本文中所描述的技术可用于以上提到的无线网络和无线技术以及其它的无线网络和无线技术。为了清楚起见，下面针对LTE来描述这些技术的某些方面，并且在以下大部分描述中使用和LTE术语。
RTP/RTSP流式传输是用于支持实时流式传输服务的常见协议。针对 eMBMS服务的3GPP规范中描述了用于长期演进(LTE)网络上的RTP 流式传输的架构。然而，该公开内容中，认识到RTP/RTSP的两个问题，并讨论了可以用于克服这些问题的技术。
时移缓存器(TSB)是可以用于在用户设备(UE)中存储一部分媒体内容的特征。该缓存器允许用户将媒体内容的回放点向前或向后移动。在这个过程中，需要通知UE缓存器深度，该深度提供了对UE需要在设备处累计等于多少时间的内容以允许特技模式回放(例如，快进或倒带回放) 的指示。在VLC媒体播放器的一个实现中，通过在启动时向VLC播放器提供作为参数的缓存器深度，来启用TSB特征。该过程不是自动的，而是反过来需要用户的干预，以提供缓存深度参数，从而启用TSB。本公开内容描述了用于在启用eMBMS的中间件层(如多播服务设备客户端 (MSDC))支持TSB的技术。
会话描述协议(SDP)描述了一种流式传输服务的端点信息及其媒体流(会话)相关参数，统称为“会话简档”。因此，如果流时传输服务在不同的传输方法中是可用的，则需要描述了针对服务的不同传输/端点参数的多个简档。例如，广播实时基于RTP的服务可以指的是针对其媒体流的多播IP地址和端口，而服务的单播版本可以指的是单播IP地址和端口。针对广播和单播传输方法，可能存在媒体流的不同表示。在LTE网络中，MSDC向启用eMBMS的应用提供流式传输服务的传递。为了支持单播和其他(例如，广播或多播)传输方法之间切换，需要使用多个会话简档，其选择将主要基于UE是在广播的覆盖范围之外还是在内。当UE移动到广播覆盖区域时，MSDC可以使用SDP简档的启用广播的版本来建立连接，并消耗内容。然而，在相反的场景，当UE移出广播覆盖范围时， MSDC可能需要使用单播SDP并与远程RTSP服务器建立单播连接，以消耗单播内容。为了向用户或应用隐藏单播和广播之间的转换，本公开内容描述了一种用于无缝转换的机制。
除了其它技术，本公开内容描述了关于支持TSB的技术和用于支承切换的技术，其可以单独使用、一起使用和/或与本公开内容中描述的其他技术任意组合使用。为了在eMBMS上的基于RTP的流式传输中启用 TSB特征，本公开内容描述了用于使用SDP机制的扩展来以信号形式发送时移缓存器的深度值的技术。针对传输切换问题，本公开内容描述了针对SDP描述的统一方法，所述SDP描述包括单播和广播描述二者。另外，为了使广播和单播之间的转换对应用/用户是无缝的，本公开内容描述了一种基于中间件的解决方案，其中中间件使用统一的SDP来处理内容的重定向，将该过程向用户隐藏。
根据本公开内容的主题的方面，提供了用于在客户端设备中或设备集合进行部署的方法、装置和架构，以提供抽象层，其中，多个不同类型的传输机制/协议(如，eMBMS、数字视频广播(DVB)等)可以用于例如向客户端的应用传递元数据和数字内容。应用不需要认识到每个单独传输的细节。本公开内容可以包括对可配置策略集合的选择，所述策略位可以用于确定传递到应用的数据和元数据的选择、位置或可用性的定时。
在互联网上访问web内容的应用可以使用通用资源标识符(URI)来识别内容，所述URI可能利用在HTTP或HTTP安全(HTTPS)方案的通用资源定位符(URL)。例如，在MPEG-DASH的上下文中，使用HTTP 或HTTPS协议，可以解决包含在HTTP或HTTPS方案中的URL引用。此外，HTTP可以用来获取由URL所引用的数据。DASH标准可以利用非 HTTP URL，并且本公开内容可以涉及以灵活的方式处理来自客户端的任意请求(包括基于HTTP请求)的情况，这提供了以下选择：使得请求在不同的时间被定向到不同的位置，和/或指示请求客户端访问替代内容。
本公开内容的技术可能涉及处理客户端对内容的请求的重定向器功能的实例。重定向器(本文中也称为重定向器/代理)可以是能够对客户端请求中识别的材料施加处理，调用方法或算法，将该处理的结果与匹配标准的表进行比较，并向客户端指示可替代位置、访问方法、定时信息或内容(例如，在文件中)，从而客户端可以知道在哪里执行后续请求。在另一个方面，重定向器可以代表客户端执行针对内容的请求，并获取所请求的内容。在这种情况下，重定向器可以充当代理或递归功能单元。
图1是示出了用于支持传输分集的示例性系统100的框图。该示例性系统100可以包括例如移动设备的应用101。应用101可以执行对内容的请求。例如，DASH多媒体回放应用处理清单或MPD，并且确定包含元数据和数据的URL，并发送HTTP请求。对内容的请求可以使用预先确定的、预先配置的或动态确定的协议端口(例如，使用TCP或UDP)，例如，通常用于配置Web浏览器的“代理”的功能的协议。对协议端口的确定可以包括使用配置文件，例如，由用户或网络/系统管理员在例如代理自动配置(PAC)文件中建立的配置文件，或经由例如Web代理自动发现协议(WPAD)的协议中建立的配置文件。
重定向器/代理104可以经由应用服务客户端102接收应用101的请求，并处理或解析该请求，以确定所请求的内容。重定向器/代理104可以将结果与包含匹配标准的表(或其它合适类型的数据结构)进行比较，以确定是否发生匹配。如果出现匹配，则重定向器/代理104可以确定重定向目标。可以将目标被传递给应用101。在另一个方面，重定向器/代理104可以以递归方式操作而应用101可能不需要处理重定向目标。例如，重定向器/代理104可以基于重定向目标代表应用101来获取内容。
重定向器/代理104可以与应用101位于同一设备上，或重定向器/代理104可以位于单独的设备上。在共同定位的重定向器/代理104的情况下，应用101可以通过HTTP、应用编程接口(API)、进程间通信(IPC) 等与重定向器/代理104通信。在重定向器/代理104位于单独的设备上的情况下，应用101可以通过HTTP等与重定向器(经由应用服务客户端102)通信。
在确定了“匹配”(或不匹配)之后，可以将重定向目标提供给应用 101。该目标可以指示要访问的替代内容对象，以代替应用101请求的内容目标。可能存在通过其将重定向目标指示给应用101的各种方法。
系统100的组件之间的信号传输可以使用API或IPC来执行。在该方面，API或IPC机制可被用在重定向器/代理104与应用101之间提供通信。在使用API的情况下，重定向器/代理104可以调用应用101或应用库中实现的方法或程序，来指示重定向目标。
系统100的组件之间的信号传递可以通过元数据重写来执行。在这个方面，元数据(例如，DASH MPD)可以被重写，以便指示对象的可替代引用。例如，原始元数据中的URI可以被重写，以形成用于访问等同或替换内容的可替代URI。
系统100的组件之间的信号传递可以使用通信协议中的指示来执行。在这个方面，应用层通信协议(例如，HTTP)可以以向应用101传输信令信息的方式来使用。在一个变型中，可以使用“重定向”类别的HTTP 响应代码(例如，这可以对应于形式为3xx的代码，其中x可能是从0到 9的数)。在该变型的一种子情况中，例如，可以使用代码300(指示多种选择可用)，其中，重定向器/代理104提供引用的矢量(例如，URI)，应用101可以从其选择一个或多个来使用。
匹配功能可以给出源自应用101的目标引用(例如，请求URI)与数据结构(例如，文件、数据库、匹配表等等)中的目标引用的比较的结果。
通过非限制性示例的方式，在一个方面，匹配标准可以表达为URI 前缀，而单个优选匹配发生是由与最长前缀(例如指示，如通过位或字节的数目来确定在常见)的匹配来指示的。在另一个方面，每个潜在的匹配可以被分配相应的优先级号码，并且可以选择具有最大(或最小)的优先级号码的条目。
在另一个方面，匹配准则可以被表达为正则表达式，并且可以使用最大数量的匹配字符来确定优选的匹配。在另一种变型中，正则表达式可以用来表达匹配标准，并可以选择具有最大(或最小)优先级号码的潜在匹配。
以上讨论的数据结构的匹配算法或内容可以基于可能被预先确定或预先配置的策略。在另一个方面，可以从逻辑策略数据库中动态地添加或删除所述策略。策略数据库可以使用各种数据结构来实现，并且不限于任何特定类型的数据结构或数据库实现。
策略可以用于以多种方式来确定匹配算法的操作，所述多种方式包括例如：将来自一个源的匹配标准相比于来自其他源的匹配标准进行优先化或去优先化(例如，一个传输类型可以受喜爱的/不受喜爱的)；根据源、时间、重定向目标和/或匹配标准值，移除匹配标准；根据源、时间、重定向目标和/或匹配标准值，添加匹配标准；和/或根据源、时间、重定向目标和/或匹配标准值，修改匹配标准。
示例性系统100可以包括传输中间件110，以用于基于重定向的位置来请求内容。传输中间件110可以包括多个传输机制/协议，如传输A 110A 至传输R 110R。每个传输机制(传输A 110A至传输R 110R)可能具有相应的模块，所述模块能够获取文件信息的列表和细节，并产生例如汇总 (summarizing)URI或公共URI前缀。这些模块可以经由通信机制(例如，IPC、API或协议)将该信息传递给可以实施策略和分辨率的控制器 106，而这可能反过来使重定向器/代理104受策略影响。传输机制(传输 A 110A至传输R 110R)可以包括例如eMBMS、DVB-T2、DVB-S其他的 DVB-族广播技术等等。每个传输中间件可以包括用于存储内容或其他数据的高速缓存器。例如，传输中间件可以高速缓存内容的起始段，使得向应用101的内容传递可能看起来对用户是瞬时的。传输中间件110可以从例如内容服务器120的源请求内容。另外或替代地，客户端可以请求网络 (包括互联网122)上的内容。对于配置用于代理“递归”操作的重定向器/代理104，重定向器/代理104可以经由传输中间件110或经由网络或互联网122来请求内容。重定向器/代理104可以被预先配置为以重定向功能或代理功能中的一个来操作。可以在运行时间例如基于一组规则来确定重定向器/代理104的功能。
图2A-2B示出了装置的了替代例子，所述装置包括用于支持传输分集的重定向器/代理104。重定向器/代理104、具有策略数据库108的控制器 106或传输中间件110可以与应用101和客户端共同位于同一个设备上，或者可以位于分开的设备。在图2A的例子中，系统200A包括重定向器/ 代理104A，其被示出为与客户端和应用101共同位于UE 101A上。例如，应用服务客户端102A可以是DASH客户端、HTTP实时流媒体(HLS)、苹果流媒体(ALS)客户端、自适应HTTP流媒体(AHS)客户端或任何其他合适的客户端。应用服务客户端102A可以经由HTTP、API、IPC或任何其他合适的协议或方式与重定向器/代理104A进行通信。在图2B的例子中，系统200B包括重定向器/代理104B，其被是示出为位于单独的实体180上，而应用服务客户端102B和应用101位于UE 101B中。例如，应用服务客户端102B可以是DASH客户端、HLS(ALS)客户端、AHS 客户端或任何其他合适的客户端。应用服务客户端102B可以经由HTTP或任何其他合适的协议或方式与重定向器/代理104B进行通信。重定向器 /代理104B可以位于任何适当的网络实体上，例如代理服务器、网关、路由器等。
图3是示出了使用被配置进行重新定向操作重定向器/代理的示例性过程流320的方面的流程图。在过程流320开始之前，策略数据库108(耦合到控制器106)可以提供或预配置具有用于确定控制器106的动作的策略信息。在配置时间，策略数据库108可被提供具有信息。
应用101，其可能与或可能不与图1中的应用101相关，可能是配置应用。应用101可以被配置为激活传输中间件110(321)，以及确定针对传输中间件110的状态。应用101可以被配置为激活传输中间件110的一个或多个传输机制。应用服务客户端102最初可以由应用101在启动时被配置具有用于识别代理端点的信息(例如，主机名称或地址、协议或协议端口号)(322)。
在这个例子中，一个以上的传输机制可能是可用的，并且各种媒体可能在不同的时间在各种传输上是可用的。特别地，各种服务可能是可用的，其中各种服务可能各自定义了用于传输媒体数据的不同的相应类型的传输(如广播、多播、单播等等)。例如，eMBMS和/或传输的DVB族中的一种或多种可能是可用的。此外，可以使用例如应用程序服务描述来表示可用的媒体内容(例如，文件)。应用服务描述的一个例子是MBMS用户服务描述(USD)元数据片段，例如在DASH内容被传递作为MBMS用户服务的情况下的MPD片段，其描述各种可用的媒体组件。应用服务描述另一个例子是苹果HLS(HTTP实时流式传输)清单文件，在HLS内容被传递作为MBMS用户服务的情况下。每个传输机制可以具有相应的模块，所述模块能够获取文件信息的列表和细节，并产生汇总URI或公共 URI前缀。这些模块可以经由通信机制(例如IPC、API其他协议)向可以应用策略和分辨率的控制器106传递该信息，而这反过来使得重定向器 /代理104受策略影响。
内容服务器310可以广播由传输中间件110(例如使用LTE RAN、 DVB-T等)接收的服务列表(例如，USD、ESG)。适当的模块(例如，传输110A到传输R 110R中的一个)解析服务列表并将信息处理为非传输特定的形式。传输中间件110可以将结果(例如，定义可用的文件列表的服务和数据的标识符，也被称为文件的可用性列表)传送给控制器106 (324)。控制器106可以处理该文件可用性列表与访问策略，以生成一组映射(325)。映射可以包括哪些URI(或URI前缀)应该被重新定向到哪个服务器(例如，来自实例化服务器的、MBMS上的文件可能是可用的，所述实例化服务器在MBMS中间件中或者与MBMS中间件相关联)
一旦应用服务客户端102被调用，则应用服务客户端102可以经由被配置的代理地址发出请求(例如，HTTP请求)以获得例如MPD内容(326)。该请求可以被传送到重定向器/代理104。重定向器/代理104可以执行匹配算法以确定匹配标准，或者，如果没有匹配发生，则确定另一个指示符 (例如，默认重定向目标、错误指示或原始请求的复本)。重定向器/代理104随后可以例如使用HTTP来向应用服务客户端102提供重新定向目标或错误(327A)。在观察到指示重定向的代码(例如，HTTP代码)(例如， 3xx类型代码)后，应用服务客户端102取决于代码类型来进行响应。例如，除了300的代码类型包括HTTP“位置：”头部，其可以指示针对资源的替代位置。当收到这种指示时，应用服务客户端102可以使用所指示的替代位置来重新尝试其请求。在这个例子中，重定向器/代理104指示特定的URI应被定向到集成在MBMS中间件中的服务器。因此，应用服务客户端102可以响应于这种重定向代码，向传输中间件110提交请求，以获取例如MPD(327B)。
一旦应用服务客户端102已经获取了MPD信息，则应用服务客户端 102可以确定要访问哪些媒体段(例如，在MPEG-DASH的情况下，哪些“表示”)，并向重定向器/代理104发出基于HTTP的请求(328)。使用上述的机制(例如，与服务ID所识别的服务相关联的传输类型)，重定向器/代理104可以向应用服务客户端102提供重定向目标(329)。所述目标可能是默认值、请求的副本(指示应用服务客户102应该处理该请求)、或对不同的服务器的引用。该目标随后作为由DASH客户端102使用的位置以获得媒体片段。也就是说，假设使用该服务，内容是可用的，则应用服务客户端102可以向传输中间件110提交内容请求(330A)，并且作为响应，传输中间件110可以将该内容传送给应用服务客户端102(331A)。对于通过其他源可用的内容(例如，当服务不可用)，应用服务客户端102 可以经由其他方法来获取该内容(例如，从其它服务器、存储器/高速缓存器或互联网)。例如，应用服务客户端102可以发送向内容服务器310 发送内容请求(330B)，并且作为响应，内容服务器310可以向应用服务客户端102传递所请求的内容(331B)。
在一些情况下，从应用服务客户端102请求的URI(在步骤326或328) 对重定向器/代理104来说可能是未知的。在这种情况下，可以生成错误 (例如，HTTP代码404)，以指示应用服务客户端102：其可以尝试请求不同的段，或停止使用HTTP重定向器/代理104(例如，替代的，使用直接互联网访问请求)。可替代地，重定向器器104可以使用相当于传入请求的位置头部，以暗示非代理操作。另一方面可能涉及重定向器/代理104 充当代理或者Web代理，在这种情况下，它可以代表应用服务客户端102 来访问互联网或另一个网络或高速缓存器，如以下在图4的示例性过程流 400中示出的。
对于300类型的HTTP错误代码，应用服务客户端102可以被呈现具有选择的矢量，其可能不存在于“位置：”头部。在这种情况下，应用服务客户端102可以取决于媒体编码格式，在提供的多种选择中进行选择，重新初始化其解码状态。以下场景可能出现，例如，如果重定向在对表示的回放场景的中间发生，所述表示是以不同于该应用服务客户端102迄今已经处理的编码方式不同的编码方式来编码的。
无论应用服务客户端102使用什么过程来选择其下一个媒体请求/访问，应用服务客户端102可以基于重定向信息来发起请求/访问。后续请求/访问最初可以通过重定向器来传递，着提供了以下机会：使得重定向器介入并有效地修改从其取回段(例如，存储为文件的位置元数据和/或媒体段)的位置(以及其它特征)。
图4是示出了使用被配置为进行代理操作的重定向器/代理的示例性过程流400的方面的流程图。在过程流400开始之前，策略数据库108(耦合到控制器106)可以提供或预配置具有用于确定控制器106的动作的策略信息。在配置时间，策略数据库108可被提供具有信息。
应用101可以是配置应用。虽然相对于图1来描述应用101，但应该理解的是，该应用不必与关于图2描述的应用是相同的。应用101可被配置为激活传输中间件110(401)。应用101可以被配置为激活传输中间件 110的一个或多个传输机制。应用服务客户端102最初可以由应用101在启动时被配置具有用于识别代理端点的信息(例如，主机名称或地址、协议或协议端口号)(402)。
在这个例子中，一个以上的传输机制可能是可用的，并且各种媒体可能在不同的时间在各种传输上是可用的。各种类型的传输可以由各自的服务来定义。例如，eMBMS和/或传输的DVB族中的一种或多种可能是可用的。此外，可用的媒体文件可以使用例如，该eMBMSUSD的MPD片段来表示，并经由DVB电子服务指南(ESG)用于DVB传输。由传输中间件110表示的各种传输机制可以具有相应的模块，所述模块能够获取可用服务和文件信息细节的列表，并用于产生汇总URI或公共URI前缀。这些模块可以经由通信机制(例如IPC、API其他协议)向可以应用策略和分辨率的控制器106传递该信息，而这反过来使得重定向器/代理104受策略影响。
内容服务器310可以广播由传输中间件110(403接收的服务列表(例如，USD、ESG)。适当的模块(例如，传输110A到传输R 110R中的一个)解析服务列表并将信息处理为非传输特定的形式。传输中间件110可以将结果传送给控制器106(404)。控制器106可以处理在文件可用性列表与访问策略以生成一组映射(405)。映射可以包括哪些URI(或URI 前缀)应该被重新定向到哪个实例化的服务器(例如，MBMS上可用的文件或媒体可能从实例化服务器是可用的，所述实例化服务器在MBMS中间件中或者与MBMS中间件相关联)。
一旦应用服务客户端102被调用，则应用服务客户端102可以经由被配置的代理地址发出请求(例如，HTTP请求)以获得例如MPD内容(406)。该请求可以传送至重定向器/代理104。重定向器/代理104可以执行匹配算法以确定匹配标准，或者，如果没有匹配发生，则确定另一个指示符(例如，默认重定向目标、错误指示或原始请求的复本)。在出现错误的情况下，可以将错误提供给应用服务客户端102。如果发生匹配，则重定向器/ 代理104可以充当代理，并代表应用服务客户端102来取回内容。目标然后作为由重定向器/代理104(其充当代理)使用的位置，来获得媒体段。即，重定向器/代理104可以向传输中间件110提交内容请求(407A)，而传输中间件可以将该内容递送给重定向器/代理104(408A)。对于通过其他源可用的内容，重定向器/代理104(其充当代理)可以经由其他服务器从存储器/文件或互联网获取内容。即，重定向器/代理104可以向内容服务器310提交内容请求(407B)，而内容服务器310可以将所请求的内容传递给重定向器/代理(408B)。
图5是示出了一种示例性方法的流程图，所述示例性方法用于针对无线通信网络(WCN)的多媒体客户端，支持与多媒体内容相关联的传输分集。多媒体客户端可以是或可以包括移动实体。在502处，方法500可以包括接收针对内容的请求。在504处，方法500可以包括基于一组规则来确定针对请求的匹配是否存在。在506处，方法500可以包括响应于确定存在匹配，向多媒体客户端发送重定向。
图6是示出了示例性装置600的框图，所述示例性装置600可以被配置为UE、网络实体或其它适当实体，或者用于在UE、网络实体或其它适当实体中使用的处理器、组件或类似设备，用于针对无线通信网络(WCN) 的多媒体客户端，支持与多媒体内容相关联的传输分集。装置600可以包括功能块，其可以表示由处理器、软件或其组合(例如，固件)所实施的功能。
如图所示，在一个例子中，装置600可以包括用于接收针对内容的请求的电组件或模块602。装置600可以包括用于基于一组规则来确定针对请求的匹配是否存在的电组件或模块604。装置600可以包括用于响应于确定存在匹配，向多媒体客户端发送重定向的电组件或模块606。
在相关方面中，在装置600被配置为网络实体的情况下，装置600可以可选地包括具有至少一个处理器的处理器组件610。在这种情况下，处理器610可以经由总线612或类似的通信耦合与组件602-606或类似的部组件进行操作性通信。处理器610可以实现发起和调度由电组件或模块 602-606执行的过程或功能的调度。
在进一步的相关方面中，装置600可以包括用于与其它网络实体进行通信的网络接口组件614。装置600可以可选地包括用于存储信息的组件，例如，举例来说，存储器设备/组件616。计算机可读介质或存储器组件 616可以经由总线612等被可操作地耦合到装置600的其它组件。存储器组件616可以适于存储计算机可读指令和数据，以用于执行组件602-606 或处理器610的活动和其子组件。存储器组件616可以保留有用于执行与组件602-606相关联的功能的指令。虽然被示出为在存储器616外部，但是应当理解的是，组件602-606可以在存储器616内存在。
图7和8是示出了用于支持运输分集的方面的框图。图7和/或8的组件可以基本与以上所描述的图1的组件相对应。例如，图7示出了网络 700、应用服务客户端702、媒体应用704、HTTP重定向器/代理706、控制器708、中间件712和策略管理器716。媒体应用704一般负责选择媒体内容(例如，响应于用户的选择)，而应用服务客户端702被配置为取回所选择的媒体内容，并将所取回的媒体内容提供给媒体应用704以进行回放。应用服务客户端702可以包括例如DASH客户端，所述DASH客户端被配置为利用HTTP来流式传输媒体数据。
如以上关于图1所讨论的，应用服务客户端702可以直接从网络700 或者从中间件712取回媒体数据。例如，当支持广播或多播的服务是可用的(例如，由控制器708确定，并且由策略管理器716存储的策略所定义)，中间件712可以接收媒体数据，并将所接收的媒体数据存储在高速缓存器 714中。应用服务客户端702可以向重定向器/代理706发出针对媒体数据的请求。当所请求的媒体数据被中间件712接收到时，HTTP重定向器/ 代理706可以向中间件712重定向针对媒体数据的请求。因此，应用服务客户端702可以向中间件712发出HTTP请求，其中间件712可以向应用服务客户端702提供媒体数据。另一方面，当中间件712没有接收到媒体数据时，HTTP重定向器/代理706可以将应用服务客户端702重定向到媒体数据是可用的服务器的网络位置，其中，该服务器可能经由网络700是可用的。
作为另一个例子，图8示出了DASH客户端802、回放应用804、HTTP 重定向器/代理818、控制器814、MSDC 808、MBMS发送单元820和策略数据库816。这些组件可以基本上与图1和/或图7的类似名称的组件对应。通常，图8的技术被讨论为利用DASH(其反过来利用HTTP)，但应该理解的是，也可以使用其他流式传输协议。例如，以下关于RTP/RTSP 来讨论可替代的例子。
最初，可以将策略信息提供给包括DASH客户端802、回放应用804、 HTTP重定向器/代理818、控制器814和MSDC 808的系统。这种策略信息可以存储在策略数据库816中(830)。该策略信息可能影响控制器814 的动作。控制器814可以以硬件、软件、固件或其任意组合来实现。推测，当以软件和/或固件实现时，还可能提供必需的硬件，例如一个或多个基于硬件的处理单元，其用于执行对应于控制器814的软件的指令。
最初，回放应用804可以提供识别信息，例如用于识别代理端点(例如，主机名称或地、协议以及协议端口号)的信息(832)。该信息可以由可选的配置应用来提供。DASH客户端802可以配置具有识别信息(834)。
在图8的例子中，一个以上的传输可能是可用的，并且各种媒体(例如，在文件中)可能在各种传输上在不同的时间是可用的。考虑，例如 eMBMS和DVB传输是可用的。进一步考虑使用应用服务描述来表示可用的媒体文件。每个传输可以具有相应的模块，所述模块能够获取媒体信息的列表和细节，并产生汇总URI或公共URI前缀，如由图1的传输模块110A-110R所示出的。在图8的例子中仅示出了MSDC 808，但应该理解的是，MSDC 808可以包括多个各自的传输模块。这些模块经由通信机制(例如，IPC、API或协议)向控制器814传输文件信息，所述控制器 814可以应用策略和分辨率，而这反过来使得重定向器/代理受策略影响。图8仅示出了针对MBMS(限制杂波)的部分。MBMS rX 820可能会收到USD(836)，并向MSDC 808解析/传递USD(838)。
MSDC 808将USD特定的信息处理为非传输特定的形式并将结果传送给控制器814(840)。控制器814随后可以处理文件可用性列表与访问策略以生成一组映射(842)。该映射指示哪些URI(或URI前缀)应该被重新定向到哪个实例化的服务器(例如，在MBMS上可用的文件可能从服务器812是可用的，其在MSDC中实例化或者与MSDC相关联)。换句话说，HTTP重定向器/代理818可以获取映射信息，所述映射信息基于用于取回媒体数据的服务，将针对媒体数据的标识符映射到资源位置，其中，所述服务定义了用于传输媒体数据的多种类型的传输(例如，广播、单播或者多播)中的至少一种。例如，在MSDC 808可以接收数据的情况下，服务可以限定用于传输媒体数据的广播或多播传输类型。MSDC 808可以将接收到的媒体数据存储在高速缓存器810中，以用于后续由例如DASH 客户端802取回，如下面所讨论的。
一旦被调用，DASH客户端802可以经由配置的代理地址(向HTTP 重定向器/代理818)发出HTTP请求，以获得MPD内容(844)。同样地， HTTP重定向器/代理818可以接收来自DASH客户端802的HTTP请求。 HTTP请求可以是针对媒体数据的请求。HTTP重定向器/代理818可以执行匹配算法来确定匹配标准，或者，如果没有匹配发生，则确定另一个指示符(例如，默认重定向目标、错误指示或原始请求的复本)。因此，使用关于映射信息的匹配标准，HTTP重定向器/代理818可以确定具体服务是可用的，例如，定义广播或多播以用于传送所请求的媒体数据的服务。随后，HTTP重定向器/代理818可以基于匹配算法，使用HTTP向DASH客户端802提供重新定向目标或错误(846)。
已经观察到指示重定向的HTTP代码(例如，3xx类型HTTP代码) 的DASH客户端802，可以取决于代码类型来进行响应。对于除了300的类型，HTTP“位置：”头部可以指示针对资源的可替代位置。当接收到这种指示时，DASH客户端802可以使用所指示的备用位置重新尝试其请求。在这个例子中，HTTP重定向器/代理818可以指示特定的URI应定向至集成在MSDC808内的服务器，DASH客户端802可以从该服务器获得MPD (848)。
一旦DASH客户端802已经获得了MPD信息，DASH客户端802可确定要访问什么媒体文件(例如，在MPEG-DASH的情况下，哪个“代表”)，并发出一个或多个基于HTTP的请求以取回所确定的媒体文件 (852)。使用上述机制，HTTP重定向器/代理818向DASH客户端802 提供重定向的目标(854)。该目标可以是默认值、请求的副本(指示客户端应该处理该请求)或对不同的服务器的引用。该目标随后作为由DASH 客户端802使用的位置以例如从MSDC 808获得媒体片段(856)。以这种方式，当服务定义了例如用于输送媒体的广播或多播是可用的时，HTTP 重定向器/代理818可以使得DASH客户端802从单元接收所请求的媒体数据(例如，MSDC 808)，所述单元使用服务从在映射信息中指示的资源位置接收媒体数据。可替代地，重定向目标可以对应于经由某些网络(包括互联网806)可用的网络位置。
在一些情况下，从客户端请求的URI(步骤844/852)对HTTP重定向器/代理818来说可能是未知的。在这种情况下，可以生成错误(例如， HTTP代码404)，以指示DASH客户端802：DASH客户端802应该尝试请求不同的段，或改变而不使用HTTP重定向器/代理818(即，取代于使用直接网络或互联网访问请求)。可替代的，HTTP重定向器/代理818可以使用相当于传入请求的位置：头部，以暗示非代理操作。一个进一步变型将包括HTTP重定向器/代理818充当常规web代理，在这种情况下， HTTP重定向器/代理818可以代表DASH客户802访问互联网806。
以这种方式，图8的技术表示一种方法的例子，所述方法包括：由代理单元(例如，HTTP重定向器/代理818)进行以下操作：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输(例如，广播、多播或单播)中的至少一个；从应用服务客户端(例如，DASH客户端802)接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
此外，如果资源位置对应于网络位置(例如，在互联网806中的位置上或经由互联网806可访问的位置)，则HTTP重定向器/代理818可以被配置为确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配，并且当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据匹配时，向所述应用服务客户端发送重定向消息，以使得所述应用服务客户端从所述网络位置取回所述媒体数据，其中所述重定向消息在所述映射信息中指定针对所述媒体数据的所述标识符映射到的所述网络位置。
同样地，HTTP重定向器/代理818表示代理单元的例子，所述代理单元被配置为获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输(例如，广播、多播或单播)中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
图9和图10是示出了用于支持RTP/RTSP流式传输的示例性MSDC 架构。图9示出了不具有TSB特征的架构，而图10示出了支持TSB的架构。在这些例子中，TSB将在中间件中保持。编号的箭头表示从网络层到中间件并最终到RTSP/RTP客户端的数据流。特别是，由LTE调制解调器接收到的数据被提供给支持多播(或广播)的IP堆栈。IP堆栈向MSDC 中间件的实时传输协议(RTP)功能单元提供所接收的数据(901)，所述 RTP功能单元对数据执行前向纠错(FEC)处理。该数据然后被提供回IP 堆栈(902)。IP堆栈然后将数据提供给RTP客户端(903)。
在图10的例子中，MSDC 1010可以支持TSB 1012。因此，在图10 的例子中，由LTE调制解调器接收到的数据被提供给支持多播(或广播) 的IP堆栈。IP堆栈向MSDC 1010的实时传输协议(RTP)功能单元提供所接收的数据(1001)，所述RTP功能单元对数据执行前向纠错(FEC) 处理。然后，将数据缓存在时移缓存器(TSB)1012中(1002)。IP堆栈随后可以在适当的时间从TSB 1012(1003)接收该数据，并将该数据提供给RTP客户端(1004)
此外，如下面更详细描述的，MSDC 1010可以接收包含属性的SDP 消息，所述属性定义针对图10的时移缓存器(TSB)的TSB深度。MSDC 1010可以基于如在SDP消息中以信号形式发送的、属性的值，确定用于 TSB 1012的存储器的量。例如，该属性的值可以限定TSB的长度，例如，关于针对要存储在TSB 1012中的媒体数据的回放秒数。因此，MSDC 1010 可以基于例如针对要接收的媒体数据的视频数据的帧速率以及基于要潜在地缓存在TSB 1012中的回放秒数，确定将被分配以形成TSB的存储器的量。MSDC 1010随后可以为TSB 1012分配所确定的存储器的量，并在 TSB 1012中存储与SDP消息相关联的接收到的媒体数据的至少一部分。
为了以信号形式表示TSB深度，也可以使用本公开内容的技术来利用SDP的扩展机制。SDP“a＝”(属性)行可以用于提供对一般会话描述的扩展。下面的语义可被用于以信号形式表示有关TSB的数据，作为一个例子：
TSB-attribute＝“a＝tsb-length:”Value
Value＝token
Value will have seconds as unit
作为一个例子，接下来在表1中提到的SDP片段描述了针对TSB的数据。在这个例子中的缓存器深度是60秒，或1分钟。这意味着MSDC (例如，图10中示出的MSDC的TSB)将保持在其时移缓存器中等于一分钟的媒体内容。根据本公开内容的技术，带下划线的文本表示以形式“a＝”行的、关于TSB的示例性属性。
表1
当在SDP中提供了针对所述TSB的数据时，所述MSDC可以分配在 SDP中提到的大小的等同量的缓存器，并且可允许RTSP/RTP客户端关于缓存的时段来快进或倒带回放。
用于实现传输分集的一个示例性技术是基于由Fall等人于2013年1 月5日递交的美国临时申请序列No.61/752,456所提出的解决方案，“ARCHITECTURE SUPPORTINGTRANSPORT DIVERSITY，”代理机构案号131286P1(以下将称为“Fall临时申请”)。Fall临时申请提出了用于支持分集传输协议的通用客户端架构。本公开内容的用于支持RTP中的传输分集的技术可以被用于扩展Fall临时申请，其涉及内容的基于DASH 的传递。
不同于DASH协议，在媒体表达描述(MPD)中的媒体表示可能会基于传输分集方法而改变，RTP协议通常没有办法经由单个SDP简档来直接区分传输分集。本公开内容描述了用以实现传输分集的示例性技术。
作为一个例子，服务eMBMS广播服务限定允许机制在单播和广播传输机制之间进行选择。例如，在eMBMS服务定义模式中的deliveryMethod 元素可以包含描述了广播递送会话的SDP简档，而 AlternativeAccessDelivery元素可能包含对针对单播访问的RTSPURL的引用，或包含PSS SDP文件，其表示单播SDP会话信息。当UE处于广播网络覆盖范围下时，eMBMS中间件可以使用广播SDP会话信息来消耗广播内容。否则，该中间件可以通过连接到AlternateAccessDelivery中的 unicastAccessURI来传递内容。该eMBMS用户服务描述(USD)模式片段的例子在图11中示出。
对携带广播SDP和单播访问URI的deliveryMethod的可替代例子具有统一的单个SDP，其在不同的媒体流中包含单播和广播会话描述二者。因为SDP中的任何会话描述可以包含多个媒体流定义(例如，一个用于音频轨，而另一个用于视频轨)，可以使用机制来将广播和单播媒体流组合成不同的集合，以提供统一的SDP简档。这可以通过在SDP中分组方法来实现。分组机制的例子描述如下
Media stream identification
a)Identifies media streams within groups
b)Media-attribute＝“a＝mid:”Identification-tag
c)Identification-tag＝token
Group attribute
d)Identifies unicast/broadcast media streams
e)Group-attribute＝“a＝group:”Semantics(identification-tag)*
f)Semantics＝“BROADCAST”|“UNICAST”
表2中的下列片段提供了例子，在所述例子中，提供了针对组和媒体流标识符属性的值。在下面的例子中，“a＝group：”行表示哪些媒体流用于广播和哪些媒体流用于单播。在该例子中，广播媒体流分别由“a＝mid：”值1和2表示，而单播分别由“a＝mid：”值3和4来表示。因此，中间件可以连接到IP地址224.1.1.2和用于广播内容的端口30000和30002，以及连接到IP地址131.10.1.2和用于单播流的端口26890和26892。
表2
以这种方式，图10示出了一种设备的例子，所述设备包括被配置为接收会话描述协议(SDP)消息的一个或多个处理器，所述SDP)消息包括限定了时移缓存器(TSB)的深度的属性，基于所述属性的值来确定用于TSB的存储器的量，向TSB分配所确定的量的存储器，以及在TSB中存储与SDP消息相关联的媒体数据的至少一部分。
图12和13是示出了用于针对RTSP/RTP客户端支持传输分集的示例性组件的框图。无论eMBMS USD中的传递方法被用于在广播和单播传输之间进行区分，还是使用统一单个SDP机制，本公开内容的技术可以提供由RTSP/RTP客户端进行的无缝内容获取。为了实现这个目标，如在Fall 临时申请中提出的，可能在eMBMS中间件(也称为多播服务设备客户端(MSDC))之外，策略管理器、控制器和RTSP重定向器/代理可以保持在UE中。当RTSP客户端请求SDP时，RTSP重定向器/代理总会提供SDP 简档，其携带本地主机(例如IP版本4，地址127.0.0.1)作为连接端点地址。方法是，无论该RTSP重定向器/代理是经由eMBMS中间件(用于广播)还是单播RTSP服务器(用于单播)接收内容，其总是从本地主机内容向RTSP/RTP客户端服务内容。因此，客户端不知道传输机制的分集。下面我们提供的架构的主要组件的简要说明，并给出了如何将内容递送至客户端的例子。
在图12和13的例子中，回放应用是尝试消耗流媒体内容的应用； RTSP/RTP客户端是针对客户端行为实现RTP协议的客户端；eMBMS中间件是实现eMBMS(或MBMS)广播服务发现(用于流是传输或文件下载)并经由广播LTE网络消耗流式传输或文件传递内容的中间件架构；策略管理器维护如上面所讨论的数据库；控制器是从策略管理器获取策略信息以及从eMBMS中间件获取和eMBMS广播覆盖指示并且向RTSP重定向器/代理提供映射、陈述要从(单播或广播)选择哪些SDP简档的组价；而RTSP重定向器/代理是从控制器接收映射信息，并取决于该映射从 eMBMS中间件收集RTP内容(在UE在广播覆盖范围中的情况下)或连接到单播RTSP URI并经由单播传输来接收内容的代理单元，其可以随后传递到RTSP/RTP客户端。
图12表示用于RTP内容的广播递送的示例性过程。图12包括 RTSP/RTP客户端1202、回放应用1204、RTSP重定向器/代理1218、控制器1214、eMBMS中间件(也称为MSDC)1208、策略管理器1216和广播传输单元(也被称为eMBMS rX)1220。图12还描绘了长期演进(LTE) 无线接入网络(RAN)1206。LTE RAN 1206提供MBMS服务，其限定了用于媒体数据的多种类型的传输(例如，广播、多播或单播)中的至少一个。因此，当MSDC 1208在由LTE RAN1206提供的覆盖的服务区域中时，MSDC 1208可以经由LTE RAN 1206使用广播或多播传输来接收媒体数据。此外，MSDC 1208实现服务器1212，所述服务器1212包括高速缓存器1210。以这种方式，MSDC 1208既可以用作接收媒体数据的客户端又能作为向例如RTSP/RTP客户端1202提供数据的服务器。另外， RTSP/RTP客户端1202可以从例如MSDC 1208或RTSP重定向器/代理 1218取回媒体数据，并且随后向回放应用1204提供所述媒体数据。
回放应用1204可以基本上对应于应用101(图1)，而RTSP/RTP客户端1202可以基本上对应于应用服务客户端102(图1)。同样，MSDC 1208 可以基本上对应于传输中间件110(图1)。控制器1214可以基本上对应于控制器106(图1)。RTSP重定向器/代理1218可以基本上对应于重定向器/代理104(图1)。
在这个例子中，策略管理器被提供具有策略(1230)。所述eMBMS 中间件(或MSDC)1208接收针对eMBMS服务列表的USD描述(1232、 1234)。所述MSDC 1208随后将针对RTP流式传输服务的SDP简档信息和广播覆盖通知传递给控制器1214(1236)，而控制器1214将SDP信息与策略列表进行匹配，并将映射信息提供给RTSP重定向器代理1218 (1238)。映射信息包含数据，所述数据指示针对每个场景(广播或单播覆盖)，要使用哪个SDP简档连接端点。以这种方式，RTSP重定向器可以获取映射信息，所述映射信息将针对所述媒体数据的标识符映射到资源位置。所述资源位置可以对应于网络地址，例如，经由LTE RAN 1206可用的地址。所述服务定义用于传输媒体数据的多个类型的传输中的至少一个，例如广播或多播。
同时，MSDC 1208将服务列表传递给回放应用1204(1240)。回放应用1204可以对应于应用101(图1)。该回放应用1204随后将RTSP URI (被提供具有来自MSDC的服务列表)和代理地址传递给RTSP/RTP客户端1202(1242)。当RTSP/RTP 1202客户端调用DESCRIBE命令时(RTSP 定义的命令)(1244)，RTSP重定向器/代理1218提供重定向至本地服务器的修改的SDP消息(1246)。该RTSP/RTP客户端1202解析SDP信息(1248)，并调用SETUP命令(RTSP命令)，以与本地服务器建立RTP 会话。当与服务器建立成功时，该RTSP/RTP客户端1202还传递播放命令(1250)。RTSP重定向器/代理1218向RTSP/RTP客户端1202提供了对 SETUP和PLAY请求的成功消息(1252)。由RTSP重定向器/代理1218 从RTSP/RTP客户端1202接收到的SETUP和PLAY命令表示针对媒体数据的请求的例子。另外，RTSP重定向器/代理1218向MSDC1208发送 SETUP和PLAY命令(1251)。
RTSP重定向器/代理1218可以确定用于取回媒体数据的服务是否是可用的，例如，将广播或多播定义作为传输的服务是否是可用的。RTSP 重定向器/代理1218可以至少部分地基于RTSP重定向器/代理1218或 MSDC 1208是否是在服务覆盖区域内，来确定服务是否是可用的。图12 的技术假定服务是可用的。如以下更详细讨论的，图13描述了当服务不可用时可以使用的额外技术。
同时，在流式传输服务的活动广播会话期间，网络运营商在LTE RAN 1206上发送RTP内容(1254)。MSDC针对来自广播连接端点(在图12 中标记为eMBMS rX 1220)的服务收集RTP内容(1256)，处理该内容(如果需要的话)，并在与RTSP重定向器/代理的SETUP命令期间，在由客户端指定的端点处将内容传递给RTSP/RTP客户端1202(1258)。以这种方式，当服务是可用的(例如，限定广播或多播传输的服务)时，RTSP重定向器/代理1218使得RTSP/RTP客户端1202从MSDC 1208接收媒体数据(即，使用服务从资源位置例如经由LTE RAN 1206接收媒体数据的单元)。特别是，在本例子中，MSDC 1208基于映射信息(例如，上述的 USD数据)经由LTE RAN 1206接收来自网络位置的媒体数据，该映射信息将服务映射到这个位置。
以这种方式，图12的技术表示了一种方法的例子，所述方法包括：由代理单元(例如，RTSP重定向器/代理1218)进行以下操作：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输(例如，广播、多播或单播)中的至少一个；从应用服务客户端(例如，RTSP/RTP 1202)接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。在这个例子中，接收媒体数据的单元对应于MSDC 1208。
图13表示用于RTP内容的单播递送的示例性过程。在本例子中，步骤1232-1248与关于图12所描述的内容的广播递送是基本相同的。然而，在这种情况下，当RTSP/RTP客户端调用SETUP和PLAY命令(1310) 时，RTSP重定向器/代理1218经由RAN/互联网1302从映射信息接触单播RTSP服务器(1312)，从单播RTSP服务器取回内容(1314)，并在SETUP 命令期间或在步骤1246处SDP中公布的那些期间将该内容传递给由 RTSP/RTP客户端1202所提到的端点。因此，在这种情况下，RTSP重定向器/代理1218(其可以存在于用户设备中，所述用户设备还包括 RTSP/RTP客户端1202)充当远程RTSP服务器的客户端，并代表RTSP/RTP 客户端来取回内容。
以这种方式，本公开内容的技术可以使用SDP扩展机制(属性)，以针对RTP内容的eMBMS广播传递提供TSB指示。本公开内容还定义了用以支持广播和单播传输之间的无缝转换的示例性架构，以及在UE内提供RTP媒体内容递送机制。此外，本公开内容描述了一种用于在SDP消息中针对内容的单播和广播递送而将多个基于RTP的媒体流分组的技术。
RTSP重定向器/代理1218表示了代理单元的例子，所述代理单元可被配置为进行以下操作：获取映射信息，所述映射信息基于用于取回所述媒体数据的服务，将针对所述媒体数据的标识符映射到资源位置，其中，所述服务定义用于传输所述媒体数据的多个类型的传输(例如，广播、多播或单播)中的至少一个；从应用服务客户端接收针对所述媒体数据的请求；确定所述服务是否是可用的；以及当所述服务是可用的时，使得所述应用服务客户端从单元接收所述媒体数据，所述单元基于所述映射信息，使用所述服务从所述资源位置接收所述媒体数据。
图14A和14B是示出了用于扩展USD以携带DASH传输信息的示例性XML内容模型的概念图。被圈的A表示图14A和14B之间的连接在此处接合的点。可以单独使用XML内容模型或结合任何上述技术来使用。图1、2A、2B、6、7和/或8的组件可以被配置为利用关于图14A和14B 所描述的XML内容模型。如上所述，本公开内容的技术包括的用在于单播和广播传输模式之间进行选择的技术。图14B示出了用于限定广播表示 (在USD中的broadcast元素)和单播表示(在USD中的unicast元素) 的数据。
根据本公开内容的某些技术，应用服务客户端，如DASH客户端(例如，图1、2A、2B、6、7和/或8的DASH客户端)可以作出对从哪个表示来取回段的初始选择。特别是，DASH客户端可以做出这种初始选择，而其余的不可知该请求的段所属于的表示的传输模式(广播和/或单播)。出于示例的目的，假设，HTTP由DASH客户端用于请求所选择的表示的段，以及图14B中所示的扩展的USD用于携带DASH传输信息。一个或多个广播表示中的每一个在USD中由broadcast元素的唯一baseUrl属性来识别。
Broadcast的每个实例映射到MBMS承载上所传递的唯一表示。其 baseURL时将与由DASH客户端所使用的、段URL的一部分作比较，以请求段，具体而言，所述段URL的一部分是段URI的初始部分，其从URI 方案开始，并延伸至并包括该段所属于的表示的标识符，以确定所述表示是否正被请求。
例如，假定由DASH客户端发出的段URL是“http://example.com/per-3/rep-512/seg-99.3gp”，其对应于时段3(Period@id ＝‘3’)中的表示512(Representation@id＝‘512’)的段99。出于与USD中的basesURL匹配的目的，要考虑的该URI的部分是“http://example.com/per-3/rep-512。在该表示在广播上也是可用的情况下， mediaPresentationDescription2.broadcast的实例将存在于USD中，具有由“http://example.com/per-3/rep-512”给出baseURL，其与请求URL中的感兴趣部分相同。例如，该请求URL中的感兴趣部分与USD的broadcast 元素的baseURL属性的匹配表示请求的段所属于的表示的广播传输。
类似地，在该例子中，零个或多个单播表示中的每个在USD中由 mediaPresentationDescription2.unicast元素的唯一baseUrl属性识别。如上所讨论的，在请求的URL的相同部分与单播baseURL的匹配模式时意味着该表示在单播传递上是可用的。同一表示可能在两个传输模式都是可用的、在仅一个传输模式上是可用的或两个传输模式上都不是可用的。
DASH客户端提交段向其请求的实体可以是代理单元(或提交给 MBMS或eMBMS客户端)。出于示例的目的，以下将代理单元描述为执行这些技术，但应理解的是，例如图1、2A、2B、6、7和/或8的MBMS 或eMBMS可以被配置为执行归因于代理单元的技术，如下所述。通过使用针对请求URL的感兴趣的部分与USD中的broadcast和unicast元素的 baseURL值之间的模式匹配，代理单元可以确定所选择的传输模式是否是可用的和/或比另一传输模式优选。
代理单元可以取回指示各种传输类型之间的偏好的策略。例如，该策略可以指示，如果请求是用于在单播上传递的表示，只要该装置位于广播覆盖范围内，仅广播传递的表示对DASH客户端是应当可访问的。虽然在不同的传输模式上传递，但如果baseURL在USD的identicalContent元素中出现，并且可以针对被请求的表示而被取代，则这种广播表示可能与原始所请求的是同一表示。
或者，广播表示可以是已知在广播上传递的可替代表示，并且被认为是可切换的表示，这是由于针对可替代表示的baseURL出现在USD元素 switchableContent的条目列表中。在这种情况下，代理单元可以将消息发送回DASH客户端，以使得DASH客户端请求属于在广播上传送的可替代表示的同一个段。例如，代理单元可以发送300类型的HTTP响应消息给DASH客户端，其对应于重定向消息，并且所述重定向消息可以指定对应于来自包含在switchableContent的列表中的可替代表示的资源URL。
作为另一例子，如果DASH客户端请求代理单元已知要在广播上传递的段，但广播接收不可用(例如，由于客户端设备处于广播覆盖区域之外)，则代理单元可以发送300类型的HTTP响应消息，其包括对应于同一单播传输的段的URL，或者如果该同一表示在单播传输上是不可用的但显示为 switchableContent中的条目，则对应于不同的表示。
作为另一例子，如果DASH客户端请求已知为代理单元要在广播上传递的段，但广播接收可用，则代理单元将请求代理到本地内容高速缓存器，并将所取回的段传递回DASH客户端。
可选地，代理单元可以用400类型错误消息来进行响应，这可能会导致DASH客户端使用不同的段URL来重新提交请求。代理单元还可以以其他方式来传输不同的传输协议，例如，经由应用编程接口(API)、进程间通信(IPC)，发送省略所选择的基URL的修改的MPD等等。
来自代理单元的重定向或错误消息可能会使得DASH客户端选择不同的传输模式。在一些例子中，在重定向的传输模式上一个以上的表示可能是可用的，在这种情况下，DASH客户端可能从那些可用的表示中的一个进行选择。作为一个例子，如果DASH客户端曾尝试选择广播表示(如由图14A和14B的broadcast元素的实例所给出的)，但代理单元确定广播接收是不可用的，则代理单元可以向DASH客户端发送消息(例如，经由IPC通信等的300类型重定向消息、400类型错误消息、API调用)，以使得DASH客户端代替地选择图14A和14B的单播表示。
在一些实例中，应用服务客户端，如DASH客户端，可以负责管理单播广播转换。作为例子，本公开内容关于图14A和图14B描述了用于利用额外的参数来扩展USD的架构，在MBMS上的DASH下载传递的情况下，使得MBMS客户端能够确定来自DASH客户段的请求是否可以作为、是或仅是来自一个或多个可替代表示。USD可以指示媒体表达描述 (MPD)中指定的每个表示的传输模式(仅广播、仅单播，还是广播和单播二者)。以下描述了用于确定表示可用性的规则和机制的示例性场景。
在一个例子中，用户设备(UE)可以位于MBMS覆盖区域内，并且 DASH客户端可以请求该USD指示是经由广播传递不可用的、特定的表示。服务提供商策略可以指示，当UE处于MBMS覆盖中时，仅同一节目的广播传递的表示是可以被访问的。在这种情况下，DASH客户端可能被限制为从通过广播传递可用的备选的表示中进行选择(或重定向或被指示选择)。
在另一个例子中，UE可能位于MBMS覆盖内，并且DASH客户端可以请求已知为在多播传递上可用的表示。在这种情况下，所期望的表示可以由UE直接访问。
在另一个例子中，UE可能位于MBMS接收区域之外，并且DASH 客户端可以请求已知为仅在广播传递上可用的表示。在这种情况下，DASH 客户端可以被限制为从以可切换内容的形式的、在单播传递上可用的备选的表示中进行选择(或重定向或被指示选择)。
在另一个例子中，UE可能位于MBMS接收区域之外，并且DASH 客户端可以请求也已知为在广播传递上可用的表示。在这种情况下，DASH 客户端可能能够在单播上接收以完全相同的内容的形式的、同一表示。
可以在USD中携带的额外信息包括对服务区域的指示，在其上，每个表示被输送，和/或包括SDP的标识，所述SDP描述携带所述表示的 FLUTE会话。
本公开内容描述了一种技术，通过所述技术，可以将mediaPresentationDescription2子元素添加在userServiceDescription之下，以携带额外的传输参数。此前，提议了MPD-特定参数，如包含在 mediaPresentationDescription2中的时段ID、适应集ID和Representatation ID，其可以识别在单播传递上可用的那些表示。这些相同的参数，连同对会话描述片段的URI引用，可以识别能够在广播上传递的每个表示，以及到携带该表示的段的、FLUTE会话的映射。
该本公开内容的技术可以克服的一个问题是使得能够使用HTTP/1.1 作为DASH客户端和MBMS客户端之间的协议接口以用于段请求/响应，同时在协议处理中维持干净的分层分离。例如，在以前的技术中，MBMS 客户端必须处理MPD-特定信息，所述MPD-特定信息能够将针对特定表示的段的DASH客户端请求纠正为实际可用的、由传输模式(广播或单播)所准许(例如，根据服务提供商策略)的表示段。在所请求的表示不能被提供的情况下，为了使MBMS客户端使用HTTP重定向(经由3xx响应代码，如在1999年6月Fielding等人“Hypertext Transfer Protocol– HTTP/1.1”，网络工作组RFC 2616中定义的，其在http://www.ietf.org/rfc/rfc2616.txt可获取)以通知DASH客户端一个或多个可替代表示，该MBMS客户端将不得不针对每个可替代资源构成完整的段URI。关于MBMS客户端部分的分层冲突可以通过使用本公开内容的技术来消除。
本公开内容的技术省略了MBMS客户端(或代理单元)要知道或必须处理(DASH特定)MPD信息的必要。该MBMS客户端基于USD中的新的元数据的出现以及与由DASH客户端生成的段请求URI，仅执行数据/模式匹配，来确定所请求的段是在广播上可用、单播上可用、两种传输模式上都可用或都不可用，或通过一些其它方式(例如，高速缓存存储器)可用。这是可能的，因为USD中还提供了唯一地标识所请求的段属于的表示的、请求URI的部分。此外，MBMS客户端可以通过USD中的匹配数据模式的位置，来确定由DASH客户端(其对传输模式是不可知的) 请求的表示是在广播、单播，两种传输模式上都或都不可用，或通过一些其它方式(例如，高速缓存存储器)可用。与任何其他有关规则和条件，例如覆盖状况(UE是在单播和/或广播服务区域)，服务提供商策略等相结合，并基于USD属性replacementAllowed＝'真'，假设用于返回可替代资源URI替代方法是允许的。该MBMS客户端可以使用HTTP/1.1机制来将段请求调解给适当的资源，例如UE中的本地内容高速缓存器，或外部 HTTP服务器，而不具有经协议分层冲突。
如在图14A和14B的例子中可以看出，所述一个或多个广播代表中的每个在USD中由broadcast元素的唯一baseUrl属性识别。baseURL值可能与DASH客户端用于请求表示的段的段URI是相同的，具体而言，与该段URI的起始部分是相同的，其从该方法开始，并延伸至并且包括该 RepresentationID。例如，如果该段的URI是URL “http://example.com/per-3/rep-512/seg-99.3gp，”对应于时段3中的表示512 (RepresentationID＝512)的段99，则baseURL可以被定义为“http://example.com/per-3/rep-512”。
在本例子中，所述一个或多个广播代表中的每个在USD中由 broadcast元素的唯一baseUrl属性识别。Broadcast的每个实例映射至在 MBMS承载上传递的唯一的表示。其baseUrl将与DASH客户端用于请求段的段URI进行比较，具体而言，与该段URI的起始部分进行比较，其从URI方案开始，并延伸至并且包括该Representation-ID(MPD中的Representation@id的值)。例如，假设DASH客户端发出的段URI是URL “http://example.com/per-3/rep-512/seg-99.3gp”，对应于针对时段3 (Period@id＝3”)中的表示512(Representation@id＝512)的段99的请求。出于与USD匹配的目的，所关心的该URL的部分是“http://example.com/per-3/rep-512。在该表示在广播上也是可用的情况下， mediaPresentationDescription2.broadcast的实例将在USD中具有由“http://example.com/per-3/rep-512”给出baseURL，其与请求URI的感兴趣部分是相同的。
在MBMS客户端确定了DASH客户端所请求的、仅可替代表示是可用的情况下，mediaPresentationDescription2的replacementAllowed属性可以指示MBMS客户端是否以及如何经由HTTP重定向(3xx状态码)方法向DASH客户端提供这种通知，如在RFC2616中定义的。
例如，如果replacementAllowed＝“真”，可以假定DASH内容和MPD 以这种方式被撰写：允许MBMS客户端经由“303见其他”重定向来向 DASH客户提供可替代资源URI，而不考虑可替代表示的传输模式。具体地，每个可替代URI可能是通过替换段URL中的感兴趣部分来形成的，如以上利用对应于可替代表示的USD中的baseURL来描述的，而同时在原始请求中保留段号。
另一方面，如果replacementAllowed＝“假”，则用于生成可替代资源 URI并将其提供给DASH客户端的这种替换方法是不允许的。导致要被请求和传递的可替代表示的、所产生的技术可能是依赖于实现的(例如， MBMS客户端可能会返回伴随有或没有可替代表示的4xx错误代码，其是由baseURL值以信号形式发送的，并依赖于DASH客户端来形成可替代请求)。下面关于图15和16，基于HTTP'303'重定向描述了示例性调用流程，示出了MBMS客户端和DASH客户端之间的交互。
类似地，零个或多个单播表示中的每个在USD中由 mediaPresentationDescription2.unicast元素的唯一baseUrl属性识别。如上所讨论的，在请求的URL的相同部分与单播baseURL的匹配模式意味着该表示在单播传递上是可用的。要注意的是，同一表示可以在两个传输模式都是可用的、在仅一个传输模式上是可用的或两个传输模式上都不是可用的。
另外，经由sessionDescription元素，每个广播表示可以链接到会话描述片段或涉及携带所述表示的FLUTE会话的SDP文件。此外，serviceArea 元素(如果存在的话)，可以指示广播表示在其上可用的MBMS服务区域。
图15是示出了用于支持MBMS上的DASH的架构的概念图。图15 的例子表示用于MBMS承载上的具有单播回退的DASH内容传递的端到端网络架构。基于FLUTE的下载传递表示BM-SC和MBMS客户端之间的TS26.346定义的接口。DASH客户端和MBMS客户端之间的假定接口 (这里假定为包括MBMS接收机、基于设备的HTTP服务器、策略、重定向和代理功能的复合实体)是HTTP/1.1。
图16是示出了与图15的网络架构相关联的、用于广播和单播传输上的DASH内容传送的呼叫流程。相对于图16所描述的技术基于图14A和 14B中所示出的USD扩展以用于携带DASH传输信息。虽然被描述为对应于图15的网络架构，但应该理解的是，图16的技术可以由其它设备来执行，所述其他设备例如图1、2A、2B、6、7、8和/或17的架构中的设备。在图16的例子中，假定USD包含表3中所示的信息，其在 mediaPresentationDescription2.broadcast和 mediaPresentationDescription2.unicas之下包括baseURL属性的值，并且假设USD中的replacementAllowed属性的值为“真”。
表3
此外，在该例子中，假定MPD包括以下内容：
·MPD@type＝‘dynamic’
·Period@id＝‘3’
·Period.SegmentTemplate@media＝
‘http://example.com/per-3/rep-$RepresentationID$/seg-$Number$.3gp’
ο Representation@id＝‘512’…
ο Representation@id＝‘256’…
ο Representation@id＝‘128’…
给定这些示例性MPD参数值，尝试请求针对Period 3中的表示512 的段no.99的DASH客户端可以发布以下请求URI： http://example.com/per-3/rep-512/seg-99.3gp。图16的呼叫流程图描述了针对两种不同情况的DASH内容传递：(1)UE位于MBMS覆盖区域，并且请求Period 3中的表示512的段，其在广播传送上时可用的，以及随后，(2)UE移出MBMS区域，并且继续请求同一表示(Representation 512)，其在单播传送上时不可用的，但表示256和128在单播上是可用的。
换句话说，本公开内容描述了某些技术，所述技术用于支持传输分集的DASH传输的基于USD的信令的使用。其可以在从高通公司的“Rationale for USD Indication ofDASH Delivery Mode and Illustrative Implementation”Tdoc S4-130051中描述的先前提议上提供一个或多个改进。例如，在该方法中，可以完全避免分层冲突，这是因为MBMS客户端不必理解或处理MPD信息。相反，MBMS客户端可以针对由DASH客户端所请求的段的URI来执行已知传输语义的数据模式匹配，以确定所请求的段是否请求经由广播和/或单播来递送，并且该请求是否满意或者需要被重定向至同一表示或使用另一种传输模式可用的可替代表示。
这种确定可以基于诸如以下因素：UE是位于MBMS覆盖内部还是外部、服务提供商策略(如果有的话)、由传输模式来管理表示的可访问性，以及可能地依赖于其他条件或规则。提供了针对经由MBMS具有单播回退的DASH内容递送的示例性网络架构和呼叫流程图，以说明端到端的内容递送，其以DASH客户端和MBMS客户端之间的HTTP协议接口的使用为特点。坚持分层协议应该提供在支持MBMS服务中的DASH中的、 UE实现的可扩展性和简单性的架构益处。
在具有值为“真”的mediaPresentationDescription2的 replacementAllowed属性上预测了经由3xx状态代码由MBMS客户端使用 HTTP重定向以限制DASH客户端访问可替代资源(表示)。在这种情况下，假设DASH内容和MPD以如下方式被撰写：允许MBMS客户端经由“303见其他”重定向来向DASH客户提供可替代资源URI，而不考虑可替代表示的传输模式。具体地，每个可替代URI是通过替换段URL中的感兴趣部分来形成的，如以上利用对应于可替代可替代表示的USD中的baseURL来描述的，而同时保在原始请求中保留段号。如果replacementAllowed的值＝“假”，则用于生成可替代资源URI并将其提供给DASH客户端的这种替换方法是不允许的。
导致要被请求和传递的可替代表示的所产生的技术可能是依赖于实现的。例如，MBMS客户端可能会返回伴随有或没有可替代表示的4xx 错误代码，其是由HTTP响应的实体主体中的baseURL值以信号形式发送的，并依赖于DASH客户端来形成可替代请求。此处，用于在响应中识别可替代的表示是可用的baseURL的存在可以用作对DASH客户端的提示，其提示DASH客户端具有后续直接请求所述表示的智能。可替代地， baseURL可能不会在4xx响应中提供“提示”，或DASH客户端可能缺乏利用这种提示来生成对另一个表示的新请求的智能，所述另一个表示可以对应于或可以不对应于从该MBMS客户端的角度所允许的表示。
图17是示出了用于支持MBMS上的DASH的示例性架构的概念图。指定BM-SC和eMBMS客户端之间的接口可能是重要的，并且eMBMS 客户端和DASH客户端之间的接口是适当的标准。例如，所述标准可以规定BM-SC和eMBMS客户端之间的接口应当符合TS26.346。所述标准还可以指定，如果DASH客户端和eMBMS客户端来自不同的供应商的话，则eMBMS客户端和DASH客户端之间的接口应当遵循TS26.247。对比图16的例子，图17示出了DASH客户端和eMBMS客户端之间的接口可以遵循TS26.247(其可以是，例如，HTTP/1.1)的例子。图17示出了用以允许MBMS上的DASH回落到单播上的DASH的高级架构。
图18-23是示出了与图17的网络架构相关联的、用于广播和单播传输上的DASH内容传送的流程图。虽然被描述为对应于图17的网络架构，但是应当理解，图18-23的技术可以由其他设备来执行，所述设备例如在图1、2A、2B、6、7、8和/或15的结构中的设备。
关于图18的例子，USD信令可以包括在以下针对eMBMS客户端在表4中示出的数据：
表4
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1＝http://www.cnn.com/512/,RepresentationId＝“512”；
Template＝seg$Number$.3gp,
BaseURL2＝http://www.cnn.com/256/,RepresentationId＝“256”；
Template＝seg$Number$.3gp,
BaseURL3＝http://www.cnn.com/128/,RepresentationId＝“128”；
Template＝seg$Number$.3gp.
在图18所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP重定向功能。
关于图19的例子，USD信令可以包括在以下针对eMBMS客户端在表5中所示出的数据：
表5
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1＝http://www.cnn.com/512/,RepresentationId＝“512”；
Template＝seg$Number$.3gp,
BaseURL2＝http://www.cnn.com/256/,RepresentationId＝“256”；
Template＝seg$Number$.3gp,
BaseURL3＝http://www.cnn.com/128/,RepresentationId＝“128”；
Template＝seg$Number$.3gp.
在图19所示的例子中，假定eMBMS客户端具有HTTP代理功能和 HTTP重定向功能二者。
关于图20的例子，USD信令可以包括在以下针对eMBMS客户端在表6中所示出的数据：
表6
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1.1＝http://www.cnn.com/512/,
BaseURL1.2＝http://localhost/512/,RepresentationId＝“512”；
Template＝seg$Number$.3gp,
BaseURL2＝http://www.cnn.com/256/,RepresentationId＝“256”；
Template＝seg$Number$.3gp,
BaseURL3＝http://www.cnn.com/128/,RepresentationId＝“128”；
Template＝seg$Number$.3gp.
在图20所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP重定向功能。
关于图21的例子，USD信令可以包括在以下针对eMBMS客户端在表7中所示出的数据：
表7
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1＝http://www.cnn.com/；
RepresentationId＝“512”；Template＝$RepresentationId$/seg$Number$.3gp,
RepresentationId＝“256”；Template＝$Representagtion$/seg$Number$.3gp,
RepresentationId＝“128”；Template＝$Representagtion$/seg$Number$.3gp.
在图21所示出的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP重定向功能。
关于图22的例子，USD信令可以包括在以下针对eMBMS客户端在表8中示出的数据：
表8
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1＝http://localhost/512/,RepresentationId＝“512”；
Template＝seg$Number$.3gp,
BaseURL2＝http://www.cnn.com/256/,RepresentationId＝“256”；
Template＝seg$Number$.3gp,
BaseURL3＝http://www.cnn.com/128/,RepresentationId＝”“128”；
Template＝seg$Number$.3gp.
在图22所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP重定向功能。
关于图23的例子，USD信令可以包括在以下针对eMBMS客户端在表9中所示出的数据：
表9
这个例子中的MPD可以指定以下数据，其中BaseURL对应于用于访问段的URL的基部：
BaseURL1＝http://www.cnn.com/1024/,RepresentationId＝“1024”；
Template＝seg$Number$.3gp,
BaseURL2＝http://www.cnn.com/512/,RepresentationId＝“512”；
Template＝seg$Number$.3gp,
BaseURL3＝http://www.cnn.com/256/,RepresentationId＝“256”；
Template＝seg$Number$.3gp,
BaseURL4＝http://www.cnn.com/128/,RepresentationId＝”“128”；
Template＝seg$Number$.3gp.
在图23所示的例子中，假定eMBMS客户端不具有HTTP代理功能，而仅具有HTTP重定向功能。
图24是用于根据本公开内容的技术，示出了用于以信号形式发送关于时移缓存器(TSB)深度的示例性方法的流程图。出于示例的目的，关于图10的组件(例如，MSDC 1010和TSB1012 )来说明图24的方法。然而，应该理解的是，利用时移缓存器的技术可以并入本文所描述的各种系统中的任意系统，例如图1、7、8、9、12、13和/或17中任意图的系统。
初始地，MSDC 1010可以接收会话描述协议(SDP)消息(2400)。 SDP消息可以包括定义了时移缓存器(TSB)的深度的属性。因此，MSDC 1010可以在SDP消息中确定针对所述属性(也称为TSB深度属性)的值 (2402)。TSB的深度属性的值可以限定TSB的深度，例如关于要存储在 TSB中的、媒体数据的回放的秒数。例如，该属性的值可以限定能存储在 TSB中的、以秒为单位的最大回放时间。
因此，MSDC 1010可以根据以信号形式所表示的深度来确定要被分配形成TSB的存储器的量(2404)。例如，假设关于媒体数据的回放时间的秒数以信号形式发送TSB的深度，并假设针对视频数据，以信号形式发送帧速率，则MSDC可以确定要存储在TSB中的视频帧的数量，将其作为帧速率(以每秒帧数来表示)和要存储的媒体数据的秒数的乘积。然后MSDC1010可以基于每帧的平均比特率和帧的数量的乘积来确定用于 TSB的存储器的量。MSDC1010可以使用类似的概念，以确定用于音频数据、定时文本数据等的存储器大小。
MSDC 1010随后可以分配所确定的量的存储器，以形成TSB(2406)。因此，随着MSDC1010接收媒体数据，MSDC 1010可以在TSB中存储 (2408)所接收的媒体数据。回放应用可以使用该缓存的媒体数据用于时移应用，例如，用于在稍后时间进行观看或用于特技模式，例如快进或倒带。当然，所缓存的数据也可以用于基本上实时地重放。
以这种方式，图24的方法表示一种方法的例子，所述方法包括：接收会话描述协议(SDP)消息，所述SDP消息包括定义了时移缓存器(TSB) 深度的属性；基于所述属性的值，确定用于所述TSB的存储器的量；分配所确定量的存储器以形成所述TSB；以及，在所述TSB中存储与所述 SDP消息相关联的至少一部分媒体数据。
本领域技术人员应当理解，信息和信号可以使用任意多种不同的方法和技术来表示。例如，在贯穿上面的描述中可能提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子或者其任意组合来表示。
本领域技术人员还应当明白，结合本文中公开内容所描述的各种示例性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或二者的组合。为了清楚地表示硬件和软件之间的这种可交换性，上面对各种示例性的组件、框、模块、电路和步骤均围绕其功能进行了总体描述。至于这种功能是实现成硬件还是实现成软件，取决于具体的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个具体应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为导致背离本公开内容的保护范围。
在一个或多个例子中，所描述的功能可以在硬件、软件、固件或其任意组合中实现。如果在软件中实现，则可以将这些功能作为一个或多个指令或代码在计算机可读存储介质上进行存储或者传输，并且由基于硬件的处理单元来执行。计算机可读介质可以包括计算机可读存储介质或通信介质，其中计算机可读存储介质对应于诸如数据存储介质的有形介质，通信介质包括例如根据通信协议促进从一个地方向另一个地方传送计算机程序的任何介质。以这种方式，计算机可读介质通常可以对应于(1)非临时性的有形计算机可读存储介质，或(2)通信介质，如例如信号或载波。数据存储介质可以是可以由一个或多个计算机或一个或多个处理器存取以取回指令、代码和/或数据结构以实现本公开内容中所描述的技术的任何可用介质。计算机程序产品可以包括计算机可读介质。
通过示例的方式而不是限制的方式，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、闪存、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质。此外，任何连接可以适当地称为计算机可读介质。例如，如果指令是使用同轴电缆、光纤光缆、双绞线、数字用户线(DSL)或者诸如红外线、无线和微波之类的无线技术从网站、服务器或其它远程源传输的，那么同轴电缆、光纤光缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所述介质的定义中。但是，应当理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它临时性介质，而是相反地，针对非临时性的、有形的存储介质。如本文中所使用的，磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字通用光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。
指令可以由一个或多个处理器来执行，所述一个或多个处理器例如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其它等同的集成或离散逻辑电路。因此，如本文所用的术语“处理器”可以指代任何前述结构或适于实施本文中所描述的技术的任何其它结构。此外，在一些方面，可以在被配置用于编码和解码的专用硬件和/或软件模块中提供本文中所描述的功能或在组合的解码器中并入本文中所描述的功能。此外，所述技术可以在一个或多个电路或逻辑元件中完全实现。
本公开内容的技术可以在各种设备或装置中实现，奥阿虎设备或装置包括无线手持设备、集成电路(IC)或IC集合(例如，芯片组)。本公开内容中描述了各个组件、模块或单元，以强调被配置为执行所公开的技术的设备的功能性方面，但不必需要由不同的硬件单元来实现。相反，如上所述，各种单元可以在编解码器硬件单元中进行组合，或由互操作硬件单元的集合来提供，所述互操作硬件单元的集合包括一个或多个处理器，连同适当的软件和/或固件。
以上阐述的详细描述连同所附附图，旨在作为对各种配置的描述，而不旨在表示本文中所描述的概念可以以其实践的唯一配置。出于提供给对各种概念的透彻理解的目的，详细描述包括特定的细节。但是，对于本领域技术人员来说将显而易见的是，可以在不具有这些特定细节的情况下实践这些概念。在一些实例中，为了避免模糊这些概念，以框图形式示出公知的结构和组件。
描述了各种例子。这些例子和其它例子处于接下来的权利要求书的保护范围之内。

Claims (24)

1.一种取回媒体数据的方法，所述方法包括：
由代理单元进行以下操作：
获取映射信息，所述映射信息将媒体数据的标识符映射到具有所述媒体数据的服务器设备的网络位置，其中，在第一服务可用时，能够经由所述服务器设备提供的所述第一服务访问所述网络位置以用于取回所述媒体数据，其中，所述第一服务将广播或多播中的至少一者定义为用于传输所述媒体数据的传输类型；
从客户端设备的应用服务客户端接收针对所述媒体数据的请求；
确定所述第一服务是否是可用的；
当所述第一服务是可用的时：
使得所述应用服务客户端从中间件单元接收所述媒体数据，所述中间件单元基于所述映射信息，使用所述第一服务从所述网络位置接收所述媒体数据；以及
当所述第一服务是不可用的时：
确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配，其中，所述映射信息包括针对每个潜在匹配的优先级值，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括：选择具有最低优先级值或最高优先级值中的一者的匹配；以及
当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据匹配时，向所述应用服务客户端发送HTTP重定向消息，以使得所述应用服务客户端根据第二服务从所选择的匹配网络位置取回所述媒体数据，其中，所述第二服务将单播定义为用于传输所述媒体数据的传输类型，以及其中，所述HTTP重定向消息指定所述媒体数据的所述标识符在所述映射信息中被映射到的所述网络位置。
2.根据权利要求1所述的方法，还包括，当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据不匹配时，向所述应用服务客户端发送所述HTTP重定向消息，以使得所述应用服务客户端从默认的重定向网络位置取回所述媒体数据，其中所述HTTP重定向消息指定所述默认的重定向网络位置。
3.根据权利要求1所述的方法，还包括：当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据不匹配时，向所述应用服务客户端发送错误消息。
4.根据权利要求1所述的方法，还包括：当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据不匹配时，将所述请求的副本发送回所述应用服务客户端。
5.根据权利要求1所述的方法，还包括：在映射表中存储所述映射信息，其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括确定针对所述媒体数据的标识符是否对应于所述映射表中的条目。
6.根据权利要求1所述的方法，其中，所述映射信息包括被表示为统一资源标识符(URI)前缀的映射标准，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括确定匹配所述请求中指示的所述媒体数据的URI的至少一部分的、所述映射信息的URI前缀。
7.根据权利要求6所述的方法，其中，确定匹配所述请求中指定的所述媒体数据的URI的至少一部分的、所述映射信息的URI前缀包括确定匹配所述请求中指示的所述媒体数据的URI的至少一部分的、所述映射信息的最长URI前缀。
8.根据权利要求6所述的方法，其中，由所述映射标准表示的所述URI前缀对应于定义用于传输媒体数据的传输类型的各个服务，并且其中，所述URI前缀的第一URI前缀定义广播服务，而所述URI前缀的第二URI前缀定义单播服务。
9.根据权利要求1所述的方法，其中，发送所述HTTP重定向消息包括以下操作中的至少一个：向所述应用服务客户端发送进程间通信(IPC)，或者调用所述应用服务客户端的应用编程接口(API)。
10.根据权利要求1所述的方法，其中，所述映射信息包括被表示为正则表达式的映射标准，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括：选择匹配最大数量的字符的正则表达式，所述字符直接匹配所述请求中指示的、针对所述媒体数据的标识符。
11.根据权利要求1所述的方法，其中，所述映射信息包括被表示为正则表达式的映射标准，其中，所述映射信息包括针对每个潜在匹配的优先级值，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括：选择具有最高优先级值的匹配。
12.根据权利要求1所述的方法，其中，所述映射信息包括被表示为正则表达式的映射标准，其中，所述映射信息包括针对每个潜在匹配的优先级值，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括：选择具有最低优先级值的匹配。
13.根据权利要求1所述的方法，其中，确定所述第一服务是否是可用的包括确定所述客户端设备是否位于在其中所述服务器设备提供所述第一服务的服务覆盖区域内。
14.根据权利要求1所述的方法，其中，所述请求符合HTTP动态自适应流媒体(DASH)请求，所述方法还包括：
由所述代理单元执行以下操作：
接收所述DASH请求，其中，所述DASH请求指定所述代理单元的网络地址；
响应于所述DASH请求，取回所述请求中指定的所述媒体数据，并向所述应用服务客户端提供所述媒体数据。
15.一种用于取回媒体数据的设备，所述设备包括代理单元，所述代理单元被配置为进行以下操作：
获取映射信息，所述映射信息将媒体数据的标识符映射到具有所述媒体数据的服务器设备的网络位置，其中，在第一服务可用时，能够经由所述服务器设备提供的所述第一服务访问所述网络位置以用于取回所述媒体数据，其中，所述第一服务将广播或多播中的至少一者定义为用于传输所述媒体数据的传输类型；
从应用服务客户端接收针对所述媒体数据的请求；
确定所述第一服务是否是可用的；
当所述第一服务是可用的时：
使得所述应用服务客户端从中间件单元接收所述媒体数据，所述中间件单元基于所述映射信息，使用所述第一服务从所述网络位置接收所述媒体数据；以及
当所述第一服务是不可用的时：
确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配，其中，所述映射信息包括针对每个潜在匹配的优先级值，并且其中，确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配包括：选择具有最低优先级值或最高优先级值中的一者的匹配；以及
当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据匹配时，向所述应用服务客户端发送HTTP重定向消息，以使得所述应用服务客户端根据第二服务从所选择的匹配网络位置取回所述媒体数据，其中，所述第二服务将单播定义为用于传输所述媒体数据的传输类型，以及其中，所述HTTP重定向消息指定所述媒体数据的所述标识符在所述映射信息中被映射到的所述网络位置。
16.根据权利要求15所述的设备，其中，所述代理单元还被配置为当所述请求中指定的所述媒体数据与所述映射信息中的所述媒体数据不匹配时，执行以下操作中的至少一项：
向所述应用服务客户端发送所述HTTP重定向消息，以使得所述应用服务客户端从默认的重定向位置取回所述媒体数据，其中所述HTTP重定向消息指定所述默认的重定向位置；
向所述应用服务客户端发送错误消息；以及
将所述请求的副本发送回所述应用服务客户端。
17.根据权利要求15所述的设备，其中，所述代理单元还被配置为在映射表中存储所述映射信息，其中，为了确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配，所述代理单元被配置为确定针对所述媒体数据的标识符是否对应于所述映射表中的条目。
18.根据权利要求15所述的设备，其中，所述映射信息包括被表示为统一资源标识符(URI)前缀的映射标准，并且其中，为了确定所述请求中指定的所述媒体数据是否与所述映射信息中的所述媒体数据匹配，所述代理单元被配置为确定匹配所述请求中指示的所述媒体数据的URI的至少一部分的、所述映射信息的URI前缀。
19.根据权利要求15所述的设备，还包括控制器单元，其向所述代理单元发送指示所述服务是否是可用的信息。
20.根据权利要求15所述的设备，其中，所述中间件单元包括多媒体广播多播服务(MBMS)中间件装置和演进的MBMS(eMBMS)中间件单元中的一个。
21.根据权利要求15所述的设备，其中，所述设备包括客户端设备，并且其中，所述客户端设备包括所述应用服务客户端。
22.根据权利要求15所述的设备，其中，所述设备包括代理设备，其中，客户端设备包括所述应用服务客户端，并且其中，所述代理设备与所述客户端设备是分开的。
23.根据权利要求15所述的设备，其中，所述代理单元从控制器单元获取所述映射信息。
24.根据权利要求23所述的设备，其中，所述设备包括代理设备，并且其中，与所述代理设备分开的控制器设备包括所述控制器单元。
CN201480004712.9A 2013-01-15 2014-01-14 用于取回媒体数据的方法和设备 Active CN105284093B (zh)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201361752456P 2013-01-15 2013-01-15
US61/752,456 2013-01-15
US201361809871P 2013-04-08 2013-04-08
US61/809,871 2013-04-08
US14/153,888 2014-01-13
US14/153,888 US10015437B2 (en) 2013-01-15 2014-01-13 Supporting transport diversity and time-shifted buffers for media streaming over a network
PCT/US2014/011475 WO2014113383A1 (en) 2013-01-15 2014-01-14 Supporting transport diversity and time-shifted buffers for media streaming over a network

Publications (2)

Publication Number Publication Date
CN105284093A CN105284093A (zh) 2016-01-27
CN105284093B true CN105284093B (zh) 2019-09-10

Family

ID=51165207

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480004712.9A Active CN105284093B (zh) 2013-01-15 2014-01-14 用于取回媒体数据的方法和设备

Country Status (9)

Country Link
US (2) US10015437B2 (zh)
EP (1) EP2946542B1 (zh)
JP (1) JP6231583B2 (zh)
KR (1) KR101847585B1 (zh)
CN (1) CN105284093B (zh)
BR (1) BR112015016989B1 (zh)
ES (1) ES2630279T3 (zh)
HU (1) HUE031896T2 (zh)
WO (1) WO2014113383A1 (zh)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US9160779B2 (en) 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US9445138B2 (en) 2012-04-12 2016-09-13 Qualcomm Incorporated Broadcast content via over the top delivery
US9820259B2 (en) 2012-05-04 2017-11-14 Qualcomm Incorporated Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand
US10015437B2 (en) 2013-01-15 2018-07-03 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
US9807188B2 (en) * 2013-04-09 2017-10-31 Samsung Electronics Co., Ltd. Methods and apparatuses for dynamic content offloading
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US9674251B2 (en) 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
EP3065411B1 (en) * 2013-10-28 2024-03-27 Saturn Licensing LLC Content supplying device, content supplying method, terminal device and content supplying program
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
US20150350284A1 (en) * 2014-05-27 2015-12-03 Acer Incorporated Method of Enhancement of Data Transmission in Multimedia Service
JP6558586B2 (ja) * 2014-06-20 2019-08-14 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US9094443B1 (en) * 2014-07-30 2015-07-28 Iboss, Inc. Web redirection for content scanning
MX2017005216A (es) * 2014-10-28 2017-10-04 Sony Corp Dispositivo de recepcion, dispositivo de transmision, y metodo de procesamiento de datos.
US10129308B2 (en) * 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
US9749372B2 (en) 2015-02-04 2017-08-29 Lg Electronics Inc. Device for transmitting broadcast signal, device for receiving broadcast signal, method for transmitting broadcast signal, and method for receiving broadcast signal
US10412132B2 (en) * 2015-02-16 2019-09-10 Lg Electronics Inc. Broadcasting signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
CN106254300B (zh) * 2015-06-08 2020-04-21 中兴通讯股份有限公司 流媒体传输方法、播放方法、传输装置及播放装置
US10193994B2 (en) * 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast
US10291681B2 (en) * 2015-06-18 2019-05-14 Ericsson Ab Directory limit based system and method for storing media segments
US11095537B2 (en) * 2015-06-19 2021-08-17 Qualcomm Incorporated Middleware delivery of dash client QoE metrics
US20170048681A1 (en) * 2015-08-11 2017-02-16 At&T Intellectual Property I, L.P. On-demand time-shifted access of broadcast content
JP6661931B2 (ja) * 2015-09-17 2020-03-11 沖電気工業株式会社 情報配信装置、情報配信プログラム及び情報配信システム
CN106549916A (zh) * 2015-09-18 2017-03-29 中兴通讯股份有限公司 组播传输方法、装置及系统
GB2543312A (en) * 2015-10-14 2017-04-19 Smartpipe Tech Ltd Network identification as a service
WO2017125150A1 (en) * 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Switching between unicast and multicast in a content delivery network
US20170295188A1 (en) 2016-04-06 2017-10-12 Karamba Security Automated security policy generation for controllers
CN106331089A (zh) * 2016-08-22 2017-01-11 乐视控股（北京）有限公司 一种视频播放控制方法和系统
US10979495B2 (en) 2016-08-29 2021-04-13 Saturn Licensing Llc Information processing apparatus, information processing method, and information processing system
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
US10542409B2 (en) * 2016-10-07 2020-01-21 Qualcomm Incorporated Access for group call services through a broadcast channel
CN107979570A (zh) * 2016-10-25 2018-05-01 北京优朋普乐科技有限公司 网络电台资源数据处理方法和装置
US10498795B2 (en) * 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
JPWO2018173874A1 (ja) 2017-03-24 2020-01-30 ソニー株式会社 コンテンツ提供システムおよびコンテンツ提供方法、並びにプログラム
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
EP3761613B1 (en) 2017-08-28 2023-02-15 Bright Data Ltd. Method for improving content fetching by selecting tunnel devices
US20190075545A1 (en) * 2017-09-02 2019-03-07 Qualcomm Incorporated Method and apparatus for providing unicast representations within a broadcast coverage area
CN108810652A (zh) * 2018-06-04 2018-11-13 深圳汇通九州科技有限公司 一种信息处理方法及终端设备
EP4053717A3 (en) 2019-02-25 2022-10-26 Bright Data Ltd. System and method for url fetching retry mechanism
EP4027618A1 (en) 2019-04-02 2022-07-13 Bright Data Ltd. Managing a non-direct url fetching service
CN110708293B (zh) * 2019-09-11 2021-11-19 中国联合网络通信集团有限公司 多媒体业务的分流方法和装置
CN112929070B (zh) * 2019-12-06 2023-04-18 中移(上海)信息通信科技有限公司 数据播发系统及方法
EP3886401A1 (en) * 2020-03-27 2021-09-29 Nokia Technologies Oy Method, apparatus, and computer program product for error handling for indirect communications
CN115134420A (zh) * 2021-03-24 2022-09-30 华为技术有限公司 一种媒体播放方法、装置和电子设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1322094A1 (en) * 2001-12-21 2003-06-25 Castify Holdings, Ltd Process for selecting a server in a content delivery network
CN1902865A (zh) * 2003-11-07 2007-01-24 诺基亚有限公司 从服务器到客户的流式传输

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6052718A (en) 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system
US6990512B1 (en) 2001-03-19 2006-01-24 Novell, Inc. Method and system for using live time shift technology to control a multimedia file
US6813690B1 (en) * 2001-06-12 2004-11-02 Network Appliance, Inc. Caching media data using content-sensitive identifiers
WO2003096669A2 (en) * 2002-05-10 2003-11-20 Reisman Richard R Method and apparatus for browsing using multiple coordinated device
US7480723B2 (en) * 2003-04-08 2009-01-20 3Com Corporation Method and system for providing directory based services
US7454510B2 (en) 2003-05-29 2008-11-18 Microsoft Corporation Controlled relay of media streams across network perimeters
US7647599B2 (en) * 2003-12-22 2010-01-12 Motorola, Inc. Interprocessor communication network providing dynamic dedication of ports
US7162533B2 (en) 2004-04-30 2007-01-09 Microsoft Corporation Session description message extensions
US20060031559A1 (en) 2004-05-25 2006-02-09 Gennady Sorokopud Real Time Streaming Protocol (RTSP) proxy system and method for its use
US20070130597A1 (en) 2005-12-02 2007-06-07 Alcatel Network based instant replay and time shifted playback
US9380096B2 (en) * 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
KR101278297B1 (ko) 2006-06-27 2013-07-30 톰슨 라이센싱 신뢰적 멀티캐스트 데이터 전송을 위한 방법 및 장치
US7584495B2 (en) 2006-06-30 2009-09-01 Nokia Corporation Redundant stream alignment in IP datacasting over DVB-H
US20080069126A1 (en) 2006-09-14 2008-03-20 Sbc Knowledge Ventures, L.P. Method and system for buffering content
US8489817B2 (en) * 2007-12-06 2013-07-16 Fusion-Io, Inc. Apparatus, system, and method for caching data
US8249561B2 (en) * 2007-09-11 2012-08-21 Research In Motion Limited System and method for sharing a SIP communication service identifier
US8458290B2 (en) 2011-02-01 2013-06-04 Limelight Networks, Inc. Multicast mapped look-up on content delivery networks
US8661155B2 (en) * 2008-12-30 2014-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Service layer assisted change of multimedia stream access delivery
US20100180011A1 (en) * 2009-01-12 2010-07-15 Microsoft Corporation Url based retrieval of portions of media content
US20100179984A1 (en) 2009-01-13 2010-07-15 Viasat, Inc. Return-link optimization for file-sharing traffic
US20110066703A1 (en) 2009-05-20 2011-03-17 Creative Ad Technology Proprietary Limited Methods and systems for delivering media to client device
CN101924944B (zh) 2009-06-15 2013-06-05 华为技术有限公司 可伸缩视频编码操作点选择方法、信息提供方法及设备
US20110219416A1 (en) 2010-03-04 2011-09-08 Telefonaktiebolaget L M Ericsson (Publ) Network Time-Shift Methods and Apparatus
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
MY168733A (en) 2010-11-02 2018-11-29 Ericsson Telefon Ab L M Methods and devices for media description delivery
US20120124179A1 (en) * 2010-11-12 2012-05-17 Realnetworks, Inc. Traffic management in adaptive streaming protocols
CN105897769B (zh) * 2011-02-11 2019-07-02 交互数字专利控股公司 用于流送内容的方法和服务器
US9026671B2 (en) 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9226265B2 (en) 2011-04-15 2015-12-29 Qualcomm Incorporated Demand-based multimedia broadcast multicast service management
WO2012167106A1 (en) 2011-06-01 2012-12-06 Interdigital Patent Holdings, Inc. Content delivery network interconnection (cdni) mechanism
US9160779B2 (en) 2011-06-30 2015-10-13 Qualcomm Incorporated Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US9268621B2 (en) 2011-11-02 2016-02-23 Red Hat, Inc. Reducing latency in multicast traffic reception
US9769281B2 (en) * 2011-12-19 2017-09-19 Google Technology Holdings LLC Method and apparatus for determining a multimedia representation for a multimedia asset delivered to a client device
US20130182643A1 (en) 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast
US9547532B2 (en) * 2012-01-19 2017-01-17 Microsoft Technology Licensing, Llc Techniques to provide proxies for web services
US9526091B2 (en) * 2012-03-16 2016-12-20 Intel Corporation Method and apparatus for coordination of self-optimization functions in a wireless network
US9820259B2 (en) 2012-05-04 2017-11-14 Qualcomm Incorporated Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand
US10015437B2 (en) 2013-01-15 2018-07-03 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
US9674251B2 (en) 2013-06-17 2017-06-06 Qualcomm Incorporated Mediating content delivery via one or more services
US10560509B2 (en) 2013-07-05 2020-02-11 Qualcomm Incorporated Method and apparatus for using HTTP redirection to mediate content access via policy execution

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1322094A1 (en) * 2001-12-21 2003-06-25 Castify Holdings, Ltd Process for selecting a server in a content delivery network
CN1902865A (zh) * 2003-11-07 2007-01-24 诺基亚有限公司 从服务器到客户的流式传输

Also Published As

Publication number Publication date
KR20150107837A (ko) 2015-09-23
US20140201323A1 (en) 2014-07-17
EP2946542B1 (en) 2016-12-28
WO2014113383A1 (en) 2014-07-24
BR112015016989A2 (pt) 2017-07-11
EP2946542A1 (en) 2015-11-25
KR101847585B1 (ko) 2018-04-10
ES2630279T3 (es) 2017-08-21
HUE031896T2 (en) 2017-08-28
US10015437B2 (en) 2018-07-03
CN105284093A (zh) 2016-01-27
JP2016510460A (ja) 2016-04-07
US20140199044A1 (en) 2014-07-17
BR112015016989B1 (pt) 2023-02-14
JP6231583B2 (ja) 2017-11-15

Similar Documents

Publication Publication Date Title
CN105284093B (zh) 用于取回媒体数据的方法和设备
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
CN105075214B (zh) 用于提供多媒体自适应流传输的方法和设备
CN105474672B (zh) 目标媒体内容的递送
CN105794160B (zh) 用于dash的客户端/服务器信令命令
JP6698553B2 (ja) １つの要求メッセージに基づいたネットワーク・ノードへの多数のチャンクの要求
TWI580237B (zh) 單一播放適應性位元率串流
US9158769B2 (en) Systems and methods for network content delivery
US20190149628A1 (en) Just in time transcoding and packaging in ipv6 networks
JP6254188B2 (ja) Ｉｍｓベースのｄａｓｈサービスにおいて、プレゼンスサーバによりプレゼンス情報を供給する方法、および、プレゼンスサーバを介してプレゼンス情報を受信するユーザ機器（ｕｅ）
WO2016205670A1 (en) Signaling cached segments for broadcast
BR112015031512B1 (pt) Mediar entrega de conteúdo via um ou mais serviços
US20140074961A1 (en) Efficiently Delivering Time-Shifted Media Content via Content Delivery Networks (CDNs)
US8898717B1 (en) System and method for obfuscating start-up delay in a linear media service environment
CN109845276A (zh) 信息处理装置和信息处理方法
US10805028B2 (en) Receiving device, transmitting device, and data processing method
EP2670109B1 (en) Method, system and devices for multimedia delivering in content delivery networks
JP6418665B2 (ja) Ｉｍｓベースのｄａｓｈサービスにおいて、プレゼンスサーバによりプレゼンス情報を供給する方法、および、プレゼンスサーバを介してプレゼンス情報を受信するユーザ機器（ｕｅ）
WO2016074149A1 (en) Expedited media content delivery
WO2016067987A1 (ja) 受信装置、送信装置、およびデータ処理方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant