CN114760281A - 对于部分段的指示 - Google Patents

对于部分段的指示 Download PDF

Info

Publication number
CN114760281A
CN114760281A CN202210441193.9A CN202210441193A CN114760281A CN 114760281 A CN114760281 A CN 114760281A CN 202210441193 A CN202210441193 A CN 202210441193A CN 114760281 A CN114760281 A CN 114760281A
Authority
CN
China
Prior art keywords
segment
server
dash
client
incomplete
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.)
Pending
Application number
CN202210441193.9A
Other languages
English (en)
Inventor
O·卢特法拉
C·M·D·帕索斯
C·N·洛
N·奈克
T·施托克哈默
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.)
Qualcomm Inc
Original Assignee
Qualcomm 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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of CN114760281A publication Critical patent/CN114760281A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Digital Computer Display Output (AREA)

Abstract

用于对于部分段的指示的方法和装置。各个实施例的系统、方法和设备使诸如根据各个实施例向DASH客户端提供段的HTTP服务器之类的HTTP服务器能够响应于来自DASH客户端的段请求递送段的不完整版本。各个实施例可以使诸如DASH客户端的客户端能够解析段的不完整版本。

Description

对于部分段的指示
本申请是申请日为2016年2月29日，申请号为201680013091.X(PCT/US2016/020092)，发明名称为“对于部分段的指示”的中国专利申请的分案申请。
相关申请
本申请要求于2015年3月2日提交的题为“Indication for Partial Segment”的美国临时专利申请No.62/126,842的优先权以及于2015年8月13日提交的题为“Indicationfor Partial Segment”的美国临时专利申请No.62/204,505。这两个申请的全部内容通过引用并入本文。
背景技术
在诸如在被称为段的单个文件中发送的视频分段或片段之类的数字文件的网络传输期间，可以发生各种事件或错误(例如，调离、无线电信道错误等)，这导致仅接收到部分文件。例如，当前的在计算设备上的演进多媒体广播多播服务(eMBMS)中间件可以仅接收部分的动态自适应流超文本传输协议(DASH)段而不是整个段。在某些情况下，可以使得向编解码器提供输入的应用和/或客户端(诸如，DASH客户端)能够将文件中的某个部分恢复并提供给编解码器，即使该文件可能尚未被应用和/或客户端完全接收也是如此。由于当前的应用和/或客户端(例如，当前的DASH客户端)没有用于指示当前的应用和/或客户端接收部分段的能力的机制，所以部分段可能不会被提供给应用和/或客户端。例如，当前的在计算设备上的eMBMS中间件可能丢弃部分段，这可能会增加播放中断。
发明内容
各个实施例的系统、方法和设备使得诸如根据各个实施例向DASH客户端提供段的超文本传输协议(HTTP)服务器的HTTP服务器能够响应于来自DASH客户端的段请求传递段的不完整版本。各个实施例可以使得诸如DASH客户端的客户端能够解析段的不完整版本。
一些实施例可以包括：在服务器中从客户端接收段请求，其中，所述段请求指示所述客户端是否能够使用不完整的段。所述服务器可以确定与所述段请求相关联的完全的段是否在所述服务器处是可用的。响应于确定与所述段请求相关联的所述完全的段在所述服务器处是不可用的，所述服务器可以基于所述段请求来确定所述客户端是否能够使用不完整的段。响应于确定所述客户端能够使用不完整的段，所述服务器可以从所述服务器向所述客户端在响应消息中发送不完整的段，所述响应消息包括关于所述响应消息包括所述不完整的段的指示、以及对针对所述不完整的段的一个或多个访问位置的指示。
一些实施例可以包括：从服务器向客户端发送消息，所述消息包括媒体文件的不完整版本、以及扩展报头，所述扩展报头指示针对所述媒体文件的所述不完整版本的一个或多个访问位置。
另外的实施例包括具有处理器的服务器，所述处理器配置有处理器可执行指令以执行在上概述的方法的操作的服务器。另外的实施例包括：服务器，其包括用于执行在上概述的方法的功能的单元。另外的实施例包括其上存储有处理器可执行指令的非暂时性处理器可读存储介质，所述处理器可执行指令被配置为使服务器处理器执行在上概述的方法的操作。
附图说明
并入本文并且构成本说明书的一部分的附图示出了本发明的示例性实施例，并且与上面给出的概括描述和下面给出的具体实施方式一起用于解释本发明的特征。
图1是适用于各个实施例的网络的通信系统框图。
图2A是示出根据各个实施例的计算设备中的传输层与应用和/或客户端层之间的关系的系统框图。
图2B是示出根据各个实施例的网络元件和计算设备应用和/或客户端层之间的关系的系统框图。
图3是示出供HTTP服务器处理针对段的不完整版本的客户端请求的现有技术方法的处理过程流程图。
图4是示出供DASH服务器处理针对段的不完整版本的DASH客户端请求的实施例方法的处理过程流程图。
图5是示出供DASH服务器处理针对段的不完整版本的DASH客户端请求的另一实施例方法的处理过程流程图。
图6是示出供DASH服务器处理针对段的不完整版本的DASH客户端请求的第三实施例方法的处理过程流程图。
图7和图8是示出根据各个实施例的DASH客户端和DASH服务器之间的交互的呼叫流程图。
图9是示出供DASH服务器处理针对段的不完整版本的DASH客户端请求的第四实施例方法的处理过程流程图。
图10和图11是示出根据各个实施例的DASH客户端和DASH服务器之间的交互的呼叫流程图。
图12是示出供DASH服务器处理针对段的不完整版本的DASH客户端请求的第五实施例方法的处理过程流程图。
图13是示出根据各个实施例的DASH客户端和DASH服务器之间的交互的呼叫流程图。
图14是媒体流中的段的数据框图。
图15是示出供DASH客户端处理段的不完整版本的实施例方法的处理过程流程图。
图16是适用于各个实施例的示例计算设备的组件图。
图17是适用于各个实施例的示例服务器的组件图。
具体实施方式
将参照附图详细描述各个实施例。尽可能地，在所有附图中将使用相同的附图标记来指代相同或相似的部分。对具体示例和实现方式的引用是为了说明的目的，并不意图限制本发明或权利要求书的范围。
各个实施例使得诸如DASH服务器之类的HTTP服务器能够根据各个实施例向DASH客户端提供DASH媒体文件中的段，以响应于来自诸如DASH客户端的客户端的段请求来传递段的不完整版本。
如本文所使用地，术语“移动设备”、“接收机设备”和“计算设备”在本文中可互换使用以指以下各项中的任何一项或全部：蜂窝电话、智能电话、个人或移动多媒体播放器、个人数据助理(PDA)、笔记本电脑、个人计算机、平板电脑、智能书籍、掌上电脑、无线电子邮件接收机、支持多媒体互联网的蜂窝电话、无线游戏控制器、卫星或有线机顶盒、流媒体播放器(诸如，ROKUTM或CHROMECASTTM或FIRE TVTM)、智能电视机、数字录像机(DVR)以及类似的个人电子设备(其包括可编程处理器和存储器以及用于接收文件的电路)。
在本文使用术语“服务器”来描述各个实施例以指能够用作服务器的任何计算设备，诸如，主交换服务器、web服务器、邮件服务器、文档服务器、内容服务器或任何其它类型的服务器。服务器可以是专用计算设备或计算设备，包括服务器模块(例如，其运行可能导致计算设备作为服务器工作的应用)。服务器模块(例如，服务器应用)可以是全功能服务器模块、或被配置为在接收机设备上的动态数据库当中提供同步服务的轻型或辅助服务器模块(例如，轻型或辅助服务器应用)。轻型服务器或辅助服务器可以是可以在接收机设备上实现的精简版本的服务器类型功能，从而使其能够仅在为提供本文所描述的功能而必需时才用作因特网服务器(例如，企业电子邮件服务器)。
如本文所使用地，术语“段的不完整版本”用于指具有丢失和/或损坏的数据部分的不完整版本的文件。例如，如果段包含由0-999索引的1,000个字节，则该段中的字节0-888是该段的不完整版本，且字节500-999是该段的另一个不完整版本，且字节0-200连同字节300-999是该段的另一个不完整版本，而字节0-999不是该段的不完整版本。
在互联网工程任务组提出的于1999年6月发布的题为“超文本传输协议-HTTP/1.1”的标准请求注解(RFC)2616(其可从http://tools.ietf.org/html/rfc2616处获得)中定义的当前的超文本传输协议(HTTP)1.1中，没有机制供服务器用于响应于文件请求而向客户端提供文件的不完整版本(例如，具有丢失/损坏的数据部分的文件)。在当前的HTTP协议中，客户端可以生成诸如“GET(得到)”方法的文件请求，并将文件请求发送给服务器。文件请求可以是针对与URL/URI相关联的文件的请求，并且可以是针对与URL/URI相关联的文件的整个数据内容的请求(例如，使用不指定任何字节范围并因此请求完整的文件的GET请求)，或者可以是针对与URL/URI相关联的文件的特定字节范围的请求(例如，使用指定完整的文件中的字节范围的部分GET请求)。
在当前的HTTP协议中，服务器可以响应于客户端的文件请求而提供“完全响应”或错误消息。响应于HTTP客户端文件请求，HTTP服务器将不提供文件的不完整版本。对于请求完整的文件的GET请求，来自HTTP服务器的完全响应是完整的文件，并且文件响应的不完整版本是比完整的文件小的文件(例如，文件的不完整版本)。对于指定字节范围的部分GET请求，来自HTTP服务器的完全响应是完整的文件与经请求的字节范围之间的交集，且字节范围响应的不完整版本是比完整的文件和经请求的字节范围之间的交集小的文件(例如，字节范围的不完整版本)。
特别地，在当前的HTTP协议中，当服务器接收到文件请求时，服务器可以确定与文件请求对应的文件是否完全可用。作为示例，服务器可以确定与文件请求相对应的文件是否是不完整的和/或损坏的，诸如丢失数据部分和/或包括关于文件是不完整的和/或损坏的的指示。作为示例，服务器可以通过确定FEC解码是成功还是不成功来确定与文件请求对应的文件是否是不完整的和/或损坏的。作为另一示例，服务器可以通过检测诸如MD5摘要之类的接收到的校验和的值与由FLUTE接收机计算的校验和的差别，来确定与文件请求对应的文件是否是不完整的和/或损坏的。那些不完整的和/或损坏的文件可以由服务器确定为完全可用的，并且可以在包括所请求的文件的“完全响应”中发送给客户端。在当前的HTTP协议中，在识别所请求的文件是不完全可用的时(即，仅具有丢失/损坏的数据部分的文件的不完整版本是可用的时)，服务器返回带有错误状态码的消息，诸如具有404“NotFound”(“未找到”)状态码的消息。因此，在当前的HTTP协议中，文件的不完整版本不被发送给进行请求的客户端；也就是说，对针对文件的请求的“不完全响应”不被支持。
如上所述，当前的HTTP协议还提供了指定了所请求文件的字节范围的部分GET请求，并且对部分GET请求的完全响应是完整的文件与所请求的字节范围之间的交集。例如，在的当前HTTP中，当HTTP客户端发送针对延伸到完整的文件末尾之外的字节范围的部分GET请求时，HTTP服务器可以提供的完全响应是从所请求的字节范围中的第一字节到完整的文件中的最后一个字节的顺序字节部分。因此，在所请求的字节范围为0-100而完整的文件仅具有字节0-88的示例中，完全响应虽然小于所请求的字节范围(特别而言，字节0-88)，但是仍被认为是“完全响应”并可以由HTTP服务器发送。
然而，在当前的HTTP协议中，当HTTP客户端发送部分GET请求并且所指定的字节范围内的某些字节丢失/损坏(即，仅所请求的字节范围的不完整版本在HTTP服务器上可用)时，HTTP服务器可以不向客户端提供所请求的字节中的任何部分，而是向客户端发送带有错误状态码的消息。因此，在所请求的字节范围为0-99、而因字节75-125丢失或损坏而仅字节0-74和126-150可用的示例中，当前的HTTP服务器将不向进行请求的客户端发送由字节0-74组成的字节范围响应的不完整版本。因此，在当前的HTTP协议中，字节范围请求的不完整版本不被发送给进行请求的客户端。这是因为不支持对针对文件的字节范围的请求的“不完整响应”。
由于如当前定义的HTTP协议不向客户端传递不完整响应，所以可以减少被使得能够恢复和使用不完整响应的客户端和/或应用的功能，这是因为客户端和/或应用可能永远不会接收到不完整响应。因此，使得HTTP服务器能够向客户端递送在服务器处可用的文件的不完整版本或文件的字节范围的不完整版本中的至少一部分可以是有用的。文件或字节范围的不完整版本中的至少一部分的递送可以使得运行应用和/或客户端的客户端设备(例如，作为运行DASH客户端的智能电话)能够呈现内容，诸如以段的不完整版本或段的字节范围来播放媒体中的至少一部分，这可以改善终端用户媒体播放体验。
各个实施例通过如下来解决当前的HTTP协议中的这个缺点：使得诸如向DASH客户端提供段的DASH服务器的HTTP服务器能够响应于来自DASH客户端的段请求来传递段的不完整版本。在一个实施例中，DASH客户端可以生成包括段的不完整版本能力指示(anincomplete version of a segment capable indication)在内的段请求。这样的段请求可以是诸如“GET”操作(即，方法)的请求消息，包括指示客户端能够使用段的不完整版本(例如，不完整的段)的报头字段。在一个实施例中，报头字段可以是在RFC 7231中描述的accept报头字段。例如，具有accept报头字段指示“application/3gpp-partial”(“应用/3gpp-部分”)的GET操作可以指示DASH客户端将接受响应于段请求的部分段。在一个实施例中，报头字段可以是在RFC 7240中描述的prefer报头字段。例如，具有prefer报头字段指示“return＝3gpp-partial”(“返回＝3gpp-部分”)的GET操作可以指示DASH客户端将接受响应于段请求的部分段。在一个实施例中，可以在针对段的初始请求中发送具有指示客户端能够使用段的不完整版本的报头字段的段请求。在另一个实施例中，可以响应于从服务器返回的诸如包括状态码404“Not Found”的错误消息之类的初始错误消息，来发送具有指示客户端能够使用段的不完整版本的报头字段的段请求。响应于接收到初始错误消息，客户端可以重新请求先前请求的段，这次包括指示客户端能够使用段的不完整版本的报头字段。在另一个实施例中，可以响应于从服务器返回的字节范围指示，发送具有指示客户端能够使用段的不完整版本的报头字段的段请求，该字节范围指示包括段中的重要部分，该重要部分使得能够定位媒体样本(诸如ISOBMFF中的“trun”框)。响应于接收到初始字节范围指示，客户端可以请求段中的后续字节范围部分，这次包括指示客户端能够使用段的不完整版本的报头字段。
在一个实施例中，DASH服务器可以生成并发送初始响应消息，该初始响应消息包括关于所请求段的不完整版本是可用的以及关于该段的可用的字节范围的指示。在一个实施例中，响应消息可以是包括扩展报头的消息，所述扩展报头指示所请求的段的不完整版本是可用的以及字节范围是可用的。例如，初始响应可以是包括状态码404和扩展报头“X-Available-Ranges：bytes a-b、c-d、...(X-可用的-范围：字节a-b、c-d、...)”的错误消息。作为另一示例，初始响应可以是部分内容消息，其包括状态码206和扩展报头“X-Available-Ranges：bytes a-b、c-d、...”。在一个实施例中，响应消息可以是诸如300系列消息的重引导消息，包括指示所请求的段的不完整版本是可用的以及可用的字节范围的实体主体，诸如“Content-Type＝3gpp-partial-byte-ranges(内容-类型＝3GPP-局部字节范围)”。
响应于从DASH服务器接收到包括关于所请求的段的不完整版本是可用的以及段的可用的字节范围的指示的初始响应消息，DASH客户端可以重新请求先前请求的段，这次包括对与如由DASH服务器指示为可用的部分对应的部分字节范围请求的指示。
在一个实施例中，DASH服务器可以生成并给能够使用文件的不完整版本的DASH客户端发送包括访问位置指示的响应消息。访问位置指示可以是对所请求的文件中的字节(或其它数据大小)位置的指示，在该位置处，DASH客户端可以访问文件的不完整版本，并开始解析文件的不完整版本以识别可以用于解码和/或呈现文件的不完整版本的随机访问点(例如，流访问点(SAP)类型1或2)或同步样本。可以在每个文件的基础上和/或在每个可用的字节范围的基础上确定和指示访问位置指示。对于DASH段，例如，可以确定一个或多个访问位置，并将该一个或多个访问位置诸如在对DASH媒体流中的段进行描述的文件传送表(FDT)中与DASH段相关联。例如，可以在FDT中在字段“IndependentUnitPositions”(“独立单元位置”)中指示访问点，该字段“IndependentUnitPositions”指示DASH段中的DASH客户端可以在其处访问该段的以空格隔开的一个或多个字节位置。
例如，响应于从DASH客户端接收针对DASH段的不完整版本的请求，DASH服务器可以以DASH段的不完整版本发送对针对DASH段的一个或多个访问位置的指示。作为另一示例，当文件的不完整版本在DASH服务器处是可用的时，DASH服务器可以确定针对文件的可用的每个字节范围的一个或多个访问位置。以这种方式，DASH服务器可以指示针对DASH段的不完整版本的第一字节范围(例如，字节范围a-b)的一个或多个访问位置，以及用于第二字节范围的一个或多个访问位置(例如，字节范围c-d)的DASH段的不完整版本。
在各个实施例中，可以在由DASH服务器发送的响应消息中的扩展报头中指示访问位置。响应消息可以指示响应包括所请求的DASH段的不完整版本，并且指示针对不完整版本的访问位置。例如，响应可以包括指示DASH段中的DASH客户端可以在其处访问该段的一个或多个字节位置的扩展报头字段“3gpp-access-position”(“3gpp-访问-位置”)、以及作为Content-Type来包括“application/3gpp-partial”(“应用/3gpp-部分”)以指示响应的包括所请求的DASH段的不完整版本。
在一个实施例中，响应于接收到包括段的不完整版本和访问位置指示的响应，DASH客户端可以确定是否接收到段中的初始部分。段中的初始部分可以是专用于指示针对段的初始化、加索引、定时和/或同步信息的位于段的开始处的字节范围。响应于确定接收到段中的初始部分，DASH客户端可以使用初始部分中的定时和/或同步信息来解析段的不完整版本中的其它接收部分。响应于确定没有接收到段中的初始部分，DASH客户端可以确定是否接收到与访问位置对应的字节。响应于确定接收到对应于针对段的访问位置的字节，DASH客户端可以开始解析访问位置处的段的不完整版本，以识别可以用于解码和/或呈现段的不完整版本的随机访问点(例如，流访问点(SAP)类型1或2)或同步样本。响应于确定与针对段的访问位置对应的字节未被接收，DASH客户端可以请求表示(representation)中的下一段。
在一个实施例中，DASH服务器可以响应于能够使用文件的不完整版本的DASH客户端请求在DASH服务器处其字节都不可用的文件，来生成并发送错误消息。例如，当DASH服务器处经请求的DASH段中的字节都不可用或DASH段的字节范围都不可用时，DASH服务器可以发送包括状态码416“经请求的范围不可满足”的错误消息。错误消息可以进一步指示在针对DASH段的FDT实例中提供的内容类型、在针对DASH段的FDT中提供的内容位置以及基于在针对DASH段的FDT中指示的内容长度的如“bytes*/content-length”(“字节*/内容-长度”)指示的内容范围。通过接收包括状态码416“经请求的范围不可满足”的错误消息，DASH客户端可以区分针对无效段的请求(例如，导致具有状态码404“Not Found”的错误消息的请求)与针对在传输中丢失了的段(例如，在FDT中指示的段，但这些段不具有导致具有状态码416“经请求的范围不可满足”的错误消息的接收到的字节)的请求。在一个实施例中，DASH客户端可以隐藏由具有状态码416的错误消息指示的传输段的丢失，并通过请求该表示中的下一段来继续正常操作。
在本文讨论了不同应用/客户端、中间件、段可用性时间线、无线电技术和传输协议的各种示例，具体地说是DASH客户端、eMBMS和HTTP。对DASH客户端、eMBMS和HTTP的讨论仅作为示例来更好地说明各个实施例的各方面，并不旨在以任何方式限制各个实施例。其它应用/客户端、中间件、无线电技术和传输协议可以与各个实施例一起使用，并且其它应用/客户端、中间件、无线电技术和传输协议可以在各种示例中被替换而不脱离本发明的精神或范围。
图1示出适用于各个实施例的蜂窝网络系统100。蜂窝网络系统100可以包括多个设备，诸如计算设备102、一个或多个蜂窝塔或基站104、以及连接到因特网110的服务器108和112。计算设备102可以经由包括码分多址(CDMA)、时分多址(TDMA)、全球移动通信系统(GSM)、个人通信服务(PCS)、第三代(3G)、第四代(4G)、长期演进(LTE)或任何其它类型的连接的一个或多个蜂窝连接106，与蜂窝塔或基站104交换数据。蜂窝塔或基站104可以与可以连接到因特网110的路由器进行通信。以这种方式，经由到蜂窝塔或基站104和/或因特网110的连接，可以在计算设备102和服务器108和112之间交换数据。在一个实施例中，服务器108可以是内容提供商服务器或编码器(例如，内容服务器)，提供用于经由DASH客户端输出的段。在一个实施例中，服务器112可以是广播多媒体服务中心(BMSC)服务器，其可以接收从编码器输出的段并对段到计算设备102的空中(OTA)传输进行控制。当然，虽然可以参照OTA传输来描述本文描述的接收机设备的特征，但是可以与有线传输、无线传输或有线和无线传输的组合相结合来使用这些特征。因此，OTA传输不是必要的。
图2A示出了计算设备中的传输层与应用和/或客户端层之间的实施例关系。在一个实施例中，可以经由因特网协议/用户数据报协议(IP/UDP)传输层202在计算设备处接收文件。作为示例，如以上参照图1讨论的经由因特网110从服务器112发送到计算设备102的广播文件可以在IP/UDP传输层202处在计算设备102处被接收。在一个实施例中，文件可以是经由因特网发送的媒体文件的段。
IP/UDP传输层202可以将接收到的文件传递到单向传输的文件递送(FileDelivery over Unidirectional Transport，FLUTE)层204。在一个实施例中，FLUTE层204可以是被使得能够使用FLUTE协议将文件从IP/UDP传输层202传递到诸如DASH客户端210之类的应用和/或客户端的应用。在一个实施例中，FLUTE层204可以对所接收的文件应用纠错，诸如前向纠错(FEC)。在一个实施例中，FLUTE层204可以接收来自诸如DASH客户端210的应用和/或客户端的指示，其可以指示应用和/或客户端是否被使得能够利用段的不完整版本。作为示例，来自DASH客户端210的文件请求可以指示DASH客户端210被使得能够利用文件的不完整版本。FLUTE层204可以解析所接收的文件并将文件传递到设备侧HTTP服务器，诸如DASH服务器206。在计算设备上运行的eMBMS中间件207可以包括设备侧DASH服务器206、FLUTE层204和/或IP/UDP传输层202中的一个或多个。在一个实施例中，设备侧DASH服务器206可以是驻留在计算设备上的HTTP服务器应用，其在计算设备上具有其自己分配的存储器空间(例如，存储器高速缓存)。在一个实施例中，DASH客户端210可以从设备侧DASH服务器206请求和/或接收文件，并且可以将文件传递到编解码器212，以便最终由计算设备呈现内容(例如，播放内容)。在一个实施例中，DASH客户端210被使得能够在呈现内容时利用文件的不完整版本。在另一个实施例中，DASH客户端210被使得能够在呈现内容之前修复文件的不完整版本。
图2B示出了网络元件与计算设备应用和/或客户端层之间的实施例关系。作为示例，可以从内容服务器108(例如，DASH服务器)将文件(例如，由编码器输出的DASH媒体流中的段)发送给服务器112(例如，具有FLUTE发送器的BMSC服务器)。另外，内容服务器108可以确定针对文件(例如，DASH媒体流中的段)的一个或多个访问位置，并且可以向服务器112发送对访问位置的指示。访问位置可以是对在所请求的文件中的字节位置的指示，在该字节位置处客户端可以访问文件的不完整版本，并开始解析文件的不完整版本，以识别可以用于解码和/或呈现文件的不完整版本的随机访问点(例如，流访问点(SAP)类型1或2)或同步样本。虽然图2B示出了由服务器108提供访问位置，但是访问位置可以由诸如服务器112、eMBMS中间件207等的通信系统中的任何元件来确定和/或指示。服务器112可以将文件分组化以便传输到计算设备102，并根据FLUTE协议准备文件递送表(FDT)。在一个实施例中，FDT可以包括对访问位置的指示。例如，FDT可以包括属性“IndependentUnitPositions”，其指示DASH段中的DASH客户端可以在其处访问该段的以空格隔开的一个或多个字节位置。
服务器112可以将包括对文件访问位置的指示和分组的FDT发送给计算设备102。在从服务器112到计算设备102的eMBMS中间件207的传输中，分组可能丢失或可能未丢失。当文件的分组未丢失时，文件的完整版本可以由eMBMS中间件207组装并且可用于DASH客户端210。当不是文件的所有数据分组丢失、或者当不是文件的所有数据分组丢失并且不可通过应用纠错恢复时，文件的不完整版本可以由eMBMS中间件207组装并且可用于DASH客户端210。当文件的所有数据分组丢失并且不可通过应用纠错恢复时，eMBMS中间件207不可以组合文件的任何版本。eMBMS中间件207可以基于所接收的FDT中的文件指示来识别是否接收到文件的完整版本、文件的不完整版本和/或没有接收到文件的任何版本。
DASH客户端210可以发送文件请求(例如，HTTP GET操作)，指示DASH客户端210被使得能够利用文件的不完整版本(例如，具有Prefer字段指示“return＝3gpp-partial”的GET操作、具有Accept报头字段指示“application/3gpp-partial”的GET操作等)。eMBMS中间件207(例如，经由设备侧DASH服务器206)可以响应于指示DASH客户端210被使得能够使用文件的不完整版本的文件请求，向DASH客户端210发送HTTP响应。作为示例，当文件的完整版本可用时，DASH服务器206可以发送具有完整的所请求的文件的200OK响应。作为另一示例，当文件的不完整版本可用时，DASH服务器206可以发送具有文件的不完整版本以及对在所接收的FDT中指示的与该文件相关联的访问位置的指示的200OK响应。作为另一示例，当文件中的任何部分都不可用时，DASH服务器206可以发送没有净荷的“经请求的范围不可满足”响应416。
尽管图2A和2B示出在计算设备的一个或多个处理器上运行的DASH客户端210和DASH服务器206并且围绕其进行讨论，但是内部的设备服务器/客户端交换仅仅是服务器/客户端交换的示例，并且在本文描述的各个实施例可以等同适用于任何类型的服务器/客户端交换。例如，DASH客户端210和DASH服务器206可以是通过诸如因特网的外部网进行通信的分开的设备。
图3示出了由当前的HTTP服务器采用的现有技术方法300，用于处理针对段的不完整版本的客户端请求。在框302中，客户端可以生成段请求。段请求是诸如对段进行请求的“GET”操作(即，方法)的消息。段请求包括所请求的段的URL/URI。在当前的HTTP协议中，也可以使用“部分GET”操作来执行段请求，该“部分GET”操作可以通过包括表示全段中的与URL/URI相关联的子集的一个或多个字节范围来包括针对段中的位于URL/URI处的一部分的请求。然而，在当前的HTTP协议中，段请求不包括关于客户端被使得能够利用与经由“GET”请求的完全资源或者如由“部分GET”所指示的部分资源有关的段的不完整版本的指示。实际上，当前的HTTP段请求事实上是“不全则无”(“all or nothing”)请求，指示客户端只能使用整个段或段中的被请求的整个子集。
在框306中，HTTP服务器接收在框304中由客户端发送的段请求。在确定框308中，HTTP服务器确定完全的经请求的段是否是可用的。HTTP服务器可以通过查看与段请求相关联的URL/URI，并确定位于URL/URI处的段是否丢失数据和/或以任何方式被破坏，来确定完全的经请求的段或者整个子集是否是可用的。在当前的HTTP协议中，仅当段或所寻求的整个子集未丢失数据和/或未被破坏时，该段或所寻求的整个子集才被确定为完全的段并被认为有资格被返回。
响应于确定完全的经请求的段是可用的(即，确定框308＝“是”)，HTTP服务器在框310中发送包括所请求的段的响应，并且在框312中，客户端接收包括该段的响应。响应可以包括指示整个经请求的段被成功获取的状态码，诸如200“OK”。
响应于确定完全的经请求的段是不可用的(即，确定框308＝“否”)，HTTP服务器在框314中发送不具有所请求的段中的任何部分的错误消息，并且客户端在框316中接收到错误消息。错误消息可以包括状态码，诸如404“Not Found”。当前的HTTP方法300的缺点在于：客户端从未接收到在服务器处可用的段的不完整版本。因此，在当前的HTTP系统中，能够使用段的不完整版本的客户端无法通过播放段的不完整版本来改善终端用户媒体播放体验，这是因为客户端不会从HTTP服务器接收到段的不完整版本。
各个实施例通过使得DASH服务器能够响应于客户端请求而提供段的不完整版本来改善终端用户媒体播放体验。图4-15示出了供服务器处理针对段的不完整版本的客户端请求的实施例方法。尽管围绕DASH客户端设备和DASH服务器讨论了图4-15所示的实施例方法的操作，但是这些操作可以由以客户端/服务器关系运行的任何两个设备和/或应用来执行。
图4示出了供DASH服务器处理针对段的不完整版本的DASH客户端请求的实施例方法400。在一个实施例中，方法400的操作可以由与DASH客户端通信的DASH服务器执行，以从DASH服务器向DASH客户端递送对媒体文件请求的不完整响应。在框402中，DASH客户端可以生成包括段的不完整版本能力指示(an incomplete version of a segment capableindication)的段请求。在一个实施例中，包括段的不完整版本能力指示的段请求可以是包括指示DASH客户端能够使用段的不完整版本(例如，不完整的段)的报头字段的“GET”操作(即，方法)。在一个实施例中，报头字段可以是在RFC 7231中描述的accept报头字段。例如，具有accept报头字段指示“application/3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。在一个实施例中，报头字段可以是在RFC 7240中描述的prefer报头字段。例如，具有prefer报头字段指示“return＝3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。
在框404中，DASH客户端可以向DASH服务器发送段请求，并且在框406中，DASH服务器可以接收段请求。
在确定框408中，DASH服务器可以确定完全的经请求的段是否是可用的。在一个实施例中，DASH服务器可以通过查看与段请求相关联的URL/URI并确定URL/URI处的段是否丢失数据和/或以任何方式被损坏，来确定完全的所请求的文件是否是可用的。那些未丢失数据和/或不包括损坏的数据的段可以被确定为完全的段。那些丢失数据和/或包括损坏的数据的段可以被确定为段的不完整版本。
响应于确定完全的所请求的段是可用的(即，确定框408＝“是”)，DASH服务器可以在框410中发送包括完全的所请求的段的响应，并且DASH客户端可以在框412中接收包括完全的所请求的段的响应。响应可以包括指示整个所请求的段被成功获取的状态码，诸如200“OK”。
响应于确定完全的所请求的段是不可用的(即，确定框408＝“否”)，DASH服务器可以在确定框414中确定DASH客户端是否已指示其能够使用段的不完整版本。在一个实施例中，DASH服务器可以至少部分地基于段请求报头字段来确定DASH客户端能够使用段的不完整版本，其中段请求报头字段指示DASH客户端能够使用段的不完整版本。
响应于确定DASH客户端不能够使用段的不完整版本(即，确定框414＝“否”)，DASH服务器可以在框416中发送不具有所请求的段中的任何部分的错误消息给DASH客户端，并且DASH客户端可以在框424中接收错误消息。在一个实施例中，错误消息可以是从DASH服务器发送给DASH客户端的消息，包括诸如“404Not Found”的错误状态码。
响应于确定DASH客户端能够使用段的不完整版本(即，确定框414＝“是”)，DASH服务器可以在确定框418中确定所请求的段是否是部分可用的。如上所述，响应于确定所请求的文件不是部分可用的(即，确定框418＝“否”)，DASH服务器可以在框416中发送不具有段的错误消息，并且DASH客户端可以在框424中接收错误消息。
响应于确定所请求的段是部分可用的(即，确定框418＝“是”)，DASH服务器可以在框420中将来自DASH服务器的响应发送给DASH客户端，该响应包括段的不完整版本和关于段是部分段的指示。例如，响应可以包括作为Content-Type的“application/3gpp-partial”，指示段是部分段。在框422中，客户端设备可以接收包括段的不完整版本的响应。由作为Content-Type的“application/3gpp-partial”标识的响应的净荷可以被包括在HTTP状态码200“OK”中，该状态码可以被格式化为具有在Content-Type报头中标识的boundary(边界)字符串的多部分/字节范围。下面示出了可以由DASH客户端接收的这种响应的示例伪代码，假设DASH服务器在DASH服务器收到请求时具有大小为8000字节的所请求的段的字节范围集合0-1999和7000-7999：
HTTP/1.1 200OK
Date:Wed,25Feb 2015 06:25:24GMT
Content-Length:3241
Content-Type:application/3gpp-partial；boundary＝THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type:video/mp4
Content-Range:bytes 0-1999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type:video/mp4
Content-Range:bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES—
图5示出了供DASH服务器处理针对段的不完整版本的DASH客户端请求的另一实施例方法500。方法500的操作可以类似于上述方法400的操作，例外地是，方法500的操作可以在DASH客户端发送初始段请求之后执行，在初始段请求中没有关于DASH客户端可以具有部分段能力的特别指示。在一个实施例中，方法500的操作可以由与DASH客户端通信的DASH服务器执行，以将对媒体文件请求的不完整响应从DASH服务器递送给DASH客户端。
在一个实施例中，DASH客户端可以发送初始段请求，该初始段请求没有关于DASH客户端能够使用段的不完整版本的任何特别指示。响应于接收到完全的所请求的段，DASH客户端可以不采取任何其它操作。然而，DASH客户端可以监测响应于段请求而接收到的错误消息，并且响应于接收到初始错误消息，DASH客户端可以重新请求先前请求的段，这次包括指示客户端能够使用段的不完整版本的报头字段。因此，在确定框502中，DASH客户端可以确定是否接收到响应于段请求的错误消息。响应于确定没有接收到错误消息(即，确定框502＝“否”)，DASH客户端可以继续在确定框502中监测错误消息。
响应于确定接收到错误消息(即，确定框502＝“是”)，DASH客户端和DASH服务器可以执行上面参照图4描述的方法400的编号相同的框中的框402-424中的操作以尝试接收响应于错误消息的部分段。
图6示出了供DASH服务器处理针对段的不完整版本的DASH客户端请求的另一实施例方法600。方法600的操作可以类似于在上描述的方法400的操作，例外的是，方法600的操作可以在DASH客户端发送初始段请求之后执行，在初始段请求中没有关于DASH客户端能够使用部分段的特别指示。在一个实施例中，方法600的操作可以由与DASH客户端通信的DASH服务器执行，以从DASH服务器向DASH客户端递送对媒体文件请求的不完整响应。
在一个实施例中，DASH客户端可以发送初始段请求，该初始段请求没有关于DASH客户端能够使用段的不完整版本的任何特别指示。响应于接收到完全的所请求的段，DASH客户端可以不采取任何其它操作。然而，DASH客户端可以监测字节范围指示，并且响应于从DASH服务器接收到字节范围指示，DASH客户端可以使用其它字节范围来请求段中的后续部分，这次包括指示客户端能够使用段的不完整版本的报头字段。因此，在确定框602中，DASH客户端可以确定是否接收到响应于段请求的字节范围。例如，DASH客户端可以确定是否接收到包括状态码206和对段中的在服务器处可用的部分的字节范围指示的部分内容消息。响应于确定没有接收到字节范围(即，确定框602＝“否”)，DASH客户端可以继续在确定框602中监测字节范围。响应于确定接收到字节范围(即，确定框602＝“是”)，DASH客户端和DASH服务器可以执行上面参照图4描述的方法400的编号相同的框中的框402-424中的操作以尝试接收响应于接收的字节范围的部分段。
图7是示出根据各个实施例的DASH客户端和DASH服务器之间的交互的呼叫流程图，其中DASH客户端可以生成段请求，该段请求包括作为在RFC 7231中描述的Accept报头字段的、关于客户端能够使用段的不完整版本的指示。例如，具有Accept报头字段指示“application/3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。
例如，在呼叫序列702中，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET，并且因为在DASH服务器处完全的段是可用的，所以可以返回具有完全的段的200响应。在呼叫序列704中，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET，并且只有段中的一部分可以是在DASH服务器处可用的。由于Accept报头指示DASH客户端能够使用部分段，所以DASH服务器可以确定DASH客户端具有部分段能力，并且可以返回具有部分段的200响应。
在呼叫序列706中，DASH客户端可以初始地发送没有特殊段能力指示的GET，并且DASH服务器可以返回404错误消息，这是因为只有部分段是可用的。作为响应，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET以重新请求段。因为Accept报头指示DASH客户端具有部分段能力，所以DASH服务器可以确定DASH客户端能够使用部分段，并且可以返回具有部分段的200响应。
在呼叫序列708中，DASH客户端可以初始地发送具有字节范围指示并且没有特殊段能力指示的部分GET，并且DASH服务器可以返回206部分内容消息，这是因为所请求的字节范围是可用的。作为响应，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET，以请求段中的后续部分，诸如超过字节1000的字节范围。DASH服务器可以基于Accept报头中的指示来确定DASH客户端能够使用部分段，并且返回具有超出字节1000的任何内容的206部分内容响应。
图8示出了根据各个实施例的DASH客户端和DASH服务器之间的交互，其中DASH客户端可以生成包括作为在RFC 7240中描述的Prefer报头字段的段的不完整版本能力指示的段请求。例如，具有Prefer报头字段指示“return＝3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。
例如，在呼叫序列802中，DASH客户端可以发送具有Prefer报头字段指示“return＝3gpp-partial”的GET，并且因为在DASH服务器处完全的段是可用的，所以可以返回具有完全的段的200响应。
在呼叫序列804中，DASH客户端可以发送具有Prefer报头字段指示“return＝3gpp-partial”的GET，但是仅段中的部分在DASH服务器处可以是可用的。因为Prefer报头指示DASH客户端能够使用部分段，所以DASH服务器可以确定DASH客户端能够使用部分段，并返回具有部分段的200响应。
在呼叫序列806中，DASH客户端可以初始发送没有特殊段能力指示的GET，并且DASH服务器可以返回404错误消息，这是因为只有部分段是可用的。作为响应，DASH客户端可以发送具有Prefer报头字段指示“return＝3gpp-partial”的GET以重新请求段。DASH服务器可以基于Prefer报头指示来确定DASH客户端能够使用部分段，并且返回具有部分段的200响应。
在呼叫序列808中，DASH客户端可以初始地发送具有字节范围指示并且没有特殊段能力指示的部分GET，并且DASH服务器可以返回206部分内容消息，这是因为所请求的字节范围是可用的。作为响应，DASH客户端可以发送具有Prefer报头字段指示“return＝3gpp-partial”的GET，以请求段中的后续部分，诸如超出字节1000的字节范围。因为Prefer报头指示DASH客户端能够使用部分段，所以DASH服务器可以确定DASH客户端能够使用部分段，并返回具有超出字节1000的任何内容的206部分内容响应。
图9示出了供DASH服务器处理针对段的不完整版本的DASH客户端请求的实施例方法900。在一个实施例中，方法900的操作可以由与DASH客户端通信的DASH服务器来执行，以将对媒体文件请求的不完整响应从DASH服务器递送给DASH客户端。在框902中，DASH客户端可以生成段请求。段请求可以不包括对DASH客户端能力的任何特殊指示。在框904中，DASH客户端可以向DASH服务器发送段请求，并且在框906中，DASH服务器可以接收段请求。
在确定框908中，DASH服务器可以确定完全的所请求的段是否是可用的。在一个实施例中，DASH服务器可以通过查看与段请求相关联的URL/URI并确定URL/URI处的段是否丢失数据和/或以任何方式被损坏，来确定完全的所请求的文件是否是可用的。那些没丢失数据和/或不包括损坏的数据的段可以被确定为完全的段。丢失数据和/或包括损坏的数据的段可以被确定为段的不完整版本。
响应于确定完全的所请求的段是可用的(即，确定框908＝“是”)，DASH服务器可以在框910中发送包括完全的所请求的段的响应，并且DASH客户端可以在框912中接收包括完全的所请求的段的响应。响应可以包括指示整个请求的段被成功获取的状态码，诸如200“OK”。
响应于确定完全的所请求的段是不可用的(即，确定框908＝“否”)，DASH服务器可以在确定框914中确定所请求的段是否是部分可用的。响应于确定所请求的段不是部分可用的(即，确定框914＝“否”)，DASH服务器可以在框916中向DASH客户端发送没有所请求的段中的任何部分的错误消息，并且DASH客户端可以在框918中接收错误消息。在一个实施例中，错误消息可以是从DASH服务器发送给DASH客户端的消息，包括错误状态码，诸如“404Not Found”。
响应于确定段是部分可用的(即，确定框914＝“是”)，DASH服务器可以在框920中将来自DASH服务器的响应发送给DASH客户端，该响应包括关于在DASH服务器处段的不完整版本是可用的的指示，并且DASH客户端可以在框922中接收响应。在一个实施例中，响应消息可以包括关于所请求的段的不完整版本是可用的以及段的可用的字节范围的指示。在一个实施例中，响应消息可以是包括指示所请求的段的不完整版本是可用的以及可用的字节范围的扩展报头在内的消息。例如，初始响应可以是包括状态码404和扩展报头“X-Available-Ranges:bytes a-b,c-d,...”的错误消息。作为另一示例，初始响应可以是部分内容消息，其包括状态码206和扩展报头“X-Available-Ranges:bytes a-b,c-d,...”。在一个实施例中，响应消息可以是诸如300系列消息的重引导消息，其包括指示所请求的段的不完整版本是可用的以及可用的字节范围的实体主体，诸如“Content-Type＝3GPP-partial-byte-ranges”。
在框924中，DASH客户端可以生成段请求。可以生成段请求以接收段的不完整版本。段请求可以包括关于客户端能够使用段的不完整版本的指示。例如，具有accept报头字段指示“application/3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。在一个实施例中，针对段的不完整版本的段请求可以是“部分GET”操作(即，方法)，包括对DASH服务器指示的对于段可用的字节范围的指示。在框926中，DASH客户端可以向DASH服务器发送段请求，并且在框928中，DASH服务器可以接收段请求。
响应于接收到具有所指示的字节范围的段请求，DASH服务器可以在框930中向DASH客户端发送包括段的不完整版本的响应。在一个实施例中，包括段的不完整版本的响应可以包括关于段是部分段的指示。例如，响应可以包括作为Content-Type的“multipart/byteranges”与相关联的boundary指示，诸如“boundary＝THIS_STRING_SEPARATES”，其指示段是部分段。在框932中，客户端可以接收包括段的不完整版本的响应。
图10示出了根据各个实施例的DASH客户端和DASH服务器之间的交互，其中从DASH服务器初始发送的响应消息是包括指示所请求的段的不完整版本是可用的以及可用的字节范围的扩展报头在内的消息。
例如，在呼叫序列1004中，对来自DASH客户端的GET的初始响应可以是来自DASH服务器的错误消息，该错误消息包括状态码406和扩展报头“X-Available-Ranges:bytes a-b,c-d,...”。具有部分段能力的DASH客户端可以将扩展报头解释为指示部分段是可用的，并且可以发送包括对DASH服务器指示的对于段可用的字节范围的指示的部分GET请求。基于GET请求中的所指示的字节范围，DASH服务器可以返回具有所请求的可用段范围的206部分内容响应。
作为另一示例，在呼叫序列1006中，对来自DASH客户端的GET的初始响应可以是包括状态码206和扩展报头“X-Available-Ranges:bytes a-b,c-d”的部分内容消息。具有部分段能力的DASH客户端可以将扩展报头解释为指示部分段是可用的，并且可以发送包括对DASH服务器指示的对于段可用的字节范围的指示的部分GET请求。基于在GET请求中包括的字节范围，DASH服务器可以返回具有所请求的可用段范围的206部分内容响应。
图11示出了根据各个实施例的DASH客户端和DASH服务器之间的交互，其中来自DASH服务器的初始响应消息是诸如300系列消息的重引导消息，其包括指示所请求的段的不完整版本是可用的以及可用的字节范围的实体主体，诸如“Content-Type＝3gpp-partial-byte-ranges”。
例如，在呼叫序列1104中，对来自DASH客户端的GET的初始响应可以是诸如300系列消息的重引导消息，包括指示所请求的段的不完整版本是可用的以及可用的字节范围的实体主体，诸如“Content-Type＝3gpp-partial-byte-ranges”。以这种方式，DASH服务器可以不重引导DASH客户端，而是仅以关于相同的段是仅部分可用的的指示将客户端引导回该相同的段。具有部分段能力的DASH客户端可以将具有实体主体的300消息解释为指示部分段可以是可用的，并且可以发送包括对DASH服务器指示的对于段可用的字节范围的指示的部分GET请求。基于包含在GET请求中的字节范围，DASH服务器可以返回具有所请求的可用段范围的206部分内容响应。
作为另一示例，在呼叫序列1106中，DASH客户端可以初始发送具有字节范围指示并且没有特殊段能力指示的部分GET，并且DASH服务器可以返回具有可用的所请求的字节范围的206部分内容消息。然后，DASH客户端可以发送部分GET请求以请求段中的后续部分，诸如超出字节1000的字节范围。因为超过字节1000的部分段是可用的，所以来自DASH服务器的响应可以是诸如作为300系列消息的重引导消息，其包括指示所请求的段的不完整版本是可用的以及可用的字节范围的实体主体，诸如“Content-Type＝3gpp-partial-byte-ranges”。以这种方式，DASH服务器可以不重引导DASH客户端，而是仅以关于相同的段是仅部分可用的的指示来将客户端引导回该相同的段。具有部分段能力的DASH客户端可以将具有实体主体的300消息解释为指示部分段是可用的，并且可以发送包括对DASH服务器指示的对于段可用的超过字节1000的字节范围的指示的GET请求。基于在GET请求中包括的字节范围，DASH服务器可以返回具有超出字节1000的所请求的可用的段范围的206部分内容响应。
图12示出了供DASH服务器处理针对段的不完整版本的DASH客户端请求的另一实施例方法1200。方法1200的操作可以类似于上面描述的方法400的操作，例外的是，方法1200的操作可以当访问位置是与段相关联的时被执行。在一个实施例中，方法1200的操作可以由与DASH客户端通信的DASH服务器来执行，以从DASH服务器向DASH客户端递送对媒体文件请求的不完全响应。在框402-424中，DASH客户端和DASH服务器可以执行上面参照图4描述的方法400的编号相同的框的操作，以当客户端不能使用段的不完整版本时提供包括完全的所请求的段或错误消息的响应。
响应于确定DASH客户端能够使用段的不完整版本(即，确定框414＝“是”)，DASH服务器可以在确定框1202中确定所接收的FDT是否指示了由DASH客户端请求的段被发送给了DASH服务器。通过检查针对包含所请求的段的DASH表示(DASH representation)的FDT，DASH服务器可以确定所请求的段是否是与该表示相关联的真实段。以这种方式，DASH服务器可以将针对媒体流中的段的错误请求与针对媒体流中的段的有效请求区分开。
响应于确定FDT没列出所请求的段(即，确定框1202＝“否”)，在框416和424中，DASH服务器和DASH客户端可以执行上面参照图4描述的方法400的编号相同的框的操作，以便指示错误。
响应于确定FDT列出所请求的段(即，确定框1202＝“是”)，DASH服务器可以在确定框418中确定所请求的段是否是部分可用的。响应于确定所请求的文件不是部分可用的(即，确定框418＝“否”)，DASH服务器可以在框1212中发送没有段的错误消息。以这种方式，响应于能够使用段的不完整版本的DASH客户端请求在DASH服务器处其字节都不可用的段，DASH服务器可以生成并发送错误消息。例如，当在DASH服务器处没有针对经请求的DASH段的字节或DASH段的字节范围是可用的时，DASH服务器可以发送包括状态码416“经请求的范围不可满足”的错误消息。错误消息可以进一步指示在针对DASH段的FDT实例中提供的内容类型、在针对DASH段的FDT中提供的内容位置、以及基于在针对DASH段的FDT中指示的内容长度的如“bytes*/content-length”指示的内容范围。
在框1214中，DASH客户端可以接收错误消息。通过接收包括状态码416“经请求的范围不可满足”的错误消息，DASH客户端可以区分针对无效段的请求(例如，导致具有状态码404“Not Found”的错误消息的请求)与针对在传输中丢失了的段(例如，在FDT中指示的段，但这些段没有导致具有状态码416“经请求的范围不可满足”的错误消息的接收到的字节)的请求。在一个实施例中，DASH客户端可以隐藏由具有状态码416的错误消息指示的传输段的丢失，并通过请求该表示中的下一段来继续正常操作。
响应于确定所请求的段是部分可用的(即，确定框418＝“是”)，DASH服务器可以在框1208中将来自DASH服务器的响应发送给DASH客户端，该响应包括段的不完整版本、关于段是部分段的指示、以及对针对段的一个或多个访问位置的指示。例如，响应可以包括：作为Content-Type的“application/3gpp-partial”，指示段是部分段以及；扩展报头字段“3gpp-access-position”，指示DASH段中的DASH客户端可以在其处访问该段的一个或多个字节位置。响应还可以包括对段中的在响应中包括的部分的指示。例如，响应可以包括指示段的在响应中包括的一个或多个字节范围的一个或多个报头字段(例如，content-range(内容-范围)报头字段)。在这样的实施例中，当响应包括指示段的在响应中包括的一个或多个字节范围的一个或多个报头字段时，一个或多个扩展报头字段“3gpp-access-position”可以包括一个或多个字节位置，该一个或多个字节位置处在所指示的一个或多个字节范围内，并且DASH客户端可以在一个或多个字节位置处访问段。在各个实施例中，可以作为DASH段的不完整接收的版本的FDT实例的文件条目的“mbms2015:IndependentUnitPositions”属性，将针对段的一个或多个访问位置向DASH服务器指示。当DASH段的不完整接收的版本的所有FDT实例的文件条目不包括“mbms2015:IndependentUnitPositions”属性时，DASH服务器可以分析DASH段的不完整接收的版本，以确定一个或多个电影片段头(moof)位置，以将该一个或多个moof识别为针对段的一个或多个访问位置。
在框1210中，DASH客户端可以接收包括段的不完整版本的响应、关于响应包括部分段的指示、以及对一个或多个访问点的指示。所接收的响应还可以例如在content-range报头字段中包括对段中的包括在响应中的部分的指示。由作为Content-Type的“application/3gpp-partial”来标识的响应的净荷可以被包括在HTTP状态码200“OK”中，该状态码可以被格式化为多部分/字节位置，该多部分/字节位置具有在Content-Type报头中标识的boundary字符串、以及以一个或多个逗号隔开的对应于在字段“3gpp-access-position”中指示的针对段的访问点的字节位置。
在一个示例中，在DASH服务器接收请求时，DASH服务器可以具有大小为256000字节的所请求的段的字节范围集合0-19999、50000-85000、105500-199888和201515-229566，并且针对DASH段的FDT实例的文件条目可以包括具有以下列表值“0 60000 80000 110000”的属性“mbms2015:IndependentUnitPositions”。在这样的示例中，DASH服务器可以将第一访问位置的字节范围标识为：0-59999，将第二访问位置标识为：60000-79999，将第三访问位置标识为：80000-109999，将第四访问位置标识为：110000-255999。因为可用于DASH服务器的第一字节范围(0-19999)包含第一访问位置的开始，所以DASH服务器可以在响应中包括“3gpp-access-position:0”。可用于DASH服务器的第二字节范围(50000-85000)可以包含第二访问位置和第三访问位置的一部分，并因此DASH服务器可以在响应中包含“3gpp-access-position:60000,80000”。类似地，可用于DASH服务器的第三字节范围(105500-199888)可以包含第四访问位置的一部分，因此DASH服务器可以在响应中包括“3gpp-access-position:110000”。最后，可用于DASH服务器的第四字节范围(201515-229566)可以不包含任何访问位置的开始，并作为结果，DASH服务器可以不在响应中包括“3gpp-access-position”元素。以下示出了DASH客户端可以接收的这种响应的伪代码示例：
HTTP/1.1 200OK
…
Content-Length:172441
Content-Type:application/3gpp-partial；boundary＝SEPARATION_STRING
Cache-Control:no-cache
--SEPARATION_STRING
Content-type video/mp4
Content-range:bytes 0-19999/256000
3gpp-access-position:0
...<the first range>…
--SEPARATION_STRING
Content-type video/mp4
Content-range:bytes 50000-85000/256000
3gpp-access-position:60000,80000
...<the second range>…
--SEPARATION_STRING
Content-type:video/mp4
Content-range:bytes 105500-199888/256000
3gpp-access-position:110000
...<the third range>…
--SEPARATION_STRING
Content-type:video/mp4
Content-range:bytes 201515-229566/256000
...<the fourth range>…
--SEPARATION_STRING
图13是示出根据各个实施例的在DASH客户端和DASH服务器之间的交互的呼叫流程图，其中DASH客户端可以生成段请求。段请求可以包括作为在RFC 7231中描述的Accept报头字段的关于客户端能够使用段的不完整版本的指示。例如，具有Accept报头字段指示“application/3gpp-partial”的GET操作可以指示DASH客户端将接受响应于段请求的部分段。
例如，在呼叫序列1302中，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET，并且因为在DASH服务器处完全的段是可用的，所以可以返回具有完全的段的200响应。
在呼叫序列1304中，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET。如果在DASH服务器处只有段的一部分是可用的，并且Accept报头指示DASH客户端能够使用部分段，那么DASH服务器可以确定DASH客户端具有部分段能力，并且可以向DASH客户端发送200响应，该响应具有部分段、部分段内容类型报头字段指示“application/3gpp-partial”和访问位置指示报头字段“3gpp--access-position”。
在呼叫序列1306中，DASH客户端可以发送具有Accept报头字段指示“application/3gpp-partial”的GET。如果段中的字节在DASH服务器处没有可以是可用的，并且Accept报头指示DASH客户端能够使用部分段，那么DASH服务器可以确定DASH客户端具有部分段能力，并且向DASH客户端发送具有内容类型报头字段指示“application/3gpp-partial”以及content-range“bytes*/content-length”的416“经请求的范围不可满足”错误消息。
图14是诸如DASH媒体流的媒体流中的段的数据框图。媒体流可以包括初始化段和诸如媒体段1、媒体段2等的各种媒体段。媒体段可以包括包括元数据的一个或多个moof，元数据诸如是指示可以由DASH客户端用于解码和/或呈现媒体段中的一个或多个媒体数据部分(mdat)(例如，媒体段的字节范围，其包括视频、音频等数据样本)的随机访问点(例如，流访问点(SAP)类型1或2)或同步样本的数据。在各个实施例中，媒体段中的初始部分可以是媒体段的对应于段中的第一moof的字节范围。
没有媒体段中的第一moof，段中的mdat可能是不可解析的，并且段中的任何其它moof的起始位置可能无法被DASH客户端定位，这是因为moof和mdat的大小可能是DASH客户端未知的。各个实施例可以提供可以标识媒体段中的字节位置的(例如，由属性“3gpp-access-position”指示的)访问位置指示，在该字节位置处，DASH客户端可以访问段以开始解析段的不完整版本，以识别可以用于解码和/或呈现段的不完整版本的随机访问点(例如，流访问点(SAP)类型1或2)或同步样本。以这种方式，访问位置可以是所请求的字节范围或所请求的段中的中间字节位置，其可以使DASH客户端能够在段中的初始部分(例如，段中的第一moof)可能丢失时解析段的不完整版本。
例如，如图14所示，媒体段1的moof1和mdat1的一部分可能在传输中丢失，这导致DASH服务器仅向进行请求的DASH客户端提供媒体段1的不完整版本。通过指示媒体段1的不完整版本被提供并且指示元素“3gpp-access-position”中的访问点字节位置，DASH客户端可以确定不完整版本是否包括初始部分(例如，moof 1)。响应于确定段中的初始部分(例如，moof 1)丢失并且不在不完整版本中，DASH客户端可以开始在访问位置处进行解析。以这种方式，moof 2中的元数据(诸如指示随机访问点(例如，流访问点(SAP)类型1或2)或同步样本的数据)可以使DASH客户端能够解码和/或呈现mdat2和诸如媒体段2的后面的媒体段。
图15示出了供DASH客户端处理段的不完整版本的实施例方法1500。在一个实施例中，方法1500的操作可以由DASH客户端执行以解析对媒体文件请求的不完全响应。如上所讨论地，在框1210中，DASH客户端可以接收包括段的不完整版本的响应、关于响应包括部分段的指示以及对一个或多个访问点的指示。例如，响应可以包括：作为Content-Type的“application/3gpp-partial”，指示段是部分段；以及扩展报头字段“3gpp-access-position”，指示DASH段中的一个或多个字节位置，其中DASH客户端可以在一个或多个字节位置处访问段。
在可选的确定框1501中，DASH客户端可以确定是否在不完整响应中接收到段中的初始部分。在各个实施例中，媒体段中的初始部分可以是媒体段的与段中的第一moof对应的字节范围。响应于确定接收到段中的初始部分(即，确定框1501＝“是”)，DASH客户端可以在框1503中在初始部分中的第一字节处开始解析段的不完整版本。
响应于确定没有接收到段中的初始部分(即，确定框1501＝“否”)，或者在于其中DASH客户端可以未被配置为检查初始部分的实施例中，DASH客户端可以在确定框1502中确定是否在段的不完整版本中接收到访问位置处的字节。响应于确定与访问位置对应的字节未被接收(即，确定框1502＝“否”)，DASH客户端可以在框1504中请求表示(representation)中的下一段。响应于确定接收到对应于访问位置的字节(即，确定框1502＝“是”)，DASH客户端可以在框1506中在访问位置处开始解析段的不完整版本。
各个实施例(包括但不限于上文参照图4-15讨论的实施例)可以在各种移动设备(即，接收机设备)中的任何一个移动设备中实现，移动设备的示例被示出在图16中。例如，移动计算设备1600可以包括耦合到触摸屏控制器1604和内部存储器1602的处理器1601。处理器1601可以是被指定用于通用或专用处理任务的一个或多个多核集成电路(IC)。内部存储器1602可以是易失性或非易失性存储器，并且还可以是安全和/或加密的存储器、或不安全和/或未加密的存储器、或其任何组合。触摸屏控制器1604和处理器1601还可以耦合到诸如电阻感测触摸屏、电容感测触摸屏、红外感测触摸屏等的触摸屏面板1612。移动计算设备1600可以具有彼此耦合和/或耦合到处理器1601的一个或多个无线电信号收发机1608(例如，
Figure BDA0003614032860000161
Zigbee、Wi-Fi、蜂窝等)和天线1610，用于进行发送和进行接收。收发机1608和天线1610可以与上述电路一起使用以实现各种无线传输协议栈和接口。移动计算设备1600可以包括蜂窝网络无线调制解调器芯片1616，其使得能够经由蜂窝网进行通信并被耦合到处理器。移动计算设备1600可以包括耦合到处理器1601的外围设备连接接口1618。外围设备连接接口1618可以被单独地配置为接受一种类型的连接，或者被多重地配置为接受各种类型的通用或专有的物理和通信连接，诸如USB、FireWire、Thunderbolt或PCIe。外围设备连接接口1618还可以耦合到类似配置的外围设备连接端口(未示出)。移动计算设备1600还可以包括用于提供音频输出的扬声器1614。移动计算设备1600还可以包括由塑料、金属或材料的组合构成的用于包含本文所讨论的全部或部分组件的外壳1620。移动计算设备1600可以包括耦合到处理器1601的电源1622，诸如一次性或可再充式电池。可再充式电池还可以耦合到外围设备连接端口，以从移动计算设备1600外部的源接收充电电流。
各个实施例(包括但不限于上文参照图4-15讨论的实施例)还可以在商业上可获得的各种服务器设备中的诸如图17所示的服务器1700的任何一个上实现。这样的服务器1700通常包括耦合到易失性存储器1702的处理器1701和诸如磁盘驱动器1704的大容量非易失性存储器。服务器1700还可以包括软盘驱动器、压缩光盘(CD)或DVD光盘驱动1706，其耦合到处理器1701。服务器1700还可以包括耦合到处理器1701的诸如网络接入端口的一个或多个网络收发机1703，用于与通信网络1707建立网络接口连接，通信网络1707诸如是耦合到其它公告系统计算机和服务器的局域网、互联网、公共交换电话网和/或蜂窝网(例如，CDMA、TDMA、GSM、PCS、3G、4G、LTE或任何其它类型的蜂窝网络)。
处理器1601和1701可以是可以由软件指令(应用)配置以执行包括上面描述的各个实施例的功能的各种功能的任何可编程微处理器、微计算机、或者一个或多个多处理器芯片或芯片。在一些设备中，可以提供多个处理器，诸如专用于无线通信功能的一个处理器和专用于运行其它应用的一个处理器。通常，软件应用可能在其被访问并被加载到处理器1601和1701之前被存储在内部存储器中。处理器1601和1701可以包括足以存储应用软件指令的内部存储器。在许多设备中，内部存储器可以是易失性或非易失性存储器(诸如闪存)、或两者的混合。为了描述的目的，对存储器的一般引用是指可由处理器1601和1701访问的存储器，其包括插入设备中的内部存储器或可移动存储器、以及处理器1601和1701本身内的存储器。
上述方法描述和处理过程流程图仅作为说明性示例来提供，并不旨在要求或意指各个实施例的步骤必须按照呈现的顺序执行。如一名本领域技术人员将理解地，前述实施例中的步骤的顺序可以以任何顺序执行。诸如“此后”、“然后”、“下一”等等不旨在限制步骤的顺序；这些单词仅用于指导读者通读对方法的描述。此外，例如使用冠词“一”、“一个”或“该个”对单数的权利要求要素的任何引用不是要被解释为将元素限制为单数。
结合本文公开的实施例描述的各种说明性逻辑框、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。为了清楚地说明硬件和软件的这种可互换性，已经围绕其功能概括地描述了各种说明性组件、框、模块、电路和步骤。至于这种功能是被实现为硬件还是软件，这取决于特定应用和施加在整个系统上的设计约束。虽然技术人员可以针对每个特定应用以不同的方式实现所描述的功能，但是这种实现决策不应被解释为导致偏离本发明的范围。
用于实现结合本文公开的方面描述的各种说明性逻辑、逻辑框、模块和电路的硬件可以用被设计用于执行本文所描述的功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或晶体管逻辑、分立硬件组件或上述各项的任何组合。通用处理器可以是微处理器，但是在替代方案中，处理器可以是任何常规的处理器、控制器、微控制器或状态机。处理器还可以被实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、结合DSP核的一个或多个微处理器、或任何其它此类配置。或者，一些步骤或方法可以由专用于给定功能的电路来执行。
在一个或多个示例性方面，所描述的功能可以在硬件、软件、固件或其任何组合中实现。如果在软件中实现，则这些功能可以作为一个或多个指令或代码存储在非暂时性计算机可读介质或非暂时性处理器可读介质上。本文公开的方法或算法的步骤可以实施在处理器可执行软件模块和/或处理器可执行指令中，处理器可执行指令可以驻留在非暂时性计算机可读或非暂时性处理器可读存储介质上。非暂时性服务器可读、计算机可读或处理器可读存储介质可以是可以由计算机或处理器访问的任何存储介质。作为示例而非限制，这种非暂时性服务器可读、计算机可读或处理器可读介质可以包括RAM、ROM、EEPROM、FLASH存储器、CD-ROM或其它光盘存储器、磁盘存储或其它磁存储设备、或可以用于以指令或数据结构的形式存储期望的程序代码并且可以由计算机访问的任何其它介质。如本文所使用的磁盘和光盘包括压缩光盘(CD)、激光盘、光盘、数字通用盘(DVD)、软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。以上的组合也包括在非暂时性服务器可读、计算机可读和处理器可读介质的范围内。另外，方法或算法的操作可以作为可以并入一个计算机程序产品中的非暂时性服务器可读、处理器可读介质和/或计算机可读介质上的一个或任何组合或者一组代码和/或指令来存储。
对所公开的实施例的前述描述被提供以使所属领域的技术人员能够制造或使用本发明。对这些实施例的各种修改对于本领域技术人员将是显而易见的，并且在不脱离本发明的精神或范围的情况下，本文定义的通用原理可以应用于其它实施例。因此，本发明不旨在限于本文所示的实施例，而是要符合与所附权利要求和本文公开的原理和新颖特征相一致的最广范围。

Claims (15)

1.一种用于将对媒体文件请求的不完整响应从服务器递送给客户端的方法，包括：
在所述服务器中从所述客户端接收段请求，其中，所述段请求指示所述客户端是否能够使用不完整的段；
在所述服务器中，确定与所述段请求相关联的完全的段是否在所述服务器处是可用的；
在所述服务器中，响应于与所述段请求相关联的所述完全的段在所述服务器处是不可用的，基于所述段请求来确定所述客户端是否能够使用不完整的段；以及
从所述服务器向所述客户端在响应消息中发送不完整的段，所述响应消息包括：
关于所述响应消息包括所述不完整的段的指示；
对经请求的段中被包括在于所述响应消息中包括的所述不完整的段中的一部分的指示，其中，对所述经请求的段中被包括在所述不完整的段中的所述部分的所述指示包括：对所述经请求的段内被包括在所述不完整的段中的字节范围的指示；
所述方法的特征在于所述响应消息还包括：
响应于确定所述客户端能够使用不完整的段，对针对所述不完整的段的一个或多个访问位置的指示，其中，所述一个或多个访问位置标识所述不完整的段内的要在其处开始进行解析以解码所述不完整的段的一个或多个点。
2.根据权利要求1所述的方法，其中，关于所述响应消息包括所述不完整的段的所述指示以及对针对所述不完整的段的一个或多个访问位置的所述指示中的一者或两者是所述响应消息中的分开的报头字段。
3.根据权利要求1所述的方法，其中，所述响应消息中的一个或多个报头字段包括对所述经请求的段中被包括在所述不完整的段中的所述部分的所述指示。
4.根据权利要求3所述的方法，其中，针对所述不完整的段的所述一个或多个访问位置位于所述经请求的段内被包括在所述不完整的段中的所述字节范围内。
5.根据权利要求1所述的方法，其中，所述一个或多个访问位置是与所述段请求相关联的段的字节范围中的一个或多个中间字节位置。
6.根据权利要求5所述的方法，其中，至少一个访问位置在与所述段请求相关联的所述段中的初始部分之外。
7.根据权利要求6所述的方法，其中，与所述段请求相关联的所述段中的所述初始部分是所述段中的第一电影片段报头。
8.根据权利要求1所述的方法，其中，所述一个或多个访问位置是在描述与所述段请求相关联的段的文件递送表FDT中指示的。
9.根据权利要求8所述的方法，其中，所述一个或多个访问位置是由所述FDT中的以逗号隔开的一个或多个字节位置来指示的。
10.根据权利要求1所述的方法，还包括：
响应于确定所述客户端能够使用不完整的段，而在所述服务器中确定是否没有与所述段请求相关联的字节在所述服务器处是可用的；以及
响应于确定没有与所述段请求相关联的字节在所述服务器处是可用的，而从所述服务器向所述客户端发送错误消息，
其中，响应于确定所述客户端能够使用不完整的段，而从所述服务器向所述客户端在响应消息中发送不完整的段，且所述响应消息包括关于所述响应消息包括所述不完整的段的指示以及对针对所述不完整的段的一个或多个访问位置的指示，包括：响应于确定所述客户端能够使用不完整的段并且确定与所述段请求相关联的字节在所述服务器处是可用的，而从所述服务器向所述客户端在响应消息中发送不完整的段，且所述响应消息包括关于所述响应消息包括所述不完整的段的指示以及对针对所述不完整的段的一个或多个访问位置的指示。
11.根据权利要求10所述的方法，其中，所述错误消息指示没有与所述段请求相关联的字节在所述服务器处是可用的。
12.根据权利要求11所述的方法，其中，所述错误消息包括416状态码。
13.根据权利要求1所述的方法，其中，所述客户端是动态自适应流超文本传输协议DASH客户端，而所述服务器是DASH服务器。
14.一种服务器，包括：
处理器，被配置有处理器可执行指令以执行包括任一前述权利要求所述的方法的操作。
15.一种非暂时性处理器可读存储介质，其上存储有处理器可执行指令，当由服务器处理器执行时，所述处理器可执行指令使得所述服务器处理器执行包括权利要求1-13中任意一个所述的方法的操作。
CN202210441193.9A 2015-03-02 2016-02-29 对于部分段的指示 Pending CN114760281A (zh)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201562126842P 2015-03-02 2015-03-02
US62/126,842 2015-03-02
US201562204505P 2015-08-13 2015-08-13
US62/204,505 2015-08-13
US15/054,214 2016-02-26
US15/054,214 US10412138B2 (en) 2015-03-02 2016-02-26 Indication for partial segment
PCT/US2016/020092 WO2016140918A1 (en) 2015-03-02 2016-02-29 Indication for partial segment
CN201680013091.XA CN107431699A (zh) 2015-03-02 2016-02-29 对于部分段的指示

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201680013091.XA Division CN107431699A (zh) 2015-03-02 2016-02-29 对于部分段的指示

Publications (1)

Publication Number Publication Date
CN114760281A true CN114760281A (zh) 2022-07-15

Family

ID=55527675

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201680013091.XA Pending CN107431699A (zh) 2015-03-02 2016-02-29 对于部分段的指示
CN202210441193.9A Pending CN114760281A (zh) 2015-03-02 2016-02-29 对于部分段的指示

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201680013091.XA Pending CN107431699A (zh) 2015-03-02 2016-02-29 对于部分段的指示

Country Status (8)

Country Link
US (1) US10412138B2 (zh)
EP (1) EP3266183B1 (zh)
JP (1) JP6734291B2 (zh)
KR (1) KR102434958B1 (zh)
CN (2) CN107431699A (zh)
AU (1) AU2016226411B2 (zh)
BR (1) BR112017018939B1 (zh)
WO (1) WO2016140918A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10749930B2 (en) 2015-03-02 2020-08-18 Qualcomm Incorporated Indication for partial segment
US10659507B2 (en) 2015-03-02 2020-05-19 Qualcomm Incorporated Indication for partial segment
WO2020037607A1 (zh) * 2018-08-23 2020-02-27 华为技术有限公司 一种传输数据的方法和装置
US10877825B2 (en) * 2018-10-04 2020-12-29 Oracle International Corporation System for offline object based storage and mocking of rest responses
EP3771220A1 (en) * 2019-07-24 2021-01-27 Nagravision S.A. Watermarking video fragments into two or more variants
CN113794898B (zh) * 2021-08-13 2023-03-07 网宿科技股份有限公司 Dash媒体流传输方法、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102687518A (zh) * 2009-12-11 2012-09-19 诺基亚公司 用于流媒体文件内表示的描述和定时的装置及方法
US20130262567A1 (en) * 2012-03-30 2013-10-03 Qualcomm Incorporated Responding to hypertext transfer protocol (http) requests

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050102371A1 (en) 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US20050144278A1 (en) 2003-12-12 2005-06-30 Valeri Atamaniouk System and method for multipart response optimization
US8219711B2 (en) 2008-11-24 2012-07-10 Juniper Networks, Inc. Dynamic variable rate media delivery system
US9060187B2 (en) 2008-12-22 2015-06-16 Netflix, Inc. Bit rate stream switching
US9282131B2 (en) * 2009-01-20 2016-03-08 Imagine Communications Corp. System and method for splicing media files
US8909806B2 (en) 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9769230B2 (en) 2010-07-20 2017-09-19 Nokia Technologies Oy Media streaming apparatus
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
JP5798451B2 (ja) * 2010-12-16 2015-10-21 キヤノン株式会社 情報処理装置およびその方法
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9042449B2 (en) 2011-09-29 2015-05-26 Avvasi Inc. Systems and methods for dynamic transcoding of indexed media file formats
JP5882683B2 (ja) 2011-11-02 2016-03-09 キヤノン株式会社 情報処理装置およびその方法
US9294226B2 (en) * 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
JP6348251B2 (ja) * 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
US9235636B2 (en) 2012-12-20 2016-01-12 Dropbox, Inc. Presenting data in response to an incomplete query
US9521179B2 (en) 2014-07-16 2016-12-13 Verizon Patent And Licensing Inc. Validation of live media stream based on predetermined standards
US10187680B2 (en) 2014-11-11 2019-01-22 Cisco Technology, Inc. Adaptive bit rate system architectures using named domain networking
US10659507B2 (en) 2015-03-02 2020-05-19 Qualcomm Incorporated Indication for partial segment
US10749930B2 (en) 2015-03-02 2020-08-18 Qualcomm Incorporated Indication for partial segment
US20170068992A1 (en) 2015-09-04 2017-03-09 Yahoo! Inc. Multi-source content blending

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102687518A (zh) * 2009-12-11 2012-09-19 诺基亚公司 用于流媒体文件内表示的描述和定时的装置及方法
US20130262567A1 (en) * 2012-03-30 2013-10-03 Qualcomm Incorporated Responding to hypertext transfer protocol (http) requests

Also Published As

Publication number Publication date
EP3266183A1 (en) 2018-01-10
US20160261664A1 (en) 2016-09-08
CN107431699A (zh) 2017-12-01
US10412138B2 (en) 2019-09-10
WO2016140918A1 (en) 2016-09-09
BR112017018939B1 (pt) 2024-02-06
JP2018514108A (ja) 2018-05-31
JP6734291B2 (ja) 2020-08-05
EP3266183B1 (en) 2020-11-25
KR20170124551A (ko) 2017-11-10
AU2016226411A1 (en) 2017-08-10
AU2016226411B2 (en) 2019-11-07
KR102434958B1 (ko) 2022-08-19
BR112017018939A2 (pt) 2018-05-15

Similar Documents

Publication Publication Date Title
CN107431700B (zh) 用于对于部分段的指示的方法和装置
US10412138B2 (en) Indication for partial segment
US9264481B2 (en) Responding to hypertext transfer protocol (HTTP) requests
US10079868B2 (en) Method and apparatus for flexible broadcast service over MBMS
CN107409130B (zh) 对于部分段的指示
AU2017280873B2 (en) Signaling which version information to use on byte-range file repair
CN107438991B (zh) 经由多媒体广播多播服务的灵活广播服务的方法和装置

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