CN111586479B - 一种由客户端设备执行的机器实现的方法以及可读介质 - Google Patents

一种由客户端设备执行的机器实现的方法以及可读介质 Download PDF

Info

Publication number
CN111586479B
CN111586479B CN202010100779.XA CN202010100779A CN111586479B CN 111586479 B CN111586479 B CN 111586479B CN 202010100779 A CN202010100779 A CN 202010100779A CN 111586479 B CN111586479 B CN 111586479B
Authority
CN
China
Prior art keywords
playlist
reproduction
media
client device
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010100779.XA
Other languages
English (en)
Other versions
CN111586479A (zh
Inventor
R·N·潘特斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc filed Critical Apple Inc
Publication of CN111586479A publication Critical patent/CN111586479A/zh
Application granted granted Critical
Publication of CN111586479B publication Critical patent/CN111586479B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

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

Abstract

本公开涉及低延迟流媒体。本发明公开了内容流传输系统，诸如使用符合HTTP的请求来获得媒体片段以在设备上呈现内容的系统。这些内容流传输系统可被优化以将延迟减小到低水平，这样直播活动可被流传输到接收设备，使得所述直播活动中的动作与接收流内容的接收设备上的所述动作的呈现之间的时间小于约10秒。当在不同比特率之间切换时，客户端设备可在呈现(第二比特率的)前一个再现之后，使用再现报告来调入到新的再现(第一比特率)；另外，例如，客户端设备可使用指示独立帧的播放列表注释来避免当在不同再现之间切换时下载从属帧媒体片段。

Description

一种由客户端设备执行的机器实现的方法以及可读介质
本申请要求于2019年2月19日提交的在先美国临时专利申请 62/807,329和于2019年2月25日提交的在先美国临时专利申请62/810,075 的优先权，这两个专利申请以引用方式并入本文。
背景技术
许多设备目前使用流媒体内容递送系统来呈现内容，诸如电影、电视节目、录制的体育活动、新闻节目、直播活动(诸如直播体育活动、直播新闻活动等)。这些流媒体内容递送系统通常使用一个或多个播放列表，这些播放列表枚举有序的一系列统一资源标识符(URI)(诸如统一资源定位符(URL))来标识可使用常规符合HTTP的请求从一个或多个服务器检索的媒体片段。一旦被检索，媒体片段可被呈现在请求媒体片段的客户端设备上，然后在每个媒体片段呈现之后在客户端设备上被擦除。这些流媒体内容递送系统可显示录制的内容，诸如电影或视频点播内容，或直播内容，诸如在客户端设备的用户正在观看的同时发生的直播体育活动或直播新闻活动。现有的流内容递送系统包括基于DASH(通过HTTP的动态自适应流)的系统，这些系统基于标准(例如ISO/IEC 23009-1:2014)，以及来自 AppleInc.的基于Apple的HTTP直播流传输(HLS)的系统。
这些现有系统可能难以以具有相对于直播活动低延迟的方式来递送直播活动的内容。例如，对于当用户正在使用流媒体系统观看直播体育活动时发生的直播体育活动，在直播活动中发生的动作可能在直播活动发生数秒钟(例如，15秒或更长时间)之后才会显示。许多用户可能会发现这种大延迟令人失望，因此存在改善流媒体系统中的递送延迟的需求。本公开提供了用于解决这种需求的各种解决方案。
发明内容
本公开描述了用于减小延迟或以其他方式改善流媒体内容的递送或处理的各种技术、系统，非暂态机器可读介质和方法。一个方面可使用来自客户端设备的更新播放列表请求，作为对更新播放列表的请求的一部分，所述更新播放列表请求包括对该更新播放列表中的(将来)媒体片段的请求，诸如该更新播放列表中的第一个(在时间上)媒体片段，并且如果包含该(将来)媒体片段的播放列表尚不可用，则服务器设备可阻止对该请求的响应，并且当包含该(将来)媒体片段的播放列表可用时，将发送更新播放列表，并将(将来)媒体片段推送到发出请求的客户端设备。根据该方面，客户端设备可被认为是在包含预期下一媒体片段的预期播放列表在服务器处可用之前提出对该预期播放列表的请求，并且服务器可阻止对该请求的响应(同时保持套接字连接打开)，直到更新播放列表可用。根据本公开的该方面，一种用于处理流媒体的方法可包括用于请求将来媒体片段的以下操作：以符合传输协议的方式(诸如HTTP/2)接收第一播放列表，其中第一播放列表包括多个统一资源标识符(URI)，这些统一资源标识符指示可被接收以重新创建内容或数据流的多个媒体片段的回放顺序，并且第一播放列表可按照该顺序包括最后一个URI，该最后一个URI标识第一播放列表中的最后一个可用媒体片段。最后一个URI在用于对在第一播放列表创建时不可用的将来媒体片段的至少一部分的请求的URI之前；该方法还包括：在根据传输协议的单个请求中，发送用于将来媒体片段的至少一部分的URI和对更新播放列表的请求，其中更新播放列表包括用于数据流的媒体片段的第二多个URI；以及响应于第一请求，接收更新播放列表和响应用于将来媒体片段的URI的将来媒体片段。因此，对更新播放列表和将来媒体片段的组合请求消除了会向该过程增加往返时间的单独请求，从而减小了延迟。使用将来媒体片段请求的一个方面还可包括：请求包括多个可用媒体播放列表的主播放列表，并且从该主播放列表请求第一播放列表，第一播放列表是所述多个可用媒体请求中的一个。根据一个方面，该方法还可包括：在接收到更新播放列表之后，确定更新播放列表中的用于在更新播放列表中标识的最后一个可用媒体片段的最后一个URI，并且在请求更新播放列表中标识的所有媒体片段之前，在单个符合HTTP 的请求中请求另一更新播放列表和由紧接在更新播放列表中的最后一个 URI之后的URI标识的媒体片段。在该方面，接收设备可跳过该另一更新播放列表中的媒体片段，以跳转到或调入到直播活动中的在由播放列表末尾的最后一个URI标识的近当前时间。在一个方面，对另一更新播放列表和由紧接在更新播放列表中的最后一个URI之后的URI标识的媒体片段的请求可作为高优先级过程发生，该过程响应于接收到更新播放列表而被快速调度以便快速调入到直播活动。
在一个方面，用于将来媒体片段的URI可指定在第一播放列表创建时不存在的将来媒体片段内的起始位置，并且该起始位置可在该将来媒体选择片段的起点和终点之间。换句话讲，用于将来媒体片段的URI可指定媒体片段内的起始位置，使得响应可避免发送媒体片段的在起始位置之前的部分。在一个方面，在用于获取直播流内容的调入阶段，客户端设备可重复地跳到下一播放列表中的下一URI中的每个以寻找该直播流内容中的最新回放时间。通过一系列快速请求的对播放列表的更新进行的连续播放列表更新可用于区分已缓存(例如，在CDN中)的较旧播放列表和在源服务器上完成的近直播点更新的播放列表，使得响应被阻止并延迟。该区分可以基于响应时间，该响应时间指示对于最新更新的播放列表而言更长的延迟。根据一个方面，直播活动可为在客户端设备的用户正在观看或以其他方式消费该活动的同时发生的活动。根据一个方面，由播放列表中的URI 标识的多个媒体片段各自的长度小于约5至10秒。根据一个方面，第一播放列表中的最后一个URI可包括用于媒体序列号的第一标签和用于部分编号的第二标签，该第二标签指定由最后一个URI标识的媒体片段内的起始位置。根据一个方面，可以在请求更新播放列表之后将套接字连接保持在打开状态，使得通过保持在打开状态的套接字连接来接收更新播放列表和将来媒体片段的至少一部分。
根据本公开的另一方面，一种用于处理流媒体的方法可包括服务器系统响应于接收到将来媒体片段请求而执行的以下操作：接收对由第一统一资源标识符(URI)标识的更新播放列表的第一请求，并且第一请求还请求该更新播放列表中的媒体片段的至少一部分，第一请求作为单个符合传输协议的请求被接收，该单个符合传输协议的请求请求更新播放列表和该更新播放列表中的媒体片段两者；响应于接收到第一请求，确定更新播放列表尚不可用；在更新播放列表尚不可用时，阻止完成对针对更新播放列表的第一请求的响应；以及一旦更新播放列表变得可用，则响应于第一请求，发送更新播放列表和第一媒体片段的至少一部分。第一媒体片段可为更新播放列表中按照标识多个媒体片段的媒体片段顺序的第一个媒体片段，并且该顺序指定了可使用该更新播放列表检索的多个媒体片段的回放顺序。请求更新播放列表的URI包含允许服务器确定服务器必须等待的媒体片段 (或媒体片段的一部分)的信息。根据一个方面，在阻止响应的完成并且在发送更新播放列表和第一媒体片段的一部分的同时，由第一请求建立的套接字连接可保持打开。根据一个方面，更新播放列表和第一媒体片段的至少一部分作为对第一请求的单个响应的一部分被发送。根据一个方面，该方法还可包括以下操作：接收对主播放列表的请求并发送主播放列表；以及接收对选自在主播放列表中标识的一组媒体播放列表中的一个媒体播放列表的请求，其中所选的媒体播放列表在第一请求被接收之前由远程客户端设备至少部分地处理。根据一个方面，执行该方法的数据处理系统可为一组一个或多个源服务器，这些源服务器完成更新播放列表的创建，从而使得在接收到第一请求之后更新播放列表可用于传输到一个或多个客户端设备。根据一个方面，该方法还可包括以下操作：在第一请求中，接收推送标签，该推送标签指定要作为对第一请求的响应从服务器发送(“推送”)到客户端的媒体片段或一个或多个媒体片段的部分的数量，其中媒体片段数量的推送允许发送第一请求的客户端设备避免发送对媒体片段数量的多个请求。根据一个方面，主播放列表或媒体播放列表中的至少一者可指定诸如一个或多个源服务器的数据处理系统可支持对将来媒体片段的请求以提供低延迟流传输服务。根据一个方面，第一个URI可包括用于媒体序列号的第一标签和用于部分编号的第二标签，该第二标签指定由第一个URI标识的媒体片段内的位置。根据另一方面，媒体序列号可不是URI 的一部分，而是基于当前播放列表顶部的媒体序列标签和最后一个媒体片段之前的中间媒体片段的数量来确定的。
根据本公开中所述的另一方面，一种方法可包括用于通过提出对媒体片段的多个并发请求来处理流媒体的以下操作：发送对媒体播放列表的第一请求，该媒体播放列表包括多个URI，这些URI指示以符合传输协议的方式回放多个媒体片段以重新创建数据流的顺序；响应于第一请求，接收媒体播放列表，并选择由在接收到的媒体播放列表中的两个连续URI指定的两个连续媒体片段；发送针对这两个连续媒体片段的第二请求，第二请求作为一个或多个符合传输协议的请求(诸如单个HTTP/2请求或两个连续请求)，并且第二请求指定这两个连续媒体片段之间的下载依赖关系(以使服务器先发送这两个中的第一个，然后发送这两个中的第二个)；响应于第二请求，接收两个连续媒体片段中的第一媒体片段；确定第一媒体片段的下载是否已经完成；以及响应于确定第一媒体片段的下载已经完成，发送对紧接在这两个连续媒体片段中的第二媒体片段之后的下一媒体片段的第三请求，该第三请求在第二媒体片段正在下载时发生。第二请求可使用HTTP/2协议指定下载依赖关系，使得在服务器开始发送第二媒体片段之前，服务器将第一媒体片段完整发送。根据一个方面，媒体播放列表可选自指定了流内容的一组再现的请求并接收的主播放列表。根据一个方面，媒体播放列表可为更新播放列表，并且内容流针对直播活动。根据本公开的一个方面，该方法还可包括：确定是否在前一媒体片段正在下载时停止发送对后一个媒体片段的请求。数据处理系统可基于更新播放列表中在具有相对于直播活动的低延迟的近直播媒体片段(在播放列表的末尾)之前存在多少媒体片段来确定暂时停止发送此类请求；该数据处理系统之所以可以这样做，是因为该数据处理系统已经有足够的缓冲数据，并且不想使用更多的资源来缓冲更多的媒体片段，或者是因为在播放列表的末尾没有更多的媒体片段可被请求。在一个方面，低延迟基于阈值，并且客户端设备被配置为尝试实现流内容的呈现的相对于直播活动的低延迟。
本公开的另一方面涉及对在客户端设备与一组一个或多个服务器(诸如源服务器或内容分发网络服务器)之间的连接介质(例如，有线和/或无线网络)中的缓冲区中的缓冲区膨胀的控制。对缓冲区膨胀的控制可用在同样尝试为通过流媒体呈现的直播活动实现低延迟的流媒体内容递送系统中。根据该方面，一种方法可以包括以下操作：测量数据处理系统(诸如客户端设备)和服务器系统之间的连接的往返时间，其中该连接被用作流媒体到客户端设备的符合HTTP的传输的一部分；基于计算出的带宽时延积确定发送窗口大小；以及将有关发送窗口大小的数据发送到服务器系统。在一个方面，有关发送窗口大小的数据用于限制吞吐量，同时保持足够的吞吐量来呈现流媒体的当前再现。根据一个方面，该方法还可包括确定用于支持流媒体的当前再现的回放的最小比特率的操作。根据一个方面，可选择该最小比特率以避免当前再现的回放的停顿。根据一个方面，确定发送窗口的大小，使得连接可以在所测量的往返时间内维持最小比特率。根据一个方面，该方法还可包括以下操作：监测连接的往返时间 (RTT)，以检测一段时间内往返时间的持续变化(超过阈值)。根据一个方面，当往返时间持续变化超过阈值时，客户端设备可确定新的发送窗口大小，并将该新的发送窗口大小发送到一个或多个服务器系统。根据一个方面，通过该连接将对更新播放列表的请求和对由更新播放列表中的URI标识的媒体片段的请求从客户端设备发送，并且由客户端设备通过该连接来接收媒体片段。根据一个方面，对更新播放列表的请求还可包括对更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP的请求的一部分。根据一个方面，客户端系统可尝试将延迟减小到针对流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与客户端设备上流媒体中的动作的呈现之间的时间差小于约3至6秒。根据一个方面，可以通过检查用于打开TCP连接的数据分组的定时数据或通过使用HTTP/2协议中包括的并且可用于测量RTT的强制ping功能来测量往返时间。
一个或多个服务器系统还可执行尝试控制缓冲区膨胀的方法，并且这些方法可包括以下操作：接收有关用于将流媒体发送到客户端设备的发送窗口大小的数据，在客户端设备测量了客户端设备和数据处理系统(诸如一个或多个服务器)之间的流媒体连接的往返时间之后，客户端设备已基于计算的带宽时延积确定了发送窗口大小；以及基于发送窗口大小来调节流媒体的符合HTTP的传输。在一个方面，客户端设备可确定发送窗口大小，使得该连接可以维持客户端设备所呈现的流媒体的当前再现所需的最小比特率，并且该最小比特率可被选择为避免当前再现的回放的停顿。客户端设备与一个或多个服务器系统之间的连接可用于接收对更新播放列表的请求，以及接收对由URI标识的将来媒体片段的请求，并且该连接可用于发送更新播放列表和发送所请求的媒体片段。根据一个方面，服务器系统可尝试限制向客户端设备的传输以限制连接中的缓冲区拥塞，同时还尝试将延迟减小到针对客户端设备上的流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与客户端设备上的流媒体中的动作的呈现之间的时间差小于约3至6秒。
本公开中所述的某些方面涉及在再现(诸如流媒体的不同比特率的再现)之间的切换。这些各个方面也可用于改善延迟以将延迟减小到低的所需值。根据涉及在再现之间进行切换的一个方面，客户端设备可执行以下操作：监测用于接收通过符合HTTP的协议提供的流媒体的第一再现的连接的带宽；基于监测的带宽来确定是否切换到流媒体的第二再现；响应于确定切换到第二再现，请求用于第二再现的第一播放列表；在请求第一播放列表之后，请求第一再现的第一多个媒体片段；以及请求第二再现的第二多个媒体片段。根据一个方面，该方法可用于在决定从第一再现切换到第二再现并且客户端设备尝试在两个再现之间切换时将两个再现同时下载到客户端设备。在一个方面，对第一多个媒体片段的请求可指定用于第一多个媒体片段的相对下载优先级的第一权重，并且其中对第二多个媒体片段的请求也指定权重，该权重为用于第二多个媒体片段的相对下载优先级的第二权重，其中第一权重和第二权重不同。根据一个方面，当第一再现具有比第二再现低的比特率时，第一权重大于第二权重，使得下载相对于第二再现更有利于第一再现(更低比特率的再现)。根据一个方面，当第二再现具有比第一再现低的比特率时，第二权重大于第一权重，使得下载相对于第一再现更有利于第二再现，并且在一段时间内，比第一再现的媒体片段更多的第二再现的媒体片段被下载。根据一个方面，该方法还可包括以下操作：请求有关一个或多个对应再现的一组一个或多个再现报告，其中这组再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入对应再现中的近直播点，并且这组再现包括以下一项或多项：(1)针对比特率比第一再现低的低比特率再现的再现报告，以及(2)针对比特率比第一再现高的高比特率再现的再现报告。所请求的一个或多个再现报告可与由服务器发送的播放列表响应捆绑在一起，因此可至少与更新播放列表本身一样最新，或者可被单独发送。根据一个方面，客户端设备可跳过更新播放列表内的媒体片段以跳转到在更新播放列表中的最后一个媒体片段之后的下一媒体片段，以便有利于快速调入流媒体内容中的近直播点。一旦客户端设备已经调入到流内容中的近直播点，客户端设备就可尝试保持用于直播活动的低延迟，使得直播活动中的动作与客户端设备上的流媒体中该动作的呈现之间的时间差小于约3至6 秒或小于约15秒。
本说明的某些方面涉及客户端设备对再现报告的使用，以允许更快地调入流媒体中的近直播点。根据客户端设备可通过执行一种方法来使用再现报告的一个方面，该方法可包括以下操作：监测用于接收通过符合HTTP 的协议提供的流媒体的第一再现的连接的带宽；基于监测的带宽来确定是否切换到流媒体的第二再现；请求有关一个或多个对应再现的一组一个或多个再现报告；以及响应于确定切换到第二再现，请求用于第二再现的第一播放列表。在一个方面，这组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入对应再现中的近直播点，并且这组一个或多个再现报告包括以下一项或多项： (1)针对比特率比第一再现低的低比特率再现的再现报告，以及(2)针对比特率比第一再现高的高比特率再现的再现报告。根据一个方面，最近更新播放列表可包括多个URI，并且其中多个URI中的最后一个URI是相对于直播活动的近直播点，数据处理系统可跳过该直播活动以有利于快速调入，其中跳到最后一个URI可避免下载在最后一个URI之前的媒体片段。在一个方面，通过与服务器的连接来发送对更新播放列表的请求和由更新播放列表中的URI标识的媒体片段的请求，并且其中对更新播放列表的请求还包括对更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP的请求的一部分。根据一个方面，客户端设备可尝试将延迟减小到针对流媒体中呈现的直播活动的低延迟值，使得直播活动中的动作与客户端设备上流媒体中的动作的呈现之间的时间差小于约3至6秒或小于约15秒。
本公开中所述的另一方面涉及播放列表注释的使用，以避免当在再现之间切换时在独立帧之前加载不可用的从属帧。根据该方面，客户端设备可执行包括以下操作的一种方法：监测用于接收通过符合HTTP的协议提供的流媒体的第一再现的连接的带宽；基于监测的带宽来确定是否切换到流媒体的第二再现；响应于确定切换到第二再现，请求用于第二再现的第一播放列表；在第一播放列表中，检查一个或多个播放列表注释，这些播放列表注释指定媒体片段是否包括独立帧，独立帧可在不使用任何先前帧的情况下被解码为完整图像帧；在第一播放列表中，跳过一个或多个媒体片段的基于一个或多个播放列表注释而不包括独立帧的至少一些部分的下载；开始下载第二再现中的媒体片段，其中一个媒体片段基于一个或多个播放列表注释而包括独立帧。根据一个方面，第一播放列表包括从属帧，在没有前一个独立帧的情况下，从属帧不能被解码为有效图像数据。独立帧是一种关键帧，该关键帧包含得出和解码关键帧中的编码图像的所有必要数据，并且在时间上在独立帧之后的从属帧使用关键帧中的数据来解码从属帧中的编码图像。根据一个方面，从属帧可包括B帧和P帧，这两类帧包括相对于其所依赖的独立帧的差异数据。根据一个方面，使用播放列表注释的方法还可以使用本文所述的再现报告。
本文所述的方面和实施方案可包括存储可执行计算机程序指令的非暂态机器可读介质，当这些计算机程序指令由一个或多个数据处理系统执行时，这些计算机程序指令可使一个或多个数据处理系统(诸如客户端设备以及一个或多个服务器系统)执行本文所述的一种或多种方法。指令可存储在非易失性存储器中，诸如闪存存储器或动态随机存取存储器或其他形式的存储器。
以上发明内容不包括本公开的所有方面和实施方案的详尽列表。所有系统和方法可根据以上发明内容的各个方面和实施方案以及以下具体实施方式中所公开的那些的所有合适的组合来实践。
附图说明
本文所述的方面以举例的方式而不是以限制的方式在各个附图的图示中进行说明，在附图中类似的附图标号是指类似的元件。
图1A示出了来自现有技术的示例，其中客户端设备与服务器设备通信以请求流媒体并从服务器设备接收流媒体。
图1B示出了内容递送系统的示例，该内容递送系统可包括一个或多个客户端设备以及一个或多个源服务器，这些源服务器通过连接介质(诸如一个或多个网络，可包括一个或多个内容分发网络)进行通信。
图2示出了根据一个方面的示例，其中客户端设备可提出播放列表请求，该请求具有将来媒体片段请求，并且服务器设备可阻止响应的完成，直到将来片段请求可用并且更新播放列表随后可完成。
图3是示出了本文所述的一个方面的流程图。
图4示出了根据本文所述的一个方面的播放列表的示例。
图5A是示出了本文所述的一个方面的流程图，其中可与对更新播放列表的请求并发地请求将来媒体片段。
图5B示出了可包括部分标识符和播放列表注释的媒体播放列表的示例。
图5C示出了结合有对将来媒体片段的请求的对更新播放列表的请求的示例。
图6是示出了本文所述的一个方面的流程图，该方面可由服务器系统在与接收到对更新播放列表的请求并发地接收到将来媒体片段请求时执行。
图7是示出了可由内容分发网络(CDN)中的一个或多个服务器执行的一个方面的流程图。
图8示出了一个方面，其中客户端设备可在一个请求中请求多个连续媒体片段并指定这些媒体片段之间的下载依赖关系。
图9是示出了根据图8所示方面的方法的流程图。
图10是示出了根据图8所示方面的方法的流程图。
图11示出了内容递送系统的示例，该系统中包括缓冲区。
图12是根据一个方面的流程图，该方面可用于控制内容分发系统中的缓冲数据的量。
图13是示出了用于在再现之间进行切换的一个方面的流程图。
图14示出了包括注释的播放列表的示例，该注释诸如当在再现之间切换时可使用的播放列表注释。
图15是示出了当在再现之间进行切换时可使用的一个或多个方面的流程图。
图16示出了在再现之间进行切换的一个方面的示例，其可使用如本文所述的播放列表注释。
图17示出了数据处理系统的示例，该数据处理系统可用作在本文所述的各个方面中的客户端设备或服务器设备。
具体实施方式
将参考以下论述的细节来描述各种实施方案和方面，并且附图将对各种实施方案进行说明。以下说明书和附图为例示性的，并且不应被理解为限制性的。描述了许多具体细节，以提供对各个实施方案的全面理解。然而，在某些实例中，熟知的或常规的细节并未被描述，以便提供对实施方案的简明论述。
在本说明书中提到的“一个方面”或“一个实施方案”或“实施方案”或“方面”是指结合该方面或该实施方案所述的特定特征、结构或特性可被包括在至少一个方面或至少一个实施方案中。在本说明书中的各个位置出现短语“在一个实施方案中”或“在一个方面”不一定都是指同一个实施方案或同一个方面。在随后的附图中所描绘的过程由包括硬件(例如，电路、专用逻辑部件等等)、软件或这两者的组合的处理逻辑部件来执行。虽然下文按照某些顺序操作来描述该过程，但应当理解，所描述的某些操作可以不同的顺序执行。此外，某些操作也可并行执行而非按顺序执行。
图1A示出了现有技术的流媒体内容递送系统中的客户端设备和服务器设备之间随时间推移的交互。客户端设备12请求媒体播放列表并请求在媒体播放列表中标识的媒体片段，并且服务器设备14响应于通过连接介质 10接收的请求，具体做法是通过连接介质10发送所请求的播放列表和发送所请求的媒体片段。如图1A所示，播放列表请求16通过连接介质10被发送16A到服务器设备14，该服务器设备利用播放列表响应17进行响应。播放列表响应17通过连接介质10被发送17A，并且在播放列表响应17开始其传输之后的某个时间被客户端设备12接收19。然后，客户端设备12 可检查该播放列表，并请求21媒体片段，并且引起向服务器设备的传输 21A。然后，服务器设备利用片段响应23进行响应，引起媒体片段响应的传输23A，该传输由客户端设备接收，如在客户端设备处接收到的媒体片段25所示。这可继续，直到新片段出现27并且包含该新片段的更新播放列表创建。在更新播放列表创建之后，客户端设备12请求更新播放列表 29，并且通过传输29A将该更新播放列表请求发送到服务器设备。在客户端设备12接收到更新播放列表并检查更新播放列表并从更新播放列表请求媒体片段(一次请求一个媒体片段)之后，该过程重复。有关该方法的更多信息可见于美国专利8,650,192中。
图1B示出了可在本文所述的一个或多个方面中使用的内容递送系统 37的示例。内容递送系统37可以包括一个或多个客户端设备，诸如客户端设备39和客户端设备41，这些客户端设备耦接到一个或多个网络43(例如，互联网)，而该网络又可以耦接到一个或多个内容分发网络45，这些内容分发网络在一种具体实中可为可选的。一个或多个内容分发网络45可继而通过一个或多个网络(诸如网络49，该网络可为一个或多个网络43的一部分)耦接到一个或多个源服务器，诸如源服务器47和源服务器49。一个或多个网络43和一个或多个网络46可以是互联网的一部分或者可以是专有网络的一部分，或者可以是互联网和专有网络等的组合。一个或多个源服务器(诸如源服务器图47和源服务器49)可以耦接到内容源，诸如内容51和内容53。除了先前录制的(非直播)内容(诸如电影、电视节目和其他内容)之外，该内容还可包括直播内容，诸如直播体育活动或直播新闻活动等。可以将内容划分为媒体片段，并且媒体片段可由一个或多个源服务器存储，并且一个或多个源服务器可创建包含标识符(诸如URI)的媒体播放列表，其中标识符标引媒体片段。本文所述的各种客户端设备和服务器系统可为图1B所示的系统中的一个。
本公开提出了各种不同的方面，当这些系统用于直播活动(诸如直播体育活动和直播新闻活动等)时，这些方面可单独使用或组合使用以减小流媒体内容递送系统中的延迟或处理其中的数据。一个这样的方面包括使用将来媒体片段请求，并且图2、图3、图4和图5A示出了客户端设备可以如何请求将来媒体片段请求以便减小接收直播流媒体内容时的延迟的示例。图2示出了一个方面的示例，其中客户端设备(诸如客户端设备103) 提出对针对播放列表的下一个更新的预先播放列表请求，并且还提出对期望在该下一个更新播放列表中的将来媒体片段的请求，该请求作为预先播放列表请求的一部分。具体地，如图2所示，客户端设备103可提出对更新播放列表的播放列表请求107，同时(作为播放列表请求107的一部分) 还请求预期在更新播放列表中的将来媒体片段，并且该请求通过连接介质 101(诸如一个或多个网络43和/或46)被发送108到一个或多个服务器系统或设备105。当新片段出现109时，一个或多个服务器系统或设备105可完成播放列表，然后将播放列表发送到客户端设备。一个或多个服务器系统或设备105还可推送新片段，该新片段是客户端设备在请求107中请求的将来媒体片段。一个或多个服务器系统105可阻止响应的完成，直到新片段109出现并且更新播放列表完成。传输110和112可以包括更新播放列表以及新片段的传输，并且客户端设备103接收114更新播放列表和新片段。在接收(114)到更新播放列表之后，客户端设备103可再次发送针对下一个更新播放列表的播放列表请求，该下一个更新播放列表可能不可用。该请求作为传输115被发送并且被一个或多个服务器105接收。可通过传输115中的播放列表请求建立对应的套接字连接。这可能导致一个或多个服务器105阻止响应的完成117，并且还使先前建立的套接字连接保持打开。一旦新片段出现119，一个或多个服务器105就可以完成更新播放列表的创建，并在传输120和121中发送更新播放列表和新片段，如图2所示。客户端设备103然后可接收(接收123)该更新播放列表和新片段，并且在传输125中再次发送(响应于接收123)另一个预先播放列表请求。
在常规系统中，将来媒体片段将是下一个播放列表中的被更新为包括新片段的媒体片段，并且该将来媒体片段在当前使用的播放列表创建时将不可用。相比之下，如图2的示例所示，客户端设备103可提出更新播放列表请求，并且同样与此同时并且作为同一请求的一部分，还请求将来媒体片段，该将来媒体片段在当前使用的播放列表创建时不可用。因此，图2 所示的方法可相对于图1A所示的示例消除至少一个往返时间。同样如图2 的示例中所示，客户端设备可被配置为在接收到当前更新播放列表之后立即提出对下一个更新播放列表的请求，使得客户端设备在接收到当前的更新播放列表时请求下一个更新播放列表。
客户端设备如何处理新接收到的更新播放列表可取决于该客户端设备是调入到针对直播活动的流内容(调入阶段)还是客户端设备在调入阶段后已经获取(“调入”)到近直播点。在调入阶段，不将任何媒体片段下载到客户端设备，并且客户端设备可通过请求具有push＝0标签的将来媒体片段来执行此操作(下面将进一步说明)。因此，将来媒体片段未被推送或下载到客户端设备，但是在调入阶段客户端设备仍将使用将来媒体片段请求向前跳转(通过获取播放列表的最新更新)至近直播点。在调入阶段之后，客户端设备处理播放列表中标识的媒体片段，具体做法是请求这些媒体片段，接收这些媒体片段并呈现这些媒体片段。当首先选择初始播放列表(例如，主播放列表)时，客户端设备可确定进入调入阶段。这通常在客户端设备的用户在接收到任何内容之前选择要观看的内容(例如，对直播活动诸如体育活动的选择)时发生。调入阶段旨在发现最新的播放列表，而不是缓存在例如内容分发网络(CDN)中的过时播放列表。在确定最近接收到的更新播放列表在该更新播放列表中的最后一个媒体片段之前只有几个新媒体片段(例如，小于3个)之后，客户端设备可决定退出调入阶段。当客户端设备在调入阶段接近近直播点时，在连续更新媒体播放列表中应存在更少的新媒体片段，并且客户端设备可退出调入阶段，并再新媒体片段的数量低于阈值时开始检索和呈现媒体片段。另选地，客户端设备可在调入阶段中花费预定的时间段之后退出调入阶段。另一种选择是在确定获得新的更新播放列表所花费的时间超过阈值之后退出调入阶段，这表明递送基础结构必须阻止响应以等待新片段的产生。
图3示出了可执行以请求将来媒体片段的方法的示例，并且图3中所示的方法可以由图2中的客户端设备103来实现。一种用于请求将来媒体片段的方法可在图3的操作151中开始，即确定源服务器支持低延迟直播流传输，例如低延迟形式的HTTP直播流传输(“HLS”)。客户端设备可通过读取(例如)直接或间接地从源服务器接收的主播放列表(或另选地媒体播放列表)中的标签来确定这种支持。例如，根据一个方面，主播放列表或媒体播放列表可通过表达“支持阻止重新加载”的标签来发信号通知这种支持(或者标签可表达：“支持低延迟流”)。根据一个方面，当客户端设备确定一个或多个服务器系统可支持低延迟模式时，客户端设备可启用低延迟模式并采用本公开所述的一个或多个方面。
在本公开的一个方面，客户端设备可仅在服务器系统指示支持时启用低延迟模式，并且这可以允许服务器系统控制允许哪些内容使用低延迟模式。实际上，服务器系统可分配低延迟模式，并允许其用于直播流活动并禁止将其用于非直播的流内容，诸如先前录制的内容(例如电影、电视节目等)。重新参见图3，在操作153中，客户端设备可请求初始播放列表，诸如初始媒体播放列表。然后在操作155中，客户端可在一个HTTP请求中请求下一个更新播放列表和该下一个更新播放列表中的媒体片段，该媒体片段可为将来媒体片段。然后，如操作157中所示，在接收到下一个更新播放列表和第一个媒体片段时，客户端设备可立即循环回到操作155，以请求下一个更新播放列表和该下一个更新播放列表中的媒体片段。通过重复操作155和157，客户端设备可通过跳过或跃过一系列一个或多个更新播放列表(而无需下载这系列中的一个或多个更新播放列表中的每个中的任何媒体片段)来快速调入直播活动(在调入阶段期间)以到达直播活动的近直播点(具有低延迟)。此外，在调入阶段之后，客户端设备可通过重复操作155和157来在直播活动的近直播点保持低延迟。根据网络连接的延迟，这可能意味着小到一或两秒的延迟，或大到3至6秒的延迟，具体取决于网络连接和其他因素。2秒的延迟意味着客户端设备在现场活动中发生的动作(例如，足球比赛中的进球)(该动作通过包括该客户端设备的流媒体内容递送系统呈现)2秒钟之后在客户端设备上呈现该现场活动中的动作。
图4示出了播放列表175的示例，该播放列表包括媒体片段，诸如图4 所示的作为播放列表175的最后一个媒体片段的媒体片段177。当客户端设备接收播放列表175时，客户端设备可检查该播放列表并确定哪个媒体片段是该播放列表中的最后一个媒体片段，然后可以通过基于最后一个片段的标识符(诸如最后一个片段177的媒体序列号＝46)得出用于将来媒体片段的标识符来确定将来媒体片段。例如，客户端设备可采用已知的预定编号约定，该约定可用于从当前播放列表中的最后一个媒体序列号得出用于将来媒体片段的下一个媒体序列号。在图4所示的示例中，利用媒体片段编号标识媒体片段，该媒体片段编号将在下文进一步解释并且可用于得出将来媒体片段。如本文所用，“将来媒体片段”是期望在可从提供流媒体内容的一个或多个服务器获得的下一个更新播放列表中的媒体片段。在图4 所示的示例中，已知的编号约定可为使用已知序列的整数，其中用于播放列表中最后一个媒体序列号的整数增加一(1)以得出用于下一个播放列表中的下一个媒体片段的媒体序列号。应当理解，另选的编号约定可以用于使用数字来标识媒体片段并得出将来媒体片段标识符，诸如用于将来媒体片段的媒体片段编号。如果第一个媒体片段在下一个播放列表中，则客户端设备可在接收到下一个播放列表及其第一个媒体片段之后，跳到第一媒体片段之后的下一个媒体片段；由于此跳过，媒体序列标签将增加1，以使按照msn的片段的标识保持一致。
图5A示出了可由客户端设备(诸如客户端设备103)执行的一种方法的示例，该方法通过使用并发的更新播放列表请求(还包括对将来媒体片段的请求)来提供对直播流媒体内容的低延迟接收。图5A中所示的方法可在操作201中开始。在操作201中，客户端设备可请求初始播放列表(诸如主播放列表)并接收该初始播放列表，然后从例如初始播放列表确定流传输源可通过低延迟流传输服务来支持低延迟流传输。可通过检测初始播放列表中指示这种支持的标签来作出该确定。然后在操作203中，客户端设备可选择并请求在初始播放列表中标识的特定媒体播放列表。客户端设备可接收所请求的媒体播放列表，并且开始请求所接收的媒体播放列表中的媒体片段以开始接收流内容。在操作205中，客户端设备可确定当前使用的媒体播放列表中的最后一个媒体片段，并得出用于在当前使用的媒体播放列表中的最后一个片段之后的将来媒体片段的标识符。在一个方面，客户端设备可使用编号约定来得出用于将来媒体片段的标识符。例如，如果当前播放列表中的最后一个片段由媒体序列号46标识，则下一个媒体序列号为47，并且对将来媒体片段的请求可使用媒体片段编号47作为用于该将来媒体片段的标识符。然后在操作207中，客户端设备可在一个HTTP请求中请求推送将来媒体片段和包含在操作205中由用于该将来媒体片段的标识符指定的下一个媒体片段的更新播放列表。根据一个方面，该下一个片段紧接在操作205中所引用的当前使用的播放列表中的最后一个片段之后。因此，客户端设备提出单个请求，该请求包含对更新播放列表和在该更新播放列表中包含的媒体片段(下一个媒体片段)的请求两者，并且还请求通过更新播放列表的传输来推送该下一个媒体片段。在某些方面，该请求可以可选地指定下一个片段的可用于下载的下一个可用位置，诸如通过部分编号来指定，并且可以可选地指定(例如，通过推送标签)所请求的将要推送的将来媒体片段的数量。例如，包括对更新播放列表和包含在该更新播放列表中的下一个片段的请求的请求还可指定部分编号和推送数量，该推送数量指定要推送的将来媒体片段的数量。下面相对于图5C对此进行进一步描述。在操作207之后，在操作209中，客户端设备可接收更新播放列表和所请求的下一个片段，并且一旦接收到这两者，就可以立即请求下一个更新播放列表和下一个片段(包含在该下一个更新播放列表中)。在操作211中接收到下一个更新播放列表和下一个片段(包含在该下一个更新播放列表中)之后，系统可在操作213中确定是否要停止流传输。如果不停止，则处理返回到操作209，并且在客户端设备正在接收流内容的同时，操作209和211可以继续。在一个方面，操作209中的该请求可通过由客户端设备的操作系统的调度机制作为高优先级过程调度的请求来提出，并且该调度可响应于接收到更新播放列表而发生。
图5A中所示的此方法可允许客户端设备快速调入直播活动，或者在调入阶段之后也可跟进直播流活动。例如，在调入阶段期间，客户端设备可跳过(而不下载)播放列表中的多个媒体片段，以跳转到或跳到当前媒体播放列表中的最后一个媒体片段。客户端设备可使用该最后一个媒体片段的标识符来得出用于包含在下一个播放列表中的下一个媒体片段(在该最后一个媒体片段之后)的标识符。根据一个具体实施，当客户端设备尝试快速调入到直播流活动时，这可能在不下载特定播放列表中的任何媒体片段的情况下发生。即使在客户端设备的调入阶段之后，客户端设备也可通过在接收到更新播放列表之后请求下一个播放列表和将来媒体片段(在该下一个播放列表中)，同时继续处理当前使用的播放列表，来以操作209 和211中所示的方式继续处理播放列表。在调入阶段之后，客户端设备将处理每个接收到的播放列表内的媒体片段(通过下载那些媒体片段并呈现那些媒体片段)，但还将在接收到当前使用过的播放列表时请求下一个播放列表和该下一个播放列表中包含的媒体片段。这样，客户端设备在调入阶段之后，可通过连续请求下一个更新播放列表以及预期在该下一个播放列表中的特定媒体序列号，同时还检索并呈现当前使用过的播放列表中的媒体片段，来跟进直播流内容。
图5B示出了媒体播放列表301的示例，该媒体播放列表包括多个媒体片段标识符，包括例如媒体片段标识符303、304、305、307和309。在图 5B所示的示例中，还为媒体片段中的一个(由媒体序列号47标识的媒体片段)提供部分标识符。在该示例中，媒体片段47可按部分被检索，并且这些部分中的一个包括由注释315指示的独立帧；这些注释的使用将在下面进一步描述。部分标识符311允许客户端设备检索第一部分，部分标识符313允许客户端设备指定对由传统媒体片段标识符309标识的媒体片段的两个部分中的第二部分的检索。除了媒体片段标识符305和307之外，媒体片段标识符309也可由客户端设备诸如传统客户端设备(其可能无法按部分来检索媒体片段)用来检索整个媒体片段，而不只是检索该媒体片段的一部分。在一个方面，可能期望将媒体片段分成仅用于更新播放列表中的最后一组媒体片段的部分，以使得接近直播活动的直播点并且已经请求了特定媒体片段的较早部分的客户端设备可跳转到该特定媒体片段的后一部分。例如，对于具有相对于直播活动小于4秒的延迟的客户端设备，该客户端设备可能已经请求了更新播放列表中的大多数媒体片段，但该更新播放列表中的最后几个媒体片段除外，因此，最后这几个媒体片段中的按部分的列表允许客户端设备选择在部分层级(而不是整个片段)上检索片段。参见图5B，在该示例中，客户端设备接收到更新播放列表301，但是由于对将来媒体片段的先前请求而已经请求了部分47.1(部分标识符 311)，因此客户端设备可请求部分47.2(部分标识符313)，因为源服务器已将该最后一个片段划分为播放列表中的各个部分，从而允许客户端设备请求整个媒体片段的各个部分。将媒体片段划分为多个部分，与客户端设备必须等待整个媒体片段变得可用的情况相比，这可允许第一部分更快地可供下载，从而可以减小查看该部分的延迟。
图5B中所示的媒体播放列表将与图5C中所示的示例结合使用，以示出根据一个方面的客户端设备如何可以提出对更新播放列表的请求，并且在同一请求中还提出对正在请求的更新播放列表中包含的将来媒体片段的请求。在图5C中所示的示例中，客户端设备可提出请求321，该请求包括播放列表请求部分323和将来媒体片段标识符325以及部分编号327和推送数量329。播放列表请求部分323可被认为是针对特定流媒体的基础或初始播放列表请求，并且将来媒体片段标识符325指定在包含由将来媒体片段标识符325标识的媒体片段的特定更新播放列表中的特定媒体片段。部分编号327指定由将来媒体片段标识符325标识的媒体片段内的特定部分。推送数量329指示客户端设备正在请求推送由媒体序列号47标识的媒体片段的两个部分(例如，第三部分和第四部分)。图5C中所示的整个请求是对更新播放列表和包含在该更新播放列表中的将来媒体片段两者的单个并发请求。该请求还指定该媒体片段的特定部分编号以及要推送的片段的数量(在图5C的示例中为2个媒体片段)。客户端设备可通过检查图 5B中所示的媒体播放列表301并确定媒体播放列表301中的最后一个片段是由包括部分标识符313的媒体序列标识符307来标识的，从而得出图5C 所示的请求。部分标识符313指示最后一个片段(在这种情况下是由媒体序列号47标识的媒体片段的一部分)是由媒体序列号47标识的那个媒体片段的第2部分。因此，客户端设备可以基于编号约定得出下一个媒体片段是由媒体序列号47标识的媒体片段的第3部分。当不使用部分编号时，客户端设备将检查当前使用过的播放列表，并(根据一个方面)对最后一个媒体序列号加一以得出用于要包含在所请求的更新播放列表中的将来媒体片段的标识符。
图6示出了服务器系统(诸如源服务器47或源服务器49)可以如何处理来自客户端设备(诸如客户端设备103，该客户端设备可使用图2或图3 或图5A中所示的方法)的请求和图5C中所示的请求以减小接收直播流内容时的延迟。根据本文所述的一个方面，服务器可遵循以下规则：只有当播放列表中标识的所有媒体片段都可用于下载之后，播放列表才能完成。服务器可使用符合HTTP的协议(例如HTTP或HTTP/2)进行操作。在操作351中，服务器可接收对更新播放列表的第一请求和标识该更新播放列表中的媒体片段的至少一部分的第一统一资源标识符(URL)。根据一个方面，第一请求使用符合HTTP的请求。然后在操作353中，服务器可响应于接收到第一请求来确定该更新播放列表在源服务器上尚不可用。这可能是由于该规则要求播放列表直到该播放列表中的所有媒体片段都可供下载时才能完成，如上所述。响应于确定更新播放列表不可用，服务器在操作 357中在更新播放列表不可用时阻止对第一请求的响应的完成。此外，在操作351中，服务器可保持已建立的套接字连接打开以发送第一请求。当更新播放列表变得可用时，则在操作359中，服务器可发送在操作351中接收到的请求中所请求的更新播放列表和所请求的媒体片段的至少一部分。这样，使用图6中所示方法的服务器可阻止请求，从而使服务器挂起请求，一旦更新播放列表可用，就可为请求提供服务，同时还保持套接字连接对提出请求的客户端设备打开。这可改善直播流媒体从服务器设备到客户端设备的传输的延迟。
图7示出了可由作为内容分发网络(诸如图1B所示的内容分发网络 45)的一部分的服务器执行的方法的示例。在操作401中，服务器可接收更新播放列表请求(诸如播放列表重新加载请求)，并且作为该请求的一部分，还接收对下一个片段的请求，该下一片段是在所请求的更新播放列表中找到的片段。然后在操作403中，内容分发网络中的服务器可确定该请求是否已经被本地缓存在内容分发网络中。内容分发网络中的服务器可缓存请求，并使用这些存储的请求来与新请求进行比较，以确定服务器是否已经具有所请求的内容，诸如更新播放列表或媒体片段。如果服务器具有所请求的内容，则服务器可在操作409中进行响应并提供内容。另一方面，如果在操作403中确定请求尚未被本地缓存，则服务器在操作405中将该请求发送到一个或多个源服务器，并等待从源服务器接收所请求的播放列表和所请求的下一个片段(这些内容是在操作401中请求的)。一旦服务器在操作407中接收到所请求的播放列表和所请求的下一个片段，服务器就将这两者缓存，然后前进到操作409，在该操作中，服务器响应对该更新播放列表的请求以及对更新播放列表中的媒体片段的请求。根据另一方面，内容分发网络中的服务器可跟踪播放列表的生存时间(TTL)数据，以跟踪播放列表是否已过时并且是否需要从源服务器刷新。例如，可删除已经超过其TTL的较旧播放列表，以保留更新播放列表，这可允许客户端设备更快速地调入直播流活动。
本公开中所述的另一方面涉及一种可以称为客户端回填的过程，其中当客户端设备确定缓冲区应被填满时，客户端设备可通过提出对已知媒体片段的多个并发请求来设法增加本地缓冲区内的内容。在一个具体实施中，客户端设备可在调入阶段之后使用客户端回填，并且在获得在每个更新播放列表中的最后一个媒体片段之前仅包含几个媒体片段(尚未在客户端设备上呈现过)的一个或多个更新播放列表后，可停止使用客户端回填。这可指示这些更新播放列表处于直播流活动中的直播点附近。
图8示出了客户端设备可如何在图8所示的方法450中使用客户端回填过程的示例。具体地，客户端设备451可在一个请求454中发送对多个媒体片段的一个或多个请求(例如，针对媒体序列号4和5)，并且该请求被发送455到服务器设备453，该服务器设备生成片段响应456。这引起传输457，其中片段4被发送到客户端设备451。显示为下载461的片段4的下载发生在沿着客户端设备451的垂直线所示的一段时间内。在片段4的下载结束时，客户端设备451发送请求460(针对媒体片段6)。在一个典型的具体实施中，服务器设备453还将已经利用片段响应458开始了片段5 的传输459，如图8所示。服务器进行的片段5的传输可在服务器完成片段 4的发送后立即开始，另选地可在服务器接收到有关客户端已接收到片段4 的最后一个部分的确定/确认后立即开始。因此，在片段5下载的同时发送对片段6的请求460。发送对片段6的请求(同时片段5正在下载)具有将预先请求保留在管道中的效果，并且这避免了在服务器发送片段5的最后一个字节之后的往返延迟(客户端收到片段5后对片段6的请求导致的往返延迟)。片段5的下载的时间显示为沿着客户端设备451的垂直线的下载465。当片段5的下载已经在客户端设备上完成时，客户端设备发送请求468，该请求是针对片段7的请求(经由传输469)，该片段是在片段6正在被下载(由于来自服务器设备453的响应464)时发送的(传输467)。在一个方面，来自客户端设备的请求指定了媒体片段之间的依赖关系，使得服务器可按适当的时间顺序发送或传输媒体片段，以使片段4被完整发送，并且下载在服务器开始发送片段5的任何部分之前完成。类似地，片段5的下载在服务器开始发送片段6的部分之前完成。在一个方面，可通过使用HTTP/2协议的请求来指定该依赖关系，以指示不同媒体片段之间随时间推移的依赖关系。这可确保服务器设备保持片段的正确顺序和片段的依赖关系，以便按照图8所示的方法正常工作。
图9示出了由客户端设备执行的方法的示例，并且该方法可类似于图 8中所示的方法450。图9的方法可从操作501开始，在该操作中，客户端设备和服务器设备使传输协议流依赖关系能够与流媒体一起使用；根据一个方面，可根据HTTP/2依赖关系机制来指定该依赖关系。在操作501之后，当确定客户端设备应启用回填模式时，客户端设备可在操作503中这样做。如本文所指出的那样，客户端回填模式在调入阶段之后可能有用，但是在接收到更新播放列表之后可能无用，这些更新播放列表在其中的最后一个媒体片段之前只有少量媒体片段。在该具体实施中，在客户端回填模式将在调入阶段之后启用，然后在某些时间点中断，如以下进一步说明的。在操作505中，客户端设备可请求在当前播放列表中标识的两个连续媒体片段，并且可指定这两个片段之间的依赖关系，使得在第一个下载响应完成之后调度第二个下载响应。例如，客户端设备可指定由第二媒体序列号标识的第二媒体片段依赖于具有第一媒体序列号的第一媒体片段，其中第二媒体片段在当前处理的更新播放列表中在第一媒体片段之后。然后在操作507中，客户端设备开始接收这两个片段中的第一个。在操作509 中，客户端设备监测这两个片段中的第一个片段的下载以确定该下载是否完成。如果未完成，则客户端设备将继续监测该下载。一旦下载完成，则执行操作511，在该操作中，客户端设备请求下一个媒体片段，并开始接收在操作505中的请求中所请求的两个片段中的第二个。然后在操作513 中，客户端设备确定这两个媒体片段中的第二个的下载状态，并确定该第二个片段的下载是否已经完成。如果未完成，则处理继续监测第二个媒体片段的下载。一旦在操作513中确定该下载完成，客户端设备就前进到操作515，在该操作中，客户端设备请求下一个媒体片段，并照旧开始接收前一个媒体片段。客户端设备在操作517中监测前一个媒体片段的下载，并继续这样做，直到下载完成。在某个时间点，客户端设备可确定是否中断回填(例如，临时中断)，并且这被示为在操作517之后的操作519。如果确定中断回填是适当的，则客户端设备前进到操作521(回填被禁用，但是客户端设备继续使用例如图5A的方法以低延迟操作)。在“播放头”(例如当前回放位置)接近近直播点和/或客户端设备已将大部分存储容量用于缓冲的媒体片段并且因为连接中的数据过多会削弱切换到较低比特率再现的能力(由于缓冲区膨胀)时，中断回填(例如临时中断)可能是合适的。如果在操作519中确定要继续回填，则处理返回到操作515，如图9所示。应当理解，在回填模式期间，客户端设备通常将指定各种媒体片段的依赖关系，使得服务器可按照本文所述的正确顺序正确地发送媒体片段。
图10示出了当客户端设备进入回填模式并执行图9所示的过程或图8 所示的过程时服务器设备可如何操作的示例。此外，服务器设备453可执行图10所示的方法，该方法可从操作551开始。在操作551中，服务器接收对在媒体播放列表中标识的两个连续媒体片段的请求，并接收指示这两个媒体片段之间的依赖关系或优先权的依赖关系数据。然后在操作553 中，服务器开始发送这两个媒体片段中的第一个，并在开始下一个媒体片段的任何传输之前完成该传输。在完成第一媒体片段的传输之后，服务器可在操作555中发送前一个片段，该前一个片段可为先前请求的两个片段中的第二个，并且在保持片段之间的依赖关系的同时接收对播放列表中的下一个媒体片段的请求。这可在操作557中继续，在该操作中，在发送前一个媒体片段和在保持片段之间的依赖关系的同时，继续接收对下一个媒体片段的请求。
本公开中所述的另一方面涉及控制在客户端设备与源服务器之间或源服务器与内容分发网络服务器之间的一个或多个网络中的缓冲区中的缓冲区膨胀。图11将这些缓冲区示为中间路由器603，这些中间路由器在流媒体内容从服务器到客户端设备的传输期间缓冲流媒体内容。这些中间路由器可保持较大的发送缓冲区，并且以正常的链路速度消耗这些缓冲区可能会导致响应延迟，该延迟表征缓冲区膨胀。内容递送系统600通常包括多个客户端设备605，这些客户端设备从源服务器和/或内容分发网络中的服务器接收媒体片段。客户端设备605可为图1B中所示的客户端设备，并且源服务器和内容分发网络可为图1B中所示的内容分发网络45以及源服务器47和49。图12中示出了一种用于控制缓冲区膨胀的方法，所述缓冲区诸如在发送流媒体数据的一个或多个网络中的中间路由器603中的缓冲区。在操作651中，客户端设备确定用于当前播放列表的回放的流的所需比特率。该所需比特率可为避免或防止通过使用当前播放列表检索的媒体流的回放停顿所需的最小比特率，或可确保网络的所有相关部分维持的任何比特率。在操作653中，客户端设备可测量客户端设备与提供播放列表和媒体片段的服务器设备之间的连接的往返时间。在一个具体实施中，客户端设备可通过检查用于打开TCP连接的分组的定时数据来测量往返时间。在另一个具体实施中，客户端设备可通过使用透明TCP代理无法欺骗的HTTP/2ping功能来测量往返时间。HTTP/2ping功能可由HTTP/2提供的加密来保护，并且对于提供准确的RTT(特别是对于使用透明代理的网络)，使用此ping功能可能更可靠。然后在操作655中，客户端设备可计算带宽时延积以确定发送窗口大小，该发送窗口大小可以维持由针对所测量的往返时间的所需比特率或最小比特率指定的所需吞吐量。在一个具体实施中，带宽时延积(BDP)可为在操作653中测量的往返时间(RTT)乘以在操作651中确定的最小所需比特率(RBR)(例如，BDP＝RTT×RBR)。在一个具体实施中，可通过将带宽时延积除以八或通过使用本领域中已知的其他技术得出发送窗口大小，来直接从带宽延迟积确定发送窗口大小。在操作655中确定发送窗口大小之后，客户端设备可在操作657中将所确定的发送窗口大小发送到正在将媒体片段发送到客户端设备的一个或多个服务器。然后，在操作659中，一个或多个服务器可将发送数据(诸如媒体片段)的突发限制在所接收的发送窗口大小，并且这有效地调节了吞吐量，并且即使在已使用例如本文所述的方法启用了直播活动的低延迟流传输的情况下也可使用该办法。因此，根据该方面，虽然可以保持低延迟以允许流直播活动具有低延迟，但是也可以通过将突发限制在由客户端设备根据图12中所示的具体实施示例确定的发送窗口大小来控制缓冲区膨胀。在操作657中发送所确定的发送窗口大小之后，客户端设备可在操作661中监测往返时间，以确定在一段时间内往返时间是否存在持久且显著的变化。如果已经确定持续变化存在了一段时间并且该持续变化超过阈值，则操作663可以通过使操作663如图12所示返回到操作651来重复该过程，从而使客户端设备重新计算发送窗口大小。可以将使用图12的方法来调节吞吐量与本文所述的其他各个方面进行组合，以实现对缓冲区膨胀的控制(避免发送媒体片段的网络中的拥塞)以及将延迟减小到用于直播流媒体的低延迟水平的目的。例如，图12所示的方法可以与图2、图3和图5A所示的方法以及本文所述的减小直播流媒体的延迟的其他方法相组合。图12的方法是限制发送窗口大小以避免中间路由器内部过度缓冲的若干可能方式中的一种；BDP是确定发送窗口大小的一种方法，但是其他方法可另选地用于选择发送窗口大小以减少过度缓冲，同时又不会过度损害下游带宽。
本公开中所述的其他方面涉及即使当在流媒体的再现(诸如相同流媒体内容(诸如相同直播体育活动)的不同比特率再现)之间切换时可如何实现低延迟。图13、图14、图15和图16涉及这样的方面，其中客户端设备可在相同的特定流媒体内容(诸如特定直播体育活动)的再现之间进行切换。图13中所示的方法可利用再现报告来允许客户端设备在再现之间进行切换，还可以快速调入新再现中的近直播点。再现报告可以针对每个再现指定信息，该信息指示在直播流媒体中的直播点附近的最新更新的播放列表。客户端设备可在操作701中请求再现报告；该请求可通过播放列表请求属性来提出，该播放列表请求属性在一个方面作为更新播放列表请求的一部分提供。客户端设备可在从当前再现的流回放时提出对再现报告的该请求，并且对再现报告的请求可为对更新播放列表的请求的一部分(因此，对再现报告的请求与对更新播放列表的请求在同一通信信道中)。例如，客户端设备可请求比当前再现高的较高比特率再现的再现报告，并且还可请求具有比当前正在由客户端设备通过使用当前播放列表呈现的当前再现低的比特率的较低比特率再现的再现报告。又如，客户端设备可基于当前连接状态和该连接状态上的吞吐量大小以及该吞吐量的历史来仅请求一个再现报告；例如，如果在流媒体内容的呈现期间吞吐量随时间的推移持续下降，则客户端设备可仅请求较低比特率再现的再现报告，使得随着该连接上的条件的恶化，客户端可准备切换到较低比特率再现。在一个示例中，客户端设备可响应于确定(从当前接收的再现)切换到另一再现而请求一组一个或多个再现报告，并且所述一个或多个报告可基于要切换过去的再现。另选地，客户端设备可接收包含在接收到的更新播放列表中的再现报告，而不必单独请求该再现报告。在操作703中，服务器可响应于对一个或多个再现报告的请求而发送所请求的再现报告，并且再现报告可与来自服务器的更新播放列表响应捆绑在一起，使得客户端和服务器不需要创建另一个信道来传送有关不同再现的最新信息，并且响应(包括再现报告)可被缓存在CDN中以有利于其他客户端提出相同的请求。另选地，服务器可将再现报告作为更新播放列表的一部分发送，而不需要客户端设备请求再现报告。再现报告可包含指示用于每个再现的媒体序列号的数据，这些媒体序列号基于直播流媒体内容中的近直播点表示最新可用的播放列表或最新更新的播放列表。客户端设备可在切换到新的再现时使用再现报告中的信息，以允许按照再现报告中的信息(诸如再现报告中指定的媒体序列号)所指定的那样更快地调入到直播点附近的新再现。例如，较低比特率再现的再现报告可指示msn＝56作为较低比特率再现的最新近直播点，而较高比特率再现的再现报告可指示msn＝97作为较高比特率再现的最新近直播点。
一组一个或多个服务器系统可通过收集数据(诸如用于最近更新播放列表末尾附近的最新媒体片段的URI)来如图13所示进行操作，并且该收集到的数据可用于生成再现报告。一旦生成，再现报告就可作为由客户端设备接收的更新播放列表的传输的一部分(例如，再现报告包含在该更新播放列表中)被发送，或者可与更新播放列表的传输分开地发送。源服务器可生成更新播放列表和这组再现报告，并将这些内容发送到缓存服务器，缓存服务器继而可根据来自客户端设备的请求将更新播放列表发送到客户端设备。
图14示出了本公开中所述的另一方面，其中通过使用播放列表注释来避免下载由于无法解码而无用的媒体片段(在新的再现中)，从而将播放列表注释用于改善当在再现之间进行切换时的延迟。在图14中所示的播放列表720中，存在若干媒体片段标识符，包括媒体片段标识符721、722、 727，以及部分标识符723、725、726和728。图14中所示的播放列表包括三个完整的媒体片段(媒体序列号42、43和44)以及第四媒体片段(媒体序列号45)的一部分(第1部分)。此外，播放列表示出了注释724和 729，这两个注释分别指示媒体片段的由部分标识符723标识的部分和媒体片段的由部分标识符728标识的部分包括独立帧，该独立帧可独立于其他帧而被解码以产生用于显示的可见图像。在一个方面，独立帧是一种关键帧，该关键帧包含得出和解码关键帧中的编码图像的所有必要数据，并且在时间上在独立帧之后的从属帧使用关键帧中的数据来解码从属帧中的编码图像；从属帧可包括P帧和B帧，这两类帧包括相对于其所依赖的独立帧的差异数据。由部分标识符725标识的媒体片段和由部分标识符726标识的媒体片段是从属帧，并且在不访问前一个独立帧的情况下无法被解码为视频帧的有效图像，该前一个独立帧在该情况下由部分标识符723所标识的媒体片段提供。除了具有如图14所示的媒体序列号44的相同媒体片段的部分标识符之外，播放列表720还包括“传统”媒体片段标识符727。因此，无法处理部分标签(诸如部分标识符723、725和726中包括的标签)的客户端设备可使用传统媒体片段标识符727请求具有媒体序列号44 的整个媒体片段。根据一个方面，可仅为后面的媒体片段标识符而不是在播放列表开头的片段标识符提供部分标识符，以避免不必要地扩大播放列表的不在直播边缘附近的区域。客户端设备可使用媒体片段内帧的独立性的注释来避免于在再现之间切换的过程中下载从属帧。这将结合图16进一步示出，该图将在下文进一步描述。
一组一个或多个服务器系统可生成播放列表，诸如包含注释(诸如注释724和729)的更新播放列表，其中注释指示其相应媒体片段包含独立帧。在对媒体片段进行编码的过程中，一个或多个服务器系统可确定媒体片段何时仅包含从属帧以及媒体片段何时包含一个或多个独立帧。当媒体片段包含至少一个独立帧时，服务器可在更新播放列表或其他播放列表中用注释对媒体片段进行注释，该注释指示媒体片段包含至少一个独立帧。播放列表中媒体片段的注释可由客户端设备用来避免当在再现之间进行切换时下载后面的媒体片段中独立帧之前的从属媒体片段。然后可将生成的包含此类注释的播放列表发送到一个或多个客户端设备(直接发送或通过缓存服务器间接发送)。
图15示出了根据一个实施方案的方法，该方法可当在再现之间进行切换时并且在也尝试为直播流活动保持低延迟时将多个方面组合成单个过程。应当理解，可将这些方面中的一些排除在具体实施之外，而不是使用如图15所示的所有方面；因此，可以在具体实施中使用图15所示的方面的子集(一个或多个)，而不是使用所有这些方面。一种典型的方法可如操作801中所示那样开始，其中客户端设备监测用于流媒体内容的当前再现的连接的带宽或吞吐量。在监测带宽的同时，客户端设备可在操作803 中定期重复地请求(或不请求而接收)再现报告，以了解用于各种再现的直播活动的最新内容的当前状态。这些对再现报告的请求可与对更新播放列表的请求捆绑在一起(并且是对更新播放列表的请求的一部分)，并且服务器可使用与所请求的再现报告捆绑在一起的更新播放列表对这些请求进行响应。例如，这些再现报告可为客户端设备请求的每个再现指定最新和最近的媒体序列号。在一个具体实施中，客户端设备可请求两个再现报告，一个报告用于比特率比当前再现高的较高比特率再现，另一个报告用于比特率比当前再现低的较低比特率再现。在其他具体实施中，客户端设备可请求所有再现报告。本文所述的图13提供了有关再现报告的更多信息，以及如何将再现报告用作操作803的一部分。在操作805中，客户端设备确定是否切换到不同再现。例如，当连接恶化(例如，带宽正在减小)时，客户端设备可决定在带宽减小时切换到较低分辨率的再现。另一方面，当带宽在改善时，客户端设备可切换到较高比特率的再现(该再现可提供较高分辨率的图像)。如果在操作805中确定不切换，则客户端设备返回到操作801并继续如图15所示的过程。另一方面，如果客户端设备决定切换到不同的再现，则在操作807中，客户端设备选择新的再现，并且可使用针对所选择的新再现的最新的再现报告来请求用于在操作807中选择的新再现的最近的(例如，最新可用的)更新播放列表。
如本文所解释的，最新再现报告通过msn值或其他机制来指定最近更新播放列表(诸如最新可用的播放列表)中的最近媒体片段，以允许客户端设备快速调入用于该新再现的流内容中的近直播点。在操作807中，客户端设备可通过请求最近更新播放列表来开始下载该播放列表，并且还可在切换到新再现之前继续从当前再现下载媒体片段。因此，根据一个方面，客户端设备可并发地从当前再现下载媒体片段和从用于新再现的最近更新播放列表下载媒体片段。
根据本公开的一个方面，在操作809中，客户端设备可在用于新再现的最近更新播放列表中使用播放列表注释来选择要下载的媒体片段，而不是开始下载最近更新播放列表中的第一个媒体片段，并且这可避免下载无法使用的媒体片段，诸如作为依赖于独立帧的从属帧的媒体片段，该独立帧不在用于该新再现的最近更新播放列表中。根据一个具体实施的方面，操作809可为可选的，因此播放列表注释的使用可为可选的；如果用于新再现的最近更新播放列表不包括播放列表注释，则在切换到新再现的过程中不执行操作809。一旦选择了用于新再现的媒体片段进行下载，就可请求这些媒体片段以开始这些媒体片段的下载。在根据本公开的一个方面的一个具体实施中，可请求用于当前再现的媒体片段和用于新再现的媒体片段并且并发地下载这些媒体片段，至少直到完成向新再现的切换为止。
在本公开的一个方面，客户端设备可以可选地(在操作811中)在传输协议(诸如HTTP/2协议)中使用相对权重来指定下载/发送优先级(在切换之前)以相对于其他组媒体片段优先考虑一组媒体片段(例如，较低比特率的媒体片段)。如果客户端设备使用相对权重，则根据本公开的一个方面，在给定的时间段内，服务器将发送比较高比特率再现的媒体片段更多的较低比特率再现的媒体片段。例如，客户端设备可指定一对值，诸如200(用于较低比特率的再现)和56(用于较高比特率的再现)(总和为256)；这可导致服务器在同一时间段内并发地发送数量是较高比特率再现的媒体片段4倍的较低比特率再现的媒体片段。相对于较高比特率再现的媒体片段的传输优先考虑较低比特率再现的媒体片段的传输可在至少一部分时间期间发生，同时在实际切换到新再现之前缓冲用于新再现的媒体片段。在切换之前的这段时间期间，可下载(例如，从服务器接收)两个再现的媒体片段并进行缓冲，同时呈现当前再现的媒体片段(例如，显示在显示设备上，而且具有来自当前再现的声音)。在一个具体实施中，在操作813中，客户端设备可决定在缓冲新再现的至少一个独立帧(如播放列表注释所示)之后进行切换。图16中示出了当切换可以发生时操作813 的示例。
现在参见图16，该图示出了在时间上相对于旧再现903的新再现 901。客户端设备已决定切换到新再现901，但仍继续下载旧再现903，同时有选择地确定要下载哪些媒体片段(或这些片段的一些部分)，同时开始缓冲来自新再现901的选定媒体片段。根据用于新再现的更新播放列表中的播放列表注释，客户端设备已经基于在包含媒体片段905、907和909的播放列表中指定的独立帧906和908分别存在而确定存在两个可能的切换点916和919。具体地，用于新再现901的播放列表中的播放列表注释指示独立帧906和908分别在媒体片段905和907中的每一者内的存在和位置。因为媒体片段905中在独立帧906之前的所有帧都是从属帧，所以客户端设备可决定避免下载这些从属帧。因此，第一个可能的切换点是切换点916(在独立帧906处)，第二个可能的切换点是切换点919，因为该切换点也包括一个独立帧908。第三个可能的切换点在媒体片段909中的独立帧910处。与从新再现901下载至少一个媒体片段并发地下载旧再现903 的媒体片段912、914、915和917；如果客户端设备选择了后面的切换点 (诸如切换点919)作为从旧再现切换到新再现的时间点(因此新再现呈现在客户端设备上，而不是旧再现)，则也可下载来自旧再现901的媒体片段921和923。可当客户端设备已在其缓冲区中存储了具有至少一个独立帧的新再现时进行切换。在一个具体实施中，客户端设备可能不会决定仅使用单个独立帧进行切换，而是等待直到多个独立帧已被缓冲，诸如在图16 中所示的示例中。
具体实施的示例的更多细节
以下部分描述了低延迟流传输可如何成为RFC 8216(Pantos,R.和May, W.，“HTTPLive Streaming”，RFC 8216，2017年8月，https://www.rfc- editor.org/info/rfc8216)和draft-pantos-hls-rfc 8216bis(参见 https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-00)中记录的现有HTTP 直播流传输(HLS)协议的扩展。HLS协议的功能得到了增强，这些功能允许客户端设备(例如智能手机、平板电脑和其他数据处理系统)在许多情况下支持公共网络上两秒或更短的视频延迟。本部分是不应被解释为限制上述其他具体实施的实施方式的示例，尽管上述实施方式和方面可以可选地利用本部分中所述的一个或多个方面。例如，在本部分中使用词语“必须”不应解释为限制上述其他具体实施。在本部分中使用词语“必须”表示该功能对于为HLS流传输实现非常低的延迟而言非常期望，或者对于与本部分中所述的低延迟HLS协议兼容而言是必需的。HLS协议的这种增强的语法向后兼容现有HLS，因此，如果服务器(或客户端)不支持低延迟 HLS，则客户端可回退到常规延迟HLS回放。
播放列表请求参数
客户端设备可以利用包括一个或多个查询参数的请求来请求更新播放列表：参数HLS_msn＝<N>；参数HLS_part＝<M>；参数HLS_push＝<0/1>；以及参数HLS_report＝<uri>。参数HLS_msn＝<N>指示服务器必须保留请求，直到播放列表包含媒体序列N或后面的媒体序列。参数HLS_part＝<M>联合参数HLS_msn指示服务器必须保留请求，直到播放列表包含媒体序列N的第M部分或后面的部分；媒体片段的第一部分为 HLS_part＝0，第二部分为HLS_part＝1，依此类推。使用参数HLS_part需要使用参数HLS_msn。如果播放列表包含指示流的末尾(没有更多内容)的标签(例如EXT-X-ENDLIST标签)，则参数HLS_msn和HLS_part不会在服务器上触发阻止。如果客户端设备要求部分编号大于媒体片段中的最后一部分，则服务器必须递送包含后一个媒体片段的第一部分的播放列表。在一个具体实施中，服务器应使用超时持续时间，该超时持续时间触发服务器的503(服务不可用)响应，是媒体播放列表中指定的目标持续时间(针对媒体片段)的3倍；可使用3以外的倍数。参数HLS_push＝<0/1> 指示服务器是否应将请求的将来媒体片段(或其一部分)与播放列表响应一起推送；1指示要推送将来媒体片段，0指示不推送。参数 HLS_report＝<uri>请求播放列表响应包含用于指定的再现的EXT-X- RENDITION-REPORT标签；uri指向指定的再现的媒体播放列表，并且uri 应相对于正提出的媒体播放列表请求的uri。可为不同的URI允许多个报告参数。客户端设备必须以UTF-8顺序对所有低延迟HLS查询参数进行排序，并将其放在URL中的任何其他查询参数之后；该做法将增大CDN缓存利用率。
媒体播放列表标签和媒体片段标签
来自服务器的媒体播放列表中的阻止重新加载标签EXT-X- BLOCKING-RELOAD:<attribute-list>指示在该具体实施中支持低延迟HLS 并且需要低延迟HLS以便服务器向接收媒体播放列表的客户端设备指示这种支持。在该具体实施中，如果服务器提供这种支持，则所有媒体播放列表都必须包括具有相同属性和值的该标签。该标签的属性列表中的一个属性可为part-target＝<s>，该属性指示以浮点秒为单位的部分目标持续时间；部分目标持续时间可为任何局部媒体片段(例如，由_HLS_msn和_HLS_part 指定的媒体片段)的最大持续时间。在该具体实施中，除了媒体片段的最后一个部分之外所有局部媒体片段必须具有part-target＝<s>的至少(例如) 85％的持续时间。该阻止重新加载标签的属性列表中的另一个属性可为hold-back＝<s>，该属性是以浮点秒为单位的阻止重新加载抑制持续时间；从播放列表末尾开始的该hold-back＝<s>秒抑制持续时间是从直播播放列表末尾开始的(在时间上)最小距离，应允许从该最小距离开始回放或者播放器应寻找到该最小距离。在该具体实施中，hold-back＝<s>属性中s的值必须大于或等于part-target＝<s>属性中s的值；例如，推荐hold-back＝<s>属性中s的值为part-target＝<s>属性中s的值的至少3倍。
标识媒体片段各部分(“局部片段”)的标签可为以下形式：EXT-X- PART:<attributelist>。在该具体实施中，由服务器提供媒体片段的各部分的并行信道，还由服务器提供整个媒体片段的另一信道。该并行信道用于分发在媒体播放列表的直播边缘的媒体，其中该媒体被划分为大量小文件，诸如CMAF(通用媒体应用格式)块。这些小文件中的每个都是所述部分 (也称为局部片段)中的一个。由于每个局部片段具有比完整媒体片段短的持续时间，因此可比完整媒体片段更早地将局部片段打包、发布和添加到媒体播放列表。虽然完整媒体片段的持续时间可(例如)为约6秒，但每个局部片段的持续时间可(例如)仅为200毫秒。因此，第一局部片段可能会仅在前一个完整片段发布后200毫秒发布，随后是29个同等的局部片段，最后是一个常规的6秒完整媒体片段，该媒体片段包含与其30个局部片段的串联产物相同的媒体。为了减小媒体播放列表膨胀，一旦局部片段大于(旧于)从直播边缘起的(例如)3倍目标持续时间，就可将局部片段从媒体播放列表中删除。局部片段主要用于在近直播点(也称为直播边缘)附近进行操作/导航；除此之外，局部片段的存在并不能证明媒体播放列表的大小增大以及服务器有关保留并行的局部片段流(除了常规的完整媒体片段流)的负担是合适的。在该具体实施中，EXTINF标签之间的一组 EXT-X-PART标签必须表示与后一个EXTINF标签的片段相同的一组媒体。该具体实施中的媒体片段标签(诸如EXT-X-DISCONTINUU、EXT-X- KEY和EXT-X-BYTERANGE)不能出现在同一父片段的两个EXT-X- PART标签之间，但EXT-X-DATERANGE除外。EXT-X-PART标签可包括以下属性：DURATION＝<s>；URI＝<str>；INDEPENDENT＝YES；和 BYTERANGE＝<n>[@<o>]。属性DURATION＝<s>指示该部分的以浮点秒为单位的持续时间，并且是该具体实施中的必需属性。属性URI＝<str>指示该部分的URI，并且也是该具体实施中的必需属性。属性INDEPENDENT＝YES指示该部分(至少)包含一个独立帧(无需使用任何先前的帧即可被解码)的起点，并且是必需属性(如果适用于正在流传输的媒体)。属性BYTERANGE＝<n>[@<o>]指示该部分是URI的子范围。
用于提供再现的再现报告的标签可为以下形式：EXT-X-RENDITION- REPORT:<attribute-list>；由服务器响应于来自客户端设备的“报告”查询参数而将该标签添加到媒体播放列表(例如，参见图13中的操作701和 703)。该标签携带有关相关再现的信息，该相关再现与包含带有该信息的标签的播放列表一样最新。服务器可提供比客户端设备所请求的更多的 RENDITION-REPORT标签。EXT-X-RENDITION-REPORT:<attribute-list> 标签可包含以下属性：URI＝<URI>；LAST-MSN＝<N>；和LAST- PART＝<M>，并且还可提供LAST-I-MSN＝<NI>和LAST-I＝PART＝<MI>。属性URI＝<uri>指示(例如，标识)用于再现的报告中描述的媒体播放列表并且应为与报告查询参数相同的字符串，并且在该具体实施中必须在标签中提供。属性LAST-MSN＝<N>指示当前在指定的再现中的最后一个媒体片段的媒体序列号，并且在该具体实施中必须在标签中提供。属性LAST- PART＝<M>指示由当前在指定的再现中的媒体序列号(msn)指定的媒体片段的最后一个部分。属性LAST-I-MSN＝<NI>指示(至少)包含当前在指定再现中的独立帧起点的最后一个媒体片段的msn，并且属性LAST-I-PART＝<MI>指示至少包含独立帧起点的最后一个媒体片段的最后一个独立部分(至少包含独立帧的起点)。
服务器配置配置文件
在该具体实施中，低延迟HLS要求某些传输功能超越常规延迟HLS 中使用的传输功能，如RFC 8216(在上文中指出)中记录，并且客户端设备应在客户端设备采用低延迟模式之前验证是否支持这些功能。
在该具体实施中，必须经由HTTP/2协议为低延迟HLS流提供服务，并且推荐使用TCP协议，而QUIC(最近开发的传输层网络协议)可在将来的具体实施中使用。应使用HTTP/2中的若干功能，包括：针对依赖关系和权重的多重流控制(如上所述)，HTTP/2推送(例如，利用更新播放列表响应来推送将来媒体片段)和HTTP/2Ping(用于测量RTT)。在该具体实施中，服务器必须支持针对流依赖关系和权重的HTTP/2优先级控制(例如，在再现之间进行切换时，控制再现之间的优先级)。在该具体实施中，每个服务器应为主播放列表中的整个一套层级或再现提供服务，并且这允许在不重新建立连接的情况下快速切换层级或再现。换句话讲，服务器应提供主播放列表中指定的所有媒体播放列表。在该具体实施中，如果使用TCP，则此类TCP具体实施必须在从客户端到服务器的整个路由中支持SACK(选择性确认，参见RFC 2018了解更多信息)。另外，如果在该具体实施中使用TCP，则推荐使用TCP时间戳、ECN(显式拥塞通知，参见RFC 3168了解更多信息)、尾部损失探测(参见RFC 7323和https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01了解更多信息)和TCP RACK(最近的确认，参见https://tools.ietf.org/id/draft-ietf- tepm-rack-03.html)以便改善TCP丢失恢复的性能。
在低延迟HLS的该具体实施中，必须使用例如GZIP来压缩媒体播放列表(而不是媒体片段)；这可加快媒体播放列表重新加载(播放列表更新)和再现转换的速度。播放列表压缩的示例在美国专利8,156,089中有所描述。
在低延迟HLS的该具体实施中，CDN和代理缓存必须识别与现有请求匹配的客户端播放列表请求，该现有请求当前在源服务器上待完成，并保留这些重复的请求，直到源服务器响应该现有请求为止。图7提供了该过程的示例。对于该功能，CDN具有不同的名称；例如，Apache Traffic服务器将此功能称为“边读边写”。活动的源导致非常需要此功能。
在低延迟HLS的该具体实施中，推荐将具有低延迟HLS查询参数的播放列表请求缓存(例如，在CDN中缓存)6倍目标持续时间，因此如果媒体片段(在所请求的播放列表中)的目标持续时间为例如6秒钟，则应将这些播放列表请求缓存36秒(因此可将这些播放列表请求的生存时间 TTL设置为36秒)。推荐将未经修饰的播放列表请求/响应缓存目标持续时间的二分之一。源应使用缓存控制标头来指示缓存时长。还推荐并发地更新用于不同再现的播放列表，以使这些播放列表基本上同步到1倍目标持续时间或更短的时间内(例如，在1倍部分目标持续时间内，该部分目标持续时间可为200毫秒)。使用这些缓存推荐可改善缓存效率。
在低延迟HLS的该具体实施中，媒体播放列表必须具有PROGRAM- DATE-TIME标签；这些标签允许跨程序的不同再现在媒体片段之间进行更精确的映射。但是，不需要客户端和服务器之间的时钟同步。推荐6秒的目标持续时间用于低延迟HLS。推荐1至2秒的GoP(图片组)大小用于低延迟HLS。
以下媒体播放列表是低延迟HLS播放列表的示例，该示例包括对本部分以及本公开的其他部分中已描述的HLS的增强。
低延迟HLS播放列表的示例
#EXTM3U
#该播放列表是对以下命令的响应：GET https://example.com/2M/waitForMSN.php？_HLS_msn＝273&_HLS_part＝2&_H LS_report＝../1M/waitForMSN.php&_HLS_report＝../4M/waitForMSN.php
#EXT-X-TARGETDURATION:4
#EXT-X-VERSION:3
#EXT-X-BLOCKING-RELOAD:PART-TARGET＝0.33334,HOLD- BACK＝1.0
#EXT-X-MEDIA-SEQUENCE:268
#EXT-X-PROGRAM-DATE-TIME:2019-02-14T02:13:36.106Z
#EXTINF:4.000008,
fileSequence268.ts
#EXTINF:4.000008,
fileSequence269.ts
#EXTINF:4.000008,
fileSequence270.ts
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.1.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.2.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.3.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.4.ts"
#EXT-X- PART:DURATION＝0.33334,URI＝"filePart271.5.ts",INDEPENDENT＝YES
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.6.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.7.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.8.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.9.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.10.ts"
#EXT-X- PART:DURATION＝0.33334,URI＝"filePart271.11.ts",INDEPENDENT＝YES
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart271.12.ts"
#EXTINF:4.000008,
fileSequence271.ts
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.a.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.b.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.c.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.d.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.e.ts"
#EXT-X- PART:DURATION＝0.33334,URI＝"filePart272.f.ts",INDEPENDENT＝YES
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.g.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.h.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.i.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.j.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.k.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart272.l.ts"
#EXTINF:4.000008,
fileSequence272.ts
#EXT-X- PART:DURATION＝0.33334,URI＝"filePart273.1.ts",INDEPENDENT＝YES
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart273.2.ts"
#EXT-X-PART:DURATION＝0.33334,URI＝"filePart273.3.ts"
#EXT-X-RENDITION-REPORT:URI＝"../1M/waitForMSN.php",LAST- MSN＝273,LAST-PART＝20
#EXT-X-RENDITION-REPORT:URI＝"../4M/waitForMSN.php",LAST- MSN＝273,LAST-PART＝19
图17为根据一个实施方案的数据处理系统1000的框图。需注意，虽然图17示出了可结合到移动设备或手持设备或服务器系统的数据处理系统的各种部件，但这并不旨在表示将这些部件互连的任何特定的架构或方式，因为此类细节与本发明并无密切关系。还应理解，还可将具有比所示更少部件或更多部件的其他类型的数据处理系统在各种实施方案中使用。
数据处理系统1000包括用于将系统的各种部件互连的一条或多条总线 1009。一个或多个处理器1003如本领域中所公知地耦接到一条或多条总线 1009。存储器1005可为易失性DRAM或非易失性RAM，诸如NOR闪存存储器或其他类型的高速、非易失性、就地执行存储器。该存储器可使用本领域已知的技术耦接到一条或多条总线1009。数据处理系统1000还可包括显式非易失性存储器1007，诸如包括一个或多个硬盘驱动器的数据存储设备、闪存存储器设备或在系统断电后保持数据的其他类型的存储器系统。非易失性存储器1007和存储器1005可各自使用已知的接口和连接技术耦接到一条或多条总线1009。显示控制器1022可耦接到一条或多条总线 1009以接收可在显示设备1023上显示的显示数据。在一个实施方案中，显示设备1023包括集成式触摸输入以提供触摸屏。
数据处理系统1000还可包括一个或多个输入/输出(I/O)控制器1015，所述I/O控制器为一个或多个I/O设备提供接口，所述一个或多个I/O设备诸如一个或多个鼠标、触摸屏、触摸板和其他输入设备(包括本领域已知的那些)，以及输出设备(例如，扬声器)。输入/输出设备1017如本领域中所公知地通过一个或多个I/O控制器1015耦接。
尽管数据处理系统1000将存储器1005和非易失性存储器1007示为直接耦接到一条或多条总线，但是在一个实施方案中，非易失性存储器1007 可远离数据处理系统1000，诸如在通过网络接口(诸如调制解调器、无线 LAN或以太网接口)耦接到数据处理系统的网络存储设备中。如本领域所熟知的，总线1009可通过各种网桥、控制器和/或适配器彼此连接。在一个实施方案中，I/O控制器1015包括用于控制USB外围设备的USB(通用串行总线)适配器或用于控制Thunderbolt外围设备的Thunderbolt控制器中的一者或多者。在一个实施方案中，一个或多个网络设备1025可耦接到一条或多条总线1009。一个或多个网络设备1025可为有线网络设备(例如，以太网)或无线网络设备(例如，WI-FI、蓝牙、蜂窝电话等)。
通过本描述将显而易见的是，本发明的各实施方案和方面可至少部分地在软件中体现。也就是说，响应于处理器执行存储在存储介质(诸如非暂态机器可读存储介质，诸如易失性DRAM或非易失性闪存存储器)中的指令序列，处理器可在数据处理系统或一组数据处理系统中执行这些技术和方法。在各种实施方案中，可将硬连线的电路与软件指令结合使用来实施本文所述的实施方案。因此，这些技术和方法不限于硬件电路与软件的任何指定组合，也不限于由一个或多个数据处理系统执行的指令的任何特定源。
以下实施方案或方面是与本公开有关的有编号的实施方案或方面，并且这些有编号的实施方案作为在本公开的第一段中提及的在先美国临时专利申请中的权利要求呈现。
实施方案1.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
以符合传输协议的方式接收第一播放列表，第一播放列表包括多个统一资源标识符(URI)，所述多个URI指示可以符合传输协议的方式接收以重新创建数据流的多个媒体片段的回放顺序，第一播放列表按该顺序包括最后一个URI，该最后一个URI标识第一播放列表中的最后一个可用媒体片段，该最后一个可用媒体片段在当第一播放列表创建时不可用的将来媒体片段的至少一部分之前；
在符合传输协议的单个请求中，发送用于对更新播放列表的请求和对将来媒体片段的至少一部分的请求的URI，该更新播放列表包括用于该数据流的媒体片段的第二多个URI；以及
响应于该单个请求，接收更新播放列表和响应对将来媒体片段的请求的将来媒体片段的至少一部分。
实施方案2.如实施方案1的介质，其中该方法还包括：请求主播放列表，该主播放列表包括多个可用媒体播放列表；以及从主播放列表请求第一播放列表，该第一播放列表是所述多个可用媒体播放列表中的一个。
实施方案3.如实施方案1的介质，其中该方法还包括：
在接收到更新播放列表之后，确定该更新播放列表中的用于在该更新播放列表中标识的最后一个可用媒体片段的URI；以及
在请求在更新播放列表中标识的所有媒体片段之前，在单个符合 HTTP的请求中请求：(1)另一个更新播放列表，该另一个更新播放列表标识在由更新播放列表标识的最后一个媒体片段之后的第二媒体片段，以及 (2)该第二媒体片段。
实施方案4.如实施方案3的介质，其中对该另一个更新播放列表和第二媒体片段的请求作为高优先级过程发生，该高优先级过程响应于接收到更新播放列表而被快速调度以便快速调入到直播活动。
实施方案5.如实施方案1的介质，其中标识将来媒体片段的URI指定在第一播放列表创建时不存在的将来媒体片段内的起始位置，并且其中该起始位置在该将来媒体选择片段的起点和终点之间。
实施方案6.如实施方案3的介质，其中在用于获取由直播活动的数据流提供的直播流内容的调入阶段期间；重复地跳到一系列更新播放列表中的下一个播放列表中的下一个URI中的每个，以寻找该直播流内容中的最新回放时间，并且其中快速请求通过该系列的连续播放列表更新，以便区分缓存在CDN或源服务器中的较旧播放列表更新与正在源服务器处完成的过程中的近直播点更新播放列表，并且其中该直播活动是与在调入阶段之后数据处理系统用户正在观看该活动的同时发生的活动。
实施方案7.如实施方案2的介质，其中主播放列表或第一播放列表中的至少一者指定用于数据流的一个或多个源服务器可支持对其他媒体片段的请求以为直播活动提供低延迟流传输服务。
实施方案8.如实施方案3的介质，其中由第一播放列表中的URI标识的多个媒体片段的长度各自小于约5至10秒，并且由第二多个URI的标识的多个媒体片段的长度各自小于约5至10秒，并且其中将来媒体片段从服务器被推送到作为客户端设备的数据处理系统。
实施方案9.如实施方案5的介质，其中第一播放列表中的最后一个 URI包括用于媒体序列号的第一标签和用于部分编号的第二标签，该第二标签指定由最后一个URI标识的媒体片段内的起始位置。
实施方案10.如实施方案3的介质，其中在请求更新播放列表之后将套接字连接保持在打开状态，使得通过该套接字连接来接收更新播放列表和将来媒体片段的至少一部分，并且其中该方法还包括：请求再现报告。
实施方案11.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
接收对由第一统一资源标识符(URI)标识的更新播放列表的第一请求和对该更新播放列表中的第一媒体片段的至少一部分的请求，第一请求作为单个符合传输协议的请求接收，该单个符合传输协议的请求请求该更新播放列表和第一媒体片段的所述至少一部分两者；
响应于接收到第一请求，确定更新播放列表尚不可用；
在更新播放列表尚不可用时，阻止完成对针对更新播放列表的第一请求的响应；以及
一旦更新播放列表变得可用，则响应于第一请求，发送该更新播放列表和第一媒体片段的所述至少一部分。
实施方案12.如实施方案11的介质，其中第一媒体片段为更新播放列表中按照标识多个媒体片段的媒体片段顺序的第一个媒体片段，并且该顺序指定了可使用该更新播放列表检索的多个媒体片段的回放顺序。
实施方案13.如实施方案12的介质，其中在阻止响应的完成并且在发送更新播放列表和第一媒体片段的所述至少一部分的同时，由第一请求建立的套接字连接保持打开。
实施方案14.如实施方案11的介质，其中更新播放列表和第一媒体片段的所述至少一部分作为对第一请求的单个响应的一部分被发送。
实施方案15.如实施方案11的介质，其中该方法还包括：
接收对主播放列表的请求并发送该主播放列表；
接收对选自在该主播放列表中标识的一组媒体播放列表中的一个媒体播放列表的请求，其中所选的媒体播放列表在对更新播放列表的第一请求被接收之前由远程客户端设备至少部分地处理。
实施方案16.如实施方案11的介质，其中该数据处理系统是一组一个或多个源服务器，这些源服务器接收在更新播放列表中标识的流内容并完成该更新播放列表的创建，从而使得在接收到第一请求之后该更新播放列表可用于传输到一个或多个客户端设备。
实施方案17.如实施方案11的介质，其中该方法还包括：在第一请求中，接收推送标签，该推送标签指定要作为对第一请求的响应的一部分而发送的媒体片段或一个或多个媒体片段的部分的数量，其中媒体片段数量的推送允许发送第一请求的客户端设备避免发送对媒体片段数量的请求。
实施方案18.如实施方案15的方法，其中主播放列表或媒体播放列表中的至少一者指定数据处理系统可支持对将来媒体片段的请求以提供低延迟流传输服务。
实施方案19.如实施方案11的方法，其中第一个URI包括用于媒体序列号的第一标签和用于部分编号的第二标签，该第二标签指定由媒体序列号标识的媒体片段内的位置。
实施方案20.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
发送对媒体播放列表的第一请求，该媒体播放列表包括多个统一资源标识符(URI)，这些URI指示以符合传输协议的方式回放多个媒体片段以重新创建数据流的顺序；
响应于第一请求，接收媒体播放列表，并选择由在接收到的媒体播放列表中的两个URI指定的两个连续媒体片段；
将对这两个连续媒体片段的第二请求作为一个或多个符合传输协议的请求发送，并且该第二请求指定这两个连续媒体片段之间的下载依赖关系，该下载依赖关系指定应在对这两个连续媒体片段中的第一个的第一下载响应之后调度对这两个连续媒体片段中的第二个的第二下载响应；
响应于第二请求，接收这两个连续媒体片段中的第一媒体片段；
确定第一媒体片段的下载是否已经完成；以及
响应于确定第一媒体片段的下载已经完成，发送对紧接在这两个连续媒体片段中的第二媒体片段之后的下一个媒体片段的第三请求，该第三请求在第二媒体片段正在下载时发生并指定在第二下载响应之后调度对第三请求的第三下载响应。
实施方案21.如实施方案20的介质，其中传输协议是超文本传输协议/2(HTTP/2协议)。
实施方案22.如实施方案21的介质，其中第二请求使用HTTP/2协议来指定下载依赖关系，使得在开始下载第二媒体片段之前，第一媒体片段被完全下载，并且其中该方法还包括：请求再现报告。
实施方案23.如实施方案20的介质，其中媒体播放列表选自所请求并接收的主播放列表，该主播放列表指定数据流的一组再现。
实施方案24.如实施方案20的介质，其中媒体播放列表是更新播放列表，并且数据流用于直播活动，并且其中响应于第一请求进行接收还包括：接受由第一个URI指定的将来媒体片段，该第一个URI按照更新播放列表中的多个媒体片段的回放顺序。
实施方案25.如实施方案24的介质，其中数据处理系统在作为单个 HTTP请求的第一请求中请求在单个HTTP/2请求中的媒体播放列表和将来媒体片段两者。
实施方案26.如实施方案20的介质，其中该方法还包括：
确定是否在前一个媒体片段正在下载时停止发送对后一个媒体片段的请求。
实施方案27.如实施方案26的介质，其中数据处理系统基于在近直播媒体片段相对于直播活动具有低延迟之前更新播放列表中存在多少媒体片段来确定停止发送对后一个媒体片段的请求。
实施方案28.如实施方案27的介质，其中低延迟基于阈值。
实施方案29.如实施方案20的介质，其中数据处理系统被配置为尝试实现数据流相对于实时活动的低延迟呈现。
实施方案30.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
测量数据处理系统和服务器系统之间的连接的往返时间，该连接用作流媒体到数据处理系统的符合HTTP的传输的一部分；
确定发送窗口大小；以及
将有关发送窗口大小的数据发送到服务器系统。
实施方案31.如实施方案30的介质，其中有关发送窗口大小的数据用于限制吞吐量，同时保持足够的吞吐量来呈现流媒体的当前再现，并且其中基于将所测量的往返时间与最小所需比特率相乘来确定发送窗口大小。
实施方案32.如实施方案31的介质，其中该方法还包括：
确定用于支持流媒体的当前再现的回放的最小比特率。
实施方案33.如实施方案32的介质，其中该最小比特率被选择为避免当前再现的回放的停顿。
实施方案34.如实施方案32的介质，其中发送窗口大小被确定为使得该连接可在所测量的往返时间内维持最小比特率。
实施方案35.如实施方案34的介质，其中该方法还包括：
监测该连接的往返时间(RTT)以检测RTT在一段时间内超过阈值的持续变化。
实施方案36.如实施方案35的介质，其中当RTT持续变化超过阈值时，数据处理系统确定新发送窗口大小并发送有关该新发送窗口大小的新数据。
实施方案37.如实施方案35的介质，其中对更新播放列表的请求和对由该更新播放列表中的统一资源标识符(URI)标识的媒体片段的请求通过该连接从数据处理系统发送，并且媒体片段由数据处理系统通过该连接接收。
实施方案38.如实施方案37的介质，其中对更新播放列表的请求还包括对该更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP 的请求的一部分。
实施方案39.如实施方案38的介质，其中数据处理系统尝试将延迟减小到针对流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与流媒体中的动作的呈现之间的时间差小于约3至6秒。
实施方案40.如实施方案30的介质，其中通过检查用于打开TCP连接的分组的定时数据或通过使用用于HTTP/2ping帧的定时数据来测量 RTT，来测量往返时间。
实施方案41.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法：
接收有关用于将流媒体发送到客户端设备的发送窗口大小的数据，在客户端设备测量了客户端设备和数据处理系统之间用于流媒体的连接的往返时间之后，客户端设备已基于计算的带宽时延积确定了发送窗口大小；以及
基于发送窗口大小来调节流媒体的符合HTTP的传输。
实施方案42.如实施方案41的介质，其中客户端设备确定发送窗口大小，使得该连接可维持客户端设备正在呈现的流媒体的当前再现所需的最小比特率。
实施方案43.如实施方案42的介质，其中该最小比特率被选择为避免当前再现的回放的停顿。
实施方案44.如实施方案42的介质，其中该方法还包括：
通过该连接来接收对更新播放列表的请求，以及通过该连接来接收对由该更新播放列表中的统一资源标识符(URI)标识的媒体片段的请求；
通过该连接来发送该更新播放列表；
通过该连接来发送媒体片段。
实施方案45.如实施方案44的介质，其中对更新播放列表的请求还包括对该更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP 的请求的一部分。
实施方案46.如实施方案45的介质，其中数据处理尝试限制向客户端设备的传输以限制该连接中的缓冲区拥塞，同时还尝试将延迟减小到针对客户端设备上的流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与客户端设备上的流媒体中的动作的呈现之间的时间差小于约6秒。
实施方案47.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
监测用于接收流媒体的第一再现的连接的带宽，该流媒体通过符合 HTTP的协议提供；
基于监测的带宽来确定是否切换到流媒体的第二再现；
响应于确定切换到第二再现，请求用于第二再现的第一播放列表；
在请求第一播放列表之后，请求第一再现的第一多个媒体片段；以及
请求第二再现的第二多个媒体片段。
实施方案48.如实施方案47的介质，其中对第一多个媒体片段的请求指定用于第一多个媒体片段的相对下载优先级的第一权重，并且其中对第二多个媒体片段的请求指定用于第二多个媒体片段的相对下载优先级的第二权重，并且其中第一权重和第二权重不同。
实施方案49.如实施方案48的介质，其中当第一再现具有比第二再现低的比特率时，第一权重大于第二权重，使得下载相对于第二再现更有利于第一再现。
实施方案50.如实施方案49的介质，其中该方法还包括：
一旦建立第二再现的回放，就停止对第一再现的媒体片段的请求；
其中当第二再现具有比第一再现低的比特率时，第二权重大于第一权重，使得下载相对于第一再现更有利于第二再现，并且在一段时间内，比第一再现的媒体片段更多的第二再现的媒体片段被下载。
实施方案51.如实施方案50的介质，其中该方法还包括：
请求有关一个或多个对应再现的一组一个或多个再现报告，并且这组再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入对应再现中的近直播点，并且这组再现报告包括以下一项或多项：(1)针对比特率比第一再现低的低比特率再现的再现报告，以及(2)针对比特率比第一再现高的高比特率再现的再现报告。
实施方案52.如实施方案51的介质，其中最近更新播放列表包括多个统一资源标识符(URI)，并且所述多个URI中的最后一个URI是相对于直播活动的近直播点，数据处理系统可跳过该直播活动以有利于快速调入，并且其中跳到最后一个URI避免下载在最后一个URI之前的媒体片段。
实施方案53.如实施方案47的介质，其中对更新播放列表的请求和对由该更新播放列表中的统一资源标识符(URI)标识的媒体片段的请求通过连接从数据处理系统发送，并且媒体片段由数据处理系统通过该连接接收，并且其中对更新播放列表的请求还包括的对该更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP的请求的一部分。
实施方案54.如实施方案53的介质，其中数据处理系统尝试将延迟减小到针对流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与数据处理系统上流媒体中的动作的呈现之间的时间差小于约3至6秒。
实施方案55.如实施方案54的介质，其中通过检查用于打开TCP连接的分组的定时数据或通过使用HTTP/2ping帧来测量RTT，来监测带宽。
实施方案56.如实施方案47的介质，其中该方法还包括：
检查播放列表注释，这些播放列表注释指定媒体片段是否包括独立帧，独立帧可在不使用任何先前帧的情况下被完整解码；
在第二再现中跳过基于播放列表注释而不包括独立帧的一个或多个媒体片段的下载；
开始下载第二再现中的媒体片段，其中一个媒体片段包括独立帧。
实施方案57.如实施方案47的介质，其中在用于获取由流媒体提供的直播流内容的调入阶段期间，重复地请求更新播放列表，直到确定播放列表更新表示近直播点而不是已由递送系统缓存的旧更新。
实施方案58.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
监测用于接收流媒体的第一再现的连接的带宽，该流媒体通过符合 HTTP的协议提供；
基于监测的带宽来确定是否切换到流媒体的第二再现；
请求有关一个或多个对应再现的一组一个或多个再现报告，其中这组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入对应再现中的近直播点，并且这组一个或多个再现报告包括以下一项或多项：(1)针对比特率比第一再现低的低比特率再现的再现报告，(2)针对比特率比第一再现高的高比特率再现的再现报告，或其组合；以及
响应于确定切换到第二再现，请求用于第二再现的第一播放列表。
实施方案59.如实施方案58的介质，其中最近更新播放列表包括多个统一资源标识符(URI)，并且其中所述多个URI中的最后一个URI是相对于直播活动的近直播点，数据处理系统可跳过该直播活动以有利于快速调入，并且其中跳到最后一个URI避免下载在最后一个URI之前的媒体片段。
实施方案60.如实施方案59的介质，其中对更新播放列表的请求和对由该更新播放列表中的URI标识的媒体片段的请求通过连接从数据处理系统发送，并且其中对更新播放列表中的请求还包括对该更新播放列表中的第一媒体片段的请求，该请求作为单个符合HTTP的请求的一部分。
实施方案61.如实施方案60的介质，其中数据处理系统尝试将延迟减小到针对流媒体中呈现的直播活动的低延迟，使得直播活动中的动作与数据处理系统上流媒体中的动作的呈现之间的时间差小于约3至6秒。
实施方案62.如实施方案58的介质，其中在单个符合HTTP的请求中请求第一播放列表，该单个符合HTTP的请求还基于所请求并接收到的接收再现报告中有关第二再现的数据来请求第二再现中的媒体片段。
实施方案63.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由数据处理系统执行时使得所述数据处理系统执行方法，所述方法包括：
监测用于接收流媒体的第一再现的连接的带宽，该流媒体通过符合 HTTP的协议提供；
基于监测的带宽来确定是否切换到流媒体的第二再现；
响应于确定切换到第二再现，请求用于第二再现的第一播放列表；
在第一播放列表中，检查一个或多个播放列表注释，这些播放列表注释指定媒体片段是否包括独立帧，独立帧可在不使用任何先前帧的情况下被解码为完整图像帧；
在第一播放列表中，跳过基于一个或多个播放列表注释而不包括独立帧的一个或多个媒体片段的下载；以及
开始下载第二再现中的媒体片段，其中一个媒体片段基于一个或多个播放列表注释而包括独立帧。
实施方案64.如实施方案63的介质，其中第一播放列表包括在没有前一个独立帧的情况下不能被解码为有效数据的从属帧。
实施方案65.如实施方案64的介质，其中独立帧是一种关键帧，该关键帧包含得出和解码关键帧中的编码图像的所有必要数据，并且在时间上在独立帧之后的从属帧使用关键帧中的数据来解码从属帧中的编码图像。
实施方案66.如实施方案65的介质，其中从属帧包括P帧和B帧，这两类帧包括相对于其所依赖的独立帧的差异数据。
实施方案67.如实施方案65的介质，其中该方法还包括：
请求有关一个或多个对应再现的一组一个或多个再现报告，其中这组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入对应再现中的近直播点，并且这组一个或多个再现报告包括以下一项或多项：(1)针对比特率比第一再现低的低比特率再现的再现报告，以及(2)针对比特率比第一再现高的高比特率再现的再现报告。
实施方案68.如实施方案67的介质，其中开始第二再现的下载的媒体片段是包含独立帧的最后一个媒体片段，但不是第一播放列表中的最后一个媒体片段。
实施方案69.一组一个或多个服务器系统，所述一组一个或多个服务器系统响应于对更新播放列表的符合HTTP的请求而提供所述更新播放列表，所述更新播放列表包括如实施方案63至68中的播放列表注释。
实施方案70.一组一个或多个服务器系统，所述一组一个或多个服务器系统提供如实施例方案58至62中的一个或多个再现报告。
在上述说明书中，已描述特定示例性实施方案。显而易见的是，可在不脱离以下权利要求所给出的更广泛的实质和范围的情况下对那些实施方案作出各种修改。相应地，说明书和附图被视为是例示性意义而不是限定性意义。
为了帮助专利局和本申请中发布的任何专利的任何读者解译所附权利要求书，申请人希望提请注意，他们并不意欲让所附权利要求书中的任一个或权利要求要素援引35U.S.C.112(f)，除非在特定权利要求中明确使用字词“用于......的装置”或“用于......的步骤”。

Claims (19)

1.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由客户端设备执行时使得所述客户端设备执行方法，所述方法包括：
监测用于接收流媒体的第一再现的连接的带宽，所述流媒体通过符合HTTP的协议提供；
基于监测的带宽来确定是否切换到所述流媒体的第二再现；
响应于确定切换到所述第二再现，请求用于所述第二再现的第一播放列表；
在所述第一播放列表中，检查一个或多个播放列表注释，所述播放列表注释指定媒体片段是否包括能够在不使用任何先前帧的情况下被解码为完整图像帧的任何独立帧；
基于所述一个或多个播放列表注释，确定用于从所述第一再现切换到所述第二再现的媒体片段的独立帧存在于所述第一播放列表中；以及
基于所确定的独立帧选择性地下载所述第一播放列表中的媒体片段，包括：
跳过在所述第一播放列表中的所确定的独立帧之前的、不包括任何独立帧的一个或多个媒体片段的下载；以及
以所确定的独立帧开始下载所述第一播放列表中的媒体片段。
2.根据权利要求1所述的介质，其中所述第一播放列表包括在没有前一个独立帧的情况下不能被解码为有效数据的一个或多个从属帧。
3.根据权利要求2所述的介质，其中所述独立帧是一种关键帧，其包含得出和解码所述关键帧中的编码图像的所有必要数据，并且在时间上在所述独立帧之后的从属帧使用所述关键帧中的数据来解码所述从属帧中的编码图像。
4.根据权利要求3所述的介质，其中从属帧包括P帧和B帧，所述P帧和B帧包括相对于其所依赖的所述独立帧的差异数据。
5.根据权利要求3所述的介质，其中所述方法还包括：
请求有关一个或多个对应再现的一组一个或多个再现报告，其中所述一组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入所述对应再现中的近直播点，并且所述一组一个或多个再现报告包括以下一项或多项：(1)针对比特率比所述第一再现低的低比特率再现的再现报告，以及(2)针对比特率比所述第一再现高的高比特率再现的再现报告。
6.根据权利要求5所述的介质，其中包括所确定的独立帧的第一媒体片段是包含独立帧的最后一个媒体片段，但不是所述第一播放列表中的最后一个媒体片段。
7.一种由客户端设备执行的机器实现的方法，所述方法包括：
监测用于接收流媒体的第一再现的连接的带宽，所述流媒体通过符合HTTP的协议提供；
基于监测的带宽来确定是否切换到所述流媒体的第二再现；
响应于确定切换到所述第二再现，请求用于所述第二再现的第一播放列表；
在所述第一播放列表中，检查一个或多个播放列表注释，所述播放列表注释指定媒体片段是否包括能够在不使用任何先前帧的情况下被解码为完整图像帧的任何独立帧；
基于所述一个或多个播放列表注释，确定用于从所述第一再现切换到所述第二再现的媒体片段的独立帧存在于所述第一播放列表中；以及
基于所确定的独立帧选择性地下载所述第一播放列表中的媒体片段，包括：
跳过在所述第一播放列表中的所确定的独立帧之前的、不包括任何独立帧的一个或多个媒体片段的下载；以及
以所确定的独立帧开始下载所述第一播放列表中的媒体片段。
8.根据权利要求7所述的方法，其中所述第一播放列表包括在没有前一个独立帧的情况下不能被解码为有效数据的一个或多个从属帧。
9.根据权利要求8所述的方法，其中所述独立帧是一种关键帧，其包含得出和解码所述关键帧中的编码图像的所有必要数据，并且在时间上在所述独立帧之后的从属帧使用所述关键帧中的数据来解码所述从属帧中的编码图像。
10.根据权利要求9所述的方法，其中从属帧包括P帧和B帧，所述P帧和B帧包括相对于其所依赖的所述独立帧的差异数据。
11.根据权利要求9所述的方法，其中所述方法还包括：
请求有关一个或多个对应再现的一组一个或多个再现报告，其中所述一组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入所述对应再现中的近直播点，并且所述一组一个或多个再现报告包括以下一项或多项：(1)针对比特率比所述第一再现低的低比特率再现的再现报告，以及(2)针对比特率比所述第一再现高的高比特率再现的再现报告。
12.根据权利要求11所述的方法，其中包括所确定的独立帧的第一媒体片段是包含所述独立帧的最后一个媒体片段，但不是所述第一播放列表中的最后一个媒体片段。
13.一种存储可执行程序指令的非暂态机器可读介质，所述可执行程序指令当由一个或多个服务器执行时使得所述一个或多个服务器执行方法，所述方法包括：
为通过符合HTTP的协议提供的流媒体内容的多个再现生成多个更新播放列表，所述多个更新播放列表中的每个更新播放列表包括一组一个或多个播放列表注释，所述播放列表注释指定媒体片段是否包括能够在不使用任何先前帧的情况下被解码为完整图像帧的任何独立帧，所述一组一个或多个播放列表注释允许一个或多个客户端设备：
在从所述多个再现中的第一再现切换到第二再现时，
确定用于从所述第一再现切换到所述第二再现的媒体片段的独立帧存在于所述多个更新播放列表中的用于所述第二再现的更新播放列表中，以及
基于所确定的独立帧选择性地下载用于所述第二再现的更新播放列表中的媒体片段，包括：在以所确定的独立帧开始下载用于所述第二再现的更新播放列表中的媒体片段之前跳过从属帧的下载；
响应于对所述多个更新播放列表中的更新播放列表的一个或多个请求，发送所述多个更新播放列表。
14.根据权利要求13所述的介质，其中所述一个或多个请求来自一个或多个缓存服务器或所述一个或多个客户端设备。
15.根据权利要求13所述的介质，其中所述多个更新播放列表中的每个更新播放列表包括在没有前一个独立帧的情况下不能被解码为有效数据的一个或多个从属帧。
16.根据权利要求15所述的介质，其中所述独立帧是一种关键帧，其包含得出和解码所述关键帧中的编码图像的所有必要数据，并且在时间上在所述独立帧之后的从属帧使用所述关键帧中的数据来解码所述从属帧中的编码图像。
17.根据权利要求16所述的介质，其中从属帧包括P帧和B帧，所述P帧和B帧包括相对于其所依赖的所述独立帧的差异数据。
18.根据权利要求13所述的介质，其中所述方法还包括：
请求有关一个或多个对应再现的一组一个或多个再现报告，其中所述一组一个或多个再现报告中的每个再现报告提供有关用于对应再现的最近更新播放列表的数据，以有利于快速调入所述对应再现中的近直播点，并且所述一组一个或多个再现报告包括以下一项或多项：(1)针对比特率比所述第一再现低的低比特率再现的再现报告，以及(2)针对比特率比所述第一再现高的高比特率再现的再现报告。
19.根据权利要求18所述的介质，其中包括用于切换到所述第二再现的所确定的独立帧的第一媒体片段是用于所述第二再现的更新播放列表中包含独立帧的最后一个媒体片段，但不是用于所述第二再现的更新播放列表中的最后一个媒体片段。
CN202010100779.XA 2019-02-19 2020-02-19 一种由客户端设备执行的机器实现的方法以及可读介质 Active CN111586479B (zh)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962807329P 2019-02-19 2019-02-19
US62/807,329 2019-02-19
US201962810075P 2019-02-25 2019-02-25
US62/810,075 2019-02-25
US16/776,824 US11757965B2 (en) 2019-02-19 2020-01-30 Low latency streaming media
US16/776,824 2020-01-30

Publications (2)

Publication Number Publication Date
CN111586479A CN111586479A (zh) 2020-08-25
CN111586479B true CN111586479B (zh) 2022-11-29

Family

ID=72040697

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202010100780.2A Active CN111586480B (zh) 2019-02-19 2020-02-19 低延迟流媒体
CN202010100779.XA Active CN111586479B (zh) 2019-02-19 2020-02-19 一种由客户端设备执行的机器实现的方法以及可读介质

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202010100780.2A Active CN111586480B (zh) 2019-02-19 2020-02-19 低延迟流媒体

Country Status (2)

Country Link
US (2) US11757965B2 (zh)
CN (2) CN111586480B (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11757965B2 (en) 2019-02-19 2023-09-12 Apple Inc. Low latency streaming media
US11792454B2 (en) * 2019-04-01 2023-10-17 World Multicast, Inc. Method using adaptive-bit-rate playlists for dynamic server capacity and broadband handovers
US11265586B2 (en) * 2019-05-06 2022-03-01 Apple Inc. Skipping segments in playlists
US11593281B2 (en) * 2019-05-08 2023-02-28 Hewlett Packard Enterprise Development Lp Device supporting ordered and unordered transaction classes
US11301232B2 (en) * 2019-05-29 2022-04-12 Microsoft Technology Licensing, Llc Update management service for enterprise computing environments
KR20210057354A (ko) * 2019-11-12 2021-05-21 삼성전자주식회사 전자 장치 및 그 제어 방법
US11089379B2 (en) 2019-12-11 2021-08-10 Apple Inc. Preload hinting for low latency HTTP live streaming system
US11228536B2 (en) * 2020-01-15 2022-01-18 Qualcomm Incorporated Usage of QUIC spin bit in wireless networks
CN111225230B (zh) * 2020-02-20 2022-10-04 腾讯科技（深圳）有限公司 一种网络直播数据的管理方法以及相关装置
US20210385513A1 (en) * 2020-06-04 2021-12-09 Comcast Cable Communications, Llc Distributed storage of content across storage subsystems
US11956482B2 (en) * 2020-07-16 2024-04-09 Comcast Cable Communications, Llc Systems and methods for storing and delivering content assets
US11700436B2 (en) * 2021-05-05 2023-07-11 Sonos, Inc. Content playback reminders
CN113630657A (zh) * 2021-08-03 2021-11-09 广东九联科技股份有限公司 基于hls协议的视频播放优化方法及系统
CN113726778A (zh) * 2021-08-30 2021-11-30 咪咕视讯科技有限公司 流媒体seek方法、装置、计算设备及计算机存储介质
US11631252B1 (en) * 2022-01-03 2023-04-18 Brian Lawrence Repper Visual media management for mobile devices

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6868440B1 (en) * 2000-02-04 2005-03-15 Microsoft Corporation Multi-level skimming of multimedia content using playlists
US20080036917A1 (en) * 2006-04-07 2008-02-14 Mark Pascarella Methods and systems for generating and delivering navigatable composite videos
WO2009075766A2 (en) * 2007-12-05 2009-06-18 Swarmcast, Inc. Dynamic bit rate scaling
US8156089B2 (en) 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
CA2748548C (en) 2008-12-31 2015-02-24 Apple Inc. Real-time or near real-time streaming
US20100169458A1 (en) 2008-12-31 2010-07-01 David Biderman Real-Time or Near Real-Time Streaming
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
GB201105502D0 (en) * 2010-04-01 2011-05-18 Apple Inc Real time or near real time streaming
WO2011123821A1 (en) 2010-04-01 2011-10-06 Apple Inc. Real-time or near real-time streaming
US9319448B2 (en) * 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US8861929B2 (en) 2011-04-14 2014-10-14 Cisco Technology, Inc. Per-subscriber adaptive bit rate stream management method
US9026670B2 (en) 2011-08-22 2015-05-05 Allot Communications Ltd. System and method for efficient caching and delivery of adaptive bitrate streaming
US9374406B2 (en) * 2012-02-27 2016-06-21 Qualcomm Incorporated Dash client and receiver with a download rate estimator
US9813740B2 (en) * 2012-08-24 2017-11-07 Google Inc. Method and apparatus for streaming multimedia data with access point positioning information
US9537917B2 (en) 2012-11-20 2017-01-03 Google Technology Holdings LLC Method and apparatus for streaming media content to client devices
US9300710B2 (en) 2013-03-07 2016-03-29 Qualcomm Innovation Center, Inc. Adaptive bandwidth switching via short-circuitable download
US9124947B2 (en) * 2013-09-04 2015-09-01 Arris Enterprises, Inc. Averting ad skipping in adaptive bit rate systems
US10432982B2 (en) * 2014-10-22 2019-10-01 Arris Enterprises Llc Adaptive bitrate streaming latency reduction
EP3210383A1 (en) 2014-10-22 2017-08-30 ARRIS Enterprises LLC Adaptive bitrate streaming latency reduction
US10749918B2 (en) * 2014-11-10 2020-08-18 Avago Technologies International Sales Pte. Limited Adaptive streaming with early client indication
US10804958B2 (en) * 2015-02-24 2020-10-13 Comcast Cable Communications, Llc Multi-bitrate video with dynamic blocks
US9742870B2 (en) * 2015-06-19 2017-08-22 Arris Enterprises Llc Selective download of alternate media files
NL2016051B1 (en) 2015-12-30 2017-07-12 Rollin Video Tech B V Live-stream video advertisement system
US10931727B2 (en) * 2016-03-30 2021-02-23 Arris Enterprises Llc Transparent intercept for adaptive bitrate splicer
US10820063B2 (en) * 2016-06-10 2020-10-27 Arris Enterprises Llc Manifest customization in adaptive bitrate streaming
US10397620B2 (en) * 2016-06-30 2019-08-27 SnifferCat, Inc. Systems and methods for dynamic stitching of advertisements in live stream content
US10567461B2 (en) 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming
CN109792545B (zh) 2016-09-30 2021-12-07 英国电讯有限公司 从服务器向客户端装置传送视频内容的方法
US11627350B2 (en) * 2016-12-30 2023-04-11 Tivo Solutions Inc. Advanced trick-play modes for streaming video
WO2018213481A1 (en) * 2017-05-16 2018-11-22 Sportscastr.Live Llc Systems, apparatus, and methods for scalable low-latency viewing of integrated broadcast commentary and event video streams of live events, and synchronization of event information with viewed streams via multiple internet channels
US10742699B1 (en) * 2017-09-29 2020-08-11 Twitch Interactive, Inc. Requesting transmission of future encoded segments
US10659512B1 (en) 2017-12-05 2020-05-19 Amazon Technologies, Inc. Optimizing adaptive bit rate streaming at edge locations
EP3515075A1 (en) * 2018-01-23 2019-07-24 THEO Technologies Video streaming
US11757965B2 (en) 2019-02-19 2023-09-12 Apple Inc. Low latency streaming media

Also Published As

Publication number Publication date
US11757965B2 (en) 2023-09-12
US20200267437A1 (en) 2020-08-20
US11240280B2 (en) 2022-02-01
CN111586480A (zh) 2020-08-25
CN111586480B (zh) 2022-06-03
US20200267198A1 (en) 2020-08-20
CN111586479A (zh) 2020-08-25

Similar Documents

Publication Publication Date Title
CN111586479B (zh) 一种由客户端设备执行的机器实现的方法以及可读介质
US9558282B2 (en) Playlists for real-time or near real-time streaming
JP5894220B2 (ja) プログレッシブ再生を含む映像分配システム
US8683071B2 (en) Method and apparatus for supporting time shift playback in adaptive HTTP streaming transmission solution
AU2009335146B2 (en) Method for streaming multimedia data over a non-streaming protocol
KR101702562B1 (ko) 멀티미디어 스트림 파일의 저장 파일 포맷, 저장 방법 및 이를 이용한 클라이언트 장치
EP3822805B1 (en) Apparatus, system, and method for adaptive-rate shifting of streaming content
KR101716071B1 (ko) 적응적 스트리밍 기법
US8639832B2 (en) Variant streams for real-time or near real-time streaming to provide failover protection
US20160028646A1 (en) Push-based transmission of resources and correlated network quality estimation
US20150271231A1 (en) Transport accelerator implementing enhanced signaling
US20150271242A1 (en) Method and Apparatus for Acquiring Streaming Media Buffer Parameter
US9356985B2 (en) Streaming video to cellular phones
US20150095447A1 (en) Serving method of cache server, cache server, and system
JP2005086362A (ja) データ多重化方法、データ送信方法およびデータ受信方法
CN115039413A (zh) 用于基于递送的内容流来提供内容流的技术
JP2021153270A (ja) ユーザ端末及びプログラム
AU2013202695B2 (en) Real-time or near real-time streaming
AU2011203178B2 (en) Real-time or near real-time streaming
KR101525390B1 (ko) 파일재생 탐색요청에서의 세션과 전송 분배장치 및 그 제어 방법
AU2013201691B2 (en) Method for streaming multimedia data over a non-streaming protocol

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant