CN103931204B - 媒体数据的网络流 - Google Patents

Abstract

在一示例中，一种设备包括一个或多个处理器，该一个或多个处理器被配置成：接收媒体数据的第一段，其中，第一段的媒体数据包括流接入点；接收媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处没有流接入点；以及相对于第一段的数据的至少一部分，对第二段的媒体数据的至少一部分进行解码。以此方式，本公开内容的技术可以用于实现针对例如HTTP上的动态自适应流(DASH)的低延迟直播简档。

Description

媒体数据的网络流

要求优先权

本申请要求享受于2011年10月5日提交的美国临时申请序列号No.61/543,792和于2012年9月19日提交的美国临时申请序列号No.61/703,174的权益，故明确地以引用方式将这两个申请中的每一个的全部内容并入本申请。

技术领域

本公开内容涉及存储和传输经过编码的媒体数据。

背景技术

可以将数字视频能力并入到大范围的设备中，包括数字电视、数字直接广播系统、无线广播系统、个人数字助理(PDA)、膝上型或台式计算机、数字照相机、数字记录设备、数字媒体播放器、视频游戏设备、视频游戏控制台、蜂窝或卫星无线电话、视频远程会议设备等。数字视频设备实现视频压缩技术，例如在由MPEG2、MPEG-4、ITU-T H.263或ITU-TH.264/MPEG-4、第10部分、高级视频编码(AVC)、很快会出现的高效视频编码(HEVC)标准以及这些标准的扩展中定义的标准中所描述的视频压缩技术，以更有效地发送和接收数字视频信息。

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

在已经对视频数据进行编码之后，可以将视频数据进行打包，以进行传输或存储。可以按照各种标准中的任何一些，将视频数据组装在视频文件中，例如国际标准化组织(ISO)基础媒体文件格式及其扩展，例如ITU-T H.264/AVC。可以以各种方式传输这样的打包视频文件，例如使用网络流量在计算机网络上进行传输。

发明内容

一般而言，本公开内容描述了用于通过网络流式传送媒体数据的技术。更具体地，本公开内容的方面涉及减少与通过网络，例如根据HTTP上的动态自适应流(DASH)，流式传送媒体数据相关联的延迟。在一些示例中，本公开内容的技术包括形成在段的开始处没有流接入点(SAP)的媒体数据的段。例如，在所有段中，一个或多个段可以没有SAP，或可以在不同于SAP的开始的位置处包括SAP。作为示例，可以使用在不同于段的开始的位置处的SAP来代替强迫的SAP，即，由应用标准所要求的SAP。

在一个示例中，一种方法包括：接收媒体数据的第一段，其中，所述媒体数据的第一段包括第一流接入点；接收媒体数据的第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点；以及在继所述第一流接入点之后的第二流接入点可用之前，相对于所述媒体数据的第一段的至少一部分，对所述媒体数据的第二段的至少一部分进行解码。

在另一示例中，一种设备包括一个或多个处理器，所述一个或多个处理器被配置成：接收媒体数据的第一段，其中，所述媒体数据的第一段包括第一流接入点；接收媒体数据的第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点；以及在继所述第一流接入点之后的第二流接入点可用之前，相对于所述第一段的媒体数据的至少一部分，对所述媒体数据的第二段的至少一部分进行解码。

在另一示例中，一种设备包括：用于接收媒体数据的第一段的模块，其中，所述媒体数据的第一段包括第一流接入点；用于接收媒体数据的第二段的模块，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点；以及用于在继所述第一流接入点之后的第二流接入点可用之前，相对于所述媒体数据的第一段的至少一部分，对所述媒体数据的第二段的至少一部分进行解码的模块。

在另一示例中，一种计算机可读存储介质具有存储在其上的指令，当所述指令被执行时，使得处理器：接收媒体数据的第一段，其中，所述媒体数据的第一段包括第一流接入点；接收媒体数据的第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点；以及在继所述第一流接入点之后的第二流接入点可用之前，相对于所述媒体数据的第一段的至少一部分，对所述媒体数据的第二段的至少一部分进行解码。

在另一示例中，一种方法包括：获得媒体数据的第一段，其中，所述媒体数据的第一段包含第一流接入点；向客户端设备发送所述第一段；获得媒体数据的第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点，并且其中，相对于所述媒体数据的第一段的一部分，对所述媒体数据的第二段的至少一部分进行编码；以及在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段。

在另一示例中，一种设备包括一个或多个处理器，所述一个或多个处理器被配置成：获得媒体数据的第一段，其中，所述媒体数据的第一段包含第一流接入点；向客户端设备发送所述第一段；获得媒体数据的第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点，并且其中，相对于所述媒体数据的第一段的一部分，对所述媒体数据的第二段的至少一部分进行编码；以及在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段。

在另一示例中，一种设备包括：用于获得媒体数据的第一段的模块，其中，所述媒体数据的第一段包含第一流接入点；用于向客户端设备发送所述第一段的模块；用于获得所述媒体数据的第二段的模块，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点，并且其中，相对于所述媒体数据的第一段的一部分，对所述媒体数据的第二段的至少一部分进行编码；以及用于在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段的模块。

在另一示例中，一种计算机可读存储介质具有存储在其上的指令，当所述指令被执行时，使得处理器：获得媒体数据的第一段，其中，所述媒体数据的第一段包含第一流接入点；向客户端设备发送所述第一段；获得第二段，其中，所述媒体数据的第二段在所述第二段的开始处没有流接入点，并且其中，相对于所述媒体数据的第一段的一部分，对所述媒体数据的第二段的至少一部分进行编码；以及在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段。

结合附图和下文的描述给出了一个或多个示例的细节。根据说明书以及附图以及根据权利要求书，其它的特征、目的和优点将显而易见。

附图说明

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

图2是示出根据本公开内容的方面的示例性获取单元的示例的框图。

图3是示出示例性多媒体内容的器件的示意图。

图4是示出根据本公开内容的方面的示例性视频数据片段的框图。

图5是示出用于执行本公开内容的技术的示例性方法的流程图。

图6是示出一系列经编码的视频帧和包括视频帧的段的示意图。

图7是示出根据IDR间隔展示误码秒数的实验测试结果的曲线图。

图8是示出由于前向纠错(FEC)的实验测试结果的另一示例的曲线图。

图9是示出展示以各种IDR间隔(在呈现时间)的段的比特率的实验测试结果的曲线图。

图10示出了描绘相对于平均意见得分(MOS)的各种峰值信噪比的一组曲线。

图11是描绘在具有和不具有FEC的情况下，展示针对各种数据突发间隔的误码秒数的实验测试结果的曲线图。

图12是示出针对各种段持续时间的IDR间隔的各种示例的示意图。

图13是示出用于发送不包括流接入点(SAP)的表现的一个或多个段的示例性方法的流程图。

图14是示出针对DASH实时和低延迟实时曲线的数据安排的示例的示意图。

图15是示出在物理层针对示例性DASH实时和DASH低延迟实时曲线的每段比特率的示意图。

图16是示出用于最小化低延迟实时段的峰到峰比特率变化的技术的示意图。

图17是示出与DSH实时和DASH低延迟实时曲线对应的示例性表现的示意图，其中，场景变化的IDR帧与强迫的IDR帧同时发生。

图18是示出在存在不同步的场景变化的IDR帧的情况下，用于最小化峰到峰比特率变化的技术的示意图。

图19是示出允许场景变化的IDR帧的次优强迫的IDR图像序列的示意图。

图20是示出用于形成根据本公开内容的某些技术的表现的另一示例性方法的流程图。

具体实施方式

一般来说，本公开内容描述了用于在网络上流式传送多媒体数据的技术，例如，音频和视频数据。可以结合HTTP上的动态自适应流(DASH)来使用本公开内容的技术。本公开内容描述了可以结合网络流来执行的各种技术，可以单独或以任何组合来实现其中的任何一个或全部。如在下文更详细描述的，可以将执行网络流的各种设备配置成实现本公开内容的技术。

根据DASH以及用于在网络上流式传送数据的类似技术，可以以多种方式编码多媒体内容(例如，电影或其它音频/视频内容，其也可以包括文字蒙板或其它数据)，并且其可以具有各种特征。内容准备设备可以形成相同多媒体内容的多个表现。每一表现可以与特定的一组特征相对应，例如编码和呈现特征，以利用具有各种编码和呈现能力的客户端设备提供可用的数据。此外，具有各种比特率的表现可以允许带宽适应。即，客户端设备可以确定当前可用的带宽量，并基于可用的带宽量与客户端设备的编码和呈现能力一起来选择表现。

在一些示例中，内容准备设备可以指示一组表现具有一组共同的特征。然后，内容准备设备可以将设置表格中的表现指示为自适应组，其中该组中的表现可以用于带宽适应。在一些实例中，还可以将自适应组成为“表现组”。该组中的表现可以在比特率、分辨率和/或帧率上不同，但是其共享基本上相同的特征。以此方式，客户端设备可以针对多媒体内容的自适应组确定各中共同特征组，并且基于客户端设备的编码和呈现能力选择自适应组。然后，客户端设备可以适应性地基于带宽可用性在所选择的自适应组中的表现之间切换。

内容准备设备还可以针对诸如格式为由3GPP(第三代合作伙伴计划)所规定的媒体呈现描述(MPD)文件之类的清单文件的不同部分提供相分离的网络位置。即，清单文件的不同部分可以是利用例如诸如统一资源定位符(URL)之类的各种统一资源标识符(URI)独立可寻址的。清单文件的初始部分可以包括URI、URL、或清单文件的另一部分的其它位置标识符。例如，如上文所讨论的，清单文件的第一部分可以包括自适应组的共同特征的描述。

自适应组中的每一个可以与清单文件的相应的不同部分相关联，其可以包括对相应的自适应组中的表现的媒体数据的位置进行指示的数据。以此方式，客户端设备可以接收清单文件的第一部分，选择适当的自适应组，针对所选择的自适应组获得清单文件的另一部分，选择所选择的组中的表现，并使用清单文件的另一部分来获得所选择的表现的数据。此外，客户端设备可以视频成使用清单文件的另一部分来改变网络带宽，即，特定于所选择的自适应组的部分。

DASH还可以在直播内容的流的背景下使用，即，实况记录的媒体内容，例如，在体育事件、有报导价值的事件、或观众希望基本上实时看见的其它时间期间。例如，可以使用增强型多媒体广播多播服务(eMBMS)来流式传送基本上实时形成的DASH段。因为观众想要尽量接近实时的观看内容，所以减少延迟(即，在事件发生和观众能看见该事件之间的延迟)的技术是非常可取的。如下文更详细描述的，本公开内容描述了可以用于减少延迟的技术。

诸如媒体内容的表现的段之类的视频文件可以符号根据ISO基本媒体文件格式、可伸缩视频编码(SVC)文件格式、高级视频编码(AVC)文件格式、第三代合作伙伴技术(3GPP)文件格式、和/或多视点视频编码(MVC)文件格式或其它类似的视频文件格式中的任何一个封装的视频数据。

ISO基本媒体文件格式被设计成包含用于以便于实现对该媒体的交换、管理、编辑以及呈现的弹性的、可扩展的格式来呈现的有时限的媒体信息。在MPEG-4部分12中可以指定ISO基本媒体文件格式(ISO/IEC14496-12：2004)，其针对基于时间的媒体文件定义了通用结构。ISO基本媒体文件格式被用作诸如被定义支持H.264/MPEG-4AVC视频压缩的AVC文件格式(ISO/IEC14496-15)、3GPP文件格式、SVC文件格式以及MVC文件格式之类的家族中的其它文件格式的基础。3GPP文件格式和MVC文件格式是AVC文件格式的扩展。ISO基本媒体文件格式包含时间、结构以及针对有时限的媒体数据序列的媒体信息，例如，视听呈现。文件结构可以是面向对象的。可以非常简单地将文件分解成基本对象并且从它们的类型隐含了对象的结构。

符号ISO基本媒体文件格式(及其扩展)的文件可以形成为一系列的对象，称为“盒”。可以在盒中包含ISO基本媒体文件中的数据，使得没有其它数据需要包含在该文件中，并且不需要有位于文件内的盒之外的数据。这包括特定文件格式所需的任何初始签名。“盒”可以是由独特的类型标识符和长度所定义的面向对象的构件。典型地，在一个文件中包含呈现，并且媒体呈现是独立的。电影容器(电影盒)可以包含媒体的元数据，并且视频和音频帧可以包含在媒体数据容器中，并且可以包含在其它文件中。

表现(动作序列)可以包含在若干文件中，其优势成为段。时间和帧(位置和大小)信息通常在ISO基本媒体文件中，并且辅助文件可以实质上实现任何格式。针对包含该呈现的系统，该呈现可以是“本地的”，或者可以通过网络或其它流传送方案来提供该呈现。

可选的元数据频道可以用于利用其具有的“有趣特征”来标记每一频道，其中，其值可能与该组中其它成员不同(例如，其比特率、屏幕大小或语言)。频道内的一些样本可以具有特别的特征或可以单独被识别出。特征中的一个示例是同步点(经常是视频I帧)。这些点可以由每一频道内的特别表格来标识。更通常地，频道样本之间的从属本性也可以使用元数据来记录。可以将元数据构造为一系列的文件格式样本，就像视频频道一样。可以将这样的频道称为元数据频道。可以将每一元数据样本构造为元数据声明。存在于各种问题相对应的各种声明，上述问题可能是询问关于相应的文件格式样本或其组成样本的。

当通过流协议传送媒体时，媒体可能需要根据其在文件中表示的方式来转换。其一个示例是当通过实时传输协议(RTP)来发送媒体时。在该文件中，例如，将视频的每一帧连续地存储为文件格式样本。在RTP中，必须遵守特定于所使用的编码解码器的打包规则，以将这些帧放置在RTP包中。可以将流服务器配置成在运行时计算这样的打包。但是，存在对流服务器的辅助的支持。

本公开内容的技术可以适用于网络流协议，例如，HTTP流，例如，根据HTTP上的动态自适应流(DASH)。在HTTP流中，频繁使用的操作包括获取和部分获取。获取操作取回整个文件，在DASH的背景下，经常成为段，与给定的统一资源定位符(URL)或其它标识符例如URI相关联。部分获取操作接收字节范围作文输入参数，并取回与所接收的字节范围相对应的文件或段的连续数量的字节。从而，针对HTTP流可以提供电影片段，因为，部分获取操作可以获取在文件或段内的一个或多个单个电影片段。要注意的是，在电影片段中，可以存在不同频道的若干频道片段。在HTTP流中，媒体表现可以是结构化的数据集合，其包括表示客户端可获得用于播放的相关多媒体内容的时间线的一个或多个文件或片段。该客户端可以请求或下载媒体数据信息，以向用户呈现流服务。或者，可以使用诸如eMBMS之类的广播或多播协议来传送DASH段。

在使用HTTP流的流3GPP数据的示例中，可以存在针对多媒体内容的视频和/或音频数据的多个表现。可以在媒体呈现描述(MPD)数据结构中定义这样的表现的清单。媒体表现可以对应于HTTP流客户端设备可获得的结构化数据集合。HTTP流客户端设备可以请求和下载媒体数据信息，以向客户端设备的用户呈现流服务。可以在MPD数据结构中描述媒体表现，其可以包括MPD的更新。

多媒体内容可以包含一系列的一个或多个时段。可以利用MPD中的时段单元来定义时段。在MPD中，每一时段可以具有属性开始。对于每一个时段，MPD可以包含开始属性和可用的开始时间属性。对于直播服务，时段的开始属性和MPD属性可用的开始时间的和可以以UTC格式指定时段，特别是相应时段中的每一表现的第一媒体段。对于按需服务，第一个时段的开始属性可以是0。对于任何其它时段，开始属性可以指定相应的时段的开始时间相对于第一个时段的开始时间的时间偏移。每一时段可以扩展，直到下一个时段的开始，或者，在最后的时段的情况下，直到媒体呈现的结束为止。时段开始时间可以是精确的。其可以反映由播放所有先前时段的媒体所造成实际时间。

每一时段可以包含针对相同媒体内容的一个或多个表现。表现可以是多个可供选择的音频或视频数据的经编码的版本中的一个。表现可以在各个特征方面不同，如编码类型例如，比特率、分辨率、和/或用于视频数据和比率的编码解码器、语言、和/或用于音频数据的编码解码器。术语表现可以用来指代与多媒体内容的特定时段相对应并以特定方式编码的经编码的音频或视频数据的一部分。

可以向组、或自适应组分配特定时段的表现，其可以由MPD中的组或自适应集合属性来指示。相同的自适应组中的表现通常被认为可相互替代。例如，可以向相同的自适应组分配针对特定时段的每一视频数据表现，使得可以选择表现中的任何一个用于解码，以针对相应的时段显示多媒体内容的视频数据。在一些示例中，一个时段内的媒体内容可以由来自自适应组0(如果存在的话)中的一个表现或来自非零的每一自适应组的至少一个表现的组合来表示。可以相对于时段的开始时间来表达时段的每一表现的时间数据。

表现可以包括一个或多个段。每一表现可以包括初始化端，或表现的每一段可以是自行初始化的。当存在的话，初始化端可以包含用于访问表现的初始化信息。通常，初始化段不包含媒体数据。可以利用诸如统一资源定位符(URL)之类的标识符来唯一地标识段。MPD可以针对每一段提供标识符。在一些示例中，MPD还可以以范围属性的形式提供字节范围，其可以与针对利用URL或URI可访问的文件中的段的数据相对应。

每一表现还可以包括一个或多个媒体组件，其中，每一媒体组件可以与诸如音频、视频和/或有时限的文本(例如，用于隐藏字幕)之类的一个单独的媒体类型的编码版本相对应。媒体组件可以跨一个表现中连续的媒体端的边界在时间上持续。

典型地，符合DASH标准的段通常具有三个部分，包括(1)固定头部，(2)针对数据单元的指针表，以及(3)数据单元自身。在一个示例中，可以根据下文示出的表1来形成段：

表11–媒体数据的段

负责发送段的设备(例如，服务器设备)通常不能发送段头部，直到知道全部数据单元的大小，使得该设备可以适当地构造指针表。因此，服务器设备通常组装数据单元和指针，生成头部，并且将完全形成的段作为单个单元来发送。或者，响应于部分获取请求，服务器可以发送端的部分(例如，指定的字节范围)。但是，在本公开内容的技术之外，服务器设备将仅在该段已经完全形成之后接收部分获取请求，例如，在已经构造媒体片段随机访问(MFRA)盒之后，该MFRA盒通常放置在一个端的结束处。即，为了使客户端设备提交部分获取请求，客户端设备将需要访问MFRA盒的数据，或具有段的特定部分的位置的指示符的类似数据结构，例如，特定类型的网络提取层(NAL)的字节位置的指示，例如，即时解码器刷新(IDR)图像。

此外，接收媒体数据的段的设备(例如，客户端设备)通常不能处理段，直到已经接收到段头部和全部的数据单元。因此，客户端设备通常在解码和显示段之前，接收完全形成的段(例如，具有整个头部、指针表以及数据单元)。或者，如上文所解释的，客户端设备可以使用MFRA盒获取段的部分(例如，一个或多个指定的字节范围)。但是，再次，在本公开内容的技术之外，仅在已经完全形成该段之后才由客户端设备执行对段特定字节范围的访问。

在在通过网络发送该段之前形成整个段(并在解码之前接收)的示例中，在发送段和解码/播放段之间引入了一个段的延迟。即，服务器设备完全形成整个段，并向客户端设备发送该段。客户端设备接收完全形成的端，并使用头部数据和指针来解码及显示整个段。由于服务器设备形成整个段，并且客户端设备在播放之前接收整个段，因此，引入了整个段的延迟。

在一示例中，为了说明的目的，一段可以在播放时间中包含一秒的视频数据。即，服务器设备可以在一段中打包(例如，编码和封装)完整的一秒视频数据(即，当解码和播放时，数据的数量可以产生一秒的播放持续时间)，并向客户端设备发送该秒长的段。然后，客户端设备接收该秒长段的头部以及全部的数据单元，并在显示该段之前解码整个端。由于客户端设备不开始解码/播放直到已经接收到整个端，因此，可能引入了一秒的延迟。

本公开内容的方面通常针对减少与流式传送媒体数据的一个或多个段相关联的延迟。在一个示例中，本公开内容的技术包括最优化媒体数据的段的传输进度。即，根据本公开内容的方面，负责通过网络发送段的设备(例如，服务器设备，如下文针对图1更详细描述的)可以将媒体数据分成适合通过网络发送的多个段，其中，上述段无需独立可解码。

例如，上述段无需包括流接入点(SAP)，例如，即时解码器刷新(IDR)图像、干净的随机访问(CRA)图像、或与随机访问相关联的其它这样的图像。而是，段中的一个可以包括SAP，并且其它的段可以包括与SAP相关的经编码的视频数据，例如，直接与SAP相关或与其它相关于SAP的经编码的视频数据相关。因此，内容准备设备可以迅速地产生并发送段，而不在每个段中都包括SAP。以此方式，通过发送不包括SPA的段，根据这些技术编码的表现的比特率可以保持与表现的比特率基本相同，在表现中每一段包括SAP；但是，根据本公开内容的技术，因为上述段可以表现短得多的播放持续时间，所以可以减少延迟。

或者，段可以包括流接入点，但是不是在段的开始处。通常，为了允许随机访问，相关的文件可以指定在其处需要IDR图像的时刻。在由相关标准指定的时刻处出现的IDR图像可以被认为是“强迫IDR”图像。具体地，常规而言，这样的强迫IDR图像将在段的开始处出现(例如，按照解码顺序)，使得可以正确地解码段的全部图像。但是，本公开内容认识到，视频编码设备偶尔可以将非强迫的IDR图像插入段中，例如，以适应场景变化。即，视频编码器可以确定对与场景变化相对应的图像进行帧内编码比对该图像进行帧间编码更有益。本公开内容提出了将这样的场景变化IDR图像用作强迫IDR图像的替代或除了强迫IDR图像之外还使用这样的场景变化IDR图像。

即，当段对应于否则相关的标准将指示在段的开始处需要IDR图像(即，“强迫IDR”)的时刻时，根据本公开内容的技术的设备可以确定该段是否将在该段的其它处包括IDR图像(例如，场景变化IDR)。如果是这样的话，该设备可以省略强迫IDR，仅在该段中包含场景变化IDR。以此方式，针对该段的比特分配可以更有效，并且该段仍然可以有效地满足相关的标准，因为客户端设备可以从该段的场景变化IDR开始解码数据。此外，可以提供指示字节范围或字节偏移达到场景变化IDR的数据，使得客户端设备可以从场景变化IDR开始流，以避免获得在该场景变化IDR图像之前的段数据，否则这些数据可能不能解码(假定客户端设备从场景变化IDR开始)。

根据本公开内容的其它方面，子段可以包括子段头部和一个或多个数据单元。子段头部可以包括指向子段的数据单元的指针表。但是，如上文所描述，子段的数据单元可以指向先前的子段或未来的子段。例如，子段的数据单元可以包括参考先前或未来子帧的帧(或片)的P或B帧(例如，P或B片)。

在一些示例中，这样的子帧可能不能独立被解码。即，在没有另一子帧中包含的参考信息的情况下，一个子帧可能未必被解码，其可以对应于跟在先前子帧之后的子帧。换句话说，子帧可以指未来的子帧。但是，子帧可以包含可以独立被解码的某些信息。例如，子帧可以包含视频数据的可以独立被解码的一个或多个I帧。

根据本公开内容的方面，子段可以包含子段头部和一个或多个数据短语。子段头部可以包含指向子帧的数据单元的指针表。但是，如上文所记载的，子段的数据单元可以指先前的子段或未来的子段。例如，子段的数据单元可以包括参考先前的或未来的子段的帧(或片)的P或B帧(P或B片)。

在一些示例中，每一子段可以包含子段头部。例如，子段头部可以包含“固定”部分，例如视频/音频编码格式、质量级别等。在一些实例中，段的头部数据以及子段头部的数据在段和/或子段之间可能不改变。因此，在本公开内容的一些方面，服务器设备可以设置、以及客户端设备可以解释指示头部数据是否已经改变的标记的值。例如，服务器设备可以将标记设置为“0”以指示段或子段头部包含与先前的段或先前的子段基本类似或相同的数据。服务器设备可以将标记设置为“1”，以指示该段或子段头部已经改变。此外，客户端设备可以从一个段或其它段接收该标记，并解释头部数据是否从一个段到另一段改变。

生成视频数据的多个子段，并在这些子段一被形成/编码就发送它们可以减少延迟(例如，与在流环境中发送、接收、解码和/或显示媒体数据相关联的延迟)。例如，在接收子段之后，客户端设备可以立即开始对子段的至少一部分进行解码。即，虽然子段的某些数据单元可能参考了尚未接收到的其它子段的数据单元，但是，客户段可以立即开始对一些数据单元(例如，在子段中包含的I帧)进行解码。此外，在接收针对该段的头部之后，客户端设备准备对整个段进行解码并播放，上述头部通常跟在上述子段之后。

在一些实施例中，根据本公开内容的方面生成多个子段并在子段一形成时就发送其可能比简单地减少整个段持续时间更有效。即，在上文所提供的、为了说明的目的段可以包含一秒的视频数据的示例中，其可能引入一个完整秒的延迟。即，如果在发送之前完整地形成该段、并且在播放前完整地接收和解码该段，则可能引入一个完整秒的延迟。减少该延迟的一种方式可以是减少该段的整个持续时间。即，服务器设备可以编码和发送500毫秒的段，而不是编码和发送一秒的段。

但是，通过减少段持续时间来减少延迟，可能增加了比特流中开销数据的比例(例如，从而减少了效率)。例如，如上文所记载的，每一段包含头部，该头部包含固定的部分以及随着在段持续时间中产生的视频/音频采样的数量增加大小的部分。当段持续时间减少时，头部的固定的部分开始对与发送数据相关联的开销的较大部分(成比例的)起作用。在给定某一比特率的情况下，增加开销减少了整个效率，这是因为更少的比特可以用于实际的媒体数据。

此外，在一些示例中，可以构造媒体数据的段，以避免参考其它段。即，在一些示例中，多媒体内容的每一段不参考其它段的数据(例如，一个段的P帧或B帧不参考另一段的帧)，并且从而其可以被独立解码。因此，在这样的示例中，当减少段持续时间时，在减少P帧和B帧数量的同时增加了I帧的数量。例如，在比例上具有更多I帧的视频数据不向具有更大比例的P或B帧的视频数据那么多地利用时间冗余。因此，对于给定的平均速率，在I帧的数量和所显示的视频数据的感知质量之间可能是反比关系。即，已经使用可变比特率进行编码的视频数据可以比使用更稳定比特率进行编码的视频数据显示出更高的感知质量。

因此，可以使用本公开内容的方面来维持给定的段持续时间(具有给定速率)，同时还减少了延迟。即，在上文描述的一秒的段持续时间的示例中，本公开内容的方面涉及在维持一秒的段持续时间的同时还将与发送和解码/显示该段相关联的延迟减少至少于1秒。以此方式，可以在维持媒体数据的感知质量的同时，还减少延迟。

本公开内容的技术还可以用于根据DASH或通过广播网络传输的其它流网络协议来发送多媒体数据。例如，服务器设备可以准备具有多个子段的段，以通过广播向一个或多个客户端设备发送。如上文所描述的，在一些示例中，客户端设备可以接收包括段的子段的广播网络传输。

本公开内容还描述了其它用于减少延迟的技术。具体地，在一些示例中，本公开内容的技术提出了利用相对较短的段(在播放时间方面)，但是仅在段的子集中提供流接入点(SAP)。以此方式，可以在一形成段时就发送段，并且客户端设备可以在一接收到包含SAP的段时，就开始解码和显示段的数据。通常，SAP可以对应于随机接入点(RAP)，例如ITU-TH.264/AVC(高级视频编码)中的即时解码器刷新(IDR)图像。在一些示例中，还可以将开放解码器刷新(ODR)图像或干净随机访问(CRA)图像用作流接入点和随机接入点。

客户端设备还可以接收随后的段并且对这些随后的段的数据进行解码和显示，例如，利用先前的段的SAP的数据(或相对于SAP的其它编码的帧)来用于参考，上述随后的段不一定需要SAP。虽然不一定需要包含SAP，但是可以将上述段构造成具有常规段头部的常规段。或者，与本申请中描述的针对修改的段头部的技术相类似的技术(例如，指示头部数据是否已经改变的标记以及使用具有固定部分和变化部分的头部)也可以应用到可以包含或不包含SAP的表现中的段。此外，在一些示例中，可以相对于随后的段的数据来编码段的数据。

图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可以包括包含所存储的视频数据的计算机可读存储介质。以此方式，可以将本公开内容中所描述的技术应用于直播的、流式的、实时音频和视频数据或应用于已存档的、预先记录的音频和视频数据。

与视频帧相对应的音频帧通常是包含与由视频源24在捕获视频帧中包含的视频数据的同时由音频源捕获的音频数据的音频帧。例如，在说话参与者通常通过说话产生音频数据时，音频源22捕获音频数据，并且视频源24同时捕获说话参与者的视频数据，即，在音频源22正在捕获音频数据时。从而，音频帧可以在时间上对应于一个或多个特定的视频帧。因此，与视频帧相对应的音频帧通常对应于音频数据和视频数据同时被捕获的情形，并且针对该情形，音频帧和视频帧分别包括同时被捕获的音频数据和视频数据。

在一些示例中，音频编码器26可以在表现记录用于经编码的音频帧的音频数据的时刻的每一经编码的音频帧中编码时间戳，并且类似地，视频编码器28可以在表现记录用于经编码的视频帧的视频数据的时刻的每一经编码的视频帧中编码时间戳。在这样的示例中，与视频帧相对应的音频帧可以包括包含时间戳的音频帧和包含相同时间戳的视频帧。内容准备设备20可以内部时钟，音频编码器26和/或视频编码器28可以根据该内部实质生成时间戳，或者音频源22和视频源24可以利用时间戳来关联音频和视频数据。

在一些示例中，音频源22可以向音频编码器26发送与记录音频数据的时间相对应的数据，视频源24可以向视频编码器28发送与记录视频数据的时间相对应的数据。在一些示例中，音频编码器26可以在经编码的音频数据中编码序列标识符，以指示经编码音频数据的相关时间顺序，而无线指示记录音频数据的绝对时间，并且类似地，视频编码器也可以使用序列标识符来指示经编码视频数据的相关时间顺序。类似地，在一些示例中，可以使序列标识符与时间戳相映射或相关联。

音频编码器26通常产生经编码音频数据的流，而视频编码器28产生经编码视频数据的流。可以将数据的每一单个流(无论音频或视频)称为基本流。基本流是表现的单个的、经数字编码(可能被压缩)的组件。例如，表现的经编码的视频或音频部分可以是基本流。可以在将基本流封装在视频文件中之前，将其转换成打包的基本流(PES)。在相同的表现内，可以使用流ID来将属于一个基本流的PES分组与其它的区分开。基本流的基本数据单元是打包的基本流(PES)分组。从而，经编码的视频数据通常与基本视频流相对应。类似地，音频数据与一个或多个相应的基本流相对应。

与许多视频编码标准一样，H.264/AVC针对无误差比特流定义了语法、语义和解码过程，其中的任何一个符合某一简档或级别。H.264/AVC不指定编码器，但是编码器的职责是保证所生成的比特流是针对解码器标准兼容的。在视频编码标准的背景下，“简档”对应于算法、特征、或应用到其上的工具和限制。如由H.264标准所定义的，例如，“简档”是由H.264标准所指定的整个比特流语法的子集。“级别”对应于解码器资源消耗的限制，诸如例如解码器存储器和计算之类的，其与图形的分辨率、比特率和宏块(MB)处理率相关。可以利用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像素的子宏块划分的限制。以此方式，解码器可以确定解码器是否能够对该比特流进行准确解码。

诸如ITU-T H.261、H.262、H.263、MPEG-1、MPEG-2、H.264/MPEG-4部分10以及即将出现的高效视频编码(HEVC)标准之类的视频压缩标准使用运动补偿的时间预测来减少时间冗余。诸如视频编码器28之类的编码器可以根据运动向量，使用来自一些先前的编码图像(在本申请中也称为帧)的运动补偿预测来预测当前的编码图像。在典型的视频编码中存在三中主要的图像类型。它们是帧内编码图像(“I图像”或“I帧”)、预测图像(“P图像”或“P帧”)以及双向预测图像(“B图像”或“B帧”)。P图像可以使用按照时间顺序在当前图像之前的参考图像。在B图像中，可以从一个或两个参考图像预测B图像的每一块。可以按照时间顺序将这些参考图像放置在当前的图像之前或之后。

参数集通常在序列参数集(SPS)中包含序列层头部信息以及在图像参数集(SPS)中包含不频繁改变的图像层头部信息。利用参数集，该不频繁改变的信息无需针对每一序列或图像重复；从而，可以提高编码效率。此外，参数集的使用可以使得能够实现对头部信息的带外传输，避免了对需要冗余传输来实现错误恢复的需要。在带外传输中，在与其它NAL单元不同的信道上发送参数集NAL单元。

在图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)。在H.264/AVC(高级视频编码)的示例中，将编码的视频段组成到NAL单元中，其提供了诸如视频电话、存储器、广播或流之类的“网络友好的”视频表现寻址应用。可以将NAL单元分类成视频编码层(VCL)NAL单元和非VCL NAL单元。VCL单元可以包含核心压缩引擎并且可以包括块、宏块、和/或片级别数据。其它NAL单元可以是非VCL NAL单元。在一些示例中，可以在接入单元中包含通常被呈现为基本编码图像的一个时间实例中的编码图像，上述接入单元可以包含一个或多个NAL单元。

除了其它的以外，非VCL NAL单元可以包含参数集NAL单元和SEI NAL单元。参数集可以包含序列级别头部信息(在序列参数集(SPS)中)和频繁改变的图像级别头部信息(在图像参数集(PPS)中)。利用参数集(例如，PPS和SPS)，无需针对每一序列或图像重复频繁改变的信息，从而，可以提高编码效率。此外，参数集的使用可以使得能够实现对重要头部信息的带外传输，避免了对错误恢复的冗余传输的需要。在带外传输的示例中，可以在助理SEI NAL单元之类的不同于NAL单元的不同信道上发送参数集NAL单元。

补充增强信息(SEI)可能包含对来自VCL NAL单元的编码图像进行解码不是必要的、但是可能对与解码、显示、错误恢复以及其它目的相关的过程有帮助的信息。SEI消息是一些标准规范的规范的部分，从而对于标准兼容的解码器实现其并不总是强制的。SEI消息可以是序列级别SEI消息或图像级别SEI消息。在SEI消息中包含的一些序列级别信息，例如在SVC的示例中的可伸缩性信息SEI消息和在MVC中的视图可伸缩性信息。这些示例性的SEI消息可以传送关于例如操作点的提取和操作点的特征。此外，封装单元30可以形成清单文件，例如，描述表现的特征的媒体呈现描述符(MPD)。封装单元30可以更加可扩展的标记语言(XML)格式化MPD。

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

在一些示例中，根据本公开内容的某些技术，一个或多个表现68可以符合DASH低延迟直播简档。即，一个或多个表现68可以包含在段的开始处缺少流接入点的段。例如，一个或多个段可以完全没有流接入点，即，不包括任何流接入点。此外或可作为选择地，一个或多个段可以在不同于段的开始的位置处(按照解码顺序)包含流接入点。如下文更详细解释的，这可以允许形成段并从内容准备设备20和/或服务器设备60以减少的延迟向客户端设备40进行发送。

此外，符号DASH低延迟直播简档的表现的段可以比符合DASH直播简档的表现的段更短。即，DASH低延迟直播简档的段可以表现比由DASH直播简档的段所表现的播放时间段更短的一段播放时间。从而，可以形成DASH低延迟直播简档的段，并比DASH直播简档的段更快的发送，相对于DASH直播简档，其可以减少延迟。

在一些示例中，根据本公开内容的一些方面，封装单元30可以被配置成根据本申请中描述的技术形成时间的子段。即，例如，封装单元30可以被配置成将媒体数据的段分成多个子段。封装单元30可以在一形成子段时就向输出接口32提供子段。然后，输出接口32可以经由网络74向客户端设备40发送该子段。

在这样的示例中，封装单元30可以生成不是独立可解码的子段。即，封装单元30可以包括在没有另一子段中的参考信息的情况下不一定被解码的子段，其可以对应于跟在先前的子段之后的子段。换句话说，封装单元30可以形成参考未来子段的子段。

封装单元30可以生成应用于段的所有子段的段头部，以及用于段中包含的子段中的每一个的子段头部。如下文更详细描述的，子段头部可以包含标识子段内的数据单元的位置的指针表。此外，封装单元30可以设置指示段头部数据是否已经改变(例如，段头部数据是否与先前生成的段不同)的标记。

在一些示例中，可以将表现68分成自适应组。如上文记载的，在一些实例中，也可以将自适应组称为“表现组”。即，表现68的各种子集可以包括相应的特征公共集，例如，编码解码器、简档及级别、分辨率、视图的数量、段的文件格式、可以标识与例如要由扬声器解码和呈现的表现和/或音频数据一起显示的文本的语言或其它特征的文本类型信息、可以描述针对自适应集中的表现的场景的相机角度和现实世界相机透视的相机角度信息、描述针对特定观众的内容合适性的评级信息等。

清单文件66可以包含对与特定自适应集相对应的表现68的子集以及自适应集的公共特征进行指示的数据。清单文件66还可以包含针对自适应组的个体表现的、表现诸如比特率之类的个体特征的数据。以此方式，自适应组可以提供简化的网络带宽自适应。可以使用清单文件66中的自适应组单元的子单元来指示子适应组中的表现。

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

请求处理单元70被配置成从诸如客户端设备40之类的服务端设备接收针对存储介质62的数据的网络请求。例如，请求处理单元70可以实现超文本传输协议(HTTP)版本1.1，如在RFC2616中、在1999年6月由IETF网络工作组的R.Fielding等所著的“超文本传输协议-HTTP/1.1”中所描述的。即，请求处理单元70可以被配置成接收HTTP获得或部分获得请求，并响应于上述请求提供多媒体内容64的数据。上述请求可以例如使用段的URL来指定表现68中能的一个的段。在一些示例中，上述请求还可以指定段的一个或多个字节范围，从而包含部分获得请求。请求处理单元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，其可以与媒体呈现描述(MPD)相对应。清单文件66可以包含对不同的可供选择的表现(例如，具有不同质量的视频服务)的描述，并且该描述可以包含例如，编码解码器信息、简档值、级别值、比特率以及表现68的其它描述性特征。客户端设备40可以获得媒体呈现的MPD，以确定如何访问表现68的段。

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

获取单元52可以将客户端设备40的解码和提交能力与由清单文件66中的信息所指示的表现68的特征进行比较。获取单元52可以初始获取清单文件66的至少一部分，以确定表现68的特征。例如，获取单元52可以根据本公开内容的技术请求描述了一个或多个自适应组的特征的清单文件66的一部分。获取单元52可以选择表现68(例如，子适应组)的子集，该子集具有可以由客户端设备40的编码和提交能力所满足的特征。然后，获取单元52可以针对自适应组中的表现来确定比特率，确定目前可用的网络带宽量，并从具有可以由网络带宽所满足的比特率的表现中的一个获取段。

通常，当可用的网络带宽降低时，较高比特率的表现可以生成较高的质量视频播放，而较低比特率的表现可以提供足够质量的视频播放。因此，当可用的网络带宽相对高时，获取单元52可以从相对高的比特率表现获取数据，而当可用网络带宽低时，获取单元52可以从相对低的比特率表现获取数据。以此方式，客户端设备40可以通过网络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中的每一个，可以将其中的任何一个集成为组合的视频编码器/解码器(编码解码器)的一部分。同样地，可以在一个或多个编码器或解码器中包含音频编码器26和音频解码器46中的每一个，其中的任何一个可以集成为组合的编码解码器的一部分。包含视频编码器28、视频解码器48、音频编码器音频编码器26、音频解码器46、封装单元30、获取单元52、和/或解封装单元50的装置可以包括集成电路、微处理器、和/或诸如蜂窝电话之类的无线通信设备。

本公开内容的方面通常针对最小化与通过网络74从服务器设备60到客户端设备40流式传送一个或多个媒体数据段相关联的延迟。即，根据本公开内容的方面，服务器设备60可以将媒体数据段分成适合通过网络74发送的多个子段。在该示例中，服务器设备60可以在子段一形成时就发送该子段。即，服务器设备60无需在发送子段之前等待形成超过一个子段。此外，服务器设备60无需在发送子段之前等待生成针对全部子段的头部数据。

应该理解的是，诸如子段信息和/或传输之类的属于服务器设备60的某些功能可以由一个或多个其它组件或设备执行。即，在另一示例中，内容准备设备20可以负责形成和通过网络74发送子段。此外或者可供选择的，根据一些示例，内容准备设备20和服务器设备60可以高度集成或并入到同一设备。从而，内容准备设备20、服务器设备60或者这样的设备的组合可以准备并在一形成子段时就向诸如客户端设备40之类的客户端设备发送子段。此外，可以以广播或多播网络传输来发送子段。

客户端设备40可以被配置成接收已经根据本公开内容的方面形成的子段，以及对该子段的至少一部分立即开始解码。即，虽然子段的某些数据单元可能参考尚未接收到的其它子段的数据单元，但是，客户端设备40可以立即开始对数据单元中的一些(例如，子段中包含的I帧)进行解码。此外，客户端设备40准备在接收到针对该段的头部之后对整个段进行解码和播放，该头部通常跟在子段之后。即，客户端设备40通常在接收到针对段的头部之前，接收到该段的所有子段。

生成视频数据的多个子段并在它们一被编码时就发送子段可以减少与服务器设备60发送段以及客户端设备40接收、解码和/或显示段相关联的延迟。

同样地，在其它示例中，生成相对短的段也可以减少与发送段相关联的延迟。如本申请中讨论的，在自适应组的表现中，与这些段相对应的呈现时间可以是固定的，但是，每一个段不一定需要包括SAP。根据本公开内容的某些技术，内容准备设备20可以获得直播媒体内容，即，记录实时发生的事件的音频和/或视频内容、对该记录的内容进行编码、准备所记录的内容以进行网络传输，并向服务器设备60发送所记录的内容。或者，内容准备设备20可以直接向客户端设备40传送该内容。在任何情况下，内容准备设备20可以至少形成不包含SAP的段。

如上文所讨论的，内容准备设备20可以被配置成通过形成具有比常规段更短的时间长度的段来减少与广播或多播网络传输相关联的延迟。例如，内容准备设备20可以形成仅表现一秒播放时间的段，而常规段可以包含表现十秒播放时间的视频数据。即，当以相应的帧速率进行解码和呈现时，这些段中包含的视频数据可以与一秒的播放时间相对应。例如，如果相应的帧速率是30帧每秒，则由内容准备设备20所形成的段可以包括用于30帧视频数据的数据以及相应数量的音频数据。作为另一个示例，如果相应的帧速率是60帧每秒，则内容准备设备20可以形成包含表现60帧视频数据的编码视频数据以及相应的音频数据的段。这与表现例如十秒播放的段形成对比，在上文讨论的示例中，表现十秒播放的段分别包括表现300帧和600帧视频数据的经编码的数据。

通过减少每一段所表现的播放持续时间，内容准备设备20可以比在段表现更长的播放持续时间的情况下更快地向例如服务器设备60或客户端设备40发送完全形成的段，尤其是，当记录直播事件时。此外，因为每一段无需包含SAP，则包含更短段(即，表现相对短播放持续时间的段)的比特流可以与包含更长段的比特流具有基本上相似的比特率。以此方式，这些技术可以提供与减少延迟即在由内容准备设备20记录的事件的发生与客户端设备40的观众能够观看与该事件相对应的播放的时间之间所经过的时间量相关的优点。

以此方式，内容准备设备20和服务器设备60表现用于发送多媒体数据的设备的示例，该设备包括一个或多个处理器，其被配置成：获得媒体数据的第一段，其中，第一段的媒体数据包括第一流接入点；向客户端设备发送第一段；获得媒体数据随后的第二段，其中，第二段的媒体数据在第二段的开始处缺少流接入点，并且其中，第二段的媒体数据的至少一部分是相对于第一段媒体数据的一部分进行编码的，并且在第二流接入点之前在第一流接入点之后可用；向客户端设备发送第二段。

同样地，客户端设备40表现用于接收媒体数据的设备的示例，该设备包括一个或多个处理器，其被配置成：接收媒体数据的第一段，其中，第一段的媒体数据包括第一流接入点；接收媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处缺少流接入点，并且在第二流接入点之前，在第一流接入点之后可用；相对于第一段媒体数据的至少一部分对第二段媒体数据的指示一部分进行解码。

在这些示例中，第一段可以包括完成形成的DASH段(或其它媒体文件)，其包含流接入点，例如即时解码器刷新(IDR)图像、干净随机访问(CRA)图像等(例如，然后帧内编码图像(I图像))。第二段还可以包括完全形成的DASH段，其不包含这样的流接入点。以此方式，可以相对于第一段的一部分对第二段的一部分进行编码(例如，编码或解码)。例如，第二段中的一个或多个图像可以相对于诸如流接入点或相对于该流接入点编码的图像之类的第一段的图像进行帧间预测模式编码。以此方式，第二段的一个或多个图像可以使用第一段的一个或多个图像作为参考图像。

以此方式，第二段无需包括流接入点。虽然这可能使得第二端不能独立被解码(由于参考第一段)，但是，这也允许第一段更快地被编码、封装以及发送，从而减少了延迟(即，在时间发生时与客户端40的用户能够观看该事件时之间的延迟)。例如，内容准备设备20和/或服务器设备60可以在获得足够的第二段的数据之前，例如，在对第二段进行捕获、编码和封装之前，发送第一段。

应该理解的是，上文所使用的术语“第一”和“第二”意在作为名义上的参考，而不作为顺序上的参考。即，“第一段”无需在实际上为多媒体数据的顺序上的第一段，而可以是多媒体段的包含流接入点的任何段。同样地，第二段无需紧跟在第一段之后，而是与包含相对于第一段的一部分进行编码的部分、按照解码顺序在第一段之后的任何段相对应。第一和第二段可以但无需表现相同的播放持续时间，例如，大约一秒的播放时间(其也称为呈现时间)。

图2是示出与获取单元52相关联的示例性组件的框图。图2中的获取单元52可以与获取单元52(图1)相对应，或包含在另一不同的获取单元中。在该示例中，获取单元52包含流管理单元80和源组件90。源组件90包括：媒体文件存储处理单元92、MPD解析单元94、媒体文件解复用(demux)单元96、以及自适应单元98和HTTP控制器100。

通常，获取单元52可以包括用于使用特定通信协议进行通信或与特定物理介质进行交互的硬件和/或软件。例如，获取单元52可以使用HTTP栈来实现HTTP和接收数据，其可以包含TCP/IP以及用于网络的其它层的其它通信协议。获取单元52可以进一步针对来自例如服务器设备60的段(或段的部分)生成HTTP获得或部分获得请求。获取单元52还可以实现广播或多播协议，例如，eMBMS或IP多播，以从广播或多播网络传输接收数据。获取单元52可以被配置成订制广播或多播网络传输，以获取传输的数据。

源组件90可以从一个或多个源接收多媒体内容的数据。初始地，源组件90可以接收诸如MPD文件之类的清单文件。MPD解析单元94可以解析MPD文件，以确定多媒体内容的可用表现、以及包括具有公共特征的表现组的自适应集、以及表现的特征。偶尔地，源组件90可以接收针对当前多媒体内容的更新的MPD，在该情况下，MPD解析单元94可以对更新的MPD进行解析，并向流管理单元80提供更新的信息。在一些示例中，源组件90可以选择表现中的至少一个，而在其它示例中，源组件90可以向流管理单元80提供表现信息。在这样的示例中，流管理单元80可以选择表现中的至少一个。在任何情况下，源组件90可以向流管理单元80发送请求，以发送用于获取多媒体内容的数据的下载信息。

流管理单元80可以被配置成从其处获取所选择的表现的数据的源。在一些示例中，流管理单元80可以接收某些通知，上述通知指示流管理单元80要选择从其处获取数据的特定源。例如，帧HTTP传输，HTTP接收机和栈可以向流管理单元80提供所估计的可用网络带宽的量。广播接收机和栈可以提供对与所选择的表现相对应的广播传输的URL是否可用以及该广播是否在范围内进行指示的指示。本地存储设备可以提供对URL是否可用于与所选择的表现相对应的本地存储的数据的指示。此外，流管理单元80可以从诸如客户端设备40之类的无线设备的一个或多个无线电设备接收无线信号强度信息(RSSI)，以确定无线信号的强度，例如，用于接收网络数据。

流管理单元80可以分析所接收的源通知，以选择从其处要获取多媒体内容的数据的源中的一个或多个。在一些示例中，流管理单元80还选择多媒体内容的表现。流管理单元80可以从源组件90接收信息，例如从MPD文件中提取的表现特征和表现的段的URL。该信息还可以包括对缓存占用量和/或可用的空间以及多媒体内容的当前播放时间的指示。使用该信息，与所接收的源通知一起，流管理单元80可以选择从其处要获取多媒体内容的数据例如当前选择的表现的数据的源。流管理单元80可以随着时间针对相同的多媒体内容在表现和/或从其处要获取表现的数据的源之间自适应地切换。

流管理单元80可以向源组件90提供对所选择的源(以及在一些情况下，所选择的表现)的指示。此外，流管理单元80可以形成下载命令，该下载命令包括用于从所选择的源获取所选择的表现的数据的信息。例如，下载命令可以包括对源类型和特定源的信息的指示。例如，对于HTTP/1.1，下载命令可以指定要在获得或部分获得命令中包含的所选择的表现的段的URL的完整路径。作为另一示例，对于广播或多媒体网络传输，下载命令可以指定广播或多播组的网络地址，以接收所选择的表现的段。以此方式，流管理单元80可以基于从流组件90接收的信息和/或其它所接收的信息，确定从其处要获取数据的适当的源以及要接收的表现的适当的段。

源组件90可以基于从流管理单元80接收的下载命令信息，形成用于从所选择的源获取所选择的表现的数据的适当的命令。例如，源组件90可以生成HTTP获取或部分获得请求，用于加入广播或多播组的请求，或用于获取本地存储介质的数据的请求。

在图2的示例中，源组件90包括媒体文件解复用(demux)单元96，其可以将所接收的数据解复用成相应的音频和视频流。媒体文件存储处理单元92可以在包括获取单元52的设备的存储器(未示出)中缓存所接收的数据。媒体文件存储处理单元92还可以向例如音频解码器46和视频解码器48(图1)提供经过解复用的数据。或者，媒体文件存储处理单元92可以在不解复用数据的情况下，向客户端设备40提供所获取的媒体数据。

相应地，获取单元52可以被配置成根据不同的通信协议操作。例如，获取单元52可以包括被配置成根据传输控制协议/互联网协议(TCP/IP)操作的网络接口。相同的网络接口(例如，网络接口的不同单元)、或不同的接口可以被配置成根据IP多播或eMBMS、或其它广播或多播网络协议来接收数据。获取单元52的另外的接口可以被配置成从物理介质接收数据。这样的接口可以包括通用串行总线(USB)接口、DVD阅读器、蓝光播放器、或用于从物理介质获取数据的其它这样的接口。

在获取单元52在其中根据HTTP接收数据的示例中，自适应单元98可以与HTTP控制器100通信，以执行带宽自适应。例如，自适应单元98可以与HTTP控制器100通信，并从多媒体内容的清单文件中选择从其处要获取多媒体内容的多媒体数据的表现。清单文件可以包括对多媒体内容的多个表现以及可能包含所选择的表现的多个表现进行指示的信息。具体地，清单文件可以包含描述表现的比特率的信息，使得自适应单元98可以鉴于当前可用的网络带宽量，基于表现的比特率，选择适当的表现。当然，应该理解的是，如上文所解释的，流管理单元还可以被配置成选择表现而不是源组件。此外，在一些示例中，源组件90和流管理单元80可以是功能集成的。

根据本公开内容的技术，源组件90可以被配置成接收广播或多播网络数据。例如，源组件90可以通过媒体文件存储处理单元92将根据广播或多播接收的数据缓存在存储器(未示出)中。自适应单元98可以确定从其处要获取随后的段的源，例如，基于所测量的带宽来确定，以及确定与所缓存的数据相对应的源的带宽实际上是无限的，从而，确定要从缓存获取数据。通过广播或多播接收的数据可以包括包含流接入点、表现编码的视频数据的第一段，以及在第二段的开始处缺少流接入点、表现编码的视频数据的第二段。媒体文件解复用单元96可以将第一和第二段解复用成相应的媒体流，例如，打包的音频或视频基本流，并且分别向音频解码器46和视频解码器48提供这些基本流的分组。

图3是示出示例性多媒体内容102的单元的示意图。多媒体内容102可以与多媒体内容64(图1)或在存储器62中存储的另一媒体内容相对应。在图3的示例中，多媒体内容102包括媒体呈现描述(MPD)104和多个表现110-120。表现110包括可选的头部数据112和段114A-114N(段114)，而表现120包括可选的头部数据122和段124A-124N(段124)。为了方便起见，字母N用于指定表现110、120中的每一个中的最后的电影片段。在一些示例中，在表现110、120之间可能存在不同数量的电影片段。

MPD104可以包括与表现110-120相分离的数据结构。MPD104可以与图1中的清单文件66相对应。同样地，表现110-120可以与图1中的表现68相对应。通常，MPD104可以包括通常描述表现110-120的特征的数据，上述特征诸如为编码和提交特征、自适应组、与MPD104对应的简档、文本类型信息、相机角度信息、评级信息、技巧模式信息(例如，对包括时间子序列的表现进行指示的信息)、和/或用于获取远程时段的信息(例如，用于在播放期间将目标广告插入媒体内容)。

当存在头部数据112时，其可以描述段114的特征，例如，随机接入点的暂时位置(RAP，其也称为流接入点(SAP))、段114中的哪一个包括随机接入点、相对于段114内的随机接入点的字节偏移、段114的统一资源定位符(URL)、或段114的其它方面。当存在头部数据122时，其可以描述段124的类似特征。另外地或可供选择地，可以在MPD104中完全包含这样的特征。

段114、124包括一个或多个编码的视频样本，其中的每一个可以包括视频数据的帧或片。段114的编码的视频样本中的每一个可以具有类似的特征，例如，高度、宽度和带宽需求。可以由MPD104的数据来描述这样的特征，虽然这样的数据在图3的示例中未示出。MPD104可以包括由3GPP规范描述的特征，外加本公开内容中描述的所发送的信息中的任何一个或全部。

段114、124中的每一个可以与唯一的统一资源定位符(URL)相关联。从而，可以使用诸如DASH之类的流网络协议独立获取段114、124中的每一个。以此方式，诸如客户端设备20之类的目标设备可以使用HTTP获得请求来获取段114或124。在一些示例中，客户端设备40可以使用HTTP部分获得请求来获取段114或124的特定字节范围。

根据本公开内容的一些方面，还可以进一步将段114、124中的每一个分成多个子段，如针对图4所示出和描述的。如上文所描述的，在已经完全形成多媒体内容102之后，在一些示例中，头部数据112、122可以包括针对诸如IDR NAL单元之类的特定NAL单元的指针。但是，根据本公开内容的技术，当一旦准备好了子段就发送表现110、120的字段时，应该理解的是，头部数据112、122可能不可用，直到已经完全形成了段114、124之后为止。然而，如本公开内容所讨论的，可以在头部数据112、122可用之前，发送段114、124的子段的数据。

在其它示例中，段114、124中的每一个可以包括常规的段头部，而不将其分成子段。但是，段114、124中的一个或多个不一定需要包括随机接入点，其也称为流接入点(SAP)。客户端设备(如图1中的客户端设备40)可以被配置成在包括SAP的段处接收表现110-120中的一个的数据，但是，该表现的一个或多个随后的段不一定需要包括SAP。例如，客户端设备可以提交加入多播组的请求，并在提交该请求之后，接收包括SAP的段(例如，第一段)。客户端设备还可以接收跟在第一段之后的多播组的另一段(例如，第二段)，但是第二段无需包括SAP。相反，第二段可以包括相对于第一段进行编码的至少一些数据。

例如，假定段114A包括SAP，但是段114B不包括(即，缺少)SAP。具体地，在该示例中，段114B完全没有SAP。客户端设备(图1)可以在段114A处开始接收表现110的数据，并在段114A的SAP处开始对数据解码。客户端设备40还可以获取段114B，例如，在对段114A的数据解码时。在这样的示例中，表现的段可以表现相对段的播放时间段(例如，一秒的播放时间)。

内容准备设备20可以构造表现110-120，使得在自适应集中的癌变110-120中，可以对其SAP。在各自适应集中，SAP不一定需要以相同的频率出现，但是可以对齐。例如，可以构造表现110在一秒的时间间隔处包括SAP，而可以构造表现120在两秒的时间间隔处包括SAP，其中，时间间隔与呈现时间相对应。假定在同一个自适应集中包括表现110和120，则段114A和124A可以以SAP开始，段114B可以包括SAP，而段124B无需包括SAP。跟在段114B之后的段(例如，段114C，图3中未示出)也可以包括SAP，并且跟在段124B之后的段(例如，段124C，图3中也未示出)可以包括SAP。在其它示例中，可以对齐在同一自适应组中的表现的所有SAP，使得在每一表现中以相同的频率出现SAP(即，在播放时间方面，具有相同的时间长度)，以及相位对齐，使得在同一自适应集的每一个表现中SAP在相同的呈现时间处出现。

构造相同自适应集的表现使得SAP在这些表现中对齐可以提供某些优点。例如，这样的表现可以提供无缝和简单的速率自适应能力。此外，对齐同一自适应集的表现中的SAP可以避免视频编码质量的降低。

此外，内容准备设备20可以在连续的SAP之间提供可变的时间。取决于内容的SAP定位可以产生相对高质量的视频，并且可以提供更好的压缩特征。内容准备设备20可以被配置成在连续的SAP之间具有最大的分离时间。此外，内容准备设备20可以在连续的SAP之间，例如，在MPD104或诸如头部数据112、122之类的表现头部数据中发送该最大的时间。

在一些示例中，段114、124中的每一个可以具有固定的持续时间。在这样的示例中，段114、124不一定需要以SAP开始。在这样的示例中，段114、124中的每一个可以表现相同数量的呈现时间，例如，一秒(或其它适当的呈现时间)。这样示例还可以提供某些优点。例如，假定根据播放时间可以以自动的方式生成段的URL，则用于预测段URL的过程可以相对简单。最后，可能需要更少的段。在另一方面，内容准备设备20可以提供段索引，以在自适应集的表现之间进行切换。

图4是根据本公开内容的一方面，示出示例性段200的示意图。段200可以与图3中示出的段114和/或124相对应，并且可以包括多媒体内容64(图1)的至少一部分或存储器62中存储的其它多媒体内容。虽然可能针对图1中示出的组件描述图4的某些方面，但是，应该理解的是，可以在具有多个不同组件的多个不同环境中实现段200。

在图4的示例中，段200包括段头部202、子段204A、子段204B(统称为子段204)以及潜在的多个另外的子段(由省略符号指示)。根据本公开内容的方面，段头部202可以包括为段200的全部子段204所共有的信息。例如，段头部202可以在解码和/或提交段200中包含用于辅助诸如客户端设备40之类的设备的某些信息。即，段头部202可以包括对用于段200的音频数据的编码格式、用于段200的视频数据的编码格式、用于段200的比特率、用于段200的质量级别、段200的视频数据的分辨率、段200的视频数据的帧速率等进行指示的数据。根据本公开内容的一些方面，如下文所描述的，可以在子段头部中包含这样的数据的一部分。在一些示例中，在已经发送了所有子段204之后，发送段头部202。在其它示例中，在已经发送子段204之前，发送段头部202。

在一些示例中，根据本公开内容的方面，段头部202可以包括指示段头部202的数据是否已经改变的标记。即，段头部标记可以指示段头部202的数据是否已经从先前接收的并解码的段头部改变。诸如服务器设备60之类的设备可以将段头部标记设置为“0”，以指示段头部202的数据尚未改变，并且可以将段头部标记设置为“1”，以指示段头部的数据已经改变。在头部数据尚未改变的情况下(标记＝0)，服务器设备60可以省略在段头部202中包含额外的信息。或者，在头部数据已经改变的情况下(标记＝1)，服务器设备60可以在段头部标记之后包含头部数据。

在图4中示出的示例中，子段204A包括具有数据单元指针208A和208B(统称数据单元指针208)的子段头部206，其中，数据单元指针208A和208B分别标识数据单元210A和210B(统称数据单元210)的相对位置。在一些示例中，子段头部206可以包括上文针对段头部202描述的数据的一部分。但是，在子段头部206中通常不包括不频繁改变的数据(例如，编码格式)。

根据本公开内容的一些方面，子段头部206包括用于对子段204A中的数据单元210中的每一个的偏移进行标识的数据单元指针208的表。例如，该偏移可以提供在子段204A内数据单元的相对位置。该偏移还可以提供对用于呈现数据单元的解码数据的适当顺序的指示(虽然，在一些示例中，可以能不按呈现/显示顺序来编码和发送数据单元)。

数据单元210通常包括非VCL NAL单元或VCL NAL单元，其可能包括编码的媒体数据。在媒体数据是视频数据的示例中，数据单元210可以包括视频数据的帧或片。根据本公开内容的方面，诸如子段204A之类的子段可能不能被独立解码。例如，数据单元210中的一个或多个可以指在一个或多个其它子段中包含的一个或多个数据单元(例如，诸如子段204B的数据单元216之类的)。即，在数据单元210包括视频数据的示例中，可以将数据单元210中的一个或多个编码为参考在一个或多个其它子段中包含的一个或多个数据单元的视频数据的P帧或B帧。从而，在一些示例中，数据单元210中的一个或多个可以指未来的子段(例如，B帧)。但是，数据单元210还可以包含可以独立被解码(例如，不参考其它子段)的某些信息。例如，数据单元210中的一个或多个可以是可以独立被解码的视频数据的I帧。

在图4中示出的示例中，子段204被配置成类似于子段204A。即，子段204B包括：具有标识数据单元216A和216B的数据单元指针214A和214B的子段头部212。在一些示例中，根据本公开内容的方面，类似于上文描述的段头部202，子段204可以包括对子段头部206、212的数据是否已经改变进行指示的标记。在图4中示出的示例中，子段头部212可以包括对先前接收的子段头部206的数据是否已经改变进行指示的标记(例如，标记＝0，数据尚未改变标记＝1，数据已经改变)。因此，在子段头部数据不改变的示例中，可以减少头部数据所消耗的比特数量。

根据本申请中描述的技术使用段200可以导致延迟减少(例如，与不包含多个子段的段相比)。即，根据本公开内容的方面，诸如服务器设备60或内容准备设备20(或实现服务器设备60和内容准备设备20两者的功能的设备)之类的负责通过网络发送段的设备可以在一形成子段204A(例如，一接收/编码子段204A的最后一个数据单元)时就发送子段204A。即，服务器设备60无需在发送子段204A之前等待形成多个子段。此外，服务器设备60无需在发送子段204A之前等待完成子段头部202。

在一形成/编码子段204时就发送子段204可以减少延迟，这样因为诸如客户端设备40之类的客户端设备可以在接收子段204之后立即开始对子段204的至少一部分进行解码。即，在图4中示出的示例中，虽然子段204A的某些数据单元210可以参考子段204B的数据单元216的一个或多个，客户端设备可以立即开始对子段204A的数据单元210中的一些(例如，子段204A中包含的I帧)进行解码。此外，客户端设备40在接收到针对段200的段头部202之后，准备对整个段200进行解码和播放，这通常在子段204A、204B之后。即，客户端设备已经接收到子段204A和204B，并且准备在接收到段头部202之后，立即开始解码。

根据本公开内容的技术，在一示例中，可以根据下面示出的表2来安排段200：

表2–具有子段的段头部

根据本公开内容的一些方面，段200可以被配置用于通过广播网络传输根据DASH或其它流网络协议来发送多媒体数据。例如，服务器设备60可以准备具有多个子段204的段200，以通过广播向一个或多个客户端设备40传输。如上文所讨论的，在一些示例中，客户端设备40可以接收包括段200的子段204的广播网络传输。

虽然图4示出了子段204A和204B被类似地配置，但是，应该理解的是，在一些示例中，表现的段可以不包括被类似配置的段。例如，表现可以包括已经被分成子段的一个或多个段以及未被分割的一个或多个子段。

图5是示出根据本公开内容的技术的示例性方法的流程图。虽然针对内容准备设备20和客户端设备40(图1)来描述图5中的方法，但是，应该理解的是，其它的设备也可以实现类似于图5中的方法中的那些技术。例如，服务器设备60、或内容传送网络中的一个或多个网络设备可以执行属于服务器设备60的功能中的一些或全部。

最初，内容准备设备20(通常，因为其可以向客户端设备提供内容，可以将其称为“服务器设备”)可以获得多媒体内容的表现的数据(260)。更具体地，内容准备设备20可以获得多媒体内容的给定表现的媒体数据段。根据将本公开内容的一些方面，内容准备设备20可以生成对与该媒体数据段相关联的头部数据是否已经改变进行指示的标记(261)。即，内容准备设备20可以指示该段的头部数据是否与先前编码的段(如果这样的段存在)的头部数据不同。内容准备设备20可以将段头部标记设置为“0”值，以指示头部数据未改变，或可以将段头部标记设置为“1”值，以指示头部数据不同(例如，然后是适当的头部数据)。

然后，内容准备设备20可以形成第一子段(262)。例如，内容准备设备20可以形成类似于图4中示出的子段204的子段，其具有子段头部，该子段头部包含对第一子段中包含的一个或多个数据单元进行标识的数据单元指针。此外，如上文所记载的，该子段可能不能被独立解码。即，第一子段可能包含参考一个或多个其它子段(以及未来的子段，诸如下文描述的第二子段)的一个或多个数据单元的一个或多个数据单元。

一旦形成了，内容准备设备20就相客户端设备40发送第一子段(264)。根据本公开内容的一方面，内容准备设备20可以广播该第一子段(以及随后的子段)。在内容准备设备20已经发送第一子段之后，客户端设备40接收第一子段(266)。在一些示例中，客户端设备40可以准备第一子段以进行解码(268)。例如，客户端设备40可以缓存或准备第一子段，以进行解码，使得第一子段可以在接收到子段头部数据之后立即被解码。

此外，内容准备设备20形成第二子段(272)。可以以与上文描述的第一子段类似的方式来形成第二子段。在形成之后，内容准备设备20可以向客户端设备40发送第二子段(具有子段头部数据)(274)。然后，客户端设备40接收第二子段(276)。在一些示例中，客户端设备40可以以与上文所描述的针对第一子段的相类似的方式来准备第二子段以进行解码。

在形成并发送第二子段之后，内容准备设备20可以形成适用于全部子段(例如，在图5中示出的示例中，第一和第二子段)的段头部(280)。内容准备设备20还可以向客户端设备40发送段头部(282)。然后，客户端设备40可以接收段头部(284)并解码第一和第二子段(286)。即，客户端设备40可以先前接收的子段中的每一个进行解码。

以此方式，图5中的方法表现包括接收多媒体数据的段的第一子段的方法的示例，其中，第一子段包括第一组的一个或多个数据单元，并且第一头部包含对第一子段中的数据单元位置进行指示的数据，其中，数据单元中的至少一个子段的第二子段中的数据单元。该方法还包括，在接收第一子段之后，接收第二子段，第二子段包括第二组的一个或多个数据单元，并且第二头部包含对第二子段内的数据单元的位置进行指示的数据，并在接收第一子段和第二子段之后处理该段。

此外，图5中的方法表现包括发送多媒体数据的段的第一子段的方法的示例，其中，第一子段包括第一组的一个或多个数据单元，并且第一头部包含对第一子段内的数据单元的位置进行指示的数据，其中，数据单元中的至少一个指该段的第二子段的数据单元。该方法还包括，在发送第一子段之后，发送第二子段，第二子段包括第二组的一个或多个数据单元，并且第二头部包含对第二子段内的数据单元的位置进行指示的数据。

应该理解的是，针对图5所示出和描述的步骤仅作为一个示例来提供。即，图5中的方法的步骤不一定需要以图5中示出的顺序来执行，并且可以执行更少的、额外的或其它的步骤。在一示例中，针对图5所示出和描述的方法包括第一和第二子段。但是，在其它示例中，服务器设备可以准备(并且客户端设备可以接收)超过媒体数据的两个子段。

如上文所讨论的，在一些示例中，子段可以用于减少端到端延迟。在其它示例中，可以使用完整的段，但是一个或多个段无需包含流接入点(SAP)。SAP通常是比特流中点，在该点处，诸如客户端设备40(图1)之类的客户端设备可以开始获取比特流，并成功地对所获取的数据进行解码和提交。以此方式，SAP可以包括与文件的随机接入点(RAP)相类似的数据，上述文件诸如为根据ISO基本媒体文件格式及其扩展之类的文件。SAP可以包括用于VCL层的IDR图像的数据。根据本公开内容的技术的一些示例，表现的一个或多个段可以包括完整的、常规的段头部，然而无需包括相应的SAP。

图6是示出一系列编码的视频帧300-332的示意图。图6还指示了在段334中包含帧300-316，而在该示例中，在段336中包含帧318-332。对帧使用不同的阴影，以指示在分层的预测结构内的相关位置。例如，帧300、316和332的阴影是黑色的，以表示帧300、316和332是在分层的预测结构的顶部。帧300、316、332可以包括，例如，帧内编码的帧，或根据单个方向中的其它帧预测的帧间编码的帧(例如，P帧)。当帧内编码时，仅根据同一帧内的数据预测帧300、316、332。当帧间编码时，例如，帧316可以相对于帧300的数据进行编码，如由从帧316到镇00的虚线箭头所指示的。

帧308、324是深色的阴影，以指示在编码层级中他们是跟在帧300、316和332之后的下一个。帧308、324可以包括双向的、帧间模式预测编码的帧。例如，帧308可以根据帧300和316的数据来预测，而帧324可以根据帧316和332来预测。

帧304、312、320和328是浅色阴影，以指示在编码层级中它们是跟在帧308和324之后的下一个。帧304、312、320和328也可以包括双向的、帧间模式预测编码的帧。通常，在编码层级中较低的帧可以相对于在编码层级中较高的帧中的任何一个进行编码，只要上述帧仍然存储在参考帧缓存器中。例如，可以根据帧300和308来预测帧304，可以根据帧308和316来预测帧312，可以根据帧316和324来预测帧320，以及可以根据帧324和332来预测帧328。此外，应该理解的是，也可以根据帧300和帧316来预测帧304的块。同样地，应该理解的是，可以根据帧300和316来预测帧312的块。

帧302、306、310、314、318、322、326、和330是白色的，以指示这些帧是编码层级中最低的。帧302、306、310、314、318、322、326、和330可以是双向的、帧间模式预测编码的帧。帧302可以根据帧300和304来预测，帧306可以根据帧304和308来预测，帧310可以根据帧308和312来预测，帧314可以根据帧312和316来预测，帧318可以根据帧316和320来预测，帧322可以根据帧320和324来预测，帧326可以根据帧324和328来预测，以及帧330可以根据帧328和332来预测。

按照显示顺序示出了帧300-322。即，在解码之后，帧300在帧302之前显示，帧302在帧304之前显示，并且以此类推。但是，由于编码层级，可以按照不同的顺序来解码帧300-332。例如，为了适当地解码帧308，可能需要先解码帧316，以充当帧308的参考帧。同样地，帧308可以充当帧302-306以及310-314中任何一个的参考帧，从而，可能需要在帧302-306以及310-314之前将其解码。

因此，在保护帧300-332的经编码的数据的比特流中，可以按照相关的解码顺序来安排帧300-332的编码版本。例如，可以按照下列的顺序在段334中安排帧300-316：300,316,328,304,312,302,306,310,314。类似地，可以按照下列的顺序在段336中安排帧318-332：332,324,320,328,318,322,326,330。其它的顺序安排也是可能的。

可以将显示帧的时间称为呈现时间或显示时间，而解码帧的时间可以称为解码时间。呈现/显示时间通常提供了对相对于相同序列中的其它帧的时间顺序的指示。视频编码器20可以向帧分配一值，该值称为图像顺序计数(POC)值，其表现了帧的显示时间(或呈现时间)。因此，视频解码器30可以使用帧的POC值来确定在解码之后帧的呈现顺序。

为了示例的目的，假定帧300是帧内编码的。以此方式，帧300可以与比特流的SAP相对应，例如，多媒体内容的表现。根据本公开内容的一些示例，可以形成段334使得段334包括帧300-316。此外，在一些示例中，可以形成包含帧318-332的段336。可以将帧316编码为相对于帧300的P帧。如上文所讨论的，帧332可以是帧间编码的，例如，编码为相对于帧316的P帧。然而，可以形成段336，使得段336包含帧318-332。由于帧332是帧间编码的，所以假定帧332不是SAP，段336表现缺少SAP的段的示例。

提供诸如段336之类的、没有SAP的段可以例如在直播流环境中提供若干优点。可以在直播流环境中提供段(例如，利用内容准备设备20)，使得段对应于相对短的播放时间(例如，一秒的呈现时间)。在内容准备设备20一形成段并使得段可用时，作为诸如服务器设备60之类的内容服务器的文件，可以使得每一个段可用于向诸如客户端设备40之类的客户端分发。

不一定需要全部的段都包含SAP。内容准备设备20可以被配置成以内容驱动的方式来在比特流中放置SAP(例如，在压缩方面使得比特流更有效)。内容准备设备20还可以被配置在连续的SAP之间具有指定的最大呈现时间差，例如5秒(在呈现时间方面)。该段序列可以具有如下属性：诸如客户端设备40之类的客户端设备可以在任何SAP处播放比特流开始，并且可以在上述段一在客户端设备处可用时就在客户端设备处播放每一段中包含的大量视频。

作为另一示例，视频帧序列(按照解码或发送顺序)可以是I、P、B、B、P、B、B、P、B、B、P、B、B、I等。在该示例性序列中，第一段可以包含头一个四帧，第二段可以包含接下来的三帧，第三段可以包含接下来的三帧，第四段可以包含接下来的三帧，然后，第五段可以以第二个I帧开始。从接收第一段起，客户端设备可以开始播放头一个四帧，可以从接收第二段起继续播放接下来的三帧，可以从接收第三个片段起播放接下来的三帧，可以从接收第四个片段起播放接下来的三帧。

从而，在该示例中，由于客户端可以在第二段在编码器侧刚开始形成时就可以潜在地开始播放该第一段，所以端到端延迟可以只有四帧，即，在第一段中包含的那些帧。此外，由于当先前段中的帧已经被播放时，每一段可以及时地可用，所以，一旦客户端设备开始播放时，该流可以平滑地继续。但是，在该示例中，由于加入该流并想要在第一个I帧的呈现时间之后而在第二个I帧的呈现时间之前的呈现时间处开始的客户端将典型地只在接收第五段之前才开始播放，所以，客户端的收听延迟将比四帧大得多。

图7是示出根据IDR间隔展示误码秒数的实验测试结果的曲线图。在该示例中，段具有固定的持续时间，每一段以IDR开始(即，对应于IDR的SAP)。随着在二十世纪90年代MPEG2数字视频的出现，迅速地确定视频编码解码器对于错误不是特别的健壮。被损坏的或丢失的数据的编码解码器缓存器寿命越长，破坏越明显。可以相对迅速确定的是，在主观效果方面，将损坏的数据置于编码解码器缓冲区之外是极其优越的。即，冻结通常比其它人工痕迹更好(在主观观察方面)。在大约第一年内，针对LTE，分组错误率(PER)需求从10-7减少至大约1％PER误块率(BLER)，其类似于针对MPEG2传输的PER。通过使在第一解码器之下的层丢弃从损坏点一直到针对H.264的下一个独立的数据刷新(IDR)帧或MPEG2中的新图像组(GOP)，实现了上述改进。

存在实现其的多种方法。例如，MPEG2采用了标识可疑分组的信令比特。随着多个专用移动多媒体物理层的出现，出现了对用于在存在错误时，评估移动视频系统性能的普遍通用的方法的需要。所采用的方案是基于长期存在的来自数据通信的度量，误码秒数。“误码秒数”通常是包含错误的任何整个秒。将该方法改编成由于错误所丢失的媒体秒的百分比。存在在宣布恢复之前需要接收到某一数量的正确分组的该方法的实现。该方法消除了对理解上层语法以进行测量的需要，但是是近似的。5％错误时间或ESR5是度量的示例。

如上文所讨论的，DASH多媒体内容包括多个段。在图7的分析中，将段持续时间设置成等于IDR间隔(在呈现时间方面)。图7中的曲线图表现了在750MHz处对于TU-63公里/小时，针对具有接近1％的平均BLER的轨迹，IDR间隔(并且从而，段持续时间)对错误时间的影响。在6km(3)、2km(5)、和1km(3)小区半径中，针对11、51秒轨迹，通过在1msec时间间隔上评估轨迹SNR来生成结果。物理突发间隔是250ms，数据突发持续时间是41msec。这近似于MCS18在5MHz800kbps、95％覆盖、6km小区、750MHz。具有错误的任何段都被算为错误时间(例如，误码秒数)。对于0.250ms的段，满足了平均小于5％的错误时间。

图8是将另一实验测试结果的示例示出为前向纠错(FEC)的结果的曲线图。存在用于处理错误时间中的变化的各种方法，例如，针对上文图7的讨论。在一个示例中，可以根据段持续时间来修改链路预算。这可以包括针对0.25至4秒IDR速率/段持续时间的范围，在所需的C/N中～0.4dB的变化。

作为另一示例，可以应用应用层FEC。这可以在4秒的链路预算中包含相对可忽略不计(清洗)的结果。从而，C/N增益可以大约补偿容量损失。如在图8的示例性曲线图中所展示的，对于～7％FEC率，错误时间大约是常数。对于轨迹应用了多普勒(2Hz)，但是由于运动没有解相关。

图9是示出展示用于在各个IDR间隔处的段的比特率的实验测试结果的曲线图(在呈现时间)。图9中描绘的结果是基于在多个典型的内容类型(例如，运动、发言人的头部特写、电影等)中、平均35dB的峰值信号噪声比(PSNR)视频的。如在该示例中示出的，频繁的IDR通常增加了相应的比特率。因此，高运动序列可能需要显著更高的比特率。

图10示出了描绘各种峰值信号噪声比(PSNR)相对于平均意见得分(MOS)的一组曲线图。如在这些图像图中示出的，内容选择和IDR放置方法可以显著地影响相对于PSNR的MOS。

图11是描绘展示针对有或没有FEC的各种数据突发间隔的误码秒数的实验测试结果的曲线图。如图11的曲线图中示出的，物理层处数据突发的频率可以影响延迟和时间分集。网络缓存时间(突发之间的距离)可以对端对端延迟添加线性。增加突发间间隔超过0.5秒可以破坏时间分集。在图11中，将IDR间隔和段持续时间设置为常数5.12秒。在该示例中，在离散值0.32、0.640、1.28、2.56、5.12秒处评估间隔。在该示例中，对于0.32秒的突发时段，5％的FEC率足够，否则，可以使用7％的比率。

发送800kbps所需的平均时间独立于数据在物理层的突发速率。突发持续时间与突发速率成反比。物理层的功耗根据突发持续时间变化。存在与每一突发相关联的大约10msec预热时间。对于50msec突发(MCS18、800kbps、320ms突发间隔)，无线电设备开启大约60msec，使得由物理层导致的功耗增加了20％。但是，当在看视频时，该无线电设备仅消耗了总设备消耗的～10％。背光在设备功耗起决定性影响。与5.12秒数据突发间隔相比，对于0.32秒，潜在存在～2％设备功耗增加。这些估计是基于MediaFLO的，并且待修订。

图12是示出针对各种段时间间隔IDR间隔的各种示例的示意图。如图12中所示出的，段持续时间和IDR间隔(即，SAP间隔)不一定需要相等。图12中的示例示出了两个示例性表现，例如，与不同DASH简档相对应的表现。表现350与根据本公开内容的技术的某些示例的示例性表现相对应，其中，一些段不包含SAP，例如，IDR图像、CRA图像、或其它随机接入点。即，表现350包括分布包含SAP354、358的段352A、352B(段352)。同样地，表现350包括不包含SAP的段356A–356D(段356)。另一方面，表现360与DASH中常规表现的示例相对应，该表现中所有段都包含SAP。即，表现360包括分布包含SAP364、366的段362A、362B(段362)。

通常，表现350、360的横轴对应于呈现时间，即，时间上的播放时间。因此，表现350、360中的SAP之间的播放时间大约相等。即，在表现350中，在SAP354和SAP358之间的呈现时间差大约等于在表现360中，在SAP364和SAP366之间的呈现时间差。但是，相比于表现360的段362，表现350的段352、356表现呈现时间的相对短的持续时间。以此方式，相比于表现360的段362A，内容准备设备20可以更快地构造并发送表现350的段352A。

以此方式，表现350表现包含第一段(例如，段352A)和第二段(例如，段356A、356B)的表现的示例，其中，第一段包括包含第一流接入点(例如，SAP354)的媒体数据，第二段包括没有流接入点的媒体数据。此外，可以相对于段352A的媒体数据例如SAP354来编码段356A和/或356B的媒体数据。例如，当对段356A和/或段356B的一个或多个图像进行编码时，视频编码器或视频解码器可以使用SAP354、或段352A的一个或多个其它的图像作为参考图像。因此，可以相对于段352A的媒体数据的至少一部分来对段356A、356B的媒体数据的至少一部分进行编码。

由诸如客户端设备40(图1)之类的客户端设备执行的长笛栈可以错过整个文件。根据本公开内容的示例，每一文件(段)可以包含或不包含IDR。如果段持续时间和IDR间隔相同(例如，表现350中的与表现360中的相同)，针对应用FEC，其可以最大化时间分集，但是也可以对延迟添加线性。另一方面，如果段比IDR间隔小得多，则可以减少针对FEC的时间分集，但是延迟也是如此。IDR间隔可以独立于段持续时间来线性地影响信道改变时间。

添加相对小数量的应用FEC(～7％)可以使得系统ESR5相对于段持续时间基本上恒定。应用层外部代码对链路预算的影响相对小。在MediaFLO早期，存在对不利用外部代码来运行流媒体的积极考虑，在现场测试之后，由于利用外部FEC的情况下视觉性能优越，因此放弃了该想法。针对流媒体维持应用层FEC的选项可能是有用的。虽然对于迅速的信道改变，接近的IDR间隔可能是有用的，但是，其不直接影响延迟。从而，可以使得段比IDR间隔更短。物理层数据突发间隔对延迟和时间分集有直接的影响，因此，如果对于网络中的所有位置根据内容类型的系统行为要是相同的，则可以相应进行指定。可以利用BVPS来指定MSP/CSA设置。这些示例中的比特率对平均内容反映了不错(3.5-4.0)的视频质量。高运动的视频，例如，针对运动，可以使用更高的比特率。

图13是示出用于发送不包含流接入点(SAP)的表现的一个或多个段的示例性方法的流程图。开始，诸如服务器设备60之类的服务器设备可以获得多媒体数据的第一段，其中，第一段包含SAP(400)。在一些示例中，服务器设备60可以从内容准备设备20(图1)接收多媒体数据的第一段。或者，服务器设备60可以被配置成执行属于内容准备设备20的功能，在该情况下，服务器设备60可以对第一段的视频数据进行编码。在该示例中，在任何情况下，第一段可以包含SAP。

可以在流数据的直播期间执行图13中的方法。因此，在服务器设备60一获得第一段，服务器设备60就可以向客户端设备40发送第一段(402)。服务器设备60还可以获得(例如，接收或编码用于其的数据)多媒体数据的第二段，其中，第二段没有SAP(408)。从而，服务器设备60可以在获得多媒体数据的第二、随后的段之前，向客户端设备60发送第一段。在获得第二段之后，服务器设备60可以向客户端设备40发送第二段(410)。

在客户端设备40接收第一段(404)之后，客户端设备40可以解码第一段(406)。此外，在已经解码图像之后，客户端设备40可以显示第一段的解码后的图像。此外，客户端设备40可以接收第二段(412)，例如，在对第一段的至少一部分进行解码之后。具体地，客户端设备40可以在接收随后的流接入点之前，接收及解码第二段。以此方式，客户端设备40可以在跟在第一流接入点之后的第二流接入点可用之前，在接收第二段之前对第一段的编码视频数据的至少一部分进行解码。在接收第二段之后，在随后的流接入点可用之前，客户端设备40可以相对于第一段的数据对第二段的至少一部分进行解码(414)。例如，第二段的至少一个帧可以相对于第一段的一个或多个帧进行帧间预编码。客户端设备40可以相对于第一段的一个或多个帧对第二段的该帧进行解码。

以此方式，图13中的方法表现了一种方法的示例，该方法包括：接收媒体数据的第一段，其中第一段的媒体数据包括第一流接入点；接收媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处没有流接入点；以及，在跟在第一流接入点之后的第二流接入点可用之前，相对于第一段的媒体数据的至少一部分对第二段的媒体数据的至少一部分进行解码。具体地，在该示例中，第二段没有流接入点，即，不包含任何流接入点。

此外，图13中的方法还表现了一种方法的示例，该方法包括：获得媒体数据的第一段，其中，该第一段的媒体数据包括第一流接入点；向客户端设备发送第一段；获得媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处没有流接入点，并且其中，第二段的媒体数据的至少一部分是相对于第一段的媒体数据的一部分进行编码的；以及，在跟在第一流接入之后的第二流接入点可用之前，向客户端设备发送第二段。

图14是示出用于DASH直播和低延迟直播简档的数据安排的示例的示意图。在该示例中，直播简档包括5秒段作为示例，包括元数据(由黑色阴影部分表示)、强迫的IDR图像(由深色阴影部分表示)，以及0个或多个场景改变IDR图像(由浅色阴影部分表示)。即，每一段包括当以预期的帧速率进行解码和播放时，足够对应于5秒播放时间的数据。例如，如果通告的帧速率是60帧每秒，则直播简档中的每一段可以包括300帧的数据。在图14中的特定示例中，直播简档包括：第一段，其包含一个场景变化IDR图像；以及，第二段，其包含两个场景变化IDR图像。直播简档中的每一段也以强迫IDR图像开始。例如，相应的视频编码标准可以指示IDR图像必须每隔5秒播放时间出现。

图14还示出了用于DASH的低延迟直播简档的一组数据示例。在该示例中，低延迟直播简档的每一段表现一个播放段。例如，如果所通告的帧速率是60帧每秒，则每一段可以包含60帧的数据。根据本公开内容的技术，低延迟直播简档的段的图像无需每个都以IDR图像开始。相反，可以相对于先前的段的IDR图像来对低延迟直播简档的段的图像进行编码。即，在段的开始处不包含IDR图像的段的图像可以相对于IDR图像、基于IDR编码的图像、或独立地(例如，作为I帧)进行编码。每一段的元数据可以包括段头部信息。因为每一段无需包含IDR图像，则相对于直播简档，低延迟直播简档的数据可以减少延迟，这是因为可以在直播简档的相应段之前，发送低延迟直播简档的段。

在一个示例中，与被配置成使用DASH低延迟直播简档的客户端设备相比，被配置成使用DASH直播简档的客户端设备(诸如图1中的客户端设备40之类的)可以缓存更多的每段视频数据。例如，如图14中所示出的，DASH直播简档可以使客户端设备缓存每段5秒的视频数据，而DASH低延迟直播简档可以使得客户端设备缓存每段一秒的视频数据。如上文所记载的，所缓存的特定时间量与播放时间量相对应。以此方式，DASH低延迟直播简档可以将相同的流划分成更多的段。即，如图14中所示出的，直播简档和低延迟直播简档可以与相同媒体内容的不同表现相对应。此外，DASH直播简档可能在每一段的开始处需要SAP或IDR图像，而根据本公开内容的技术，DASH低延迟直播简档可以省略这样的需要。即，如图14中所示出的，根据DASH低延迟直播简档形成的表现可以在一个或多个段的开始处没有IDR图像。

图15是示出针对物理层处的示例性DASH直播和DASH低延迟直播简档的每段比特率的示意图。DASH低延迟直播简档可以减少延迟，但是也可以增加段到段数据大小的变化。例如，如图15中所示出的，与DASH直播简档段相比，DASH低延迟直播简档段可以具有更大的大小，这是因为在每一段中，可能存在更低速率的滑动。在图15中，为了示例的目的，将IDR和其它帧假定为固定大小，并且其比例是基于各种内容类型的平均的。

图16是示出用于最小化低延迟直播段的峰峰比特率变化的技术的示意图。在一示例中，可以将多个服务复用到一起。通过相对于DASH低延迟直播简档段位置错开强迫的IDR图像的阶段，可以最小化针对DASH低延迟直播简档的合计比特率变化。例如，如图16中所示出的，以错开的方式，每DASH低延迟直播简档段插入一个强迫的IDR图像。如果一服务的组合体上有N个流，则可以基于DASH直播简档段持续时间和DASH低延迟直播简档段之间的整数关系，以循环的方式插入N阶段的强迫的IDR图像。换句话说，在图16中，可以以循环的方式插入5个强迫的IDR图像，因为DASH直播简档段是DASH低延迟直播简档段长度的5倍。在一个配置中，如果存在大量的服务，使得DASH直播简档段变得太长，则可以将N个服务划分成多个IDR图像循环组。此外，强迫的IDR图像的循环无需刚好是N；强迫的IDR图像间隔可以大于N。

以此方式，诸如内容准备设备20或服务器设备60之类的源设备可以被配置成形成服务的组合体，服务中的每一个包括相应的多个段，其中，服务中的一个包括包含第一段和第二段的多个段，其中，形成服务的组合体包括形成包括HTTP上的动态自适应流(DASH)直播简档服务的服务中的一个，其中，DASH直播简档服务中的第一段的第一SAP具有第一呈现时间，其中，DASH直播简档的第二段的第二SAP具有第二呈现时间，并且其中，在DASH直播简档服务中，第一段和第二段是连续的，以及形成包括相应的DASH低延迟直播概要服务的服务中的一个或多个，使得针对在第一呈现时间和第二呈现时间之间的呈现时间，DASH低延迟直播简档服务包括具有在第一呈现时间和第二呈现时间之间的呈现时间的SAP，其不同于第一呈现时间，并且不同于DASH低延迟直播简档服务的其它服务的其它SAP的呈现时间。

当包含呈现时间在第一呈现时间和第二呈现时间之间的SAP的DASH低延迟直播简档服务的段不包含场景变化即时解码器刷新(IDR)图像时，源设备还可以形成DASH直播简档服务，使得第一段的长度是DASH低延迟直播简档服务的段长度的倍数。此外，源设备可以确定服务的组合体是否包括超过阈值数量的服务的多个服务，并且当多个服务超过阈值数量的服务时，将该组分成两个或更多个单独的服务的组合体。

DASH低延迟直播简档服务的段可以具有第一长度，并且源设备可以构造DASH直播简档服务的第一段的长度等于DASH低延迟直播简档服务的数量乘以第一长度，再加上第一长度。即，如果第一长度是K，并且服务的数量是N，则DASH直播简档服务的第一段的长度可以具有长度：K*N+K，或(N+1)*K。或者，DASH直播简档服务的第一段的长度可以是(N+J)*K，其中，J是正整数。

如果服务的组合体仅是完整组的第一子集，并且完整的组相对大，完整组的第二子集可以包括在与第一子集的SAP的呈现时间相对应的呈现时间处的SAP。以此方式，其中，服务的组合体包括完整组的第一子集，并且其中，完整服务的组合体的第二子集包括DASH低延迟直播简档服务，其包含在第一子集的DASH低延迟直播简档服务的至少一些呈现时间的呈现时间处的SAP。即，源设备可以根据大的服务的组合体的段，增加每服务的组合体的SAP的数量。

图17是示出与DASH直播和DASH低延迟直播简档相对应的示例性表现的示意图，其中，场景变化IDR帧与强迫的IDR帧是一致的。在DASH低延迟直播简档中，强迫的IDR帧(表现SAP的示例)可能与场景变化的IDR帧是一致的(即，强迫的IDR帧和场景变化的IDR帧在同一段中)。诸如内容准备设备20或服务器设备60(图1)之类的源设备可以确定在相关的编码标准指示需要IDR图像的时间处出现段(在播放时间中测量)。但是，源设备可以进一步确定段会包括IDR图像，例如场景变化IDR图像。

从而，源设备可以仅包含场景变化的IDR图像，而不包含强迫的IDR图像和场景变化的IDR图像两者，这可以满足相关标准的需求并改进针对该段的失真率度量。可以相对于先前的段的数据来对在段的场景变化的IDR图像之前出现的图像数据(按照解码顺序)进行编码。该源设备还可以提供用于将场景变化的IDR图像作为随机接入点访问的信息，例如，针对场景变化的IDR图像的子节偏移。以此方式，诸如客户端设备40之类的客户端设备可以使用该数据来从场景变化的IDR图像而不是从该段的开始处发起流。

场景变化的IDR可能无法在DASH低延迟直播简档中被重新定位。在一示例中，可以将该段中的强迫的IDR帧丢弃，而不对DASH低延迟直播简档所需的能力造成变化(即，可以由场景变化的IDR帧来提供所丢弃的强迫的IDR帧的功能)。DASH低延迟直播简档可以支持不以IDR帧或SAP开始的段。在另一方面，DASH直播简档可以保留强迫的IDR帧。该行为可以使得DASH低延迟直播简档与DASH直播简档不同，但是对于专用的场内应用，这不会造成问题，因为，该编码专用于单个设施。但是，可能需要避免参考在未来段中的视频图像的视频图像，否则，可能会增加延迟。

图18是示出用于在存在非同时发生的场景变化的IDR帧的情况下，最小峰峰比特率变化的技术的示意图。作为示例，场景变化的IDR图像可以与针对其它流的强迫的IDR帧的循环分配潜在同时发生。在一示例中，可以将强迫的IDR图像延迟一个段，以避免在同一DASH低延迟直播简档段中出现不同流上的两个IDR图像。该技术可能与基本的、从同一编码器同时生成DASH直播简档和DASH低延迟直播简档不兼容。在另一示例中，如果在循环组中的服务中存在两个或更多个场景变化的IDR图像，则仅可以丢弃或延迟一个强迫的IDR图像。如先前所讨论的，如果场景变化的IDR图像在同一服务中，则可以丢弃强迫的IDR图像，或者如果场景变化的IDR图像在另一服务的相同段中，则可以将其延迟。

以此方式，诸如内容准备设备20或服务器设备60之类的源设备可以被配置成形成多个不同表现的多个段，使得当多个不同的表现中的一个的段包含流接入点时，多个不同表现的其它表现的在时间上共存的段没有流接入点。

图19是示出允许场景变化的IDR帧的次优强迫的IDR图像序列的示意图。以在DASH低延迟直播概要服务的组合体中的服务数量更大的节奏在段中插入强迫的IDR图像可以允许增加在重新定位IDR图像中的灵活性。在一个示例中，可以通过下面的公式来给出在给定的每段服务中可能的IDR图像的总数：

在上面的公式中，C是在段中，强迫的IDR图像的插入节奏，S是在段中场景变化的IDR图像之间的平均时间，N是该组中服务的数量。因为用于是速率平滑的基本方案是在服务的组合体中实现每段一个IDR图像，所以，将每强迫的IDR图像的段数量增加至比服务的数量更多的节奏可以增加可能满足每段一个IDR帧的目标的可能性。但是，该方法可能尤其局限性，因为该目标是实现每段组一个IDR图像，而不是更少。

例如，如图19中所示出的，如果存在四个服务，并且场景变化的IDR图像的平均时间是7个段，则强迫的IDR图像节奏的持续时间可以最优地为8段的持续时间。在该示例中，名义上，在全部服务的组合体中每隔一段可能存在一个强迫的IDR图像。使用上文描述的技术，当与场景变化的IDR图像同时发生时，可以转移强迫的IDR图像。

在图19中示出的示例中，在强迫的IDR帧位置中没有出现场景变化的IDR图像，这可能是随意的和不太可能的。但是，该安排满足了对于组每段一个IDR图像的目标。如果服务的内容高度相关，则场景变化也可以高度相关，并且所描述的方法可能不能有效。此外，对于较大组的服务，可以将该目标调整至每组段两个或更多个IDR图像。因为服务池可能增加，所以这可能比具有多个组更有效。此外，当服务数量乘以每段场景变化的IDR图像的概率等于1时，强迫IDR图像的节奏可能变得非常大。

图20是示出用于根据本公开内容的某些技术形成表现的另一示例的流程图。在该示例中，诸如内容准备设备20或服务器设备60(图1)之类的服务器设备形成包括至少一个段的表现，该至少一个段在不同于段的开始处的位置处包含SAP。具体地，在该示例中，服务器设备接收第一段的多媒体数据(450)。该多媒体数据可以按照解码顺序在第一段的开始处包含IDR图像。或者，多媒体数据可以不包含IDR图像，而服务器设备可以将第一段的图像转码为IDR图像。因此，服务器设备可以创造在第一段的开始处(按照解码顺序)包含IDR图像的第一段，以及所接收的剩余的多媒体数据(452)。

然后，服务器设备可以继续对其它段进行编码(图20中未示出)。虽然对其它段进行编码，但是服务器设备可以追踪从第一段的IDR图像起的时间距离。如有相关编码标准所指示的，基于该追踪，服务器设备可以确定到下一个IDR图像的时间距离何时已经经过(454)。例如，服务器设备可以追踪在其它段中已经包含的多个图像，以及用于多媒体数据播放的帧速率，并且基于该帧速率和图像的数量确定时间距离何时已经经过。

然后，服务器设备可以以该时间距离接收第二段的多媒体数据(456)。应该理解的是，一个或多个段可以将第一段与第二段分开，并且在图20的该描述中，术语“第一”和“第二”在名义上使用，而不是在顺序上使用。服务器设备还可以确定第二段的多媒体数据包含场景变化的IDR图像(458)。此外，服务器设备可以确定多媒体数据不包含任何其它IDR图像，例如，在第二段的多媒体数据的开始处的IDR图像。

常规地，第二段可以在第二段的开始处包含IDR图像，而根据本公开内容的技术，服务器设备可以将场景变化的IDR图像当中满足相关编码标准的IDR图像来对待。即，可以使用第二段的场景变化的IDR图像而不是额外的“强迫的IDR”图像。因此，服务器设备可以形成包含多媒体数据的第二段，使得第二段在第二段的开始处没有IDR图像，而不管相关标准的要求。因为第二段的多媒体数据包括场景变化的IDR图像，所以该场景变化的IDR图像可以满足IDR图像以特定的时间规律出现的相关标准的命令。

此外，诸如客户端设备40(图1)之类的客户端设备可以获得第二段的数据(462)。例如，客户端设备可以在场景变化的IDR图像处开始网络流。从而，客户端设备可以在场景变化的IDR图像处开始网络流，而不是在第二段的开始处开始网络流。服务器设备可以例如在与第一段和第二段相对应的清单文件中通告针对场景变化的IDR图像的开始处的字节范围偏移。从而，客户端设备可以提交部分获得请求，指定以字节偏移开始的第二段的字节范围。

客户端设备可以但是不需要获取在场景变化的IDR图像之前的第二段的数据。但是，当客户端设备以第二段开始流时，第二段中在场景变化的IDR图像之前(按照解码顺序)的这样的数据可能不能解码。客户端设备可以对所接收的第二段的数据进行解码，按照解码顺序从场景变化的IDR图像开始(464)。在解码之后，客户端设备还可以将第二段的图像的顺序重新安排成显示顺序，并显示解码的图像。

以此方式，图20中的方法表现一种方法的示例，该方法包括：接收多媒体数据的段，其中，该多媒体的段的媒体数据在第二段的开始处没有流接入点；以及对该段的媒体数据的至少一部分进行解码。

图20中的方法表现在其中客户端设备执行从第二段开始的随机接入的示例。但是，在其它示例中，客户端设备可以接收第一段和第二段两者。在这样的示例中，该方法可以包括：接收媒体数据的第一段，其中，第一段的媒体数据包括第一流接入点；接收媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处没有流接入点；并且在位于第一流接入点之后的第二流接入点可用之前，相对于第一段的媒体数据的至少一部分，对第二段的媒体数据的至少一部分进行解码。具体地，在该示例中，第二段包括第三流接入点，其与第一流接入点和第二流接入点相分离，并且第三流接入点在不同于第二段的开始的位置处出现。以此方式，第三流接入点在第一接入点之后但是在第二流接入点之前出现。相对于第一段解码的第二段的部分可以与按照解码顺序在场景变化的IDR之前的一个或多个图像相对应。

图20中的方法还表现一种方法的示例，该方法包括：获得媒体数据的第一段，其中，第一段的媒体数据包括第一流接入点；向客户端设备发送第一段；获得媒体数据的第二段，其中，第二段的媒体数据在第二段的开始处没有流接入点，并且其中，相对于第一段的媒体数据的一部分对第二段的媒体数据的至少一部分进行编码；以及，在位于第一流接入点之后的第二流接入点可用之前，向客户端设备发送第二段。

在一个或多个示例中，本申请所述功能可以用硬件、软件、固件或其任意组合的方式来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输，并且其可由基于硬件的处理单元来执行。计算机可读介质可以包括计算机存储介质，其与诸如数据存储介质之类的有形介质相对应，或者通信介质，其包括例如根据通信协议便于从一个地方向另一个地方传送计算机程序的任何介质。以此方式，计算机可读介质通信对应于(1)有形的计算机可读介质，其是非暂时性的或(2)诸如信号或载波之类的通信介质。数据存储介质可以是一个或多个计算机或一个或多个处理器能够存取以获取用于实现本公开内容中描述的技术的指令、代码和/或数据结构的任何可用介质。计算机程序产品可以包括计算机可读介质。

通过示例的方式而不是限制的方式，这种计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储介质或其它磁存储设备、闪存、或者能够用于存储具有指令或数据结构形式的期望的程序代码并能够由计算机进行存取的任何其它介质。此外，任何连接都可以适当地被称为计算机可读介质。例如，如果指令是使用同轴线缆、光纤线缆、双绞线、数字用户线(DSL)或者诸如红外线、无线和微波之类的无线技术从网站、服务器或其它远程源传输的，那么同轴线缆、光纤线缆、双绞线、DSL或者诸如红外线、无线和微波之类的无线技术包括在所述介质的定义中。但是，应该理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它暂时的介质，而是针对非暂时的、有形的存储介质。如本申请所使用的，磁盘和光盘包括压缩盘(CD)、激光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光盘，其中磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上面的组合也应当包括在计算机可读介质的保护范围之内。

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

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

已经描述了各个示例。这些和其它的示例在随后的权利要求书的包含范围之内。

Claims (61)

1.一种接收媒体数据的方法，所述方法包括：

接收媒体数据的第一段，其中，所述第一段包括第一流接入点；

接收媒体数据随后的第二段，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的；以及

在继所述第一流接入点之后的第二流接入点可用之前，相对于所述第一段的至少一部分，对所述第二段的至少一部分进行解码。

2.根据权利要求1所述的方法，其中，所述第二段没有流接入点。

3.根据权利要求1所述的方法，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

4.根据权利要求1所述的方法，还包括：

在接收所述第二段之前，对所述第一段的至少一部分进行解码。

5.根据权利要求1所述的方法，其中，所述第一段的经编码的数据与播放持续时间相对应，并且其中，所述第二段的经编码的数据与相同的播放持续时间相对应。

6.根据权利要求5所述的方法，其中，一个表现包括包含所述第一段和所述第二段的多个段，并且其中，所述多个段中的每一个包括相同的播放持续时间。

7.根据权利要求1所述的方法，其中，所述第一段的经编码的数据与播放时间的第一播放持续时间相对应，并且其中，所述第二段的经编码的数据与不同于所述第一播放持续时间的第二播放持续时间相对应。

8.根据权利要求1所述的方法，其中，所述流接入点包括所述第一段的即时解码器刷新(IDR)图像。

9.根据权利要求1所述的方法，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。

10.根据权利要求1所述的方法，其中，所述第一段包括第一媒体文件，并且其中，所述第二段包括与所述第一媒体文件相分离的第二媒体文件。

11.一种用于接收媒体数据的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置成：

接收媒体数据的第一段，其中，所述第一段包括第一流接入点；

接收媒体数据随后的第二段，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的；以及

在继所述第一流接入点之后的第二流接入点可用之前，相对于所述第一段的数据的至少一部分，对所述第二段的至少一部分进行解码。

12.根据权利要求11所述的设备，其中，所述第二段没有流接入点。

13.根据权利要求11所述的设备，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

14.根据权利要求11所述的设备，其中，所述一个或多个处理器被配置成：在接收所述第二段之前，对所述第一段的至少一部分进行解码。

15.根据权利要求11所述的设备，其中，所述第一段的经编码的数据与播放持续时间相对应，并且其中，所述第二段的经编码的数据与相同的播放持续时间相对应。

16.根据权利要求15所述的设备，其中，一个表现包括包含所述第一段和所述第二段的多个段，并且其中，所述多个段中的每一个包括相同的播放持续时间。

17.根据权利要求11所述的设备，其中，所述第一段与具有第一播放时间的媒体数据相对应，并且其中，所述第二段与具有不同于所述第一播放时间的第二播放时间的媒体数据相对应。

18.根据权利要求11所述的设备，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。

19.一种用于接收媒体数据的设备，所述设备包括：

用于接收媒体数据的第一段的模块，其中，所述第一段包括第一流接入点；

用于接收媒体数据随后的第二段的模块，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的；以及

用于在继所述第一流接入点之后的第二流接入点可用之前，相对于所述第一段的至少一部分，对所述第二段的至少一部分进行解码的模块。

20.根据权利要求19所述的设备，其中，所述第二段没有流接入点。

21.根据权利要求19所述的设备，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

22.根据权利要求19所述的设备，还包括：

用于在接收所述第二段之前，对所述第一段的至少一部分进行解码的模块。

23.根据权利要求19所述的设备，其中，所述第一段的经编码的数据与播放持续时间相对应，并且其中，所述第二段的经编码的数据与相同的播放持续时间相对应。

24.根据权利要求19所述的设备，其中，所述第一段与具有第一播放时间的媒体数据相对应，并且其中，所述第二段与具有不同于所述第一播放时间的第二播放时间的媒体数据相对应。

25.根据权利要求19所述的设备，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。

26.一种发送媒体数据的方法，所述方法包括：

获得媒体数据的第一段，其中，所述第一段包含第一流接入点；

向客户端设备发送所述第一段；

获得媒体数据随后的第二段，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的，并且其中，相对于所述第一段的至少一部分，对所述第二段的至少一部分进行编码；以及

在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段。

27.根据权利要求26所述的方法，其中，所述第二段没有流接入点。

28.根据权利要求26所述的方法，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

29.根据权利要求28所述的方法，还包括：

确定所述第二段对应于需要流接入点的时间位置，以及将对应于在不同于所述第二段的所述开始的位置处的所述流接入点的场景变化即时解码器刷新(IDR)图像当作所需的流接入点进行处理。

30.根据权利要求28所述的方法，还包括：

形成服务的组合体，所述服务中的每一个服务包括相应的多个段，其中，所述服务中的一个服务包括包含所述第一段和所述第二段的多个段，其中，形成所述服务的组合体包括：

形成所述服务中的一个服务以包括第一服务，其中，所述第一服务的第一段的第一SAP具有第一呈现时间，其中，所述第一服务的第二段的第二SAP具有第二呈现时间，并且其中，所述第一段和所述第二段在所述第一服务中是连续的；以及

形成所述服务中的多个服务以包括与所述第一服务相分离的相应的多个服务，使得对于在所述第一呈现时间和所述第二呈现时间之间的呈现时间，所述多个服务包括具有呈现时间的SAP，所述呈现时间在所述第一呈现时间和所述第二呈现时间之间、与所述第一呈现时间不同、并且与所述多个服务的其它服务的其它SAP的呈现时间不同。

31.根据权利要求30所述的方法，其中，当包含具有在所述第一呈现时间和所述第二呈现时间之间的所述呈现时间的所述SAP的所述多个服务的段不包括场景变化即时解码器刷新(IDR)图像时，形成第一服务包括形成所述第一段以具有为所述多个服务的段的长度的倍数的长度，其中，所述倍数大于1。

32.根据权利要求31所述的方法，其中，所述倍数大于或等于所述多个服务的数量。

33.根据权利要求30所述的方法，其中，所述多个服务的段具有第一长度，并且其中，所述第一服务的所述第一段具有等于所述多个服务的数量乘以所述第一长度再加上所述第一长度的长度。

34.根据权利要求30所述的方法，其中，所述服务的组合体包括服务的整个组合体的第一子集，并且其中，所述服务的整个组合体的第二子集包括多个服务，所述多个服务在所述第一子集中的所述多个服务的至少一些呈现时间的呈现时间处包括SAP。

35.根据权利要求30所述的方法，还包括：

确定所述服务的组合体是否包括超过服务的阈值数量的服务数量；以及

当所述服务数量超过所述服务的阈值数量时，将所述组合体分成两个或更多个分开的服务的组合体。

36.根据权利要求30所述的方法，其中，形成所述多个服务包括：以符合循环插入的方式来插入所述SAP，并且当所述多个服务中的第一个服务包括具有不同于与所述循环插入相对应的呈现时间的一呈现时间的场景变化即时解码器刷新(IDR)图像时，针对所述多个服务中的所述第一个服务，在对应于所述循环插入的所述呈现时间处，插入所述多个服务中的第二个服务的SAP。

37.根据权利要求26所述的方法，其中，发送所述第一段包括在获得所述第二段之前发送所述第一段。

38.根据权利要求26所述的方法，还包括：

形成符合HTTP上的动态自适应流(DASH)的低延迟直播简档的表现，使得所述表现包括所述第一段和所述第二段。

39.根据权利要求26所述的方法，其中，所述第一段的经编码的数据与播放持续时间相对应，并且其中，所述第二段的经编码的数据与相同的播放持续时间相对应。

40.根据权利要求26所述的方法，其中，一个表现包括包含所述第一段和所述第二段的多个段。

41.根据权利要求26所述的方法，其中，获得所述第一段包括从内容准备设备接收所述第一段，并且其中，获得所述第二段包括从所述内容准备设备接收所述第二段。

42.根据权利要求26所述的方法，其中，获得所述第一段包括在直播录制期间，实时接收所述第一段的媒体数据。

43.根据权利要求26所述的方法，其中，获得所述第一段包括对所述第一段的媒体数据进行编码，并且其中，获得所述第二段包括对所述第二段的媒体数据进行编码。

44.根据权利要求43所述的方法，其中，对所述第二段进行编码包括：相对于所述第一段的数据对所述第二段的至少一部分进行编码。

45.根据权利要求26所述的方法，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。

46.根据权利要求26所述的方法，其中，所述第一段包括第一媒体文件，并且其中，所述第二段包括与所述第一媒体文件相分离的第二媒体文件。

47.一种用于发送媒体数据的设备，所述设备包括一个或多个处理器，所述一个或多个处理器被配置成：

获得媒体数据的第一段，其中，所述第一段包含第一流接入点；

向客户端设备发送所述第一段；

获得媒体数据随后的第二段，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的，并且其中，相对于所述第一段的至少一部分，对所述第二段的至少一部分进行编码；以及

在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段。

48.根据权利要求47所述的设备，其中，所述第二段没有流接入点。

49.根据权利要求47所述的设备，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

50.根据权利要求47所述的设备，其中，所述一个或多个处理器被配置成在获得所述第二段之前发送所述第一段。

51.根据权利要求47所述的设备，其中，所述第一段的经编码的数据与播放持续时间相对应，并且其中，所述第二段的经编码的数据与相同的播放持续时间相对应。

52.根据权利要求47所述的设备，其中，一个表现包括包含所述第一段和所述第二段的多个段。

53.根据权利要求47所述的设备，其中，所述一个或多个处理器被配置成：对所述第一段的媒体数据进行编码，以及相对于所述第一段的数据对所述第二段的媒体数据进行编码。

54.根据权利要求47所述的设备，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。

55.一种用于发送媒体数据的设备，所述设备包括：

用于获得媒体数据的第一段的模块，其中，所述第一段包含第一流接入点；

用于向客户端设备发送所述第一段的模块；

用于获得所述媒体数据随后的第二段的模块，其中，所述第二段在所述第二段的开始处没有流接入点，并且所述第二段的至少一部分是相对于所述第一段的一部分进行编码的，并且其中，相对于所述第一段的至少一部分，对所述第二段的至少一部分进行编码；以及

用于在继所述第一流接入点之后的第二流接入点可用之前，向所述客户端设备发送所述第二段的模块。

56.根据权利要求55所述的设备，其中，所述第二段没有流接入点。

57.根据权利要求55所述的设备，其中，所述第二段在不同于所述第二段的开始的位置处包括第三流接入点，并且其中，所述第二流接入点在所述第三流接入点之后。

58.根据权利要求55所述的设备，其中，所述用于发送所述第一段的模块包括：用于在获得所述第二段之前发送所述第一段的模块。

59.根据权利要求55所述的设备，其中，一个表现包括包含所述第一段和所述第二段的多个段。

60.根据权利要求55所述的设备，其中，所述用于获得所述第一段的模块包括：用于对所述第一段的媒体数据进行编码的模块，并且其中，所述用于获得所述第二段的模块包括：用于相对于所述第一段的数据对所述第二段的媒体数据进行编码的模块。

61.根据权利要求55所述的设备，其中，所述第一段包括第一HTTP上的动态自适应流(DASH)段，并且其中，所述第二段包括不同于所述第一DASH段的第二DASH段。