CN109565620A - 低延迟http实时流传输 - Google Patents

Abstract

实施方式利用现有内容分发网络提供了一种用于低延迟实时视频流的结构。示例方法包括在广播流的开始处创建用于广播流的播放列表，该广播流标识至少两个分段文件。分段文件的每一个的内容是表头。该方法还包括将播放列表和分段文件的每一个传输到缓存服务器，获取视频广播流作为一系列帧，并利用HTTP块传输协议将该系列帧中的每个帧传输到缓存服务器，每个帧与播放列表中标识的第一分段文件相关联并写入第一分段文件。当广播流中的帧是中断帧时，该方法包括传输第一分段文件的文件结束标记，并且在传输之前为中断帧添加视频头。

Description

低延迟HTTP实时流传输

相关申请的交叉引用

本申请要求于2017年7月19日提交的美国非临时申请第15/654,494号的以及于2016年8月4日提交的美国临时申请第62/371,092号、题为“低延迟HTTP实时流”的优先权，并且是上述两个申请的继续申请，其公开内容通过引用并入本文。

背景技术

内容提供商向观看者分发媒体内容。一些这样的内容提供商提供实时流媒体，该实时流媒体实时或接近实时地提供。内容提供商通常选择通过持久连接或通过HTTP/HTTPS(超文本传输协议)/(HTTP安全协议)来分发实时流媒体。持久连接协议(例如实时消息传送协议(RTMP))通过在流的持续时间内持久存在的连接，一次一帧地向观看者分发实时流媒体。这种直接分发允许低延迟，例如大约2秒。延迟是介于当在广播设备上产生内容时与当观看设备播放内容时之间的时间。但是为大量观看者(例如数百个)提供持久的连接是昂贵的并因此成本过高。通过HTTP分发实时流媒体可以利用HTTP实时流协议(HLS)完成，该协议将实时视频流分解到非常短的文件的播放列表中，所述文件使用标准内容分发网络(CDN)或类似的缓存服务分发和缓存。通过内容分发网络的分发不限制观看者，但是将流分段为短文件的基于HTTP的流协议增加了延迟。例如，在HLS的情况下，延迟通常约为9-10秒。

发明内容

所公开的实施方式为实时流流媒体提供了低延迟的有成本效益的解决方案。实施方式包括低延迟HTTP实时流协议(也称为LHLS)，其利用分块HTTP传输和修改的HLS播放列表文件一次一帧地传输实时流媒体文件。利用本文所公开的协议，可以使用内容分发网络向实时流媒体文件提供大约2秒的延迟，这使得能够实际上向无限数量的观看者分发。这种低延迟时间使得实时流视频广播的任何数量的观看者能够提供闭合的反馈回路，其中来自观看者的参与被实时或接近实时地提供给广播者以及其他观看者。例如，观看者可以对广播进行评论，可以对广播中的特定时刻表示认可，可以邀请其他社交媒体用户加入广播等。由于低延迟(例如2秒或更短)，在适合于允许广播者对观看者做出反应并与观看者交互的延迟时间段内可以将这种参与返回提供给观看者和广播者。

在一些实施方式中，实时流视频服务器可以利用分块HTTP传输将实时视频流的每个帧传输给缓存服务器(例如内容分发网络)。然后，速缓存服务器也使用分块HTTP传输向观看者提供帧。在分块HTTP传输中，文件是利用HTTP传输的，但是是以许多单独传输的方式，并不预先知道文件的总持续时间。每个块(帧)与文件(也称为分段文件)相关联，并且整个实时流媒体广播可以由一系列分段文件组成。每个分段文件可以表示大致的时间段，例如3秒的视频。但是，在分段中的帧传输到缓存服务器之前，并不知道任何分段文件的确切的持续时间。而是一旦在视频流中识别出中断帧，就确定每个特定分段文件的持续时间。中断帧可以表示在某时间间隔(例如3秒)后接收的关键帧，使得一旦已经接收到所有帧，每个分段文件大约为3秒长。中断帧还可以表示改变实时流广播的视频属性的不连续。例如，当广播者从照相手机切换到无人机摄像机时，或者当广播的视频质量因广播者可用的带宽而改变时，可能发生不连续。以这种方式生成分段文件允许视频服务器以LHLS格式和HLS格式提供广播，这是由于已经完成的分段文件可以被添加到HLS播放列表。这使得不具有LHLS查看器的观看者能够参与广播，即使这些观看者由于延迟增加可能无法参与闭合的反馈回路中也是如此。

低延迟播放列表文件使得能够通过分块HTTP传输来传输实时视频流中的帧。使用分块传输编码的好处在于它消除了通常与基于HTTP的流式传输相关联的分段延迟。例如，在HLS实时流传输中，来自广播者的连续的媒体帧通常被集合成每个几秒长的分段。仅当分段完成时，才能将分段的URL添加到实时媒体播放列表。延迟问题在于，到分段完成时，分段中的第一帧与分段的持续时间一样长。尽管可以通过减小分段的大小来减少这种“分段延迟”，但这会降低视频编码效率，此处假设每个分段以I帧开始，这是由于I帧通常比预测帧大许多倍。另一方面，通过利用分块传输编码，可以在分段完成之前将分段的URL添加到媒体播放列表。客户端可以请求尚未完成的分段，并且在服务器从广播者一接收分段的帧客户端就开始接收分段的帧。

低延迟播放列表类似于HLS协议中使用的播放列表，但区别在于其支持分块HTTP传输。首先，低延迟播放列表不能包括用于不连续的标记，因为在生成或更新播放列表时不知道不连续。因此，实时流视频服务器标识不连续，在遇到不连续时开始新的分段文件，并在视频流中提供视频属性。此外，播放列表需要标识至少两个分段文件。尽管正在传送的帧(例如，传送到内容服务器以及从内容服务器传送到观看者)通常与播放列表中标识的第一分段文件相关联，但是其他分段文件必须存在，并且写入有限的表头数据以确保观看者可以请求文件并且不间断地播放实时流视频广播。但是，分段文件的准确长度不能包含在播放列表中，这是由于在使用表头数据生成文件时不知道长度。

附图说明

图1是根据一种实施方式的使用分块HTTP传输的低延迟实时流广播的示意图。

图2a是根据一种实施方式的用于低延迟HTTP实时流协议的播放列表的示例。

图2b是根据一种实施方式的用于低延迟HTTP实时流协议的播放列表的另一示例。

图3是根据一种实施方式的描绘提供低延迟HTTP实时流协议的内容服务器的示例操作的示例方法的流程图。

图4是根据另一实施方式的描绘接收低延迟HTTP实时流协议的回放设备的示例操作的示例方法的流程图。

图5是根据一种实施方式的以计算设备的示例形式的机器的示意图，该机器内具有一组指令，用于使机器执行图1的交互式视频广播服务的任何一个或多个功能。

图6是针对LHLS和HLS对在观看设备处接收的视频帧随时间变化进行比较的曲线图。

图7是针对LHLS和HLS对回放缓冲区充满度进行比较的曲线图。

具体实施方式

图1是用于支持低延迟HTTP实时流广播的系统100的示意图。系统100可以包括通过一个或多个网络150连接到一个或多个流服务器计算机160的一个或多个客户端设备102(例如102a、102b)。客户端设备102既可以是观看设备也可以是广播设备，这是由于视频流应用程序132支持两种功能。客户端设备102是消费者计算设备，并且可以是移动计算设备(例如智能电话、PDA、平板电脑、可穿戴设备(如腕式或头戴式设备)、虚拟现实设备、或膝上型计算机)或非移动个人计算设备(例如桌面台式计算设备、支持互联网的电视或娱乐系统)。客户端设备102可以包括一个或多个处理器106(例如形成在基板中的处理器(如中央处理单元、图形处理器等))、易失性存储器108以及非易失性存储器110。在各种实施方式中，易失性存储器108可以存储例如由处理器106执行的指令，并且非易失性存储器110可以存储例如各种用户数据、指令(用于执行操作系统)、应用程序等。虽然比起客户端设备102b，图1更详细地示出了客户端设备102a，但是应当理解的是，客户端设备102b包括类似的组件。还应理解，尽管图1的系统为了便于讨论在实时流视频广播系统方面讨论了图1，但所公开的实施方式不限于此并且可以应用于任何流式媒体系统。

计算设备102可以包括操作系统112和多个应用程序114，所述多个应用程序114可以由计算设备102执行(例如通过执行存储在存储器108或110中的对应于应用程序的一个或多个指令的处理器106)并且可以与操作系统通信(例如通过一个或多个应用程序编程接口(API))。执行应用程序114可以向计算设备102的用户提供各种功能。在一些示例中，电子邮件应用程序可以在用户的许可下提供对用户的电子邮件帐户以及与该帐户相关联的电子邮件消息的访问。浏览器应用程序可以向用户提供Web浏览器，以便用户可以访问可加载到浏览器应用程序中并由浏览器应用程序显示的内容。社交网络应用程序可以在与社交网络应用程序相关联的社交媒体平台内从用户已选择来关联到的联系人和来源向用户提供内容。摄像机应用程序可以提供对计算设备102内的摄像机116的访问，以捕获静态图片或视频。在一些实施方式中，摄像机116可以位于计算设备102的外部(例如与计算设备102无线通信(例如通过蓝牙或Wi-Fi)的摄像机)。也可以提供向用户提供丰富的各种其他功能和信息的应用程序。在一些实施方式中，视频流应用程序132可以看作是应用程序114之一。

计算设备102包括显示器118(例如触摸屏显示器、LED显示器等)，显示器118可以显示由设备执行的应用程序114的用户界面。一次可以执行多于一个应用程序。然而，在一些实施方式中(例如在智能电话的情况下)，显示的持续时间更适合于一次显示单个执行的应用程序。在显示器118上显示的执行的应用程序可以称为“面向前”的应用程序。

计算设备102可以包括内部扬声器117，内部扬声器117可以提供来自设备的音频输出。计算设备102还可以包括端口(未示出)，该端口可以用于将计算设备连接到外部设备(例如在连接到设备102时可以提供音频输出的扬声器)。计算设备102还可以包括：麦克风122，其检测设备的环境中的声音。在一些实施方式中，麦克风122可位于计算设备102的外部。麦克风122(无论是内部还是外部)可为实时视频流提供音频。

计算设备还包括确定时间和日期的时钟120，并且可以包括GPS收发器124，GPS收发器124与全球定位系统通信以确定计算设备102的位置。该位置可以作为与实时视频流相关联的元数据的一部分。计算设备102还包括各种网络接口电路，例如移动网络接口126(计算设备可以通过其与蜂窝网络通信)、Wi-Fi网络接口128(计算设备可以利用其与Wi-Fi基站182通信)、蓝牙网络接口130(计算设备可以利用其与其他蓝牙设备(例如外部摄像机、麦克风或扬声器)通信)、和/或以太网连接或能够使计算设备102访问网络150的其他有线连接。计算设备102可以包括其他传感器(未示出)，例如环境光传感器、温度传感器、加速度计等。

视频流应用程序132可以配置为使计算设备102的用户能够开始实时视频流。在一些实施方式中，可以通过社交媒体平台共享实时视频流。当视频流的来源是视频捕获设备而不是存储介质时，视频流是实时的或即时的。视频捕获设备可以是与计算设备102通信的摄像机(例如摄像机116)，例如与计算设备102通信(例如通过蓝牙接口130或Wi-Fi接口128)的、无人机上的摄像机或者安装在头盔上的摄像机。视频流应用程序132可以是移动应用程序，或者可以是基于网络的应用程序。视频流应用程序132可以配置为使得用户能够为实时视频流选择隐私设置。隐私设置控制广播的潜在观众(例如任何人都可以看到，或者更具限制性的东西)。

在接收来自想要开始广播的用户的请求后，视频流应用程序132可以配置为使用计算设备102的各种组件或与计算设备102通信的组件来捕获和发送实时视频流并且显示来自实时视频流的观看者的交互(例如参与的表示)。例如，视频流应用程序132可以使用计算设备102的摄像机116、GPS124和麦克风122来捕获具有音频的实时视频流。在一些实施方式中，GPS124可以将位置与实时视频流相关联。在一些实施方式中，视频流应用程序132可以包括质量引擎134，质量引擎134可以配置为通过网络150确定设备102和服务器160之间的吞吐量。吞吐量表示可用于将实时视频流从设备102传输到服务器160的带宽。当带宽低时，质量引擎134配置为降低发送到服务器160的视频质量。这与传统的流系统不同，这是因为广播视频流应用程序132基于广播设备102可用的带宽决定了观看者可用的最高视频质量。视频流应用程序132可以配置为一次一帧地向内容服务器(例如服务器160)提供实时视频流。降低或提高提供给服务器160的视频广播中的帧的视频质量表示实时视频流中的不连续。

视频流应用程序132配置为将来自广播计算设备102的实时视频流提供给内容服务器，例如服务器160。内容服务器还可以称为视频流服务器。服务器160可以是单个计算设备，或者可以是通信地连接以共享工作负载和资源的两个或更多个分布式计算的表示。在一些实施方式中，服务器160是社交媒体平台服务器。服务器160还可以包括形成在配置为执行指令的基板中的一个或多个处理器178。指令可以存储在存储器(例如RAM、闪存、缓存、磁盘、磁带等)中。此外，服务器160可以包括配置为以持久方式存储数据的一个或多个数据存储器。例如，服务器160可以存储连接图168。连接图168可以是表示一个或多个实体之间的关系(即连接)的数据结构。例如，连接图168可以是跟踪社交媒体账户之间的关系的数据集。关系可以包括朋友、追随、喜欢、联系或一些其他关系。在一些实施方式中，连接图168可以表示已经安装了视频流应用程序132并通过交互式流应用程序建立用户账户的实体。

在一些实施方式中，连接图168可以表示来自多于一个社交媒体平台的实体或已经安装了各种社交媒体应用程序的实体。因此，连接图168可以理解为表示多个不同的数据源，每个数据源表示用于单独的社交媒体平台的单独的一组实体和关系。在一些实施方式中，一个数据存储器中的第一用户帐户可以包括用于第二数据存储器中的第二用户帐户的标识符，其中第一用户帐户和第二用户帐户对应于单个人类用户。因此，视频流引擎170可以能够通过第一用户帐户和第二用户帐户之间的联系访问第二数据存储器。因此，系统可以通过这种连接的帐户访问第二社交媒体平台。人类用户可以控制这种连接。

服务器160还可以包括视频流引擎170。在一些实施方式中，视频流引擎170可以服务于社交媒体平台，并且因此可以访问用于社交媒体平台的连接图168。但是视频流引擎170不需要连接到社交媒体平台或服务于社交媒体平台。视频流引擎170可以配置为接收来自广播计算设备102的开始实时视频流的请求。在接收请求时，视频流引擎170可以为请求分配用于标识为请求所接收的实时流视频广播视频流标识符和音频流标识符。视频流引擎170还可以为实时流内容生成LHLS播放列表166。LHLS播放列表166包括至少两个分段文件。每个分段文件包括有限的表头数据，但在其创建时没有视频帧。由于分段文件最初缺少任何关联的视频帧，因此分段文件在生成时被视为缺少内容。这不同于HLS协议，对于HLS协议必须使用内容生成分段文件。对于分段文件的每一个来说，表头数据都是相同的并且包括标识音频流标识符和视频流标识符的表头。在一些实施方式中，表头的第一个字节是流索引。表头内容由mpeg2传输流标准指定。它由包含ISO/IEC 13818-1:2013(E)中规定的PMT和PAT的mpeg2传输流包组成。表头是在客户端请求分段文件时发送到客户端的第一块。当与该分段相关联的、媒体的帧变得可用时，服务器将它们作为后续块发送到客户端。分段文件包含在所存储的视频流文件168中。在一些实施方式中，视频流引擎170可以包括生成LHLS播放列表166和分段文件的低延迟HLS引擎176。

一旦广播者开始实时流视频广播，视频流引擎170就可以开始接收视频帧用于广播。当接收到视频帧时，视频流引擎170可以确定视频帧是否是中断帧。中断帧表示应该写成另一分段文件中的第一帧的帧。中断帧可以表示改变实时流视频广播的视频属性的不连续。中断帧还可以表示在广播中达到的基于时间的间隔。例如，视频流引擎170可以配置为存储目标持续时间(例如3秒、5秒、10秒等)的分段文件。基于时间的间隔表示目标持续时间。当接收到视频帧时，视频流引擎170将每个帧与分段文件(例如当前分段文件)相关联。该当前分段文件是LHLS播放列表166中列出的第一文件。一旦视频流引擎170将足够的帧与分段文件相关联以达到目标持续时间，视频流引擎170就可以查找下一个关键帧。关键帧是全帧数据。在一些实施方式中，广播设备102a可以以规律间隔写入全帧数据，并且跟随关键帧的帧可以仅包括改变自先前帧的数据。在这种方式下，一些实施方式可以压缩实时流视频广播中的数据。关键帧出现的间隔独立于目标时间(或者换言之，用于确定分段文件结束的基于时间的间隔)。当在已经达到基于时间的间隔之后遇到下一个关键帧时，该关键帧是中断帧。

当视频流引擎170遇到中断帧时，它关闭当前分段文件，发送当前分段文件的文件结束指示，创建新的分段文件，并且通过移除当前分段文件以及将新的分段文件添加到播放列表166的末尾来更新LHLS播放列表166。视频流引擎170将中断帧与新的当前分段文件(作为更新的播放列表166中的第一分段文件的分段文件)相关联，将视频信息添加到中断帧，并且开始将接收自广播设备102的帧与该新的当前分段文件相关联。当更新播放列表166时，视频流引擎170可以将更新的LHLS播放列表166传输到缓存服务器161，例如内容分发网络(CDN)中的服务器。缓存服务器161是配置为利用HTTP传输向观看设备(例如设备102b)提供文件的任何服务器。视频流引擎170可以将帧作为分块HTTP传输传输到缓存服务器161。换言之，视频流引擎170可以在接收到帧时传输帧，而不是将帧写入分段文件并且然后将分段文件作为整体传输到缓存服务器161。

在一些实施方式中，视频流引擎170还可以包括HLS引擎174和/或RTMP引擎172。HLS引擎174和RTMP引擎172是可选的。通过持久连接(例如利用RTMP协议或与其类似的协议)，RTMP引擎172可以将从广播者获得的实时视频流提供给一个或多个观看者。HLS引擎174可以生成HLS播放列表164并将HLS播放列表164提供给缓存服务器161。HLS播放列表164可以标识由LHLS引擎176生成的分段文件中的一个或多个。换言之，HLS播放列表164和LHLS播放列表166可以使用相同的分段文件。不同之处在于LHLS播放列表166在分段文件尚未完成时(例如可以将另外的帧添加到分段文件中)标识分段文件，其中HLS播放列表164标识完整的分段文件(例如没有另外的帧将添加到文件中)。在LHLS播放列表166中，被标识的分段文件中的至少一些将还不具有与它们相关联的任何内容(例如帧)。因此，LHLS播放列表166不能包括分段文件的准确的持续时间，而HLS播放列表164中的每个分段文件的持续时间是必需的。

在一些实施方案中，视频流引擎170可以配置为接收来自客户端观看设备(例如设备102b)的参与并且与被提供给各客户端设备的视频流一起提供参与指示。视频流引擎170还可以向广播设备(例如设备102a)提供参与指示。参与可以与实时视频流中的特定时间相关联。例如，参与可以与由时间戳数据包所表示的时间相关联，所述时间戳分组与接收参与时所显示的视频帧相关联。参与是来自观看者中的一个的某种类型的互动。例如，赞赏信号是一种参与类型，其中观看者在实时视频流期间的特定时刻表达认可。该时刻可以由时间戳分组中与客户端设备接收到参与时所正在显示的帧相关联的时间来表示。参与的另一示例是观看者提供的评论。另一示例是共享，其可以具有相应的共享通知，告知其他观看者和广播者，观看者已经邀请了其他观看者。视频流引擎170可以提供参与视频流的指示，以鼓励观看者和广播者之间的交互。在一些实施方式中，视频流引擎170可以集聚不同类型的参与，生成广播的统计数据。

服务器160可以将已存储的视频流文件168存储有限的时间(例如12或24小时)。例如，当广播者完成实时广播时，广播者可以选择使视频流可用于重播。因此，服务器160可以将视频流存储在已存储的视频流文件168中。在一些实施方式中，服务器160可以将为LHLS(以及可能地HLS)传输生成的所有分段文件存储为视频流文件168，并且制作可用于重播的整个系列的分段文件。例如，可以在用于特定实时视频流的播放列表(例如扩展的M3U播放列表)中标识该实时视频流的分段文件。扩展的M3U播放列表也用于HLS协议。在可获取自https://tools.ietf.org/html/draft-pantos-http-live-streaming-19的用于HTTP实时流的互联网草案(Internet-Draft)中描述了扩展的M3U播放列表和HLS协议，其通过引用并入本文。

系统100还可以包括缓存服务器161。缓存服务器161表示内容分发网络中的服务器，并且通过网络150(例如因特网)向客户端设备102提供文件传输。服务器160可以通过网络150将LHLS播放列表166和HLS播放列表提供给缓存服务器，这使得播放列表可用于观看设备。服务器160还通过分块HTTP传输将实时流广播的帧传输到缓存服务器161，并且缓存服务器161可以依次通过分块HTTP传输将帧提供给观看设备102。应当理解的是，在服务器160接收用于特定分段文件的中断帧(其定义分段文件的结束)之前，可以将该分段文件的帧提供给观看设备102。这不同于在HLS下服务器160将整个分段文件提供给缓存服务器161，而这在服务器160处已经接收到分段文件的所有帧之前不能完成。此外，观看设备102在其可以开始播放整个分段文件中的帧之前，必须在HLS下接收来自缓存服务器161的该分段。因此，在分段文件的持续时间为3秒的情况下，在HLS下的延迟约为10秒。相比之下，由于使用LHLS传输的帧在它们一被接收就可以被发送到缓存服务器161并且然后发送到观看设备102，这些帧利用LHLS协议通过分块HTTP传输快得多地到达观看设备102，并且延迟大约是2秒钟。

消费者计算设备102的视频流应用程序132可以配置有观看用户界面或回放操作，这使得潜在的观看者能够接收关于实时视频流的通知，加入流并且以评论或赞赏信号的形式提供反馈。例如，视频流应用程序132可以包括LHLS观看引擎136。在一种实施方式中，一旦观看者选择要观看的实时视频流，计算设备102的视频流应用程序132可以配置为下载用于该流的LHLS播放列表并且通过分块HTTP传输接收来自缓存服务器161的实时视频流。例如，视频流应用程序132可以配置为周期性地(例如每秒)下载LHLS播放列表166以确定用于实时视频流的播放列表166是否已经改变。视频流应用程序132下载播放列表166的时段应该短于分段文件的估计的持续时间，以确保不间断地进行回放。例如，由于不连续，某些分段文件可能比预期短得多。当LHLS播放列表166改变时，视频流应用程序132的回放操作可以在新的分段文件一出现在播放列表166中时就请求该新的分段文件。但是，在接收上一分段的内容已完成的指示之前，不将数据放置在用于该新的分段文件的解码流水线中。由于在LHLS协议中不知道分段文件的持续时间，所以视频流应用程序132的回放操作可以查找每个分段的文件结束(EOF)标记。当接收到EOF标记时，视频流应用程序132可以开始解码并且将来自下一分段文件的内容呈现在播放列表中。可以在分段文件的传输中将EOF标记作为最后的HTTP块接收。一旦广播者结束广播，最后一个分段的最后一个块可以包括广播结束标记。当视频流应用程序132接收广播结束标记时，它可以停止回放。广播结束标记是最后一个分段的内容的一部分，并且是H.264视频规范的一部分。

在一些实施方式中，视频流应用程序132或者应用程序114还可以配置为通过HLS协议接收实时视频流。例如，利用分块HTTP传输来观看实时流视频广播的LHLS观看器可以提供比利用HLS协议的观看器低得多的延迟时间。因此，在一些实施方式中，视频流应用程序132可以在利用LHLS观看实时流视频时启用参与，但在利用HLS时禁止参与。

图2a是HLS播放列表164和LHLS播放列表166的示意图。示例LHLS播放列表166包括三个分段文件205。出现在LHLS播放列表166中的分段中的至少一些在它们在服务器上完成之前出现在播放列表中。在图2a的示例中，标识为seg1276.m3u8的分段文件205表示来自标识为seg1275.m3u8的分段文件205的不连续。换言之，seg1276.m3u8具有与seg1275.m3u8不同的视频属性。在传统的HLS播放列表(例如HLS播放列表164)中，必须用不连续标签210来标识这种不连续。在图2a的示例中，HLS播放列表164表示在接收到与分段文件的每一个相关联的内容之后生成的播放列表文件。因此，例如，在为相同分段文件生成LHLS播放列表166和HLS播放列表的系统中，HLS播放列表164在时间上晚于LHLS播放列表166生成。例如，LHLS播放列表166可以在第一帧首次与分段文件seg1275相关联之前或者首次与分段文件seg1275相关联之时生成，而HLS播放列表164可以在seg1277的最后一帧被接收并添加到分段文件中之后生成。因此，可以理解，LHLS播放列表166表示比HLS播放列表164更早的时刻(例如5到10秒之前)。需要时刻上的差异来显示对于相同的帧而言LHLS播放列表166如何不同于播放列表164。

除了包括标记分段文件之间的不连续的标签215之外，必须利用不连续序列标签215在HLS播放列表164中标识不连续的序列。相比之下，LHLS播放列表166缺少用于不连续的标记，因为事先不知道它，例如，何时分段文件被添加到播放列表、何时将发生不连续。这是由于(如上所述)LHLS播放列表166中的分段文件205中的至少一些仅是占位符，并且在与分段相关联的内容(例如帧)可用之前LHLS播放列表166被写入。

除了缺少不连续标记之外，LHLS播放列表166缺少分段文件的准确持续时间并且可能根本没有任何持续时间。可以提供目标持续时间220，但是当将分段文件添加到HLS播放列表166时，分段文件的最终持续时间是未知的。分段文件的最终持续时间可以比目标持续时间220短得多或长得多。因此，可以理解，目标持续时间220仅是近似值，并且在一些实施方式中是可选的。相比之下，HLS播放列表164包括实际持续时间225，该实际持续时间225表示以秒为单位的分段长度。优选地，实际持续时间225是浮点数以增加持续时间的准确性。实际上，持续时间225必须接近分段文件的实际持续时间以使HLS协议起作用。

图2b是另一LHLS播放列表166'的示意图。示例LHLS播放列表166'包括图2a的LHLS播放列表166的三个相同的分段文件205以及附加的分段文件(seg1278.m3u8)，并且表示广播中较晚的时间(即在已经完全写入seg1275.m3u8之后)。播放列表166'示出了可以包括在LHLS播放列表中的可选标签。例如，日期-时间标签230记录了创建分段205的绝对时钟时间。该标签也可以包括在HLS播放列表164中，并且是HLS协议的一部分。正在进行的标签235对于LHLS播放列表是唯一的，并且指示正在进行的或未完全写入的分段。这些标签可以包括在LHLS播放列表中，以通过使播放器而不是服务器决定播放列表中的哪个分段在播放器加入时开始播放来减少初始延迟。

填充回放缓冲区达到期望的回放开始阈值(到第一帧的时间)所花费的时间、最终回放缓冲区大小、以及因缓冲所导致的延迟完全取决于在播放器加入的那一刻广播行进通过分段的确切距离。当数据的传递因网络抖动而可变时，客户端的回放缓冲区允许回放不间断，但也会增加延迟。因此，在较差的网络设置中较高的延迟和较少的停顿之间存在折衷。

对于大多数播放器来说，对于到第一帧的时间，广播以远低于播放器下载带宽的比特率进行编码，这是由于广播者的上传带宽通常远低于播放器的下载带宽。这意味着如果从已经完全被写入的更旧分段开始，播放器可以以完全下载速度下载。这也意味着如果播放器以当前正在被编码的帧开始，则播放器在该帧创建时实时填充回放缓冲区。因此，当播放器以已经写入的更旧的分段开始时，播放器可以在不到半秒的时间内填充2秒缓冲区，而实时填充回放缓冲区则需要整整2秒。

利用HLS播放列表164和LHLS播放列表166，播放器在第一文件的开始处开始。在播放列表的开头开始意味着创建播放列表的服务器(例如服务器160)决定回放缓冲区的长度和到第一帧的时间。相比之下，LHLS播放列表166'包括另外的标签230和235，另外的标签230和235使得播放器能够基于播放器的本地网络状况动态地决定回放缓冲区的长度和到第一帧的时间。

为了提供播放器所需的信息以动态地确定回放缓冲区和到第一帧的时间，在一些实施方式中，播放列表166'更长(例如包括多于三个条目)。最后两个条目(例如标识为seg1278.m3u8的分段文件205和标识为seg1277.m3u8的分段文件205)仅具有PAT/PMT表头(例如是占位符条目)。之前的那个，即倒数第二个条目(例如标识为seg1276.m3u8的分段文件205)是当前正被写入的那个。此条目之前的任何条目都已完全被写入，并且可以以下载带宽将被立即下载到播放器的下载缓冲区中。播放器可以使用关于网络状况的试探法来决定使用多大的回放缓冲区，然后使用日期-时间标签230和正在进行的标签235来决定播放列表中的哪个分段开始播放。在一些实施方式中，播放器可以使用以下中的一个或多个来计算回放缓冲区持续时间：1)从广播者到服务器的帧到达抖动的最近的测量值，2)用于当前广播的从服务器到客户端的帧到达抖动，以及3)确保最小的缓冲区大小的常量。在一些实施方式中，播放器可以使用广播者到服务器抖动的、服务器到客户端抖动的最大值、和最小缓冲区大小来计算回放缓冲区持续时间。当前广播的服务器到客户端抖动仅在停顿后重新缓冲时可用。对于广播者到服务器的抖动分量，服务器可以记录来自广播者的帧的到达间隔时间，并计算在过去30秒内吸收到达间隙所需的缓冲区大小。在一些实施方式中，LHLS播放列表166可以包括记录抖动值的定制标签(图2b中未示出)。在一些实施方式中，播放器还可以查看播放器处的到达间隔是否在某个时段内已经一致。

图3是示出根据一种实施方式的过程300的流程图，该过程300描绘了提供基于HTTP的低延迟实时流媒体广播的内容服务器的示例操作。示例操作可以作为包括媒体流引擎(例如图1的视频流引擎170)的系统的一部分来执行。在一些实施方式中，媒体流引擎可以包括LHLS引擎以及HLS引擎和其他组件(如参考图1的服务器160所解释的)。关于单个实时流媒体广播描述了示例过程300，但是媒体流引擎可以能够一次处理多个这样的实时流。因此，可以理解，媒体流引擎可以针对任何数量的实时流媒体广播同时执行过程300。为方便起见，将过程300描述为视频广播，但是实施方式也包括实时音频广播。

过程300开始于创建至少两个分段文件(305)。系统可以响应于接收开始实时流视频广播的请求而创建分段文件。系统可以创建具有头信息(例如包括用于音频流的标识符和用于视频流的标识符但没有内容的表头)的分段文件。这些标识符可以响应于启动实时流视频的请求而由系统生成。因此，对于该实时流视频的每个分段文件，头信息是相同的，但是在不同的流之间是不同的。系统还可以创建标识至少两个分段文件的播放列表(310)。播放列表可以包括两个分段文件中的每一个的目标时间或目标持续时间。目标持续时间是近似的持续时间，这是由于实际分段文件可能比近似的持续时间短得多或长得多。例如，目标持续时间可以是3秒，但是一旦内容与分段文件相关联，分段文件可能由于不连续而仅为1.25秒，或者可能由于遇到3秒后的下一个关键帧时而为4.5秒长。因此，播放列表中的目标持续时间不是近似值。图2a的播放列表166和图2b的播放列表166'是播放列表的示例。

系统可以将播放列表和至少两个分段文件发送到缓存服务器(315)。缓存服务器可以是内容分发网络中的服务器。内容分发网络是通常通过互联网向用户分发内容(例如网页和其他文件)的分布式服务器系统。传输到缓存服务器的一个或多个(或所有)分段文件没有内容，或者换言之，没有来自实时流视频但是与其相关联的帧。此时，这些文件是仅使用头数据生成的占位符。头数据允许播放器(例如观看设备(如图1的设备102b))请求下载文件，使得一旦内容与文件相关联，它就可以通过HTTP块传送。

系统可以开始一次一个地接收来自实时流视频广播的帧(320)。对于接收到的每个帧，系统可以确定该帧是否是中断帧(325)。中断帧可以是在达到目标时间之后发生的不连续或关键帧。关键帧是全帧数据。在一些实施方式中，广播设备可以以规律间隔写入全帧数据，并且跟随关键帧的帧可以仅包括改变自先前帧的数据。关键帧出现的间隔(或者换言之，用于确定分段文件结束的基于时间的间隔)独立于目标时间。因此，分段文件最终可能比播放列表中的分段文件的目标持续时间长。中断帧也可以是不连续。不连续是视频属性发生变化的帧。例如，如果广播者切换输入设备(例如从电话摄像头切换到无人机摄像机或安装在头盔上的摄像机)，则会发生这种情况。如果广播设备的吞吐量发生改变，也会发生这种情况，从而使视频质量更好或更差。当实时流视频广播中的这种变化发生时，系统可以检测到不连续并且可以将具有新的视频属性的第一帧视为中断帧。

如果帧不是中断帧(325，否)，则系统可以将帧作为与当前分段文件相关联的块进行传输(355)。当前分段文件是在播放列表中列为第一位的分段文件。步骤355还将帧与分段文件相关联。因此，例如，系统可以将帧写入例如存储在视频流服务器160处的分段文件。以这种方式，系统可以构建分段文件，该分段文件也可以用于利用HLS传输实时流视频广播。换言之，在将帧与分段文件相关联而结束系统之后，系统可以将完整的分段文件和HLS播放列表传输到缓存服务器。

如果帧是中断帧(325，是)，则系统可以确定中断帧是否是该广播遇到的第一中断帧(335)。如果是第一中断帧(335，是)，则系统可以将具有视频头的帧作为块发送到缓存服务器(355)。如果帧不是第一中断帧(335，否)，则系统可以传输用于当前分段文件的文件结束(EOF)标记(340)。EOF标记指示当前分段文件已完成，或者换言之，具有与其相关联的所有内容。EOF标记向媒体播放器指示已经接收到该分段的所有HTTP块，并且播放器可以从播放列表中的下一分段文件开始解码并且进行呈现。没有EOF标记，播放器不知道对下一分段开始下载和解码流水线。在系统提供HLS以及LHLS中的实时流视频广播的实施方式中，系统还可以完成分段文件并利用已完成的分段文件创建或更新HLS播放列表。可以将已更新的HLS播放列表和已完成的分段文件传输到缓存服务器。当然，与该分段文件相关联的帧已经通过分块HTTP传输在LHLS协议下传输到缓存服务器。因此，在HLS观看者能够开始下载分段文件之前，使用LHLS来接收实时流媒体广播的用户已经观看了与该分段文件相关联的帧。

系统还可以创建新的分段文件，例如，创建下一个分段文件并将标识实时流视频广播的头信息写入新的分段文件(345)。系统还可以更新播放列表文件，删除当前分段文件(例如列在第一位的文件)并且添加新创建的分段文件。这意味着当前分段文件已经改变(它是以前列为播放列表中第二条目的文件，但现在是第一条目，这是因为删除了先前列为第一的分段文件)。系统还可以更新播放列表中的媒体序列标签(如果包括在播放列表中的话)。例如，如果播放列表最初列出seg1、seg2和seg3，其中seg1是当前分段文件，则更新的播放列表可以标识seg2、seg3和seg4，其中seg2现在是当前分段文件并且可以将媒体序列标签设置为2，指示已从播放列表中删除至少一个分段。然后，系统可以将新的播放列表和新的分段文件传输到缓存服务器(350)。如前所述，在观看设备上运行的播放器可以配置为以规律间隔下载播放列表，因此传输更新的播放列表使得更新可供下载给观看者(正如针对图4更为详细地解释的)。

然后，系统可以将帧作为当前分段文件的块进行传输(355)。系统保持接收实时流视频广播的帧(320)，通过分块HTTP传输发送帧，并且如上所述确定在何处中断分段文件。当系统接收来自广播设备的广播结束的指示或超时时(例如未能在预定时间范围内接收用于实时流视频广播的帧)，过程300可以结束。在广播结束时(无论是由广播者还是由超时发起)，系统可以向播放列表添加广播结束标记并将更新的播放列表传输到缓存服务器。系统可以在最后一个分段文件之后在播放列表中插入广播结束标记以使内容与其相关联，并且可以移除在广播结束标记之后出现的、播放列表中的任何分段文件。

图4是根据一种实施方式的示例过程400的流程图，该过程描绘了接收低延迟HTTP实时流(LHLS)协议的回放设备的示例操作。过程400可以由在实时流视频广播系统的观看设备(例如图1的设备102a或102b)上执行的视频流应用程序执行。过程400可以使观看设备能够将实时广播视频流的帧作为分块HTTP传输接收，使得延迟(例如由广播者提供帧和由观看者观看帧之间的时间)低，大约为2秒钟。分块HTTP传输使得观看设备甚至在接收到分段文件的最后一帧之前(或者换言之，在分段文件完成之前)有可能开始观看分段文件的帧。

当观看设备请求要加入的实时流视频广播时，过程400开始(405)。可能已经由广播者或观看广播的某人就有关实时流视频通知了观看设备，或者可以从搜索界面对观看设备标识广播，等等。作为响应，观看设备可以接收用于实时流视频广播的低延迟HLS播放列表(410)。播放列表可以是图2a的播放列表166或者图2b的播放列表166'的示例。因此，播放列表包括作为占位符的至少一个分段文件(即分段文件还没有与其相关联的视频流内容)。播放列表也可以缺少分段文件的实际持续时间。相反，在一些实施方式中，播放列表可以具有目标持续时间。目标持续时间有时可能超出分段文件的实际最终持续时间50％或更多。因此，目标持续时间并不总是最终持续时间的近似值，并且不需要接近最终持续时间。在一些实施方式中，观看设备可以使用播放列表中的标签来确定回放缓冲区的大小和要请求哪个文件(如上面针对图2b所述)。

然后，观看设备可以从缓存服务器请求播放列表中列出的分段文件(415)。对第一分段的请求将首先获得在所述请求到达的时间之前在该分段中已累积的任何媒体，但是将在块于该分段的剩余持续时间内从广播者到达服务器时获得这些块。对任何另外的分段的请求都接收分段头，但在第一分段完成之前不会接收另外的信息。缓存服务器可以通过分块HTTP传输提供所请求的文件。因此，观看设备可以接收用于播放列表中的分段文件的分块HTTP传输(420)。传输包括指示传输针对哪个分段文件的头。观看设备可以确定块是否是文件结束标记(425)。如果块是文件结束标记(425，是)，则观看设备可以开始解码并呈现来自播放列表中的下一分段文件的视频流(435)。换言之，文件结束标记向观看设备发信号通知不再接收该分段文件的块，并且观看设备可以开始解码播放列表中的下一分段文件。由于在播放列表中没有标记不连续，所以观看设备可以能够获得下一分段文件的第一帧中的视频参数并且能够利用视频参数来设置回放参数。例如，H.264视频编码标准中的序列和图片参数集(SPS和PPS)出现在每个分段开始处的H.264IDR帧中。H.264IDR帧是开始新分段文件的中断帧。视频解码器可以将IDR帧中的SPS PPS与当前使用的参数集进行比较，并且如果它们已经改变，则解码器可以根据需要重置参数。作为另一示例，视频解码器可以寻找时间戳序列中的不连续(例如通过检查PCR中的跳转，其中PCR是传输流文件中通常单调增加的时间码)。因此，例如，观看设备可以调整质量或维度参数，使得回放与从第一帧获得的视频参数相匹配。

如果块不是文件结束标记(425，否)，则观看设备可以将帧添加到用于分段文件的解码流水线(430)。过程400可以继续(例如观看设备可以继续接收用于实时流视频广播的分块HTTP传输并且将它们放入流水线中)，直到(例如在更新的播放列表文件中)标识出广播结束标记。

尽管观看设备正在接收分块HTTP传输，它还可以周期性地检查更新的播放列表(440)。例如，大约每秒，观看设备就可以向缓存服务器发送对播放列表的请求。如果播放列表已经更新(440，是)，则观看设备可以发送对已添加到播放列表的新分段文件(一个或多个)的请求(445)。因此，观看设备可以准备接收已添加到播放列表的另外的分段文件，包括为新分段文件设置解码队列。观看设备可以在当前分段结束之前接收分段头但不接收媒体。在在播放列表中的分段可用很早以前为播放列表中的分段进行通告的好处在于它消除了因客户端播放列表轮询频率和CDN缓存中的播放列表TTL而导致的播放列表延迟的问题。如果更新的播放列表包括广播结束消息而不是新分段文件，则观看设备可以设置将使得过程400在步骤435结束的标志，而不是开始解码和呈现下一分段文件。

图6是针对LHLS和HLS对在观看设备处所接收的视频帧随时间变化进行比较的曲线图。在图6的示例中，对于LHLS和HLS，分段持续时间固定为2秒。对于LHLS而言，帧由于块传输编码响应而持续地到达。由于分段早在它们处于“实时”之前就出现在媒体播放列表中，所以因CDN缓存中的播放列表TTL和观看设备的播放列表轮询频率而导致的播放列表延迟不会中断媒体的稳定到达。相比之下，对于HLS而言，观看设备只能在分段在服务器上完成后并且在客户端接收更新的播放列表后请求分段。因此，帧到达是突发性的，通常在周期性的分段请求之间不向缓冲区添加帧。

图7是对于图6中使用的示例视频到达轨迹针对LHLS和HLS的回放缓冲区充满度进行比较的曲线图。在图7的示例中，在为LHLS和HLS缓冲4秒的媒体之后开始回放。对于HLS而言，缓冲区在帧的每个突发到达之间稳定地清空。对于LHLS而言，帧到达更加连续并且缓冲区状态更加恒定。在带宽波动期间，回放缓冲区占用率下降到2.75秒。相比而言，HLS缓冲区占用率经常下降到1秒以下。

图5示出了计算设备500的示例形式的机器的图形表示，其中可以执行用于使机器执行本文所讨论的任何一种或多种方法的一组指令。计算设备500可以是手机、智能手机、上网本电脑、机架式服务器、路由器计算机、服务器计算机、个人计算机、大型计算机、笔记本电脑、平板电脑、台式电脑等，在其内部可以执行用于使机器执行本文所讨论的任何一种或多种方法的一组指令。在一种实施方式中，计算设备500可以向用户呈现覆盖的UI(如上所述)。在替代实施方式中，机器可以连接(例如联网)到LAN、内联网、外联网或互联网中的其他机器。机器可以在客户端-服务器网络环境中以服务器机器的能力运行。该机器可以是个人计算机(PC)、机顶盒(STB)、服务器、网络路由器、交换机或网桥、或能够执行一组指令(顺序的或其他方式)的任何机器，其中所述一组指令对由该机器实施的动作进行指定。此外，虽然仅示出了单个机器，但术语“机器”还应被视为包括单独或联合执行一组(或多组)指令以执行本文所讨论的任何一种或多种方法的机器的任何集合。

示例计算设备500包括处理装置(例如处理器)502、主存储器504(例如只读存储器(ROM)、闪存、动态随机存取存储器(DRAM)(例如同步DRAM(SDRAM))、静态存储器506(例如闪存、静态随机存取存储器(SRAM))和数据存储装置518，它们通过总线530彼此通信。

处理装置502表示一个或多个通用处理装置，例如微处理器、中央处理单元等。更特别地，处理装置502可以是复杂指令集计算(CISC)微处理器、精简指令集计算(RISC)微处理器、超长指令字(VLIW)微处理器或执行其他指令集的处理器或执行指令集的组合的处理器。处理装置502还可以是一个或多个专用处理装置，例如专用集成电路(ASIC)、现场可编程门阵列(FPGA)、数字信号处理器(DSP)、网络处理器等。处理装置502配置为执行指令526(例如用于应用程序排序系统的指令)用于执行本文所讨论的操作和步骤。

计算设备500还可以包括可以与网络520通信的网络接口装置508。计算设备500还可以包括视频显示器510(例如液晶显示器(LCD)或阴极射线管(CRT))、字母数字输入装置512(例如键盘)、光标控制装置514(例如鼠标)和信号生成装置516(例如扬声器)。在一种实施方式中，视频显示器510、字母数字输入装置512和光标控制装置514可以组合成单个组件或设备(例如LCD触摸屏)。

数据存储装置518可以包括计算机可读存储介质528，其上存储有一组或多组指令526(例如用于应用程序排序系统的指令)，其体现本文所述的任何一种或多种方法或功能。指令526还可以在由计算设备500执行期间完全或至少部分地驻留在主存储器504内和/或处理装置502内，主存储器504和处理装置502也构成计算机可读介质。还可以经由网络接口装置508在网络520上发送或接收指令。

虽然计算机可读存储介质528在示例实施方式中显示为单个介质，但是术语“计算机可读存储介质”应视为包括存储一组或多组指令的单个介质或多个介质(例如集中式或分布式的数据库和/或相关联的缓存和服务器)。术语“计算机可读存储介质”还应被视为包括能够存储、编码或携带一组指令以供机器执行并且使机器执行本公开的任何一种或多种方法的任何介质。因此，术语“计算机可读存储介质”应被视为包括但不限于固态存储器、光学介质和磁介质。术语“计算机可读存储介质”不包括瞬态信号。

在以上描述中，阐述了许多细节。然而，对于受益于本公开的本领域普通技术人员显而易见的是，可以在没有这些具体细节的情况下实践本公开的实施方式。此外，实施方式不限于某些操作的确切顺序，并且应当理解的是，可以对示出为两个步骤的某些操作进行组合，并且可以将示出为一个步骤的某些操作进行分割。在一些情况下，众所周知的结构和设备以框图形式而不是详细地示出，以避免模糊描述。

详细描述的一些部分是根据对计算机存储器内的数据位的操作的算法和符号表示来呈现的。这些算法描述和表示是数据处理领域的技术人员用来最有效地将他们工作的实质传达给本领域其他技术人员的手段。算法在这里并且通常被认为是导致期望结果的自相一致的步骤序列。这些步骤是需要物理地操纵物理量的步骤。通常，尽管不是必须的，这些量采用能够被存储、被传输、被组合、被比较和以其他方式操纵的电信号或磁信号的形式。有时，主要出于通用的原因，已经证明将这些信号称为比特、值、元件、符号、字符、术语、数字等是方便的。

然而，应该记住，所有这些和类似术语都与适当的物理量相关联，并且仅仅是应用于这些量的方便的标签。除非从上面的讨论中明确说明，否则应当理解，在整个说明书中，利用例如“识别”、“确定”、“计算”、“更新”、“传输”、“接收”、“生成”、“改变”等术语进行的讨论是指计算机系统或类似电子计算设备的动作和过程，所述计算机系统或类似电子计算设备操纵表示为计算机系统的寄存器和存储器中的物理(例如，电子)量的数据并且将其转换到类似地表示为计算机系统存储器或寄存器或其他此类信息存储、传输或显示设备内的物理量的其他数据中。

本公开的实施方式还涉及用于执行本文的操作的装置。该装置可以是为所需目的而专门构造的，或者它可以包括由存储在计算机中的计算机程序选择性地激活或重新配置的通用计算机。这样的计算机程序可以存储在非暂时性计算机可读存储介质中，例如但不限于任何类型的盘，包括软盘、光盘、CD-ROM和磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁卡或光卡、闪存或适用于存储电子指令的任何类型的介质。

本文使用词语“示例”或“示例性”来表示用作示例、实例或说明。本文中描述为“示例”或“示例性”的任何方面或设计不必被理解为比其他方面或设计更优选或更具优势。相反，使用词语“示例”或“示例性”旨在以具体方式呈现概念。如在本申请中所使用的，术语“或”旨在表示包含性的“或”而非排他性的“或”。也就是说，除非另有说明或从上下文中清楚，否则“X包括A或B”旨在表示任何自然的包含性排列。也就是说，如果X包括A；X包括B；或者X包括A和B，然后在任何前述情况下满足“X包括A或B”。另外，本申请和所附权利要求中使用的冠词“一个(a)”和“一个(an)”通常应理解为表示“一个或多个”，除非另有说明或从上下文清楚地指向单数形式。此外，除非如此描述，否则贯穿全文使用术语“一种实施方式”或“一个实施例”或“一种实施方式”或“一个实施方式”并不旨在表示相同的实施例或实施方式。此外，本文使用的术语“第一”、“第二”、“第三”、“第四”等是指用于区分不同元件的标签，并且根据它们的数字标记可以不一定具有序数含义。

本文呈现的算法和显示并非固有地与任何特定计算机或其他装置相关。根据本文的教导，各种通用系统可以与程序一起使用，或者可以证明构造更专用的装置以执行所需的方法步骤是方便的。各种这些系统所需的结构将从下面的描述中看出。另外，不参考任何特定编程语言描述本公开。应当理解，可以使用各种编程语言来实现如本文所述的本公开的教导。

在一个方面，一种计算设备包括至少一个处理器和具有存储在其上的可执行指令的非暂时性计算机可读介质，所述可执行指令当由所述至少一个处理器执行时，配置为执行低延迟视频广播引擎。低延迟视频广播引擎配置为将表头写入至少两个分段文件，该表头标识视频广播流。将表头写入至少两个分段文件响应于开始广播的命令而进行。低延迟视频广播引擎还配置为生成标识至少两个分段文件的播放列表，并且生成用于至少两个分段文件的当前分段文件的视频头，将播放列表和至少两个分段文件传输到缓存服务器，并且开始从广播设备接收视频广播流作为一系列帧。每个帧与当前分段文件相关联，并且作为块通过HTTP块传输传输到缓存服务器。响应于检测到中断帧，广播引擎配置为在将中断帧与当前分段文件相关联之前，将指示和当前分段文件的结束的标记作为块传输到缓存服务器，将至少两个分段文件中的下一分段文件标识为新的当前分段文件，并且生成用于中断帧的视频头，以便视频头与中断帧一起作为块传输到缓存服务器。

在一个方面，一种用于利用现有内容分发网络生成低延迟视频流的方法可以包括为视频广播流创建播放列表。播放列表标识一定数量的分段文件，数量至少为2，并且分段文件的每一个的内容是没有媒体内容的表头。该方法还包括将播放列表和分段文件的每一个传输到缓存服务器，获取视频广播流作为一系列帧，并利用HTTP块传输协议将该系列帧中的每个帧传输到缓存服务器。每个帧与播放列表中标识的第一分段文件相关联并写入第一分段文件。

在一个方面，一种方法包括从缓存服务器接收用于视频广播流的播放列表，该播放列表标识一定数量的分段文件，该数量为至少2个。该方法还可以包括从缓存服务器请求分段文件并且接收具有内容的分块HTTP传输，该传输标识来自播放列表的分段文件。该方法还可以包括确定分块HTTP传输是否是文件结束消息。当分块HTTP传输不是文件结束消息时，该方法包括将传输的内容添加到用于在传输中标识的分段文件的解码流水线，该内容表示视频广播流的帧。当分块HTTP传输是文件结束消息时，该方法包括切换到用于播放列表中的下一分段的解码流水线。在一些实施方式中，该方法还包括基于网络抖动和最小缓冲区大小来确定回放缓冲区长度。网络抖动可以作为播放列表中的参数包括在内。在一些实施方式中，中断帧可以表示视频广播流中的不连续、视频广播流中达到的基于时间的间隔或者视频广播流的关键帧中的一个。在一些实施方式中，播放列表缺少用于分段文件之间的不连续的标记和/或播放列表缺少播放列表中标识的分段文件的持续时间。

在一个方面，一种方法使用现有内容分发网络生成低延迟视频流。该方法包括为视频广播流创建播放列表，该播放列表标识一定数量的分段文件，该数量至少为2，其中分段文件的每一个的内容是表头。该方法还包括将播放列表和分段文件的每一个传输到缓存服务器，获取视频广播流作为一系列帧，并且利用HTTP块传输协议将该系列帧中的每个帧传输到缓存服务器，每个帧与播放列表中标识的第一分段文件相关联并且写入第一分段文件。在一些实施方式中，响应于视频广播流是中断帧，该方法包括传输第一分段文件的文件结束标记，以及在传输之前为中断帧添加视频头。

在一个方面，一种计算机系统包括至少一个处理器和存储指令的存储器，当由所述至少一个处理器执行时，所述指令使计算机系统执行本文描述的方法的任何一个。

Claims (21)

1.一种计算设备，包括：

至少一个处理器；以及

非暂时性计算机可读介质，具有存储在其上的可执行指令，所述可执行指令当由所述至少一个处理器执行时，配置为执行低延迟视频广播引擎，所述低延迟视频广播引擎配置为：

将表头写入至少两个分段文件，所述表头标识视频广播流；

生成标识所述至少两个分段文件的播放列表；

为所述至少两个分段文件中的当前分段文件生成视频头；

将所述播放列表和所述至少两个分段文件传输到缓存服务器；以及

开始从广播设备接收所述视频广播流作为一系列帧，其中每个帧与所述当前分段文件相关联，并且作为块通过HTTP块传输传输到所述缓存服务器，并且

其中，当检测到中断帧时，所述广播引擎在将所述中断帧与所述当前分段文件相关联之前，配置为：

将指示所述当前分段文件的结束的标记作为块传输到所述缓存服务器；

将所述至少两个分段文件的下一分段文件标识为新的当前分段文件；以及

生成用于所述中断帧的视频头，以便所述视频头与所述中断帧一起作为块传输到所述缓存服务器。

2.根据权利要求1所述的计算设备，其中所述中断帧表示所述视频广播流中的中止。

3.根据权利要求1所述的计算设备，其中所述中断帧表示在所述视频广播流中达到的基于时间的间隔。

4.根据权利要求3所述的计算设备，其中所述基于时间的间隔小于4秒。

5.根据前述权利要求中任一项所述的计算设备，其中所述视频头包括所述当前分段文件的尺寸。

6.根据前述权利要求中任一项所述的计算设备，其中所述至少两个分段文件中的至少一个在任何帧与该分段文件相关联之前被写入。

7.根据前述权利要求中任一项所述的计算设备，其中所述低延迟视频广播引擎在传输指示所述当前分段文件的结束的所述标记之后，配置为：

将表头写入所述至少两个分段文件中的新分段文件；

将所述新分段文件添加到所述播放列表；

从所述播放列表移除所述当前分段文件；以及

将所述播放列表和所述新分段文件发送到所述缓存服务器。

8.根据前述权利要求中任一项所述的计算设备，其中所述低延迟视频广播引擎在传输指示所述当前分段文件的结束的所述标记之后，配置为：

将所述当前分段文件添加到与所述视频广播流相关联的HLS播放列表。

9.一种用于利用现有内容分发网络生成低延迟视频流的方法，该方法包括：

为视频广播流创建播放列表，所述播放列表标识一定数量的分段文件，所述数量至少为2，其中所述分段文件中的每个的内容是表头；

将所述播放列表和所述分段文件中的每个传输到缓存服务器；

获取所述视频广播流作为一系列帧；以及

利用HTTP块传输协议将所述一系列帧中的每个帧传输到所述缓存服务器，每个帧与所述播放列表中标识的第一分段文件相关联并写入所述第一分段文件；

其中当所述视频广播流中的帧是中断帧时，所述方法包括：

传输所述第一分段文件的文件结束标记；以及

在传输所述中断帧之前为所述中断帧添加视频头。

10.根据权利要求9所述的方法，其中当所述流中的帧是中断帧时，所述方法还包括：

创建新分段文件，其中所述新分段文件具有表头作为所述新分段文件的内容；

在所述播放列表的末尾添加所述新分段文件；

从所述播放列表中删除所述第一分段文件，使得下一分段文件成为所述播放列表中标识的第一分段文件，所述中断帧被写入所述下一分段文件并与所述下一分段文件相关联。

11.根据权利要求10所述的方法，其中在传输与所述第一分段文件相关联的第一帧之前，所述方法包括将视频头添加到所述第一帧。

12.根据权利要求11所述的方法，其中所述视频头包括与所述第一帧相关联的尺寸。

13.根据权利要求11或12中任一项所述的方法，其中所述视频头包括以表格格式与所述第一帧相关联的属性。

14.根据权利要求9至13中任一项所述的方法，其中所述表头包括用于所述视频广播流的视频流标识符。

15.根据权利要求9至14中任一项所述的方法，其中所述表头包括用于所述视频广播流的音频流标识符。

16.一种方法，包括：

从缓存服务器接收视频广播流的播放列表，所述播放列表标识一定数量的分段文件，所述数量至少为2；

从所述缓存服务器请求所述分段文件；

接收具有内容的分块HTTP传输，所述传输标识来自所述播放列表的分段文件；

确定所述分块HTTP传输是否是文件结束消息；

当所述分块HTTP传输不是文件结束消息时，将所述传输的所述内容添加到用于在所述传输中标识的所述分段文件的解码流水线，所述内容表示所述视频广播流的帧；以及

当所述分块HTTP传输是文件结束消息时，切换到用于所述播放列表中的下一分段的解码流水线。

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

基于网络抖动和最小缓冲区大小确定回放缓冲区长度。

18.根据权利要求17所述的方法，其中所述网络抖动包括在所述播放列表中。

19.根据权利要求16至18中任一项所述的方法，其中所述播放列表包括至少四个分段文件，每个分段文件具有相应的日期-时间标签，并且所述至少四个分段文件中的至少一些分段文件具有相应的正在进行中的标签，并且所述方法还包括：

基于所述正在进行中的标签和所述日期-时间标签，确定回放缓冲区大小和所述至少四个分段文件中要首先请求的特定分段文件。

20.根据权利要求16至19中任一项所述的方法，其中作为切换到解码流水线的一部分，所述方法还包括：

在所述解码流水线读取来自第一帧的视频参数；以及

利用来自所述第一帧的所述视频参数调整视频回放参数。

21.根据权利要求16至20中任一项所述的方法，还包括：

以规律间隔请求所述播放列表；以及

在接收具有新分段文件的更新的播放列表之后，发送对所述新分段文件的请求，其中所述新分段文件通过分块HTTP传输来接收。