具体实施方式

通常，本公开描述了用于发送描述媒体呈现的数据的技术。服务器设备可以指示用于呈现应当提供优先用户体验的呈现设置的媒体呈现的服务描述数据。客户端设备可以使用服务描述数据来修改媒体数据的回放。例如，对于一些呈现(例如，诸如体育事件的实时事件)，用户在呈现的事件发生时立即体验可能更好，使得如果经历了重新缓冲，则会丢弃一些先前接收到的媒体数据。对于其它呈现(例如电影或电视节目)，用户体验整个呈现可能更好，使得如果经历了重新缓冲，则呈现先前接收的媒体数据。

通常，本公开的技术可以用于网络流式传输，例如HTTP流式传输(例如，HTTP上的动态自适应流式传输(Dynamic Adaptive Streaming over HTTP，DASH))。在HTTP流中，常用的操作包括HEAD、GET和部分GET。HEAD操作检索与给定的统一资源定位符(URL)或统一资源名称(URN)相关联的文件的标头，而无需检索与URL或URN相关联的有效载荷。GET操作检索与给定URL或URN相关联的整个文件。部分GET操作接收字节范围作为输入参数，并检索文件的连续数量的字节，其中字节数量对应于接收到的字节范围。因此，可以针对HTTP流式传输提供电影片段(movie fragment)，因为部分GET操作可以获取一个或多个单独的电影片段。在电影片段中，可以有几个不同轨道的轨道片段(track fragment)。在HTTP流式传输中，媒体呈现可以是客户端可访问的结构化数据集合。客户端可以请求并下载媒体数据信息以向用户呈现流式传输服务。

在使用HTTP流式传输的3GPP数据流式传输的示例中，可以存在多媒体内容的视频和/或音频数据的多个呈现。如下所述，不同的呈现可以对应于不同的编码特性(例如，视频编码标准的不同配置文件或级别)、不同的编码标准或编码标准的扩展(例如，多视图和/或可缩放扩展)或不同的比特率。可以在媒体呈现描述(Media Presentation Description，MPD)数据结构中定义这种呈现的清单。媒体呈现可以对应于HTTP流式传输客户端设备可访问的结构化数据集合。HTTP流式传输客户端设备可以请求并下载媒体数据信息以向客户端设备的用户呈现流式传输服务。可以在MPD数据结构中描述媒体呈现，该媒体呈现可以包括MPD的更新。

媒体呈现可以包含一个或多个时间段的序列。每个时间段可以延长到下一个时间段的开始，或者对于最后一个时间段，直到媒体呈现的结束为止。每个时间段可以包含相同媒体内容的一个或多个呈现。呈现可以是音频、视频、定时文本或其它这种数据的许多替代编码版本之一。这些呈现可以通过编码类型(例如，针对视频数据的比特率、分辨率和/或编解码器以及针对音频数据的比特率、语言和/或编解码器)而不同。术语呈现可用于指代与多媒体内容的特定时间段相对应并以特定方式编码的编码的音频或视频数据的一部分。

可以将特定时间段的呈现分配给由MPD中的、指示呈现所属的适配集合(adaptation set)的属性所指示的组。通常认为同一适配集合中的呈现是彼此的替代，因为客户端设备可以在这些呈现之间动态且无缝地切换，例如以执行带宽自适应。例如，可以将特定时间段的视频数据的每个呈现分配给同一适配集合，从而可以选择任何呈现进行解码以呈现对应时间段的多媒体内容的媒体数据，例如视频数据或音频数据。在一些示例中，一个时间段内的媒体内容可以通过来自0组的一个呈现(如果存在)或来自每个非零组的至多一个呈现的组合来呈现。时间段的每种呈现的时序数据可以相对于时间段的开始时间来表示。

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

可以选择不同的呈现以用于基本上同时检索不同类型的媒体数据。例如，客户端设备可以选择音频呈现、视频呈现和定时文本呈现，以从中检索分段。在一些示例中，客户端设备可以选择特定的适配集合以执行带宽适配。即，客户端设备可以选择包括视频呈现的适配集合、包括音频呈现的适配集合和/或包括定时文本的适配集合。可替代地，客户端设备可以选择用于某些类型的媒体(例如，视频)的适配集合，并且直接选择用于其它类型的媒体(例如，音频和/或定时文本)的呈现。

DASH-IF(Dash行业论坛)和数字视频广播(DVB)目前正在针对低时延流式传输开发基于DASH的解决方案。这项工作中的关键问题是可以提供使得端到端时延受限并与其它电视分发手段相当的服务的能力。可以考虑不同的时延。例如，端到端时延(End-to-EndLatency，EEL)描述了相机捕获的动作直到该动作在远程屏幕上可见的时延。作为另一示例，编码+分发时延(Encoding+Distribution Latency，EDL)描述了线性播放输出(通常用作(多个)分发编码器的输入)到屏幕的时延。

除了端到端时延之外，启动延迟(有时称为信道更改时间)也可能相关。在这种情况下，可以区分两个不同的延迟。实时边缘启动延迟(Live Edge Start-up Delay，LSD)描述了用户操作(服务接入或服务加入)和直到用户在实时边缘加入时感知到服务的第一个媒体样本的时间之间的时间。搜寻启动延迟(Seek Start-up Delay，SSD)描述了用户操作(服务接入或服务加入)和直到搜寻时移缓冲器时用户感知到服务的第一个媒体样本的时间之间的时间。

此外，另一方面是能够跨不同设备准确地同步呈现以实现一致的用户体验的能力。

例如，DVB旨在能够(但不要求)实现以下目标的技术：

·编码器到屏幕的时延为3.5秒。

·实时边缘启动延迟大约为1秒或更短。

·在500毫秒容差范围内，以特定的挂钟时间呈现媒体时间。

DVB的另一目标是，可以提供一种服务产品，使其与现有客户端向后兼容，从而可以观察到更长的时延。

DVB的另一要求是改变服务以不必一定以要求的最低时延运行，使得如果这有利于网络资源和编码效率，则可以将服务设置为以更长的时延运行。该决定可以由设备根据其环境来决定，或者可以由服务提供商来决定，或者由两者决定。

图1是示出了实现用于在网络上流式传输媒体数据的技术的示例系统10的框图。在该示例中，系统10包括内容准备设备20，服务器设备60和客户端设备40。客户端设备40和服务器设备60通过网络74通信耦合，网络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产生编码的视频数据流。每个单独的数据流(无论是音频还是视频)可以称为基本流。基本流是呈现的单个的、数字编码的(可能是压缩的)分量。例如，呈现的编码视频或音频部分可以是基本流。在被封装在视频文件内之前，可以将基本流转换成封包化的基本流(packetized elementarystream，PES)。在同一呈现内，流ID可用于区分属于一个基本流的PES封包与另一个基本流的PES封包。基本流的基本数据单元是封包化的基本流(PES)封包。因此，编码的视频数据通常对应于基本视频流。类似地，音频数据对应于一个或多个相应的基本流。

许多视频编码标准(例如ITU-T H.264/AVC和即将推出的高效视频编码(HEVC)标准)针对无错误的比特流定义了语法、语义和解码过程，其中任何一个都符合特定的配置文件或级别。视频编码标准通常不指定编码器，但是编码器的任务是确保生成的比特流符合解码器的标准。在视频编码标准的上下文中，“配置文件”对应于应用于它们的算法、特征或工具和约束的子集。例如，如由H.264标准所定义，“配置文件”是由H.264标准所指定的整个比特流语法的子集。“级别”对应于解码器资源消耗的限制(例如解码器存储器和计算)，这与图片的分辨率、比特率和块处理速率有关。可以用profile_idc(配置文件指示符)值来信令通知配置文件，同时可以用level_idc(级别指示符)值信令通知级别。

例如，H.264标准认识到，在由给定配置文件的语法所施加的范围内，取决于比特流中的语法元素图片所采用的值(例如解码的图像的指定尺寸)，仍然可能要求编码器和解码器的性能的大的变化。H.264标准进一步认识到，在许多应用中，实现能够处理特定配置文件中语法的所有假设用途的解码器既不切实际，也不经济。因此，H.264标准将“级别”定义为施加在比特流中语法元素的值上的指定约束集合。这些约束可能是对值的简单限制。可替代地，这些约束可以采取对值的算术组合的约束的形式(例如，图片宽度乘以图片高度乘以每秒解码的图片数量)。H.264标准进一步规定，各个实现可以针对每个受支持的配置文件支持不同的级别。

符合配置文件的解码器通常支持配置文件中定义的所有特征。例如，作为编码特征，H.264/AVC的基线配置文件中不支持B图片编码，而H.264/AVC的其它配置文件中支持B图片编码。符合某个级别的解码器应该能够对任何不需要超出该级别中定义的限制的资源的比特流进行解码。配置文件和级别的定义可能有助于解释。例如，在视频发送期间，可以针对整个发送会话协商并同意一对配置文件和级别定义。更具体地说，在H.264/AVC中，级别可以定义对需要处理的宏块的数量、解码图片缓冲器(DPB)大小、编码图片缓冲器(CPB)大小、垂直运动矢量范围、每两个连续MB的运动矢量的最大数量，以及B块是否可以具有小于8x8像素的子宏块分割的限制。以这种方式，解码器可以确定解码器是否能够正确地对比特流进行解码。

在图1的示例中，内容准备设备20的封装单元30从视频编码器28接收包括编码的视频数据的基本流，并且从音频编码器26接收包括编码的音频数据的基本流。在一些示例中，视频编码器28和音频编码器26可各自包括用于从编码的数据形成PES封包的封包器。在其它示例中，视频编码器28和音频编码器26可各自与相应的用于从编码的数据形成PES封包的封包器接口。在其它示例中，封装单元30可以包括用于从编码的音频和视频数据形成PES封包的封包器。

视频编码器28可以以各种方式对多媒体内容的视频数据进行编码，以以各种比特率并且以各种特性(例如，像素分辨率、帧速率，符合各种编码标准，符合各种配置文件和/或各种编码标准的配置文件的级别，具有一个或多个视图的呈现(例如，用于二维或三维回放)或其它此类特征)来产生多媒体内容的不同呈现。如本公开中所使用的呈现可以包括音频数据、视频数据、文本数据(例如，用于闭路字幕)或其它此类数据中的一种。呈现可以包括基本流，诸如音频基本流或视频基本流。每个PES封包可以包括识别该PES封包所属的基本流的stream_id。封装单元30负责将基本流组装成各种呈现的视频文件(例如，分段)。

封装单元30从音频编码器26和视频编码器28接收用于呈现的基本流的PES封包，并且从PES封包形成对应的网络抽象层(NAL)单元。可以将编码的视频分段组织成NAL单元，这些NAL单元提供“网络友好”的视频呈现，用于处理诸如视频电话、存储、广播或流式传输的应用。NAL单元可以分类为视频编码层(Video Coding Layer，VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎，并且可以包括块、宏块和/或条带级数据。其它NAL单元可以是非VCL NAL单元。在一些示例中，通常作为主编码的图片呈现的一个时间实例中的编码的图片可以被包含在接入单元中，该接入单元可以包括一个或多个NAL单元。

非VCL NAL单元可以包括参数集合NAL单元和SEI NAL单元等。参数集合可以包含序列级报头信息(在序列参数集合(SPS)中)和不经常改变的图片级报头信息(在图片参数集合(PPS)中)。使用参数集合(例如PPS和SPS)，不需要对每个序列或图片重复不经常改变的信息。因此，可以提高编码效率。此外，参数集合的使用可以实现重要报头信息的带外发送，从而避免了对用于错误恢复的冗余发送的需要。在带外发送示例中，可以在与其它NAL单元(例如SEI NAL单元)不同的信道上发送参数集合NAL单元。

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

封装单元30可以将用于多媒体内容的一个或多个呈现的数据以及清单文件(例如，MPD)提供给输出接口32。输出接口32可以包括网络接口或用于写入存储介质的接口，例如通用串行总线(USB)接口、CD或DVD写入器或刻录机，到磁性或闪存存储介质的接口或其它用于存储或发送媒体数据的其它接口。封装单元30可以将多媒体内容的每个呈现的数据提供给输出接口32，输出接口32可以经由网络传输或存储介质将数据发送到服务器设备60。在图1的示例中，服务器设备60包括存储各种多媒体内容64的存储介质62，每个多媒体内容64包括各自的清单文件66和一个或多个呈现68A-68N(呈现68)。在一些示例中，输出接口32还可将数据直接发送到网络74。

在一些示例中，呈现68可以被分成适配集合。也就是说，呈现68的各个子集可以包括相应的共同特征集合，例如编解码器、配置文件和级别、分辨率、视图数、分段的文件格式、可以识别语言的文本类型信息或要与呈现一起显示的文本的其他特性和/或要解码和呈现的音频数据(例如，通过扬声器)、可以描述相机角度的相机角度信息或适配集合中的用于呈现的场景的真实世界相机视角、描述对于特定观众的内容适合性的评级信息等。

清单文件66可以包括指示与特定适配集合相对应的呈现68的子集以及适配集合的共同特征的数据。清单文件66还可以包括表示用于适配集合的各个呈现的各个特征(例如比特率)的数据。以这种方式，适配集合可以提供简化的网络带宽适配。可以使用清单文件66的适配集合元素的子元素来指示适配集合中的呈现。

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

请求处理单元70被配置为从诸如客户端设备40的客户端设备接收对存储介质62的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(HTTP)版本1.1，如在以下文档中描述的：RFC 2616,R.Fielding等人的“超文本传输协议-HTTP/1.1”，网络工作组,IETF，1999年6月。也就是说，请求处理单元70可以被配置为接收HTTP GET或部分GET请求，并且响应于请求而提供多媒体内容64的数据。请求可以例如使用分段的URL来指定呈现68中的一个的分段。在一些示例中，请求还可以指定分段的一个或多个字节范围，从而包括部分GET请求。请求处理单元70可以进一步被配置为服务HTTP HEAD请求，以提供呈现68中的一个的分段的报头数据。在任何情况下，请求处理单元70可以被配置为处理请求，以将请求的数据提供给诸如客户端设备40的请求设备。

附加地或替代地，请求处理单元70可以被配置为经由诸如eMBMS的广播或多播协议来传送媒体数据。内容准备设备20可以以与所描述的基本相同的方式来创建DASH分段和/或子分段，但是服务器设备60可以使用eMBMS或另一广播或多播网络传输协议来传送这些分段或子分段。例如，请求处理单元70可以被配置为从客户端设备40接收多播组加入请求。也就是说，服务器设备60可以向与特定媒体内容(例如，实时事件的广播)相关联的客户端设备(包括客户端设备40)通告与多播组相关联的互联网协议(IP)地址。客户端设备40又可以转而提交加入多播组的请求。该请求可以在整个网络74(例如，构成网络74的路由器)中传播，使得路由器将去往与多播组相关联的IP地址的流量定向到订阅客户端设备(例如客户端设备40)。

如图1的示例中所示，多媒体内容64包括清单文件66，清单文件66可以对应于媒体呈现描述(MPD)。清单文件66可以包含对不同替代呈现68(例如具有不同质量的视频服务)的描述，并且该描述可以包括例如呈现68的编解码器信息、配置文件值、级别值、比特率和其它描述性特征。客户端设备40可以检索媒体呈现的MPD以确定如何接入呈现68的分段。

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

检索单元52可以将客户端设备40的解码和渲染能力与由清单文件66的信息指示的呈现68的特征进行比较。检索单元52可以最初检索清单文件66的至少一部分以确定呈现68的特征。例如，检索单元52可以请求描述一个或多个适配集合的特征的清单文件66的一部分。检索单元52可以选择呈现68的子集(例如，适配集合)，该子集具有可以由客户端设备40的编码和渲染能力满足的特征。检索单元52然后可以确定适配集合中的呈现的比特率，确定网络带宽的当前可用量，并且从具有可以由网络带宽满足的比特率的呈现中的一个中检索分段。

通常，较高的比特率的呈现可以产生较高质量的视频回放，而较低的比特率的呈现可以在可用网络带宽减小时提供足够质量的视频回放。因此，当可用网络带宽相对较高时，检索单元52可以从相对较高的比特率的呈现中检索数据，而当可用网络带宽较低时，检索单元52可以从相对较低的比特率的呈现中检索数据。以这种方式，客户端设备40可以在网络74上流式传输多媒体数据，同时还适应于网络74的变化的网络带宽可用性。

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

网络接口54可以接收所选呈现的分段的数据并将其提供给检索单元52，检索单元52转而又可以将该分段提供给解封装单元50。解封装单元50可以将视频文件的元素解封装成组成的PES流(constituent PES stream)，对PES流进行解封包以检索编码的数据，并取决于编码的数据是音频流还是视频流的一部分(例如，如流的PES封包报头所示)将编码的数据发送到音频解码器46或视频解码器48。音频解码器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描述了这些技术。然而，应当理解，内容准备设备20可以被配置为执行这些技术，而不是(或者除了)服务器设备60。

封装单元30可以形成NAL单元，该NAL单元包括标识该NAL单元所属的程序的报头以及有效载荷，例如音频数据、视频数据或描述该NAL单元所对应的发送或程序流的数据。例如，在H.264/AVC中，NAL单元包括1字节的报头和大小可变的有效载荷。在其有效载荷中包括视频数据的NAL单元可以包括各种粒度级别的视频数据。例如，NAL单元可以包括视频数据块、多个块、视频数据条带或视频数据的整个图片。封装单元30可以以基本流的PES封包的形式从视频编码器28接收编码的视频数据。封装单元30可以将每个基本流与对应的程序相关联。

封装单元30还可从多个NAL单元组装接入单元。通常，接入单元可以包括一个或多个用于呈现视频数据的帧的NAL单元，以及与该帧相对应的音频数据(当这种音频数据可用时)。接入单元通常包括用于一个输出时间实例的所有NAL单元，例如，用于一个时间实例的所有音频和视频数据。例如，如果每个视图的帧速率均为每秒20帧(fps)，则每个时间实例可以对应于0.05秒的时间间隔。在此时间间隔期间，可以同时渲染同一接入单元(同一时间实例)的所有视图的特定帧。在一个示例中，接入单元可以在一个时间实例中包括编码的图片，其可以被呈现为主编码图片。

因此，接入单元可以包括公共时间实例的所有音频和视频帧，例如，对应于时间X的所有视图。本公开还将特定视图的编码的图片称为“视图分量”。即，视图分量可以包括在特定时间用于特定视图的编码的图片(或帧)。因此，接入单元可以被定义为包括公共时间实例的所有视图分量。接入单元的解码顺序不必与输出或显示顺序相同。

媒体呈现可以包括媒体呈现描述(MPD)，媒体呈现描述可以包含对不同替代呈现(例如，具有不同质量的视频服务)的描述，并且该描述可以包括例如编解码器信息、配置文件值和级别值。MPD是清单文件(例如清单文件66)的一个示例。客户端设备40可以检索媒体呈现的MPD，以确定如何接入各种呈现的电影片段。电影片段可以位于视频文件的电影片段盒(moof box)中。

清单文件66(其可以包括例如MPD)可以通告呈现68的分段的可用性。即，MPD可以包括指示呈现68中的一个的第一分段变为可用的挂钟时间的信息，以及指示呈现68内的分段的持续时间的信息。以这种方式，客户端设备40的检索单元52可以基于开始时间以及特定分段之前的分段的持续时间来确定每个分段何时可用。

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

网络接口54可以经由网络74接收NAL单元或接入单元，并经由检索单元52将NAL单元或接入单元提供给解封装单元50。解封装单元50可以将视频文件的元素解封装成组成的PES流，对PES流进行解封包以检索编码的数据，并取决于编码的数据是音频流还是视频流的一部分(例如，如流的PES封包报头所示)将编码的数据发送到音频解码器46或视频解码器48。音频解码器46对编码的音频数据进行解码并将解码的音频数据发送到音频输出42，而视频解码器48对编码的视频数据进行解码并将解码的视频数据(可以包括流的多个视图)发送到视频输出44。

根据本公开的技术，如以下更详细地讨论的，媒体呈现可以具有用于更高质量的用户体验的相关联的回放推荐。例如，对于实时事件，可能希望尽快观看该事件，例如体育赛事或新闻事件。对于实时事件，通常希望使事件发生与呈现事件的媒体数据的发送、接收和回放之间的时延最小化。内容准备设备20(例如，封装单元30)可以准备服务描述，该服务描述指定一个或多个目标时延(例如，期望的端到端时延)和用于实现该时延的技术。例如，内容准备设备20可以在服务描述中指示回放加速或减速速率，客户端设备40可以使用该速率来调整回放速率以维持期望的端到端时延，而不会对用户体验的回放产生负面影响。

因此，客户端设备40(例如，检索单元52)可以根据服务描述来调整回放，以实现期望的端到端时延。例如，如果检索单元52的存储器的缓冲相对于回放缓慢地填充，则检索单元52可以根据服务描述来减速回放速率。相反，如果缓冲器填充太快，则检索单元52可以根据服务描述来加速回放速率。

检索单元52还可以使用服务描述来确定媒体呈现的加入行为。例如，如果媒体呈现是实时事件，则检索单元52可以确定服务描述指示在媒体呈现的实时边缘处(即，在媒体呈现中媒体数据最近可用的点处)而不是在媒体呈现的开始处加入的加入行为。服务描述还可以指定与各种时延相关联的媒体呈现的感知质量，以及与客户端设备40的设备类型相关联的目标时延(例如，客户端设备40是否为蜂窝电话、计算机终端、电视、投影仪等)。

以这种方式，客户端设备40表示用于检索媒体数据的设备的示例，该设备包括配置为存储媒体呈现的媒体数据的存储器；以及一个或多个在电路中实现的处理器并且该处理器被配置为：检索包括数据的服务描述，该数据包括用于媒体呈现的一个或多个回放偏好，回放偏好包括期望的端到端时延；经由网络流式传输协议检索媒体呈现的媒体数据；以及根据一个或多个回放偏好呈现检索到的媒体数据，以实现期望的端到端时延。

同样地，内容准备设备20和服务器设备60表示用于发送媒体数据的设备的示例，该设备包括配置为存储媒体呈现的媒体数据和包括用于媒体呈现的一个或多个回放偏好的服务描述的存储器，回放偏好包括期望的端到端时延；以及一个或多个在电路中实现的处理器并且该处理器被配置为：将服务描述发送到客户端设备；从客户端设备接收对媒体呈现的媒体数据的请求；以及根据一个或多个回放偏好，响应于来自客户端设备的对媒体数据的请求，将媒体呈现的媒体数据发送给客户端设备，以实现期望的端到端时延。

图2是更详细地示出了图1的检索单元52的示例组件集合的框图。在该示例中，检索单元52包括eMBMS中间件单元100、DASH客户端110和媒体应用112。

在该示例中，eMBMS中间件单元100还包括eMBMS接收单元106、高速缓存104和代理服务器单元102。在该示例中，eMBMS接收单元106被配置为例如根据以下文档描述的单向传输上的文件传递(Delivery over Unidirectional Transport，FLUTE)经由eMBMS接收数据：T.Paila等人的“FLUTE—单向传输上的文件传递”，网络工作组，RFC 6726，2012年11月，可在tools.ietf.org/html/rfc6726获得。即，eMBMS接收单元106可以经由广播从例如服务器设备60接收文件，该服务器设备60可以充当广播/多播服务中心(BM-SC)。

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

代理服务器单元102可以充当DASH客户端110的服务器。例如，代理服务器单元102可以将MPD文件或其它清单文件提供给DASH客户端110。代理服务器单元102可以通告MPD文件中的分段的可用性时间，以及可以从中检索分段的超链接。这些超链接可以包括与客户端设备40相对应的本地主机地址前缀(例如，对于IPv4为127.0.0.1)。以这种方式，DASH客户端110可以使用HTTP GET或部分GET请求从代理服务器单元102请求分段。例如，对于链接http://127.0.0.1/rep1/seg3中可用的分段，DASH客户端110可以构造包括对http://127.0.0.1/rep1/seg3的请求的HTTP GET请求，并将该请求提交给代理服务器单元102。代理服务器单元102可以响应于这种请求而从高速缓存104中检索所请求的数据并将该数据提供给DASH客户端110。可替代地，DASH客户端110可以经由单播从服务器设备(例如服务器设备60)检索媒体数据。DASH客户端110可以将高速缓存104用作用于存储检索到的媒体数据的缓冲器，直到媒体数据准备好播放为止。

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

MPD 122可以包括与呈现124分离的数据结构。MPD 122可以对应于图1的清单文件66。同样地，呈现124可以对应于图1的呈现68。通常，MPD 122可以包括通常描述呈现124的特征(诸如编码和渲染特征、适配集合、MPD 122所对应的配置文件、文本类型信息、相机角度信息，评级信息，特技模式信息(例如，指示包括时间子序列的呈现的信息)，和/或用于检索远程时间段(例如，用于在回放期间将目标广告插入媒体内容)的信息)的数据。

报头数据126(如果存在)可以描述分段128的特性，例如，随机接入点(RAP，也称为流接入点(stream access point，SAP))的时间位置、分段128中的哪个包括随机接入点、到分段128内的随机接入点的字节偏移、分段128的统一资源定位符(URL)或分段128的其它方面。报头数据130(如果存在)可以描述分段132的相似特征。附加地或可替代地，这种特征可以被完全包括在MPD 122内。

分段128、132包括一个或多个编码的视频样本，每个样本可以包括视频数据的帧或条带。分段128的每个编码的视频样本可以具有相似的特征，例如，高度、宽度和带宽要求。尽管在图3的示例中未示出这种数据，但是可以通过MPD 122的数据来描述这种特征。MPD 122可以包括如3GPP规范所描述的特征，并添加本公开中所描述的任何或所有信令信息。

分段128、132中的每一个可以与唯一的统一资源定位符(URL)相关联。因此，可以使用诸如DASH的流式传输网络协议来独立地检索分段128、132中的每一个。以这种方式，诸如客户端设备40之类的目标设备可以使用HTTP GET请求来检索分段128或132。在一些示例中，客户端设备40可以使用HTTP部分GET请求来检索分段128或132的特定字节范围。

根据本公开的技术，如下面更详细地讨论的，MPD 122可以包括诸如xlink参数的数据，该数据定义服务描述参数数据的网络位置。可替代地，MPD 122可以包括服务描述本身。

图4是示出了示例视频文件150的元素的框图，其可以对应于呈现的分段，诸如图3的分段128、132种的一个。分段128、132中的每一个可以包括基本上符合图4的示例中所示的数据的布置的数据。可以说视频文件150封装了分段。如上所述，根据ISO基础媒体文件格式及其扩展的视频文件将数据存储在称为“盒(box)”的一系列对象中。在图4的示例中，视频文件150包括文件类型(file type，FTYP)盒152、电影(movie，MOOV)盒154、分段索引(segment index，sidx)盒162、电影片段(movie fragment，MOOF)盒164和电影片段随机访问(movie fragment random access，MFRA)盒166。尽管图4表示视频文件的示例，但是应当理解，根据ISO基础媒体文件格式及其扩展，其他媒体文件可以包括类似于视频文件150的数据构造的其它类型的媒体数据(例如，音频数据、定时文本数据等)。

文件类型(FTYP)盒152通常描述视频文件150的文件类型。文件类型盒152可以包括识别描述视频文件150的最佳使用的规范的数据。文件类型盒152可以替代地放置在MOOV盒154、电影片段盒164和/或MFRA盒166之前。

在一些示例中，诸如视频文件150的分段可以在FTYP盒152之前包括MPD更新盒(未示出)。MPD更新盒可以包括指示与包括视频文件150的呈现相对应的MPD将被更新的信息，以及用于更新MPD的信息。例如，MPD更新盒可以提供用于更新MPD的资源的URI或URL。作为另一示例，MPD更新盒可以包括用于更新MPD的数据。在一些示例中，MPD更新盒可以紧随视频文件150的分段类型(segment type，STYP)盒(未示出)，其中，STYP盒可以定义视频文件150的分段类型。

在图4的示例中，MOOV盒154包括电影报头(movie header，MVHD)盒156、轨道(TRAK)盒158和一个或多个电影扩展(movie extend，MVEX)盒160。通常，MVHD盒156可以描述视频文件150的一般特征。例如，MVHD盒156可以包括描述最初创建视频文件150的时间、最后修改视频文件150的时间、视频文件150的时间刻度、视频文件150的回放持续时间的数据，或通常描述视频文件150的其它数据。

TRAK盒158可以包括视频文件150的轨道的数据。TRAK盒158可以包括描述与TRAK盒158相对应的轨道的特征的轨道报头(track header，TKHD)盒。在一些示例中，TRAK盒158可以包括编码的视频图片，而在其它示例中，轨道的编码的视频图片可以包括在电影片段164中，电影片段164可以由TRAK盒158和/或sidx盒162的数据引用。

在一些示例中，视频文件150可以包括一个以上的轨道。因此，MOOV盒154可以包括与视频文件150中的轨道数量相等的TRAK盒数量。TRAK盒158可以描述视频文件150的对应轨道的特征。例如，TRAK盒158可以描述对应轨道的时间和/或空间信息。当封装单元30(图3)在视频文件(例如视频文件150)中包括参数集合轨道时，类似于MOOV盒154的TRAK盒158的TRAK盒可以描述参数集合轨道的特征。封装单元30可以信令通知在描述参数集合轨道的TRAK盒内的参数集合轨道中的序列级SEI消息的存在。

MVEX盒160可以描述对应的电影片段164的特征，例如，除了MOOV盒154内包括的视频数据(如果有的话)之外，信令通知视频文件150包括电影片段164。在流式传输视频数据的上下文中，编码的视频图片可以被包括在电影片段164中，而不是被包括在MOOV盒154中。因此，所有编码的视频样本可以被包括在电影片段164中，而不是被包括在MOOV盒154中。

MOOV盒154可以包括与视频文件150中的电影片段164的数量相等的MVEX盒160的数量。MVEX盒160中的每一个可以描述电影片段164中的对应一个的特征。例如，每个MVEX盒可以包括描述了电影片段164中的对应一个的时间持续时间的影扩展报头(movie extendsheader，MEHD)盒。

如上所述，封装单元30可以将序列数据集合存储在不包括实际编码的视频数据的视频样本中。视频样本通常可以对应于接入单元，该接入单元是在特定时间实例的编码的图片的呈现。在AVC的上下文中，编码的图片包括一个或多个VCL NAL单元，该一个或多个VCL NAL单元包含用于构造接入单元和其它相关联的非VCL NAL单元的所有像素的信息，例如SEI消息。因此，封装单元30可以在电影片段164中的一个中包括序列数据集合，该序列数据集合可以包括序列级SEI消息。封装单元30还可以信令通知序列数据集合和/或序列级SEI消息的存在，该序列数据集合和/或序列级SEI消息存在于与电影片段164中的一个相对应的MVEX盒160中的一个内的电影片段164中的一个中。

SIDX盒162是视频文件150的可选元素。也就是说，符合3GPP文件格式或其它此类文件格式的视频文件不一定包括SIDX盒162。根据3GPP文件格式的示例，SIDX盒可以用于识别分段(例如，视频文件150内包含的分段)的子分段。3GPP文件格式将子分段定义为“具有相应(多个)媒体数据盒的一个或多个连续的电影片段盒的自包含集合，并且包含由电影片段盒引用的数据的媒体数据盒必须在该电影片段盒之后并且在包含有关同一轨道的信息的下一个电影片段盒之前。”3GPP文件格式还指示SIDX盒“包含对该盒所记录的(子)分段的子分段的一系列引用。引用的子分段在呈现时间上是连续的。同样，由分段索引盒引用的字节在分段内始终是连续的。引用的尺寸给出引用的材料中字节数的计数。”

SIDX盒162通常提供表示视频文件150中包括的分段的一个或多个子分段的信息。例如，这种信息可以包括子分段开始和/或结束的回放时间、子分段的字节偏移、子分段是否包括(例如，从流接入点开始)流接入点(SAP)，SAP的类型(例如，SAP是否是瞬时解码器刷新(instantaneous decoder refresh，IDR)图片、干净的随机接入(clean random access，CRA)图片、断开的链路接入(broken link access，BLA)图片等)、SAP在子分段中的位置(根据回放时间和/或字节偏移)等。

电影片段164可以包括一个或多个编码的视频图片。在一些示例中，电影片段164可以包括一个或多个图片组(groups of picture，GOP)，每个图片组可以包括多个编码的视频图片，例如，帧或图片。另外，如上所述，在一些示例中，电影片段164可以包括序列数据集合。电影片段164中的每一个可以包括电影片段报头盒(MFHD(movie fragment header)，未在图4中示出)。MFHD盒可以描述对应的电影片段的特征，例如电影片段的序列号。电影片段164可以按序列号的顺序被包含在视频文件150中。

MFRA盒166可以描述视频文件150的电影片段164内的随机接入点。这可以有助于执行特技模式，例如对由视频文件150封装的分段内的特定时间位置(即，回放时间)执行搜索。在一些示例中，MFRA盒166通常是可选的，并且不需要被包括在视频文件中。同样地，客户端设备(例如客户端设备40)不一定需要参考MFRA盒166来正确地解码和显示视频文件150的视频数据。MFRA盒166可以包括等于视频文件150的轨道数量，或者在一些示例中等于视频文件150的媒体轨道(例如，非提示轨道)的数量的轨道片段随机接入(track fragmentrandom access，TFRA)盒(未示出)的数量。

在一些示例中，电影片段164可以包括一个或多个流接入点(SAP)，例如IDR图片。同样地，MFRA盒166可以提供SAP的视频文件150内的位置的指示。因此，视频文件150的时间子序列可以由视频文件150的SAP形成。时间子序列还可以包括其它图片，例如依赖于SAP的P帧和/或B帧。可以将时间子序列的帧和/或条带布置在分段内，使得可以适当地对依赖于子序列的其它帧/条带的时间子序列的帧/条带进行解码。例如，在数据的分层布置中，用于其它数据的预测的数据也可以被包括在时间子序列中。

图5是示出了包括可以执行本公开的技术的各种设备和单元的示例架构200的概念图。具体而言，架构200包括服务器侧设备和单元，包括自适应比特率(adaptive bitrate，ABR)编码器、加密和CMAF封包设备206、MPD生成和DASH封包设备208、源服务器设备210、基于会话的MPD修改设备204和CDN(HTTPS)设备212。架构200还包括客户端侧设备和单元的两个示例集合。作为一个示例，第一客户端设备包括低时延DASH客户端单元214、文件格式解析(CMAF)单元216、解密单元218和解码单元220。作为另一示例，第二客户端设备包括常规DASH客户端单元222、文件格式解析单元224、解密单元226和解码单元228。

图5的设备和单元可以对应于图1的设备和单元。例如，图5的ABR编码器、加密和CMAF封包设备206，以及MPD生成和DASH封包设备208(并且在一些情况下，源服务器设备210)可以共同地对应于图1的内容准备设备20。图5的CDN(HTTPS)设备212可以对应于图1的服务器设备60。图5的各种DASH客户端214、222，文件格式解析单元216、224，解密单元218、226和解码单元220、228可以对应于图1的客户端设备40的各个组件，诸如检索单元52、解封装单元50、音频解码器46和视频解码器48。

在图5的示例中，ABR编码器、加密和CMAF封包设备206可以例如产生公共媒体应用格式(common media application format，CMAF)/DASH分段。MPD生成和DASH封包设备208生成MPD并将数据作为DASH分段发布在源服务器设备210上。基于MPD中的信息，DASH客户端单元214、222可以发起它们的流式传输逻辑和播放。常规DASH客户端单元222可以基于其缓冲逻辑以例如10秒的时延来播放媒体呈现。然而，低时延DASH客户端单元214可以识别出其能够减少端到端时延从而提供更好的流式传输体验。常规的DASH客户端也可以用于补看(catch-up)服务。

图6是示出了根据本公开的技术的在示例低时延模式中DASH封包设备252的示例操作的概念图。在该示例中，DASH封包设备252将CMAF报头(CMAF header，CH)、CMAF非初始组块(CMAF non-initial chunk，CNC)和CMAF初始组块(CMAF initial chunk，CIC)封包到包括相应的HTTP组块的DASH分段中。也就是说，产生ISO BMFF电影片段或CMAF组块，然后由DASH封包设备252将其映射到HTTP组块。DASH客户端(例如常规DASH客户端单元254和低时延DASH客户端单元256)请求完整的分段，但是DASH封包设备252可以比其完整可用性更早地开始传送分段。具体地，DASH封包设备252可以将分段提供给CDN设备262，CDN设备262可以存储该分段，并且响应于来自DASH客户端254、256的对分段的HTTP请求，将DASH分段提供给DASH客户端254、256。

常规操作之外的DASH低时延技术概述包括：

·每个分段有多个电影片段，以能够产生分段的较早部分并将其提供到CDN上。

ο组块持续时间是一个部署选项，但示例包括：1帧，320ms，“迷你GOP”。

·在MPD中信令通知早期可用性

ο在DASH MPD中支持使用@availabilityTimeOffset和@availablityComplete属性，与标称可用性时间相比这些属性信令通知分段的早期可用性。

·使用@duration和$Number$用于信令通知URL和可用性时间

o本公开认识到分段时间线的问题，该问题要求知道分段的持续时间并予以公布。

·信令通知帧和prtf的捕获时间

οDASH的Amd.5中对此进行了讨论。

·部分可用文件的HTTP组块传输编码

·支持Emsg解析

ο可用于MPD更新。

ο可能可用于信令通知稀疏元数据。

·实时和低时延的DRM和加密

ο可用于确保许可证获取可以在时延限制下完成，并且不会在网络基础设施中过载。

·考虑信令通知缺失或不适当的内容

οDASH的Amd.5中对此进行了讨论。

·在设备中加速的回放，以解决低时延和快速启动二者的问题

ο这可以用于确保可以在不牺牲信道接入的情况下维持时延。

·HTTP变体，例如，支持排队的请求。

·低时延模式的显式信令通知(格式信令通知和/或协议)。

在DASH部署中，DASH客户端对DASH服务的算法和用户感知具有重要的控制。DASH客户端可以例如确定使用速率适配算法、缓冲器策略、缓冲器持续时间以及所得的时延和信道改变时间。但是，通过将所有决策留给DASH客户端，这可能导致不一致的行为，因为不同的客户端实现可以(例如)选择不同的策略。因此，作为示例，对于不同的DASH客户端上的相同服务，可以观察到明显不同的时延。

图7是示出了根据本公开的技术的示例DASH客户端配置的概念图。图7描绘了编码器和DASH封包设备280(其可以对应于图1的内容准备设备20)、CDN设备282(其可以对应于图1的服务器设备60)以及低时延DASH客户端单元286(其可以对应于图1的客户端设备40的检索单元52)。在该示例中，编码器和DASH封包设备280准备包括HTTP组块的分段的CNC和CIC，并将这些分段提供给CDN设备282。CDN设备282响应于对分段或HTTP组块的HTTP请求，将这些分段(或其HTTP组块)提供给低时延DASH客户端单元286。

在应用控制媒体呈现服务的回放的情况下，该应用还可以控制低时延DASH客户端单元286。作为示例，图7示出了将低时延DASH客户端单元286(例如，dash.js客户端)集成到服务环境中。当前实现2.9.0中的Dash.js支持API集合，应用可以使用这些API来将客户端设置为低时延模式并确定延迟。在图7的示例中，延迟设置为1，指示目标为1秒。在测试运行中，这种设置导致2.2秒的延迟。

这种情况可能会导致服务被提供给不同的DASH客户端实现的部署：

·基于应用的解决方案并不总是可靠的，因为某些环境例如在没有应用的情况下工作，或者应用无法接入DASH客户端。此外，DASH客户端API可以不同，并且没有通用的解决方案，并且无法设置参数。

·DASH客户端需要根据来自服务提供、设备功能、用户交互和网络状态的信息做出复杂的决定。此类信息可能并不总是被一致地表达。

·服务提供商想要表达支持/强制DASH客户端适当执行速率适配的期望的服务感知。

因此，有益的是更一致地定义服务参数并使得能够将这些服务参数作为清单文件(例如，MPD)的一部分进行传送。服务参数的客户端的使用可能取决于客户端的实现，但是也可以在某些应用标准中，在客户端上制定更高的要求以满足此类服务参数。根据本公开的技术，编码器和DASH封包设备280可以准备包括回放偏好的服务描述，例如CDN设备282和低时延DASH客户端单元286之间(或者编码器和DASH封包设备280和低时延DASH客户端单元286之间)的期望的端到端时延。

以下用例可以被视为服务配置，其可以在服务描述的回放偏好中表达：

1.服务具有期望的端到端时延，由此内容包含一些锚点，这些锚点将媒体时间映射到挂钟时间(或DASH客户端可以访问的任何其它时间参考)，因此DASH客户端在此时延下回放该服务。

2.从最小值开始，服务可能会随着延迟而逐渐降级。例如，在3.5秒的时延，质量可以被认为是高的，在10秒的时延，质量可以被认为是中等的，在30秒的时延，实时消费中的质量可以被认为是低的。

3.在实时情况下，服务可以请求在重新缓冲的情况下，服务尽快返回实时延迟，而不是延迟服务。在另一种情况下，服务可以优选地不跳回实时边缘。

4.还有另一服务可以尝试与另一设备同步，并且该服务仅在其维持特定时延的情况下才有价值。如果时延大于请求的时延，则服务质量可能是无用的。

5.服务产品可以提供期望的接入时间，或者可能在服务接入时间内提供质量下降。

6.该服务是UHD服务，并且根据选择的呈现和适配集合(可能随着时间的推移)来判断服务质量。

7.该服务具有多种产品，例如以标清(SD)、高清(HD)和超高清(UHD)提供。根据设备功能(例如设备显示分辨率)，客户端希望选择匹配的适配集合。

8.对于音频可以考虑类似的方面。根据扬声器布局，应选择专用的适配集合。

9.可以根据客户端应遵守的最大重新缓冲百分比来描述服务质量，或者可以在重新缓冲率上提供质量下降。

10.该服务可以允许媒体的加速或减速的回放，以补偿缓冲器问题。可以指定允许的最大加速/减速。

因此，编码器和DASH封包设备280可以准备服务描述，该服务描述包括表示上述讨论的任何或所有配置数据的回放偏好，例如期望的端到端时延。低时延DASH客户端单元286可以使用服务描述及其回放偏好来控制回放，例如以实现期望的端到端时延。例如，低时延DASH客户端单元286可以检索分段或HTTP组块，并将这些分段或组块存储到存储器中的缓冲器，诸如图2中所示的高速缓存104。低时延DASH客户端单元286还可以确定清空缓冲器的速度是快于还是慢于填充缓冲器的速度。如果清空缓冲器的速度快于填充缓冲器的速度，则低时延DASH客户端单元286可以降低媒体数据的回放速率，以避免缓冲器下溢。如果清空缓冲器的速度慢于填充缓冲器的速度，则低时延DASH客户端单元286可以提高媒体数据的回放速率，以避免缓冲器溢出。低时延DASH客户端单元286可以使用在服务描述中信令通知的数据，该服务描述指定了媒体回放的最大和最小加速/减速，以确保这种回放速率调整在指定的最大和最小范围内。

作为另一示例，期望的端到端时延可以是各种指定的目标时延中的一个。编码器和DASH封包设备280可以指定与每个可能的目标延迟相关联的各种质量。以这种方式，低时延DASH客户端单元286可以选择与期望的回放质量相关联的目标时延中的一个，并且检索和回放与所选择的目标时延相关联的媒体数据。

低时延DASH客户端单元286可以响应于重新缓冲事件(即，回放中的中断)，进一步确定是从回放被中断的地方继续回放还是向前跳到实时边缘。实时边缘表示可以被检索和呈现的媒体数据的最近可用部分。编码器和DASH封包设备280可以指定在服务描述中推荐这些行为中的哪一个。

在一些示例中，编码器和DASH封包设备280可以指定一个或多个客户端设备是否应同步回放(例如，如果多个显示器正在显示相同的实时内容，例如正在实时发生的体育赛事或有新闻价值的事件)。仅当所有同步设备使用相同的延迟时，这种同步才是可能的。编码器和DASH封包设备280可以指定此类时延以用于同步。因此，低时延DASH客户端单元286可以确定是否与一个或多个其它客户端设备同步回放，并且如果是，则使用指定用于同步的时延中的一个作为期望的端到端时延。

可以考虑其它方面，并且可以考虑一些可扩展性或专有信令通知。

质量的降低可以用例如平均意见得分(mean opinion score，MOS)得分来表示，或者可以表示为抽象点标度，例如从0(无法使用的质量)到100(完美的质量)。

根据本公开的技术，低时延DASH客户端单元286可以将这些参数中的一个或多个用于内容的静态选择以及用于回放的动态操作以创建考虑到不同服务产品(serviceoffering)的不同维度的实用功能。

DASH客户端(例如图1的检索单元52、图2的DASH客户端110，或图5-图7的各种DASH客户端)以及源设备(例如内容准备设备20和服务器设备60，或图5-图7的各种服务器和源设备)可以被配置为使用本公开的技术。通常，本公开的技术：

·定义良好定义的服务描述参数的集合，这些参数反映实际用例，并且DASH客户端可以使用这些参数来遵循这些技术。

·在DASH中定义服务描述到MPD信令的映射。服务描述可以作为URL提供，例如作为xlink提供。这避免了MPD更新需要重复地重新获取数据。在媒体呈现的实时时间内，信息应该是静态的。

·定义扩展机制，以便可以根据服务器和客户端协议添加服务信令。

·定义简单的DASH参考客户端描述以显示如何在DASH操作中使用此类信息。

根据本公开的技术，以下任何或所有参数可以包括在服务描述参数中：

·服务类型：提供服务类型的描述

ο实时：客户端只期望跟踪实时边缘。

ο实时和补看(catchup)：该服务期望将跟踪实时边缘，但也可以用作补看。

ο补看：该服务是从实时服务转换而来的，但是所有媒体都可用

ο按需：该服务是按需服务。

ο未知：服务类型未知。

ο基数(Cardinality)：0…1

·加入行为类型

ο实时边缘：客户端期望在实时边缘加入。

ο第一时间段：客户端期望在第一时间段加入。

ο未知：客户根据自己或其它信息进行选择。

ο基数：0…1

·实时时延属性：

ο最小时延

ο最大时延

ο期望的时延

ο对(pair)的集合(时延和质量)

ο基数：0…1

·重新缓冲属性

ο最大重新缓冲百分比

ο期望的重新缓冲百分比

ο作为对的集合(重新缓冲百分比和时延)

ο基数：0…1

·随机接入时间

ο期望的随机接入时间

ο最大随机接入时间

ο对的集合(随机接入时间和质量)

ο基数：0…1

·对于设备类型的服务质量(可以针对每个时间段进行更新)

ο设备属性

ο显示分辨率

ο其它设备类型元素

ο对(选择的呈现id和质量)

ο基数：0…N

·加速的回放

ο最大

ο最小

ο最大百分比

ο基数：0…1

·服务参数

οschemeIdURI和值

ο遵循DASH描述符逻辑

图8是示出了根据本公开的技术的向客户端设备发送媒体数据的示例方法的流程图。关于图1的内容准备设备20解释图8的方法。然而，应当理解，诸如图1的服务器设备60的其它设备可以被配置为单独地或与内容准备设备20结合地执行这些或其它类似技术。例如，图5的MPD生成和DASH封包设备208、源服务设备210和CDN(HTTPS)设备212可以共同执行图8的方法的对应部分。作为另一示例，图6的DASH封包设备252和CDN设备262可以联合执行图8的方法的对应部分。作为另一示例，编码器和DASH封包设备280和CDN设备282可以联合执行图8的方法的对应部分。

在该示例中，内容准备设备20最初例如从管理员或其他用户接收定义用于媒体呈现的回放偏好的数据(300)。这种回放偏好可以包括用于媒体呈现的一个或多个时延，以及实现那些时延的其它属性。内容准备设备20然后可以准备指定回放偏好的服务描述(302)。例如，如上所述，内容准备设备20可以构建服务描述以指定服务类型，诸如实时、实时和补看、补看、或按需。作为另一示例，内容准备设备20可以构建服务描述以指定加入行为，例如在实时边缘或在第一可用时间段加入。作为另一示例，内容准备设备20可以构建服务描述以指定时延属性，例如最小时延和/或最大时延、一个或多个目标时延，以及在一些情况下，用于指定目标时延的对应的质量。

作为另一示例，内容准备设备20可以构建服务描述以指定重新缓冲属性，例如最大重新缓冲百分比和期望的重新缓冲百分比，以及在一些示例中，对于重新缓冲百分比的对应的时延。作为另一示例，内容准备设备20可以构建服务描述以指定随机接入时间，例如期望的随机接入时间和/或最大随机接入时间，以及在一些示例中，相关联的质量。作为另一示例，内容准备设备20可以构建服务描述以基于设备类型来指定服务质量，例如设备的特征(例如，显示分辨率)以及每种类型的设备的对应的期望的质量。

在一些示例中，内容准备设备20可以构建服务描述以指定加速或减速的回放速率信息，例如最大加速，最小加速(即，最大减速)和/或回放速率调整百分比。可以设置此类回放速率调整，以防止客户端设备缓冲器溢出和下溢，而不会过度影响媒体回放的可感知质量。内容准备设备20可以构建服务描述以根据DASH描述符逻辑将各种参数指定为schemeIdURI和值。

内容准备设备20然后可以将服务描述发送到客户端设备，例如客户端设备40(图1)(304)。内容准备设备20可以经由服务器设备60发送服务描述。在一些示例中，内容准备设备20可以将服务描述发送到不同的网络位置，并且在清单文件(例如，MPD)中为该服务描述的网络位置指定URL或其它标识符。内容准备设备20然后可以从客户端设备接收对媒体数据的请求(306)，并且根据在服务描述中指定的服务参数将所请求的媒体数据发送到客户端设备(308)以实现期望的端到端时延。

以这种方式，图8的方法表示发送媒体的方法的示例，该方法包括向客户端设备发送包括数据的服务描述，该数据包括用于对应的媒体呈现的一个或多个回放偏好，该回放偏好包括期望的端到端时延；从客户端设备接收对媒体呈现的媒体数据的请求；根据一个或多个回放偏好，响应于来自客户端设备的对媒体数据的请求，将媒体呈现的媒体数据发送到客户端设备，以实现期望的端到端时延。

图9是示出了根据本公开的技术的检索媒体数据的示例方法的流程图。关于图1的客户端设备40解释图9的方法。然而，应当理解，其他设备可以被配置为执行该方法或类似方法。例如，图5的低时延DASH客户端单元214、图5的常规DASH客户端单元222、图6的常规DASH客户端单元254、图6的低时延DASH客户端单元256或图7的低时延DASH客户端单元286可以被配置为根据本公开的技术执行该方法或类似方法。

在该示例中，客户端设备40的检索单元52接收指定对于媒体呈现的回放偏好的服务描述(320)。例如，检索单元52可以最初检索清单文件(例如，MPD)，例如图1的清单文件66或图3的MPD 122。清单文件可以包括服务描述。可替代地，清单文件可以指定可以从其检索服务描述的网络位置，并且客户端设备40可以例如通过取消引用清单文件的xlink参数来检索服务描述。

然后，检索单元52可以从服务描述中确定对于媒体呈现的期望的端到端时延(322)。例如，服务描述可以指定一个或多个目标时延，其可以包括最大和/或最小时延。服务描述还可以(附加地或替代地)为各种时延指定对应的质量等级。在一些示例中，服务描述可以指定与各种类型的客户端设备(例如，蜂窝电话、计算机终端、电视、投影仪等)相关联的各种时延。另外，服务描述可以指定用于执行回放以实现和维持目标时延的技术，例如最大和最小回放加速(或减速)值。服务描述还可以指定如上所述的其它回放偏好，例如加入行为，重新缓冲行为等。

因此，检索单元52可以根据回放偏好来请求媒体数据(324)并且可以根据回放偏好来回放媒体数据(326)。例如，假设服务描述指定了期望的端到端时延和回放加速/减速速率以实现期望的端到端时延，则检索单元52可以检索媒体数据并将媒体数据缓冲在存储器中(例如，图2的高速缓存104)。在回放期间，检索单元52可以根据缓冲器是否被过快地填充或清空而加速或减速回放。如上所述，如果缓冲器被过快地填充，则检索单元52可以加速回放速率，而如果缓冲器被过快地清空，则检索单元52可以在服务描述的信令通知的回放加速/减速速率之内减速回放速率。

作为另一示例，如果发生重新缓冲事件，则检索单元52可以根据服务描述来确定是从回放被中断的地方还是在媒体呈现的实时边缘重新开始回放。类似地，检索单元52可以在最初接入媒体呈现时确定是接入媒体呈现的最早可用时间段还是媒体呈现的实时边缘。

以这种方式，图9的方法表示检索媒体数据的方法的示例，该方法包括：检索包括数据的服务描述，该数据包括用于对应的媒体呈现的一个或多个回放偏好，回放偏好包括期望的端到端时延；经由网络流式传输协议检索媒体呈现的媒体数据；以及根据一个或多个回放偏好呈现检索到的媒体数据，以实现期望的端到端时延。

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

作为示例而非限制，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁性存储设备、闪存或可用于以指令或数据结构形式存储所需程序代码且可由计算机访问的任何其他介质。而且，任何连接都适当地称为计算机可读介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或无线技术(例如红外，无线电和微波)从网站、服务器或其他远程源发送指令，则介质的定义包括同轴电缆、光纤电缆、双绞线、DSL或无线技术(例如红外，无线电和微波)。然而，应当理解，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其他瞬时介质，而是针对非瞬时的有形存储介质。本文使用的磁盘和光盘包括压缩光盘(CD)、激光光盘、光学光盘、字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常以磁性方式复制数据，而光盘则通过激光光学方式复制数据。上述的组合也应包括在计算机可读介质的范围内。

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

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

已经描述了各种示例。这些和其他示例在所附权利要求的范围内。