CN107534663A - 用于通过广播支持dash的进一步设备定时调整和方法 - Google Patents

用于通过广播支持dash的进一步设备定时调整和方法 Download PDF

Info

Publication number
CN107534663A
CN107534663A CN201680022873.XA CN201680022873A CN107534663A CN 107534663 A CN107534663 A CN 107534663A CN 201680022873 A CN201680022873 A CN 201680022873A CN 107534663 A CN107534663 A CN 107534663A
Authority
CN
China
Prior art keywords
segmentation
time
mpd
time started
receiver device
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.)
Pending
Application number
CN201680022873.XA
Other languages
English (en)
Inventor
R·A·戈尔米
O·卢特法拉
C·M·D·帕索斯
N·奈克
N·希瓦尚卡尔
N·A·巴西乌尼
T·M·纳加拉杰
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 CN107534663A publication Critical patent/CN107534663A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/75—Media network packet handling
    • 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/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • 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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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/80—Responding to QoS
    • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Abstract

各个实施例的系统、方法和设备使接收机设备能够使用修改的分段可用时间。在各个实施例中，可以使接收机设备能够修改分段可用性时间轴(例如，媒体呈现描述(MPD))中的分段的可用开始时间，以说明分段可用于DASH客户端的实际时间。

Description

用于通过广播支持DASH的进一步设备定时调整和方法
相关申请
本申请要求享受2015年4月20日提交的、标题为“Further Device TimingAdjustments and Methods for Supporting DASH Over Broadcast”的美国临时专利申请No.62/149,776的优先权，故以引用方式将其全部内容并入本文。
背景技术
当前，超文本传输协议(HTTP)流媒体是互联网上最流行的用于传送内容的方法。对于实时事件而言，通过固定持续时间的分段来使内容逐渐可用。这种沿着时间轴的分段可用性，指示每一个后续的分段在HTTP服务器处变得可用。
超文本传输协议动态自适应流媒体(DASH)是一种实现HTTP流媒体的标准。DASH在媒体呈现描述(MPD)中通告分段可用性。MPD是用于通告分段、分段可用的时间以及这些分段的大小的分段可用性时间轴。
在当前系统中，通过空中下载(OTA)传输来向接收机设备提供MPD。在所提供的MPD中，分段可用开始时间可以对应于生成这些分段的网络侧编码器的编码器输出时间。由于分段可用开始时间对应于编码器输出时间，因此对于在接收机设备上运行的DASH客户端来说，这些可用开始时间并没有说明实际的分段可用的差值(例如，传送路径延迟、接收机设备处理延迟、或者接收机设备时钟漂移)。因此，在当前MPD中所通告的可用开始时间，可能并不对应于分段可用于DASH客户端的实际时间。
发明内容
各个实施例的系统、方法和设备使接收机设备能够使用修改的分段可用时间。在各个实施例中，可以使接收机设备能够修改分段可用时间轴(例如，媒体呈现描述(MPD))中的分段的可用开始时间，以说明分段可用于DASH客户端的实际时间。
在一些实施例中，一种用于计算接收机设备定时漂移的方法，可以包括：通过URL匹配来确定分段的索引；基于可用性时间轴中的匹配的时段和表示对，确定该分段的可用开始时间；根据所述可用性时间轴，确定分段持续时间；确定用于该分段的解码时间；判断用于该分段的解码时间减去该分段的可用开始时间是否大于分段持续时间的一部分；响应于确定用于该分段的解码时间减去该分段的可用开始时间大于分段持续时间的一部分，触发所述可用开始时间的重新计算。
在一些实施例中，一种用于计算接收机设备定时偏移的方法，可以包括：通过URL匹配来确定接收的分段的分段索引；确定源自于所接收的分段的可用开始时间的改变；判断该可用开始时间的改变是否大于门限；响应于确定该可用开始时间的改变大于门限，触发可用开始时间重新计算。
另外的实施例可以包括具有处理器的接收机设备，其中该处理器配置为执行上面所概述的任一方法的操作。
附图说明
被并入本文并且构成本说明书一部分的附图，描绘了本发明的示例性实施例，并且连同上面给出的概括描述以及下面给出的详细描述一起来解释本发明的特征。
图1是适合于结合各种实施例使用的网络的通信系统框图。
图2是根据一个实施例，示出接收机设备的架构的框图。
图3A根据一个实施例，示出了分段传输路径和MPD传输调整之间的关系。
图3B根据一个实施例，示出了分段传输路径和MPD传输调整之间的关系。
图4根据一个实施例，示出了网络的不同部分中的传输路径延迟之间的关系。
图5A是示出用于基于确定的第一FDT接收时间，响应于分段索引改变来修改分段可用开始时间的实施例方法的处理流程图。
图5B是示出用于基于确定的第一FDT接收时间，响应于分段索引改变来生成延迟调整消息的实施例方法的处理流程图。
图6A是示出用于基于确定的第一FDT接收时间，响应于基URL改变来修改分段可用开始时间的实施例方法的处理流程图。
图6B是示出用于基于确定的第一FDT接收时间，响应于基URL改变来生成延迟调整消息的实施例方法的处理流程图。
图7根据一个实施例，示出了可用性时间轴、MPD可用开始时间、传输时间和到达时间。
图8A是示出用于基于任何确定的FDT接收时间，在单播模式下修改分段可用开始时间的实施例方法的处理流程图。
图8B是示出用于基于任何确定的FDT接收时间，在单播模式下生成延迟调整消息的实施例方法的处理流程图。
图9A是根据一个实施例，示出多播服务设备客户端和接收机设备上的应用/DASH客户端之间的交互的消息流程图。
图9B是根据另一个实施例，示出多播服务设备客户端和接收机设备上的应用/DASH客户端之间的交互的消息流程图。
图10是示出基于延迟调整消息，调整可用开始时间的实施例方法的处理流程图。
图11A是示出用于处理MPD更新的实施例方法的处理流程图。
图11B是示出用于处理MPD更新的另一种实施例方法的处理流程图。
图12根据另一个实施例，示出了可用性时间轴、MPD可用开始时间、传输时间和到达时间。
图13是示出用于应对接收机设备定时漂移的实施例方法的处理流程图。
图14是示出用于标记失败的HTTP记录的实施例方法的处理流程图。
图15A是示出用于应对接收机设备定时漂移的另一种实施例方法的处理流程图。
图15B是示出用于应对接收机设备定时漂移的第三实施例方法的处理流程图。
图16是示出用于通过URL匹配来确定分段索引的实施例方法的处理流程图。
图17A、17B和17C是根据一个实施例的示例性MPD的元素的框图。
图18是根据一个实施例的示例性MPD的XML树的框图。
图19示出了根据一个示例的分段的可用性时间轴。
图20是根据一个实施例的单一分段持续时间MPD的示例性架构(schema)部分。
图21是根据一个实施例，示出在时段和表示对中爬取(crawl)MPD和匹配URL的各种结果的框图。
图22示出了根据一个实施列的分段的可用性时间轴。
图23是根据一个实施例的两分段持续时间MPD的示例性架构部分。
图24是根据另一个实施例，示出在时段和表示对中爬取(crawl)MPD和匹配URL的各种结果的框图。
图25是示出用于通过URL匹配来确定分段索引的另一种实施例方法的处理流程图。
图26示出了根据一个实施例的重复分段的可用性时间轴。
图27是示出用于基于URL匹配来应对接收机设备定时漂移的实施例方法的处理流程图。
图28是示出用于基于URL匹配来应对接收机设备定时漂移的另一种实施例方法的处理流程图。
图29是示出用于基于URL匹配来应对接收机设备定时漂移的第三实施例方法的处理流程图。
图30是适合于结合各种实施例使用的示例性移动设备的组件图。
图31是适合于结合各种实施例使用的示例性服务器的组件图。
具体实施方式
现在参照附图来详细地描述各个实施例。在可以的地方，贯穿附图使用相同的附图标记来指代相同或者类似的部件。对于特定示例和实现的引用只是用于说明目的，而不是旨在限制本发明或者权利要求的保护范围。
各个实施例使接收机设备能够考虑用于在该接收机设备上使用的数据流中的数据分段可用性(“分段可用性”)的延迟。在一个实施例中，接收机设备可以基于接收的分段将可用于该接收机设备上的应用/客户端(例如，获取分段以用于媒体播放器应用的超文本传输协议动态自适应流媒体(DASH)客户端)的实际时间，来调整从网络接收的分段可用性时间轴中的可用开始时间(例如，通过空中(OTA)从广播多媒体服务中心(BMSC)服务器接收的媒体呈现描述(MPD))以生成修改的MPD列表。当网络和接收机设备时钟同步或不同步时，各个实施例可以使得能够生成修改的MPD。
本文所使用的“示例性的”一词意味着“用作例子、例证或说明”。本文中描述为“示例性”的任何实现方式不应被解释为比其它实现方式更优选或更具优势。
如本文所使用的，本文互换地使用术语“移动设备”和“接收机设备”，以指代下面中的任何一项或者全部：蜂窝电话、智能电话、个人或移动多媒体播放器、个人数据助理(PDA)、膝上型计算机、平板计算机、智能本、掌上计算机、无线电子邮件接收机、具备多媒体互联网功能的蜂窝电话、无线游戏控制器、智能电视、机顶盒、数字录像机(DVR)以及类似的个人电子设备，其中这些个人电子设备包括可编程处理器和存储器，以及用于接收MPD和使MPD可用于DASH客户端的电路。
DASH是一种实现HTTP流媒体的标准。DASH在MPD中通告分段可用性。MPD是用于通告分段、分段可用的时间以及这些分段的大小的分段可用性时间轴。在当前系统中，通过OTA传送来向接收机设备提供MPD。第三代合作伙伴计划(3GPP)在下载传输上，将DASH标准化成用于在长期演进(LTE)上使用广播来提供HTTP流媒体的方法(即，演进型多媒体广播多播服务(eMBMS))。
本文讨论了不同的应用/客户端、中间件、分段可用性时间轴、无线电技术和传输协议的各种示例，特别是DASH客户端、多播服务设备客户端(MSDC)、MPD、eMBMS和HTTP。DASH客户端、多播服务设备客户端、MPD、eMBMS和HTTP的讨论，只是提供成用于更好地描绘各个实施例的方面的例子，而不是旨在以任何方式来限制各个实施例。其它的应用/客户端、中间件、分段可用性时间轴、无线电技术和传输协议也可以结合各个实施例来使用，并在不脱离本发明的精神或保护范围的基础上，可以在各个例子中替换其它的应用/客户端、中间件、分段可用性时间轴、无线电技术和传输协议。
在一个实施例中，接收机设备可以确定延迟调整，以应对分段可用于该接收机设备上的客户端应用的延迟。在一个实施例中，可以在延迟调整消息中提供该延迟调整。延迟调整消息可以是延迟调整的参数和/或指示，例如，包括延迟调整的文件。在一个实施例中，延迟调整消息可以使接收机设备上的客户端应用能够基于接收的分段将可用于该接收机设备上的应用/客户端(例如，获取分段以用于媒体播放器应用的DASH客户端)的实际时间，修改从网络接收的用于描述分段可用性的清单文件(例如，分段可用性时间轴)(例如，通过OTA从BMSC服务器接收的MPD)中的可用开始时间，以生成修改的MPD列表。虽然围绕分段可用性时间轴和/或MPD来讨论了各个实施例，但分段可用性时间轴和/或MPD仅仅是用于描述分段可用性的清单文件的示例，并且描述分段可用性的任何清单文件可以在各种示例中替代本文所讨论的分段可用性时间轴和/或MPD。当网络和接收机设备时钟同步或者不同步时，各个实施例可以实现延迟调整消息和修改的MPD。在另一个实施例中，延迟调整消息可以使接收机设备上的客户端应用能够基于接收的分段将可用于该接收机设备上的应用/客户端(例如，获取分段以用于媒体播放器应用的DASH客户端)的实际时间，来调整其对于分段的请求的定时，而无需修改分段可用性时间轴本身。
在各个实施例中，随着接收到分段片段，接收机设备处理器可以监测分段片段的分段索引号或者基统一资源标识符(URI)，并且将连续接收的分段的分段索引号或基URI彼此之间进行比较。当最近的分段片段的分段索引号或基URI与前一分段片段的分段索引号或基URI不同时(例如，检测到分段索引号或基URI改变)，最近的分段片段可以是时间轴中的下一个分段的第一分组，例如，时间轴中的下一个分段的单向传输文件传送(FLUTE)文件传送表(FDT)。接收机设备处理器(例如，在处理器上运行的多播服务设备客户端)可以将该下一个分段识别成基分段，并且可以使用第一分组(例如，第一FDT)的到达时间来修改时间轴中的基分段的可用开始时间，并且基于修改的可用开始时间来使后续分段的所有后续可用时间进行偏移。用此方式，接收机设备处理器可以修改时间轴中的可用开始时间(例如，MPD中的AST)，以说明分段的实际到达时间。
在各个实施例中，接收机设备处理器可以爬取(例如，解析)所接收的MPD，以确定与每个时段和表示对相对应的URL格式。例如，该URL格式可以是格式“XXX$number$YYY”，其中，XXX可以是前缀，YYY可以是后缀，$number$可以是分段的索引号(例如，DASH中的分段号)。接收机设备处理器可以使用该信息，来首先判断接收的分段的URL是否与特定时段和表示对的分段URL格式相匹配，随后可以确定分段号。此外，接收机设备处理器还可以判断该分段号是否导致与该时段和表示对相对应的分段，并且可以确定实际分段号。一旦确定了分段号，则接收机设备处理器可以将该分段号与先前检测的分段号进行比较。在一个实施例中，该URL格式可以是基于数字的URL方案。在另外的实施例中，该基URL可以始终是绝对URL。在一个实施例中，可以通过向可用性时间计算应用调整，来支持baseURL@availabilityTimeOffset。在一个实施例中，URL格式或者模板可以是基于时间的，而不是基于分段号的。例如，与相同的持续时间相对应的音频和视频分段，可以在模板中具有相同的$time$标签。接收机设备处理器可以确定每个进入分段的可用开始时间，并基于每个进入分段的可用开始时间的改变来确定基分段。
在各个实施例中，可以将基分段的修改的可用开始时间确定为：第一FDT到达时间加上每分段的分段片段数量(SF)乘以多播信道(MCH)调度周期(MSP)加上裕度(M)，或者修改的可用开始时间＝第一FDT到达时间+(SF*MSP)+M。在一个实施例中，MSP的值可以是预先提供给接收机设备的缺省值。在另一个实施例中，MSP可以是与用于接收分段的临时移动组标识符(TMGI)相关联的变量值。裕度(M)可以是用于考虑接收机设备的处理延迟的额外裕度，其可以被配置成在接收机设备的存储器中预先配置的值。在一个实施例中，SF可以等于小区分段持续时间/MSP。SF可以通过乘法因子(例如，小于或大于1的值，但是大于零的值，例如0.8、0.9、1.1、1.2等)来调整，以考虑如在编码器中生成的分段大小的变化性以及广播系统中的调度方法。
在各个实施例中，在相同承载上同时广播的多个表示(例如，音频和视频)，可以不影响接收机设备处理器识别索引变化和修改分段可用开始时间的能力。在一些实施例中，两个或更多表示可以具有相同的起始索引和相同的分段持续时间。在一些实施例中，两个或更多表示可以具有不同的起始索引和/或不同的分段持续时间。单独的音频和视频表示仍然可以包括索引值，并且无论两个分段是否是音频和/或视频段，接收机设备处理器可以将索引值改变处理成用于跟踪下一分段的FDT到达时间的指示。
在一个实施例中，随着接收到分段片段，接收机设备处理器可以监测分段片段的分段可用时间，并且将连续接收的分段的分段可用开始时间彼此之间进行比较。当最近的分段片段的分段可用开始时间与前一分段片段的分段可用开始时间不同时，最近的分段片段可以是时间轴中的下一个分段的单向传输文件传送(FLUTE)文件传送表(FDT)。接收机设备处理器(例如，在处理器上运行的多播服务设备客户端)可以将该下一个分段识别成基分段，并且可以使用第一FDT的到达时间来修改时间轴中的基分段的可用开始时间，并且基于修改的可用开始时间来使后续分段的所有后续可用开始时间进行偏移。
在一个实施例中，当不同的广播表示的分段持续时间不同时(例如，2s分段持续时间的音频和1s分段持续时间的视频)，接收机设备处理器可以仅仅使用视频表示来确定所述调整。此外，接收机设备处理器还可以使用表示之间的更高的分段持续时间，来确定其可用性可以对齐并且可以应用相同的计算的超级分段。当分段持续时间是彼此的倍数时，接收机设备处理器可以只使用视频表示来确定所述调整。当分段持续时间不是彼此的倍数时，接收机设备处理器可以使用分段持续时间的最低公倍数。
在各个实施例中，当接收机设备处理器确定单播提取活动时，接收机设备处理器(例如，在处理器上运行的多播服务设备客户端)可以确定在接收机设备处接收的任何分段的任何FDT的接收时间，并且可以基于FDT的接收时间来修改该分段的可用开始时间。用此方式，可以立即使MPD中的可用时间偏移，而无需等待接收下一个分段或者分段索引改变，并且可以利用更紧密的时间轴，使得能够更早地通过单播来使用单播提取请求分段。基于描述分段的第一广播FDT来设置可用性时间轴，可以确保比通过使用描述该分段的任何FDT所确定的时间轴更严格的截止日期。例如，描述一个分段的最后FDT可以是比描述该分段的第一FDT更晚大约一个分段持续时间，并且使用它来设置分段可用开始时间，可能导致分段的可用性延迟相同的持续时间。因此，一旦遇到FDT，就可以使MPD可用，使得与等待要接收的下一个分段或者分段索引改变相比，更早地开始实现播放。在一个实施例中，可以通过单播来获取第一个的一个或多个分段。
可以将每DASH标准的媒体分段的可用时间确定为：MPD的可用开始时间(AST)的值(例如，用于表示MPD中描述的所有分段的可用性的锚定时间的MPD元素“MPD@availabilityStartTime”中指示的时间)，加上包含时段的时段起始(PeriodStart)时间，加上该媒体分段的MPD可用开始时间(AST)(例如，该分段自身的AST)，加上分段持续时间。在各个实施例中，基于所识别的基分段的URI，接收机设备处理器(例如，在接收机设备的处理器上运行的多播服务设备客户端)可以确定MPD中的所有剩余分段的相应的可用开始时间。在一个实施例中，接收机设备处理器可以基于根据第一FDT到达时间所确定的基分段的修改的可用开始时间，来修改MPD的可用开始时间(AST)。例如，可以将MPD的AST修改为等于：修改的可用开始时间减去PeriodStart时间，减去基分段的时间段(分段持续时间乘以分段号减去起始分段号)中的分段开始时间。在各个实施例中，在接收到与先前MPD具有相同AST的MPD更新后，接收机设备处理器可以调整MPD更新的AST，以匹配针对先前MPD所确定的修改的AST。在各个实施例中，在接收到与先前MPD具有不同AST的MPD更新后，接收机设备处理器可以使用基于第一FDT到达时间所确定的基分段的修改的可用开始时间，来调整MPD更新的AST。在各个实施例中，接收到具有不同的AST的MPD更新，可以触发新的可用开始时间确定。
在另一个实施例中，接收机设备处理器可以调整与所接收的分段相对应的基URL元素的segmentAvailabilityOffset(分段可用性偏移)属性。该segmentAvailabilityOffset参数可以修改计算的可用开始时间，并且其可以自行调整以替代可用开始时间。
在各个实施例中，接收机设备处理器可以将基分段匹配到两个不同的时段和表示对。正确的匹配可以是导致更小的时间轴调整的时段和表示对，这是因为该时段和表示对可能是实时流媒体系统中的更可能的时间轴调整。
在各个实施例中，可以跟踪接收机设备处的定时漂移，并响应于检测到定时漂移，接收机设备处理器可以确定用于MPD的新的可用开始时间。在各个实施例中，接收机设备处理器(例如，在接收机设备处理器上运行的多播服务设备客户端)可以跟踪与DASH客户端的失败的HTTP请求相关联的分段号或者分段URI。一旦对分段号或者分段URI进行跟踪，则接收机设备处理器可以判断DASH客户端的每个后续HTTP请求是针对于相同的分段号或分段URI，还是针对于不同的分段号或分段URI。
在接收到针对不同的分段号或分段URI的HTTP请求后，接收机设备处理器可以判断失败的HTTP请求是否被清除或者仍然未完成，以及请求的分段是否现在位于高速缓存中。当失败的HTTP请求仍然未完成并且请求的分段在高速缓存中时，接收机设备上的定时偏移可能已经发生，其导致在DASH客户端可能已经放弃请求分段之后，该分段到达(即，满足漂移条件)。当检测到定时漂移时(即，满足漂移条件)，可以重新计算可用开始时间，并且接收机设备可以修改MPD以考虑该定时漂移。
在一个实施例中，为了避免在DASH客户端一次发出大量的HTTP请求时(例如，在启动以确定媒体流的线边缘时)跟踪分段，可以对下一个分段的跟踪进行延迟(例如，延迟等于分段持续时间的90％的时间)。在另外实施例中，仅当下一个分段号比当前跟踪的分段更大一个分段索引时，才可以应用针对漂移条件的检查。在一些实施例中，一次只能跟踪一个分段。在其它实施例中，一次可以跟踪多个分段。
在各个实施例中，可以使用分段的URL与MPD中的相应的时段和表示对的URL匹配，来判断是否发生定时漂移。在一个实施例中，响应于与分段持续时间的一半相比，用于分段的解码时间减去根据MPD的分段的可用开始时间(其基于匹配的时段和表示对)更大，接收机设备处理器可以确定已发生定时漂移，并且触发可用开始时间的重新计算(即，触发可用开始时间重新计算)。在另一个实施例中，可以响应于至少部分地基于URL匹配而确定发生了分段索引改变，来确定定时漂移。在一个实施例中，可以至少部分地基于URL匹配，来确定源自于所接收的分段的AST改变。响应于AST变化量比门限(例如，一个分段持续时间)更大，接收机设备处理器可以确定已发生定时漂移，并且触发可用开始时间重新计算。
图1示出了适合于结合各种实施例使用的蜂窝网络系统100。蜂窝网络系统100可以包括多个设备，例如，接收机设备102、一个或多个蜂窝塔或基站104、以及连接到互联网110的服务器108和112。接收机设备102可以经由一个或多个蜂窝连接106(其包括CDMA、TDMA、GSM、PCS、3G、4G、LTE或任何其它类型的连接)，与蜂窝塔或基站104交换数据。蜂窝塔或基站104可以与路由器进行通信，其中路由器可以连接到互联网110。用此方式，经由与蜂窝塔或基站104和/或互联网110的连接，可以在接收机设备102和服务器108和112之间交换数据。在一个实施例中，服务器108可以是提供用于经由DASH客户端来输出的MPD和分段的内容提供商服务器或编码器。在一个实施例中，服务器112可以是能从编码器接收MPD和分段输出，并控制这些MPD和分段向接收机设备102的OTA传输的广播多媒体服务中心(BMSC)服务器。当然，虽然本文所描述的接收机设备的特征是参照OTA传输来描述的，但这些特征也可以结合有线传输、无线传输或者有线传输和无线传输的组合来使用。因此，并不是必须进行OTA传输。
图2示出了根据一个实施例的简化接收机设备202的体系结构。接收机设备202可以包括调制解调器层208，后者管理接收机设备202的所有无线电方面，例如，捕获、切换、链路维持等等。调制解调器层208可以对接收的eMBMS承载信号进行解码，将互联网协议(IP)分组传送给多播服务设备客户端(MSDC)206。
多播服务设备客户端206可以是接收机设备202的服务层，其从传送的IP分组中恢复分段，并使分段可用于应用/客户端(例如，应用/DASH客户端204)。举例而言，多播服务设备客户端206可以是作为接收机设备202的操作系统的一部分的服务层。此外，多播服务设备客户端206还可以从传送的IP分组中恢复MPD。多播服务设备客户端206可以将接收的分段存储在该接收机设备的存储器中。
在一个实施例中，多播服务设备客户端206可以调整MPD以生成修改的MPD，将修改的MPD存储在接收机设备的存储器中，将修改的MPD传送给应用/DASH客户端204。在另一个实施例中，多播服务设备客户端206可以确定针对MPD的延迟调整，将针对MPD的延迟调整存储在接收机设备的存储器中(例如，存储在延迟调整消息中)，将MPD存储在接收机设备的存储器中，并且可以将MPD和针对MPD的延迟调整传送给应用/DASH客户端204。
应用/DASH客户端204可以是具备DASH能力的应用和/或用于发起DASH客户端以呈现媒体(直接呈现和/或通过诸如媒体播放器之类的另一个应用进行呈现)的应用。在一个实施例中，应用/DASH客户端204可以从多播服务设备客户端206获得修改的MPD位置(例如，统一资源定位符(URL))，从多播服务设备客户端206请求和接收修改的MPD，并根据该修改的MPD中的可用性时间轴来从多播服务设备客户端206请求分段。在另一个实施例中，应用/DASH客户端204可以从多播服务设备客户端206获得MPD位置(例如，统一资源定位符(URL))和针对MPD位置(例如，URL)的延迟调整，从多播服务设备客户端206请求和接收MPD和针对MPD的延迟调整，根据针对MPD的延迟调整来修改MPD以生成修改的MPD，根据修改的MPD中的可用性时间轴来从多播服务设备客户端206请求分段。应用/DASH客户端204可以从多播服务设备客户端206接收所请求的分段，并呈现分段内容(直接呈现和/或通过诸如媒体播放器之类的另一个应用进行呈现)。
在一个实施例中，用于确定针对MPD的延迟调整的多播服务设备客户端206的功能可以集成到客户端206中，并且客户端206可以确定延迟调整和/或自身修改MPD。
图3A根据一个实施例，示出了沿着分段传输路径，针对分段可用性时间轴(例如，MPD)所做出的传输调整。该分段传输路径可以包括编码器302、BMSC 304、接收机设备的多播服务设备客户端306、以及接收机设备的DASH客户端308。编码器302可以将媒体内容编码到分段中，并定期地向BMSC 304传送分段。例如，可以经由eMBMS网关，定期地从编码器302向BMSC 304传送分段。BMSC 304可以接收这些分段，并通过承载(例如，经由OTA广播)来广播这些分段。在一个实施例中，前端的延迟和抖动可能是已知的。在接收机设备中执行的多播服务设备客户端306可以经由调制解调器接收这些分段，多播服务设备客户端306可以处理这些分段(例如，对这些分段进行解码，应用FEC等等)，以使这些分段可用于在该接收机设备上执行的DASH客户端308。DASH客户端308可以向接收机设备的应用(例如，媒体播放器)或编解码器提供这些分段，以使接收机设备能够输出媒体内容。
除了生成分段之外，编码器302可以生成MPD 310。编码器所生成的MPD 310可以列出所生成的分段和/或将由编码器302生成的分段、分段长度(例如，大小)、以及这些分段的可用开始时间。在一个实施例中，编码器所生成的MPD 310中的可用开始时间，可以对应于编码器302生成的分段的输出时间。编码器302可以向BMSC 304提供所生成的MPD 310。在一个实施例中，BMSC 304可以接收所生成的MPD 310，调整分段可用性时间轴以说明任何OTA传输延迟(例如，网络抖动)，从而生成MPD 312。BMSC 304可以向接收机设备发送MPD 312。MPD 312可以列出与这些分段的OTA可用开始时间相对应的分段可用开始时间。
在一个实施例中，接收机设备可以接收MPD 312，接收机设备的多播服务设备客户端306可以基于接收机设备延迟(例如，处理延迟、接收机设备时钟漂移裕度等等)，根据本地接收机设备时钟来调整可用开始时间，以生成修改的MPD 314，其中该修改的MPD 314列出了在该接收机设备处这些分段的实际估计的可用开始时间。多播服务设备客户端306可以向DASH客户端308提供修改的MPD 314，该DASH客户端可以使用该MPD中的分段可用开始时间，以便利用接收机设备时钟从该接收机设备的本地HTTP服务器请求分段。在另一个实施例中，接收机设备的多播服务设备客户端306可以基于接收机设备延迟(例如，处理延迟、时钟漂移等等)，根据本地接收机设备时钟来调整MPD 312中的可用开始时间，并独立于向DASH客户端308发送的任何MPD，向DASH客户端308传输针对这些可用开始时间的调整量。在另外的实施例中，多播服务设备客户端306进行的调整，可以基于经由单播还是广播传输来接收呈现，和/或每个呈现的分段大小而发生变化。
图3B根据另一个实施例，示出了沿着分段传输路径，针对分段可用性时间轴(例如，MPD)所做出的传输调整。图3B中所示出的传输调整类似于上面关于图3A中所描述的那些，除了在图3B中，在向DASH客户端308发送MPD之前，多播服务设备客户端306不能修改该MPD。
在一个实施例中，接收机设备可以接收MPD 312，接收机设备的多播服务设备客户端306可以向DASH客户端308提供MPD312，而不修改分段可用开始时间。在一个实施例中，多播服务设备客户端306可以确定用于基于接收机设备延迟(例如，处理延迟、时钟漂移等等)，根据本地接收机设备时钟来调整可用开始时间的延迟调整量，并生成用于列出该延迟调整量的延迟调整消息316。多播服务设备客户端306可以向DASH客户端308提供该延迟调整消息。
在一个实施例中，DASH客户端308可以使用延迟调整消息316中的延迟调整指示，来修改MPD 312中的分段可用开始时间以生成修改的MPD314。DASH客户端308可以使用接收机设备时钟，从接收机设备的本地HTTP服务器请求分段。在另一个实施例中，DASH客户端308可以接收延迟调整消息316，并使用延迟调整消息316来修改从该接收机设备的本地HTTP服务器中进行的针对分段的请求，而不用生成修改的MPD 314。
图4示出了网络400的不同部分中的两个示例性传输路径延迟Δ1和Δ2之间的关系。来自编码器402的内容可以从编码器402传送到分段器404，并提供给不同的BMSC(BMSC1和BMSC2)以及它们相应的演进节点B(eNodeB)(eNB1.1、eNB1.2、eNB1.n、eNB2.1、eNB2.2、eNB2.n等等)所服务的网络406、408的两个不同部分。eNodeB eNB1.2可以在第一部分406中向接收机设备1 410提供该内容，并且eNodeB eNB2.2可以在第二部分408中向接收机设备2412提供该内容。在网络400的一些部署中，网络部分406和408可以由不同的基础设施供应商来管理，和/或可以是不同的多播广播单频网(MBSFN)。
路径延迟Δ1可以是BMSC 1的处理延迟，以及在从BMSC 1通过相应的eNodeB(eNB1.1、eNB1.2、eNB1.n)向接收机设备1 410提供分段时所经历的延迟。路径延迟Δ2可以是BMSC 2的处理延迟，以及在从BMSC 2通过相应的eNodeB(eNB2.1、eNB2.2、eNB2.n)向接收机设备2 412提供分段时所经历的延迟。第一部分406中的路径延迟Δ1可以与第二部分408中的路径延迟Δ2不同。因此，由于不同的部分406、408中的不同的路径延迟Δ1和Δ2，与相同分段的内容在接收机设备2 412处变得可用相比，该内容可能在不同的时间，在接收机设备1 410处变得可用。不同的路径延迟Δ1和Δ2可能是由各种因素造成的，其包括：具有多个基础设施供应商的网络部署和/或接收机设备在对于相同内容使用不同MSP的不同MBSFN之间的移动性。
当路径延迟小于所估计的网络400的最差情况延迟时，与提供给接收机设备的MPD中所列出的可用开始时间相比，接收机设备1 410或接收机设备2 412处的内容的分段的实际可用开始时间。例如，在一些同步网络部署中，路径延迟Δ1可能比路径延迟Δ2更短，并且为了应对网络中最长的路径延迟(例如，Δ2)，网络中的MPD可以使可用开始时间同步，以匹配与更长的路径延迟Δ2相称的可用性开始时间。在这种例子中，接收机设备2 412中的分段可用性时间轴可以偏移大约Δ2-Δ1，并且在重放开始之前，接收机设备1 410可能不必要地存储至少Δ2-Δ1的第一接收段。各种实施例可以使得接收机设备1 410和/或接收机设备2412能够考虑它们实际经历的路径延迟Δ1和/或Δ2，并在它们实际可用时请求内容的分段。
图5A示出了基于确定的第一FDT接收时间，响应于分段索引改变来修改分段可用开始时间的实施例方法500a。在一个实施例中，方法500a的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法500a的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框502中，多播服务设备客户端或者客户端应用可以接收MPD。在一个实施例中，接收机设备可以经由OTA传输来接收MPD。在一个实施例中，MPD可以是从网络接收的，并且前端可以将分段的可用开始时间设置在MPD中。在一个实施例中，MPD中的可用开始时间可以由网络进行设置，并且可以考虑从生成分段的编码器到接收机设备的最差情况端到端传输延迟。在一个实施例中，客户端应用可以经由多播服务设备客户端来接收MPD。在方框504中，多播服务设备客户端或者客户端应用可以接收在MPD中描述的一个或多个分段的一个或多个分段片段。例如，这些分段片段可以是在多播信道(MCH)调度周期(MSP)期间通过OTA来接收的。
在判断框506处，多播服务设备客户端或者客户端应用可以判断是否发生分段索引改变。在一个实施例中，多播服务设备客户端或者客户端应用可以通过将两个连续接收的分段片段中指示的分段索引进行彼此之间比较，来判断是否发生分段索引改变，并且分段索引改变可以通过连续接收的分段片段的分段索引之间的不匹配来指示。在各个实施例中，可以将接收的分段片段进行彼此之间比较，而不管每个分段片段相关联的分段的类型(例如，视频或音频)。响应于确定没有发生分段索引改变(即，判断框506＝“否”)，多播服务设备客户端或者客户端应用可以继续在方框504中接收分段片段。
响应于确定发生了分段索引改变(即，判断框506＝“是”)，在方框508中，多播服务设备客户端或者客户端应用可以将接收的最新分段设置为基分段。在一个实施例中，接收的最新分段可以是具有最高索引号的分段。在方框510中，多播服务设备客户端或者客户端应用可以接收针对基分段的第一FDT。在方框512中，多播服务设备客户端或者客户端应用可以确定第一FDT接收时间(1stFDTArrivalTimeBaseSegment(第一FDT到达时间基分段))。在一个实施例中，多播服务设备客户端或者客户端应用可以将如用于基分段的第一FDT中所描述的与基分段相对应的对象的第一分组的接收时间，确定为第一FDT接收时间(1stFDTArrivalTimeBaseSegment)。
在方框514中，多播服务设备客户端或者客户端应用可以将用于基分段的调整的可用开始时间(例如，AvailabilitySBASE)确定为：第一FDT接收时间(例如，1stFDTArrivalTimeBaseSegment)加上每分段的分段片段数量(SF)乘以MSP加上裕度(M)，例如：
AvailabilitySBASE＝1stFDTArrivalTimeBaseSegment+(SF*MSP)+M在一个实施例中，MSP的值可以是预先提供给接收机设备的缺省值。在另一个实施例中，MSP可以是与用于接收分段的临时移动组标识符(TMGI)相关联的变量值。裕度(M)可以是用于考虑接收机设备的处理延迟的额外裕度，其可以预先配置在接收机设备的存储器中。在一个实施例中，多播服务设备客户端或者客户端应用可以至少部分地基于与基分段相对应的对象的第一分组的接收时间，来确定基分段的调整的可用开始时间。
在方框516中，多播服务设备客户端或者客户端应用可以将延迟调整确定为：用于基分段的调整的可用开始时间(AvailabilitySBASE)和接收的MPD中的基分段的可用开始时间之间的差值。在方框518中，多播服务设备客户端或者客户端应用可以将MPD中的分段的可用开始时间偏移该延迟调整量。用此方式，多播服务设备客户端或者客户端应用可以对可用开始时间进行偏移，以反映这些分段在接收机设备处实际可用的时间。
在可选框520中，多播服务设备客户端或者客户端应用可以将修改的MPD存储在可用于该多播服务设备客户端或者客户端应用的存储器中。在一个实施例中，存储经修改的MPD可以包括：在与一些或所有MPD存储在接收机设备的URL相关联的存储器位置处，存储经修改的MPD。在另一个实施例中，客户端应用可以不专门地将经修改的MPD存储在单独的存储器位置。相反，在可选框522中，客户端应用可以仅仅使用修改的MPD，以在偏移的可用开始时间请求分段。
图5B示出了用于基于确定的第一FDT接收时间，响应于分段索引改变来生成延迟调整消息的实施例方法500b。方法500b类似于上面参照图5A所描述的方法500a，除了可以在无需对分段可用性时间轴进行偏移的情况下，生成用于指示分段可用性时间轴中的偏移的延迟调整消息之外。在一个实施例中，方法500b的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法500b的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框502、504、506、508、510、512、514和516中，多播服务设备客户端或者客户端应用可以执行上面参照图5A所描述的方法500a的类似编号方框的操作，以确定延迟调整。
在方框524中，多播服务设备客户端或者客户端应用可以将延迟调整的指示存储在延迟调整消息中。在一个实施例中，延迟调整消息可以是一个数据文件，其中客户端应用可以使用该数据文件来确定用于考虑接收机设备处的分段可用性的延迟调整，可以使用该延迟调整消息对一个或多个分段的可用开始时间进行偏移。在一个实施例中，可以将延迟调整消息存储在与一些或所有延迟调整消息存储在接收机设备的URL相关联的存储器位置。在可选框521中，多播服务设备客户端可以向客户端应用发送延迟调整消息，以便该客户端应用在对一个或多个分段的可用开始时间进行偏移时使用。在另一个实施例中，可以不发送延迟调整消息，而是根据客户端应用的需要来从其存储的存储器位置进行访问或者请求。
图6A示出了用于基于确定的第一FDT接收时间，响应于基URL改变来修改分段可用开始时间的实施例方法600a。方法600a类似于上面参照图5A所描述的方法500a，除了以下方面之外：不是接收到用于指示来自新分段的分段片段的分段索引改变，而是分段之间的基URL改变可以指示已接收到新分段的分段片段。在一个实施例中，方法600a的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法600a的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框502和504中，多播服务设备客户端或者客户端应用可以执行上面参照图5A所描述的方法500a的类似编号方框的操作。
在方框507中，多播服务设备客户端或者客户端应用可以判断基URL改变是否发生。在一个实施例中，多播服务设备客户端或者客户端应用可以通过将两个连续接收的分段片段中指示的基URL进行彼此之间比较，来判断是否发生基URL改变，并且可以通过连续接收的分段片段的基URL之间的不匹配来指示基URL改变。例如，虽然用于分段的每一个分段片段的整体URL是唯一的，但对于共同分段的每个分段片段来说，形成该URL的初始部分的基URL可以是相同的。因此，基URL(例如，URL的初始部分)的改变可以指示正在接收新分段的片段。响应于确定基URL改变没有发生(即，判断框507＝“否”)，多播服务设备客户端或者客户端应用可以继续在方框504中接收分段片段。响应于确定发生了基URL改变(即，判断框507＝“是”)，多播服务设备客户端或者客户端应用可以执行上面参照图5A所描述的方法500a的类似编号方框508、510、512、514、516、518、520和522的操作。
图6B示出了基于确定的第一FDT接收时间，响应于基URL改变来生成延迟调整消息的实施例方法600b。实施例方法600b类似于上面参照图6A所描述的方法600a，除了可以在无需对分段可用性时间轴进行偏移的情况下，生成用于指示分段可用性时间轴中的偏移的延迟调整消息之外。在一个实施例中，方法600b的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法600b的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框502、504、506、508、510、512、514和516中，多播服务设备客户端或者客户端应用可以执行上面参照图6A所描述的方法600a的类似编号方框的操作，以确定延迟调整。在方框524和526中，多播服务设备客户端或者客户端应用可以执行上面参照图5B所描述的方法500b的类似编号方框的操作，以存储和发送延迟调整文件。在一个实施例中，方法600b的操作可以由多播服务设备客户端或客户端应用与上面分别参照图5A和5B描述的方法500a或500b的操作并行地执行。
图7根据一个实施例，示出了可用性时间轴、MPD可用开始时间、传输时间和到达时间。如图7中所示，可以从源向BMSC发送分段1、2、3、4和5，并且BMSC可以将分段1、2、3、4和5分割成一系列分段片段，以便在每个MSP持续时间进行广播。该BMSC处理和同步调度操作可以在这些分段片段向接收机设备的OTA传输中造成延迟，并且每个MSP持续时间可以发送来自一个以上的分段的片段。在BMSC进行这些分段的OTA传输之后的某个时段，可以在接收机设备处对这些分段进行解码并变得可用。
在上面参照图5A、5B、6A和6B所讨论的各个实施例中，在捕获开始之后，随着接收到分段片段，多播服务设备客户端或客户端应用可以对分段片段的属性(例如，分段索引或者基URL)进行比较，直到通过这些属性的不匹配来识别新分段的分段片段为止。如图7中所示，当接收到用于分段2的最后FDT和用于分段3的第一FDT时，可以发生这种不匹配。基于用于分段3的第一FDT的到达时间，根据上面参照图5A、5B、6A和6B所讨论的方法500a、500b、600a和600b，多播服务设备客户端或客户端应用可以将分段的可用开始时间指示成：FDT到达时间加上每分段的分段片段数量(SF)乘以MSP加上裕度(M)(例如，(SF*MSP)+M))。修改的MPD可以相应地指示用于分段3的可用开始时间，每个后续分段的可用开始时间(例如，分段4的可用开始时间)可以是从修改的MPD中的分段3的指示的可用开始时间的连续分段持续时间。因此，可以在第一步骤中确定基分段的可用开始时间，可以在第二步骤中调整MPD，使得MPD中的基分段的可用开始时间与在第一步骤中确定的基分段的可用开始时间相匹配。
图8A示出了用于基于任何确定的FDT接收时间，在单播模式下修改分段可用开始时间的实施例方法800a。在一个实施例中，方法800a的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法800a的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。如上面所讨论的，在方框502中，多播服务设备客户端或者客户端应用可以接收MPD。在另一个实施例中，可以使用FDT来确定分段索引或者基URL的改变，实际到达时间可以是接收到携带文件的标识符(在FLUTE的情况下，传输对象标识符TOI)的第一分组的时间。
在判断框802中，多播服务设备客户端或者客户端应用可以判断单播提取是否活动。在一个实施例中，单播提取可以是在模式1下活动(例如，在启动时使用单播来请求分段)，或者在模式2下活动(例如，在任何时间使用单播)。在模式1或模式2下，单播提取可以使多播服务设备客户端或者客户端应用能够经由单播来请求分段，而无需等待这些分段的广播/多播接收。可以以任何方式来指示单播提取活动或者不活动，例如，通过接收机设备的存储器中的与单播提取相关联的标志设置。响应于确定单播提取是不活动的(即，判断框802＝“否”)，多播服务设备客户端或者客户端应用可以转到图5A的方框502，以执行方法500a的操作。
响应于确定单播提取是活动的(即，判断框802＝“是”)，在方框806中，多播服务设备客户端或者客户端应用可以经由广播或多播传输来接收FDT。该FDT可以是接收的OTA，可以是针对一个分段的任何FDT(例如，第一FDT、最后FDT或者中间FDT)。在方框808中，多播服务设备客户端或者客户端应用可以将与所接收的FDT相关联的分段设置为基分段。在方框810中，多播服务设备客户端或者客户端应用可以确定接收的FDT接收时间(FDTArrivalTimeBaseSegment(FDT到达时间基分段))。
在方框812中，多播服务设备客户端或者客户端应用可以将用于基分段的调整的可用开始时间(例如，AvailabilitySBASE)确定为：FDT接收时间(例如，FDTArrivalTimeBaseSegment)加上每分段的分段片段数量(SF)乘以MSP加上裕度(M)，例如：
AvailabilitySBASE＝FDTArrivalTimeBaseSegment+(SF*MSP)+M.
在一个实施例中，MSP的值可以是预先提供给接收机设备的缺省值。在另一个实施例中，MSP可以是与用于接收分段的临时移动组标识符(TMGI)相关联的变量值。裕度(M)可以是用于考虑接收机设备的处理延迟的额外裕度，其可以被配置成接收机设备的存储器中的预先配置的值。在方框516、518、520和522中，多播服务设备客户端或者客户端应用可以执行上面参照图6A所描述的方法600a的类似编号方框的操作，以确定延迟调整。
图8B示出了用于基于任何确定的FDT接收时间，在单播模式下生成延迟调整消息的实施例方法800b。方法800b类似于上面参照图8A所描述的方法800a，除了可以在无需对分段可用性时间轴进行偏移的情况下，生成用于指示分段可用性时间轴中的偏移的延迟调整消息之外。在一个实施例中，方法800b的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法800b的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框502、802、804、806、808、810、812和516中，多播服务设备客户端或者客户端应用可以执行上面参照图8A所描述的方法800a的类似编号方框的操作，以确定延迟调整。在方框524和526中，多播服务设备客户端或者客户端应用可以执行上面参照图5B所描述的方法500b的类似编号方框的操作，以存储和发送延迟调整文件。
图9A是用于根据一个实施例，示出多播服务设备客户端和接收机设备上的应用/DASH客户端之间的交互的消息流图。应用/DASH客户端可以通过向多播服务设备客户端服务发现功能发送请求，来请求激活一个服务。多播服务设备客户端服务发现功能可以接收该服务请求，确定该服务是有效的，向多播服务设备客户端流媒体功能发送服务信息以激活该服务。多播服务设备客户端流媒体功能可以确定该服务是有效的，向多播服务设备客户端调制解调器接口发送用于激活该服务的临时移动组标识符(TMGI)的请求。此外，多播服务设备客户端流媒体功能还可以请求多播服务设备客户端数据传输功能激活FLUTE会话，请求多播服务设备客户端数据传输功能捕获分段URL。
一旦在移动控制信道(MCCH)中激活了临时移动组标识符，该设备可以对媒体传输信道(MTCH)进行解码。可以将调制解调器所接收的IP分组，从多播服务设备客户端调制解调器接口传送到多播服务设备客户端数据传输功能。可选地，MSD调制解调器接口可以向MSP流媒体功能传送更新的承载描述。多播服务设备客户端数据传输功能可以向MSP流媒体功能发送文件捕获请求。随着接收到分段N、N+1、N+2等等，并对它们进行了解码，还可以将它们发送给多播服务设备客户端DASH网关。
在一个实施例中，当多播服务设备客户端流媒体功能确定在接收的分段片段之间存在索引改变时，多播服务设备客户端服务发现功能可以向多播服务设备服务发现功能指示基分段FDT接收时间和索引号，其中多播服务设备服务发现功能可以修改MPD以调整可用开始时间，如上所述。多播服务设备客户端服务发现功能可以向多播服务设备客户端DASH网关发送修改后的MPD。多播服务设备客户端流媒体功能可以向应用/DASH客户端指示已启动该服务。
应用/DASH客户端可以发起媒体播放器，向媒体播放器指示修改后的MPD的URL。应用/DASH客户端可以按照修改的MPD URL，发送针对修改的MPD的HTTP Get()请求。多播服务设备客户端DASH网关可以使用修改的MPD进行响应。应用/DASH客户端可以按照初始分段(IS)URL，来发送针对该IS的HTTP Get()请求。多播服务设备客户端DASH网关可以使用该IS进行响应。应用/DASH客户端可以发送针对分段N-1的HTTP Get()请求。没有可用的分段N-1，多播服务设备客户端DASH网关可以以没有发现该分段(例如，404没有发现)进行响应。应用/DASH客户端可以发送针对分段N+1的HTTP Get()请求。多播服务设备客户端DASH网关可以使用分段N+1进行响应。
图9B是用于根据另一个实施例，示出多播服务设备客户端和接收机设备上的应用/DASH客户端之间的交互的消息流图。图9B中所示出的流程类似于上面参照图9A所描述的那些，除了在图9B中可以独立地捕获视频和音频分段之外。随着多播服务设备客户端数据传输功能发送针对编号为M的视频分段和编号为M的音频分段的捕获请求，其还可以发送针对编号为M+1的下一个视频分段的捕获请求。在一个实施例中，当多播服务设备客户端流媒体功能确定接收的视频分段M和视频分段M+1之间的索引改变时，多播服务设备客户端服务发现功能可以指示视频分段M+1是基分段，向多播服务设备服务发现功能指示基分段FDT接收时间和索引号，其中多播服务设备服务发现功能可以修改MPD以调整可用开始时间，如上面所讨论的。多播服务设备客户端服务发现功能可以向多播服务设备客户端DASH网关发送该修改的MPD。多播服务设备客户端流媒体功能可以向应用/DASH客户端指示已启动该服务。
应用/DASH客户端可以发起媒体播放器，向媒体播放器指示修改的MPD的URL。应用/DASH客户端可以按照该MPD URL，发送针对修改的MPD的HTTP Get()请求。多播服务设备客户端DASH网关可以使用修改的MPD进行响应。应用/DASH客户端可以按照初始分段(IS)URL，发送针对IS的HTTP Get()请求。多播服务设备客户端DASH网关可以使用该IS进行响应。应用/DASH客户端可以发送针对音频分段M的HTTP Get()请求，并接收音频分段M。在一个实施例中，可以经由单播提取(当其活动时)来接收视频分段M，当视频分段M+1和音频分段M+1变得经由广播或者多播可用时，可以向多播服务设备流媒体功能通知这些分段的可用性。
虽然图9A和图9B示出了多播服务设备服务发现功能修改MPD，但在其它实施例中，多播服务设备服务发现功能可以生成延迟调整消息或者包括延迟调整的指示的文件，其中，可以使用该延迟调整来偏移MPD中的可用开始时间，使得这些时间反映分段实际可用于接收机设备上的应用/DASH客户端的时间。因此，多播服务设备客户端或者应用/DASH客户端可以使用该延迟调整或文件，对MPD中的可用开始时间进行偏移，和/或在分段实际可用于接收机设备上的应用/DASH客户端时请求分段。
图10是示出基于延迟调整消息，调整可用开始时间的实施例方法的处理流程图。在一个实施例中，方法1000的操作可以由在接收机设备(例如，智能电话)的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框1002中，客户端应用可以接收MPD。在一个实施例中，客户端应用可以经由多播服务设备客户端，通过接收机设备上的HTTP服务器来接收MPD。在方框1004中，客户端应用可以接收延迟调整消息。在一个实施例中，客户端应用可以经由多播服务设备客户端，通过接收机设备上的HTTP服务器来接收延迟调整消息。
在方框1006中，客户端应用可以基于该延迟调整消息，对MPD中的一些或所有分段的可用开始时间进行偏移。在一个实施例中，基于延迟调整消息对可用开始时间进行偏移，可以包括：使用延迟调整的指示和/或其它值来调整每个分段在接收机设备上可用的时间。在一个实施例中，对可用开始时间进行偏移可以包括：修改MPD自身以生成修改的MPD。在另一个实施例中，对可用开始时间进行偏移可以涉及：在不修改MPD自身的情况下，改变分段在接收机设备上可用的时间的指示。在对MPD进行修改的实施例中，在可选框1008中，客户端应用可以将修改的MPD存储在可用于该客户端应用的存储器中。在方框1010中，客户端应用可以在经偏移的可用开始时间，请求分段。
图11A是示出用于处理MPD更新的实施例方法的处理流程图。在一个实施例中，方法1100a的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1100a的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框1102中，多播服务设备客户端或者客户端应用可以接收MPD更新。在一个实施例中，MPD更新可以是从网络接收的，并且前端可以将分段的可用开始时间设置在MPD更新中。在一个实施例中，MPD更新中的可用开始时间可以由网络进行设置，并且可以考虑从生成分段的编码器到接收机设备的最差情况端到端传输延迟。在一个实施例中，客户端应用可以经由多播服务设备客户端来接收MPD。
在方框1104中，多播服务设备客户端或者客户端应用可以确定MPD更新中的可用开始时间(AST)集。在判断框1106处，多播服务设备客户端或者客户端应用可以判断在最初接收的MPD和MPD更新之间是否发生AST改变。例如，多播服务设备客户端或者客户端应用可以将MPD的任何修改之前在原始MPD中指示的AST，与MPD更新中的AST进行比较。
响应于确定MPD更新中的AST与原始AST相同(即，判断框1106＝“否”)，在方框1108中，多播服务设备客户端或者客户端应用可以调整MPD更新中的AST，以匹配先前修改的MPD中的修改的AST。响应于确定这些AST不匹配(即，判断框1106＝“是”)，多播服务设备客户端或者客户端应用可以将MPD更新中的AST修改下面二者之间的差值：所确定的基分段的调整的可用开始时间(AvailabilitySBase)和在修改之前的原始AST之间的差值。
图11B示出了用于处理MPD更新的实施例方法1100b。方法1100b类似于上面参照图11A所描述的方法1100a，除了MPD更新中的AST的改变可以触发可用开始时间重新计算之外。在一个实施例中，方法1100b的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1100b的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框1102、1104、1106和1108中，多播服务设备客户端或者客户端应用可以执行上面参照图11A所描述的方法1100a的类似编号方框的操作。
响应于确定AST不匹配(即，判断框1106＝“是”)，在方框1112中，多播服务设备客户端或者客户端应用可以触发可用开始时间的重新计算。例如，多播服务设备客户端或者客户端应用可以发送中断，其造成多播服务设备客户端或者客户端应用执行上面参照图5A、5B、6A、6B、8A或8B所描述的方法500a、500b、600a、600b、800a或800b中的一个的操作，以修改MPD更新中的可用开始时间。作为另外的示例，触发可用开始时间重新计算可以包括：向激活与该分段相关联的服务的应用发出通知。
图12根据另一个实施例，示出了可用性时间轴、MPD可用开始时间、传输时间和到达时间。图12示出了随着时间的推移，虽然可以确定诸如分段3之类的分段的可用开始时间，并对可用开始时间进行偏移以考虑分段何时在接收机设备处实际可用(例如，基于其第一FDT的接收时间)，但接收机设备上的定时漂移可能导致修改的MPD中的可用开始时间不再有效。
在一些时间N之后，可以在修改的MPD中指示可用开始时间(AvailabilitytimeS4+N)，DASH客户端可以发现针对分段S4+N的HTTP请求。但是，由于接收机设备定时漂移，DASH客户端可能在没有接收分段S4+N的情况下，耗尽HTTP重试。因此，由于接收机设备定时漂移，分段S4+N可能在DASH客户端停止尝试请求分段S4+N之后变得可用。在各个实施例中，在耗尽DASH客户端的HTTP重试(例如，一旦请求了分段S4+N+1)之后的分段S4+N的接收，可以触发可用开始时间的重新计算。用此方式，该可用开始时间重新计算可以考虑接收机设备定时漂移。
图13示出了用于应对接收机设备定时漂移的实施例方法1300。在一个实施例中，方法1300的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1300的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框1302中，多播服务设备客户端可以接收针对分段的HTTP请求，或者客户端应用可以生成HTTP请求。该HTTP请求可以指示分段的URI和分段号。在判断框1304中，多播服务设备客户端或者客户端应用可以判断当前是否正在跟踪任何分段。在各个实施例中，当与分段相关联的HTTP请求失败时，可以跟踪该分段。
响应于确定没有在跟踪分段(即，判断框1304＝“否”)，在方框1306中，多播服务设备客户端或者客户端应用可以判断所述请求是否成功。例如，多播服务设备客户端或者客户端应用可以判断是否接收到用于指示所请求的分段不可用的400系列HTTP响应，以判断该请求是否成功。响应于该请求是成功的(即，判断框1306＝“是”)，在方框1308中，多播服务设备客户端或者客户端应用可以清除跟踪记录，在方框1302中，接收或者生成针对下一个分段的下一个HTTP请求。
响应于确定所述请求失败(即，判断框1306＝“否”)，在方框1310中，多播服务设备客户端或者客户端应用可以开始跟踪所请求的分段，在方框1302中，再次接收或者生成针对相同分段的HTTP请求。
响应于确定正在跟踪分段(即，判断框1304＝“是”)，在判断框1312中，多播服务设备客户端或者客户端应用可以判断是否正在跟踪所请求的分段。响应于确定正在跟踪所请求的分段(即，判断框1312＝“是”)，如上面所讨论的，在方框1306、1308和1310中，多播服务设备客户端或者客户端应用可以判断该请求是否成功，清除跟踪记录或者继续跟踪分段。
响应于确定正在跟踪的分段不是所请求的分段(即，判断框1312＝“否”)，在方框1314中，多播服务设备客户端或者客户端应用可以判断所跟踪的分段是否处于高速缓存中(例如，处于分配给接收的分段存储的存储器位置中)。用此方式，多播服务设备客户端或者客户端应用可以检查多播服务设备客户端或客户端应用先前请求但未能接收的分段是否在随后已经被接收。
响应于确定所跟踪的分段不在高速缓存中(即，判断框1314＝“否”)，在方框1316中，多播服务设备客户端或者客户端应用可以清除跟踪记录。在可选的实施例中，在方框1318中，多播服务设备客户端或者客户端应用可以判断自从请求上一个新的分段号以来，是否流逝了分段持续时间的90％(例如，.9*SD)。用此方式，可以将其中一次请求多个分段的启动场景与大约每个分段持续时间发生的定期定时请求进行区分。在这种可选的实施例中，响应于确定没有流逝分段持续时间的90％(即，判断框1318＝“否”)，在方框1302中，多播服务设备客户端或者客户端应用可以接收或者生成针对一个分段的HTTP请求。虽然示出成分段持续时间的90％(例如，.9*SD)，但可以选择分段持续时间的任何百分比值。例如，可以使用分段持续时间的10％、50％、95％或者任何其它百分比值，来替代在本文所描述的例子中的分段持续时间的90％。
在方框1316中清除跟踪记录之后，或者在可选的实施例中，响应于确定已流逝分段持续时间的90％(即，判断框1318＝“是”)，在方框1306、1308和1310中，多播服务设备客户端或者客户端应用可以判断所述请求是否成功，并清除跟踪记录或者继续跟踪分段。
响应于确定所跟踪的分段在高速缓存中(即，判断框1314＝“否”)，在方框1112中，多播服务设备客户端或者客户端应用可以触发可用开始时间的重新计算。例如，多播服务设备客户端或者客户端应用可以发送中断，其造成多播服务设备客户端或者客户端应用执行上面参照图5A、5B、6A、6B、8A或8B所描述的方法500a、500b、600a、600b、800a或800b中的一个的操作，以修改MPD中的可用开始时间。用此方式，可以通过分段的迟到来识别接收机设备处的定时漂移，多播服务设备客户端或者客户端应用可以考虑该定时漂移。
图14示出了用于标记失败的HTTP记录的实施例方法1400。在一个实施例中，方法1400的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1400的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在各个实施例中，方法1400的操作可以结合下面参照图15A和图15B所描述的方法1500a和/或1500b的操作来执行。
在方框1402中，多播服务设备客户端或者客户端应用可以接收分段。例如，该分段可以是经由广播或者多播OTA传输来接收的。在判断框1404中，多播服务设备客户端或者客户端应用可以判断接收的分段是否正在被跟踪。例如，多播服务设备客户端或者客户端应用可以判断是否存在与接收到的分段的URI和/或分段索引相关联的失败的HTTP记录。响应于确定该分段没有在被跟踪(即，判断框1404＝“否”)，在方框1406中，多播服务设备客户端或者客户端应用可以不采取动作。响应于确定该分段正在被跟踪(即，判断框1408＝“是”)，多播服务设备客户端或者客户端应用可以将该失败的HTTP记录标记成“已接收分段”。用此方式，可以识别与后来接收的分段相关联的失败的HTTP请求，并与和未接收的分段相关联的失败的HTTP请求进行区分。
图15A示出了用于应对接收机设备定时漂移的实施例方法1500a。在一个实施例中，方法1500a的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1500a的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在各个实施例中，方法1500a的操作可以结合上面参照图14所描述的方法1400的操作来执行。
在方框1502中，多播服务设备客户端或者客户端应用可以接收针对分段的HTTP请求，或者客户端应用可以生成HTTP请求。该HTTP请求可以指示分段的URI和分段号。在判断框1504中，多播服务设备客户端或者客户端应用可以判断在该请求中是否指示新的URI。例如，多播服务设备客户端或者客户端应用可以将该HTTP请求中的URI与前一HTTP请求中的URI进行比较，以判断该URI是否是新的。
响应于确定该URI是新的(即，判断框1504＝“否”)，在方框1506中，多播服务设备客户端或者客户端应用可以可以判断该请求是否成功。例如，多播服务设备客户端或者客户端应用可以判断是否接收到用于指示所请求的分段不可用的400系列HTTP响应，以判断该请求是否成功。响应于确定该请求是成功的(即，判断框1506＝“是”)，在方框1508中，多播服务设备客户端或者客户端应用可以清除针对该URI的任何失败的HTTP记录。
响应于确定该URI不是新的(即，判断框1504＝“是”)，在方框1510中，多播服务设备客户端或者客户端应用可以判断所述请求是否成功。例如，多播服务设备客户端或者客户端应用可以判断是否接收到用于指示所请求的分段不可用的400系列HTTP响应，以判断该请求是否成功。响应于确定该请求失败(即，判断框1510＝“否”)，在方框1512中，多播服务设备客户端或者客户端应用可以增加针对该URI的失败的HTTP记录，将失败的URI记录中的初始时间戳设置为当前时间。
响应于确定所述请求不成功(即，判断框1506＝“否”)，或者在方框1512中增加了针对URI的失败的HTTP记录之后，在方框1516中，多播服务设备客户端或者客户端应用可以将针对该URI的失败的HTTP记录中的最后时间戳设置为当前时间。用此方式，针对URI的失败的HTTP记录中的从初始时间戳到最后时间戳的时间，可以指示用于该失败的HTTP记录的跟踪时段。
响应于在方框1508中清除了针对URI的失败的HTTP记录，在方框1516中，设置最后时间戳，或者确定所述请求成功(即，判断框1510＝“是”)，在方框1520中，多播服务设备客户端或者客户端应用可以清除存储的比记录跟踪时段最大值更长的任何失败的HTTP记录。例如，记录跟踪时段最大值可以是FFR_period(例如，十秒)的两倍。可以清除(例如，删除)失败的HTTP记录中的从初始时间戳到最后时间戳的时间超过该记录跟踪时段最大值的失败的HTTP记录。
在判断框1522中，多播服务设备客户端或者客户端应用判断在可用于多播服务设备客户端或客户端应用的存储器中，是否存在最后时间戳比当前时间更早一个分段持续时间的被标记成“已接收分段”的任何失败的HTTP记录。响应于确定没有任何被标记成“已接收分段”的失败的HTTP记录比一个分段持续时间更早(即，判断框1522＝“否”)，在方框1502中，多播服务设备客户端或者客户端应用可以接收或者生成下一个HTTP请求。
响应于确定被标记成“已接收分段”的失败的HTTP记录比一个分段持续时间更早(即，判断框1522＝“是”)，在方框1112中，多播服务设备客户端或者客户端应用可以触发可用开始时间的重新计算。例如，多播服务设备客户端或者客户端应用可以发送中断，其造成多播服务设备客户端或者客户端应用执行上面参照图5A、5B、6A、6B、8A或8B所描述的方法500a、500b、600a、600b、800a或800b中的一个的操作，以修改MPD中的可用开始时间。用此方式，可以通过分段的迟到来识别接收机设备处的定时漂移，多播服务设备客户端或者客户端应用可以考虑该定时漂移。
图15B示出了用于应对接收机设备定时漂移的实施例方法1500b。实施例方法1500b类似于上面参照图15A所描述的方法1500a，除了在触发可用开始时间重新计算之前引入延迟之外。在一个实施例中，方法1500b的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1500b的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在方框1502、1504、1506、1508、1510、1512、1516、1518、1520和1522中，多播服务设备客户端或者客户端应用可以执行上面参照图15A所描述的方法1500a的类似编号方框的操作。
响应于确定被标记成“已接收分段”的失败的HTTP记录比一个分段持续时间更早(即，判断框1522＝“是”)，在方框1524中，多播服务设备客户端或者客户端应用可以判断是否已经引入了延迟。响应于确定没有引入延迟(即，判断框1524＝“否”)，在方框1528中，多播服务设备客户端或者客户端应用可以引入分段持续时间的90％(0.9*SD)的延迟，取消标记所有失败的HTTP记录。用此方式，可以不用立即触发可用开始时间重新计算，失败的HTTP记录所对应的分段可能需要在这些分段被重新标记为“已接收分段”之前进行第二次接收。分段的这种强制重新请求可以使得能在分段各自的可用开始时间结束之前接收到分段时，避免可用开始时间的重新计算。在方框1502中，多播服务设备客户端或者客户端应用可以接收或者生成下一个HTTP请求。
响应于确定已经引入了延迟(即，判断框1524＝“是”)，多播服务设备客户端或者客户端应用可以判断是否已引入了超过两个分段持续时间的延迟。响应于确定没有引入超过两个分段持续时间的延迟(即，判断框1526＝“否”)，在方框1502中，多播服务设备客户端或者客户端应用可以接收或者生成下一个HTTP请求。
响应于确定已引入超过两个分段持续时间的延迟(即，判断框1526＝“是”)，在方框1112中，多播服务设备客户端或者客户端应用可以触发可用开始时间的重新计算。例如，多播服务设备客户端或者客户端应用可以发送中断，其造成多播服务设备客户端或者客户端应用执行上面参照图5A、5B、6A、6B、8A或8B所描述的方法500a、500b、600a、600b、800a或800b中的一个的操作，以修改MPD中的可用开始时间。用此方式，可以通过分段的迟到来识别接收机设备处的定时漂移，多播服务设备客户端或者客户端应用可以考虑该定时漂移。
图16示出了用于通过URL匹配来确定分段索引的实施例方法1600。在一个实施例中，方法1600的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法1600的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在各个实施例中，方法1600的操作可以结合上面分别参照图5A和图5B所描述的方法500a或500b的操作来执行。例如，可以在接收到MPD(图5A或图5B的方框502)和分段片段(图5A或图5B的方框504)之后，在判断是否发生分段索引改变(图5A或图5B的方框506)之前，执行方法1600的操作。
在方框1602中，多播服务设备客户端或者客户端应用可以确定所接收分段的URL。例如，用于所接收分段的URL可以遵循URL模板“xxx$number$yyy”。再举一个例子，与相同持续时间相对应的音频和视频分段可以在URL模板中具有相同的$time$标签。在方框1604中，多播服务设备客户端或者客户端应用可以爬取MPD以找到该MPD中的初始时段和表示对，将初始时段和表示对设置为当前时段和表示对。在各个MPD中，爬取MPD可以包括：对表示MPD的文件(例如，XML文件)进行解析。如本文所讨论的，时段和表示对可以是MPD所规定的唯一表示。MPD中规定的每个时段可以包括用于一个或多个表示的属性(例如，一个或多个适配集)，来自所述一个或多个表示的时段和单个表示的组合可以构成一个时段和表示对。MPD中的时段和表示对可以包括用于描述服务的每个时段和表示的属性，其包括时段边界、URL格式、分段持续时间、分段时间尺度、起始编号、带宽、时段标识符等等。
在方框1606中，多播服务设备客户端或者客户端应用可以将所确定的接收的分段的URL与MPD中的当前时段和表示对进行比较。例如，多播服务设备客户端或者客户端应用可以将接收的分段中的URL与所述时段和表示对中指示的URL进行比较。
在判断框1608中，多播服务设备客户端或者客户端应用可以判断所确定的分段的URL是否与当前时段和表示对中的URL相匹配。响应于确定URL不匹配(即，判断框1608＝“否”)，在方框1614中，多播服务设备客户端或者客户端应用可以爬取MPD以找到MPD中的下一个时段和表示对，将下一个时段和表示对设置为当前时段和表示对。在方框1606中，多播服务设备客户端或者客户端应用可以将所确定的URL与MPD中的新的当前时段和表示对进行比较。
响应于确定URL匹配(即，判断框1608＝“是”)，在方框1610中，多播服务设备客户端或者客户端应用可以至少部分地基于当前时段和表示对以及所确定的URL，确定潜在分段号匹配。例如，多播服务设备客户端或者客户端应用可以通过在分段URL的末尾处识别分段索引，来至少部分地基于URL来确定潜在分段号，其中在分段URL的末尾前面至少有一个非数字字符，并且可选地在非数字字符后面跟着一个文件扩展名。
在判断框1612中，多播服务设备客户端或者客户端应用可以判断该潜在分段号是否与当前时段和表示对的分段边界相对应。可以基于MPD的period@start属性或者period@duration属性，或者通过确定下一个时段起始属性和当前时段起始属性之间的差值，来确定时段的边界。用此方式，多播服务设备客户端或者客户端应用可以验证分段号是否与位于当前时段的边界中的分段相对应。
响应于确定分段号不位于当前时段的边界中(即，判断框1612＝“否”)，在方框1614中，多播服务设备客户端或者客户端应用可以爬取MPD以找到MPD中的下一个时段和表示对，并且将下一个时段和表示对设置为当前时段和表示对。如果发现不匹配，则该过程失败，并且多播服务设备客户端或者客户端应用可以不向MPD应用任何调整，或者只增加裕度M来作为针对AST的调整。
响应于确定分段号不位于当前时段的边界中(即，判断框1612＝“是”)，在方框1614中，多播服务设备客户端或者客户端应用可以将用于所接收分段的分段索引设置为等于潜在分段号。
图17A、17B和17C是根据一个实施例的示例性MPD 1700的元素的框图。如图17A、17B和17C中所示，随着爬取MPD以识别时段和表示对，多播服务设备客户端或者客户端应用可以识别MPD的关键属性。这些关键元素可以包括：可用开始时间、媒体呈现持续时间、时段、时段开始、时间持续时间、时段基URL、时段分段模板、适配集、适配集基URL、适配集分段模板、表示、表示标识符、表示带宽、表示基URL和表示分段模板。
图18是根据一个实施例的示例性MPD 1800的XML树的框图。如图18中所示，MPD1800可以包括多个时段、适配集和表示。在各个实施例中，多播服务设备客户端或者客户端应用可以顺序地沿着MPD 1800的XML树的每个叶子，从每个时段到其相应的适配集以及到这些适配的每个相应表示，来爬取该MPD 1800的XML树。随着爬取MPD 1800，多播服务设备客户端或者客户端应用可以识别URL(例如，与模板“xxx$number$yyy”匹配的URL的基部分)，以确定与接收的分段的URL相匹配。
图19示出了根据一个示例的分段的可用性时间轴。具体而言，图19示出了如相关联的MPD中所列出的视频服务表示(R1)的分段的可用开始时间，相对于这些分段在接收机设备上的实际可用开始时间。如图19中所示，单一分段持续时间视频服务可以具有以0.5秒的短持续时间分段(S36)结束的第一时段。假定分段S1变得可用于1秒钟时的时段1，分段S36变得可用于36秒钟时的时段1。那么，基于用于分段S36的0.5秒的分段持续时间，分段S36和时段1的可用结束时间可以是36.5秒。
图20是根据示出时段1和2的实施例，单一分段持续时间MPD 2000的示例性架构(schema)部分，其中每个时段具有它们自己相应的适配集1和2，每个适配集具有它们自己的表示1。该MPD根据图19中所示出的时间轴，示出了分段的可用开始时间。
图21是根据一个实施例，示出爬取图20所示出的MPD 2000和匹配时段和表示对中的URL的各种结果的框图。多播服务设备客户端或者客户端应用可以确定所接收的分段2102的URL是“/video150000/0/chunk_41.mp4”，可以尝试将URL 2102与时段和表示对2106进行匹配以发现匹配。用于时段2适配集1表示1的时段和表示对可以与URL 2102相匹配，这是由于带宽15000可以匹配，id 0可以匹配URL 2102中的元素。可以将分段的可用开始时间确定为时段的开始时间35.5s加上1000ms的分段持续时间+分段索引N＝41减去起始分段号40，使得可用开始时间是37.5秒(其位于36.5秒到无穷的时段边界之内)。因此，该匹配是有效的，可以确定用于所接收的分段的分段索引是41。
图22示出了根据一个实施列的分段的可用性时间轴，其中在该实施例中，在MPD中描述了多个分段持续时间。该内容可以具有两个表示：具有1秒分段持续时间的第一表示(R1)和具有2秒分段持续时间的第二表示(R2)。具体而言，图22示出了如相关联的MPD中所列出的表示R1和R2的分段的可用开始时间，相对于这些分段在接收机设备上的实际可用开始时间。如图22中所示，表示R1或R2的第一分段的可用开始时间，取决于该分段所属于的表示的分段持续时间。可以期望这些表示中的一个在一个服务区域中，在任何给定的时间进行广播。
图23是根据示出时段1和2的实施例，两个分段持续时间MPD 2300的示例性架构(schema)部分，其中每个时段具有它们自己相应的适配集1，每个适配集包含分别具有不同的分段持续时间1秒和2秒的两个表示0和1。该示例性MPD与图22中所示出的时间轴相对应于。
图24是根据一个实施例，示出爬取图23所示出的MPD 2300和匹配时段和表示对中的URL的各种结果的框图。多播服务设备客户端或者客户端应用可以确定所接收的分段2402的URL是“/audio30000/1/chunk_6.mp4”，可以尝试将URL 2402与时段和表示对2406进行匹配以发现匹配。用于时段2适配集1表示2的时段和表示对可以与URL 2402相匹配，这是由于带宽30000可以匹配，id 1可以匹配URL 2402中的元素。可以将分段的可用开始时间确定为时段的开始时间8s加上2000ms的分段持续时间+分段索引N＝6减去起始分段号5，使得可用开始时间是12秒(其位于10秒到无穷的时段边界之内)。因此，该匹配是有效的，可以确定用于所接收的分段的分段索引是6。
图25是示出当一个以上的时段和表示对可以与分段的URL相匹配，并具有用于该分段的有效边界时，通过URL匹配来确定分段索引的实施例方法2500。例如，如图26的可用性时间轴中所示，一些服务可以包括重复的分段(例如，广告)，当接收到重复的分段(例如，A3)时，分段URL可以与具有有效时段的一个以上的时段和表示对的URL相匹配。为了选择最佳候选匹配时段和表示耦合，方法2500的操作可以使多播服务设备客户端或者客户端应用将分段号选择成与导致最低AST改变的时段和表示对相对应的分段号。在一个实施例中，方法2500的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法2500的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。在各个实施例中，方法2500的操作可以结合上面分别参照图5A和图5B所描述的方法500a或500b的操作来执行。例如，可以在接收到MPD(图5A或图5B的方框502)和分段片段(图5A或图5B的方框504)之后，在判断是否发生分段索引改变(图5A或图5B的方框506)之前，执行方法2500的操作。
在方框1602-1612中，多播服务设备客户端或者客户端应用可以执行上面参照图16所描述的方法1600的类似编号方框的操作。响应于确定潜在分段号处于当前时段和表示对的分段边界内(即，判断框1612＝“是”)，在方框2502中，多播服务设备客户端或者客户端应用可以将当前时段和表示对与潜在分段号存储成可能匹配。
在判断框2504中，多播服务设备客户端或者客户端应用可以判断是否爬取了整个MPD。响应确定还没有爬取整个MPD(即，判断框2504＝“否”)，在方框1614中，多播服务设备客户端或者客户端应用可以爬取MPD以找到MPD中的下一个时段和表示对，将下一个时段和表示对设置为当前时段和表示对。
响应于确定已爬取整个MPD(即，判断框2504＝“是”)，在方框2506中，多播服务设备客户端或者客户端应用可以确定源自于所有可能的存储的匹配的AST改变。例如，多播服务设备客户端或者客户端应用可以计算源自于分段的接收的AST。可以以任何方式来计算源自于分段的接收的AST，例如，基于上面参照图5A-15B中的任何一个所描述的方法或者基于任何其它方法。例如，一旦发生了分段索引改变，则作为方框2506的一部分，方法2500可以应用图5A或图5B中的过程，以确定MPD时间轴修改。随后，多播服务设备客户端或者客户端应用可以从所计算的源自于分段的接收的AST中，减去每个可能的存储的匹配的原始AST，来确定每个可能的存储的匹配的AST改变结果。
在方框2508中，多播服务设备客户端或者客户端应用可以将用于所接收的分段的分段索引，设置为等于具有最低的AST改变的可能匹配的潜在分段号。例如，通过将每个单个可能的存储的匹配的所确定的AST改变进行一起比较，可以识别最低确定的AST改变，用于所接收的分段的分段索引可以是与具有所识别的最低确定的AST改变的可能匹配相关联的分段索引。用此方式，在方框2508中，多播服务设备客户端或者客户端应用可以选择对于MPD中的现有时间轴导致更小的时间修改的MPD时间轴调整(例如，导致最小的AST改变的MPD时间轴调整)。在一个实施例中，多播服务设备客户端或者客户端应用可以存储导致可用开始时间的最小改变(即，最小可用开始时间改变)的延迟调整。
图27示出了用于基于URL匹配来应对接收机设备定时漂移的实施例方法2700。在一个实施例中，方法2700的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法2700的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框2702中，多播服务设备客户端或者客户端应用可以通过URL匹配，来确定接收的分段的分段索引。例如，多播服务设备客户端或者客户端应用可以执行上面分别参照图16和图25所描述的方法1600或2500的操作，以通过URL匹配来确定分段索引。
在方框2704中，多播服务设备客户端或者客户端应用可以基于匹配的时段和表示对，确定用于具有所确定的分段索引的分段的按照MPD的可用开始时间(AvailPerMPD)。在方框2706中，多播服务设备客户端或者客户端应用可以根据MPD来确定分段持续时间(SD)。在方框2708中，多播服务设备客户端或者客户端应用可以确定用于该分段的解码时间(DT)。解码时间(DT)可以是该分段在接收机设备上实际变得可用的时间。
在判断框2710中，多播服务设备客户端或者客户端应用可以判断解码时间(DT)减去按照MPD的可用开始时间(AvailPerMPD)是否大于0.5乘以分段持续时间(SD)。虽然示出成分段持续时间的一半(例如，0.5*SD)，但判断解码时间(DT)减去按照MPD的可用开始时间(AvailPerMPD)是否大于0.5乘以分段持续时间(SD)，仅仅只是门限的一种示例性比较，其中，可以将解码时间(DT)和按照MPD的可用开始时间(AvailPerMPD)之间的差值与该门限进行比较。其它门限(其包括固定值或者设置为分段持续时间的分数(例如，.1*SD、.6*SD、.9*SD)或者分段持续时间的任何其它分数的门限)可以替代本文所讨论的0.5乘以分段持续时间(SD)门限。响应于确定DT-AvailPerMPD大于或等于0.5*SD(即，判断框2710＝“否”)，在方框2712中，多播服务设备客户端或者客户端应用可以确定没有发生定时漂移，并且可以不采取动作。可以在设备上提供该因素(例如，0.5)，或者将其接收成网络广播的配置文件的一部分。
响应于确定DT-AvailPerMPD大于0.5*SD(即，判断框2710＝“是”)，在方框1112中，多播服务设备客户端或者客户端应用可以确定发生了定时漂移，并触发可用开始时间的重新计算，如上面参照图11B所描述的。此外，多播服务设备客户端或者客户端应用还可以向应用通知已修改了MPD。
图28示出了用于基于URL匹配来应对接收机设备定时漂移的实施例方法2800。方法2800类似于上面参照图27所描述的方法2700，除了响应于分段索引改变，触发可用开始时间的重新计算之外。在一个实施例中，方法2800的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法2800的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框2702中，多播服务设备客户端或者客户端应用可以执行上面参照图27所描述的方法2700的类似编号方框的操作。在判断框506中，多播服务设备客户端或者客户端应用可以判断是否发生分段索引改变，如上面参照图5A所描述的。响应于确定分段索引没有改变(即，判断框506＝“否”)，在方框2712中，多播服务设备客户端或者客户端应用可以不采取动作，如上面参照图27所描述的。
响应于确定分段索引改变的发生(即，判断框506＝“是”)，多播服务设备客户端或者客户端应用可以执行上面参照图27所描述的方法2700的类似编号方框的方框2704、2706、2708、2710、2712和1112中的操作。
图29示出了用于基于URL匹配来应对接收机设备定时漂移的实施例方法2900。方法2900类似于上面参照图27所描述的方法2700，除了响应于确定AST改变超过门限(例如，一个分段持续时间)，触发可用开始时间的重新计算之外。在一个实施例中，方法2900的操作可以由在接收机设备(例如，智能电话)的处理器上运行的多播服务设备客户端来执行。在另一个实施例中，方法2900的操作可以由在接收机设备的处理器上运行的客户端应用(例如，DASH客户端)来执行。
在方框2702中，多播服务设备客户端或者客户端应用可以执行上面参照图27所描述的方法2700的类似编号方框的操作。
在方框2902中，多播服务设备客户端或者客户端应用可以确定源自于所接收的分段的AST改变。例如，多播服务设备客户端或者客户端应用可以计算源自于分段的接收的AST。可以以任何方式来计算源自于分段的接收的AST，例如，基于上面参照图5A-15B中的任何一个所描述的方法或者基于任何其它方法。随后，多播服务设备客户端或者客户端应用可以从所计算的源自于分段的接收的AST中，减去该分段的原始AST，来确定源自于该分段的AST改变。
在判断框2904中，处理器可以判断该AST改变是否大于门限。该门限可以是存储在接收机设备的存储器中的值，可以是任何值(预先提供的、用户可规定的、在MPD中规定的等等)，例如，其可以等于分段持续时间、小于一个分段持续时间、大于一个分段持续时间等等。响应于确定AST改变小于或等于门限(即，判断框2904＝“否”)，在方框2712中，多播服务设备客户端或者客户端应用可以不采取动作，如上面参照图27所描述的。响应于确定AST改变大于门限(即，判断框2904＝“是”)，在方框1112中，多播服务设备客户端或者客户端应用可以触发可用开始时间重新计算，如上面参照图27所描述的。
在各个实施例中，可以按照固定的时间间隔或者固定的分段计数间隔，来定期地应用上面分别参照图27、28和图29所描述的方法2700、2800和2900的操作。
各种实施例(其包括但不限于上面参照图3A-29所讨论的实施例)可以在各种各样的移动设备(即，接收机设备)中的任何一种之中实现，图30示出了其一种例子。例如，移动设备3000可以包括耦合到触摸屏控制器3004和内部存储器3002的处理器3001。处理器3001可以是被设计为实现通用任务或特定处理任务的一个或多个多核集成电路(IC)。内部存储器3002可以是易失性存储器或非易失性存储器，还可以是安全和/或加密存储器，或者非安全和/或非加密存储器、或者其任意组合。此外，触摸屏控制器3004和处理器3001还可以耦合到触摸屏面板3012，例如，电阻式感应触摸屏、电容感应触摸屏、红外线感测触摸屏等等。移动计算设备3000可以具有用于进行发送和接收的一个或多个无线电信号收发机3008(例如，Wi-Fi、RF、蜂窝等等)和天线3010，它们彼此之间相耦合和/或耦合到处理器3001。收发机3008和天线3010可以结合上面所提及的电路进行使用，以实现各种无线传输协议栈和接口。移动计算设备3000可以包括蜂窝网络无线调制解调器芯片3016，后者经由蜂窝网络进行通信并耦合到处理器。移动计算设备3000可以包括耦合到处理器3001的外围设备连接接口3018。外围设备连接接口3018可以被单独地配置为接受一种类型的连接，或者被多重地配置为接受多种类型的物理和通信连接、共同或专有连接(例如，USB、火线、Thunderbolt或PCIe)。此外，外围设备连接接口3018还可以耦合到类似配置的外围设备连接端口(没有示出)。此外，移动计算设备3000还可以包括用于提供音频输出的扬声器3014。此外，移动计算设备3000还可以包括使用塑料、金属、或材料的组合构成的壳体3020，以包含本文所讨论的所有部件或者一些部件。移动计算设备3000可以包括耦合到处理器3001的电源3022，例如一次性或可充电电池。此外，该可充电电池还可以耦合到外围设备连接端口，以便从移动计算设备3000之外的源接收充电电流。
各种实施例(其包括但不限于上面参照图3A-29所讨论的实施例)还可以实现在各种各样的市场上可买到的服务器设备中的任何一种上(例如，图31中所示出的服务器3100)。通常，这种服务器3100包括耦合到易失性存储器3102和大容量非易失性存储器(例如，硬盘驱动器3104)的处理器3101。此外，服务器3100还可以包括耦合到处理器3101的软盘驱动器、压缩光盘(CD)或者DVD光盘驱动器3106。此外，服务器3100还可以包括耦合到处理器3101的一个或多个网络收发机3103(例如，网络接入端口)，以便与通信网络3107(例如，耦合到其它通告系统计算机和服务器的局域网、互联网、公众交换电话网和/或蜂窝网络(例如，CDMA、TDMA、GSM、PCS、3G、4G、LTE或者任何其它类型的蜂窝网络))建立网络接口连接。
处理器3001和3101可以是能通过软件指令(应用)进行配置，以执行多种功能(其包括上面所描述的各种实施例的功能)的任何可编程的微处理器、微计算机或多个处理器芯片或芯片集。在一些设备中，可以提供多个处理器，例如，一个处理器专用于无线通信功能，一个处理器专用于运行其它应用。通常，在访问软件应用并将它们装载到处理器3001和3101之前，可以将这些软件应用存储在内部存储器中。处理器3001和3101可以包括足够用于存储这些应用软件指令的内部存储器。在很多设备中，内部存储器可以是易失性存储器或者非易失性存储器(例如，闪存)、或者二者的混合。为了便于说明起见，对于存储器的引用通常指代：处理器3001和3101可访问的存储器，其包括内部存储器或者插入在设备之中的可移动存储器、以及处理器3001和3101自身中的存储器。
上述的方法描述和处理流程图仅仅是用作为说明性例子，而不是旨在要求或者隐含着必须以所给出的顺序来执行各个实施例的步骤。如本领域普通技术人员所应当理解的，可以以任何顺序来执行上述的实施例中的步骤顺序。此外，诸如“其后”、“转而”、“接着”等等之类的词语，并不旨在限制这些步骤的顺序；这些词语仅仅只是用于引导读者遍历该方法的描述。此外，任何对权利要求元素的单数引用(例如，使用冠词“一个(a)”、“某个(an)”或者“该(the)”)，不应被解释为将该元素限制为单数形式。
结合本文所公开的实施例描述的各种示例性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或二者的组合。为了清楚地表示硬件和软件之间的这种可交换性，上面对各种示例性的部件、框、模块、电路和步骤均围绕其功能进行了总体描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本发明的保护范围。
用于执行本文所述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件部件或者其任意组合，可以用来实现或执行结合本文所公开的方面描述的用于实现各种示例性的逻辑、逻辑框、模块和电路的硬件。通用处理器可以是微处理器，或者，该处理器也可以是任何常规的处理器、控制器、微控制器或者状态机。处理器也可以实现为计算设备的组合，例如，DSP和微处理器的组合、若干微处理器、一个或多个微处理器与DSP内核的结合，或者任何其它此种结构。替代地，一些步骤或方法可以由特定于给定的功能的电路来执行。
在一个或多个示例性方面，本文所述功能可以用硬件、软件、固件或它们任意组合的方式来实现。当在软件中实现时，可以将这些功能存储成非临时性计算机可读介质或者非临时性处理器可读介质上的一个或多个处理器可执行指令或者代码。本文所公开的方法或算法的步骤，可以体现在处理器可执行软件模块中，后者可以位于非临时性计算机可读或者处理器可读存储介质上。非临时性服务器可读、计算机可读或者处理器可读存储介质可以是计算机或处理器能够存取的任何存储介质。举例而言，但非做出限制，这种非临时性服务器可读介质、计算机可读或处理器可读介质可以包括RAM、ROM、EEPROM、闪存、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。如本文所使用的，磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字通用光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上述的组合也应当包括在非临时性服务器可读、计算机可读和处理器可读介质的保护范围之内。另外，一种方法或算法的操作可以作为一个代码和/或指令集或者其任意组合，位于非临时性服务器可读介质、处理器可读介质和/或计算机可读介质上，其中该非临时性服务器可读介质、处理器可读介质和/或计算机可读介质可以并入到计算机程序产品中。
为使本领域任何普通技术人员能够实现或者使用本发明，上面围绕所公开的实施例进行了描述。对于本领域普通技术人员来说，对这些实施例的各种修改是显而易见的，并且，本文定义的总体原理也可以在不脱离本发明的精神或保护范围的基础上应用于其它实施例。因此，本发明并不限于本文所示出的实施例，而是与所附权利要求书和本文公开的原理和新颖性特征的最广范围相一致。

Claims (16)

1.一种用于应对接收机设备定时漂移的方法，包括：
通过统一资源标识符(URL)匹配来确定分段的索引；
基于可用性时间轴中的匹配的时段和表示对来确定所述分段的可用开始时间；
根据所述可用性时间轴来确定分段持续时间；
确定用于所述分段的解码时间；
判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于门限；以及
响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述门限，触发对所述可用开始时间的重新计算。
2.根据权利要求1所述的方法，其中：
判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于门限包括：判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于所述分段持续时间的一部分；以及
响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述门限，触发对所述可用开始时间的重新计算包括：响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述分段持续时间的所述一部分，触发对所述可用开始时间的重新计算。
3.根据权利要求2所述的方法，其中，所述分段持续时间的所述一部分是一半。
4.根据权利要求1所述的方法，还包括：
判断分段索引改变是否在所述接收机设备处的两个接收的分段片段之间发生，
其中，基于所述可用性时间轴中的匹配的时段和表示对来确定所述分段的所述可用开始时间包括：响应于确定分段索引改变在所述接收机设备处的两个接收的分段片段之间的发生，基于所述可用性时间轴中的匹配的时段和表示对来确定所述分段的所述可用开始时间。
5.根据权利要求4所述的方法，其中，所述可用性时间轴是超文本传输协议动态自适应流媒体(DASH)媒体呈现描述(MPD)。
6.一种用于应对接收机设备定时偏移的方法，包括：
通过统一资源标识符(URL)匹配来确定接收的分段的分段索引；
确定源自于所述接收的分段的可用开始时间的改变；
判断所述可用开始时间的所述改变是否大于门限；以及
响应于确定所述可用开始时间的所述改变大于门限，触发对所述可用开始时间的重新计算。
7.根据权利要求6所述的方法，其中，所述门限是分段持续时间。
8.根据权利要求7所述的方法，其中，可用性时间轴是超文本传输协议动态自适应流媒体(DASH)媒体呈现描述(MPD)。
9.一种接收机设备，包括：
处理器，其配置有处理器可执行指令以执行包括以下的操作：
通过统一资源标识符(URL)匹配来确定分段的索引；
基于可用性时间轴中的匹配的时段和表示对来确定所述分段的可用开始时间；
根据所述可用性时间轴来确定分段持续时间；
确定用于所述分段的解码时间；
判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于门限；以及
响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述门限，触发对所述可用开始时间的重新计算。
10.根据权利要求9所述的接收机设备，其中，所述处理器配置有处理器可执行指令以执行操作，使得：
判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于门限包括：判断用于所述分段的所述解码时间减去所述分段的所述可用开始时间是否大于所述分段持续时间的一部分；以及
响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述门限，触发对所述可用开始时间的重新计算包括：响应于确定用于所述分段的所述解码时间减去所述分段的所述可用开始时间大于所述分段持续时间的所述一部分，触发对所述可用开始时间的重新计算。
11.根据权利要求10所述的接收机设备，其中，所述分段持续时间的所述一部分是一半。
12.根据权利要求9所述的接收机设备，其中，所述处理器配置有处理器可执行指令以执行还包括下面的操作：判断分段索引改变是否在两个接收的分段片段之间发生，并且
其中，所述处理器配置有处理器可执行指令以执行操作，使得基于所述可用性时间轴中的匹配的时段和表示对来确定所述分段的所述可用开始时间包括：响应于确定分段索引改变在两个接收的分段片段之间的发生，基于所述可用性时间轴中的匹配的时段和表示对来确定所述分段的所述可用开始时间。
13.根据权利要求12所述的接收机设备，其中，所述可用性时间轴是超文本传输协议动态自适应流媒体(DASH)媒体呈现描述(MPD)。
14.一种接收机设备，包括：
处理器，其配置有处理器可执行指令以执行包括以下的操作：
通过统一资源标识符(URL)匹配来确定接收的分段的分段索引；
确定源自于所述接收的分段的可用开始时间的改变；
判断所述可用开始时间的所述改变是否大于门限；以及
响应于确定所述可用开始时间的所述改变大于门限，触发对所述可用开始时间的重新计算。
15.根据权利要求14所述的接收机设备，其中，所述门限是分段持续时间。
16.根据权利要求15所述的接收机设备，其中，可用性时间轴是超文本传输协议动态自适应流媒体(DASH)媒体呈现描述(MPD)。
CN201680022873.XA 2015-04-20 2016-02-26 用于通过广播支持dash的进一步设备定时调整和方法 Pending CN107534663A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562149776P 2015-04-20 2015-04-20
US62/149,776 2015-04-20
US14/812,535 US20160308927A1 (en) 2015-04-20 2015-07-29 Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
US14/812,535 2015-07-29
PCT/US2016/019795 WO2016171793A1 (en) 2015-04-20 2016-02-26 Further device timing adjustments and methods for supporting dash over broadcast

Publications (1)

Publication Number Publication Date
CN107534663A true CN107534663A (zh) 2018-01-02

Family

ID=57129070

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201680022618.5A Pending CN107534680A (zh) 2015-04-20 2016-02-26 用于通过广播支持dash的进一步设备定时调整和方法
CN201680022873.XA Pending CN107534663A (zh) 2015-04-20 2016-02-26 用于通过广播支持dash的进一步设备定时调整和方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201680022618.5A Pending CN107534680A (zh) 2015-04-20 2016-02-26 用于通过广播支持dash的进一步设备定时调整和方法

Country Status (5)

Country Link
US (3) US10051031B2 (zh)
EP (2) EP3286902A1 (zh)
JP (2) JP2018519694A (zh)
CN (2) CN107534680A (zh)
WO (3) WO2016171791A1 (zh)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2954653B1 (en) * 2013-02-06 2018-11-28 Telefonaktiebolaget LM Ericsson (publ) Technique for detecting an encoder functionality issue
US9998477B2 (en) 2015-03-31 2018-06-12 Comcast Cable Communications, Llc Digital content access control
US10051031B2 (en) 2015-04-20 2018-08-14 Qualcomm Incorporated Further device timing adjustments and methods for supporting DASH over broadcast
CN107710712B (zh) * 2015-06-19 2020-06-26 华为技术有限公司 一种集群通信方法、装置及设备
US9973819B1 (en) 2015-06-26 2018-05-15 Amazon Technologies, Inc. Live video stream with interactive shopping interface
US10021458B1 (en) 2015-06-26 2018-07-10 Amazon Technologies, Inc. Electronic commerce functionality in video overlays
US9883249B2 (en) 2015-06-26 2018-01-30 Amazon Technologies, Inc. Broadcaster tools for interactive shopping interfaces
US10440436B1 (en) * 2015-06-26 2019-10-08 Amazon Technologies, Inc. Synchronizing interactive content with a live video stream
US10152080B2 (en) 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
US10158682B2 (en) * 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
KR101916022B1 (ko) * 2015-10-06 2018-11-07 한국전자통신연구원 세그먼트 기반의 방송 콘텐츠 반복 전송 방법 및 장치
US10477286B2 (en) * 2017-06-19 2019-11-12 Wangsu Science & Technology Co., Ltd. Streaming media file processing method and live streaming system
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
JP6271072B1 (ja) * 2017-10-10 2018-01-31 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
CN111031354B (zh) * 2019-12-09 2020-12-01 腾讯科技（深圳）有限公司 一种多媒体播放方法、装置及存储介质
US11770588B2 (en) 2020-12-07 2023-09-26 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
US11490153B2 (en) 2020-12-07 2022-11-01 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
US11490167B2 (en) 2020-12-07 2022-11-01 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
CN117478942A (zh) * 2022-07-20 2024-01-30 联发科技（新加坡）私人有限公司 流媒体播放方法和电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101194453A (zh) * 2005-04-29 2008-06-04 诺基亚公司 用于动态地调整例如媒体接入控制（mac）层的协议层处的分段的方法、设备和计算机程序
CA2774923A1 (en) * 2009-09-22 2011-03-31 Michael G. Luby Enhanced block-request streaming system using signaling or block creation
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统
CN103973662A (zh) * 2013-02-06 2014-08-06 华为技术有限公司 流媒体请求方法及控制器

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100355237C (zh) * 2003-07-24 2007-12-12 Lg电子株式会社 用于在移动电话中再现多媒体内容的系统和方法
US20060059256A1 (en) * 2004-09-10 2006-03-16 Nokia Corporation Signaling a state of a transmission link via a transport control protocol
US20070101394A1 (en) * 2005-11-01 2007-05-03 Yesvideo, Inc. Indexing a recording of audiovisual content to enable rich navigation
KR100946902B1 (ko) * 2006-05-06 2010-03-09 삼성전자주식회사 이동 통신 시스템에서 자원 운용 장치 및 방법
EP2737439A4 (en) * 2011-07-26 2015-04-01 United Parcel Service Inc SYSTEMS AND METHODS FOR ASSESSING THE EFFECTIVENESS OF MOBILE ASSETS
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9088583B2 (en) 2011-10-31 2015-07-21 Interdigital Patent Holdings, Inc. Method and apparatus for enabling multimedia synchronization
US8843596B2 (en) * 2011-11-30 2014-09-23 Adobe Systems Incorporated Conversion between streaming media communication protocols
US9386058B2 (en) * 2012-02-27 2016-07-05 Qualcomm Incorporated DASH client and receiver with playback rate selection
US8661491B1 (en) * 2012-08-02 2014-02-25 Ericsson Television Inc. Methods using base content and additive content and related client devices and network server devices
WO2014076052A1 (en) 2012-11-13 2014-05-22 Telefonaktiebolaget L M Ericsson (Publ) Processing of multimedia data
US9386062B2 (en) 2012-12-28 2016-07-05 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (HTTP) requests
US9426196B2 (en) 2013-01-04 2016-08-23 Qualcomm Incorporated Live timing for dynamic adaptive streaming over HTTP (DASH)
EP2954653B1 (en) * 2013-02-06 2018-11-28 Telefonaktiebolaget LM Ericsson (publ) Technique for detecting an encoder functionality issue
US9438654B2 (en) 2013-04-18 2016-09-06 Futurewei Technologies, Inc. Fragment interface into dynamic adaptive streaming over hypertext transfer protocol presentations
RU2016115980A (ru) * 2013-10-30 2017-10-25 Сони Корпорейшн Устройство подачи контента, способ подачи контента, программа, оконечное устройство и система подачи контента
US20150172066A1 (en) * 2013-12-13 2015-06-18 Qualcomm Incorporated Practical implementation aspects of unicast fetch for http streaming over embms
KR102273757B1 (ko) * 2014-01-03 2021-07-06 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
US9491239B2 (en) * 2014-01-31 2016-11-08 Comcast Cable Communications, Llc Methods and systems for processing data requests
US10476693B2 (en) * 2014-02-24 2019-11-12 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals
US9706572B2 (en) * 2014-04-30 2017-07-11 Qualcomm Incorporated Techniques for obtaining and maintaining access to a wireless communication medium
US10051031B2 (en) 2015-04-20 2018-08-14 Qualcomm Incorporated Further device timing adjustments and methods for supporting DASH over broadcast

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101194453A (zh) * 2005-04-29 2008-06-04 诺基亚公司 用于动态地调整例如媒体接入控制（mac）层的协议层处的分段的方法、设备和计算机程序
CA2774923A1 (en) * 2009-09-22 2011-03-31 Michael G. Luby Enhanced block-request streaming system using signaling or block creation
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
CN103973662A (zh) * 2013-02-06 2014-08-06 华为技术有限公司 流媒体请求方法及控制器
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统

Also Published As

Publication number Publication date
US20160308934A1 (en) 2016-10-20
CN107534680A (zh) 2018-01-02
EP3286902A1 (en) 2018-02-28
WO2016171791A1 (en) 2016-10-27
EP3254445A1 (en) 2017-12-13
US10051031B2 (en) 2018-08-14
JP2018519694A (ja) 2018-07-19
US20160308928A1 (en) 2016-10-20
WO2016171793A1 (en) 2016-10-27
US20160308927A1 (en) 2016-10-20
JP2018519695A (ja) 2018-07-19
WO2016171792A1 (en) 2016-10-27

Similar Documents

Publication Publication Date Title
CN107534663A (zh) 用于通过广播支持dash的进一步设备定时调整和方法
CN104904180B (zh) 设备定时调整和用于支持广播上的dash的方法
CN103535013B (zh) 在广播网络中使用多信道单向输送文件传递(“flute”)协议传递不同类别的文件的系统及设备
JP6425720B2 (ja) コンテンツ配信のための方法及び装置
CN102687518A (zh) 用于流媒体文件内表示的描述和定时的装置及方法
CN104023250B (zh) 基于流媒体的实时互动方法和系统
CN107113454A (zh) 配置引用用于自适应流式传输视频的基础设施服务提供商的清单文件
CN105516115A (zh) 一种频道快速播放的方法及用户设备ue
CN1859526B (zh) 实现流媒体模拟直播的方法及流媒体服务器和内容管理系统
CN105324974A (zh) 用于服务的单向传输协议会话上的多个文件传送
CN101114998A (zh) 网络中媒体交递的装置及方法
CN106233758A (zh) 在不同的区域中使用不同的承载来用信号发送eMBMS服务的服务定义
CN107431700A (zh) 对于部分段的指示
CN102497423A (zh) 网页聊天室的放歌方法、装置及系统
CN109788247A (zh) 一种监控指令识别的方法和装置
WO2023061060A1 (zh) 音视频码流的调度方法、系统、介质及电子装置
US20230014950A1 (en) Wireless Broadband Network with Integrated Streaming Multimedia Services
CN107431699A (zh) 对于部分段的指示
CN107251561A (zh) 设备对通过广播的dash的可用性开始时间调整
CN107409130A (zh) 对于部分段的指示
KR102457526B1 (ko) 미디어 스트림 송신 방법, 장치, 시스템, 및 디바이스
CN106664444A (zh) 用于在多媒体系统中接收媒体分组的方法和设备
CN102655510A (zh) 基于p-tractert源路径发现技术的应用层组播系统
CN112738188A (zh) 一种数据跨网传输方法及装置
CN107306356A (zh) 视频信息描述文件获取方法及内容分发服务器、机顶盒、系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20180102

WD01 Invention patent application deemed withdrawn after publication