WO2011054319A1 - 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统 - Google Patents

一种在httpstreaming系统中实现分层请求内容的方法，装置和系统 Download PDF

Info

Publication number
WO2011054319A1
WO2011054319A1 PCT/CN2010/078518 CN2010078518W WO2011054319A1 WO 2011054319 A1 WO2011054319 A1 WO 2011054319A1 CN 2010078518 W CN2010078518 W CN 2010078518W WO 2011054319 A1 WO2011054319 A1 WO 2011054319A1
Authority
WO
WIPO (PCT)
Prior art keywords
fragment
client
service
url
description information
Prior art date
Application number
PCT/CN2010/078518
Other languages
English (en)
French (fr)
Inventor
袁卫忠
石腾
张园园
刘光远
田永辉
张仁宙
吴凌燕
乐培玉
张楚雄
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP10827933.2A priority Critical patent/EP2493191B1/en
Publication of WO2011054319A1 publication Critical patent/WO2011054319A1/zh
Priority to US13/467,738 priority patent/US20120221681A1/en

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

Definitions

  • the present invention relates to the field of network communication technologies, and in particular, to a method, apparatus and system for implementing layered request content in an http streaming system.
  • the terminal device There are various ways for users to use the terminal device to obtain multimedia content and play it. Typically, it is downloaded through HTTP file or P2P file is downloaded to the local disk, and the traditional streaming mode (RTP/RTCP and playback control RTSP for data transmission) , live streaming / on-demand streaming of P2P streaming, HTTP Progressive Download, and more.
  • HTTP file or P2P file is downloaded to the local disk
  • traditional streaming mode RTP/RTCP and playback control RTSP for data transmission
  • live streaming / on-demand streaming of P2P streaming HTTP Progressive Download
  • HTTP progressive download is an improvement on the way HTTP file is downloaded. It allows the terminal device to play while downloading, without waiting for the entire file to be downloaded before it can be played.
  • the playback start time is not too long.
  • the implementation principle is that the media content is fragmented, and one (/set) content fragment can be independently decoded on the terminal device without relying on other fragments. In this way, the server and the client only need to transmit one (/set) of content fragments at a time, and the terminal device can decode and play after receiving, and can also receive the next (/group) content fragment. In this way, the processing granularity of the media file is adjusted from the entire file to one of the content segments.
  • the typical content segmentation playback time can be several seconds, for example, 10 seconds.
  • the HTTP protocol is a stateless protocol.
  • the HTTP Streaming scheme based on the HTTP protocol can also achieve the advantages of simple implementation: Each HTTP request and response can constitute a transaction independent of other HTTP requests/responses (transactions, but at the same time This requirement is also raised for this scheme: Each time a media content fragment is obtained, the client needs to actively send an HTTP request to the server, and the HTTP server serves the client's request and returns a response message including the corresponding content fragment.
  • the client takes a long time to acquire and buffer content fragments when starting playback and Seek operations.
  • the HTTP protocol does not have a cancellation mechanism, once the content fragmentation is started, it needs to be transmitted (of course, the TCP connection can be closed and the TCP connection can be re-established, but this will cause an additional burden), and the longer fragmentation time will also affect the bit rate. Switching the timeliness of the response, because the rate switching is at least the fragmentation as the minimum unit;
  • each content fragment is small (shorter duration), then the client will need to initiate a request to the server frequently. More HTTP request messages will increase the uplink bandwidth usage, and will also increase the burden on the server to process requests, as well as the reduction of effective media content included in each HTTP response, resulting in a decrease in effective media transmission rate.
  • Segment Aggregates is a structure between the entire media content and the most basic composition of the content, in order to achieve greater flexibility than before.
  • the client's process of obtaining media content can be summarized as shown in the following figure:
  • Step 2 The client requests the Media Presentation Description information from the server to obtain the necessary media metadata information, and can generate subsequent media content requests by using the information; the server returns the description information to the client, including the time information of the slice set level. , and the URL information that can get the fragment set, etc.;
  • Step 4 The client requests the corresponding fragment set by means of an HTTP GET request according to the fragment set URL in the description information; after receiving the request message, the server returns the corresponding fragment set;
  • Step 5 If there is a fragment request trigger event (such as just starting playback, Seek operation, bandwidth change requires code rate switching, etc.), it will determine which fragment set the fragment of the request is located in;
  • a fragment request trigger event such as just starting playback, Seek operation, bandwidth change requires code rate switching, etc.
  • Step ⁇ 7 The client requests the initial part of the slice set (initial potion, the meta-information describing the slice set needs to be located at the head of the slice set) according to the determined fragment set URL, using a partial GET request.
  • the server may first request about 1000 bytes; after receiving the request message, the server returns the initial part of the fragment set including the metadata information (if the metadata information required by the client is not included in the returned response message, the client may Determining the byte range that needs to be requested and sending another request, the server will send the remaining fragment set metadata information to the client);
  • Step 8 The client parses and processes the metadata information of the fragment set, and obtains the location information (starting position and fragment length) of the required fragment in the fragment set;
  • Step 10 The client uses the fragment set URL and the location information of the fragment in the fragment set to request a fragment in the fragment set by partial GET; the server returns the corresponding fragment data in the response message.
  • the terminal and the server support the partial GET operation of the HTTP protocol, but there are currently some servers (especially the content distribution network edge).
  • the Cache Server) or the terminal cannot support partial GET. If the content distribution network is at the edge The cache server cannot support partial GET. It may need to forward the received partial GET request to the server for processing. The response will not be cached and the response time of the request will be increased.
  • the client when the client needs to request fragmentation, the client must first The metadata of the fragment set is requested from the server, and the metadata information obtained by the processing is analyzed, and the corresponding partial GET request can be constructed after the location information of the fragment is obtained, and the processing efficiency is low.
  • HTTP protocol is not required for Part GET GET.
  • HTTP servers and cache devices that have been widely deployed on the Internet may include older servers that only support the HTTP 1.0 protocol, even on HTTP 1. 1
  • the specification part of the partial GET has the text clearly stated: "A server MAY ignore the Range header.”, and also does not use the "MUST”, “SHALL” ⁇ ”SHOULD” that must be supported in the RFC. It is just a suggestion " ought to support byte ranges when poss ible. Therefore, using the partial GET scheme, in some network environments, you may encounter unsupported or incompatible situations.
  • a method for implementing layered request content in a http streaming system comprising: receiving a service information acquisition request sent by a client; returning a service information acquisition request response including a media presentation description information to the client, where the media presentation description information includes a URL corresponding to the multi-level service content; receiving a service request message GET message sent by the client, where the request message includes a URL of the multi-level service content determined by the client according to the service requirement and the media presentation description information; and returning the service request message response to the client
  • the service request message response includes a service content corresponding to the service content determined by the client according to the service requirement and the media presentation description information;
  • a server comprising: a receiving module, configured to receive a service information acquisition request sent by a client; a service information sending module, configured to return a service information acquisition request response including media presentation description information to the client, where the media presentation description information is included a service request receiving module, configured to receive a service request message GET message sent by the client, where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information; the service content sending module, The service request message response is returned to the client, and the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information.
  • a system for implementing layered request content in a http streaming system comprising: a server, configured to receive a service information acquisition request sent by a client; and return a service information acquisition request response including a media presentation description information to the client, and the media presentation description
  • the information includes a URL corresponding to the service content; receiving a service request message GET message sent by the client, where the request message includes a fragment URL determined by the client according to the service requirement and the media presentation description information; and returning a service request message response to the client,
  • the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information; the client is configured to send a service information acquisition request to the server; and the content returned by the obtained server corresponds to the service content URL media presentation description
  • a service request message GET message containing the service content URL determined according to the service requirement and the media presentation description information is sent to the server.
  • FIG. 1 is a process flow of acquiring media content in an SA solution in the prior art
  • FIG. 2 is a flowchart of a method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention
  • FIG. 3 is a schematic diagram of hierarchical layering of media content according to an embodiment of the present invention.
  • FIG. 4 is a flowchart of a fragment set request processing of a client according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a fragment request processing of a client according to an embodiment of the present invention.
  • FIG. 6 is a block diagram of a server according to an embodiment of the present invention.
  • FIG. 7 is a basic block diagram of a system for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 8 is a basic flowchart of another method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 9 is a basic flowchart of another method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 10 is a basic flowchart of another method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 11 is a basic flowchart of another method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 12 is a flowchart of processing a client-to-fragment trigger event according to an embodiment of the present invention.
  • FIG. 13 is a basic flowchart of another method for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention.
  • FIG. 14 is a flowchart of processing a client-to-fragmentation trigger event according to an embodiment of the present invention.
  • An elementary flow of a method for implementing hierarchical request content in an http streaming system Al, receiving a service information acquisition request sent by the client;
  • the client requests the Media Presentization information from the server to obtain the necessary media metadata, where the metadata is the resource description information.
  • A2 returning, to the client, a service information acquisition request response that includes media presentation description information, where the media presentation description information includes a URL corresponding to the service content;
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content corresponding to the content sharding embodiment according to the hierarchy may be the same or different.
  • Rate 1 Paragraph 3 corresponds to content fragmentation Optional code rate 2 URL
  • the shards here only correspond to a certain time period content in the shard set, but also allow the data content of the corresponding time period directly included in the shard set to be different, as long as all consecutive ones correspond to one shard set.
  • the media content included in each successive slice may be the same as the media content included in the slice set.
  • A3 receiving a service request message GET message sent by the client, where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information;
  • the client uses HTTP according to the fragment set URL in the description information and the time information of the fragment set required.
  • the GET request method requests the corresponding fragment set; after receiving the request message, the server returns the corresponding fragment set, and the client's fragment set request processing flow refers to FIG. 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the required fragment set, the URL of the required request fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information according to the sequence number of the slice set. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • the specific processing process is related to server implementation and content deployment, and can support different deployment implementations:
  • each slice set URL corresponds to a stored static slice set file (for example, each slice set can be stored as a .3gp file or .mp4 file), and the server directly obtains according to the slice set URL.
  • the corresponding fragment set file is encapsulated in an HTTP response message and sent to the client;
  • the content of the fragment set corresponding to each fragment set URL is static, that is, the same score is sent by different clients.
  • the HTTP request message constructed by the slice set URL has the same fragment set content.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request.
  • the fragment set, and the sequence number in the fragment set, to determine the URL of the required fragment can be referred to Figure 5:
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete URL information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The fragment URL information corresponding to the sequence number is obtained at the corresponding code rate; the client constructs the HTTP GET request message by using the fragment URL obtained in the above step, and sends the message to the server to request the corresponding content fragmentation.
  • A4 returning a service request message response to the client, where the service request message response includes a service content corresponding to the service content determined by the client according to the service requirement and the media presentation description information;
  • the real-time example of the present invention adopts a method for implementing layered request content in the http streaming system, receiving a service information acquisition message sent by the client, and returning a service information acquisition message response including the media presentation description information to the client, the media presentation
  • the description information includes a URL corresponding to the service content
  • receives a service request message GET message sent by the client where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information, and returns a service request to the client.
  • the service request message response includes the service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that the search can be directly performed according to the URL when searching for the content, thereby improving the processing efficiency.
  • FIG. 6 A basic block diagram of a server according to an embodiment of the present invention may refer to FIG. 6, which mainly includes:
  • the receiving module 601 is configured to receive the service information acquisition request sent by the client, and the client requests the media present information to obtain the necessary media metadata, where the metadata is the resource description information;
  • the service information sending module 602 is configured to return, to the client, a service information acquisition request response that includes the media presentation description information, where the media presentation description information includes a URL corresponding to the service content, and the service information sending module 602 returns the media presentation to the client.
  • the description information should include the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the complete URL corresponding to each layer fragment.
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content fragment URL corresponding to the content fragmentation embodiment according to the hierarchy can be organized as shown in Table 1.
  • the service request receiving module 603 is configured to receive a service request message GET message sent by the client, where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information; and the client follows the fragmentation in the description information.
  • the set URL, and the time information of the fragment set of the request request the corresponding fragment set by means of the HTTP GET request; after receiving the request message, the server returns the corresponding fragment set, and the client's fragment set request
  • the process flow refers to Figure 4: 401.
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the required fragment set, the URL of the required request fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information according to the sequence number of the slice set. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • Each fragment set URL corresponds to a stored static fragment set file (for example, each slice set can be stored as a .3gp file or .mp4 file), the server directly obtains the corresponding slice set file according to the fragment set URL, encapsulates it in the HTTP response message and sends it to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request.
  • the fragment set, and the sequence number in the fragment set, to determine the URL of the required fragment can be referred to Figure 5:
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) , to request a start 30 minutes and 12 seconds of fragmentation, which is the 61st slice); if the duration of the slice set is not fixed length, according to the media, the uniform slice time axis information in the description information, and the fragmentation This point in the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete URL information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The fragment URL information corresponding to the serial number is obtained at the corresponding code rate. .
  • the service content sending module 604 is configured to return a service request message response to the client, where the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information.
  • the client constructs an HTTP GET request message by using the fragment URL obtained in the above step, and sends the message to the server to request the corresponding content fragmentation; after receiving the request message, the server returns the corresponding content fragment.
  • the server further includes
  • the layering module 605 is configured to divide the media resource into at least the following playing units, fragments, fragment sets, and paragraphs.
  • the allocation module 606 is configured to at least allocate a URL for the fragment, the fragmentation set, and the paragraph.
  • the real-time example of the present invention adopts a server, and the receiving module 601 receives the service information acquisition message sent by the client, and the service information sending module 602 returns a service information acquisition message response including the media presentation description information to the client, where the media presentation description information is included.
  • the service request receiving module 603 receives the service request message GET message sent by the client, where the request message includes the service content URL determined by the client according to the service requirement and the media presentation description information, and the service content sending module
  • the 604 returns a service request message response to the client, where the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that the content can be directly searched according to the URL when searching for the content. , improve processing efficiency.
  • a basic frame of a system for implementing hierarchical request content in an http streaming system according to an embodiment of the present invention
  • the figure can refer to Figure 7, which mainly includes:
  • the server 701 is configured to receive a service information acquisition request sent by the client 702, and return a service information acquisition request response including the media presentation description information to the client 702, where the media presentation description information includes a URL corresponding to the service content; a service request message GET message sent by the terminal 702, where the request message includes a fragmentation URL determined by the client according to the service requirement and the media presentation description information; and a service request message response is returned to the client 702, where the service request message response includes The service content corresponding to the service content URL determined by the client 702 according to the service requirement and the media presentation description information; the service information acquisition request sent by the receiving client 702 requests the client to request the media present information to obtain the necessary media element.
  • the data where the metadata is the resource description information, returns a service information acquisition request response including the media presentation description information to the client 702, where the media presentation description information includes the description information corresponding to the service content, and includes all levels. Minute Duration (and included in a content segment number of slices) or information uniform slice axis information, as well as with the complete division of the levels corresponding to Feng information pieces;
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content fragmentation URL corresponding to the hierarchical content fragmentation embodiment may be organized as shown in Table 1: receiving a service request message GET message sent by the client 702, where the request message includes a client according to the client The service requirement and the media display the service content URL determined by the description information; the client 702 requests the corresponding fragment set by means of the HTTP GET request according to the fragment set URL in the description information and the time information of the fragment set of the required request. After the server receives such a request message, it returns the corresponding fragment set.
  • the client 702 is configured to send a service information acquisition request to the server 701. After obtaining the URL media presentation description information corresponding to the service content returned by the server 701, sending the message to the server 701 includes determining according to the service requirement and the media presentation description information.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines the URL of the required request fragment set according to the description information and the time information of the required fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • Each fragment set URL corresponds to a stored static fragment set file (for example, each slice set can be stored as a .3gp file or .mp4 file), the server directly obtains the corresponding slice set file according to the fragment set URL, encapsulates it in the HTTP response message and sends it to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request.
  • the fragment set, and the sequence number in the fragment set, to determine the URL of the required fragment can be referred to Figure 5:
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set; 503.
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete URL information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The corresponding piece of phoenix information corresponding to the serial number is obtained at the corresponding code rate.
  • the real-time example of the present invention adopts a system for implementing hierarchical request content in the http streaming system
  • the server 701 receives the service information acquisition message sent by the client 702, and the server 701 returns a service information acquisition message including the media presentation description information to the client 702.
  • the media presentation description information includes a URL corresponding to the service content
  • the server 70 receives the service request message GET message sent by the client 702, where the request message includes the client 702 determining according to the service requirement and the media presentation description information.
  • the service content server 701 returns a service request message response to the client 702, where the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that when the content is searched It can be searched directly according to the URL, which improves the processing efficiency.
  • FIG. 8 A specific example of a method for implementing hierarchical request content in a http streaming system according to an embodiment of the present invention refers to FIG. 8, which mainly includes the steps:
  • the client sends a service information acquisition request to the server.
  • the client requests the Media Presentation Description information from the server to obtain the necessary media metadata, where the metadata is the resource description information.
  • the server returns a service information acquisition request response to the client.
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content segmentation URL corresponding to this hierarchical content segmentation embodiment can be organized as shown in Table 1:
  • the shards here only correspond to a certain time period content in the shard set, but also allow the data content of the corresponding time period directly included in the shard set to be different, as long as all consecutive contiguous ones corresponding to one shard set
  • the media content included in the contiguous slice is the same as the media content included in the shard set.
  • the client sends a GET message requesting a fragment set to the server.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the required fragment set, the URL of the required request fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information according to the sequence number of the slice set. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • Each fragment set URL corresponds to a stored static fragment set file (for example, each slice set can be stored as a .3gp file or .mp4 file), the server directly obtains the corresponding slice set file according to the fragment set URL, encapsulates it in the HTTP response message and sends it to the client;
  • the content of the slice set corresponding to each slice set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are identical.
  • multiple slice sets can be continuously stored in the same large file, and the server maps the slice set according to the URL information in the large text. Position and length information in the piece, and dynamically extracting the required piece set content from the file storing the plurality of slice sets when serving the client request, encapsulated in the HTTP response message and sent to the client;
  • the client waits for the server to return a response message.
  • the server returns a corresponding fragment set to the client.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request.
  • the client sends a GET message to the server to request the fragment content.
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete URL information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The fragment URL information corresponding to the sequence number is obtained at the corresponding code rate; the client constructs the HTTP GET request message by using the fragment URL obtained in the above step, and sends the message to the server to request the corresponding content fragmentation.
  • the server returns a corresponding fragment content to the client.
  • the real-time example of the present invention adopts a method for implementing layered request content in the http streaming system, receiving a service information acquisition message sent by the client, and returning a service information acquisition message response including the media presentation description information to the client, the media presentation
  • the description information includes a URL corresponding to the service content
  • receives a service request message GET message sent by the client where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information, and returns a service request to the client.
  • the service request message response includes the service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that the search can be directly performed according to the URL when searching for the content, thereby improving the processing efficiency.
  • the client sends a service information acquisition request to the server.
  • the client requests the Media Presentization Information from the server to obtain the necessary media metadata, where the metadata is the resource description information.
  • the server returns a service information acquisition request response to the client.
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and the fragmentation with each layer.
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content segmentation URL corresponding to this hierarchical content segmentation embodiment can be organized as shown in Table 1:
  • the shards here only correspond to a certain time period content in the shard set, but also allow the data content of the corresponding time period directly included in the shard set to be different, as long as all consecutive contiguous ones corresponding to one shard set
  • the media content included in the contiguous slice is the same as the media content included in the shard set.
  • the client sends a GET message to the server to request the service content.
  • a GET message to the server to request the service content.
  • the considerations for selecting the slice level are user selection, available bandwidth, player cache size, demand for effective media content load rate, server policy, assuming that the slice set shown in Figure 3 is requested here.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the required fragment set, the URL of the required request fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information according to the sequence number of the slice set. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • the specific processing process is related to server implementation and content deployment, and can support different deployment implementations:
  • each slice set URL corresponds to a stored static slice set file (for example, each slice set can be stored as a .3gp file or .mp4 file), and the server directly obtains according to the slice set URL.
  • the corresponding fragment set file is encapsulated in an HTTP response message and sent to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the server returns a corresponding fragment set to the client.
  • Trigger an event to a lower level slice The only thing to consider here is not only the fragmentation triggering event, but the global consideration of all events that switch to lower-level fragments (that is, the duration of each fragment needs to be shorter, and of course the fragmentation set is also included. The case of switching to a slice). After the corresponding event processing is completed or ended, it needs to have corresponding The process or information can inform step 903 that the process of step 903 can determine the level of media slice content for subsequent requests.
  • fragmentation trigger event processing is an example of fragmentation trigger event processing.
  • the client sends a GET message to the server to request fragmentation content.
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete URL information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The fragment URL information corresponding to the sequence number is obtained at the corresponding code rate; the client constructs the HTTP GET request message by using the fragment URL obtained in the above step, and sends the message to the server to request the corresponding content fragmentation.
  • the server returns a corresponding fragment content to the client.
  • FIG. 10 A specific example of a method for implementing hierarchical request content in a http streaming system according to an embodiment of the present invention refers to FIG. 10, which mainly includes the steps:
  • the client sends a service information acquisition request to the server.
  • the client requests the Media Presentation Description information from the server to obtain the necessary Media metadata, where the metadata is the resource description information, where the metadata of the audio and video are separately obtained.
  • the server returns a service information acquisition request response to the client.
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment.
  • the duration information of different layer fragments needs to be provided (optionally, and the next layer of content included)
  • the number such as 1 minute for each slice set (including 30 fragments, or 10 seconds including 10 fragments, or 30 seconds including 15 fragments, etc.), and 2 seconds (or 1 second).
  • 1 minute for each slice set including 30 fragments, or 10 seconds including 10 fragments, or 30 seconds including 15 fragments, etc.
  • 2 seconds or 1 second
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the audio and video content fragmentation URL corresponding to the hierarchical content fragmentation embodiment can be as shown in Table 2:
  • a corresponding content sharding URL embodiment 3 can be organized as follows:
  • Fragment 1_-1 Video URL -> Corresponding Slice 1 Video Content
  • Fragment 1_-2 video URL -> corresponding fragment 2 video content
  • Fragment 1_-3 video URL -> corresponding fragment 3 video content
  • Fragment 1_-3 audio URL -> corresponding fragment 3 audio content fragment 1_M video URL -> corresponding fragment M video content
  • the content of each paragraph is not separated from the audio and video content, and of course it can be separated.
  • the shards here only correspond to a certain time period content in the shard set, but also allow the data content of the corresponding time period directly included in the shard set to be different, as long as all consecutive contiguous ones corresponding to one shard set
  • the media content included in the contiguous slice is the same as the media content included in the shard set.
  • the client sends a GET message requesting a fragment set to the server.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines the URL of the required request fragment set according to the description information and the time information of the required fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set. Obtaining a fragment set corresponding to the sequence number from the complete URL information corresponding to each layer fragment included in the media presentation description information according to the sequence number of the fragment set URL.
  • the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • Each fragment set URL corresponds to a stored static fragment set file (for example, each slice set can be stored as a .3gp file or .mp4 file), the server directly obtains the corresponding slice set file according to the fragment set URL, encapsulates it in the HTTP response message and sends it to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the server returns a corresponding fragment set to the client.
  • the client will determine which slice set the slice of the requested request is located based on the media presentation description information and the time point of the request, and the sequence number in the slice set, thereby determining the URL of the required request slice.
  • the client sends a GET message to the server to request fragmentation content.
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required request fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is a fixed length, according to the fragment set.
  • the duration and the duration information of each fragment (or the number of next-level fragments included in the fragment set), and the sequence number of the corresponding fragment is obtained (for example, the fragment set duration is 30 seconds, and the fragmentation duration is 2 seconds).
  • the fragment to be requested is the 7th fragment from the beginning of the beginning fragmentation, and the 7th fragment is included; if the fragmentation included in the fragmentation set is not fixed length And determining, according to the unified timeline information of the fragmentation in the description information of the media, and the time point information of the request fragment, determining the sequence number of the required request fragment in the corresponding fragment set;
  • the client obtains the fragment URL information corresponding to the sequence number according to the complete phoenix information corresponding to each layer fragment included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment, it is also necessary to combine the sequence number and the code rate information of the fragment, that is, how many code rates should be requested for the next fragment to be requested, and The fragment URL information corresponding to the sequence number is obtained at the corresponding code rate; the client constructs the HTTP GET request message by using the fragment URL obtained in the above step, and sends the message to the server to request the corresponding content fragmentation.
  • the server returns a corresponding fragment content to the client.
  • the server After receiving the request message, the server returns the corresponding content fragment.
  • the real-time example of the present invention adopts a method for implementing layered request content in the http streaming system, receiving a service information acquisition message sent by the client, and returning a service information acquisition message response including the media presentation description information to the client, the media presentation
  • the description information includes a URL corresponding to the service content
  • receives a service request message GET message sent by the client where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information, and returns a service request to the client.
  • the service request message response includes the service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that the search can be directly performed according to the URL when searching for the content, thereby improving the processing efficiency.
  • FIG. 11 A specific example of a method for implementing hierarchical request content in a http streaming system according to an embodiment of the present invention refers to FIG. 11, which mainly includes the steps:
  • the client sends a service information acquisition request to the server.
  • the client requests the Media Presentation Description information from the server to obtain the necessary media metadata, where the metadata is the resource description information.
  • the server returns a service information acquisition request response to the client.
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment timeline information, and a higher-level URL.
  • Information (only includes the URL of the slice set hierarchy, but does not include the URL of the lowest slice);
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content corresponding to the content sharding embodiment according to the hierarchy may be the same or different.
  • the index set 1 index URL (or slice set 1 video index URL/slice set 1 audio index URL) for obtaining the scaly index of all the shards included in the shard set 1 is optional, that is, if not included
  • the client needs to know how to obtain the index of all the fragments included in the fragment set.
  • the scheme can be constructed by adding the corresponding parameter to the URL of the fragment set.
  • Fragment set 1 index URL fragment set 1 URL/segment Index
  • the client sends a GET message requesting a fragment set to the server.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued;
  • the client determines the URL of the required request fragment set according to the description information and the time information of the required fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information. The sequence number of the request fragment set.
  • the slice set URL corresponding to the sequence number is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • Each fragment set URL corresponds to a stored static fragment set file (for example, each slice set can be stored as a .3gp file or .mp4 file), the server directly obtains the corresponding slice set file according to the fragment set URL, encapsulates it in the HTTP response message and sends it to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the server returns a corresponding fragment set to the client.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request.
  • the fragment set, and the sequence number in the fragment set, to determine the URL of the required request fragment the detailed processing flow is shown in Figure 12:
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the fragment set corresponding to the required fragment. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) , to request a slice from the beginning 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, according to the media exhibition
  • the uniform slice time axis information in the information, and the time when the slice falls within the time range of the slice set, are described to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • step 1204 determining whether the media presentation description information includes a fragment set index URL, if it is included, continuing to step 5 below, otherwise jumping to step 6;
  • the media presentation description information includes a fragment set URL corresponding to each layer fragment and a fragment set index URL information, and the fragment set index URL information corresponding to the sequence number may be directly obtained. If the HTTP Streaming scheme supports dynamic rate switching, when determining the fragment set index URL, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, the code rate of the next fragment to be requested. And obtaining a slice set index URL corresponding to the serial number at the corresponding code rate;
  • the client constructs the required fragment set index according to the server consensus, and the construction rule may be given in the description information, for example.
  • This additional parameter can also be constructed in the description by adding additional parameter constructs to the fragment set URL information.
  • the client sends a GET message to the server to request the fragment content.
  • the client uses the fragment set index URL obtained in Figure 12 above to construct a corresponding HTTP GET request; the client sends the constructed HTTP GET request message to the server; the server returns an index with the corresponding fragmented list, that is, The URL of each shard included in the shard set is arranged in order; the client receives the response message sent by the server, and obtains the fragment set index information, that is, the URL list of the shard; the client is in the shard set according to the shard The serial number, and the fragment URL list, determine the URL information of the fragment of the required request; the client constructs the HTTP GET request message by using the fragment URL obtained in the above step, and sends it to the server to request the corresponding content fragmentation.
  • the server returns a corresponding fragment content to the client.
  • the server After receiving the request message, the server returns the corresponding content fragment.
  • the real-time example of the present invention adopts a method for implementing layered request content in the http streaming system, receiving a service information acquisition message sent by the client, and returning a service information acquisition message response including the media presentation description information to the client, the media presentation
  • the description information includes a URL corresponding to the service content, and receives a service request message GET message sent by the client, where the request message includes the client according to the service requirement and the media presentation description information.
  • the service content URL returns a service request message response to the client, where the service request message response includes a service content corresponding to the service content URL determined by the client according to the service requirement and the media presentation description information, so that the content can be found when searching for content Finding directly based on the URL improves processing efficiency.
  • FIG. 13 A specific example of a method for implementing hierarchical request content in the http streaming system according to an embodiment of the present invention refers to FIG. 13 , which mainly includes the steps:
  • the client sends a service information acquisition request to the server.
  • the client requests the Media Presentization Information from the server to obtain the necessary media metadata, where the metadata is the resource description information.
  • the server returns a service information acquisition request response to the client.
  • the server returns the media presentation description information to the client, and the description information includes the duration of each fragment (and the number of sub-content fragments included) or the unified fragment time axis information, and the description information needs to include a hierarchy.
  • the client can directly construct the URL of the next-level resource according to the construction rule and using the phoenix of the superior resource;
  • each slice set may be the same or different; likewise, the duration of each slice in the slice set may be the same or different.
  • the content segmentation URL corresponding to this hierarchical content segmentation embodiment can be organized as shown in Table 1:
  • the shards here only correspond to a certain time period content in the shard set, but also allow the data content of the corresponding time period directly included in the shard set to be different, as long as all consecutive contiguous ones corresponding to one shard set
  • the media content included in the contiguous slice is the same as the media content included in the shard set.
  • the client sends a GET message requesting a fragment set to the server.
  • the client's fragment set request processing flow refers to Figure 4:
  • the client determines whether there is no fragment request trigger event. If there is a fragment request trigger event, the process proceeds to the corresponding fragment trigger event processing flow, otherwise the following steps are continued; 402.
  • the client determines the URL of the required request fragment set according to the description information and the time information of the required fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set to be divided by the duration information of each fragment set is obtained, and the sequence number of the slice set is obtained (for example, the duration of each slice set is 30 seconds) To request a slice set from the beginning 20 minutes, it is the 41st slice set); if the duration of the slice set is not fixed length, it can be determined according to the unified slice time axis information in the media presentation description information.
  • the sequence number of the request fragment set is obtained from the complete phoenix information corresponding to each layer slice included in the media presentation description information. If the HTTP Streaming scheme supports dynamic rate switching, when determining the URL of the fragment set, it is also necessary to combine the sequence number and the code rate information of the fragment set, that is, what code rate the next fragment set to be requested should be. And obtaining the fragment set URL corresponding to the serial number at the corresponding code rate;
  • the client constructs a corresponding HTTP GET request message according to the obtained fragment set URL.
  • the client sends the foregoing HTTP GET request message to the server.
  • the specific processing process is related to server implementation and content deployment, and can support different deployment implementations:
  • each slice set URL corresponds to a stored static slice set file (for example, each slice set can be stored as a .3gp file or .mp4 file), and the server directly obtains according to the slice set URL.
  • the corresponding fragment set file is encapsulated in an HTTP response message and sent to the client;
  • the content of the slice set corresponding to each fragment set URL is static, that is, different clients send HTTP request messages constructed by the same slice set URL, and the obtained slice set contents are completely the same.
  • multiple slice sets can be continuously stored in the same large file.
  • the server maps the location and length information of the slice set in the large file according to the URL information, and dynamically dynamically serves the client request. Extracting the required fragment set content from the file storing multiple fragment sets, encapsulating it in an HTTP response message and sending it to the client;
  • the client waits for the server to return a response message.
  • the server returns a corresponding fragment set to the client.
  • the client will determine which fragment of the requested request is located according to the media presentation description information and the time point of the request. The fragment set, and the sequence number in the fragment set, to determine the URL of the required request fragment. If there is a fragment request trigger event (such as just starting playback, Seek operation, bandwidth change requires code rate switching, etc.), the client The terminal will determine which fragment set the fragment of the request is located according to the media presentation description information and the time point of the request, and the sequence number in the fragment set, and then determine the URL of the required request fragment.
  • the detailed processing flow is as shown in FIG. 14 Show:
  • the client determines whether there is a fragment request trigger event. If no fragment request triggers the event, the process proceeds to the corresponding fragment set request processing flow, otherwise the following steps are continued;
  • the client determines, according to the description information and the time information of the fragment to be requested, the corresponding request fragment. Fragment set. If the duration of the fragment set is fixed length, the time information of the fragment set and the duration information of each fragment set may be requested to obtain the sequence number of the corresponding slice set (for example, each slice set duration is 30 seconds) To request a slice from the beginning of 30 minutes and 12 seconds, it is the 61st slice); if the duration of the slice set is not fixed length, the unified slice time axis information in the description information according to the media presentation, and The slice falls within the time range of the slice set to determine the sequence number of the required request slice set;
  • the duration of the fragment included in the determined fragment set is fixed length, according to the duration of the fragment set and the duration information of each fragment (or the next level included in the fragment set) Number of slices), get the sequence number of the corresponding slice (for example, the slice set duration is 30 seconds, the slice length is 2 seconds (or the slice set includes 15 fragments), and the requested slice distance starts fragmentation. If the beginning of the set is 12 seconds, it is the 7th slice; if the slice includes the duration of the slice is not fixed length, according to the media presentation description information, the unified slice time axis information, and the requested slice Time point information to determine the sequence number of the required request fragment in the corresponding fragment set;
  • the client directly constructs the corresponding fragment URL according to the construction rule of the hierarchical URL included in the media description information, the URL information of the fragment set, and the sequence number of the fragment in the corresponding fragment set.
  • the URL of the 100th content shard set with a code rate of 400K is as follows: http : //HDvideo. foo. com/NBA. 3gp/QualityLevels (400000) /SegmentAggregates (100) Description of the obtained media In the information, if the phoenix construction rule is added on the basis of the fragment set URL
  • Http //HDvideo. foo. com/NBA. 3gp/QualityLevels (400000) /SegmentAggregates ( 100) /Segment (X)
  • X is the sequence number of the slice determined in the above step 3 in the corresponding slice set.
  • the client sends a GET message to the server to request the fragment content.
  • the client constructs an HTTP GET request message by using the fragment URL obtained in step 1405 above, and sends it to the server to request the corresponding content fragmentation.
  • the server returns a corresponding fragment content to the client.
  • the server After receiving the request message, the server returns the corresponding content fragment.
  • the real-time example of the present invention adopts a method for implementing layered request content in the http streaming system, receiving a service information acquisition message sent by the client, and returning a service information acquisition message response including the media presentation description information to the client, the media presentation
  • the description information includes a URL corresponding to the business content, and receives the industry sent by the client.
  • the service request message GET message where the request message includes a service content URL determined by the client according to the service requirement and the media presentation description information, and returns a service request message response to the client, where the service request message response includes the client according to the service
  • the demand and the media display the service content corresponding to the service content URL determined by the description information, so that the search can be directly performed according to the URL when searching for the content, thereby improving the processing efficiency.

Description

一种在 hup streaming系统中实现分层请求内容的方法， 装置和系统
本申请要求于 2009年 11月 09日提交中国专利局、 申请号为 200910110054. 2、 发 明名称为 "一种在 http streaming系统中实现分层请求内容的方法， 装置和系统" 的 中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及网络通信技术领域， 尤其涉及一种在 http streaming系统中实现分层 请求内容的方法， 装置和系统。
背景技术
用户使用终端设备获取多媒体内容并进行播放的方式有多种， 典型的有通过 HTTP 文件下载或者 P2P 文件下载到本地磁盘后播放、 传统的流媒体方式 （数据传输的 RTP/RTCP和播放控制 RTSP)、 P2P流媒体方式的在线直播 /点播、 HTTP渐进式下载（HTTP Progressive Download) 等等。
HTTP渐进式下载则是对 HTTP文件下载方式的一种改进， 它可以让终端设备边下载 边播放， 而无需等到整个文件下载完成后才能够进行播放， 播放启动时间也不太长。 其 实现原理是对媒体内容进行分片， 一个 （/一组） 内容分片能够在终端设备进行独立解 码， 而不用依赖其他分片。 这样， 服务器和客户端之间每次只要传输一个 （/一组） 内 容分片， 终端设备接收到之后可以解码播放， 同时还可接收下一个（/一组） 内容分片。 这种方式将媒体文件的处理粒度从整个文件调整为其中一个内容分片， 典型的内容分片 播放时长可以是几秒， 例如广 10秒。
HTTP协议是无状态协议，基于 HTTP协议构造的 HTTP Streaming方案也因此能取得 简单易实现的优点： 每次的 HTTP请求和响应都能构成一个与其他 HTTP请求 /响应独立 的事务（transactions 但这同时也对这种方案提出了这样的需求： 每次为获得一个媒 体内容分片， 客户端需要主动向服务器发送一个 HTTP请求， HTTP服务器为客户端的请 求服务并返回包括相应内容分片的响应消息。
这样服务器在对媒体内容进行分片的时候， 就需要衡量究竟应该如何分割多大（多 少时长） 的内容分片：
如果每个内容分片较大（时长较长）， 在启动播放和 Seek操作时客户端需要较长时 间来获取和缓冲内容分片。 另外， 由于 HTTP协议没有取消机制， 一旦开始传输内容分 片就需要传输完 （当然也可关闭 TCP连接并重建 TCP连接， 但这样会引起额外负担）， 较长的分片时长也会影响码率切换响应的及时性， 因为码率切换至少是以分片作为最小 单位的；
如果每个内容分片较小 （时长较短）， 那么客户端将需要频繁向服务器发起请求， 较多的 HTTP请求消息将使上行链路带宽占用增加， 同时还会造成服务器处理请求的负 担加重， 以及每个 HTTP响应中包括的有效媒体内容的降低， 造成有效媒体传输率下降。 现有技术中， 高通提出可以将多个连续的内容分片封装到一个分片集 （Segment Aggregates )文件内， 客户端可以获取完整的分片集， 或者根据需要通过分片集的元数 据来获得分片集中所包括分片在分片集内的分布情况和位置信息， 并通过 partial GET 方式请求获取分片数据。
分片集 （Segment Aggregates ) 是处于整个媒体内容和最基本组成内容分片两者之 间的一种结构， 以期获得比以前更大的灵活性。 在这种情况下， 客户端对媒体内容的获 取流程可以概括如下图所示：
步骤广 2: 客户端向服务器请求 Media Presentation Description信息， 获取必要 的媒体元数据信息， 并可借助这些信息产生后续的媒体内容请求； 服务器向客户端返回 描述信息， 包括分片集层次的时间信息， 以及能获取到分片集的 URL信息， 等；
步骤; Γ4: 客户端按照描述信息中的分片集 URL， 用 HTTP GET请求的方式请求相应 的分片集； 服务器收到这样的请求消息后， 返回对应的分片集；
步骤 5: 如果有分片请求触发事件（如刚启动播放、 Seek操作、 带宽变动导致需要 进行码率切换等） 发生， 将确定所需请求的分片位于哪个分片集；
步骤^ 7: 客户端按照确定的分片集 URL的， 用 partial GET请求的方式请求分片 集的初始部分 （initial potion, 描述分片集的元数据信息需要位于分片集的头部）， 可以先请求约 1000个字节； 服务器收到请求消息后， 返回包括元数据信息的分片集初 始部分（如果客户端所需要的元数据信息并没有包括在返回的响应消息中， 客户端可以 确定还需请求的字节范围并再发一个请求，服务器将把剩余的分片集元数据信息发送给 客户端）；
步骤 8: 客户端解析并处理分片集的元数据信息， 获得所需分片在分片集中的位置 信息 （起始位置和分片长度）；
步骤纩10： 客户端利用分片集 URL以及分片在分片集中的位置信息， 采用 partial GET的方式请求分片集内某个分片； 服务器在响应消息中返回对应的分片数据。
上述步骤; Γ4、 5〜10发生的先后顺序视实际的播放过程而定， 并可根据实际需要重 复多次。
现有技术一为了获取分片集的元数据信息， 以及分片集内所包括的内容分片， 需要 终端和服务器支持 HTTP协议的 partial GET操作,但目前存在部分服务器 （特别是内容 分发网络边缘的缓存服务器） 或终端不能支持 partial GET。 如果内容分发网络边缘的 缓存服务器不能支持 part ial GET, 可能需要将收到的 part ial GET请求转发给服务器 处理， 将无法缓存该响应， 并且会增加请求的响应时间； 其次， 客户端在需要请求分片 时， 首先要从服务器请求分片集的元数据， 分析处理获得的元数据信息， 在得到分片的 位置信息之后才能构造相应的 part ial GET请求， 处理效率较低。 但是， HTTP协议对于 part ial GET的支持并不是必须的， 暂且不论互联网中已经广 泛部署的 HTTP服务器和缓存设备可能会包括较早的只支持 HTTP 1. 0协议的服务器， 就 算在 HTTP 1. 1 协议 RFC2616 中， 其对 part ial GET 的规范部分有文字明确指出： "A server MAY ignore the Range header. "，并且也没有使用 RFC中强制必须支持的" MUST "、 " SHALL "^" SHOULD ",而只是给出建议" ought to support byte ranges when poss ible 因此采用 part ial GET方案， 在某些网络环境中就可能会遇到不支持或不兼容的情况。 发明内容
一种在 http streaming系统中实现分层请求内容的方法， 包括， 接收客户端发送 的业务信息获取请求； 向客户端返回包含媒体展现描述信息的业务信息获取请求响应， 媒体展现描述信息中包含与多层次业务内容对应的 URL; 接收客户端发送的业务请求消 息 GET消息，请求消息中包含客户端根据业务需求和媒体展现描述信息确定的多层次业 务内容的 URL; 向客户端返回业务请求消息响应， 业务请求消息响应中包含与客户端根 据业务需求和媒体展现描述信息确定的业务内容鳳对应的业务内容；
一种服务器， 包括， 接收模块， 用于接收客户端发送的业务信息获取请求； 业务信 息发送模块， 用于向客户端返回包含媒体展现描述信息的业务信息获取请求响应， 媒体 展现描述信息中包含与业务内容对应的 URL; 业务请求接收模块，用于接收客户端发送 的业务请求消息 GET消息，请求消息中包含客户端根据业务需求和媒体展现描述信息确 定的业务内容 URL; 业务内容发送模块， 用于向客户端返回业务请求消息响应， 业务请 求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容 URL对应 的业务内容。
一种在 http streaming系统中实现分层请求内容的系统， 包括， 服务器， 用于接 收客户端发送的业务信息获取请求； 向客户端返回包含媒体展现描述信息的业务信息获 取请求响应，媒体展现描述信息中包含与业务内容对应的 URL; 接收客户端发送的业务 请求消息 GET消息，请求消息中包含客户端根据业务需求和媒体展现描述信息确定的分 片 URL; 向客户端返回业务请求消息响应， 业务请求消息响应中包含与客户端根据业务 需求和媒体展现描述信息确定的业务内容 URL对应的业务内容； 客户端， 用于向服务器 发送业务信息获取请求； 在获得服务器返回的包含与业务内容对应的 URL媒体展现描述 信息后， 向服务器发送包含根据业务需求和媒体展现描述信息确定的业务内容 URL的业 务请求消息 GET消息。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施例或现有 技术描述中所需要使用的附图作一简单地介绍， 显而易见地， 下面描述中的附图是本发 明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还 可以根据这些附图获得其他的附图。
图 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系统中实现分层请求内容的方法的基本流 Al、 接收客户端发送的业务信息获取请求；
客户端向服务器请求 Media Presentat ion Descript ion信息， 以获取必要的媒体 元数据， 这里的元数据即为资源描述信息。
A2、 向客户端返回包含媒体展现描述信息的业务信息获取请求响应， 所述媒体展现 描述信息中包含与业务内容对应的 URL ;
服务器向客户端返回媒体展现描述信息， 描述信息中需包括各级分片的时长（及所 包括的下一级内容分片数目）信息或者统一的分片时间轴信息， 以及与各层次分片对应 的完整的 URL信息；
在提供媒体描述信息时， 如果同一层次（粒度） 的分片在时长上完全相同， 则只需 要提供不同层次分片的时长信息 （可选的， 还有所包括的下一层内容分片的数目）， 如 每个分片集 1分钟 （包括 30个分片， 或 10秒包括 10个分片， 或 30秒包括 15个分片 等）、 分片 2秒 （或 1秒）。 对于按照定长进行内容分片的情况， 如果最后一个段落或分 片集跟前面同层次的分片在时长上不一样， 需单独提供针对性的描述信息。 如果同层次 (粒度） 的分片在时长上不完全相同， 则需要提供一份统一的、 有关整个媒体内容分片 情况的时间轴信息。 一个定长分片的实施例如图 3所示：
在图 3中每个分片集的时长可以相同， 或者不同； 同样， 分片集中每个分片的时长 可以相同， 或者不同。 相应的， 与这个按照层次式进行内容分片实施例相对应的内容分
Figure imgf000007_0001
URL —— > 码率 1段落 3对应的内容分片 可选码率 2 URL 其他可选码率 URL
表 1 这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括 的相应时间段的数据内容不完全相同， 只要所有连续的、 对应于一个分片集的各个连续 分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
A3、 接收客户端发送的业务请求消息 GET消息， 所述请求消息中包含客户端根据业 务需求和媒体展现描述信息确定的业务内容 URL;
客户端按照描述信息中的分片集 URL， 以及所需请求的分片集的时间信息， 用 HTTP
GET请求的方式请求相应的分片集；服务器收到这样的请求消息后，返回对应的分片集, 客户端的分片集请求处理流程参考图 4:
401、 客户端判断是否无分片请求触发事件， 若有分片请求触发事件， 则转到相应 的分片触发事件处理流程， 否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的 URL。 如果是分片集的时长是定长的， 可根据需请求分片集的时间信息除以每个分片集的时长 信息， 得到分片集的序号 （例如每个分片集时长为 30秒， 要请求距开始 20分钟的分片 集， 则为第 41个分片集）； 如果分片集的时长不是定长的， 可根据媒体展现描述信息中 统一的分片时间轴信息确定所需请求分片集的序号。 根据分片集的序号， 从媒体展现描 述信息中所包括的与各层次分片对应的完整的 鳳 信息获取与该序号对应的分片集 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、 向客户端返回业务请求消息响应， 所述业务请求消息响应中包含与客户端根据 业务需求和媒体展现描述信息确定的业务内容鳳对应的业务内容；
服务器收到该请求消息后， 返回对应的内容分片。 本发明实时例采用一种在 http streaming系统中实现分层请求内容的方法， 接收 客户端发送的业务信息获取消息， 向客户端返回包含媒体展现描述信息的业务信息获取 消息响应， 所述媒体展现描述信息中包含与业务内容对应的 URL， 接收客户端发送的业 务请求消息 GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确 定的业务内容 URL， 向客户端返回业务请求消息响应， 所述业务请求消息响应中包含与 客户端根据业务需求和媒体展现描述信息确定的业务内容 URL对应的业务内容， 使得在 查找内容时可直接根据 URL进行查找， 提高了处理效率。
本发明实施例的一种服务器的基本框图可参考图 6， 主要包括：
接收模块 601，用于接收客户端发送的业务信息获取请求客户端向服务器请求 Media Presentat ion Descript ion信息， 以获取必要的媒体元数据， 这里的元数据即为资源描 述信息；
业务信息发送模块 602， 用于向客户端返回包含媒体展现描述信息的业务信息获取 请求响应，所述媒体展现描述信息中包含与业务内容对应的 URL ;业务信息发送模块 602 向客户端返回媒体展现描述信息， 描述信息中需包括各级分片的时长（及所包括的下一 级内容分片数目）信息或者统一的分片时间轴信息，以及与各层次分片对应的完整的 URL 自 .
I Ή、；
在提供媒体描述信息时， 如果同一层次（粒度） 的分片在时长上完全相同， 则只需 要提供不同层次分片的时长信息 （可选的， 还有所包括的下一层内容分片的数目）， 如 每个分片集 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。 如果 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发送的业务信息获取请求客户端 向服务器请求 Media Presentat ion Descript ion信息， 以获取必要的媒体元数据， 这 里的元数据即为资源描述信息； 向客户端 702返回包含媒体展现描述信息的业务信息获 取请求响应，所述媒体展现描述信息中包含与业务内容对应的鳳描述信息中需包括各 级分片的时长（及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息， 以 及与各层次分片对应的完整的鳳信息；
在提供媒体描述信息时， 如果同一层次（粒度） 的分片在时长上完全相同， 则只需 要提供不同层次分片的时长信息 （可选的， 还有所包括的下一层内容分片的数目）， 如 每个分片集 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。 如果 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时， 还需要将分片的序号和码率信息结合起来， 即下一个要请求的 分片应该是多少码率的， 并在相应的码率下获取到序号对应的分片鳳信息。
本发明实时例采用一种在 http streaming系统中实现分层请求内容的系统， 服务 器 701接收客户端 702发送的业务信息获取消息，服务器 701向客户端 702返回包含媒 体展现描述信息的业务信息获取消息响应，所述媒体展现描述信息中包含与业务内容对 应的 URL，服务器 70接收客户端 702发送的业务请求消息 GET消息，所述请求消息中包 含客户端 702根据业务需求和媒体展现描述信息确定的业务内容鳳， 服务器 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。 如果 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系统中实现分层请求内容的方法的一个具
901、 客户端向服务器发送业务信息获取请求；
客户端向服务器请求 Media Presentat ion Descript ion信息， 以获取必要的 媒体元数据， 这里的元数据即为资源描述信息
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。 如果 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信息， 下面以音频为例， 视频类似。
在提供媒体描述信息时， 如果同一层次（粒度） 的分片在时长上完全相同， 则只需 要提供不同层次分片的时长信息 （可选的， 还有所包括的下一层内容分片的数目）， 如 每个分片集 1分钟 （包括 30个分片， 或 10秒包括 10个分片， 或 30秒包括 15个分片 等）、 分片 2秒 （或 1秒）。 对于按照定长进行内容分片的情况， 如果最后一个段落或分 片集跟前面同层次的分片在时长上不一样， 需单独提供针对性的描述信息。 如果同层次
(粒度） 的分片在时长上不完全相同， 则需要提供一份统一的、 有关整个媒体内容分片 情况的时间轴信息。 一个定长分片的实施例如图 3所示：
在图 3中每个分片集的时长可以相同， 或者不同； 同样， 分片集中每个分片的时长 可以相同， 或者不同。 相应的， 与这个按照层次式进行内容分片实施例相对应的音视频 内容分片 URL可以如表 2所示：
内容的 URL。 一个对应的内容分片 URL实施例 3可以组织如下：
—— "^Y — 丽^"
段落 1 URL —— > 码率 1段落 1对应的内容分片
分片集 1视频 URL—— > 对应分片集 1视频内容
分片集 1音频 URL —— > 对应分片集 1音频内容
分片 1_ — 1视频 URL —— >对应分片 1视频内容
分片 1_ — 1音频 URL —— >对应分片 1音频内容
分片 1_ —2视频 URL —— >对应分片 2视频内容
分片 1_ —2音频 URL —— >对应分片 2音频内容
分片 1_ —3视频 URL —— >对应分片 3视频内容
分片 1_ —3音频 URL —— >对应分片 3音频内容 分片 1_M视频 URL ->对应分片 M视频内容
分片 1_M音频 URL ->对应分片 M音频内容
分片集 2视频 URL —— 对应分片集 2视频内容
分片集 2音频 URL —— 对应分片集 2音频内容 分片集 3视频 URL — > 对应分片集 3视频内容
分片集 3音频 URL —— > 对应分片集 3音频内容 分片集 N视频 URL —— > 对应分片集 N视频内容
分片集 N音频 URL —— > 对应分片集 N音频内容
URL —— > 码率 1段落 2对应的内容分片 段落 3 URL 码率 1段落 3对应的内容分片 可选码率 2 URL i 其他可选码率 URL ……
上表中， 对每个段落的内容没有将音视频内容分开， 当然也可以分开。 这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括 的相应时间段的数据内容不完全相同， 只要所有连续的、 对应于一个分片集的各个连续 分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
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信息。 如果 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中每个分片集的时长可以相同， 或者不同； 同样， 分片集中每个分片的时长 可以相同， 或者不同。 相应的， 与这个按照层次式进行内容分片实施例相对应的内容分
Figure imgf000025_0001
表 3
§丄 nd—t UR „ ^ l u L„i春丄 £ - i^^
Figure imgf000025_0002
表 4 或者， 在音频内容和视频内容分开的情况下， 通过分片集 1视频 index URL， 获取 到如下的 URL列表， 如表 5所示：
分片 1_1视频 URL >对应分片 1视频内容
分片 1_2视频 URL >对应分片 2视频内容
分片 1 3视频 URL >对应分片 3视频内容 分片 1 M视频 URL >对应分片 M视频内容
表 5
通过分片集 1音频 index URL, 获取到如下的 URL列表： 分片 1_2音频 URL — >对应分片 2音频内容
分片 1_3音频 URL —— >对应分片 3音频内容 分片 1_M音频 URL —— >对应分片 M音频内容 表 6
为获取分片集 1所包括的所有分片的鳳索引的分片集 1 index URL (或分片集 1 视频 index URL/分片集 1音频 index URL) 是可选的， 即如果不包括的话， 客户端需 要知道如何获取分片集所包括的所有分片的鳳索引，例如可以通过分片集的 URL加相 应参数构造的方案， 一种可能的实施例如下：
构造： 分片集 1 index URL = 分片集 1 URL?id=segmentIndex
或者层次式 URL:
分片集 1 index URL = 分片集 1 URL/segment Index
1103、 客户端向服务器发送 GET消息请求分片集；
客户端的分片集请求处理流程参考图 4:
401、 客户端判断是否无分片请求触发事件， 若有分片请求触发事件， 则转到相应 的分片触发事件处理流程， 否则继续下面步骤；
402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的 URL。 如果是分片集的时长是定长的， 可根据需请求分片集的时间信息除以每个分片集的时长 信息， 得到分片集的序号 （例如每个分片集时长为 30秒， 要请求距开始 20分钟的分片 集， 则为第 41个分片集）； 如果分片集的时长不是定长的， 可根据媒体展现描述信息中 统一的分片时间轴信息确定所需请求分片集的序号。 根据分片集的序号， 从媒体展现描 述信息中所包括的与各层次分片对应的完整的 鳳 信息获取与该序号对应的分片集 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信息加上额外的参数构造，这个附加的参数也需在描述信息 中给出。
1106、 客户端向服务器发送 GET消息请求分片内容；
客户端利用上述图 12得到的分片集索引 URL， 构造相应的 HTTP GET请求；； 客户 端将构造得到的 HTTP GET请求消息发送给服务器； 服务器返回与相应的分片鳳列表 索引， 也即在分片集中所包括的每个分片的 URL按顺序排列的列表； 客户端接收服务器 发送的响应消息， 获得分片集索引信息， 即分片的 URL列表； 客户端根据分片在分片集 中的序号， 以及分片 URL列表， 确定所需请求的分片的 URL信息； 客户端利用上述步骤 获得的分片 URL， 构造 HTTP GET请求消息， 并发送给服务器以请求相应的内容分片。
1107、 服务器向客户端返回对应的分片内容；
服务器收到该请求消息后， 返回对应的内容分片。
本发明实时例采用一种在 http streaming系统中实现分层请求内容的方法， 接收 客户端发送的业务信息获取消息， 向客户端返回包含媒体展现描述信息的业务信息获取 消息响应， 所述媒体展现描述信息中包含与业务内容对应的 URL， 接收客户端发送的业 务请求消息 GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确 定的业务内容 URL， 向客户端返回业务请求消息响应， 所述业务请求消息响应中包含与 客户端根据业务需求和媒体展现描述信息确定的业务内容 URL对应的业务内容，使得在 查找内容时可直接根据 URL进行查找， 提高了处理效率。 本发明实施例的一种在 http streaming系统中实现分层请求内容的方法的一个具 体设施例参考图 13， 主要包括步骤：
1301、 客户端向服务器发送业务信息获取请求；
客户端向服务器请求 Media Presentat ion Descript ion信息， 以获取必要的 媒体元数据， 这里的元数据即为资源描述信息
1302、 服务器向客户端返回业务信息获取请求响应；
服务器向客户端返回媒体展现描述信息， 描述信息中需包括各级分片的时长 (及所包括的下一级内容分片数目）信息或者统一的分片时间轴信息， 描述信息中需包 括层次式鳳的构造规则， 客户端可以根据该构造规则并利用上级资源的鳳直接构造 其下一级资源的 URL ;
在提供媒体描述信息时， 如果同一层次（粒度） 的分片在时长上完全相同， 则只需 要提供不同层次分片的时长信息 （可选的， 还有所包括的下一层内容分片的数目）， 如 每个分片集 1分钟 （包括 30个分片， 或 10秒包括 10个分片， 或 30秒包括 15个分片 等）、 分片 2秒 （或 1秒）。 对于按照定长进行内容分片的情况， 如果最后一个段落或分 片集跟前面同层次的分片在时长上不一样， 需单独提供针对性的描述信息。 如果同层次 (粒度） 的分片在时长上不完全相同， 则需要提供一份统一的、 有关整个媒体内容分片 情况的时间轴信息。 一个定长分片的实施例如图 3所示：
在图 3中每个分片集的时长可以相同， 或者不同； 同样， 分片集中每个分片的时长 可以相同， 或者不同。 相应的， 与这个按照层次式进行内容分片实施例相对应的内容分 片 URL可以组织如表 1所示：
这里的分片只是对应于分片集中的某一时间段内容，但也允许与分片集中直接包括 的相应时间段的数据内容不完全相同， 只要所有连续的、 对应于一个分片集的各个连续 分片所包括的媒体内容与该分片集所包括的媒体内容相同即可。
1303、 客户端向服务器发送 GET消息请求分片集；
客户端的分片集请求处理流程参考图 4 :
401、 客户端判断是否无分片请求触发事件， 若有分片请求触发事件， 则转到相应 的分片触发事件处理流程， 否则继续下面步骤； 402、客户端根据描述信息和需请求分片集的时间信息，确定所需请求分片集的 URL。 如果是分片集的时长是定长的， 可根据需请求分片集的时间信息除以每个分片集的时长 信息， 得到分片集的序号 （例如每个分片集时长为 30秒， 要请求距开始 20分钟的分片 集， 则为第 41个分片集）； 如果分片集的时长不是定长的， 可根据媒体展现描述信息中 统一的分片时间轴信息确定所需请求分片集的序号。 根据分片集的序号， 从媒体展现描 述信息中所包括的与各层次分片对应的完整的 鳳 信息获取与该序号对应的分片集 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) /SegmentAggregates (100) 在获取的媒体展现描述信息中， 如果鳳构造规则为在分片集 URL的基础上再增加
"/Segment (分片序号），，， 则可以构造出分片的鳳如下：
http : //HDvideo. foo. com/NBA. 3gp/QualityLevels (400000) /SegmentAggregates ( 100) /Segment (X)
这里 X为上述步骤 3中所确定的分片在对应分片集中的序号。
1306、 客户端向服务器发送 GET消息请求分片内容；
客户端利用上述 1405步骤获得的分片 URL， 构造 HTTP GET请求消息， 并发送给服 务器以请求相应的内容分片。
1307、 服务器向客户端返回对应的分片内容；
服务器收到该请求消息后， 返回对应的内容分片。
本发明实时例采用一种在 http streaming系统中实现分层请求内容的方法， 接收 客户端发送的业务信息获取消息， 向客户端返回包含媒体展现描述信息的业务信息获取 消息响应， 所述媒体展现描述信息中包含与业务内容对应的 URL， 接收客户端发送的业 务请求消息 GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述信息确 定的业务内容 URL， 向客户端返回业务请求消息响应， 所述业务请求消息响应中包含与 客户端根据业务需求和媒体展现描述信息确定的业务内容 URL对应的业务内容，使得在 查找内容时可直接根据 URL进行查找， 提高了处理效率。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以 通过程序来指令相关的硬件来完成， 该程序可以存储于计算机可读存储介质中， 存储介 质可以包括： R0M、 RAM, 磁盘或光盘等。
以上对本发明实施例所提供的限制主叫用户呼叫的方法、 系统和装置， 本文中应用 了具体个例对本发明的原理及实施方式进行了阐述， 以上实施例的说明只是用于帮助理 解本发明的方法及其核心思想； 同时，对于本领域的一般技术人员，依据本发明的思想， 在具体实施方式及应用范围上均会有改变之处， 综上所述， 本说明书内容不应理解为对 本发明的限制。

Claims

权利要求
1、 一种在 http streaming系统中实现分层请求内容的方法， 其特征在于： 接收客户端发送的业务信息获取请求；
向客户端返回包含媒体展现描述信息的业务信息获取请求响应，所述媒体展现描述 信息中包含与多层次业务内容对应的 URL;
接收客户端发送的业务请求消息 GET消息，所述请求消息中包含客户端根据业务需 求和媒体展现描述信息确定的多层次业务内容的 URL;
向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务 需求和媒体展现描述信息确定的多层次业务内容的鳳对应的业务内容。
2、 如权利要求 1所述的方法， 其特征在于，
所述多层次业务内容至少包括， 分片， 分片集， 段落；
所述媒体展现描述信息中包含与多层次业务内容对应的鳳具体为：
至少为分片， 分片集， 段落分配对应的 URL;
3、 如权利要求 2所述的方法， 其特征在于，
所述请求消息中包含客户端根据业务需求和媒体展现描述信息确定的业务内容 URL 具体为：
客户端根据据业务需求和媒体展现描述信息确定分片集中的分片对应的 URL;
4、 如权利要求 3所述的方法， 其特征在于， 所述向客户端返回业务请求消息响应， 所述业务请求消息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务 内容 URL对应的业务内容具体包括，
当客户端根据业务需求和媒体展现描述信息确定的业务内容鳳为户端根据据业务 需求和媒体展现描述信息确定的分片对应的鳳时， 将分片发送给客户端；
5、 如权利要求 2所述的方法， 其特征在于， 所述客户端根据业务需求和媒体展现 描述信息确定分片集中的分片对应的鳳具体为：
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集；
客户端确定分片在所述分片集中对应的序号；
客户端根据媒体展现描述信息获取所述分片对应的 URL。
6、 如权利要求 2所述的方法， 其特征在于， 所述客户端根据业务需求和媒体展现 描述信息确定分片集中的分片对应的鳳具体为；
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集；
客户端确定分片在所述分片集中对应的序号；
客户端获取分片集中的分片索引信息； 客户端根据分片索引信息获取所述分片对应的 URL。
7、 如权利要求 2所述的方法， 其特征在于， 所述客户端根据业务需求和媒体展现 描述信息确定分片集中的分片对应的鳳具体为；
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集和分片集对应的 URL;
客户端确定分片在所述分片集中对应的序号；
客户端根据媒体展现描述信息中的鳳构造规则， 构造分片对应的 URL。
8、 如权利要求 1所述的方法， 其特征在于， 所述媒体展现描述信息进一步包括不 同的多层次业务内容对应的 URL;
9、 如权利要求 1所述的方法， 其特征在于， 所述方法进一步包括， 接收客户端发 送的业务请求消息 GET消息，所述请求消息中包含客户端根据业务需求和媒体展现描述 信息确定的不同多层次业务内容的 URL;
向客户端返回业务请求消息响应，所述业务请求消息响应中包含与客户端根据业务 需求和媒体展现描述信息确定的不同多层次业务内容的鳳对应的不同业务内容。
10、 一种服务器， 其特征在于， 所述服务器包括，
接收模块， 用于接收客户端发送的业务信息获取请求；
业务信息发送模块，用于向客户端返回包含媒体展现描述信息的业务信息获取请求 响应， 所述媒体展现描述信息中包含与业务内容对应的 URL;
业务请求接收模块， 用于接收客户端发送的业务请求消息 GET消息， 所述请求消息 中包含客户端根据业务需求和媒体展现描述信息确定的业务内容 URL;
业务内容发送模块， 用于向客户端返回业务请求消息响应， 所述业务请求消息响应 中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容 鳳 对应的业务内 容。
11、 如权利要求 10所述的服务器， 其特征在于， 所述服务器进一步包括， 分层模块， 用于将媒体资源至少分成以下播放单元， 分片， 分片集， 段落。
12、 如权利要求 10所述的服务器， 其特征在于， 所述服务器进一步包括， 分配模块， 至少用于为， 分片， 分片集， 段落分配 URL。
13、 一种在 http streaming系统中实现分层请求内容的系统， 其特征在于， 所述 系统包括，
服务器， 用于接收客户端发送的业务信息获取请求； 向客户端返回包含媒体展现描 述信息的业务信息获取请求响应，所述媒体展现描述信息中包含与业务内容对应的 URL; 接收客户端发送的业务请求消息 GET消息，所述请求消息中包含客户端根据业务需求和 媒体展现描述信息确定的分片 URL; 向客户端返回业务请求消息响应， 所述业务请求消 息响应中包含与客户端根据业务需求和媒体展现描述信息确定的业务内容 URL对应的业 务内容；
客户端， 用于向服务器发送业务信息获取请求； 在获得服务器返回的包含与业务内 容对应的鳳媒体展现描述信息后， 向所述服务器发送包含根据业务需求和媒体展现描 述信息确定的业务内容 URL的业务请求消息 GET消息。
14、 如权利要求 13所述的系统， 其特征在于， 所述根据业务需求和媒体展现描述 信息确定的业务内容 URL具体为：
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集；
客户端确定分片在所述分片集中对应的序号；
客户端根据媒体展现描述信息获取所述分片对应的 URL。
15、 如权利要求 13所述的系统， 其特征在于， 所述根据业务需求和媒体展现描述 信息确定的业务内容 URL具体为：
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集；
客户端确定分片在所述分片集中对应的序号；
客户端获取分片集中的分片索引信息；
客户端根据分片索引信息获取所述分片对应的 URL。
16、 如权利要求 13所述的系统， 其特征在于， 所述根据业务需求和媒体展现描述 信息确定的业务内容 URL具体为；
客户端根据业务需求和媒体展现描述信息确定分片对应的分片集和分片集对应的
URL;
客户端确定分片在所述分片集中对应的序号；
客户端根据 URL构造规则， 构造分片对应的 URL。
PCT/CN2010/078518 2009-11-09 2010-11-08 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统 WO2011054319A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP10827933.2A EP2493191B1 (en) 2009-11-09 2010-11-08 Method, device and system for realizing hierarchically requesting content in http streaming system
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 (2)

Application Number Priority Date Filing Date Title
CN200910110054.2A CN102055718B (zh) 2009-11-09 2009-11-09 一种在http streaming系统中实现分层请求内容的方法,装置和系统
CN200910110054.2 2009-11-09

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/467,738 Continuation US20120221681A1 (en) 2009-11-09 2012-05-09 Method, apparatus and system for hierarchically requesting contents in a http streaming system

Publications (1)

Publication Number Publication Date
WO2011054319A1 true WO2011054319A1 (zh) 2011-05-12

Family

ID=43959653

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/078518 WO2011054319A1 (zh) 2009-11-09 2010-11-08 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统

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)

* Cited by examiner, † Cited by third party
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
CN105379293B (zh) * 2013-04-19 2019-03-26 华为技术有限公司 基于超文本协议的动态自适应流媒体中的媒体质量信息指示
BR112015025871A8 (pt) * 2013-04-19 2019-12-31 Sony Corp dispositivo servidor, método, e, mídia legível por computador não-transitória
CN105409226B (zh) * 2013-07-25 2018-05-04 华为技术有限公司 有效控制自适应流媒体中的客户端行为的系统和方法
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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1902865A (zh) * 2003-11-07 2007-01-24 诺基亚有限公司 从服务器到客户的流式传输
CN101193273A (zh) * 2006-11-20 2008-06-04 中兴通讯股份有限公司 一种实时多媒体图像信息存储和播放方法
CN101287107A (zh) * 2008-05-29 2008-10-15 腾讯科技（深圳）有限公司 媒体文件的点播方法、系统和设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
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
US8914835B2 (en) * 2009-10-28 2014-12-16 Qualcomm Incorporated Streaming encoded video data

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1902865A (zh) * 2003-11-07 2007-01-24 诺基亚有限公司 从服务器到客户的流式传输
CN101193273A (zh) * 2006-11-20 2008-06-04 中兴通讯股份有限公司 一种实时多媒体图像信息存储和播放方法
CN101287107A (zh) * 2008-05-29 2008-10-15 腾讯科技（深圳）有限公司 媒体文件的点播方法、系统和设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2493191A4 *

Also Published As

Publication number Publication date
EP2493191A4 (en) 2012-08-29
EP2493191B1 (en) 2015-10-28
EP2493191A1 (en) 2012-08-29
CN102055718A (zh) 2011-05-11
US20120221681A1 (en) 2012-08-30
CN102055718B (zh) 2014-12-31

Similar Documents

Publication Publication Date Title
WO2011054319A1 (zh) 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统
JP6698755B2 (ja) セグメント化コンテンツのストリーミング
KR100492567B1 (ko) 이동통신 시스템의 ｈｔｔｐ 기반 비디오 스트리밍 장치및 방법
US10511646B2 (en) System and method for delivering content
EP2649792B1 (en) Pre-buffering audio/video stream pairs
US10116572B2 (en) Method, device, and system for acquiring streaming media data
US6708213B1 (en) Method for streaming multimedia information over public networks
CN106209892B (zh) 使用可伸缩编码的增强型块请求流送
KR101702562B1 (ko) 멀티미디어 스트림 파일의 저장 파일 포맷, 저장 방법 및 이를 이용한 클라이언트 장치
US20170149860A1 (en) Partial prefetching of indexed content
US20140095593A1 (en) Method and apparatus for transmitting data file to client
CN110933517B (zh) 码率切换方法、客户端和计算机可读存储介质
US20120246335A1 (en) Method, terminal, and server for implementing fast playout
WO2012071998A1 (zh) 一种内容分发网络中媒体文件下载方法及客户端
JP2007529121A (ja) ストリーミングメディアの疎（ｓｐａｒｓｅ）キャッシング
KR20150083793A (ko) 클라이언트 단말기에서, 멀티미디어 컨텐츠의 세그먼트의 다가오는 시퀀스를 다운로딩하는 방법, 및 대응하는 단말기
TW201123795A (en) System, method and apparatus for dynamic media file streaming
KR101104729B1 (ko) 최적의 캐시조각 획득방식을 이용하는 컨텐츠 분산 저장형 멀티미디어 스트리밍 시스템 및 방법
WO2019128800A1 (zh) 一种内容服务的实现方法、装置及内容分发网络节点
JP2011501504A (ja) ストリーミングメディアコンテンツに対応する広告コンテンツを管理するためのシステム及び方法
WO2015192683A1 (zh) 一种基于码流自适应技术的内容分发方法、装置及系统
WO2015169172A1 (zh) 网络视频播放的方法和装置
JP2005094769A (ja) マルチメディアコンテンツの高速ダウンロードサービス装置及びその方法
WO2012122900A1 (zh) 用于统计用户体验的方法、终端设备和系统
JP2015170323A (ja) 配信装置、及び配信方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10827933

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010827933

Country of ref document: EP