CN105100172B - 一种http协议的缓存状态更新方法和设备、处理机 - Google Patents

一种http协议的缓存状态更新方法和设备、处理机 Download PDF

Info

Publication number
CN105100172B
CN105100172B CN201410218849.6A CN201410218849A CN105100172B CN 105100172 B CN105100172 B CN 105100172B CN 201410218849 A CN201410218849 A CN 201410218849A CN 105100172 B CN105100172 B CN 105100172B
Authority
CN
China
Prior art keywords
buffer status
request
http
caching
caching event
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
CN201410218849.6A
Other languages
English (en)
Other versions
CN105100172A (zh
Inventor
陈兵
高山
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201410218849.6A priority Critical patent/CN105100172B/zh
Priority to EP14892670.2A priority patent/EP3101871B1/en
Priority to PCT/CN2014/088370 priority patent/WO2015176470A1/zh
Publication of CN105100172A publication Critical patent/CN105100172A/zh
Priority to US15/248,603 priority patent/US10003999B2/en
Application granted granted Critical
Publication of CN105100172B publication Critical patent/CN105100172B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • 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/40—Support for services or applications
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4333—Processing operations in response to a pause request
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/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/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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/355—Application aware switches, e.g. for 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]

Abstract

本发明实施例提供了一种基于超文本传输协议HTTP的缓存状态更新方法，所述方法包括：接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态。根据本发明实施例的缓存状态更新的方法，通过只分析HTTP协议字段的方式实现了基于缓存事件的对缓存状态的更新，使得缓存模型更加接近真实的客户端缓存情况。本发明实施例还提供了一种基于HTTP协议的缓存状态更新设备和一种基于HTTP协议的缓存状态处理机。

Description

一种HTTP协议的缓存状态更新方法和设备、处理机
技术领域
本发明涉及通信传输技术，尤其涉及一种一种HTTP协议的缓存状态更新方法和设备、处理机。
背景技术
在互联网协议(Internet Protocol，简称为IP)网络的音视频应用中，为了平滑网络传输带来的影响及实现收发端的同步播放，收端需要把接收到的音视频数据暂存于缓存中，以保证音视频数据在通过IP网络传输后仍能连续播放。缓存的设计需要综合考虑缓存带来的延迟和丢包，缓存过小可能引起过多的丢包，缓存过大可能造成播放的延迟过大，由此可见，收端的缓存状态会直接影响音视频的播放质量，因此，通过估计缓存的状态对音视频的播放质量进行评估等变得尤为重要。
现有技术主要是针对实时传输协议(Real-time Transport Protocol，简称为RTP)/用户数据包协议(User Datagram Protocol，简称为UDP)场景下的缓存进行建模，以便于通过估计缓存的状态对音视频的播放质量进行评估等操作。目前，基于传输控制协议(Transmission Control Protocol，简称为TCP)的音视频应用越来越多。
当前IP网络中的音视频应用都会在接收端使用缓存，缓存可以在很大程度上平滑网络抖动对应用的影响，继而缓存的表现可以反应这些应用的端到端性能。
为了平滑网络传输带来的影响和同步发端和收端的播放，收端需要把接收到的数据暂存在缓存中。缓存的主要作用是计算网络的抖动，按照解码的需要，提供音视频数据。这样的缓存被称为抖动缓存(de-jitter buffer)，保证音视频在通过网络传输后仍能够连续播放。de-jitter buffer的设计需要综合考虑缓存带来的延迟和丢包，缓存过小可能引起过多的丢包，太大可能造成播放延迟过大。
终端缓冲状态直接影响主观质量评估的结果，对各种缓存建模是主观质量评估必不可少的步骤。
缓存事件，例如拖动、暂停、重新播放、码流切换，会直接影响缓冲状态，为了准确更新缓存状态，必须准确的确定缓存事件。
现有技术中，通过对音频/视频数据流和显示时间标签(Presentation TimeStamp，PTS)实现缓存事件的判断；如果没有新的音频/视频数据流到达，则发生暂停；在发生暂停后，有新的音频/视频数据流到达，则发生重新播放；如果音频/视频数据流的PTS发生跳变，则发生拖动。
现有方法通过对音频/视频数据流和PTS判断缓存事件，需要解析媒体文件得到PTS，在某些情况下，如数据加密，海量用户并发，无法实现或者很难实时实现。
发明内容
有鉴与此，为解决上述问题，本发明的实施例提供了一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新方法。根据本发明实施例的缓存状态更新方法，通过只分析HTTP协议字段的方式实现了基于缓存事件的对缓存状态的确定，使得缓存模型更加接近真实的客户端缓存情况。
本发明第一方面的实施例公开了一种基于超文本传输协议(HyperText TransferProtocol，HTTP)的缓存状态更新方法，所述方法包括：
接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；
根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态。
根据本发明实施例的缓存状态更新方法，通过只分析HTTP协议字段的方式实现了基于缓存事件的对缓存状态的更新，使得缓存模型更加接近真实的客户端缓存情况。
结合本发明第一方面实施例的本发明第一方面实施例第一种可能实现的方式中，所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自终端的当前GET请求，其中，接收所述当前GET请求的时间为t；
若在以t为起始的预设时间内没有接收到来自所述终端的后一GET请求，则触发所述暂停；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述暂停，将所述缓存状态设为所述停止播放状态。
结合本发明第一方面实施例第一种可能实现的方式的本发明第一方面实施例第二种可能实现的方式中，在所述触发暂停之后，如果接收到来自所述终端的后一GET请求，所述方法还包括：
根据所述后一GET请求触发所述重新播放；
根据所述重新播放，将所述缓存状态设为所述正常播放状态。
结合本发明第一方面实施例第二种可能实现的方式的本发明第一方面实施例第三种可能实现的方式中，所述当前GET请求中包括当前码流指示符，所述后一GET请求中包括后一码流指示符；
若所述当前码流指示符和所述后一码流指示符不同，在接收到来自所述终端的后一GET请求后，所述方法还包括：
触发所述码流切换；
根据所述码流切换，将所述缓存状态设为所述码流切换状态。
结合本发明第一方面实施例上述任一种可能实现的方式的本发明第一方面实施例第四种可能实现的方式中，所述方法还包括：
根据所述当前GET请求中的关键字，确定是否触发所述拖动；
若确定触发所述拖动，则根据所述拖动，将所述缓存状态设为所述再缓冲状态。
结合本发明第一方面实施例第四种可能实现的方式的本发明第一方面实施例第五种可能实现的方式中，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的rang值与来自所述终端的前一GET请求的range值的差大于预设阈值，则触发所述拖动。
结合本发明第一方面实施例第四种可能实现的方式的本发明第一方面实施例第六种可能实现的方式中，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的ts_start值与来自所述终端的前一GET请求的ts_start值差大于预设阈值且所述当前GET请求中的ts_end值与来自所述终端的前一GET请求的ts_end值的差大于所述预设阈值，则触发所述拖动。
结合本发明第一方面实施例第四种可能实现的方式的本发明第一方面实施例第七种可能实现的方式中，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的begin值与来自所述终端的前一GET请求的begin值的差大于预设阈值，则触发所述拖动。
结合本发明第一方面实施例的本发明第一方面实施例第八种可能实现的方式中，
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第一GET请求，根据所述第一GET请求中的关键字，触发所述拖动；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述拖动，将所述缓存状态设为所述再缓冲状态。
结合本发明第一方面实施例的本发明第一方面实施例第九种可能实现的方式中，
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第二GET请求，根据所述第二GET请求触发所述重新播放；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述重新播放，将所述缓存状态设为所述正常播放状态。
结合本发明第一方面实施例的本发明第一方面实施例第十种可能实现的方式中，
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第三GET请求，所述第三请求包括码流指示符；
若所述码流指示符与来自所述终端的前一码流指示符不同，则触发所述码流切换；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述码流切换，将所述缓存状态设为所述码流切换状态。
本发明第二方面的实施例公开了一种基于超文本传输协议(HyperText TransferProtocol，HTTP)的缓存状态更新设备，所述设备包括：接收模块，用于接收来自终端的HTTP请求；触发模块，用于根据所述HTTP请求触发缓存事件；缓存状态模块，用于根据所述缓存事件，更新缓存状态；其中，所述缓存事件包括拖动、暂停、重新播放、码流切换，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态。
根据本发明实施例的缓存状态更新设备，通过只分析HTTP协议字段的方式实现了基于缓存事件的对缓存状态的更新，使得缓存模型更加接近真实的客户端缓存情况。
结合本发明第二方面实施例的本发明第二方面实施例第一种可能实现的方式中，所述接收模块具体用于接收来自所述终端的当前GET请求，其中，接收所述当前GET请求的时间为t；
所述触发模块具体用于在以t为起始的预设时间内没有接收到来自所述终端的后一GET请求时，触发暂停；
所述缓存状态模块具体用于根据所述暂停，将缓存状态设为停止播放状态。
结合本发明第二方面实施例第一种可能实现的方式的本发明第二方面实施例第二种可能实现的方式中，所述接收模块还用于接收所述后一GET请求；相应的，所述触发模块还用于根据所述后一GET请求触发所述重新播放；所述缓存状态模块还用于根据所述重新播放，将所述缓存状态设为正常播放状态。
结合本发明第二方面实施例第一种可能实现的方式或本发明第二方面实施例第二种可能实现的方式的本发明第二方面实施例第三种可能实现的方式中，所述触发模块还用于触发所述码流切换，所述缓存状态模块还用于根据所述码流切换，将所述缓存状态设为码流切换状态。
结合本发明第二方面实施例上述任一种可能实现的方式的本发明第二方面实施例第四种可能实现的方式中，所述触发模块还用于根据所述当前GET请求中的关键字，触发所述拖动；所述缓存状态模块还用于根据所述拖动，将所述缓存状态设为再缓冲状态。
结合本发明第二方面实施例的本发明第二方面实施例第五种可能实现的方式中，
所述接收模块具体用于接收来自所述终端的第四GET请求；
所述触发模块具体用于根据所述第四GET请求中的关键字，触发所述拖动；
所述缓存状态模块具体用于根据所述拖动，将所述缓存状态设为再缓冲状态。
结合本发明第二方面实施例的本发明第二方面实施例第六种可能实现的方式中，
所述接收模块具体用于接收来自所述终端的第五GET请求；
所述触发模块具体用于根据所述第五GET请求触发所述重新播放；
所述缓存状态模块具体用于根据所述重新播放，将所述缓存状态设为所述正常播放状态。
结合本发明第二方面实施例的本发明第二方面实施例第七种可能实现的方式中，
所述接收模块具体用于来自所述终端的第六GET请求，所述第六请求包括码流指示符；
所述触发模块具体用于根据所述码流指示符，触发所述码流切换；
所述缓存状态模块具体用于根据所述码流切换，将所述缓存状态设为所述码流切换状态。
本发明第三方面的实施例公开了一种基于超文本传输协议(HyperText TransferProtocol，HTTP)的缓存状态处理机，其中，缓存事件包括拖动、暂停、重新播放和码流切换，缓存状态包括再缓冲状态、正常播放状态、停止播放状态和码流切换状态，所述缓存状态处理机用于：
获得所述缓存事件；
当所述缓存事件为暂停时，进入停止播放状态，
当所述缓存事件为重新播放时，进入正常播放状态，
当所述缓存事件为拖动时，进入再缓冲状态，
当所述事件为码流切换时，进入码流切换状态。
根据本发明实施例的缓存状态处理机，通过只分析HTTP协议字段的方式实现了基于缓存事件的对缓存状态的更新，使得缓存模型更加接近真实的客户端缓存情况。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例的一种基于HTTP协议的缓存状态更新方法的流程示意图。
图2为本发明实施例的一种基于HTTP协议的缓存状态更新设备的结构示意图。
图3为本发明实施例的HTTP流传输的整体框架示意图。
图4为本发明实施例的HTTP流传输的硬件实现的示意图。
图5为本发明实施例的HTTP报文的格式示意图。
图6为本发明实施例的缓存事件和缓存状态转换的示意图。
图7为本发明实施例的GET请求中含有的关键字的取值的具体示例。
图8为本发明另一实施例的GET请求中含有的关键字的取值的具体示例。
图9为本发明实施例的一种具体应用的示意图。
图10为本发明实施例的一种基于HTTP协议的缓存状态处理机的示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
超文本传输协议(英文：HyperText Transfer Protocol，缩写：HTTP)是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符(Uniform ResourceIdentifiers，URI)来标识。HTTP的发展是万维网协会(World Wide Web Consortium，W3C)和互联网工程任务组(Internet Engineering Task Force，IETF)合作的结果,1999年6月公布的RFC2616定义了HTTP协议中现今广泛使用的一个版本—HTTP1.1。
图3说明了基于HTTP的媒体内容流播系统300，该系统可实现本发明的概念及方法。系统300具有可通过IP网络304将流播媒体传输至HTTP客户端306的HTTP流播服务器302。这应理解为，其它实施例也可适用于HTTP流播系统之外的其它流播系统。
图4说明经自适应而可使用本发明实施例的计算机系统400，例如，存储和/或运行与实施例相关的软件。中央处理器(CPU)401与系统总线402相耦合。CPU401可为一般用途的CPU。但是只要CPU401支持本文所述的创造性操作，本发明的实施例则不受限于CPU401的架构。总线402与随机存取存储器(RAM)403相耦合，后者可为SRAM、DRAM或SDRAM。诸如PROM、EPROM或EEPROM等ROM404也可与总线402相耦合。RAM403和ROM404存储本领域内常见的用户及系统数据和程序。
总线402也与输入/输出(I/O)适配器405、通信适配器411、用户接口408和多媒体适配器409相耦合。I/O适配器405将存储设备406，例如以下驱动器中的一种或多种：一个硬盘驱动器、一个CD驱动器、一个软盘驱动器、一个磁带驱动器，连接至计算机系统400。I/O适配器405还可连接至打印机(未显示)，后者有利于系统打印诸如文件、照片、文章等信息的纸质副本。注意：打印机可为点阵式打印机、激光打印机等打印机、传真机、扫描仪或影印机。用户接口适配器与键盘413和鼠标407及其它设备相耦合。在某些实施例中其可为显示器和/或音频卡的多媒体适配器409连接至显示设备410和音频设备415。显示设备410可为CRT、平板显示器或其它类型的显示设备，而音频设备415可为扬声器、耳机或其它模拟或数字音频系统。
在某些实施例中，HTTP流播指代基于HTTP协议的多媒体内容的流播。3GPP版本4及以上版本支持流播分发。3GPP TS26.234具体说明了基于RTSP over UDP协议和RTP overUDP协议的流播分发，本发明实施例提供的基于HTTP协议的缓存更新的方法主要是基于HTTP协议和RTP协议的。HTTP流播成为了互联网视频分发的主要形式，而且将HTTP用作多媒体分发的主要协议，已成为趋势。在其它实施例中，可采用其它流播系统及标准。
HTTP流播得到广泛应用的技术原因包括：可使用标准服务器和标准HTTP缓存(或一般而言较廉价的服务器)来分发内容，以便能从内容分发网络(CDN，Content DeliveryNetwork)或其它任何标准服务器集群分发内容；能将对“流播会话”的控制整体转移至客户端，后者基本上仅打开一个或几个与一个或几个标准HTTP服务器相连的TCP接口。HTTP流播之所以广为应用的原因还在于，它能克服防火墙穿越问题，从而简单且轻松地提供流播服务。
HTTP流播的一种方法称为静态内容服务模式。在此模式中，使用标准HTTP服务器无需任何扩展。以一个文件或一组文件的形式提供内容，此类文件可从HTTP服务器获取。客户端通过访问使用HTTP GET请求而具有或未具有字节范围的文件来获取内容。
本发明实施例利用音频和/或视频和/或其它媒体类型多媒体流的HTTP流播技术的系统及方法。此类系统及方法可灵活且有效地支持基于存储方法，媒体展现描述(MediaPresentation Description,MPD),以及具有或未具有字节范围的HTTP GET请求的点播及直播技术。在MPD中，可包括媒体片断的字节范围和时间范围，以便客户端能高效地请求仅使用字节范围的媒体片断。MPD可包括媒体其它展现的更多编解码信息，以支持采用一种以上编码配置而进行编码的媒体内容。
HTTP是一个客户端终端(用户)和服务器端(网站)请求和应答的标准。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口(默认端口为80)。我们称这个客户端为用户代理程序。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个“中间层”，比如代理、网关或者隧道。
尽管TCP/IP协议是互联网上最流行的应用，HTTP协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。
通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1200OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。
HTTP/1.1协议中共定义了八种方法(也叫“动作”)来以不同方式操作指定的资源：
OPTIONS：这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用'*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。
HEAD：与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部份。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”(元信息或称元数据)。
GET：向指定的资源发出“显示”请求。GET方法意思是获取被请求URI(Request-URI)指定的信息(以实体的格式)。如果请求URI涉及到一个数据生成过程，那么这个过程生成的数据应该被作为实体在响应中返回而不是过程的源文本，除非源文本恰好是过程的输出。如果请求消息包含If-Modified-Since,If-Unmodified-Since，If-Match，If-None-Match或者If-Range头域，GET的语义将变成“条件(conditionall)GET”。一个条件GET方法会请求满足条件头域的实体。条件GET方法的目的是为了减少不必要的网络使用，这通过允许利用缓存里仍然保鲜的实体而不用多次请求或传输客户端已经拥有的实体来实现的。
如果请求方法包含一个Range头域，那么GET方法就变成“部分Get”(partial GET)方法。一个部分GET会请求实体的一部分。部分GET方法的目的是为了减少不必要的网络使用，可以允许客户端从服务器获取实体的部分数据，而不需要获取客户端本地已经拥有的部分实体数据。
POST：向指定资源提交数据，请求服务器进行处理(例如提交表单或者上传文件)。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。
PUT：向指定资源位置上传其最新内容。
DELETE：请求服务器删除Request-URI所标识的资源。
TRACE：回显服务器收到的请求，主要用于测试或诊断。
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器)。
下面结合图5描述根据本发明实施例的HTTP报文的格式。
HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。HTTP有两类报文：请求报文和响应报文。
请求报文，一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成，图5给出了请求报文的一般格式。
(1)请求行。
请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET/index.html HTTP/1.1。
HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。
GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号(“？”)代表URL的结尾与请求参数的开始，传递参数长度受限制。例如，
/index.jsp？id＝100&op＝bind。
POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，可用来传送文件。
(2)请求头部。
请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
(3)空行。
最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。
对于一个完整的http请求来说空行是必须的，否则服务器会认为本次请求的数据尚未完全发送到服务器，处于等待状态。
(4)请求数据。
请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length
下面是一个具体的请求示例，分别表示POST和GET报文。
GET：
GET报问头如下：
GET/sn/index.php？sn＝123&n＝asa HTTP/1.1
Accept:*/*
Accept-Language:zh-cn
host:localhost
Content-Type:application/x-www-form-urlencoded
Content-Length:12
Connection:close。
POST：
POST报文头如下：
POST/sn/index.php HTTP/1.1
Accept:*/*
Accept-Language:zh-cn
host:localhost
Content-Type:application/x-www-form-urlencoded
Content-Length:12
Connection:close
sn＝123&n＝asa
在http头后边有一空行，空行后边接着发送post数据，长度通过Content-Length:12
指出，此post数据中包含两项
sn＝123
n＝asa
其中：Content-Type:application/x-www-form-urlencoded指定POST数据的编码类型
Content-Length:12POST数据的长度。
具体的字段含义解释可参考HTTP协议中的规定。
下面结合图1描述本发明实施例的基于HTTP协议的缓存状态更新方法，
如图1所示，该方法包括：
S11：接收来自终端的HTTP请求。
在本发明的一个实施例中，接收来自终端的当前GET请求，其中，接收当前GET请求的时间为t1。
在本发明的一个实施例中，接收来自终端的第一GET请求。
在本发明的一个实施例中，接收来自终端的第二GET请求。
在本发明的一个实施例中，接收来自终端的第三GET请求，第三GET请求包括码流指示符。
可以理解的是，上述例举主要是为了帮助理解本发明实施例而做出的一种举例，而不是对本发明实施例的一种限制。本发明实施例的各个缓存事件之间是可以相互独立处理的，根据不同的缓存事件，相应的更新缓存状态。
本方法的执行主体既可以是HTTP流播系统中的服务器，也可以是具有探针能力的网管或网络设备。
S12：根据所述HTTP请求触发缓存事件。
在本发明的一个实施例中，若在以t1为起始的预设时间内没有接收到来自所述终端的后一GET请求，则触发缓存事件中的暂停。
可以理解的是，本步骤中所提到的预设时间可以是一个经验值，例如3-5秒。也可以是根据具体的媒体业务所设置的与媒体业务相匹配的一个时间长度。
在本发明的一个实施例中，根据第一GET请求中的关键字，触发拖动，
在一个具体示例中，若第一GET请求中的ts_start值与来自终端的前一GET请求(相对于第一GET请求而言)的ts_start值差大于预设阈值且第一GET请求中的ts_end值与来自终端的前一GET请求的ts_end值的差大于预设阈值，则触发拖动。此处的连续是针对关键字而言的。例如，前一GET请求中的ts_start取值为1，ts_end为200；第一GET请求中的ts_start为201，ts_end为400，则可以认为取值连续。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、100、400等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中的取值示例可参考图7。
在一个具体示例中，对比连续GET请求中的Range取值是否连续，如果连续两个GET请求中的Range值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中Range值的示例可参考图8。
在一个具体的示例中，对比连续GET请求中的begin取值是否连续，如果连续两个GET请求中的begin值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中begin值的示例可参考如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
在本发明的一个实施例中，根据第二GET请求触发重新播放。在发生暂停后，当接收到对同一媒体流的后一GET请求(即第二GET请求)时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，根据第三GET请求触发码流切换，在一个具体的示例中，具体的，如果第三GET请求中的itag取值发生变化，则发生缓存事件中的码流切换。
示例如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
示例中第三GET请求中的itag值为22，如果前一GET请求(相对于第三GET请求而言)中的itag值不为22，例如可以是20或24，则发生缓存事件中的码流切换。
S13：根据所述缓存事件，更新缓存状态。
在本发明的一个实施例中，根据暂停，将缓存状态设为停止播放状态。
在本发明的一个实施例中，根据拖动，将缓存状态设为再缓存状态。
在本发明的一个实施例中，根据重新播放，将缓存状态设为正常播放状态。
在本发明的一个实施例中，根据码流切换，将缓存状态设为码流切换状态。
可以理解的是，上述例举主要是为了帮助理解本发明实施例而做出的一种举例，而不是对本发明实施例的一种限制。本发明实施例的各个缓存事件之间是可以相互独立处理的，根据不同的缓存事件，相应的更新缓存状态。
根据本发明实施例的基于HTTP协议的缓存状态更新方法，通过对缓存事件的确定触发相应的缓存状态转换。能够准确的满足现有媒体业务中的缓存需求，使得缓存模型更接近真实。
下面结合图2对本发明实施例的基于HTTP协议的缓存状态更新设备20做进一步的说明，如图2所示，缓存状态更新设备20包括：接收模块21、触发模块22和缓存状态模块23，其中，接收模块21和触发模块22相连，缓存状态模块23和触发模块22相连。
其中，接收模块21用于接收来自终端的HTTP请求。
在本发明的一个实施例中，接收来自终端的当前GET请求，其中，接收当前GET请求的时间为t1。
在本发明的一个实施例中，接收来自终端的第一GET请求。
在本发明的一个实施例中，接收来自终端的第二GET请求。
在本发明的一个实施例中，接收来自终端的第三GET请求，第三GET请求包括码流指示符。
可以理解的是，上述例举主要是为了帮助理解本发明实施例而做出的一种举例，而不是对本发明实施例的一种限制。本发明实施例的各个缓存事件之间是可以相互独立处理的，根据不同的缓存事件，相应的更新缓存状态。
触摸模块22根据所述HTTP请求触发缓存事件。
在本发明的一个实施例中，若在以t1为起始的预设时间内没有接收到来自所述终端的后一GET请求，则触发缓存事件中的暂停。
可以理解的是，本步骤中所提到的预设时间可以是一个经验值，例如3-5秒。也可以是根据具体的媒体业务所设置的与媒体业务相匹配的一个时间长度。
在本发明的一个实施例中，根据第一GET请求中的关键字，触发拖动，
在一个具体示例中，若第一GET请求中的ts_start值与来自终端的前一GET请求(相对于第一GET请求而言)的ts_start值差大于预设阈值且第一GET请求中的ts_end值与来自终端的前一GET请求的ts_end值的差大于预设阈值，则触发拖动。此处的连续是针对关键字而言的。例如，前一GET请求中的ts_start取值为1，ts_end为200；第一GET请求中的ts_start为201，ts_end为400，则可以认为取值连续。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、100、400等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中的取值示例可参考图7。
在一个具体示例中，对比连续GET请求中的Range取值是否连续，如果连续两个GET请求中的Range值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中Range值的示例可参考图8。
在一个具体的示例中，对比连续GET请求中的begin取值是否连续，如果连续两个GET请求中的begin值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中begin值的示例可参考如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
在本发明的一个实施例中，根据第二GET请求触发重新播放。在发生暂停后，当接收到对同一媒体流的后一GET请求(即第二GET请求)时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，根据第三GET请求触发码流切换，在一个具体的示例中，具体的，如果第三GET请求中的itag取值发生变化，则发生缓存事件中的码流切换。
示例如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
示例中第三GET请求中的itag值为22，如果前一GET请求(相对于第三GET请求而言)中的itag值不为22，例如可以是20或24，则发生缓存事件中的码流切换。
缓存模块23用于根据所述缓存事件，更新缓存状态。
在本发明的一个实施例中，根据暂停，将缓存状态设为停止播放状态。
在本发明的一个实施例中，根据拖动，将缓存状态设为再缓存状态。
在本发明的一个实施例中，根据重新播放，将缓存状态设为正常播放状态。
在本发明的一个实施例中，根据码流切换，将缓存状态设为码流切换状态。
可以理解的是，上述例举主要是为了帮助理解本发明实施例而做出的一种举例，而不是对本发明实施例的一种限制。本发明实施例的各个缓存事件之间是可以相互独立处理的，根据不同的缓存事件，相应的更新缓存状态。
根据本发明实施例的基于HTTP协议的缓存状态更新设备20，通过对缓存事件的确定触发相应的缓存状态转换。能够准确的满足现有媒体业务中的缓存需求，使得缓存模型更接近真实。相应的，更新设备20各模块所执行的功能可以参考相应的方法实施例，在此不再赘述。
下面结合附图6对本发明实施例的基于HTTP协议的缓存状态更新方法做进一步的说明。
在本发明各实施例中，缓存事件包括拖动(Seek)、暂停(Pause)、重新播放(Resume)、码流切换(Stream switch)。其中，拖动(Seek)、暂停(Pause)、重新播放(Resume)等缓存事件所表示的含义与现有技术中的含义保持一致，例如可参考ITU-T G.1021标准中的规定，在此不再赘述。码流切换事件则表示在多个媒体文件描述中进行不同的码率文件的选择。
在本发明各实施例中，缓存的缓存状态可以包括：初始缓冲状态、正常播放状态、再缓冲状态、结束播放状态、停止播放状态和码流切换状态中的至少一个。初始缓冲状态、正常播放状态、再缓冲状态、结束播放状态、停止播放状态所表示的终端的缓存变化可参考ITU-T制定的G.1021标准，在此不再赘述。特别说明的是，该标准是基于UDP协议进行的缓存状态更新，而本发明实施例所提供的缓存状态更新的方案是基于TCP协议的。
缓存状态更新模型的初始状态设置为初始缓冲状态，也就是说，如果本次状态更新是第一次状态更新，则本次状态更新前的缓存状态为初始缓冲状态。对于本次状态更新为非第一次状态更新时，本次状态更新前的缓存状态即为上一次状态更新获取的缓存状态，则本次状态更新前的缓存状态可能是初始缓冲状态、正常播放状态、再缓冲状态、结束播放状态、停止播放状态和码流切换状态中的任意一个状态。相应的，无论本次状态更新是否是第一次状态更新，则更新出的本次缓存状态也可能是初始缓冲状态、正常播放状态、再缓冲状态、结束播放状态、停止播放状态和码流切换状态中的任意一个状态。各缓存状态之间的跳转是基于缓存事件的触发的。各缓存状态之间的跳转关系具体如图6所示。
在本发明的一个实施例中，通过判断HTTP的GET请求是否到达，确定缓存事件中的暂停和重新播放。
具体的，在接收到用户端发送的GET请求之后，如果在某设定的时间门限内没有收到用户新的GET请求，则发生缓存事件中的暂停。这里的时间门限可以是经验值，例如1秒，3秒，5秒等，也可以是根据具体的媒体应用业务设置的值。
在发生暂停后，当接收到对同一媒体流的后一GET请求时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，还可以通过分析GET请求中关键字，确定缓存事件中的拖动和码流切换。
具体的，如果GET请求中的itag取值发生变化，则发生缓存事件中的码流切换。
示例如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
示例中当前GET请求中的itag值为22，如果前一GET请求中的itag值不为22，例如可以是20或24，则发生缓存事件中的码流切换。
通过对比连续GET请求中的range取值是否连续，如果大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间。门限值的设定可以为经验值，如1、100、400等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。
根据缓存事件，更新当前缓存状态，
当缓存事件为拖动(seek)时，进入再缓冲状态；
当缓存事件为重新播放(resume)时，进入正常播放状态；
当缓存事件为暂停(pause)时，进入停止播放状态。
可以理解的是，上述几种判断是独立的分支，并不存在顺序之间的限制。
在本发明的一个实施例中，通过判断HTTP的GET请求是否到达，确定缓存事件中的暂停和重新播放。
具体的，在接收到用户端发送的GET请求之后，如果在某设定的时间门限内没有收到用户新的GET请求，则发生缓存事件中的暂停。这里的时间门限可以是经验值，例如1秒，3秒，5秒等，也可以是根据具体的媒体应用业务设置的值。
在发生暂停后，当接收到对同一媒体流的后一GET请求时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，还可以通过分析GET请求中关键字，确定缓存事件中的拖动和码流切换。
对比连续GET请求中的ts_start和ts_end取值是否连续，如果大于某设定的门限时，则发生缓存事件中的拖动。此处的连续是针对关键字而言的。例如，前一GET请求中的ts_start取值为1，ts_end为200；当前GET请求中的ts_start为201，ts_end为400，则可以认为取值连续。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、100、400等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中的取值示例可参考图7。
根据缓存事件，更新当前缓存状态，
当缓存事件为拖动(seek)时，进入再缓冲状态；
当缓存事件为重新播放(resume)时，进入正常播放状态；
当缓存事件为暂停(pause)时，进入停止播放状态。
可以理解的是，上述几种判断是独立的分支，并不存在顺序之间的限制。
在本发明的一个实施例中，通过判断HTTP的GET请求是否到达，确定缓存事件中的暂停和重新播放。
具体的，在接收到用户端发送的GET请求之后，如果在某设定的时间门限内没有收到用户新的GET请求，则发生缓存事件中的暂停。这里的时间门限可以是经验值，例如1秒，3秒，5秒等，也可以是根据具体的媒体应用业务设置的值。
在发生暂停后，当接收到对同一媒体流的后一GET请求时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，还可以通过分析GET请求中关键字，确定缓存事件中的拖动和码流切换。
对比连续GET请求中的Range取值是否连续，如果连续两个GET请求中的Range值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中Range值的示例可参考图8。
根据缓存事件，更新当前缓存状态，
当缓存事件为拖动(seek)时，进入再缓冲状态；
当缓存事件为重新播放(resume)时，进入正常播放状态；
当缓存事件为暂停(pause)时，进入停止播放状态。
可以理解的是，上述几种判断是独立的分支，并不存在顺序之间的限制。
在本发明的一个实施例中，通过判断HTTP的GET请求是否到达，确定缓存事件中的暂停和重新播放。
具体的，在接收到用户端发送的GET请求之后，如果在某设定的时间门限内没有收到用户新的GET请求，则发生缓存事件中的暂停。这里的时间门限可以是经验值，例如1秒，3秒，5秒等，也可以是根据具体的媒体应用业务设置的值。
在发生暂停后，当接收到对同一媒体流的后一GET请求时，则发生缓存事件中的重新播放。可以理解的是，现有技术中基于HTTP协议有多种判断两个GET请求是否属于同一媒体流的方式，在此不再赘述。
在本发明的一个实施例中，还可以通过分析GET请求中关键字，确定缓存事件中的拖动和码流切换。
对比连续GET请求中的begin取值是否连续，如果连续两个GET请求中的begin值之间的差大于某设定的门限时，则发生缓存事件中的拖动。设定的门限值可以为字节数或时间，门限值的设定可以为经验值，如1、3、5等，也可以是本领域普通技术人员不需要付出创造性劳动即可想到的其它方式。具体的GET请求中begin值的示例可参考如下：
http://o-o---preferred---ord12s17---v9---nonxt8.c.youtube.com/videoplayback？upn＝ZklvQD0CWlk&***&itag＝22&signature＝CB56719507C9C7792A578C38776DC229D11692F0.371C9E4DB6063A48A0ACD76D5E8A2EAC9E10595C&***&id＝2b72abf2705cbde0&begin＝834234。
根据缓存事件，更新当前缓存状态，
当缓存事件为拖动(seek)时，进入再缓冲状态；
当缓存事件为重新播放(resume)时，进入正常播放状态；
当缓存事件为暂停(pause)时，进入停止播放状态。
可以理解的是，上述几种判断是独立的分支，并不存在顺序之间的限制。
下面结合图9描述本发明实施例的一种基于HTTP的缓存状态更新方法在DASH(Dynamic Adaptive Streaming over HTTP)规定的环境下的具体应用。DASH标准的具体内容可参考3GPP和MPEG等标准组织的规定，在此不再赘述。
如图9所示，流媒体的处理程序包括如下的步骤：
S901，客户端91从服务器92处获得MPD文件。具体的获取方式既可以是客户端91向服务器92发送MPD获取请求，然后接收服务器92发送的MPD文件。也可以是服务器92直接将MPD文件发送给客户端91。MPD文件的格式具体可参考3GPP-DASH和MPEG-DASH的有关规定，在此不再赘述。
在本实施例一种可能的方式中，客户端91可以通过使用HTTP GET请求获取MPD。客户端还可能通过采用一种循序渐进的方式(即使用具有字节范围的多个HTTP GET请求)获取MPD。MPD中的每一项都可包含一个文件或多个文件的媒体内容数据，其中每一个文件都与一个独特的统一资源定位符(URL)相关联。
MPD可包括所有片断的最大长度，从而无需MPD中的字节范围的信令即可使用字节范围，并大大缩减MPD的大小，这意味着流播过程的启动迟延降低。为了表明直播流会话结束，服务器可采用异常方式组成下一个预期文件或片断，例如，清空文件或片断。为了成功调至直播流会话并开始请求最新内容，流播服务器中可用的且其中包含最新片断的文件使用了一个特殊的文件名称，继而使用了一个特殊的URL。为了让客户端计算出其欲寻找一个具体临时位置时启动的具体文件，当片断持续时间保持不变，以及MPD中每一个片断都没有任何字节偏移或时间偏移信令，可生成文件的URL其其可具有指明文件开始回放时间的功能。提供了可启动诸如设置、暂停、续播及停止等一般流播流程的高效流播流程，并提供了搜索、快进、快退及媒体流自适应流程。
S902，客户端91向服务器92发送HTTP GET请求，请求某一时间的媒体片断,请求的片断既可以包括音频文件和视频文件，也可以只单独请求其中的一种，一次请求可以请求一个或多个媒体片断。
S903,服务器92将相应的媒体片断发送给客户端91。在一个可能的实施例中，如果GET请求的媒体片断不包括其他媒体片断，字节域可以不用，否则必须使用字节域。
客户端91为了获取某一个特殊的媒体片断，可以进行在客户端91进行拖动的操作。此时客户端91会向服务器92发送基于要拖动到的位置的新的GET请求，服务器92可以通过分析GET请求中的关键字确定发生了缓存事件中的拖动，从而触发相应的缓存状态的改变，确定终端进入了再缓冲状态。
具体的，可通过比较连续的GET请求(如S904和S906)中的range值或begin值的方式判断是否发生了缓存事件中的拖动。也可以通过比较连续的GET请求(如S904和S906)中的ts_start和ts_end值的方式判断是否发生了缓存事件中的拖动。
码流切换。客户端91可以从MPD中获取进行码流切换所需要的足够的信息。例如选择不同语言的音频流，不同视角的视频流，以及上述音视频流组合选择，还可以提供在同一视频内容下不同码率的动态选择。
在客户端91如果发生了暂停或停止播放的操作，客户端91不再向服务器92发送GET请求。服务器在预设的时间内没有收到客户端91新的GET请求的话，可以确定客户端发生了缓存事件中的暂停。
根据本发明实施例提供的技术方案，通过对缓存事件的确定触发相应的缓存状态转换。能够准确的满足现有媒体业务中的缓存需求，使得缓存模型更接近真实。
下面结合图10描述根据本发明实施例的缓存状态处理机100，如图10所示，缓存状态处理机100包括获取模块101和状态处理模块102。其中，获取模块101和状态处理模块102相连。缓存事件包括拖动、暂停、重新播放和码流切换，缓存状态包括再缓冲状态、正常播放状态、停止播放状态和码流切换状态。
获取模块101主要用于获得缓存事件，状态处理模块102用于根据获取模块101获得的缓存事件更新缓存状态。
其中，
当所述缓存事件为暂停时，进入停止播放状态，
当所述缓存事件为重新播放时，进入正常播放状态，
当所述缓存事件为拖动时，进入再缓冲状态，
当所述事件为码流切换时，进入码流切换状态。
根据本发明实施例的基于HTTP协议的缓存状态处理机100，通过对缓存事件的确定触发相应的缓存状态转换。能够准确的满足现有媒体业务中的缓存需求，使得缓存模型更接近真实。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的处理机、设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块、单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，在本发明各个实施例中的各功能模块、单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (17)

1.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新方法，其特征在于，所述方法包括：
接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；
根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自终端的当前GET请求，其中，接收所述当前GET请求的时间为t；
若在以t为起始的预设时间内没有接收到来自所述终端的后一GET请求，则触发所述暂停；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述暂停，将所述缓存状态设为所述停止播放状态。
2.根据权利要求1所述的缓存状态更新方法，其特征在于，在所述触发暂停之后，如果接收到来自所述终端的后一GET请求，所述方法还包括：
根据所述后一GET请求触发所述重新播放；
根据所述重新播放，将所述缓存状态设为所述正常播放状态。
3.根据权利要求2所述的缓存状态更新方法，其特征在于，所述当前GET请求中包括当前码流指示符，所述后一GET请求中包括后一码流指示符；
若所述当前码流指示符和所述后一码流指示符不同，在接收到来自所述终端的后一GET请求后，所述方法还包括：
触发所述码流切换；
根据所述码流切换，将所述缓存状态设为所述码流切换状态。
4.根据权利要求1-3任意之一所述的缓存状态更新方法，其特征在于，所述方法还包括：
根据所述当前GET请求中的关键字，确定是否触发所述拖动；
若确定触发所述拖动，则根据所述拖动，将所述缓存状态设为所述再缓冲状态。
5.根据权利要求4所述的缓存状态更新方法，其特征在于，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的rang值与来自所述终端的前一GET请求的range值的差大于预设阈值，则触发所述拖动。
6.根据权利要求4所述的缓存状态更新方法，其特征在于，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的ts_start值与来自所述终端的前一GET请求的ts_start值差大于预设阈值且所述当前GET请求中的ts_end值与来自所述终端的前一GET请求的ts_end值的差大于所述预设阈值，则触发所述拖动。
7.根据权利要求4所述的缓存状态更新方法，其特征在于，所述根据所述当前GET请求中的关键字，确定是否触发所述拖动，具体包括：
若所述当前GET请求中的begin值与来自所述终端的前一GET请求的begin值的差大于预设阈值，则触发所述拖动。
8.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新方法，其特征在于，所述方法包括：
接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；
根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第一GET请求，根据所述第一GET请求中的关键字，触发所述拖动；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述拖动，将所述缓存状态设为所述再缓冲状态。
9.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新方法，其特征在于，所述方法包括：
接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；
根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第二GET请求，根据所述第二GET请求触发所述重新播放；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述重新播放，将所述缓存状态设为所述正常播放状态。
10.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新方法，其特征在于，所述方法包括：
接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，所述缓存事件包括拖动、暂停、重新播放、码流切换；
根据所述缓存事件，更新缓存状态，其中，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收来自终端的HTTP请求，根据所述HTTP请求触发缓存事件，具体包括：
接收来自所述终端的第三GET请求，所述第三GET请求包括码流指示符；
若所述码流指示符与来自所述终端的前一码流指示符不同，则触发所述码流切换；
相应的，所述根据所述缓存事件，更新缓存状态具体包括：
根据所述码流切换，将所述缓存状态设为所述码流切换状态。
11.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新设备，其特征在于，所述设备包括：
接收模块，用于接收来自终端的HTTP请求；
触发模块，用于根据所述HTTP请求触发缓存事件；
缓存状态模块，用于根据所述缓存事件，更新缓存状态；
其中，所述缓存事件包括拖动、暂停、重新播放、码流切换，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收模块具体用于接收来自所述终端的当前GET请求，其中，接收所述当前GET请求的时间为t；
所述触发模块具体用于在以t为起始的预设时间内没有接收到来自所述终端的后一GET请求时，触发暂停；
所述缓存状态模块具体用于根据所述暂停，将缓存状态设为停止播放状态。
12.根据权利要求11所述的缓存状态更新设备，其特征在于，所述接收模块还用于接收所述后一GET请求；相应的，所述触发模块还用于根据所述后一GET请求触发所述重新播放；所述缓存状态模块还用于根据所述重新播放，将所述缓存状态设为正常播放状态。
13.根据权利要求11或12所述的缓存状态更新设备，其特征在于，所述触发模块还用于触发所述码流切换，所述缓存状态模块还用于根据所述码流切换，将所述缓存状态设为码流切换状态。
14.根据权利要求11或12所述的缓存状态更新设备，其特征在于，所述触发模块还用于根据所述当前GET请求中的关键字，触发所述拖动；所述缓存状态模块还用于根据所述拖动，将所述缓存状态设为再缓冲状态。
15.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新设备，其特征在于，所述设备包括：
接收模块，用于接收来自终端的HTTP请求；
触发模块，用于根据所述HTTP请求触发缓存事件；
缓存状态模块，用于根据所述缓存事件，更新缓存状态；
其中，所述缓存事件包括拖动、暂停、重新播放、码流切换，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收模块具体用于接收来自所述终端的第四GET请求；
所述触发模块具体用于根据所述第四GET请求中的关键字，触发所述拖动；
所述缓存状态模块具体用于根据所述拖动，将所述缓存状态设为再缓冲状态。
16.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新设备，其特征在于，所述设备包括：
接收模块，用于接收来自终端的HTTP请求；
触发模块，用于根据所述HTTP请求触发缓存事件；
缓存状态模块，用于根据所述缓存事件，更新缓存状态；
其中，所述缓存事件包括拖动、暂停、重新播放、码流切换，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；
所述接收模块具体用于接收来自所述终端的第五GET请求；
所述触发模块具体用于根据所述第五GET请求触发所述重新播放；
所述缓存状态模块具体用于根据所述重新播放，将所述缓存状态设为所述正常播放状态。
17.一种基于超文本传输协议(HyperText Transfer Protocol，HTTP)的缓存状态更新设备，其特征在于，所述设备包括：
接收模块，用于接收来自终端的HTTP请求；
触发模块，用于根据所述HTTP请求触发缓存事件；
缓存状态模块，用于根据所述缓存事件，更新缓存状态；
其中，所述缓存事件包括拖动、暂停、重新播放、码流切换，所述缓存状态包括正常播放状态、停止播放状态、再缓冲状态、码流切换状态；所述接收模块具体用于来自所述终端的第六GET请求，所述第六GET请求包括码流指示符；
所述触发模块具体用于根据所述码流指示符，触发所述码流切换；
所述缓存状态模块具体用于根据所述码流切换，将所述缓存状态设为所述码流切换状态。
CN201410218849.6A 2014-05-22 2014-05-22 一种http协议的缓存状态更新方法和设备、处理机 Active CN105100172B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201410218849.6A CN105100172B (zh) 2014-05-22 2014-05-22 一种http协议的缓存状态更新方法和设备、处理机
EP14892670.2A EP3101871B1 (en) 2014-05-22 2014-10-11 Updating method and device for cache state based on http, and processor therefor
PCT/CN2014/088370 WO2015176470A1 (zh) 2014-05-22 2014-10-11 一种http协议的缓存状态更新方法和设备、处理机
US15/248,603 US10003999B2 (en) 2014-05-22 2016-08-26 HTTP-based buffer status updating method and device, and buffer status processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410218849.6A CN105100172B (zh) 2014-05-22 2014-05-22 一种http协议的缓存状态更新方法和设备、处理机

Publications (2)

Publication Number Publication Date
CN105100172A CN105100172A (zh) 2015-11-25
CN105100172B true CN105100172B (zh) 2018-03-27

Family

ID=54553345

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410218849.6A Active CN105100172B (zh) 2014-05-22 2014-05-22 一种http协议的缓存状态更新方法和设备、处理机

Country Status (4)

Country Link
US (1) US10003999B2 (zh)
EP (1) EP3101871B1 (zh)
CN (1) CN105100172B (zh)
WO (1) WO2015176470A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10798144B2 (en) 2015-06-18 2020-10-06 Ericsson Ab Directory limit based system and method for storing media segments
CN108011944B (zh) * 2017-11-30 2020-12-22 北京酷我科技有限公司 一种Android上降低http请求失败的方法
CN108346297A (zh) * 2018-03-30 2018-07-31 合肥城市泊车投资管理有限公司 一种基于智能管理系统的违章停车管理控制方法
CN111510790B (zh) 2019-01-30 2021-10-15 上海哔哩哔哩科技有限公司 视频请求方法、系统、计算机设备及计算机可读存储介质
US11184420B2 (en) * 2020-01-06 2021-11-23 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
CN111601144B (zh) * 2020-05-19 2021-10-08 青岛海信传媒网络技术有限公司 流媒体文件播放方法及显示设备
CN112787993A (zh) * 2020-12-25 2021-05-11 北京金万维科技有限公司 一种基于udp协议高并发http请求缓存和内容推送系统及方法
CN113014997B (zh) * 2021-03-12 2023-04-07 上海哔哩哔哩科技有限公司 缓存更新方法及装置
US20220385709A1 (en) * 2021-05-28 2022-12-01 Spotify Ab Command buffering

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127989A (zh) * 2007-09-11 2008-02-20 中兴通讯股份有限公司 一种支持手机超文本传输流媒体业务的方法
CN101212399A (zh) * 2006-12-27 2008-07-02 深圳Tcl工业研究院有限公司 一种内存管理方法
CN101282348A (zh) * 2007-04-06 2008-10-08 上海晨兴电子科技有限公司 运用http协议实现流媒体功能的方法
CN102025760A (zh) * 2009-09-21 2011-04-20 华为技术有限公司 Http的媒体传输方法及装置
CN103428105A (zh) * 2012-05-14 2013-12-04 中国科学院声学研究所 一种基于带宽估计的自适应http流化码流切换方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8144837B2 (en) * 2001-01-22 2012-03-27 Dialogic Corporation Method and system for enhanced user experience of audio
CN102118270B (zh) * 2011-03-04 2014-04-30 华为技术有限公司 一种度量用户体验质量QoE的方法及装置
US8489760B2 (en) 2011-03-31 2013-07-16 Juniper Networks, Inc. Media file storage format and adaptive delivery system
CN102868908B (zh) * 2011-07-04 2015-05-20 哈尔滨融智达网络科技有限公司 高效流媒体播放方法和装置
US9826502B2 (en) * 2011-07-25 2017-11-21 Qualcomm Incorporated Managing handoff triggering between unicast and multicast services
CN102333089A (zh) 2011-09-26 2012-01-25 南京邮电大学 基于超文本传输协议流化的多码率媒体流自适应控制方法
US9954717B2 (en) * 2012-07-11 2018-04-24 Futurewei Technologies, Inc. Dynamic adaptive streaming over hypertext transfer protocol as hybrid multirate media description, delivery, and storage format
US9071887B2 (en) * 2012-10-15 2015-06-30 Verizon Patent And Licensing Inc. Media session heartbeat messaging

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101212399A (zh) * 2006-12-27 2008-07-02 深圳Tcl工业研究院有限公司 一种内存管理方法
CN101282348A (zh) * 2007-04-06 2008-10-08 上海晨兴电子科技有限公司 运用http协议实现流媒体功能的方法
CN101127989A (zh) * 2007-09-11 2008-02-20 中兴通讯股份有限公司 一种支持手机超文本传输流媒体业务的方法
CN102025760A (zh) * 2009-09-21 2011-04-20 华为技术有限公司 Http的媒体传输方法及装置
CN103428105A (zh) * 2012-05-14 2013-12-04 中国科学院声学研究所 一种基于带宽估计的自适应http流化码流切换方法及系统

Also Published As

Publication number Publication date
CN105100172A (zh) 2015-11-25
EP3101871A4 (en) 2017-03-15
EP3101871A1 (en) 2016-12-07
US20160366617A1 (en) 2016-12-15
US10003999B2 (en) 2018-06-19
WO2015176470A1 (zh) 2015-11-26
EP3101871B1 (en) 2020-05-06

Similar Documents

Publication Publication Date Title
CN105100172B (zh) 一种http协议的缓存状态更新方法和设备、处理机
CN102611945B (zh) 一种流媒体切片方法、切片服务器及流媒体点播系统
KR100993955B1 (ko) 다중매체 프리젠테이션
US20100082747A1 (en) Real-time collaborative browsing
US8990429B2 (en) HTTP-based synchronization method and apparatus
US20050086344A1 (en) Method and system for unrestricted, symmetric remote scripting
EP2383941A1 (en) Stream media server, client terminal and method and system for downloading stream media
WO2017096830A1 (zh) 用于cdn平台的内容分发方法及调度代理服务器
CN104854838A (zh) 用于向客户端设备分发视听内容的系统和方法
JP4435819B2 (ja) キャッシュ制御プログラム、キャッシュ制御装置、キャッシュ制御方法、およびキャッシュサーバ
WO2013010369A1 (zh) 一种获取网页中音/视频链接地址的方法及装置
CN109640113A (zh) 一种拖拉视频数据的处理方法及代理服务器
CN102158518B (zh) 一种cdn网络中的数据传输方法、网络节点及系统
CN105657440A (zh) 一种视频直播的方法及系统
CN103281594A (zh) 监控基于开放互联网的自适应视频流式传输
CN107113325A (zh) 用于选择性传输加速器操作的系统和方法
CN107111624B (zh) 接收装置、发送装置和数据处理方法
CN114827670A (zh) 一种视频播放方法、装置及电子设备
CN105721895A (zh) 数据交互方法及系统
CA2964712C (en) Reception device, transmission device, and data processing method
CN103795792B (zh) 一种语音导航方法及系统
US9483575B2 (en) Reproducing a graphical user interface display
CN108200452A (zh) 一种防止下载的web视频在线播放系统及其控制方法
McKinley et al. Design and performance evaluation of a Java-based multicast browser tool
JP2003051846A (ja) 帯域制御方法、ネットワークサービスシステム、コンテンツサーバ装置、帯域管理装置及びコンテンツ管理装置

Legal Events

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