CN102055718B - 一种在http streaming系统中实现分层请求内容的方法,装置和系统 - Google Patents
一种在http streaming系统中实现分层请求内容的方法,装置和系统 Download PDFInfo
- Publication number
- CN102055718B CN102055718B CN200910110054.2A CN200910110054A CN102055718B CN 102055718 B CN102055718 B CN 102055718B CN 200910110054 A CN200910110054 A CN 200910110054A CN 102055718 B CN102055718 B CN 102055718B
- Authority
- CN
- China
- Prior art keywords
- burst
- url
- client
- collection
- 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
Links
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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- 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
- 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
- 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/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
-
- 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/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- 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
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)
Abstract
本发明采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与多层次业务内容对应的URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的多层次业务内容的URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
Description
技术领域
本发明涉及一种在http streaming系统中实现分层请求内容的方法，装置和系统。
背景技术
用户使用终端设备获取多媒体内容并进行播放的方式有多种，典型的有通过HTTP文件下载或者P2P文件下载到本地磁盘后播放、传统的流媒体方式（数据传输的RTP/RTCP和播放控制RTSP）、P2P流媒体方式的在线直播/点播、HTTP渐进式下载（HTTP Progressive Download）等等。
HTTP渐进式下载则是对HTTP文件下载方式的一种改进，它可以让终端设备边下载边播放，而无需等到整个文件下载完成后才能够进行播放，播放启动时间也不太长。其实现原理是对媒体内容进行分片，一个（/一组）内容分片能够在终端设备进行独立解码，而不用依赖其他分片。这样，服务器和客户端之间每次只要传输一个（/一组）内容分片，终端设备接收到之后可以解码播放，同时还可接收下一个（/一组）内容分片。这种方式将媒体文件的处理粒度从整个文件调整为其中一个内容分片，典型的内容分片播放时长可以是几秒，例如1～10秒。
HTTP协议是无状态协议，基于HTTP协议构造的HTTP Streaming方案也因此能取得简单易实现的优点：每次的HTTP请求和响应都能构成一个与其他HTTP请求/响应独立的事务（transaction）。但这同时也对这种方案提出了这样的需求：每次为获得一个媒体内容分片，客户端需要主动向服务器发送一个HTTP请求，HTTP服务器为客户端的请求服务并返回包括相应内容分片的响应消息。
这样服务器在对媒体内容进行分片的时候，就需要衡量究竟应该如何分割多大（多少时长）的内容分片：
如果每个内容分片较大（时长较长），在启动播放和Seek操作时客户端需要较长时间来获取和缓冲内容分片。另外，由于HTTP协议没有取消机制，一旦开始传输内容分片就需要传输完（当然也可关闭TCP连接并重建TCP连接，但这样会引起额外负担），较长的分片时长也会影响码率切换响应的及时性，因为码率切换至少是以分片作为最小单位的；
如果每个内容分片较小（时长较短），那么客户端将需要频繁向服务器发起请求，较多的HTTP请求消息将使上行链路带宽占用增加，同时还会造成服务器处理请求的负担加重，以及每个HTTP响应中包括的有效媒体内容的降低，造成有效媒体传输率下降。
现有技术中，高通提出可以将多个连续的内容分片封装到一个分片集（Segment Aggregates）文件内，客户端可以获取完整的分片集，或者根据需要通过分片集的元数据来获得分片集中所包括分片在分片集内的分布情况和位置信息，并通过partial GET方式请求获取分片数据。
分片集（Segment Aggregates）是处于整个媒体内容和最基本组成内容分片两者之间的一种结构，以期获得比以前更大的灵活性。在这种情况下，客户端对媒体内容的获取流程可以概括如下图所示：
步骤1～2：客户端向服务器请求Media Presentation Description信息，获取必要的媒体元数据信息，并可借助这些信息产生后续的媒体内容请求；服务器向客户端返回描述信息，包括分片集层次的时间信息，以及能获取到分片集的URL信息，等；
步骤3～4：客户端按照描述信息中的分片集URL，用HTTP GET请求的方式请求相应的分片集；服务器收到这样的请求消息后，返回对应的分片集；
步骤5：如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，将确定所需请求的分片位于哪个分片集；
步骤6～7：客户端按照确定的分片集URL的，用partial GET请求的方式 请求分片集的初始部分（initial potion,描述分片集的元数据信息需要位于分片集的头部），可以先请求约1000个字节；服务器收到请求消息后，返回包括元数据信息的分片集初始部分（如果客户端所需要的元数据信息并没有包括在返回的响应消息中，客户端可以确定还需请求的字节范围并再发一个请求，服务器将把剩余的分片集元数据信息发送给客户端）；
步骤8：客户端解析并处理分片集的元数据信息，获得所需分片在分片集中的位置信息（起始位置和分片长度）；
步骤9～10：客户端利用分片集URL以及分片在分片集中的位置信息，采用partial GET的方式请求分片集内某个分片；服务器在响应消息中返回对应的分片数据。
上述步骤3～4、5～10发生的先后顺序视实际的播放过程而定，并可根据实际需要重复多次。
现有技术一为了获取分片集的元数据信息，以及分片集内所包括的内容分片，需要终端和服务器支持HTTP协议的partial GET操作,但目前存在部分服务器（特别是内容分发网络边缘的缓存服务器）或终端不能支持partialGET。如果内容分发网络边缘的缓存服务器不能支持partial GET，可能需要将收到的partial GET请求转发给服务器处理，将无法缓存该响应，并且会增加请求的响应时间；其次，客户端在需要请求分片时，首先要从服务器请求分片集的元数据，分析处理获得的元数据信息，在得到分片的位置信息之后才能构造相应的partial GET请求，处理效率较低。
但是，HTTP协议对于partial GET的支持并不是必须的，暂且不论互联网中已经广泛部署的HTTP服务器和缓存设备可能会包括较早的只支持HTTP1.0协议的服务器，就算在HTTP1.1协议RFC2616中，其对partial GET的规范部分有文字明确指出：“A server MAY ignore the Range header.”，并且也没有使用RFC中强制必须支持的“MUST”、“SHALL”或“SHOULD”，而只是给 出建议“ought to support byte ranges when possible”。因此采用partial GET方案，在某些网络环境中就可能会遇到不支持或不兼容的情况。
发明内容
一种在http streaming系统中实现分层请求内容的方法，包括，客户端向服务器发送业务信息获取请求；所述客户端接收所述服务器返回的包含媒体展现描述信息的业务信息获取请求响应，媒体展现描述信息中包含与多层次业务内容对应的URL和层次式URL的构造规则；当所述多层次业务内容中的分片集包括的分片的时长不是定长时，所述媒体展现描述信息中还包括统一的分片时间轴信息；所述客户端根据业务需求和媒体展现描述信息确定需请求的分片对应的分片集和分片集对应的URL；在所述分片集中包括的分片的时长不是定长时，根据所述统一的分片时间轴信息确定所述需请求的分片在所述分片集中对应的序号；所述客户端根据所述构造规则，所述分片集对应的URL以及所述需请求的分片在分片集中的序号构造所述需请求的分片对应的URL；所述客户端向所述服务器发送的业务请求消息GET消息，请求消息中包含所述客户端构造的URL；所述客户端接收所述服务器返回的业务请求消息响应，业务请求消息响应中包含与所述客户端构造的URL对应的业务内容；
一种在http streaming系统中实现分层请求内容的系统，包括，服务器，用于接收客户端发送的业务信息获取请求；向客户端返回包含媒体展现描述信息的业务信息获取请求响应，媒体展现描述信息中包含与业务内容对应的URL和层次式URL的构造规则；，当所述多层次业务内容中的分片集包括的分片的时长不是定长时，所述媒体展现描述信息中还包括统一的分片时间轴信息；接收客户端发送的业务请求消息GET消息，请求消息中包含客户端构造的URL；向客户端返回业务请求消息响应，业务请求消息响应中包含与客户端构造的URL对应的业务内容；客户端，用于向服务器发送业务信息获取请求；在获得服务器返回的媒体展现描述信息后，根据业务需求和所述媒体展现描述信息确 定需请求的分片对应的分片集和分片集对应的URL，在所述分片集中包括的分片的时长不是定长时，根据所述统一的分片时间轴信息确定所述需请求的分片在所述分片集中对应的序号，根据所述构造规则，所述分片集对应的URL以及所述需请求的分片在分片集中的序号构造所述需请求的分片对应的URL，向服务器发送包含构造的URL的业务请求消息GET消息，并接收服务器返回的包含与构造的URL对应的业务内容的业务请求消息响应。
附图说明
图1为现有技术中在SA方案下获取媒体内容的处理流程；
图2为本发明实施例提供的一种在http streaming系统中实现分层请求内容的方法的流程图；
图3为本发明实施例提供的对媒体内容进行层次式分片的示例图；
图4为本发明实施例提供的客户端的分片集请求处理流程图；
图5为本发明实施例提供的客户端的分片请求处理流程图；
图6为本发明实施例提供的服务器框图；
图7为本发明实施例提供的一种在http streaming系统中实现分层请求内容的系统的基本框图；
图8为本发明实施例提供的另一种在http streaming系统中实现分层请求内容的方法的基本流程图；
图9为本发明实施例提供的另一种在http streaming系统中实现分层请求内容的方法的基本流程图；
图10为本发明实施例提供的另一种在http streaming系统中实现分层请求内容的方法的基本流程图；
图11为本发明实施例提供的另一种在http streaming系统中实现分层请求 内容的方法的基本流程图；
图12为本发明实施例提供的客户端对分片触发事件的处理流程图；
图13为本发明实施例提供的另一种在http streaming系统中实现分层请求内容的方法的基本流程图；
图14为本发明实施例提供的客户端对分片触发事件的处理流程。
具体实施方式
为了使本领域的技术人员更好的理解本发明内容，以下结合附图以及具体实施例对本发明内容作具体说明。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的基本流程可参考图1，主要包括步骤：
A1、接收客户端发送的业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息。
A2、向客户端返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与业务内容对应的URL；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示：
表1
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括的相应时间段的数据内容不完全相同，只要所有连续的、对应于一个分片集的各个连续分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
A3、接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL；
客户端按照描述信息中的分片集URL，以及所需请求的分片集的时间信息，用HTTP GET请求的方式请求相应的分片集；服务器收到这样的请求消息后，返 回对应的分片集,客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL，具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
504、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息；客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
A4、向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容;
服务器收到该请求消息后，返回对应的内容分片。
本发明实时例采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种服务器的基本框图可参考图6，主要包括：
接收模块601，用于接收客户端发送的业务信息获取请求客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息；
业务信息发送模块602，用于向客户端返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与业务内容对应的URL；业务信息发送模块602向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示。
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示。
业务请求接收模块603，用于接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL；客户端按照描述信息中的分片集URL，以及所需请求的分片集的时间信息，用HTTP GET请求的方式请求相应的分片集；服务器收到这样的请求消息后，返回对应的分片集,客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片 集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
5、客户端等待服务器返回响应消息。
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL，具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现 描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
504、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息。。
业务内容发送模块604，用于向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容。
客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片；服务器收到该请求消息后，返回对应的内容分片。
所述服务器进一步包括，
分层模块605，用于将媒体资源至少分成以下播放单元，分片，分片集，段落。
分配模块606，至少用于为，分片，分片集，段落分配URL。
本发明实时例采用一种服务器，接收模块601接收客户端发送的业务信息获取消息，业务信息发送模块602向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，业务请求接收模块603接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，业务内容发送模块604向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种在http streaming系统中实现分层请求内容的系统的 基本框图可参考图7，主要包括：
服务器701，用于接收客户端702发送的业务信息获取请求；向客户端702返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与业务内容对应的URL；接收客户端702发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的分片URL；向客户端702返回业务请求消息响应，所述业务请求消息响应中包含与客户端702根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容；接收客户端702发送的业务信息获取请求客户端向服务器请求MediaPresentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息；向客户端702返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与业务内容对应的URL描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示：接收客户端702发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL；客户端702按照描述信息中的分片集URL，以及所 需请求的分片集的时间信息，用HTTP GET请求的方式请求相应的分片集；服务器收到这样的请求消息后，返回对应的分片集,
客户端702，用于向服务器701发送业务信息获取请求；在获得服务器701返回的包含与业务内容对应的URL媒体展现描述信息后，向所述服务器701发送包含根据业务需求和媒体展现描述信息确定的业务内容URL的业务请求消息GET消息。
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL，具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
504、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息。
本发明实时例采用一种在http streaming系统中实现分层请求内容的系统，服务器701接收客户端702发送的业务信息获取消息，服务器701向客户端702返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，服务器70接收客户端702发送的业务请求消息GET消息，所述请求消息中包含客户端702根据业务需求和媒体展现描述信息确定的业务内容URL，服务器701向客户端702返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的一个具体设施例参考图8，主要包括步骤：
801、客户端向服务器发送业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息
802、服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个 分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示：
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括的相应时间段的数据内容不完全相同，只要所有连续的、对应于一个分片集的各个连续分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
803、客户端向服务器发送GET消息请求分片集；
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
804、服务器向客户端返回对应的分片集；
805、分片请求触发事件；
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL
806、客户端向服务器发送GET消息请求分片内容；
具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间 信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
504、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息；客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
807、服务器向客户端返回对应的分片内容；
服务器收到该请求消息后，返回对应的内容分片。
本发明实时例采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的一个具体设施例参考图9，主要包括步骤：
901、客户端向服务器发送业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息
902、服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示：
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括的相应时间段的数据内容不完全相同，只要所有连续的、对应于一个分片集的各个连续分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
903、客户端向服务器发送GET消息请求业务内容；
这里需要判断并确定当前处理的分片的层次，获取与该层次相对应的URL信息。选择分片层次的可供考虑因素有用户选择、可用带宽情况、播放器缓存大小、对有效媒体内容负载率的需求、服务器策略，假设这里请求的是如图3所示的分片集
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但 是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
904、服务器向客户端返回对应的分片集；
905、分片请求触发事件；
向较低层次分片触发事件。这里要考虑的不仅仅只有分片触发事件，而是需要全局考虑所有向较低层次分片切换的事件（也即每个分片的时长需要变得更短，当然也包括了从分片集向分片切换的情形）。在相应的事件处理完成或者结束之后，需要有相应的处理或信息能告知步骤903，以便步骤903的处理能够确定后续所需请求的媒体分片内容的层次。这里以分片触发事件处理为例
906、客户端向服务器发送GET消息请求分片内容；
具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是 第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
504、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息；客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
907、服务器向客户端返回对应的分片内容；
服务器收到该请求消息后，返回对应的内容分片。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的一个具体设施例参考图10，主要包括步骤：
1001、客户端向服务器发送业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息，这里需要分别获得是音频和视频的元数据。
1002、服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的URL信息，这里媒体展现描述信息中分别包含音频和视频的URL信息，下面以音频为例，视频类似。
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个 分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的音视频内容分片URL可以如表2所示：
内容的URL。一个对应的内容分片URL实施例3可以组织如下：
表2
上表中，对每个段落的内容没有将音视频内容分开，当然也可以分开。
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括的相应时间段的数据内容不完全相同，只要所有连续的、对应于一个分片集的各个连续分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
1003、客户端向服务器发送GET消息请求分片集；
为了播放某个分片集时间段的媒体内容，需要分别发送音频分片集的HTTP GET请求和视频分片集的HTTP GET请求，两者处理和发送的先后次序并没有严格要求，只要能满足在请求分片集的播放时间点到来之前相应分片集的音频和视频内容已经就绪即可，下面以请求音乐分片集为例，
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率 信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
1004、服务器向客户端返回对应的分片集；
1005、分片请求触发事件；
这里需要确定所需请求视频分片的URL以及音频分片的URL，下面以音乐分片为例
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL。
1006、客户端向服务器发送GET消息请求分片内容；
具体的分片处理流程可参考图5：
501、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
502、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
503、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
4、客户端根据媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息，获取与该序号对应的分片URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片的URL时，还需要将分片的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到序号对应的分片URL信息；客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
1007、服务器向客户端返回对应的分片内容；
服务器收到该请求消息后，返回对应的内容分片。
本发明实时例采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的 URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的一个具体设施例参考图11，主要包括步骤：
1101、客户端向服务器发送业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息
1102、服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，以及较高层次的URL信息（只包括分片集层次的URL，但不包括最底层的分片的URL）；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表3所示：
表3
通过分片集1index URL，可以获取到如下的URL列表，如表4所示：
表4
或者，在音频内容和视频内容分开的情况下，通过分片集1视频index URL，
获取到如下的URL列表，如表5所示：
表5
通过分片集1音频index URL，获取到如下的URL列表：
表6
为获取分片集1所包括的所有分片的URL索引的分片集1index URL（或分片集1视频index URL/分片集1音频index URL）是可选的，即如果不包括的话，客户端需要知道如何获取分片集所包括的所有分片的URL索引，例如可以通过分片集的URL加相应参数构造的方案，一种可能的实施例如下：
构造：分片集1index URL=分片集1URL?id=segmentIndex
或者层次式URL：
分片集1index URL=分片集1URL/segmentIndex
1103、客户端向服务器发送GET消息请求分片集；
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片 集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
1104、服务器向客户端返回对应的分片集；
1105、分片请求触发事件；
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL，详细处理流程如图12所示：
1201、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则 转到相应的分片集请求处理流程，否则继续下面步骤；
1202、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
1203、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
1204、判断媒体展现描述信息中是否包括了分片集索引URL，如果包括则继续下面步骤5，否则跳转到步骤6；
1205、由于媒体展现描述信息包括了与各层次分片对应的分片集URL以及分片集索引URL信息，可以直接获取与该序号对应的分片集索引URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片集索引URL时，还需要将分片集的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到与序号对应的分片集索引URL；
1206、由于媒体展现描述信息中没有包括分片集的索引URL信息，客户端按照和服务器协商一致的来构造所需的分片集索引URL，这种构造规则可以在描述信息中给出，例如可以通过对分片集URL信息加上额外的参数构造，这个附加的参数也需在描述信息中给出。
1106、客户端向服务器发送GET消息请求分片内容；
客户端利用上述图12得到的分片集索引URL，构造相应的HTTP GET请求；；客户端将构造得到的HTTP GET请求消息发送给服务器；服务器返回与相应的分片URL列表索引，也即在分片集中所包括的每个分片的URL按顺序排列的列表；客户端接收服务器发送的响应消息，获得分片集索引信息，即分片的URL列表；客户端根据分片在分片集中的序号，以及分片URL列表，确定所需请求的分片的URL信息；客户端利用上述步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
1107、服务器向客户端返回对应的分片内容；
服务器收到该请求消息后，返回对应的内容分片。
本发明实时例采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本发明实施例的一种在http streaming系统中实现分层请求内容的方法的一个具体设施例参考图13，主要包括步骤：
1301、客户端向服务器发送业务信息获取请求；
客户端向服务器请求Media Presentation Description信息，以获取必要的媒体元数据，这里的元数据即为资源描述信息
1302、服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息，描述信息中需包括各级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息，描述信息中需包括层次式URL的构造规则，客户端可以根据该构造规则并利用 上级资源的URL直接构造其下一级资源的URL；
在提供媒体描述信息时，如果同一层次（粒度）的分片在时长上完全相同，则只需要提供不同层次分片的时长信息（可选的，还有所包括的下一层内容分片的数目），如每个分片集1分钟（包括30个分片，或10秒包括10个分片，或30秒包括15个分片等）、分片2秒（或1秒）。对于按照定长进行内容分片的情况，如果最后一个段落或分片集跟前面同层次的分片在时长上不一样，需单独提供针对性的描述信息。如果同层次（粒度）的分片在时长上不完全相同，则需要提供一份统一的、有关整个媒体内容分片情况的时间轴信息。一个定长分片的实施例如图3所示：
在图3中每个分片集的时长可以相同，或者不同；同样，分片集中每个分片的时长可以相同，或者不同。相应的，与这个按照层次式进行内容分片实施例相对应的内容分片URL可以组织如表1所示：
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括的相应时间段的数据内容不完全相同，只要所有连续的、对应于一个分片集的各个连续分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
1303、客户端向服务器发送GET消息请求分片集；
客户端的分片集请求处理流程参考图4：
401、客户端判断是否无分片请求触发事件，若有分片请求触发事件，则转到相应的分片触发事件处理流程，否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的URL。如果是分片集的时长是定长的，可根据需请求分片集的时间信息除以每个分片集的时长信息，得到分片集的序号（例如每个分片集时长为30秒，要请求距开始20分钟的分片集，则为第41个分片集）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息确定所需请求分片集的序号。根据分片集的序号，从媒体展现描述信息中所包括的与各层次分片 对应的完整的URL信息获取与该序号对应的分片集URL。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需将分片集的序号和码率信息结合起来，即下一个要请求的分片集应该是什么码率的，并在相应的码率下获取与序号对应的分片集URL；
403、客户端基于获得的分片集URL，构造相应的HTTP GET请求消息；
404、客户端将上述HTTP GET请求消息发送给服务器；
具体处理流程与服务器实现和内容部署相关，可以支持不同的部署实现方式：
(a)、每个分片集URL对应于一个存储的静态的分片集文件（例如每个分片集可存储为一个.3gp文件或.mp4文件），服务器根据分片集URL直接获取与之相对应的分片集文件，封装在HTTP响应消息中并发送给客户端；
(b)、每个分片集URL所对应的分片集内容是静态的，即不同客户端发出由相同分片集URL构造的HTTP请求消息，所获得的分片集内容是完全相同的。但是多个分片集可以连续存放在同一个较大的文件内，由服务器根据URL信息映射出分片集在所处大文件中的位置和长度信息，并在服务于客户端请求时动态地从存放多个分片集的文件内提取所需的分片集内容，封装在HTTP响应消息中并发送给客户端；
405、客户端等待服务器返回响应消息。
1304、服务器向客户端返回对应的分片集；
1305、分片请求触发事件；
如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确定所需请求分片的URL如果有分片请求触发事件（如刚启动播放、Seek操作、带宽变动导致需要进行码率切换等）发生，客户端将根据媒体展现描述信息以及请求的时间点确定所需请求的分片位于哪个分片集，以及在分片集中的序号，进而确 定所需请求分片的URL，详细处理流程如图14所示：
1401、客户端判断是否有分片请求触发事件，若无分片请求触发事件，则转到相应的分片集请求处理流程，否则继续下面步骤；
1402、客户端根据描述信息和需请求分片的时间信息，确定所需请求分片所对应的分片集。如果是分片集的时长是定长的，可根据需请求分片集的时间信息以及每个分片集的时长信息，得到相应分片集的序号（例如每个分片集时长为30秒，要请求距开始30分12秒的分片，则是第61个分片）；如果分片集的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及分片所落在分片集的时间范围中这点，来确定所需请求分片集的序号；
1403、如果上述确定的分片集中所包括的分片的时长是定长的，可根据该分片集的时长以及每个分片的时长信息（或者该分片集所包括的下一级分片数目），得到相应分片的序号（例如该分片集时长为30秒，分片的时长为2秒（或者该分片集中包括了15个分片）要请求的分片距开始分片集开头12秒，则是第7个分片）；如果该分片集包括的分片的时长不是定长的，可根据媒体展现描述信息中统一的分片时间轴信息，以及请求分片的时间点信息，来确定所需请求分片在对应分片集中的序号；
1404、根据分片所对应的分片集的序号，以及媒体展现描述信息中所包括的分片集的URL，确定对应的分片集的URL信息。如果HTTP Streaming方案支持动态码率切换，则在确定分片集的URL时，还需要将分片集的序号和码率信息结合起来，即下一个要请求的分片应该是多少码率的，并在相应的码率下获取到与序号对应的分片集URL；
1405、客户端根据媒体描述信息中包括的层次式URL的构造规则、分片集的URL信息，以及分片在对应分片集中的序号，直接构造对应的分片URL。
例如，如果码率为400K的第100个内容分片集的URL如下所示：http://HDvideo.foo.com/NBA.3gp/QualityLevels(400000)/SegmentAggrega tes(100)
在获取的媒体展现描述信息中，如果URL构造规则为在分片集URL的基础上再增加“/Segment(分片序号)”，则可以构造出分片的URL如下：
http://HDvideo.foo.com/NBA.3gp/QualityLevels(400000)/SegmentAgg regates(100)/Segment(X)
这里X为上述步骤3中所确定的分片在对应分片集中的序号。
1306、客户端向服务器发送GET消息请求分片内容；
客户端利用上述1405步骤获得的分片URL，构造HTTP GET请求消息，并发送给服务器以请求相应的内容分片。
1307、服务器向客户端返回对应的分片内容；
服务器收到该请求消息后，返回对应的内容分片。
本发明实时例采用一种在http streaming系统中实现分层请求内容的方法，接收客户端发送的业务信息获取消息，向客户端返回包含媒体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对应的URL，接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容URL，向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容URL对应的业务内容，使得在查找内容时可直接根据URL进行查找，提高了处理效率。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。
以上对本发明实施例所提供的限制主叫用户呼叫的方法、系统和装置，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
Claims (2)
1.一种在http streaming系统中实现分层请求内容的方法，其特征在于：
客户端向服务器发送业务信息获取请求；
所述客户端接收所述服务器返回的包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与多层次业务内容对应的URL和层次式URL的构造规则；当所述多层次业务内容中的分片集包括的分片的时长不是定长时，所述媒体展现描述信息中还包括统一的分片时间轴信息；
所述客户端根据业务需求和媒体展现描述信息确定需请求的分片对应的分片集和分片集对应的URL；
在所述分片集中包括的分片的时长不是定长时，根据所述统一的分片时间轴信息确定所述需请求的分片在所述分片集中对应的序号；
所述客户端根据所述构造规则，所述分片集对应的URL以及所述需请求的分片在分片集中的序号构造所述需请求的分片对应的URL；
所述客户端向所述服务器发送的业务请求消息GET消息，所述请求消息中包含所述客户端构造的URL；
所述客户端接收所述服务器返回的业务请求消息响应，所述业务请求消息响应中包含与所述客户端构造的URL对应的业务内容。
2.一种在http streaming系统中实现分层请求内容的系统，其特征在于，所述系统包括，
服务器，用于接收客户端发送的业务信息获取请求；向客户端返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与多层次业务内容对应的URL和层次式URL的构造规则，当所述多层次业务内容中的分片集包括的分片的时长不是定长时，所述媒体展现描述信息中还包括统一的分片时间轴信息；接收客户端发送的业务请求消息GET消息，所述请求消息中包含客户端构造的URL；向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端构造的URL对应的业务内容；
客户端，用于向服务器发送业务信息获取请求；在获得服务器返回的所述媒体展现描述信息后，根据业务需求和所述媒体展现描述信息确定需请求的分片对应的分片集和分片集对应的URL，在所述分片集中包括的分片的时长不是定长时，根据所述统一的分片时间轴信息确定所述需请求的分片在所述分片集中对应的序号，根据所述构造规则，所述分片集对应的URL以及所述需请求的分片在分片集中的序号构造所述需请求的分片对应的URL；向所述服务器发送包含构造的URL的业务请求消息GET消息，并接收服务器返回的包含与构造的URL对应的业务内容的业务请求消息响应。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910110054.2A CN102055718B (zh) | 2009-11-09 | 2009-11-09 | 一种在http streaming系统中实现分层请求内容的方法,装置和系统 |
| EP10827933.2A EP2493191B1 (en) | 2009-11-09 | 2010-11-08 | Method, device and system for realizing hierarchically requesting content in http streaming system |
| PCT/CN2010/078518 WO2011054319A1 (zh) | 2009-11-09 | 2010-11-08 | 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统 |
| US13/467,738 US20120221681A1 (en) | 2009-11-09 | 2012-05-09 | Method, apparatus and system for hierarchically requesting contents in a http streaming system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910110054.2A CN102055718B (zh) | 2009-11-09 | 2009-11-09 | 一种在http streaming系统中实现分层请求内容的方法,装置和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102055718A CN102055718A (zh) | 2011-05-11 |
| CN102055718B true CN102055718B (zh) | 2014-12-31 |
Family
ID=43959653
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910110054.2A Active CN102055718B (zh) | 2009-11-09 | 2009-11-09 | 一种在http streaming系统中实现分层请求内容的方法,装置和系统 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20120221681A1 (zh) |
| EP (1) | EP2493191B1 (zh) |
| CN (1) | CN102055718B (zh) |
| WO (1) | WO2011054319A1 (zh) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102202094A (zh) * | 2011-05-13 | 2011-09-28 | 中兴通讯股份有限公司 | 一种基于http的业务请求处理方法及装置 |
| CN102394880B (zh) * | 2011-10-31 | 2014-07-30 | 北京蓝汛通信技术有限责任公司 | 内容分发网络中的跳转响应处理方法和设备 |
| US8850054B2 (en) * | 2012-01-17 | 2014-09-30 | International Business Machines Corporation | Hypertext transfer protocol live streaming |
| EP2988516B1 (en) * | 2013-04-19 | 2019-09-25 | Sony Corporation | Server device, client device, content distribution method, and computer program |
| CN105379293B (zh) * | 2013-04-19 | 2019-03-26 | 华为技术有限公司 | 基于超文本协议的动态自适应流媒体中的媒体质量信息指示 |
| WO2015013687A1 (en) * | 2013-07-25 | 2015-01-29 | Futurewei Technologies, Inc. | System and method for effectively controlling client behavior in adaptive streaming |
| US11201908B2 (en) * | 2014-02-05 | 2021-12-14 | Seon Design (Usa) Corp. | Uploading data from mobile devices |
| CN103986976B (zh) * | 2014-06-05 | 2017-05-24 | 北京赛维安讯科技发展有限公司 | 基于cdn网络的传输系统及方法 |
| CN105704185B (zh) * | 2014-11-27 | 2019-04-12 | 华为软件技术有限公司 | 资源转移方法及装置 |
| KR102454470B1 (ko) * | 2016-10-06 | 2022-10-14 | 삼성전자주식회사 | 스트리밍 서비스를 지원하는 방법 및 장치 |
| CN109413509A (zh) * | 2018-12-06 | 2019-03-01 | 武汉微梦文化科技有限公司 | 一种高清视频处理方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1902865A (zh) * | 2003-11-07 | 2007-01-24 | 诺基亚有限公司 | 从服务器到客户的流式传输 |
| CN101287107A (zh) * | 2008-05-29 | 2008-10-15 | 腾讯科技（深圳）有限公司 | 媒体文件的点播方法、系统和设备 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9386064B2 (en) * | 2006-06-09 | 2016-07-05 | Qualcomm Incorporated | Enhanced block-request streaming using URL templates and construction rules |
| CN101193273B (zh) * | 2006-11-20 | 2010-07-14 | 中兴通讯股份有限公司 | 一种实时多媒体图像信息存储和播放方法 |
| US8914835B2 (en) * | 2009-10-28 | 2014-12-16 | Qualcomm Incorporated | Streaming encoded video data |
-
2009
- 2009-11-09 CN CN200910110054.2A patent/CN102055718B/zh active Active
-
2010
- 2010-11-08 EP EP10827933.2A patent/EP2493191B1/en active Active
- 2010-11-08 WO PCT/CN2010/078518 patent/WO2011054319A1/zh active Application Filing
-
2012
- 2012-05-09 US US13/467,738 patent/US20120221681A1/en not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1902865A (zh) * | 2003-11-07 | 2007-01-24 | 诺基亚有限公司 | 从服务器到客户的流式传输 |
| CN101287107A (zh) * | 2008-05-29 | 2008-10-15 | 腾讯科技（深圳）有限公司 | 媒体文件的点播方法、系统和设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP2493191A1 (en) | 2012-08-29 |
| EP2493191A4 (en) | 2012-08-29 |
| CN102055718A (zh) | 2011-05-11 |
| WO2011054319A1 (zh) | 2011-05-12 |
| US20120221681A1 (en) | 2012-08-30 |
| EP2493191B1 (en) | 2015-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102055718B (zh) | 一种在http streaming系统中实现分层请求内容的方法,装置和系统 | |
| JP6944485B2 (ja) | １つの要求メッセージに基づいたネットワーク・ノードへの多数のチャンクの要求 | |
| CN108063769B (zh) | 一种内容服务的实现方法、装置及内容分发网络节点 | |
| CN106060102B (zh) | 媒体提供方法和终端 | |
| US20140165119A1 (en) | Offline download method, multimedia file download method and system thereof | |
| CN104125229B (zh) | 流媒体的播放方法与播放装置 | |
| TW201021573A (en) | Proxy functionality | |
| CN102694831B (zh) | 移动终端流媒体数据补偿方法与系统、内容分发网络 | |
| US20140074961A1 (en) | Efficiently Delivering Time-Shifted Media Content via Content Delivery Networks (CDNs) | |
| CN103813185B (zh) | 一种分段节目快速分发的方法、服务器及客户端 | |
| US8817983B2 (en) | Streaming video to cellular phones | |
| US20160134900A1 (en) | Streaming media processing method, apparatus, and system | |
| US20040010613A1 (en) | Storage and distribution of segmented media data | |
| CN101662658B (zh) | 节目推送方法、机顶盒及电子节目菜单 | |
| CN110933517A (zh) | 码率切换方法、客户端和计算机可读存储介质 | |
| WO2015192683A1 (zh) | 一种基于码流自适应技术的内容分发方法、装置及系统 | |
| US20210021655A1 (en) | System and method for streaming music on mobile devices | |
| EP3310065B1 (en) | Receiving device, transmission device and data processing method | |
| CN106604077B (zh) | 自适应流媒体传输方法及装置 | |
| CN102439935B (zh) | 媒体适配的方法和装置 | |
| KR20170141677A (ko) | 수신 장치, 송신 장치 및 데이터 처리 방법 | |
| CN117596232A (zh) | 流媒体快速启动方法、装置和系统 | |
| CN107925798A (zh) | 接收设备、发送设备和数据处理方法 | |
| WO2017114393A1 (zh) | Http流媒体传输方法及装置 | |
| WO2017071524A1 (zh) | 多媒体资源的发布方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |