CN107005729A - 用于多媒体和文件传输的传输接口 - Google Patents

用于多媒体和文件传输的传输接口 Download PDF

Info

Publication number
CN107005729A
CN107005729A CN201580064999.9A CN201580064999A CN107005729A CN 107005729 A CN107005729 A CN 107005729A CN 201580064999 A CN201580064999 A CN 201580064999A CN 107005729 A CN107005729 A CN 107005729A
Authority
CN
China
Prior art keywords
section
data
media
time
bytes range
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
CN201580064999.9A
Other languages
English (en)
Inventor
G·K·瓦尔克
T·施托克哈默
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 CN107005729A publication Critical patent/CN107005729A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/70—Media network packetisation
    • 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/752—Media network packet handling adapting media to network 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • 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
    • 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/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
    • 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/22—Parsing or analysis of headers
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • 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/26208—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 the scheduling operation being performed under constraints
    • H04N21/26216—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 the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • 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/643—Communication protocols
    • H04N21/64322—IP
    • 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
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种用于发送媒体数据的服务器设备，该服务器设备包括第一单元和第二单元。第一单元包括一个或多个处理单元，其被配置为：向服务器设备的第二单元发送针对媒体数据的描述性信息，其中，描述性信息指示媒体数据的区段或区段的字节范围，以及能够传递区段或字节范围的最早时间或者能够传递区段或区段的字节范围的最迟时间；以及向第二单元发送媒体数据。第二单元由此根据描述性信息来传递区段或区段的字节范围(例如，在最早时间之后和/或在最迟时间之前)。

Description

用于多媒体和文件传输的传输接口
本申请要求享有于2014年12月5日递交的美国临时申请62/088,351、于2015年1月13日递交的美国临时申请62/102,930、以及于2015年8月25日递交的美国临时申请No.62/209,620的权益，故此以引用方式将上述每项申请的全部内容并入本文。
技术领域
本公开内容涉及媒体数据的传输。
背景技术
数字视频能力可以并入到广泛的设备中，包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上型或台式计算机、数字相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频电话会议设备等。数字视频设备实现视频压缩技术(例如由MPEG-2、MPEG-4、ITU-T H.263或ITU-T H.264/MPEG-4，第10部分，高级视频编码(AVC)，高效视频编码(HEVC)/ITU-T H.265所定义的标准中以及这些标准的扩展中所描述的那些视频压缩技术)，以更有效地发送和接收数字视频信息。
视频压缩技术执行空间预测和/或时间预测，以减少或移除视频序列中固有的冗余。对于基于块的视频编码，可以将视频帧或切片划分成宏块。可以进一步地划分每个宏块。可以使用相对于相邻宏块的空间预测来对帧内编码(I)帧或切片中的宏块进行编码。帧间编码(P或B)帧或切片中的宏块可以使用相对于相同帧或切片中的相邻宏块的空间预测或者相对于其它参考帧的时间预测。在帧或帧组间可以使用分级参考。
在对视频数据进行编码之后，可以对视频数据进行打包以用于传输或存储。可以将媒体数据组装成符合各种标准(例如，国际标准化组织(ISO)基本媒体文件格式(ISOBMFF)及其扩展，例如AVC)中的任何标准的文件。
发明内容
概括地说，本公开内容描述了与媒体数据的传递(例如，通过网络)相关的技术。服务器设备通常包括媒体数据的传递中所涉及的各种单元。例如，所述单元可以包括：第一单元，用于对媒体数据进行打包；以及第二单元，用于发送经打包的媒体数据。更具体地说，本公开内容的技术涉及：所述第一单元向所述第二单元提供指示应当何时传递所述媒体数据的信息。
在一个例子中，一种传输媒体数据的方法包括：由服务器设备的第一单元进行以下操作：向所述服务器设备的第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或者所述区段的字节范围中的至少一项，以及能够传递所述区段或所述区段的所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间中的至少一项；以及向所述第二单元发送所述媒体数据。
在另一个例子中，一种用于传输媒体数据的服务器设备包括第一单元和第二单元。所述第一单元包括一个或多个处理单元，其被配置为：向所述服务器设备的所述第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或所述区段的字节范围，以及能够传递所述区段或所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间；以及向所述第二单元发送所述媒体数据。
在另一个例子中，一种用于传输媒体数据的服务器设备包括第一单元和第二单元。所述第一单元包括：用于向所述服务器设备的所述第二单元发送针对媒体数据的描述性信息的单元，其中，所述描述性信息指示所述媒体数据的区段或所述区段的字节范围，以及能够传递所述区段或所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间；以及用于向所述第二单元发送所述媒体数据的单元。
在另一个例子中，一种具有存储在其上的指令的计算机可读存储介质，其中当所述指令被执行时，使得服务器设备的第一单元的处理器执行以下操作：向所述服务器设备的第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或者所述区段的字节范围中的至少一项，以及能够传递所述区段或所述区段的所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间中的至少一项；以及向所述第二单元发送所述媒体数据。
在下面的附图和描述中阐述了一个或多个例子的细节。通过描述和附图以及通过权利要求书，其它特征、目标和优势将是显而易见的。
附图说明
图1是示出了实现用于通过网络来流式传输媒体数据的技术的示例性系统的框图。
图2是示出了示例性多媒体内容的元素的概念图。
图3是示出了服务器设备(例如，图1的服务器设备)和客户端设备(例如，图1的客户端设备)的示例性组件的框图。
图4是示出了(图3的客户端设备的)媒体访问控制(MAC)/PHY(物理)层处接收到数据的时间和媒体播放器输出从接收到的数据产生的媒体数据的时间之间的差异的例子的概念图。
图5是示出了(图3的客户端设备的)MAC/Phy层处接收到数据的时间、(图3的客户端设备的)DASH播放器处接收到输入的时间以及DASH播放器传递输出的时间之间的差异的例子的概念图。
图6是示出了数据传递事件和媒体传递事件之间的对应关系的例子的概念图。
图7是示出了MAC/PHY数据传递块的概念图。
图8是示出了发送过程和接收过程的例子的概念图。
图9A和图9B示出了根据本公开内容的技术的、应用于媒体数据的前向纠错(FEC)的例子。
图10是示出了各种区段传递样式(A-D)的概念图。
图11是示出了真实的传输缓冲器模型的概念图。
图12A和图12B是将本公开内容的技术与MPEG-2 TS模型进行对比的概念图。
图13是示例性的接收机IP栈的框图，其中可以由客户端设备(例如，图3的客户端设备和/或图1的客户端设备)来实现示例性的接收机IP栈。
图14是示出了根据恒定延迟假设和基于块传递的phy来实现的示例性发送系统的概念图。
图15是示出了示例性的发射机配置的框图。
图16是示出了具有经调度的分组传递的系统中针对数据的示例性传递模型的概念图。
图17是示出了发送系统的更多细节的概念图。
图18是示出了区段时间的交错的概念图。
图19是示出了当流包括可以是可选的媒体数据和强制的媒体时，目标时间和最早时间之间的差异的概念图。
图20是具有潜在地可丢弃的帧组的视频序列的概念图。
图21是示出了根据本公开内容的技术的另一个示例性系统的框图。
图22是示出了用于获取媒体传递事件的示例性技术的流程图。
图23是示出了根据本公开内容的技术的、用于传输媒体数据的示例性方法的流程图。
具体实施方式
概括地说，本公开内容描述了与用于多媒体和文件传递的传输接口设计的方面相关的技术。具体而言，这些技术关于具有定时媒体和/或文件传递的系统。这偏离了用于例如基于MPEG-2系统的MPEG-2传输流(TS)的系统的历史方法，其中MPEG-2系统通常假设恒定的端到端延迟，当考虑最新的传输系统及其相关的物理(PHY)层/媒体访问控制(MAC)时，此时这种假设远没有那么相关。
本公开内容的技术可以应用于视频或其它多媒体和元数据文件，其中这些视频或其它多媒体和元数据文件符合根据以下文件格式中的任何文件格式来进行封装的视频数据：ISO基本媒体文件格式、可缩放视频编码(SVC)文件格式、高级视频编码(AVC)文件格式、第三代合作伙伴计划(3GPP)文件格式、和/或多视图视频编码(MVC)文件格式或者其它类似的视频文件格式。
在HTTP流式传输中，频繁使用的操作包括HEAD、GET和部分GET。HEAD操作获取与给定的统一资源定位符(URL)或统一资源名称(URN)相关联的文件的报头，而不获取与URL或URN相关联的有效载荷。GET操作获取与给定的URL或URN相关联的整个文件。部分GET操作接收字节范围作为输入参数并且获取文件的连续数量的字节，其中，字节数量对应于所接收的字节范围。因此，可以提供电影片段用于HTTP流式传输，这是因为部分GET操作可以取得一个或多个单独的电影片段。在电影片段中，可以存在不同轨道的若干个轨道片段。在HTTP流式传输中，媒体呈现可以是客户端可访问的结构化数据集合。客户端可以请求并下载媒体数据信息，以向用户提供流式传输服务。
在使用HTTP流式传输来流式传输3GPP数据的例子中，可能存在针对多媒体内容的视频和/或音频数据的多个表示(representation)。如下面说明的，不同的表示可以对应于不同的编码特性(例如，不同的视频编码标准简档或层级)、不同的编码标准或编码标准的扩展(例如，多视图和/或可缩放扩展)或者不同的比特速率。可以在HTTP的动态自适应流式传输(DASH)的媒体呈现描述(MPD)数据结构中定义这种表示的清单(manifest)。媒体呈现可以对应于HTTP流式传输客户端设备可访问的结构化数据集合。HTTP流式传输客户端设备可以请求并下载媒体数据信息，以向客户端设备的用户提供流式传输服务。可以在MPD数据结构(其可以包括MPD的更新)中描述媒体呈现。
媒体呈现可以包含一个或多个周期的序列。可以由MPD中的Period(周期)元素来定义周期。每个周期可以具有MPD中的属性start(开始)。MPD可以包括针对每个周期的start属性和availabilityStartTime(可用开始时间)属性。对于实况服务，周期的start属性和MPD属性availabilityStartTime的和可以以网络时间协议(NTP)64格式来指定周期的可用时间，特别是针对相应周期中的每个表示的第一媒体区段。对于按需服务，第一周期的start属性可以是0。对于任何其它周期，start属性可以指定相应周期的开始时间相对于第一周期的开始时间的时间偏移。每个周期可以扩展，直到下一周期的开始为止，或者在最后一个周期的情况下，直到媒体呈现的结束为止。周期开始时间可以是精确的。周期开始时间可以反映由于播放所有先前周期的媒体而产生的实际定时。
每个周期可以包含针对相同媒体内容的一个或多个表示。表示可以是音频或视频数据的多个替代的经编码版本中的一个版本。表示可以依据编码类型(例如，比特速率、分辨率、和/或针对视频数据和比特速率的编解码器、语言、和/或针对音频数据的编解码器)而不同。术语表示可以用于指代经编码的音频或视频数据的对应于多媒体内容的特定周期并以特定方式编码的部分。
特定周期的表示可以分配给MPD中的属性(其指示表示所属的适配集)所指示的群组。相同适配集中的表示通常被视为彼此的替代，因为客户端设备可以动态地并且无缝地在这些表示之间切换，例如，以便执行带宽适配。例如，针对特定周期的视频数据的每个表示可以分配给相同的适配集，使得表示中的任何表示可以被选择用于解码，以呈现针对相应周期的多媒体内容的媒体数据(例如，视频数据或音频数据)。一个周期内的媒体内容可以由来自群组0的一个表示(如果存在的话)来表示，或者在一些例子中，由来自每个非零群组的最多一个表示的组合来表示。可以相对于周期的开始时间来表达针对周期的每个表示的定时数据。
表示可以包括一个或多个区段。每个表示可以包括初始化区段，或者表示的每个区段可以是自初始化的。当存在初始化区段时，其可以包含用于访问表示的初始化信息。通常，初始化区段不包含媒体数据。可以用标识符(例如，统一资源定位符(URL)、统一资源名称(URN)或统一资源标识符(URI))来唯一地引用区段。MPD可以提供针对每个区段的标识符。在一些例子中，MPD还可以以range(范围)属性的形式来提供字节范围，其可以与针对可由URL、URN或URI访问的文件内的区段的数据相对应。
可以选择不同的表示以用于大体上同时获取不同类型的媒体数据。例如，客户端设备可以选择从中获取区段的音频表示、视频表示以及定时文本表示。在一些例子中，客户端设备可以选择特定的适配集以用于执行带宽适配。即，客户端设备可以选择包括视频表示的适配集、包括音频表示的适配集、和/或包括定时文本的适配集。替代地，客户端设备可以选择针对某些类型的媒体(例如，视频)的适配集，并且直接地选择针对其它类型的媒体(例如，音频和/或定时文本)的表示。
图1是示出了实现用于通过网络来流式传输媒体数据的技术的示例性系统10的框图。在该例子中，系统10包括内容准备设备20、服务器设备60和客户端设备40。客户端设备40和服务器设备60通过网络74(其可以包括互联网)通信地耦合。在一些例子中，内容准备设备20和服务器设备60也可以通过网络74或另一个网络耦合，或者可以直接通信地耦合。在一些例子中，内容准备设备20和服务器设备60可以包括相同的设备。
在图1的例子中，内容准备设备20包括音频源22和视频源24。音频源22可以包括例如麦克风，其中麦克风产生电信号，所述电信号表示所捕获的要由音频编码器26编码的音频数据。替代地，音频源22可以包括：存储介质，其存储先前记录的音频数据；音频数据生成器，例如计算机化的合成器；或者任何其它的音频数据源。视频源24可以包括：视频相机，其产生要由视频编码器28进行编码的视频数据；编码有先前记录的视频数据的存储介质；视频数据生成单元，例如计算机图形源；或者任何其它的视频数据源。内容准备设备20不一定在所有的例子中都通信地耦合到服务器设备60，但是可以将多媒体内容存储到由服务器设备60读取的单独介质。
原始音频和视频数据可以包括模拟或数字数据。可以在由音频编码器26和/或视频编码器28对模拟数据进行编码之前对其进行数字化。当说话参与者正在说话时，音频源22可以从该说话参与者获得音频数据，并且视频源24可以同时获得该说话参与者的视频数据。在其它例子中，音频源22可以包括包含所存储的音频数据的计算机可读存储介质，并且视频源24可以包括包含所存储的视频数据的计算机可读存储介质。以此方式，本公开内容中所描述的技术可以应用于实况的、流式传输的、实时的音频和视频数据，或者应用于经存档的、预先记录的音频和视频数据。
与视频帧相对应的音频帧通常是包含音频数据的音频帧，其中该音频数据是由音频源22与包含在视频帧内的由视频源24捕获(或生成)的视频数据同时捕获(或生成)的。例如，当说话参与者通常通过说话来产生音频数据时，音频源22捕获音频数据，并且视频源24同时(即，当音频源22正在捕获音频数据时)捕获说话参与者的视频数据。因此，音频帧可以在时间上对应于一个或多个特定的视频帧。因此，与视频帧相对应的音频帧通常对应于以下情形：在该情形中，同时捕获音频数据和视频数据，并且对于该情形，音频帧和视频帧分别包括同时捕获的音频数据和视频数据。
在一些例子中，音频编码器26可以将时间戳编码到每个经编码的音频帧中，其中该时间戳表示用于经编码的音频帧的音频数据被记录的时间，并且类似地，视频编码器28可以将时间戳编码到每个经编码的视频帧中，其中该时间戳表示用于经编码的视频帧的视频数据被记录的时间。在这些例子中，与视频帧相对应的音频帧可以包括：包括时间戳的音频帧，以及包括相同时间戳的视频帧。内容准备设备20可以包括内部时钟，其中音频编码器26和/或视频编码器28可以根据该内部时钟来生成时间戳，或者音频源22和视频源24可以使用该内部时钟来分别将音频和视频数据与时间戳相关联。
在一些例子中，音频源22可以向音频编码器26发送与音频数据被记录的时间相对应的数据，并且视频源24可以向视频编码器28发送与视频数据被记录的时间相对应的数据。在一些例子中，音频编码器26可以将序列标识符编码到经编码的音频数据中，以指示经编码的音频数据的相对时间排序，而不必指示音频数据被记录的绝对时间，并且类似地，视频编码器28也可以使用序列标识符来指示经编码的视频数据的相对时间排序。类似地，在一些例子中，序列标识符可以被映射或者以其它方式与时间戳相关。
音频编码器26通常产生经编码的音频数据流，而视频编码器28产生经编码的视频数据流。每个单独的数据流(无论是音频还是视频)可以被称为基本流或者来自所传递的多个对象的片段集合。基本流是表示的单个的、经数字编码(可能经压缩)的分量。例如，表示的经编码的视频或音频部分可以是基本流。基本流可以在被封装到视频文件中之前转换为打包的基本流(PES)。在相同的表示内，可以使用流ID来将属于一个基本流的PES分组与属于其它基本流的PES分组进行区分。基本流的基本数据单元是打包的基本流(PES)分组。因此，经编码的视频数据通常对应于基本视频流。类似地，音频数据对应于一个或多个对应的基本流。在一些例子中，例如，根据单向传输的实时对象传递(ROUTE)协议，可以以在功能上与基本流类似的方式来流式传输媒体对象。这也与渐进式下载和回放类似。ROUTE会话可以包括一个或多个分层编码传输(LCT)会话。在Luby等人2009年10月的RFC 5651“LayeredCoding Transport(LCT)Building Block”中描述了LCT。
许多视频编码标准(例如，ITU-T H.264/AVC和高效视频编码(HEVC)标准(还被称为ITU-T H.265))定义了针对无错误比特流的语法、语义和解码过程，其中任何一项符合某个简档或层级。视频编码标准通常不指定编码器，但是编码器的任务是保证所生成的比特流对于解码器来说是符合标准的。在视频编码标准的上下文中，“简档”与算法、特征或工具以及施加到算法、特征或工具的约束的子集相对应。如由H.264标准定义的，例如，“简档”是由H.264标准指定的整个比特流语法的子集。“层级”对应于诸如解码器存储器和计算之类的解码器资源消耗的限制，这些限制与图片的分辨率、比特速率以及块处理速率相关。可以利用profile_idc(简档指示符)值来用信号发送简档，同时可以利用level_idc(层级指示符)值来用信号发送层级。
例如，H.264标准认识到，在由给定简档的语法强加的界限内，取决于比特流中的语法元素所取的值(例如，经解码的图片的指定大小)，仍然可能要求编码器和解码器的性能的大变化。H.264标准进一步认识到，在许多应用中，实现能够处理特定简档内的语法的所有假设使用的解码器既不实际也不经济。因此，H.264标准将“层级”定义为强加在比特流中的语法元素的值上的指定约束集合。这些约束可以是对值的简单限制。替代地，这些约束可以采取对值的算术组合(例如，图片宽度乘以图片高度乘以每秒解码的图片数量)的约束的形式。H.264标准还提供的是，单独的实现方式可以针对每个所支持的简档支持不同的层级。
符合简档的解码器通常支持该简档中所定义的所有特征。例如，作为编码特征，B图片编码在H.264/AVC的基线简档中未得到支持，但是在H.264/AVC的其它简档中得到支持。符合层级的解码器应当能够解码不需要超出该层级中定义的限制的资源的任何比特流。简档和层级的定义可以有助于可解释性。例如，在视频传输期间，可以针对整个传输会话来协商和同意一对简档和层级定义。具体而言，在H.264/AVC中，层级可以定义对以下各项的限制：需要处理的宏块数量，经解码图片缓冲器(DPB)大小，经编码图片缓冲器(CPB)大小，垂直运动向量范围，每两个连续MB的运动向量的最大数量，以及B块是否可以具有小于8x8像素的子宏块划分。以此方式，解码器可以确定该解码器是否能够恰当地解码比特流。
在图1的例子中，内容准备设备20的封装单元30从视频编码器28接收包括经编码的视频数据的基本流，并且从音频编码器26接收包括经编码的音频数据的基本流。在一些例子中，视频编码器28和音频编码器26均可以包括打包器(packetizer)以用于根据经编码的数据来形成PES分组。在其它例子中，视频编码器28和音频编码器26均可以与用于根据经编码的数据来形成PES分组的对应打包器对接。在其它例子中，封装单元30可以包括打包器，以用于根据经编码的音频和视频数据来形成PES分组。
视频编码器28可以以各种方式来对多媒体内容的视频数据进行编码，以在各种比特速率下并且利用各种特性(例如，像素分辨率、帧速率、对各种编码标准的符合性、对用于各种编码标准的各种简档和/或简档层级的符合性、具有一个或多个视图的表示(例如，针对二维或三维回放)，或其它此类特性)来产生多媒体内容的不同表示。如本公开内容中所使用的，表示可以包括以下各项中的一项：音频数据、视频数据、文本数据(例如，用于隐藏式字幕)，或者其它此类数据。表示可以包括基本流，例如音频基本流或视频基本流。每个PES分组可以包括stream_id(流_id)，其标识该PES分组所属的基本流。封装单元30负责将基本流组装成各种表示的视频文件(例如，区段)。
封装单元30从音频编码器26和视频编码器28接收用于表示的基本流的PES分组，并且根据PES分组来形成相应的网络抽象层(NAL)单元。在H.264/AVC(高级视频编码)的例子中，将经编码的视频区段组织成NAL单元，其中NAL单元提供处理例如视频电话、存储、广播或流式传输等应用的“网络友好的”视频表示。NAL单元可以分类为视频编码层(VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎并且可以包括块、宏块和/或切片层级数据。其它NAL单元可以是非VCL NAL单元。在一些例子中，一个时间实例中的经编码图片(通常呈现为主要经编码图片)可以包含在访问单元中，其中访问单元可以包括一个或多个NAL单元。
非VCL NAL单元可以包括参数集NAL单元和补充增强信息(SEI)NAL单元等等。参数集可以包含序列层级报头信息(在序列参数集(SPS)中)以及很少改变的图片层级报头信息(在图片参数集(PPS)中)。利用参数集(例如，PPS和SPS)，不需要针对每个序列或图片重复很少改变的信息，因此可以提高编码效率。此外，参数集的使用可以实现重要报头信息的带外传输，从而避免了需要针对错误复原而进行冗余传输。在带外传输的例子中，可以在与其它NAL单元(例如，SEI NAL单元)不同的频道上发送参数集NAL单元。
SEI NAL单元可以包含对于解码来自VCL NAL单元的经编码图片样本来说不是必要的但是可以辅助与解码、显示、错误恢复以及其它目的相关的过程的信息。SEI消息可以包含在非VCL NAL单元中。SEI消息是一些标准规范的规范性部分，并且因此对于符合标准的解码器实现方式来说并非总是强制的。SEI消息可以是序列层级SEI消息或图片层级SEI消息。一些序列层级信息可以包含在SEI消息中，例如，在SVC的例子中的可缩放信息SEI消息，以及在MVC中的视图可缩放信息SEI消息。这些示例性的SEI消息可以传送关于例如操作点的提取和操作点的特性的信息。另外，封装单元30可以形成清单文件，例如，对表示的特性进行描述的媒体呈现描述(MPD)。封装单元30可以根据可扩展标记语言(XML)来格式化MPD。
封装单元30可以将用于多媒体内容的一个或多个表示的数据连同清单文件(例如，MPD)提供给输出接口32。输出接口32可以包括网络接口或者用于向存储介质写入的接口，例如，通用串行总线(USB)接口、CD、DVD、蓝光写入器、烧录器或压模、到磁性或闪速存储介质的接口、或者用于存储或发送媒体数据的其它接口。封装单元30可以将多媒体内容的表示中的每个表示的数据提供给输出接口32，其中输出接口32可以经由网络传输或存储介质来将数据发送给服务器设备60。在图1的例子中，服务器设备60包括存储各种多媒体内容64的存储介质62，其中每个多媒体内容64包括对应的清单文件66以及一个或多个表示68A-68N(表示68)。在一些例子中，输出接口32还可以将数据直接发送给网络74。
在一些例子中，表示68可以被分离成适配集。即，表示68的各个子集可以包括对应的共同特性集合，例如，编解码器、简档和层级、分辨率、视图数量、区段的文件格式、文本类型信息(其可以对要利用表示来显示的文本和/或要由例如说话者解码并呈现的音频数据的语言或其它特性进行标识)、相机角度信息(其可以描述针对适配集中的表示的场景的相机角度或真实世界相机视角)、描述针对特定观众的内容合适性的分级信息等。
清单文件66可以包括对与特定适配集相对应的表示68的子集以及针对适配集的共同特性进行指示的数据。清单文件66还可以包括对针对适配集的单独表示的单独特性(例如，比特速率)进行表示的数据。以此方式，适配集可以提供简化的网络带宽适配。可以使用清单文件66的适配集元素的子元素来指示适配集中的表示。
服务器设备60包括请求处理单元70和网络接口72。在一些例子中，服务器设备60可以包括多个网络接口。此外，可以在内容传递网络的其它设备(例如，路由器、桥接器、代理设备、交换机或其它设备)上实现服务器设备60的特征中的任何或所有特征。在一些例子中，内容传递网络的中间设备可以高速缓存多媒体内容64的数据，并且包括大体上符合服务器设备60的组件的组件。通常，网络接口72被配置为经由网络74来发送和接收数据。
请求处理单元70被配置为从客户端设备(例如，客户端设备40)接收针对存储介质62的数据的网络请求。例如，请求处理单元70可以实现如RFC 2616，1999年6月，IETF，网络工作组，R.Fielding等人的“超文本传输协议–HTTP/1.1”中所描述的超文本传输协议(HTTP)版本1.1。即，请求处理单元70可以被配置为接收HTTP GET或部分GET请求并且响应于该请求而提供多媒体内容64的数据。请求可以指定表示68中的一个表示的区段(例如，使用该区段的URL)。在一些例子中，请求还可以指定区段的一个或多个字节范围，因此包括部分GET请求。请求处理单元70还可以被配置为对HTTP HEAD请求进行服务，以提供表示68中的一个表示的区段的报头数据。在任何情况下，请求处理单元70可以被配置为对请求进行处理，以向请求设备(例如，客户端设备40)提供所请求的数据。
另外地或替代地，请求处理单元70可以被配置为经由广播或多播协议(例如，eMBMS)来传递媒体数据。内容准备设备20可以以所描述的方式大体上相同的方式来创建DASH区段和/或子区段，但是服务器设备60可以使用eMBMS或另一个广播或多播网络传输协议来传递这些区段或子区段。例如，请求处理单元70可以被配置为从客户端设备40接收多播群组加入请求。即，服务器设备60可以向与特定媒体内容(例如，实况事件的广播)相关联的客户端设备(包括客户端设备40)通告与多播群组相关联的互联网协议(IP)地址。客户端设备40转而可以提交加入多播群组的请求。可以在整个网络74(例如，构成网络74的路由器)上传播该请求，使得促使路由器将以关联于多播群组的IP地址为目的地的业务引导到订阅客户端设备(例如，客户端设备40)。DASH指代HTTP的动态自适应流式传输，例如，如INTERNATIONAL STANDARD ISO/IEC 23009-1Second edition 2014-05-01InformationTechnology-Dynamic Adaptive Streaming Over HTTP(DASH)Part 1:MediaPresentation Description and Segment Formats中所定义的。
如图1的例子中所示出的，多媒体内容64包括清单文件66，其中清单文件66可以对应于媒体呈现描述(MPD)。清单文件66可以包含对不同的替代表示68(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如编解码器信息、简档值、层级值、比特速率以及表示68的其它描述性特性。客户端设备40可以获取媒体呈现的MPD，以确定如何访问表示68的区段。
具体而言，获取单元52可以获取客户端设备40的配置数据(未示出)，以确定视频解码器48的解码能力和视频输出44的渲染能力。配置数据还可以包括以下各项中的任何或所有项：客户端设备40的用户所选择的语言偏好、与客户端设备40的用户所设置的深度偏好相对应的一个或多个相机视角、和/或客户端设备40的用户所选择的分级偏好。获取单元52可以包括例如被配置为提交HTTP GET和部分GET请求的web浏览器或媒体客户端。获取单元52可以与客户端设备40的一个或多个处理器或处理单元(未示出)所执行的软件指令相对应。在一些例子中，可以在硬件、或者硬件、软件、和/或固件的组合中实现针对获取单元52所描述的功能中的全部或部分功能，其中，可以提供必要的硬件来执行针对软件或固件的指令。
获取单元52可以将客户端设备40的解码和渲染能力与清单文件66的信息所指示的表示68的特性进行比较。获取单元52可以初始地获取清单文件66的至少一部分以确定表示68的特性。例如，获取单元52可以请求清单文件66的描述一个或多个适配集的特性的部分。获取单元52可以选择表示68的子集(例如，适配集)，该子集具有客户端设备40的编码和渲染能力能够满足的特性。获取单元52然后可以确定针对适配集中的表示的比特速率，确定当前可用的网络带宽量，以及从表示(其具有网络带宽能够满足的比特速率)中的一个表示中获取区段。
通常，较高比特速率的表示可以产生较高质量的视频回放，而当可用的网络带宽减小时，较低比特速率的表示可以提供足够质量的视频回放。因此，当可用的网络带宽相对高时，获取单元52可以从相对高的比特速率的表示中获取数据，而当可用的网络带宽低时，获取单元52可以从相对低的比特速率的表示中获取数据。以此方式，客户端设备40可以通过网络74来流式传输多媒体数据，同时也适应网络74的变化的网络带宽可用性。
另外地或替代地，获取单元52可以被配置为接收根据广播或多播网络协议(例如，eMBMS或IP多播)的数据。在这些例子中，获取单元52可以提交加入与特定媒体内容相关联的多播网络群组的请求。在加入多播群组之后，获取单元52可以接收多播群组的数据而无需向服务器设备60或内容准备设备20发出进一步的请求。当不再需要多播群组的数据时，获取单元52可以提交离开多播群组的请求，例如，以便停止回放或将频道改变到不同的多播群组。
网络接口54可以接收所选择的表示的区段的数据并将其提供给获取单元52，获取单元52转而可以将区段提供给解封装单元50。解封装单元50可以将视频文件的元素解封装为组成PES流，对PES流进行解包以获取经编码的数据，以及将经编码的数据发送给音频解码器46或视频解码器48，这取决于经编码的数据是音频流还是视频流的一部分(例如，如流的PES分组报头所指示的)。音频解码器46对经编码的音频数据进行解码并将经解码的音频数据发送给音频输出42，而视频解码器48对经编码的视频数据进行解码并将经解码的视频数据(其可以包括流的多个视图)发送给视频输出44。
视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52以及解封装单元50均可以视适用情况实现为各种适当的处理电路中的任何处理电路，例如，一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、分立逻辑电路、软件、硬件、固件或者其任何组合。视频编码器28和视频解码器48中均可以包括在一个或多个编码器或解码器中，其中任一项可以集成为组合的视频编码器/解码器(CODEC)的一部分。同样地，音频编码器26和音频解码器46均可以包括在一个或多个编码器或解码器中，其中任一项可以集成为组合的CODEC的一部分。包括视频编码器28、视频解码器48、音频编码器26、音频解码器46、封装单元30、获取单元52和/或解封装单元50的装置可以包括集成电路、微处理器和/或无线通信设备(例如，蜂窝电话)。
客户端设备40、服务器设备60和/或内容准备设备20可以被配置为根据本公开内容的技术来操作。出于举例的目的，本公开内容针对客户端设备40和服务器设备60来描述这些技术。但是，应当理解的是，作为服务器设备60的替代或者除服务器设备60之外，内容准备设备20也可以被配置为执行这些技术。
封装单元30可以形成NAL单元，其包括标识NAL单元所属的节目的报头以及有效载荷，例如音频数据、视频数据或者描述NAL单元所对应的流的数据。例如，在H.264/AVC中，NAL单元包括一个字节的报头和变化大小的有效载荷。在其有效载荷中包括视频数据的NAL单元可以包括各种粒度水平的视频数据。例如，NAL单元可以包括视频数据块、多个块、视频数据切片或者视频数据的整个图片。封装单元30可以从视频编码器28接收具有基本流的PES分组形式的经编码的视频数据。封装单元30可以将每个基本流与相应的节目相关联。
封装单元30还可以根据多个NAL单元来组装访问单元。通常，访问单元可以包括用于表示视频数据帧的一个或多个NAL单元，以及对应于该帧的音频数据(当该音频数据可用时)。访问单元通常包括针对一个输出时间实例的所有NAL单元，例如，针对一个时间实例的所有音频和视频数据。例如，如果每个视图具有每秒20帧(fps)的帧速率，则每个时间实例可以对应于0.05秒的时间间隔。在该时间间隔期间，可以同时渲染针对相同访问单元(相同时间实例)的所有视图的特定帧。在一个例子中，访问单元可以包括一个时间实例中的经编码图片，其可以被呈现为主要经编码图片。
因此，访问单元可以包括共同时间实例的所有音频帧和视频帧，例如对应于时间X的所有视图。本公开内容还将特定视图的经编码图片称为“视图分量”。即，视图分量可以包括针对特定时间处的特定视图的经编码图片(或帧)。因此，访问单元可以定义为包括共同时间实例的所有视图分量。访问单元的解码顺序不必与输出顺序或显示顺序相同。
媒体呈现可以包括媒体呈现描述(MPD)，其可以包含对不同的替代表示(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如编解码器信息、简档值和层级值。MPD是清单文件(例如，清单文件66)的一个例子。客户端设备40可以获取媒体呈现的MPD，以确定如何访问各种表示的电影片段。电影片段可以位于视频文件的电影片段盒(moof盒)中。
清单文件66(其可以包括例如MPD)可以对表示68的区段的可用性进行通告。即，MPD可以包括对表示68中的一个表示的第一区段变为可用的挂钟时间进行指示的信息，以及对表示68内的区段的持续时间进行指示的信息。以此方式，客户端设备40的获取单元52可以基于在特定区段之前的区段的开始时间以及持续时间来确定每个区段何时可用。
在封装单元30已经基于接收到的数据将NAL单元和/或访问单元组装成视频文件之后，封装单元30将视频文件传递给输出接口32以用于输出。在一些例子中，封装单元30可以本地地存储视频文件或者经由输出接口32将视频文件发送给远程服务器，而不是直接地将视频文件发送给客户端设备40。输出接口32可以包括例如发射机、收发机、用于向计算机可读介质(例如，光学驱动器、磁性介质驱动器(例如，软盘驱动器))写入数据的设备、通用串行总线(USB)端口、网络接口或者其它输出接口。输出接口32将视频文件输出到计算机可读介质34，例如传输信号、磁性介质、光学介质、存储器、闪速驱动器或者其它计算机可读介质。
网络接口54可以经由网络74来接收NAL单元或访问单元，并且经由获取单元52将NAL单元或访问单元提供给解封装单元50。解封装单元50可以将视频文件的元素解封装为组成PES流(constituent PES stream)，对PES流进行解包以获取经编码的数据，并且将经编码的数据发送给音频解码器46或视频解码器48，这取决于经编码的数据是音频流还是视频流的一部分(例如，如流的PES分组报头所指示的)。音频解码器46对经编码的音频数据进行解码并将经解码的音频数据发送给音频输出42，而视频解码器48对经编码的视频数据进行解码并将经解码的视频数据(其可以包括流的多个视图)发送给视频输出44。
出于本公开内容的技术的目的，假设客户端设备40(或者其它接收设备)和服务器设备60(或者内容准备设备20或其它发送设备)具有根据协调世界时间(UTC)的准确的时钟。可以在发射机(例如，服务器设备60)中经由全球定位系统(GPS)或类似技术来建立时间。例如，可以在客户端设备40的物理层中(例如，在网络接口54内)经由高级电视系统委员会(ATSC)3.0技术来建立时间。虽然DASH协议强制该要求，但是DASH标准当前没有定义用于实现同步时间的实际方法。当然，客户端设备40处的ATSC 3.0时间名义上是在服务器设备60的时间之后的飞行时间。但是，对于本公开内容的技术来说，这是期望的结果。即，客户端设备40中的本地时间将准确地描述物理层处的数据块的位置。下面更加详细地描述了本公开内容的技术。
在一些例子中，服务器设备60和客户端设备40被配置为使用稳健报头压缩(ROHC)来压缩/解压缩分组的报头数据。ROHC技术包括使用上下文信息来执行压缩。因此，当服务器设备60使用特定的上下文来压缩分组的报头信息时，客户端设备40使用相同的上下文来解压缩该分组的报头信息是重要的。因此，当客户端设备40在随机访问点(RAP)处执行随机访问时，应当提供用于确定上下文(该上下文用于解压缩针对包括该RAP的一个或多个分组的报头信息)的信息。因此，本公开内容的技术包括提供ROHC上下文信息连同RAP。
例如，当发送媒体呈现描述(MPD)(或其它清单文件)和初始化区段(IS)时，服务器设备60可以紧接在MPD/清单文件之前发送ROHC上下文初始化数据。同样地，客户端设备40可以紧接在MPD/清单文件和IS之前接收ROHC上下文初始化数据。“紧接在…之前”可以意指早于MPD/清单文件和IS并且紧邻MPD/清单文件和IS来接收用于ROHC上下文初始化的数据。
图2是示出了示例性多媒体内容102的元素的概念图。多媒体内容102可以与多媒体内容64(图1)或存储在存储器62中的另一个多媒体内容相对应。在图2的例子中，多媒体内容102包括媒体呈现描述(MPD)104以及多个表示110-120。表示110包括可选的报头数据112和区段114A-114N(区段114)，而表示120包括可选的报头数据122和区段124A-124N(区段124)。为了方便起见，使用字母N来标示表示110、120中的每个表示中的最后一个电影片段。在一些例子中，在表示110、120之间可能存在不同数量的电影片段。
MPD 104可以包括与表示110-120分离的数据结构。MPD 104可以对应于图1的清单文件66。同样地，表示110-120可以对应于图1的表示68。通常，MPD 104可以包括通常描述表示110-120的特性(例如，编码和渲染特性、适配集、MPD 104所对应的简档、文本类型信息、相机角度信息、分级信息、特技模式信息(例如，对包括时间子序列的表示进行指示的信息)和/或用于获取远程周期的信息(例如，用于在回放期间将目标广告插入到媒体内容中))的数据。
报头数据112(当存在时)可以描述区段114的特性，例如，随机访问点(RAP，还被称为流访问点(SAP))的时间位置，区段114中的哪个区段包括随机访问点，到区段114内的随机访问点的字节偏移，区段114的统一资源定位符(URL)，或者区段114的其它方面。报头数据122(当存在时)可以描述区段124的类似特性。另外地或替代地，这些特性可以完全地包括在MPD 104中。
区段114、124包括一个或多个经编码的视频样本，其中每个视频样本可以包括视频数据帧或切片。区段114的经编码的视频样本中的每个视频样本可以具有类似的特性，例如，高度、宽度以及带宽要求。可以由MPD 104的数据来描述这些特性，尽管图2的例子中没有示出这种数据。MPD 104可以包括如由3GPP规范描述的特性，外加本公开内容中所描述的用信号发送的信息中的任何或所有信息。
区段114、124中的每个区段可以与唯一的统一资源定位符(URL)相关联。因此，可以使用流式传输网络协议(例如，DASH)来独立地获取区段114、124中的每个区段。以此方式，目的地设备(例如，客户端设备40)可以使用HTTP GET请求来获取区段114或124。在一些例子中，客户端设备40可以使用HTTP部分GET请求来获取区段114或124的特定字节范围。
图3是示出了服务器设备(例如，图1的服务器设备60)和客户端设备(例如，图1的客户端设备40)的示例性组件的框图。在该例子中，服务器设备包括媒体编码器、分段器、发送机(在该例子中，发送机使用ROUTE传输协议)、MAC/PHY调度器以及激励器/放大器。在该例子中，客户端设备包括MAC/PHY接收机、传输接收机(在该例子中，传输接收机使用ROUTE协议)、媒体播放器(在该例子中，媒体播放器是DASH客户端)以及编解码器。
可以在硬件中或者在硬件和软件的组合中实现服务器设备的各个元件(例如，媒体编码器、分段器、发送机以及MAC/PHY调度器)中的任何或所有元件。例如，可以在一个或多个微处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)和/或分立逻辑电路或者其组合中实现这些单元。另外地或替代地，可以在由硬件执行的软件中实现这些单元。针对软件的指令可以存储在计算机可读存储介质上，并且由一个或多个处理单元(其可以包括诸如上面讨论的硬件)来执行。
媒体编码器产生具有回放时间信息的经压缩的媒体。分段器将该媒体打包到文件中，很可能是ISO BMFF(基本媒体文件格式)。分段器将作为字节范围的文件传递给发送机。发送机对作为字节范围文件进行包装以用于以IP/UDP/ROUTE传递。MAC/PHY取得IP分组并经由RF将其发送给接收机。虚线处的连接是端到端工作的。出于给出块名称的目的，这是简化的讨论。
根据本公开内容的技术，服务器设备包括与媒体数据的传递相关的第一单元和第二单元。第一单元向第二单元发送针对媒体数据的描述性信息。在该例子中，第一单元和第二单元可以分别对应于分段器和发送机或者发送机和MAC/PHY调度器。描述性信息指示媒体数据的区段或者区段的字节范围中的至少一项，以及能够传递区段或区段的字节范围的最早时间或者能够传递区段或区段的字节范围的最迟时间中的至少一项。第一单元还向第二单元发送媒体数据。
应当理解的是，服务器设备可以进一步封装媒体区段或者其部分(例如，特定的字节范围)以用于网络传输。例如，服务器设备可以以一个或多个分组的形式来对媒体区段的数据进行封装。通常，通过利用根据网络栈的不同层级处的一个或多个协议(例如，根据开放式系统互联(OSI)模型)的数据对有效载荷进行封装来形成分组。例如，可以用传输控制协议(TCP)报头和互联网协议(IP)报头来对有效载荷(例如，ISO BMFF文件的全部或部分)进行封装。应当理解的是，描述性信息也适用于用于对有效载荷进行封装的数据。例如，当描述性信息指示能够传递区段或区段的字节范围的最早时间时，最早时间也适用于用于对区段或字节范围进行封装的任何数据(例如，根据一个或多个网络协议的数据)。同样地，当描述性信息指示能够传递区段或区段的字节范围的最迟时间时，最迟时间也适用于用于对区段或字节范围进行封装的任何数据。
以此方式，第二单元可以被配置为根据描述性信息来向客户端设备传递媒体数据。例如，第二单元可以确保不早于最早时间传递区段或区段的字节范围、和/或确保在最迟时间之前传递区段或字节范围。
通过根据描述性信息来发送数据(例如，在最早时间之后和/或在最迟时间之前)，服务器设备可以确保媒体数据在客户端可以使用该媒体数据的时间抵达客户端设备。如果媒体数据早于最早时间或者迟于最迟时间抵达，则客户端设备可能丢弃媒体数据，因为该媒体数据可能是不可用的。此外，如果媒体数据在最迟时间之后抵达(或者被丢弃)，则该媒体数据可能不可用作为对随后的媒体数据进行解码的参考媒体数据。例如，如果媒体数据包括一个或多个参考图片，则由于参考图片将不可用于参考，因此随后的图片可能不可准确地解码。以此方式，本公开内容的技术可以避免浪费的带宽并改善用户体验。
描述性信息还可以包括以下各项中的任何或所有项：区段或字节范围的受制于特定媒体编码器的部分；目标时间，其中区段或字节范围应当在目标时间处或紧接在目标时间之后传递；能够传递区段或字节范围的最迟时间；针对区段或字节范围内的数据的呈现时间戳；包括区段的媒体流相对于其它媒体流关于针对媒体流的数据的目标传递时间的优先级；和/或针对区段或字节范围内的数据的解码时间戳。因此，第二单元可以根据该额外信息中的任何或全部信息来传递媒体数据。例如，第二单元可以确保尽可能地接近目标时间、和/或在呈现时间和/或解码时间之前传递媒体数据。同样地，第二单元可以根据优先级信息来传递媒体数据。例如，如果仅可以按时传递媒体数据的多个离散单元中的一个离散单元，则第二单元可以确定离散单元中的哪个离散单元具有最高优先级，并且在其它离散单元之前传递该离散单元。这里，术语媒体数据的“离散单元”可以指代例如区段或区段的字节范围。
图4是示出了(图3的客户端设备的)MAC/PHY层处接收到数据的时间和媒体播放器输出从接收到的数据产生的媒体数据的时间之间的差异的例子的概念图。MAC/Phy层和媒体播放器可以互操作，以在工作的系统中实现传输缓冲器模型(其可以使两个准独立时间线一致)。这两个时间线包括示出了离散时间媒体输出事件的媒体传递和消耗时间线(图4的底部)以及示出了离散时间数据传递事件的MAC/PHY层数据传递时间线(图4的顶部)。
图4示出了接收机角度(例如，图3的客户端设备(其可以对应于图1的客户端设备40)的角度)。MAC/Phy时间线可以被认为是接收机中的MAC的输出处的物理层的脉冲响应，其在特定时间处具有数据突发。媒体播放器输出时间线可以是特定时间处的视频帧或音频样本。图4顶部的箭头表示数据传递事件(在MAC/Phy时间线中)或者例如在媒体播放器输出时间线中的视频帧。图4底部的箭头表示媒体播放器输出事件，例如，特定时间处的媒体数据的呈现。
图5是示出了(图3的客户端设备的)MAC/Phy层处接收到数据(即，图5顶部的MAC/PHY时间线中的离散时间数据传递事件)的时间、(图3的客户端设备的)DASH播放器接收到输入(即，图5的垂直中部的DASH播放器输入时间线中的离散时间媒体数据事件)的时间、以及DASH播放器传递输出(即，图5底部的DASH播放器输出时间线中的离散时间媒体输出事件)的时间之间的差异的例子的概念图。媒体输出通常不能直接地符合MAC/Phy层的数据传递事件。这是因为输出离散时间媒体事件可能具有许多输入媒体样本。例如，音频可能具有每个音频帧数千个样本。举另一个例子，输出视频帧可能具有描述输出视频帧所需要的N个输入视频帧。传输缓冲器模型允许MAC/Phy离散时间数据传递事件和DASH播放器离散时间媒体传递事件之间的一致。
图6是示出了数据传递事件和媒体传递事件之间的对应关系的例子的概念图。存在驱动事件的某些数据集合，例如，开始并播放媒体以及下一个媒体帧或帧组。ROUTE发送机/接收机接口的字节范围传输机制允许分段器(图3)定义对DASH播放器有意义的媒体的离散单元。有意义的离散单元(媒体数据事件)的例子是用于开始视频回放的单元，其可以包括MPD、IS、电影盒(Moof)以及多达6个针对HEVC的经压缩的视频帧。图6示出了接收机视图以及各层间的时间关系/对应关系。具体而言，图6示出了MAC/PHY时间线中的离散时间数据传递事件、DASH播放器输入时间线中的离散时间媒体数据事件，以及DASH播放器输出时间线中的离散时间媒体输出事件。
图7是示出了MAC/Phy数据传递块的概念图。根据本公开内容的技术，这些块不再是单独的MPEG-2 TS(传输流)分组(尽管在ATSC 1.0中它们是单独的MPEG-2 TS分组)。图7示出了从由MAC地址定义的输入端口到输出端口的现代物理层传输数据块。这些数据块的大小的范围可以是2KB至8KB，但是在任何情况下远大于MPEG-2 TS分组。这些数据块可以包含IP分组。MAC地址可以映射到IP地址和端口号。在MAC/Phy输出处知道块的内容的传递时间(依据相对于MAC/Phy输入的延迟)。图7表示数据传递块的经抽象的模型。恰好是具有已知传递时间的IP分组的离散数据单元被传递给接收机。
图8是示出了发送过程和接收过程的例子的概念图。在由(例如，图3的)服务器设备执行的发送过程中，分段器被配置有对经压缩的媒体的数据结构以及所定义的媒体事件的时间传递要求(例如，编解码器的输入处在特定的时间要求特定的音频帧)进行定义的数据。特殊事件(例如，媒体层处的随机访问点(RAP))具有额外要求的数据，但是分段器可以检测到RAP的存在并且可以预先准备该额外要求的数据，例如，MPD、IS、Moof等。MAC/Phy调度器在特定时间处将特定数据分配给特定的块。这些数据块在Phy/MAC的输出处具有已知的接收时间。
在由(例如，图3的)客户端设备执行的接收过程中，Phy/MAC层接收数据块并立即地(按时间表)将其公布，即，通过将数据块提供给传输单元。这些IP/UDP/ROUTE分组直接地进入ROUTE传输缓冲器。媒体传递事件按时间表可用于DASH播放器。播放器按时间表将媒体向上传递给编解码器。编解码器然后按时间表进行解码。
对于发送和接收过程来说存在某些边界条件。对于周期边界，假如在周期边界处存在媒体的任何切换(例如，在表示之间)(例如，用于广告插入)，则为了使切换是无缝的，不能提早传递周期的第一字节。如果提早传递第一字节，则广告可能不能正确地开始。结束点不是那么敏感，因为下一个周期(无论是广告还是返回到节目)的开始传输RAP(T-RAP)将干净地开始解码器，但是如果在正确的目标周期期间接收最后一个字节将会更好。此外，对于IP片段和碎片整理(defragment)，分别在ROUTE发送机和ROUTE接收机中处理IP封装和解封装。ROUTE发送机对IP分组进行组织，使得T-RAP和周期边界是干净的。传输接收机可以提早(但是从不在周期边界处)看到下一个媒体传递事件(MDE)媒体事件的片段。
安全开始：媒体事件时间线的定义和物理层调度可以保证为了开始而需要的媒体在正确的时间抵达。所以，至此，如果客户端设备具有数据，则该客户端设备可以立即播放数据。至此所描述的系统可以通过实施早时间和迟时间来假设地实现这一点，但是这会对物理层施加不实际的要求，这会导致过于激进的媒体压缩(其是使经编码的媒体符合所要求的呈现调度的物理层/MAC调度器手段)。
宽松调度：为了使物理层具有能够调度所有数据的最佳机会，如果在传递时间上存在某种灵活性将是不错的。不是每个字节可以同时传递给接收机。例如，如果phy传递速率是20Mbs/sec，并且服务占用3Mbs/sec，则传递可以以平均7X真实时间运行。在该示例性用例中，对于0.5秒的区段，0.5秒的时间余量会将是非常充足的。
图9A和图9B示出了根据本公开内容的技术的、应用于媒体数据的前向纠错(FEC)的例子。下面描述了在执行安全开始时的示例性场景。在一个例子中，存在提早开始。即，客户端设备可能在接收到以T-RAP开始的媒体传递事件时立即尝试播放媒体数据。在最坏的情况下，这导致短暂的停顿。停顿的最大持续时间取决于时间余量。停顿持续时间可以定义为实际的开始点和功能上要求的长期开始时间之间的差异。对于严格符合的相对于媒体呈现时间线的媒体大小，物理层调度器确保安全开始是可能的，但是这可能不会产生最佳可能的视频质量。这里关注的关键方面是早/迟机制足够灵活以允许出现期望的结果。结果的多个方面与以下事实相关：可以存在不同的目标并且这些机制可以有效地服务所有目标。
在安全开始中，客户端设备在最后一个字节的经调度的传递之后播放媒体数据。可以保证对媒体传递事件的最后一个字节的接收。传递窗口持续时间可以是动态的。除有可能周期结束之外，迟时间大部分时间很可能按固定的时间表。类似地，除在周期开始时之外，早时间可以是灵活的。也就是说，灵活性是可能的，但是在周期边界处可能受约束。图9A示出了如果A/V对象与A/V绑定束上的FEC对齐，则FEC如何没有影响。图9B示出了如果多达五个A/V对象与A/V绑定束上的FEC对齐(这会增加容量(其有益于记录))，则FEC如何会引起零至四秒的延迟。
图10是示出了各种区段传递样式的概念图。为了避免启动延迟，MPD和IS应当紧接在RAP之前。因此，图10示出了其中MPD和IS在RAP之前的两个例子。如果使用稳健报头压缩(ROHC)，则在两个例子中可以紧接在MPD之前插入ROHC上下文初始化数据。以此方式，ROHC解压缩器(或解码器)可以接收ROHC上下文初始化数据并且使用该初始化数据来恰当地解压缩报头。上下文信息可以特定于ROUTE会话或每个LCT会话，其中，ROUTE会话可以包括一个或多个LCT会话。因此，对于单个ROUTE会话和/或对于ROUTE会话的一个或多个LCT会话中的每个LCT会话，可以在MPD之前传递上下文信息。
图11是示出了真实的传输缓冲器模型的概念图。通过本公开内容的技术使该传输缓冲器模型变得简单。就启动和溢出而言，仅存在一个缓冲器，并且该缓冲器是传输缓冲器。MAC/phy调度保证启动，而不涉及缓冲器模型。仅存在一个重要的界限。媒体在经调度的传递时间进入缓冲器，并且当其作为文件在输出区域中发布时被删除。服务开始(servicestart)(即，以T-RAP开始的MDE)清除缓冲器。缓冲器模型在数据将传递或发布到传输缓冲器的每个时间t处进行更新。寄存器值是针对接收机设备(客户端设备)处的时间t的缓冲器模型充满度(fullness)(以字节为单位)。缓冲器包含与该会话中的当前传递和所有其它当前未解决的传递相关的所有IP/UDP/ROUTE分组，包括针对每个当前活动传递的所有相关AL-FEC。当发布的一个或多个对象的状态是已解决时，缓冲器模型减少所有与这些对象相关的分组的大小。在这种使用方式中，当ROUTE传输接收机已确定状态并相应地采取行动时(即，发布或丢弃对象)，该对象“已解决”。删除相应的相关传输数据，并且缓冲器模型寄存器相应地减少。
以此方式，通过建立针对物理层的MAC/Phy调度(其对于所使用的MAC/Phy来说是准确的)，就缓冲器模型而言不存在启动条件。由于保证了时间线事件，因此可以直接计算缓冲器充满度。已知大小的媒体事件在已知时间进入。在已知时间(即，当区段发布到输出区域时)删除媒体。
图12A和图12B是将本公开内容的技术与MPEG-2 TS模型进行对比的概念图。在图12A中，在被发送和接收的分组之间存在固定延迟。这对于MPEG-2 TS是相当优良的模型并且该模型很好地服务于业界。但是，如图12B中所示出的，尝试使其适应ATSC 3.0可能具有一些不令人期望的结果。图12B包括前向纠错(FEC)解码缓冲器、去抖动缓冲器以及MPEG媒体传输协议(MMTP)解封装缓冲器。为了使MPEG-2 TS模型有效，必须用低通滤波器来对ASTC3.0物理层的固有突发方面进行平滑。该物理层平滑最终使到播放器的媒体传递延迟。
图13是示例性的接收机IP栈的框图，其中可以由客户端设备(例如，图3的客户端设备和/或图1的客户端设备40)来实现示例性的接收机IP栈。图13示出了物理层，该物理层向UDP IP栈提供数据块，UDP IP栈向AL-FEC和文件传递协议层提供分组，AL-FEC和文件传递协议层向DASH客户端/ISO-BMFF/MMT/文件处理程序层提供文件或文件的字节范围，DASH客户端/ISO-BMFF/MMT/文件处理程序层向编解码器的解码器提供媒体流。文件传递协议层和文件处理程序层之间的接口有可能会允许向上传递文件和或文件的部分(例如，文件的字节范围)。此外，这些文件或文件的部分可能具有针对在接收机处进行接收的时限并且还具有优选的接收顺序。文件可以表示例如根据DASH的媒体内容的表示的区段。
针对这种系统的历史方法是假设经由固定延迟和带宽管道跨物理层的恒定延迟的缓冲器模型，如图12A中所描绘的。这些系统在RF处对MPEG-2 TS分组进行表达，并且经常将整个输入流视为单个系列的MPEG2传输流分组。这些MPEG2传输流可能包含具有若干不同的唯一分组ID或所谓的PID的分组。
现代物理层通常不将MPEG-2 TS表达为RF处的特征。就算携带了MPEG-2 TS，其也是在某个更大的容器(例如，2K字节或8K字节)内，而该更大的容器可能包含IP分组。可以对这些RF数据块进行分段，尽管当尝试实现直接访问某些地址时，不这样做是更加电池高效的。
图14是示出了根据恒定延迟假设和基于块传递的物理层来实现的示例性发送系统的概念图。图14描绘了发送机设备的Phy/MAC缓冲器，以及接收机设备的两个缓冲器(包括Phy/MAC缓冲器和传输缓冲器)。对于图14的系统的发送侧，存在很大程度上对称的发送栈，如在下面所描述的图15中所示出的。这些现代物理层以如下方式演进：使得可以将这些现代物理层视为对数据块的传输，其中数据块具有已知的大小以及从输入到输出的可知的延迟。承载数据频道的这种配置很大程度上是利用来自所定义的MAC/Phy特性的已知出发时间和传递时间来分配容量。不需要将这些类型的系统视为具有恒定延迟的单个或甚至多个传递管道。此外，为了实现恒定延迟，这些系统实际上可能必须实现输入和/或输出缓冲器，这会增加整体延时并减慢频道改变。图14中示出了这种系统的经抽象的接收机模型。
图15是示出了源设备的示例性发射机配置的框图。在该例子中，源设备(本文中还被称为发送机设备或服务器设备)包括媒体编码器、一个或多个分段器、ROUTE发送机以及MAC/phy单元。与图14的系统的配置相反，向MAC/phy接口提供数据(其具有关于目的地处何时需要该数据的信息)并且令MAC/phy调度器优化所定义的虚拟传递管道中的已知管道(可能通过动态配置)是更有效的。通常由IP地址和端口号来映射这些虚拟传递管道。
图16是示出了在具有经调度的分组传递的系统中针对数据的示例性传递模型的概念图。该特定配置示出了ROUTE传输协议的使用，出于经由块传输物理层来发送对象(文件)的目的，ROUTE传输协议是合适的，但是协议还可以是FLUTE(IETF RFC 6726中所定义的单向传输的文件传递)，FLUTE具有类似的功能，尽管具有稍微要少些的特征。图16中示出了针对这种系统的修正模型。发射机和接收机二者都不需要包含接收机物理层平滑缓冲器，如图16中所示出的。经调度的分组直接地或以最小延迟传递给接收机的传输缓冲器。由于在更接近实际需要的时间传递媒体，因此所产生的设计既更简单又会引起更快的启动。
返回参照图15，ROUTE、FLUTE或其它文件传递协议可以对要传递给接收机的对象(文件)进行处理。在FLUTE的情况下，这通常是每次单个文件以及整个对象(可选地具有FEC)。ROUTE和可能的其它协议还可以将对象作为一系列字节范围来传递。可以例如以不透明的方式将这些字节范围传递给ROUTE发送机。为了对字节范围进行处理，ROUTE发送机不必知道文件类型。ROUTE发送机仅将对象的字节范围传递给链路的另一端。此外，对象和或字节范围在接收机传输缓冲器接口处可能具有要求的或期望的传递时间，如上面讨论的可能在扩展报头中表达的传递时间。也就是说，整个对象可能必须在某个时间之前传递给接收机传输缓冲器接口(这可能符合availabilityStartTime)，或者对象的一部分在某个时间之前传递给接收机传输缓冲器接口(这可能符合扩展报头)。情况是，多个对象可能同时在到接收机的传递过程中。
该当前讨论是针对到一个传输缓冲器的一个传递的。所传递的对象可以是DASH区段(INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01Information Technology-Dynamic Adaptive Streaming Over HTTP(DASH)Part 1:Media Presentation Description and Segment Formats)，并且文件类型可以是专用于流式传输媒体的ISO BMFF，如ISO/IEC 14496-12:2012(E),INTERNATIONAL STANDARD ISO/IEC14496-12 Fourth edition,2012-07-15 Corrected version 2012-09-15,Information Technology-Coding of Audio-Visual Objects Part 12:ISO Base MediaFile Format中所描述的。
ROUTE或其它发送机不需要知道“要传递的”对象的(例如，文件)的文件类型，但是所传递的文件类型可能具有对于接收机来说是重要的特定部分。图15中被示出为“分段器”的块可以确定所传递的媒体部分(字节范围)的重要性，并且还可以确定终端中所要求的文件或文件的部分的传递时间。通常，文件的前缀具有某个传递时间，以便使客户端以渐进的方式消耗文件。因此，在一个例子中，可能要求文件的特定前缀P1，以便呈现所包含的媒体直至时间T1。可能要求第二前缀P2>P1，以便呈现所包含的媒体直至时间T2>T1。可以使用流式传输媒体(例如，作为具有特定持续时间的一系列ISO BMFF文件来传输的视频或音频)来构造这种用例的例子。在这些所谓的区段文件内，某个字节范围对于媒体播放器(例如，DASH)来说可能具有时间重要性。这种例子可以是视频帧或帧组(这可能是先前描述的MDE)。某些编解码器类型可能要求编码器图像的N帧，以便在特定时刻或者可能在特定时刻之前产生单个输出视频帧。
分段器或类似的媒体或文件类型感知格式器可以以要求的传递时间来向ROUTE传输发送机提供字节范围。要求的传递时间可以被表达为要传递区段或区段的字节范围的最早时间和/或最迟时间中的任意一个或二者。对于特定的字节范围，该传递时间不需要是具体的。例如，所述要求可以指定“应当如此传递该字节范围：使得在时间X之后并且在时间Y之前在传输缓冲器处接收到该字节范围”，其中，X表示最早时间，并且Y表示最迟时间。当加入流时，在时间X之后到传输缓冲器的传递可以是相关的。如果过早地接收数据，则在加入事件(例如，周期边界的切换)中可能丢失数据。通过避开周期开始，接收机不能加入服务，这导致差的用户体验。另一个界限Y可以与例如跨多个设备的同步播出相关。假设的模型接收机可能不能够在任何迟于该传递界限所规定的时间播放媒体。假设的接收机具有ROUTE(接收机传输)缓冲器大小，保证其既不欠运行(under run)也不超限运行(over run)。例如在ROUTE协议中描述了所要求的缓冲器的实际大小。当然，情况是，假如接收机期望进一步延迟回放时间，则接收机可以分配更多的内存。
这些时间X和Y可以是绝对的或相对的。至发布到接口的时刻的相对时间似乎是优选的解决方案。应当理解的是，发送机将确定跨MAC/Phy的实际延迟，以便不要求不可服务的请求。一般来说，通过发送机远早于实际发送时间发布媒体，可以简化针对物理层调度器的任务。MAC/phy调度器具有更多的时间来映射媒体数据，则MAC/phy调度器可以更好地完成工作。
分段器可以指示传递时间应当接近Z。分段器还可以提供关于该时间的优先级。例如，在相同的ROUTE传递中可能要携带两个字节范围，但是这些字节范围中的一个字节范围具有关于接近时间Z的优先级，该优先级可以提供给ROUTE发送机并且随后提供给MAC/phy接口，以便使MAC/phy接口确定物理层处的最优传递排序。优先级可以例如产生顺序，以实现快速和一致的频道改变体验。在一些例子中，可以针对ROUTE会话来强加传递顺序，即，必须在接收机中的ROUTE接收机的输入处保留传递给调度器的字节范围/MDE的顺序。例如，语法元素(例如，标志)可以指示是否按传递顺序来提供ROUTE会话的数据，以及是否要保持该传递顺序。
因此，尽管某些字节范围可能具有半重叠的传递时间，但是如果语法元素指示数据已经是按顺序的并且要保持(即，保留)该顺序，则即使无序传递仍然会满足如通告的传递时间，也需要保持/保留该传递顺序。如果已指示按顺序传递，则期望在调度器之前的功能提供允许按顺序传递的早传递时间和迟传递时间。以此方式，语法元素(例如，标志)表示对当从例如MAC/phy接口向客户端设备发送媒体数据时是否必须保留媒体数据的传递顺序进行指示的语法元素的例子。
如所描绘的，图15示出了在围绕媒体编码器、分段器、ROUTE发送机以及MAC/phy的级联的闭环中可能或可以存在速率控制机制功能。这是公共配置，其中，多个媒体流通过公共或共享的物理层同时地发送。这种通用方法经常被称为统计复用。一般来说，统计复用器使用各个媒体流的统计独立性来将更多服务装入单个传递系统中。通常，媒体编码器输出经定义的编码语法。即，语法数据随后被放置在容器文件(例如，ISO BMFF)中。随后将这些文件封装到传输协议(例如，ROUTE或FLUTE)中。存在添加到分段器和发送机功能二者中的增量数据(例如，元数据和报头信息)。速率控制系统仅可以直接管理媒体的大小而通常不直接管理信号的元数据或报头部分的大小，尽管传送给MAC/phy的数据是由所有三种类型构成的，并且某个文件和或字节范围可能不包含受到媒体编码器控制的数据。
图17是示出了发送系统的更多细节的概念图。图17中示出了MAC/Phy的功能的实际实现方式。物理层调度器解决了物理层的传递调度(即，调度器可以确定在传递方面物理层实际上可以实现什么)，并且定义了对基带处的RF信号的描述。可以将该基带波形分发给多个发射机，这些发射机将同时生成相同波形以创建单频网络(SFN)。诸如FLO或媒体FLO以及LTE广播/eMBMS之类的系统已经使用了同时生成相同波形的这种方法。
图18是示出了区段时间的交错的概念图。交错区段时间可以使峰值比特速率要求最小化。可能需要以使得峰值带宽需求的可能冲突最小化方式来组织各个服务的区段时间。这对接口的设计没有影响，但是对单独的流的组织有影响。区段边界时间的这种组织可能与物理层具有特定的关系，如图18中所描绘的。
在图18中，区段被描绘为在时间上是线性的，与对物理层的访问一样。对服务的这种阶段划分往往对平均数据速率进行平滑而具有RAP或SAP的最小位移。区段内数据速率相对于呈现时间不是均匀的。这仅是一个示例性方法，提供该方法以说明物理层上的调度是实际启动延迟的确定因素。传输仅在最后适当的时刻或在最后适当的时刻之前将媒体沿着栈向上传递。
下面描述了系统的各个组件之间的接口的例子。媒体编码器可能有或者可能没有其自身和分段器之间的暴露的接口。但是，假如系统包括这种接口，则对于分段器来说是重要的字节范围可以离散地并直接地传递给分段器。重要方面可以包括：最迟传递时间，以便足够快地传递给传输缓冲器；以及最早目标传递时间，以便不会过早地将字节范围或对象传递给传输缓冲器。可以由分段器来分析地确定这些方面，其中分段器将经编码的媒体转换为区段，例如ISO BMFF文件。这些ISO BMFF文件包含将媒体帧传递给接收机中的媒体解码器的具体细节。在媒体编码器的语法之外该接口自身可以传送特定的所传递的媒体特征(例如，相关联的媒体帧、呈现时间戳和/或解码时间戳)的大小。
分段器和ROUTE发送机之间的接口可以提供以下信息：
·针对重要特征的适用字节范围或前缀
·所传递的数据的受制于特定媒体编码器的部分
●对于每个文件单个媒体类型，这是一一映射
●对于所谓的经复用的区段，针对媒体编码器(其在该区段中具有媒体)中的每个媒体编码器的比例的描述
·标识符，该标识符允许知道关于特定媒体编码器(其是源)的类型和可能的地址，很可能是IP地址和端口。
·可以传递字节范围的最早时间，使得在针对接收机中的传输缓冲器的最早特定时间之前不会接收到该字节范围。
·目标时间，其中媒体应当在目标时间处或者紧接在目标时间之后传递，使得在传输缓冲器处在正确的时间接收到该媒体。
·该媒体流与该传递中的其它媒体流相比关于精确的目标传递时间的相对优先级。
·可以传递字节范围的最迟时间。
发送机和MAC/phy之间的接口可以提供以下信息：
·针对当前传递的适用字节范围，可能是整个IP分组
·所传递的数据的受制于特定媒体编码器的部分
·标识符，该标识符允许知道特定媒体编码器的身份
·可以传递整个字节范围的最早时间。
·目标时间，其中媒体应当在目标时间处或者紧接在目标时间之后传递，使得在接收机传输缓冲器处在适当的时间及时接收到该媒体。
·该媒体流与该传递中的其它媒体流相比关于精确的目标传递时间的相对优先级。
·可以传递字节范围或前缀的最迟时间，使得在接收机中的传输缓冲器处及时接收到该字节范围或前缀。
所定义的接口级联允许MAC/phy调度器具有要传递的媒体的完整画面，这可以允许对物理层的调度。MAC/phy调度器可以看到在相关时间跨度中所传递的所有媒体。如果没有给定早时间，则目标时间可以是最早时间或早时间，并且目标时间可以被设置为相同的值。
下面描述了由MAC/phy层执行的示例性的调度器功能。只要认为有用，调度器就可以提前映射。这会增加整体延时，只要整体延时保持在合理的限度，这通常不是问题。但是，提前规划还会引起增加的效率以及特别是优化的频道改变。最迟传递的需求约束了phy层关于当前发送的媒体的选择。phy层在用于传递的分辨率方面还可能具有离散限制。这是单独物理层的特性，并且对于给定物理层来说，MAC/phy调度器已知该特性。
图19是示出了当流包括可以是可选的媒体数据以及强制的媒体时，目标时间和最早时间之间的差异的概念图。通常，流式传输媒体的传递具有时间线。存在消耗媒体的顺序。某些媒体可以是可选的。丢弃媒体是不令人期望的，尽管如果连续地接收流，则所丢弃的媒体可能是简短的并且仅在启动处。使用该特征会潜在地与所谓的公共加密发生干扰，因此必须将使用限制于早传递的数据不与DRM或诸如文件循环冗余码(CRC)(其可能由于丢失媒体而失效)之类的机制发生干扰的情况。针对早传递或很早传递的最可能的应用是大型文件传递，其中，最迟传递时间远超过物理层调度器的分析的前向时间深度，即，物理层容量没有完全用于流式传输媒体，并且可能在每次传递N字节的额定传递调度上的非实时文件可以机会性地占用更多的物理层容量。将预期依据目标时间和最迟时间来运行媒体。在这些情况下，目标时间和早时间将具有相同的值。
图20是具有潜在地可丢弃的帧组的视频序列的概念图。在该例子中，箭头表示可能的帧间预测。还存在图20中所示出的两行数字。上面一行指示在那些数字之上的帧的相对显示顺序。下面一行数字指示显示顺序中所标识的帧的解码顺序。即，第一帧(I帧)第一个显示并且第一个解码，第一P帧第八个显示并且第二个解码，第一B帧第二个显示并且第五个解码等等。
某些媒体元素可以被视为是可选的。例如，在帧组中，非RAP帧可以被视为是可选的。但是，如图20中所示出的，由于帧之间的依赖性，因此当丢弃某些帧时，依赖于所丢弃的帧的其它帧将不可恰当地解码，并且因此也可能被丢弃。在图20中，在下面一行数字中概述了要作为组来丢弃的帧。例如，如果帧8被丢弃，则所有随后的帧(按解码顺序)也被丢弃。另一方面，如果帧4被丢弃，则帧2、1、3、6、5和7被丢弃。同样地，如果帧2被丢弃，则帧1和3区域也被丢弃。以此方式，某些媒体元素可以被视为是可选的。
具有数据的块传递的物理层的可用性可以实现比针对MPEG-2传输所实施的媒体传递映射更具体的媒体传递映射。这转而可以允许将传递映射到phy/MAC接收机接口处实际要求的时间。这种特殊性可以降低缓冲要求并且可以允许开始时间不取决于常规MPEG-2TS缓冲器模型。这转而可以引起频道改变时间的整体改善，并且可以简化缓冲器模型。本文所描述的增强可以允许在系统的网络侧实现该方案。
图21是示出了根据本公开内容的技术的另一个示例性系统的框图。图21的示例性系统类似于图3、15和17。即，图21的例子包括：发送机设备，其包括媒体编码器、分段器、发送机、MAC/phy调度器、以及激励器/放大器；以及接收机设备，其包括MAC/phy接收机、传输机、媒体播放器(例如，DASH媒体播放器)和编解码器(例如，解码器)。图21示出了关于针对这些各个组件的传输缓冲器模型的例子的更详细的细节。
本公开内容描述了用于对跨越多个接口的字节范围和对象进行描述的某些技术。实现方式的具体架构可以暴露或者可以不暴露所有接口。可以产生的益处包括允许MAC/phy以更有效的方式来进行调度的能力。此外，这些技术可以允许MAC/phy以以下方式来进行调度：将在不丢弃媒体的情况下进行播放，除非丢弃媒体是期望的能力。
以此方式，本公开内容的技术包括将接口配置为：视适用情况，提供描述针对对象或字节范围的所要求的传递时间(例如，最早和/或最迟时间)的信息。对象可以对应于区段(即，根据DASH的、独立地可获取的文件)，并且字节范围可以对应于区段的字节范围。描述针对对象或字节范围的期望传递时间的信息可以包括：对象/字节范围相对于传递中的其它媒体流和/或该MAC/phy资源上的其它服务的优先级。相对于其它媒体流的优先级可以描述例如视频数据相对于相同媒体内容的音频和/或定时文本流的优先级。所述信息还可以描述最迟传递时间。所述信息还可以描述最早传递时间，对于对该对象/字节范围和其它对象/字节范围进行编码的编码器，最早传递时间可以包括相对于所述其它字节范围的优先级。所述信息还可以描述字节范围或对象的受制于特定编码器的部分，其可以包括编码器的类型和/或编码器的地址。
本公开内容的技术还可以包括编码器和分段器/打包器、分段器和发送机(例如，实现ROUTE和/或FLUTE协议的发送机)、以及发送机(其实现ROUTE和/或FLUTE协议)和MAC/phy层设备间的接口。
图22是示出了用于获取媒体传递事件的示例性技术的流程图。即，图22示出了示例性数据和相关联的事件以实现流式传输媒体服务。可以由例如接收机设备(例如，图3的MAC/Phy接收机或ROUTE接收机)来执行图22的技术。在该例子中，存在两个事件序列。第一群组与物理层相关。调度器可以被配置为：确定包含例如服务列表(SLT)和时间需求的分组在引导程序和前导码之后的紧凑的邻近时间内出现。这可以通过将相关分组标识为“紧接在前导码之后的FEC帧中进行发送”来支持。引导程序和前导码的循环时间位置很可能与媒体T-RAP时间线对齐，以便使等待状态最小化。多个交错的媒体开始时间和T-RAP可能要求：需要多个引导程序和相关联的信令来使频道改变时间最小化。如果使用ROHC-U(单向模式的稳健报头压缩)报头压缩，则可能需要对上下文刷新进行同步，以便在功能上标识T-RAP。这应当可选地支持，如图22中所示出的。
此外，可以提供用于以信号形式通知存在T-RAP的数据。也就是说，第一单元(诸如在以上例子中示出的分段器或发送机)可以以信号形式通知区段或区段的字节范围包括T-RAP。该数据可以与区段本身分离，例如，与区段分离的元数据。因此，第二单元(诸如发送机或MAC/PHY单元)可以确定区段或区段的字节范围包括T-RAP而不必检查区段或区段的字节范围本身。或者，第二单元可以根据现有的语法元素来确定存在T-RAP。
如图22中所示出的，用于获取媒体传递事件的示例性技术(其可以由如上面针对例如图1、3、8、14、15、17和21所讨论的发送机设备来执行)可以包括引导程序检测、前导码接收、获取SLT和时间PLP和可选的ROHC-U、以及获取服务PLP，上述各项中的所有项可以使用时间上的群组传递来使等待状态最小化。PLP可以是BS/前导码之后的第一PLP。另外，所述技术可以包括MPD接收、IS接收、媒体区段接收以及媒体回放。可以使用经由T-RAP的群组传递来使等待状态最小化。
图23是示出了根据本公开内容的技术的、用于传输媒体数据的示例性方法的流程图。具体而言，该例子通常涉及一种方法，该方法包括：从服务器媒体数据的第一单元向服务器的第二单元发送媒体数据，连同针对媒体数据的描述性信息。描述性信息通常指示第二单元何时能够将媒体数据传递给客户端设备。第一单元可以对应于例如分段器(例如，图3、8、15、17和21的分段器)或发送机(例如，图3、8、15、17和21的发送机)。替代地，第一单元可以对应于发送机(例如，图3、8、15、17和21的发送机)，并且第二单元可以对应于MAC/phy单元(例如，图3、8、15和21的MAC/phy单元或者图17的物理层调度器)。
在图23的例子中，初始地，第一单元生成包括区段的比特流，其中区段具有随机访问点(RAP)以及紧接在RAP中的至少一个RAP之前的清单文件(150)。清单文件可以包括例如媒体呈现描述(MPD)。尽管在该例子中，第一单元生成比特流，但是应当理解的是，在其它例子中，第一单元可以例如从内容准备设备20(图1)简单地接收所生成的比特流。在一些例子中，第一单元可以接收比特流并且然后对比特流进行操作，例如，以便紧接在RAP中的至少一个RAP之前插入清单文件，例如，如图10中所示出的。
第一单元然后将针对比特流的媒体数据的描述性信息发送给服务器设备的第二单元。描述性信息指示媒体数据的区段中的一个区段或者区段中的至少一个区段的字节范围中的至少一项，以及能够传递区段或区段的字节范围的最早时间或者能够传递区段或区段的字节范围的最迟时间中的至少一项(152)。描述性信息可以符合上面的描述。例如，描述性信息可以包括以下各项中的任何或所有项：区段或字节范围的受制于特定媒体编码器的部分；目标时间，其中区段或字节范围应当在目标时间处或紧接在目标时间之后传递；能够传递区段或字节范围的最迟时间；针对区段或字节范围中的数据的呈现时间戳；包括区段的媒体流相对于其它媒体流关于针对媒体流的数据的目标传递时间的优先级；和/或针对区段或字节范围中的数据的解码时间戳。此外，描述性信息(相关的元数据)可以包括关于区段或区段的字节范围包括T-RAP的指示。或者，第一单元可以发送与描述性信息分离的、以信号形式通知存在T-RAP的数据。第一单元还向第二单元发送媒体数据(例如，比特流或者一个或多个区段、或者区段的部分)(154)。
第一单元还可以向第二单元发送语法元素，其中语法元素指示当从第二单元向客户端设备发送媒体数据时是否必须保留媒体数据的传递顺序(156)。语法元素可以是例如一比特的标志，其指示是否按传递顺序提供ROUTE会话的数据以及是否要保持/保留该传递顺序，如上面所讨论的。
第二单元然后可以向客户端设备发送区段或区段的字节范围(其中，客户端设备与服务器设备分离)，使得客户端设备在不早于特定时间接收到媒体数据(即，区段或区段的字节范围)，其中特定时间基于能够传递区段或字节范围的最早时间或者能够传递区段或字节范围的最迟时间，如由描述性信息指示的(158)。例如，第二单元可以确保在能够传递区段或字节范围的最早时间之后和/或最迟时间之前传递区段或区段的字节范围。因此，第二单元可以确保在其间客户端可以使用区段或字节范围的时间传递区段或字节范围。
在一个或多个例子中，可以在硬件、软件、固件或者其任意组合中实现所描述的功能。如果在软件中实现，则所述功能可以作为一个或多个指令或代码存储在计算机可读介质上或者通过计算机可读介质进行传输，并且可由基于硬件的处理单元来执行。计算机可读介质可以包括计算机可读存储介质或通信介质，其中计算机可读存储介质对应于有形介质，例如数据存储介质，通信介质包括促进计算机程序从一个地方传送到另一个地方(例如，根据通信协议)的任何介质。以此方式，计算机可读介质通常可以对应于(1)非暂时性的有形计算机可读存储介质或(2)通信介质，例如信号或载波。数据存储介质可以是可由一个或多个计算机或者一个或多个处理器存取以获取用于实现本公开内容中所描述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。
通过举例而非限制性的方式，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、闪存、或者可以用于以指令或数据结构的形式存储期望的程序代码并且可由计算机存取的任何其它介质。此外，任何连接可以适当地称为计算机可读介质。例如，如果使用同轴电缆、光纤光缆、双绞线、数字用户线(DSL)或诸如红外线、无线电和微波之类的无线技术从网站、服务器或其它远程源传输软件，则同轴电缆、光纤光缆、双绞线、DSL或诸如红外线、无线电和微波之类的无线技术包括在介质的定义中。但是，应当理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它暂时性介质，而是涉及非暂时性的有形存储介质。如本文所使用的，磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常磁性地复制数据，而光盘通常利用激光来光学地复制数据。上述的组合也应当包括在计算机可读介质的范围内。
指令可以由一个或多个处理器执行，例如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)、或者其它等效的集成或分立逻辑电路。因此，如本文所使用的，术语“处理器”可以指代前述结构中的任何结构或者适合于实现本文所描述的技术的任何其它结构。另外，在某些方面，可以在被配置用于进行编码和解码的专用硬件模块和/或软件模块内提供本文所描述的功能，或者将本文所描述的功能并入组合的编解码器中。此外，可以在一个或多个电路或逻辑元件中充分地实现所述技术。
可以在广泛多样的设备或装置(包括无线手持设备、集成电路(IC)或一组IC(例如，芯片组))中实现本公开内容的技术。本公开内容中描述各种组件、模块或单元是为了强调被配置为执行所公开的技术的设备的功能方面，但不一定要求由不同的硬件单元来实现。相反，如上面所描述的，各种单元可组合到编解码器硬件单元中，或者由互操作的硬件单元的集合(包括如上面所描述的一个或多个处理器)结合适当的软件和/或固件来提供。
已描述了各种例子。这些例子和其它例子在所附权利要求书的范围内。

Claims (38)

1.一种传输媒体数据的方法，所述方法包括，由服务器设备的第一单元进行以下操作：
向所述服务器设备的第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或者所述区段的字节范围中的至少一项，以及能够传递所述区段或所述区段的所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间中的至少一项；以及
向所述第二单元发送所述媒体数据。
2.根据权利要求1所述的方法，还包括向所述第二单元发送语法元素，其中所述语法元素指示当从所述第二单元向客户端设备发送所述媒体数据时是否必须保留所述媒体数据的传递顺序。
3.根据权利要求1所述的方法，其中，所述描述性信息还指示所述区段或所述字节范围的受制于特定媒体编码器的部分。
4.根据权利要求1所述的方法，其中，所述描述性信息还指示目标时间，其中所述区段或所述字节范围应当在所述目标时间处或者紧接在所述目标时间之后传递。
5.根据权利要求1所述的方法，其中，所述描述性信息还指示包括所述区段的媒体流相对于其它媒体流关于针对所述媒体流的数据的目标传递时间的优先级。
6.根据权利要求5所述的方法，其中，所述媒体流包括视频流，并且其中，所述其它媒体流包括与所述视频流相关的音频流。
7.根据权利要求5所述的方法，其中，所述媒体流包括音频流，并且其中，所述其它媒体流包括与所述音频流相关的视频流。
8.根据权利要求5所述的方法，其中，所述媒体流包括：包括所述其它媒体流的多个流中的一个流，其中，所述多个流中的每个流与相同的媒体内容相关，并且其中，所述多个流包括一个或多个视频流以及一个或多个音频流。
9.根据权利要求8所述的方法，其中，所述多个流还包括一个或多个定时文本流。
10.根据权利要求1所述的方法，其中，所述描述性信息还指示以下各项中的至少一项：能够传递所述区段或所述字节范围的最迟时间，针对所述区段或所述字节范围内的数据的呈现时间戳，或者针对所述区段或所述字节范围内的数据的解码时间戳。
11.根据权利要求1所述的方法，其中，所述第一单元包括分段器，并且其中，所述第二单元包括发送机。
12.根据权利要求1所述的方法，其中，所述第一单元包括发送机，并且其中，所述第二单元包括MAC/phy单元。
13.根据权利要求1所述的方法，还包括：由所述第二单元向与所述服务器设备分离的客户端设备发送所述区段或所述区段的所述字节范围，使得所述客户端设备不早于特定时间接收所述媒体数据，其中所述特定时间基于由所述描述性信息指示的所述最早时间或所述最迟时间。
14.根据权利要求13所述的方法，还包括：确定所述服务器设备和所述客户端设备之间的延迟，其中，发送包括：基于所述最早时间或所述最迟时间以及所确定的延迟来发送所述区段或所述字节范围。
15.根据权利要求1所述的方法，还包括：生成比特流以包括描述所述媒体数据的清单文件，使得所述清单文件紧接在所述媒体数据的随机访问点(RAP)之前。
16.根据权利要求15所述的方法，其中，生成所述比特流包括：生成所述比特流以包括紧接在所述清单文件之前的稳健报头压缩(ROHC)上下文初始化数据。
17.根据权利要求16所述的方法，其中，所述ROHC上下文初始化数据是针对用于传输所述比特流的单向传输的实时对象传递(ROUTE)会话的。
18.根据权利要求17所述的方法，还包括：针对包括在所述ROUTE会话中的一个或多个分层编码传输(LCT)会话来生成所述ROHC上下文初始化数据。
19.根据权利要求16所述的方法，其中，所述ROHC上下文初始化数据是针对用于传输所述比特流的一个或多个分层编码传输(LCT)会话的。
20.根据权利要求16所述的方法，还包括：当使用ROHC-U(处于单向模式的ROHC)压缩时，对上下文刷新进行同步。
21.根据权利要求15所述的方法，其中，所述清单文件包括根据HTTP的动态自适应流式传输(DASH)的媒体呈现描述(MPD)。
22.根据权利要求1所述的方法，还包括：利用根据一个或多个网络协议的数据来对所述区段或所述字节范围进行封装，其中，指示所述最早时间或最迟时间的所述描述性信息也适用于所述根据所述一个或多个网络协议的数据。
23.一种用于发送媒体数据的服务器设备，所述设备包括：
第一单元，以及
第二单元，
其中，所述第一单元包括一个或多个处理单元，其被配置为：
向所述服务器设备的所述第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或所述区段的字节范围，以及能够传递所述区段或所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间；以及
向所述第二单元发送所述媒体数据。
24.根据权利要求23所述的设备，其中，所述第一单元包括分段器，并且其中，所述第二单元包括发送机。
25.根据权利要求23所述的设备，其中，所述第一单元包括发送机，并且其中，所述第二单元包括MAC/phy单元。
26.根据权利要求23所述的设备，其中，所述描述性信息还指示以下各项中的至少一项：所述区段或所述字节范围的受制于特定媒体编码器的部分；目标时间，其中所述区段或所述字节范围应当在所述目标时间处或紧接在所述目标时间之后传递；能够传递所述区段或所述字节范围的最迟时间；针对所述区段或所述字节范围内的数据的呈现时间戳；或者针对所述区段或所述字节范围内的数据的解码时间戳。
27.根据权利要求23所述的设备，其中，所述描述性信息还指示包括所述区段的媒体流相对于其它媒体流关于针对所述媒体流的数据的目标传递时间的优先级。
28.根据权利要求23所述的设备，其中，所述第一单元的所述一个或多个处理器还被配置为：生成比特流以包括描述所述媒体数据的清单文件，使得所述清单文件紧接在所述媒体数据的随机访问点(RAP)之前，并且稳健报头压缩(ROHC)上下文初始化数据紧接在所述清单文件之前。
29.一种用于发送媒体数据的服务器设备，所述设备包括：
第一单元，以及
第二单元，
其中，所述第一单元包括：
用于向所述服务器设备的所述第二单元发送针对媒体数据的描述性信息的单元，其中，所述描述性信息指示所述媒体数据的区段或所述区段的字节范围，以及能够传递所述区段或所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间；以及
用于向所述第二单元发送所述媒体数据的单元。
30.根据权利要求29所述的设备，其中，所述描述性信息还指示以下各项中的至少一项：所述区段或所述字节范围的受制于特定媒体编码器的部分；目标时间，其中所述区段或所述字节范围应当在所述目标时间处或者紧接在所述目标时间之后传递；能够传递所述区段或所述字节范围的最迟时间；针对所述区段或所述字节范围中的数据的呈现时间戳；或者针对所述区段或所述字节范围中的数据的解码时间戳。
31.根据权利要求29所述的设备，其中，所述描述性信息还指示包括所述区段的媒体流相对于其它媒体流关于针对所述媒体流的数据的目标传递时间的优先级。
32.根据权利要求29所述的设备，其中，所述第一单元还包括：
用于生成比特流以包括描述所述媒体数据的清单文件，使得所述清单文件紧接在所述媒体数据的随机访问点(RAP)之前的单元；以及
用于生成紧接在所述清单文件之前的稳健报头压缩(ROHC)上下文初始化数据的单元。
33.一种具有存储在其上的指令的计算机可读存储介质，其中当所述指令被执行时，使得服务器设备的第一单元的处理器执行以下操作：
向所述服务器设备的第二单元发送针对媒体数据的描述性信息，其中，所述描述性信息指示所述媒体数据的区段或者所述区段的字节范围中的至少一项，以及能够传递所述区段或所述区段的所述字节范围的最早时间或者能够传递所述区段或所述区段的所述字节范围的最迟时间中的至少一项；以及
向所述第二单元发送所述媒体数据。
34.根据权利要求33的计算机可读存储介质，其中，所述描述性信息还指示以下各项中的至少一项：所述区段或所述字节范围的受制于特定媒体编码器的部分；目标时间，其中所述区段或所述字节范围应当在所述目标时间处或者紧接在所述目标时间之后传递；能够传递所述区段或所述字节范围的最迟时间；针对所述区段或所述字节范围内的数据的呈现时间戳；或者针对所述区段或所述字节范围内的数据的解码时间戳。
35.根据权利要求33的计算机可读存储介质，其中，所述描述性信息还指示包括所述区段的媒体流相对于其它媒体流关于针对所述媒体流的数据的目标传递时间的优先级。
36.根据权利要求33的计算机可读存储介质，还包括使得所述处理器执行以下操作的指令：
生成比特流以包括描述所述媒体数据的清单文件，使得所述清单文件紧接在所述媒体数据的随机访问点(RAP)之前；以及
生成紧接在所述清单文件之前的稳健报头压缩(ROHC)上下文初始化数据。
37.根据权利要求1所述的方法，还包括用于指示所述区段或者所述区段的字节范围包括传输随机访问点(T-RAP)的信令数据。
38.根据权利要求1所述的方法，还包括：根据现有的语法数据，来确定所述区段或者所述区段的所述字节范围包括传输随机访问点(T-RAP)。
CN201580064999.9A 2014-12-05 2015-12-04 用于多媒体和文件传输的传输接口 Pending CN107005729A (zh)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201462088351P 2014-12-05 2014-12-05
US62/088,351 2014-12-05
US201562102930P 2015-01-13 2015-01-13
US62/102,930 2015-01-13
US201562209620P 2015-08-25 2015-08-25
US62/209,620 2015-08-25
US14/958,086 US20160164943A1 (en) 2014-12-05 2015-12-03 Transport interface for multimedia and file transport
US14/958,086 2015-12-03
PCT/US2015/064055 WO2016090280A1 (en) 2014-12-05 2015-12-04 Transport interface for multimedia and file transport

Publications (1)

Publication Number Publication Date
CN107005729A true CN107005729A (zh) 2017-08-01

Family

ID=55229794

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201580064999.9A Pending CN107005729A (zh) 2014-12-05 2015-12-04 用于多媒体和文件传输的传输接口

Country Status (5)

Country Link
US (1) US20160164943A1 (zh)
KR (1) KR20170089863A (zh)
CN (1) CN107005729A (zh)
TW (1) TWI668982B (zh)
WO (1) WO2016090280A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110545492A (zh) * 2018-09-05 2019-12-06 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN114430909A (zh) * 2019-10-01 2022-05-03 高通股份有限公司 用于自适应比特率组播的修复机制

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3232668A4 (en) * 2014-12-10 2018-06-13 LG Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method
WO2016105100A1 (ko) * 2014-12-22 2016-06-30 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10142233B2 (en) * 2015-01-21 2018-11-27 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US10721505B2 (en) * 2015-01-21 2020-07-21 Lg Electronic Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
WO2016126116A1 (ko) 2015-02-04 2016-08-11 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US9872063B2 (en) * 2015-03-01 2018-01-16 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method of transmitting broadcast signals and method of receiving broadcast signals
WO2016153241A1 (ko) 2015-03-23 2016-09-29 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10469919B2 (en) * 2015-04-07 2019-11-05 Lg Electronics Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
US10594417B2 (en) 2016-01-14 2020-03-17 Lg Electronics Inc. Apparatus and method for transmitting and receiving broadcast signal
MX2018009625A (es) * 2016-02-15 2018-09-11 Sony Corp Aparato de recepcion, aparato de transmision y metodo de procesamiento de datos.
US10432690B1 (en) * 2016-06-03 2019-10-01 Amazon Technologies, Inc. Manifest partitioning
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
KR102391799B1 (ko) * 2017-10-19 2022-04-29 삼성전자주식회사 유니캐스트　기반 멀티미디어 서비스 방법 및 장치
GB2569276B (en) 2017-10-20 2020-10-14 Graphcore Ltd Compiler method
GB201717295D0 (en) 2017-10-20 2017-12-06 Graphcore Ltd Synchronization in a multi-tile processing array
GB2569275B (en) 2017-10-20 2020-06-03 Graphcore Ltd Time deterministic exchange
US10963003B2 (en) 2017-10-20 2021-03-30 Graphcore Limited Synchronization in a multi-tile processing array
GB201721847D0 (en) 2017-12-22 2018-02-07 Telecom Paris Tech Priority map for media files
CN115552914A (zh) 2020-01-02 2022-12-30 密执安州立大学董事会 用于增强的多媒体信号广播、接收、数据递送和数据收集的系统和方法
US11638044B1 (en) * 2022-03-01 2023-04-25 Amazon Technologies, Inc. Preparation of warm inputs for digital content streaming

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370175A (zh) * 2007-08-15 2009-02-18 华为技术有限公司 确定数据发送时间的方法、组播分组方法、装置和系统
US20120042090A1 (en) * 2010-08-10 2012-02-16 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
CN102484741A (zh) * 2009-08-21 2012-05-30 香港中文大学 用于规划媒体数据的传输时间的装置和方法
US20130170451A1 (en) * 2011-12-30 2013-07-04 UV Networks, Inc. High capacity network communication link using multiple cellular devices
US20130271655A1 (en) * 2012-04-12 2013-10-17 Google Inc. System, apparatus and method to facilitate live video streaming
US20140040498A1 (en) * 2012-08-03 2014-02-06 Ozgur Oyman Methods for quality-aware adaptive streaming over hypertext transfer protocol

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6988144B1 (en) * 1999-11-18 2006-01-17 International Business Machines Corporation Packet scheduling system and method for multimedia data
EP1170919A1 (en) * 2000-07-04 2002-01-09 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Method and device for improving the transmission efficiency in a communication system with a layered protocol stack
US7489706B2 (en) * 2004-06-28 2009-02-10 Spirent Communications, Inc. Method and apparatus for placing a timestamp in a frame
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
JP5312456B2 (ja) * 2007-07-05 2013-10-09 コーヒレント・ロジックス・インコーポレーテッド 移動体テレビジョン放送システム
CN101971578B (zh) * 2007-12-28 2014-07-30 茨特里克斯系统公司 Tcp分组间距
US9185445B2 (en) * 2009-09-24 2015-11-10 At&T Intellectual Property I, L.P. Transmitting a prioritized audio stream along with multimedia content
EP2784996A1 (en) * 2013-03-27 2014-10-01 British Telecommunications public limited company Deadline driven content delivery

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101370175A (zh) * 2007-08-15 2009-02-18 华为技术有限公司 确定数据发送时间的方法、组播分组方法、装置和系统
CN102484741A (zh) * 2009-08-21 2012-05-30 香港中文大学 用于规划媒体数据的传输时间的装置和方法
US20120042090A1 (en) * 2010-08-10 2012-02-16 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US20130170451A1 (en) * 2011-12-30 2013-07-04 UV Networks, Inc. High capacity network communication link using multiple cellular devices
US20130271655A1 (en) * 2012-04-12 2013-10-17 Google Inc. System, apparatus and method to facilitate live video streaming
US20140040498A1 (en) * 2012-08-03 2014-02-06 Ozgur Oyman Methods for quality-aware adaptive streaming over hypertext transfer protocol

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110545492A (zh) * 2018-09-05 2019-12-06 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN114430909A (zh) * 2019-10-01 2022-05-03 高通股份有限公司 用于自适应比特率组播的修复机制

Also Published As

Publication number Publication date
WO2016090280A1 (en) 2016-06-09
KR20170089863A (ko) 2017-08-04
US20160164943A1 (en) 2016-06-09
TWI668982B (zh) 2019-08-11
TW201633759A (zh) 2016-09-16

Similar Documents

Publication Publication Date Title
CN107005729A (zh) 用于多媒体和文件传输的传输接口
JP6342457B2 (ja) コード化ビデオデータのネットワークストリーミング
CN107409234B (zh) 基于lct利用dash格式的基于文件格式的流式传输
US11405699B2 (en) Using GLTF2 extensions to support video and audio data
JP5964972B2 (ja) 複数のソースからのマルチメディアデータのストリーミング
CN104885473B (zh) 用于经由http的动态自适应流式传输(dash)的实况定时方法
CN108141455B (zh) 用于媒体数据的流式发射的期限信令
CN105900445B (zh) 用于动态自适应流式传输的稳健实况操作的方法和装置
US11381867B2 (en) Multiple decoder interface for streamed media data
JP2017175623A (ja) ビデオデータをストリーミングするためのシーケンスデータセットを提供すること
KR102659380B1 (ko) 파일 포맷 박스들에 대한 제네릭 디스크립터를 사용한 미디어 데이터의 프로세싱
JP2018510545A (ja) 低レイテンシビデオストリーミング
US11388427B2 (en) Multiple decoder interface for streamed media data
CN117397227A (zh) 实时增强现实通信会话
CN114503599B (zh) 使用gltf2场景描述中的扩展来支持视频和音频数据

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: 20170801

WD01 Invention patent application deemed withdrawn after publication