用于使用HTTP流的DASH流的方法和装置与流程

本申请一般地涉及传输系统中的媒体数据传递，并且更具体地，涉及基于推送的、自适应的超文本传输协议(HTTP)流。

背景技术：

传统地，传输控制协议(TCP)已经被认为不适合诸如音频和视频内容的实时媒体的传递。这主要是由于TCP实施的激进的拥塞控制算法和重传程序所致。TCP中，发送者在检测到拥塞事件——一般通过丢包或过度的传输延迟来识别时，显著地降低传输速率(通常降低到一半)。因而，TCP的传输吞吐量通常以公知的锯齿形状为特征。这一行为对流应用(streaming application)是不利的，因为它们对延迟敏感但相对能容忍丢包，然而TCP牺牲传递延迟以利于可靠的并且可感知阻塞(congestion-aware)的传输。

技术实现要素：

[技术问题]

近来，趋势已经转向部署作为用于通过互联网传递多媒体内容的首选协议的超文本传输协议(HTTP)。HTTP在TCP的上面运行并且是文本协议。这一转变的原因在于该协议容易部署。不需要部署用于传递内容的专用服务器。而且，HTTP通常被准许经防火墙和NAT进行访问，其显著地简化了部署。

[问题的解决方案]

在第一实施例中，提供了一种设备。该设备包括：天线，被配置为建立与服务器的通信连接。该设备还包括处理电路，被配置为：对服务器支持网络套接字WebSocket上的自适应的超文本传输协议(HTTP)流的能力进行确定；为在HTTP流期间执行速率自适应操作而向服务器发送命令；以及在HTTP流上接收来自服务器的信息。

在第二实施例中，提供了一种服务器。该服务器包括被配置为耦接到至少一个客户端设备的接口。该服务器还包括处理电路，被配置为：向至少一个客户端设备发送关于支持WebSocket上的自适应的超文本传输协议(HTTP)流的指示；接收升级的请求、确定是接受还是拒绝该升级，并且响应于从至少一个客户端设备接收的、在HTTP流期间进行流操作的命令，建立与至少一个客户端设备的传入的WebSocket连接。

第三实施例中，提供了一种用于客户端设备的方法。该方法包括建立与服务器的通信连接。该方法还包括对服务器支持WebSocket上的自适应的超文本传输协议(HTTP)流的能力的确定。该方法进一步包括为了在HTTP流期间执行流操作而向服务器发送命令。

从以下特征、描述和权利要求中，其它的技术特征对本领域技术人员可以是容易显见的。

在进行以下具体描述之前，阐述贯穿本专利文档全文所使用的某些词语和短语的定义可能是有益的。术语“耦接”及其衍生词指代两个或多个元件之间的任意直接或非直接的通信，无论那些元件是否彼此物理接触。术语“发送”、“接收”和“通信”及其衍生词，包括直接和非直接的通信两者。术语“包括”和“包含”及其衍生词，意思是无限制的包括。术语“或”是包括性的，意思是和/或。短语“与…关联”及其衍生词，意思是包括、包括在内、与…互连、包含、包含在内、连接到或与…连接、耦接到或与…耦接、与…通信、与…合作、交织、并列、靠近、与…紧密相连、具有、具有…属性、与…有关系等。术语“控制器”指的是控制至少一个操作的任意设备、系统或其部分。这样的控制器可在硬件或硬件和软件的组合和/或固件中实现。与任意特定控制器关联的功能可以被集中或分布，无论在本地或远端地。短语“至少其一”，当和列表项使用时，意思是一个或多个所列项目的不同组合可以被使用，并且可能只需要列表中的一个项目。例如，“A、B和C中至少一个”包括任意以下组合：A、B、C、A和B、A和C、B和C，以及A和B和C。

并且，以下描述的各种功能可由一个或多个计算机程序实现或支持，每个计算机程序由计算机可读程序代码形成并且在计算机可读介质中具体化。术语“应用”和“程序”指的是一个或多个计算机程序、软件组件、指令集、过程、功能、对象、类、实例、相关的数据及改变以适合在合适的计算机可读程序代码中实现的其部分。短语“计算机可读程序代码”包括任意类型计算机代码，包括源代码、目标代码和可执行代码。短语“计算机可读介质”包括能被计算机访问的任意类型介质，诸如只读存储器(ROM)、随机存取存储器(RAM)、硬盘驱动器、致密盘(CD)、数字视频盘(DVD)或任何其它类型存储器。“非暂态”计算机可读介质不包括传输暂时的电的或其它信号的有线的、无线的、光学的或其它通信链路。非暂态计算机可读介质包括数据可以被永久地存储的介质和数据可以被存储并且之后被重写的介质，诸如可再写光盘或可擦除存储器设备。

贯穿本专利文档全文提供了对于其它某些词语和短语的定义。本领域技术人员应当明白，在许多情况而非大多数情况下，这些定义适用于这样定义的词语和短语的现有的和将来的使用。

附图说明

为了对本公开及其优点的更全面理解，结合附图，对以下描述进行了引用，其中相同的附图标记指代相同的部分：

图1示出了根据本公开的示例计算系统；

图2和图3示出了根据本公开的计算系统中的示例设备；

图4示出了根据本公开的实施例的自适应的HTTP流架构；

图5示出了根据本公开的实施例的MPD结构；

图6和图7示出了根据本公开的HTTP 1.0和HTTP 2.0之间的区别；

图8示出了根据本公开的实施例的支持WebSocket(网络套接字)的网络；

图9示出了根据本公开的实施例的对客户端设备使用WebSocket的自适应的HTTP流过程；以及

图10示出了根据本公开的实施例的对服务器使用WebSocket的自适应的HTTP流过程。

具体实施方式

以下所讨论的图1到图10，和用来描述本专利文档中的发明的原理的各种实施例只作为阐述并且不应被以任何方式解释为限制本公开的范围。本领域技术人员应当理解本公开的原理可在任何适当安排的设备或系统中实现。

图1示出了根据本公开的示例计算系统100。图1所示的计算系统100的实施例只是用于阐述。计算系统100的其它实施例可以在不脱离本公开范围的情况下使用。

如图1所示，系统100包括有助于系统100中各种组件之间的通信的网络102。例如，网络102可以在网络地址之间传送网际协议(IP)包、帧中继帧、异步传输模式(ATM)信元，或其它信息。网络102可以包括一个或多个局域网(LAN)、城域网(MAN)、广域网(WAN)、诸如互联网的全球网络的全部或部分、或一个或多个位置处的任何其它通信系统。

网络102有助于至少一个服务器104和各种客户端设备106-114之间的通信。每个服务器104包括可以对一个或多个客户端设备提供计算服务的任何合适的计算或处理设备。每个服务器104可以包括，例如，一个或多个处理设备、存储指令和数据的一个或多个存储器、以及有助于通过网络102的通信的一个或多个网络接口。

每个客户端设备106-114表示通过网络102与至少一个服务器或其它(多个)计算设备交互的任何合适的计算或处理设备。在这一示例中，客户端设备106-114包括桌面型计算机106、移动电话或智能电话108、个人数字助手(PDA)110、膝上型计算机112、以及平板计算机114。然而，任何其它或附加的客户端设备可在计算系统100中使用。

在这个示例中，一些客户端设备108-114与网络102间接地通信。例如，客户端设备108-110经诸如蜂窝基站或eNodeB的一个或多个基站116通信。并且，客户端设备112-114经诸如IEEE 802.11无线接入点的一个或多个无线接入点118通信。注意，这些只是用于阐述并且每个客户端设备可以与网络102直接地通信或者经任意(多个)合适的中间设备或网络与网络102间接地通信。

如以下更具体描述的，网络102有助于HTTP上的高效的、基于推送的媒体流。一个或多个服务器104支持通过WebSocket(网络套接字)的媒体流。当服务器104支持通过WebSocket的媒体流时，一个或多个客户端设备106-114能够检测到。当服务器104支持通过WebSocket的媒体流时，一个或多个客户端设备106-114能够建立到服务器的WebSocket连接并且提交指示流中所选择的再现(representation)和位置的初始请求。各个客户端设备106-114然后按照服务器104所推送的顺序来接收媒体分段(segment)。

尽管图1示出了计算系统100的一个示例，但是可以对图1进行各种变化。例如，系统100可以以任何适当的布置包括任意数目的每个组件。通常，计算和通信系统以多种配置出现，并且图1不将本公开的范围限制为任何特定配置。尽管图1示出了其中本专利文档所公开的各种特征可以被使用的一种操作环境，但是这些特征可以在任何其它合适的系统中使用。

图2和图3示出了根据本公开的计算系统中的示例设备。特别地，图2示出了示例服务器200，并且图3示出了示例客户端设备300。服务器200可以表示图1中的服务器104，并且客户端设备300可以表示图1中的客户端设备106-114的一个或多个。

如图2所示，服务器200包括总线系统205，其支持至少一个处理设备210、至少一个存储设备215、至少一个通信单元220和至少一个输入/输出(I/O)单元225之间的通信。服务器104可以被配置为与服务器200相同或类似。服务器200能够支持通过WebSocket的媒体流。

处理设备210运行可以被加载到存储器230中的指令。处理设备210可以以任何适当的布置包括任何适当数目和类型的处理器或其它设备。处理设备210的示例类型可以包括微处理器、微控制器、数字信号处理器、现场可编程门阵列、专用集成电路和分立电路。

存储器230和持久的存储装置235是存储设备215的示例，其表示能够存储并且有助于信息(诸如临时或永久的数据、程序代码和/或其它合适的信息)的取回的任意结构。存储器230可以表示随机存取存储器或任何其它合适的(多个)易失性或非易失性存储设备。持久的存储装置235可以包含支持较长期的数据存储的一个或多个组件或设备，诸如只读存储器、硬盘驱动器、快闪存储器或光盘。

通信单元220支持与其它系统或设备的通信。例如，通信单元220可以包括有助于通过网络102的通信的处理电路、网络接口卡或无线收发机。通信单元220可以支持经任何合适的(多个)物理的或无线的通信链路的通信。通信单元220使能到一个或多个客户端设备的连接。即，通信单元220提供被配置为耦接到至少一个客户端设备的接口。

I/O单元225允许数据的输入和输出。例如，I/O单元225可以提供用于经键盘、鼠标、键区、触摸屏或其它合适的输入设备的用户输入的连接。I/O单元225还可以将输出发送到显示器、打印机或其它合适的输出设备。

注意，尽管图2被描述为表示图1的服务器104，但是相同或相似的结构可以在一个或多个客户端设备106-114中使用。例如，膝上型或桌面型计算机可以具有和图2中所示的相同或相似的结构。

图3示出了根据本公开的示例STA 300。图2中示出的STA 300的实施例只是用于阐述，并且图1的(多个)STA 104-112可以具有相同或相似的配置。然而，(多个)STA以多种配置出现，并且图3不将本公开的范围限制为STA的任何特定的实施方式。

STA 300包括多个天线305a-305n、多个无线电频率(RF)收发机310a-310n、发送(TX)处理电路315、麦克风320和接收(RX)处理电路325。TX处理电路315和RX处理电路325分别耦接到每个RF收发机310a-310n，例如，耦接到RF收发机310a、RF收发机310b直到第N个RF收发机310n，这些RF收发机分别耦接到天线305a、天线305b和第N条天线305n。在某些实施例中，STA 104包括单一的天线305a和单一的RF收发机310a。STA 300还包括扬声器330、主处理器340、输入/输出(I/O)接口(IF)345、键区350、显示器355和存储器360。存储器360包括基本操作系统(OS)程序361和一个或多个应用362。

RF收发机310a-310n从各自的天线305a-305n接收由网络100的AP 102发送的到来的RF信号。RF收发机310a-310n将到来的RF信号下变频以生成中频(IF)或基带信号。IF或基带信号被发送到RX处理电路325，其通过滤波、解码和/或数字化该基带或IF信号来生成已处理的基带信号。RX处理电路325将已处理的基带信号发送到扬声器330(诸如针对语音数据)或主处理器340用于进一步处理(诸如针对网络浏览器数据)。

TX处理电路315接收来自麦克风320接收模拟或数字的语音数据或来自主处理器340的其它的输出的基带数据(诸如网络数据(web data)、电子邮件或交互视频游戏数据)。TX处理电路315编码、复用和/或数字化外出的基带数据以生成已处理的基带或IF信号。RF收发机310a-310n接收来自TX处理电路315的外出的已处理的基带或IF信号并且将该基带或IF信号上变频为经一个或多个天线305a-305n发送的RF信号。

主处理器340可以包括一个或多个处理器或其它处理设备并且运行存储在存储器360中的基本OS程序361以便控制STA 300的整体操作。例如，主处理器340可以按照周知的原理、通过RF收发机310a-310n、RX处理电路325和TX处理电路315来控制正向信道信号的接收和反向信道信号的发送。在一些实施例中，主处理器340包括至少一个微处理器或微控制器。

主处理器340还能够运行驻留在存储器360中的其它进程或程序，诸如针对Websocket上的媒体流的操作。主处理器340可按运行中的进程的要求将数据移入或移出存储器360。在一些实施例中，主处理器340被配置为基于OS程序361或响应于从AP 102或运营商接收的信号来运行应用362。主处理器340还耦接到I/O接口345，其为STA 300提供连接到诸如膝上型计算机和掌上型计算机的其它设备的能力。I/O接口345是这些附件和主控制器340之间的通信路径。

主处理器340还耦接到键区350和显示器单元355。STA 300的操作者可以使用键区350来键入数据到STA 300。显示器355可以是液晶显示器或能够渲染诸如来自网站的文本和/或至少有限的图形的其它显示器。

存储器360耦接到主处理器340。处理器360的部分可以包括随机存取存储器(RAM)，并且存储器360的另一部分可以包括快闪存储器或其它只读存储器(ROM)。

尽管图2和图3示出了计算系统中的设备的示例，但是可以对图2和图3进行各种变化。例如，图2和图3中的各种组件可以被组合、进一步细分、或省略，并且附加的组件可以根据特定的需要而添加。作为特定的示例，主处理器340可以被划分成多个处理器，诸如一个或多个中央处理单元(CPU)以及一个或多个图形处理单元(GPU)。并且，尽管图3示出了被配置为移动电话或智能电话的客户端设备300，但是客户端设备可以被配置为作为其它类型的移动的或固定的设备来操作。此外，如同计算和通信网络，客户端设备和服务器也可以以多种配置出现，并且图2和图3不将本公开限制为任何特定的客户端或服务器。

通过HTTP的动态自适应流(Dynamic Adaptive Streaming over HTTP，DASH)近来已被3GPP和MPEG标准化。针对自适应HTTP流的若干其它专有的解决方案，诸如的HTTP直播流(HTTP Live Streaming，HLS)和的平滑流，现今正被商业性地部署。相比之下，DASH是完全开放并且已标准化的媒体流解决方案，其驱动了不同实施方式之间的互操作性。

图4示出了根据本公开的实施例的自适应的HTTP流架构。图4所示的HTTP流架构400的实施例只是用于阐述。其它实施例可以在不脱离本公开的范围的情况下被使用。

在HTTP流架构400中，内容在内容准备405步骤中被准备。内容由HTTP流服务器410传递。HTTP流服务器410可以被配置为与服务器104相同或类似。在流中，内容被缓存或缓冲在HTTP缓存415中并且进一步被流式传输到HTTP流客户端420。HTTP流客户端420可以是客户端106-114的其中一个。

在DASH中，内容准备405步骤需要被执行，其中内容被分成多个分段。初始化分段被创建以携带配置媒体播放器所必要的信息。只有这样才能消费媒体分段。内容通常以多个变体，一般是若干比特率，被编码。每个变体对应于该内容的再现(Representation)。内容再现可以彼此替换或者它们可以彼此补充。在前面的情况中，客户端只能从替换的再现组中选择一个替换。替换的再现被分组到一起作为适应集。客户端可以继续添加包含附加的媒体组件的补充再现。

提供给DASH流的内容需要向客户端420描述。这是使用媒体呈现描述(Media Presentation Description，MPD)文件来进行的。MPD是包含内容的描述、内容的时段、适应集、内容的再现和最重要地如何访问内容的每个分段的XML文件。MPD元素是MPD文件中的主元素。它包含关于内容的一般信息，诸如它的类型和内容可用的时间窗口。MPD包含一个或多个时段(Period)，每个时段描述内容的时间分段。每个时段可以包含被分组到一个或多个适应集的内容的一个或多个再现。每种再现是一个或多个内容组件的编码并且具有特定的配置。再现主要在它们的带宽要求、它们所包含的媒体组件、所使用的编解码器、语言等方面不同。

图5示出了根据本公开的实施例的MPD结构。图5所示的MPD结构500的实施例只是用于阐述。其它实施例可以在不脱离本公开范围的情况下被使用。

在图5所示的示例中，MPD结构500包括具有许多时段510的媒体呈现505。每个时段510包括许多适应集515。每个适应集515包括许多再现520。每个再现520包括分段信息525。分段信息525包括初始分段530和许多媒体分段535。

在DASH的其中一个部署场景中，使用基于ISO的文件格式及其派生格式(MP4和3GP文件格式)。内容被存储在所谓的电影片段(fragment)中。每个电影片段包含媒体数据和相对应的元数据。媒体数据通常是来自所述再现的所有媒体组件的媒体样本的集合。每个媒体组件被描述为文件的轨道。

HTTP流

HTTP是基于请求/响应的协议。客户端设备300建立到服务器200的连接以发送它的HTTP请求。服务器200接受来自客户端设备300的连接以接收HTTP请求并将响应发送回客户端设备300。在标准的HTTP模型中，服务器200不能发起到客户端的连接，也不能发送未请求的HTTP响应。为了在HTTP上执行媒体流，客户端设备300然后不得不一个分段505接一个分段505地请求媒体数据。这造成了明显的用于请求的上行(upstream)通信量以及附加的端到端延迟。

为了改善用于网络应用的环境，社区已开发了若干所谓的HTTP流机制。这些机制使网络服务器200不需要等待来自客户端设备300的轮询请求就能发送数据到客户端300。用于HTTP流的主要方法(通常记作COMET)，要么是通过保持请求暂缓直到数据变成可用，要么通过无限期地保持响应开启。在第一种情况下，新的请求仍将需要在已收到响应之后被发送。在HTTP流中，不终止请求并且不关闭连接。每当数据变成可用时，数据之后被推送到客户端设备300。

HTTP长轮询

关于传统的请求，客户端向服务器200发送有规律的请求并且每个请求试图拉取任意可用的数据。如果没有可用的数据，服务器200返回空响应或错误消息。客户端设备300在稍晚的时间执行轮询。轮询频率依赖于应用。在DASH中，这由分段可用初始时间来确定，但是在客户端和服务器之间需要时钟同步。

在长轮询中，服务器200试图通过保持请求暂缓直到所请求的资源变成可用来最小化延迟和轮询频率。当应用于DASH时，直到所请求的DASH分段变成可用才会发送响应。相比之下，当前的默认行为是对于不可用的分段的请求将是“404错误”的响应。

然而，长轮询对于DASH来说可能不是最佳的，因为客户端设备300仍将不得不发送对每个分段的HTTP请求。也有可能是分段URL是不可预知的，所以客户端设备300将不得不首先得到MPD并且解析它以查明当前分段的位置，这带来了附加的延迟。

HTTP流

HTTP流机制无限期地保持请求开启。它不终止请求或不关闭连接，即使在已向客户端发送某些数据之后。这一机制显著地减少延迟，因为客户端和服务器不需要打开和关闭连接。该过程由进行初始请求的客户端设备300启动。客户端设备300然后等待响应。服务器200推迟响应直到数据可用。每当数据可用时，服务器会将数据发送回客户端设备300作为部分的响应。这是由HTTP/1.1和HTTP/1.0二者支持的能力。在这一情况下，Content-Length(内容-长度)头部字段不被提供在响应中，因为它是不可预知的。代替地，响应长度将通过连接的关闭来确定。关于这一HTTP流的方法的主要问题是关于这些连接的中间节点的行为不能被保证。例如，中间节点可能不立即转发部分的响应。中间节点可以决定缓冲该响应并且在稍晚的时间发送它。

图6和图7示出了根据本公开的HTTP 1.0和HTTP 1.1之间的区别。尽管流程图描述了一系列连续的信号，除非明确地声明，否则不应该从关于执行的特定顺序的序列中得到如下推论，步骤或其部分的执行是连续地而不是同时地或以重叠的方式，或所描述的步骤的执行完全没有中介或中间步骤的出现。所述示例中描述的过程由例如服务器中或客户端设备中的处理电路来实现。

HTTP/2和WebSocket

HTTP协议需要更大的灵活性早已被察觉，但是社区不情愿对最普遍并且大量使用的协议的其中一个做出改变。图6所示的示例示出了HTTP 1.0600允许每次连接只有一个请求，这造成对于斜向上和向下的TCP连接的明显的延迟。对于来自客户端设备300的每个“get(获取)”请求，服务器200发送连续的响应。即，对于客户端设备300作出的第一个“get”请求605a，服务器200发送连续的响应610a。对于客户端设备300作出的第二个“get”请求605b，服务器200发送连续的响应610b。图7所示的示例示出了HTTP 1.1 700引进了持久的连接和请求管线传输(request pipelining)。客户端设备300作出的多个“get”请求后面接着服务器200发送的多个相应的响应。即，第一个“get”请求705a、第二个“get”请求705b和第三个“get”请求705c，是由客户端设备300发送的。作为响应，服务器200发送相应的第一个响应710a、第二个响应710b和第三个响应710c。关于持久的连接，同一TCP连接可以被用来发出多个请求并且接收它们的响应。这避免了经历连接的建立和TCP的慢启动阶段。请求管线传输允许客户端在接收先前请求的响应之前发送多个请求。图6和图7所示的示例示出了对于HTTP 1.0和HTTP 1.1的不同的消息交换序列，其示出了在延迟和链路利用率方面的潜在增益。

然而，HTTP 1.1 700引进管线传输和持久的连接也不满足所有应用需要。例如，即使当使用管线传输时，来自服务器200的响应的顺序必须和客户端设备300请求的顺序相同并且如果一个请求阻塞，后面的请求也将阻塞。即，如果第一个“get”请求705a阻塞，则第二个“get”请求705b和第三个“get”请求705c也阻塞。HTTP 1.1 700也不支持将来自服务器200的内容推送到客户端设备300。因而客户端设备300将只得到客户端设备300已实际请求的资源。对于经常访问的网站，很可能，在请求了链接所有链接资源的主HTML文档之后，链接资源的集合将被请求。因此，客户端设备300必须在请求链接资源之前等待该主文件被接收并被解析，其可造成在渲染网站时明显的延迟。

在以下实施例中，公开了HTTP/2和WebSocket所提供的新特征。本公开的某些实施例使能通过HTTP/2和WebSocket的DASH。

HTTP 2.0

HTTP 2.0，这里也被称为“HTTP/2”，是互联网工程任务组(IETF)的工作草案，其试图解决HTTP 1.1从前的限制，而同时保持所有功能不被改变。

HTTP/2引进了流的概念，其中流是被客户端设备300和服务器200独立对待的。流被用来携带请求并且接收关于该请求的响应，在这之后流被关闭。消息交换是在帧中进行的，其中帧可以是头部(HEADER)类型或数据(DATA)类型，这依赖于帧的有效载荷是什么。此外，还定义了一组控制帧。那些帧被用来取消进行中的流(RST_STREAM)、指示流对比其它流的优先级(PRIORITY)、传送流的设置(SETTINGS)、指示没有更多的流可以在当前TCP连接上生成(GOAWAY)、执行乒/乓操作(PING和PONG)、提供将数据从服务器推送到客户端的承诺(PUSH_PROMISE)或前一帧的连续(CONTINUATION)。在某些实施例中，帧的长度最多16383字节。

HTTP/2还试图经头部压缩提高线路上的效率。当使用时，头部压缩对头部字段名编制索引并且使用数值标识符来指示哪个头部字段被使用。大多数头部字段被分配了静态的id值，但是头部压缩允许动态地将值分配给其它头部字段。

WebSocket

类似于HTTP/2，在某些实施例中，WebSocket也被实现为完全符合HTTP协议的升级，其开始于握手过程，在此期间两端商定将连接升级到WebSocket。在成功地将连接升级为WebSocket连接后，数据可以同时在两个方向上流动，其结果是全双工的连接。服务器200可以在不需要客户端请求的情况下决定将数据发送到客户端设备300。客户端设备300也可以发送多个请求而不需要等待服务器响应。

实际上，HTTP/2从WebSocket借用许多概念，诸如握手过程和成帧过程，包括若干帧类型(诸如数据、连续、乒和乓)。WebSocket不定义关于应用数据的格式的任何进一步的细节，并且将其留给应用来定义。在握手阶段协商实际的格式，其中两端点通过交换Sec-WebSocket-Protocol头部字段来商定将要使用的子协议。

根据本公开的某些实施例：

客户端设备300避免连续地拉取数据；

客户端设备300避免同步问题和资源取回错误；

客户端设备300仍然在会话的控制之下；以及

服务器200获得对会话的某些控制。

结果是，本公开的某些实施例减少体验延迟(experience delay)和网络通信量。

在某些实施例中，定义了成帧协议来使能在HTTP流上基于推送的自适应HTTP流解决方案。成帧协议使客户端设备300能将命令发送到服务器200以在流会话期间执行速率自适应操作。

图8示出了根据本公开的实施例的支持WebSocket的网络。图8所示的支持WebSocket的网络800的实施例只是用于阐述。其它实施例可在不脱离本公开的范围的情况下被使用。

支持WebSocket的网络800包括原始服务器805、一个或多个内容分发网络(content delivery network，CDN)代理服务器810和许多客户端设备815。原始服务器805可以被配置为与服务器200相同或类似。一个或多个CDN代理服务器810可以被配置为与服务器200相同或类似。一个或多个客户端设备815可以被配置为与客户端设备300相同或类似。CDN代理服务器810经互联网820与原始服务器805通信。互联网820可以与网络102相同或类似。客户端设备815a与CDN代理服务器810a建立通信连接，通过该连接客户端设备815a可以接收来自原始服务器805的内容。客户端设备815b与CDN代理服务器810b建立通信连接，通过该连接客户端设备815b可以接收来自原始服务器805的内容。客户端设备815c与CDN代理服务器810b建立通信连接，通过该连接客户端设备815c可以接收来自原始服务器805的内容。在图8所示的示例中，WebSocket在最后一跳中被使用以使内容从CDN流向客户端。即，客户端设备815b或客户端设备815c，或它们两者，经从CDN代理服务器815b到原始服务器805的各自的连接通过WebSocket 825来建立自适应的HTTP流。

在某些实施例中，客户端设备815b首先检测原始服务器805或CND代理服务器810b是否支持通过WebSocket的媒体流。尽管实施例的示出是关于客户端设备815b或额外地包括客户端设备815b，但是与流式传输到客户端设备815c或客户端设备815a相对应的实施例可以在不脱离本公开范围的情况下被使用。当第一设备确定要么是原始服务器805、要么是CDN代理服务器810b时，客户端设备815b经CDN代理服务器810b建立到原始服务器805的WebSocket连接并且提交指示流中所选择的再现和位置的初始请求。客户端设备815b然后按照原始服务器805推送媒体分段的顺序来接收媒体分段。这一过程继续直到客户端设备815b：

决定选择或切换为替换的再现；

决定执行特技模式操作；

接收要求客户端动作的清单文件更新或其指示；

接收流的结尾或服务指示的结尾；以及

接收来自服务器的请求以发送针对下一分段的请求。

基于客户端设备815b的决定或接收，客户端设备815b决定创建并且提交给原始服务器805什么命令。

图9示出了根据本公开的实施例、对客户端设备利用WebSocket的自适应的HTTP流过程900。尽管流程图描述了一系列连续的步骤，除非明确地声明，否则不应该从关于执行的特定顺序的序列中得到如下推论，步骤或其部分的执行是连续地而不是同时地或以重叠的方式，或所描述的步骤的执行完全没有中介或中间步骤的出现。所述示例中描述的过程由例如客户端设备中的处理电路来实现。

在块905中，客户端设备300接收服务器200支持WebSocket的指示。服务器200向客户端设备300指示服务器200乐于升级到WebSocket以服务到客户端设备300的媒体流会话。在建立到客户端设备300的连接之后，在块910中，服务器200接收对于分段的初始请求。客户端设备300向服务器200发送命令或请求以选择再现和位置。服务器200将分段分装在帧中并且发送它。在块915中，客户端设备300接收来自服务器200的分段。服务器200连续地发送后面的分段，诸如通过将分段号增加1，直到客户端设备300接收到新的命令或要求决定。即，在块920中，要么命令被发送、要么动作被指示为要求，诸如当MPD文件更新变成可用时。块920中如果没有要求动作，则客户端设备300继续接收分段，诸如通过返回块915。块910中如果要求动作，则块925中客户端设备300确定是否终止会话。块925中当客户端设备300决定不终止会话时，在块910中客户端设备300向服务器发送其它命令以选择再现和位置。替换地，块925中当客户端设备300决定终止会话时，块930中，客户端设备300要么终止该会话、要么切换到另一服务器。

图10示出了根据本公开的实施例、对服务器利用WebSocket的自适应的HTTP流过程1000。尽管流程图描述了一系列连续的步骤，除非明确地声明，否则不应该从关于执行的特定顺序的序列中得到如下推论，步骤或其部分的执行是连续地而不是同时地或以重叠的方式，或所描述的步骤的执行完全没有中介或中间步骤的出现。所述示例中描述的过程由例如服务器中的处理电路来实现。

块1005中，服务器200向客户端设备300指示服务器200乐于升级到WebSocket以服务到客户端设备300的媒体流会话。在客户端设备300接收到接收服务器200支持WebSocket的指示后，在块1010中服务器200与客户端设备300建立传入的WebSocket连接。在建立到客户端设备300的连接后，块1015中服务器200接收初始命令或对于分段的请求。即，响应于客户端设备300向服务器200发送命令或请求以选择再现和位置，服务器200通过将分段封装在帧中并且将分段发送到客户端设备300来处理流命令。块1020中，服务器200向客户端设备300发送下一分段。服务器200连续地发送后面的分段，诸如通过将分段号增加1，直到客户端设备300接收到新的命令或要求决定。即，在块1025中，服务器200确定是否要求客户端动作，诸如当MPD文件更新变成可用时。如果块1025中没有要求动作，则服务器200继续发送分段，诸如通过返回块1020。如果块1025中要求客户端设备动作，则块1030中服务器200向客户端设备300发送指示相应动作的命令，诸如当MPD文件更新变成可用时。

在某些实施例中，通过WebSocket的自适应的HTTP流被实现为WebSocket协议的子协议。命令被定义为WebSocket帧头部的扩展数据。以下是从客户端设备300到服务器200的可能的命令：

向特定再现请求数据流，可以从初始(init)分段和特定分段号开始。请求可以是第一分段的统一资源定位符(URL)或者请求可以是呈现(Presentation)标识符、再现(Representation)标识符和开始分段号；以及

向服务器请求停止流。

以下是从服务器200到客户端设备300的可能的命令：

关于MPD更新的信息；

被发送到客户端的分段的标识符；每一分段单独地成帧并且前面是它的URL或其它标识；

请求客户端选择，诸如由于新的时段。这个命令包括时间轴上的当前位置以及为什么请求客户端选择的其它信息；以及

关于过早地结束会话或终止流会话的信息。

分段和MPD更新被成帧以使客户端设备能分别识别每个分段。分段可以被片段化以便每个电影片段可以被作为唯一片段发送。

通过HTTP/2和WebSocket的DASH

为了利用新的协议HTTP/2和WebSocket的全部的潜能，DASH应用必须定义将在已升级的连接之上使用的新的子协议。当HTTP/2比WebSocket定义更多功能时，因为在那种情况下的子协议意味着等价于HTTP 1.1的功能，所以在HTTP/2的情况下需要执行的工作将更少。

本公开的某些实施例示出了对DASH应用可用的功能：

DASH客户端设备能最小化向服务器的请求数；

DASH客户端设备能进行迅速的速率自适应；

DASH客户端设备能最小化延迟，诸如在直播流的情况中，其中内容被即时生成；以及

DASH/Web服务器能基于不同再现中的数据对回放的重要性来对这些数据划分优先次序。

基于这些目标，定义了对于HTTP/2和WebSocket的新的子协议。

对于WebSocket的DASH子协议

子协议由名字“dash”来标识。想要使用WebSocket用于DASH流的客户端设备包括关键词“dash”作为Sec-WebSocket-Protocol头部字段的部分，以及协议升级请求。

在成功地将协议升级为WebSocket之后，客户端和服务器交换DASH数据帧(操作码‘文本’或‘二进制’或其任意‘连续’帧)。DASH帧格式定义为如下：

STREAM_ID：8比特是当前流的标识符，其允许在同一websocket连接上复用多个请求/响应。

CMD_CODE：8比特指示按照这个请求/响应发送的DASH命令。当前定义的命令如下：

F：3比特--这一字段提供将要基于所述命令而被设置并且被解释的一组标志。

EXT_LENGTH：13比特--提供先于应用数据的扩展数据的字节的长度。

对于HTTP/2的DASH子协议

如早前讨论的，HTTP/2可以被认为是WebSocket的超集，HTTP/2提供等价于HTTP 1.1协议的子协议。为WebSocket DASH子协议所提出的若干功能已由HTTP/2协议来提供，诸如支持对于多个流，取消特定流上的当前传输并且使用PUSH_PROMISE帧来将数据推送到客户端。

为了保持与HTTP/2的向后兼容，DASH子协议使用HEADERS帧来传达DASH特定的信息和命令。出于这一目的，定义了新的头部字段，其携带用逗号分开的名字的集合＝值的对。DASH头部字段被称为“Dash”。介绍以下命令：

(a)协商对DASH子协议的支持；

(b)请求特定再现的连续流；

(c)请求客户端决定；以及

(d)传送MPD更新

尽管已用示例实施例描述了本公开，但各种变化和修改可以被建议给本领域技术人员。意图本公开包含落入所附权利要求范围内的变化和修改。