CN114302166A - Streaming media service system and method for IP and IPQAM network convergence scheduling - Google Patents

Abstract

The invention discloses a streaming media service system for IP and IPQAM network convergence scheduling, which comprises an IPQAM module, an AMS module, a PORTAL module, a central node and subnodes, wherein the central node is internally provided with an ODT module and a CACHE module, and the subnodes are internally provided with an ODT-VSS module, a CACHE module and an ISS module. The invention preferentially dispatches to the IPQAM channel to ensure the user experience, support the mixed distribution of multiple protocols of HTTP, RTSP and HLS, selects different protocol distribution for different terminal users, supports bandwidth self-adaptation to deal with complex network reconstruction modes, supports the HTTP protocol by the video on demand cache system, supports Range requests, shares HTTP cache with the broadband cache system, conveniently accesses the HTTP video source of each content provider and has zero online time delay.

Description

Streaming media service system and method for IP and IPQAM network convergence scheduling

Technical Field

The invention relates to a streaming media service system, in particular to a streaming media service system and a method thereof for IP and IPQAM network convergence scheduling.

Background

In the network infrastructure layer, the broadcast television network has two networks of an IP network and an HFC network, both the two networks can bear streaming media service, an IPQAM channel has the characteristic of QoS guarantee, the IP network has no bandwidth guarantee when transmitting streaming media, and the areas of the home-entering bandwidth of the IP network are greatly different. The dual-network video service carrying capability is a unique characteristic of radio and television operators.

In the aspect of the construction of a cache system, a VOD system based on an IPQAM channel is a set of dedicated and closed systems, which cannot be generally used for carrying OTT video services, and the cache system thereof is a dedicated cache based on an FTP protocol, which cannot be opened for broadband services; on the other hand, the caching system of broadband services is based on the HTTP protocol and cannot be shared by the VOD system, which is basically two independent caching systems.

The Http Live Streaming protocol has the characteristic of code rate self-adaption and is very suitable for carrying out services under the complicated and changeable network conditions of a broadcast television network, so that the new TVOS box and the android box both support the HLS protocol, and a multi-code rate playlist file meeting the requirements of the HLS protocol needs to be produced when media resources are required to be produced.

The existing set-top box of the radio and television generally supports the DVB-C on-demand and HTTP and HLS protocols, and when a large number of users use on-demand services at night, the two split systems cannot be mixed and load balanced, so that the existing streaming media service system of the radio and television cannot be well utilized.

NGOD (Next Generation On Demand Video architecture) is a framework of a VOD system architecture proposed by Comcast, USA. Although the VOD architecture is proposed by an enterprise, the VOD architecture is an actual international standard, and most of China radio and television operators perform necessary cutting and combination on the NGOD overall system architecture according to actual operation and deployment requirements. FIG. 1 is a typical simplified NGOD VOD system, briefly described as follows:

1: the set-top box (STB) requests the session resource management Server (SM) to establish the request session through the S1 interface, and transmits the information of the own RegionID, CA information, request film source and the like to the SM when the request is made.

2: after receiving the request, the SM transmits the request information to the ODRM, and then feeds back the distributed frequency point information and the SDP parameter of the media asset to the set-top box.

3: the set-top box requests video on demand from VSS through the C1 interface.

4: the VSS responds to the request of the set-top box and according to the designated IP: and the Port sends media data to the IPQAM equipment, and the data is transmitted on the HFC network after being modulated by the IPQAM equipment.

5: the set-top box receives the on-demand data at a given frequency point. When playing, pausing, fast forwarding, fast rewinding and other operations are carried out in the ordering process, the STB sends a signaling to VSS through a C1 interface, the corresponding VSS responds, a code stream controlled by the responding operation is pushed to IPQAM through a V1 interface, and the IPQAM modulates the code stream into an RF signal and transmits the RF signal to the STB.

NGOD this system has the following problems in the new potential of broadcast television:

1: the system is a closed special system, cannot be used for directly providing VOD service through an IP network under the condition that the quality of a broadcasting and television broadband is greatly improved (namely data does not go through an IPQAM channel), and only the requirement of providing the VOD service through the IPQAM channel is considered mainly during design.

2: the content must be transcoded to be accessed to the on-demand system, the online delay is large, the scale of the offline transcoding service system limits the scale of the accessible content, the automation degree of the content production process is not enough, the strict requirement during content production is a CBR TS file, and the content providers can provide basically VBR content, such as files in MP4 or FLV format.

3: the radio and television generally needs to support the multi-screen fused media asset production and distribution, the system can only support one screen of a set top box, and the fact that the radio and television needs to purchase a plurality of streaming media service systems to support different screens can be substantially caused, the workload in the media asset production process is also multiplied, and errors are easy to make in management.

4: the special Cache system is generally based on an FTP protocol, and the HTTP Cache of the broadcasting and television for developing broadband service construction can not be reused, so that the broadcasting and television needs to repeatedly invest in the Cache system, and a set of system needs to be maintained in operation and maintenance.

5: when the system needs capacity expansion, the capacity expansion cost of the IPQAM is higher than that of the broadband, so that a large amount of IPQAM resources are idle in a non-VOD peak period.

Disclosure of Invention

Aiming at the problems in the prior art, the invention provides an IP/IPQAM dual-network scheduling streaming media load, which is preferentially scheduled to an IPQAM channel to ensure user experience and support mixed distribution of multiple protocols of HTTP, RTSP, HLS, DASH and LAS, different protocols are selected for different terminal users to distribute and support bandwidth self-adaptation to cope with a complex network reconstruction mode, when broadcasting and television use an IP network to develop streaming media service, because the access network reconstruction modes of broadcasting and television are many and the bandwidth is greatly changed, a new intelligent set top box can achieve bandwidth self-adaptation by supporting protocols of HLS, DASH and the like through terminals, an old high-definition interactive set top box needs to adapt to the change of bandwidth through code rate switching supported by a service end, a video on demand caching system supports the HTTP protocol, supports the Range request, shares HTTP caching with a broadband caching system, and conveniently accesses HTTP of various content providers, a streaming media service system and method with zero online time delay and IP and IPQAM network convergence scheduling.

The purpose of the invention is realized by the following technical scheme.

A streaming media service system for IP and IPQAM network convergence scheduling comprises an IPQAM module, an AMS module, a PORTAL module, a central node and sub-nodes, wherein an ODT module and a CACHE module are arranged in the central node, and an ODT-VSS module, a CACHE module and an ISS module are arranged in the sub-nodes.

The system comprises a central node, an AMS module, an ODT-VSS module, an IPQAM module and an AMS module, wherein the central node is internally provided with the Original Server module, the AMS module is connected with the Original Server module, the Original Server module is connected with the ODT module, the ODT module is connected with the CACHE module in the central node in a bidirectional communication mode, the central node is connected with a sub-node in a bidirectional communication mode, the ODT module is connected with a BO module in a bidirectional communication mode, the BO module is respectively connected with the AMS module, the PORTAL module and the ODT-VSS module in the sub-node in a bidirectional communication mode, the ODT-VSS module is respectively connected with the CACHE module in the sub-node in a bidirectional communication mode, and the ISS module is connected in a bidirectional communication mode.

The ODT module is an on-demand transcoding module which transcodes any HTTP video source into a multi-rate playlist in real time as required, before a user does not request, all the playing links in the multi-rate playlist are virtual links, the system does not transcode any code, and when the user actually views a certain video segment, the system initiates a transcoding request of the corresponding segment as required and outputs the video segment.

The generated multi-rate playlist must include a sub-playlist of the CBR rate for the IPQAM channel.

The ODT module supports file package formats including, but not limited to, FLV, MP4, 3gp, WMV, TS, MOV, m3u8, dash, LAS file package formats.

The transfer protocols supported by the ODT module include HTTP, RTSP, RTMP, DASH, LAS, UDP live and on-demand transfer protocols.

The CACHE module is a standard HTTP CACHE module, the CACHE module uses any CACHE engine supporting HTTP protocol, the CACHE module supports get video data in HTTP form and CACHEs, supports Range request, supports CACHE-Control max-age-N (seconds), supports Last-Modified Date, If-Modified-site Date, supports Etag: "xxxx", and supports Expires: Date.

The ODT-VSS module is used for acquiring one video clip in the multi-rate play list, converting and packaging the video clip into a video stream, and serving a traditional client by an RTSP protocol.

The ISS module is a standard HTTP cache engine deployed on a sub-node, serves HTTP clients, and comprises Android clients, iOS clients, or OTT boxes and PCs supporting HTTP protocols.

A streaming media service method of IP and IPQAM network convergence scheduling comprises a RTSP on-demand method under a data-based IP network, or a RTSP on-demand method under a data-based IPQAM channel, or any video on-demand method under the IP network.

Compared with the prior art, the invention has the advantages that: a

(1) The IP/HFC network can bear various value-added services and can be scheduled arbitrarily according to the network load.

(2) The system may interface with infrastructure within existing NGOD architectures such as IPQAM, ERM, etc. The existing investment of the broadcast television network is fully utilized.

(3) The buffer system of broadcast and television broadband access is multiplexed, and the buffer system does not need to be additionally invested for a new value-added service.

(4) All terminals have the capability of network adaptation.

(5) The method is completely suitable for the architecture of provincial companies building central nodes and prefecture branch companies building branch nodes.

(6) Various video value-added services can be carried.

(7) The mixed plug-flow system is compatible with an Android set-top box and an old Linux set-top box.

(8) Making full use of the HTTP CACHE already available.

(9) The IP and IPQAM dual networks carry the streaming media load.

(10) One platform supports streaming media services for a variety of different terminals.

(11) And the RTSP, HTTP and HLS distribution is supported.

(12) The HTTP video sources of each content provider can be conveniently accessed, the online time delay is zero, the production process of media assets is automated, and manual intervention is not needed.

Drawings

Fig. 1 is a schematic diagram of an NGOD architecture.

Fig. 2 is a schematic diagram of an IP/IPQAM mixed scheduling streaming media service system under NGOD architecture according to the present invention.

Fig. 3 is a flow chart of RTSP on demand under the IP path.

Fig. 4 is a flow chart of RTSP on demand under the IPQAM channel.

FIG. 5 is a flow chart of multi-rate on demand in IP channel.

Detailed Description

The invention is described in detail below with reference to the drawings and specific examples.

As shown in fig. 2, a streaming media service system for IP and IPQAM network convergence scheduling includes an IPQAM module, an AMS module, an STB module, a PORTAL module, a central node, and a sub-node, where the central node is provided with an ODT module and a CACHE module, and the sub-node is provided with an ODT-VSS module, a CACHE module, and an ISS module.

The central node is internally provided with an origin Server module, the AMS module is connected with the origin Server module, the origin Server module is connected with the ODT module, the ODT module is connected with a CACHE module in the central node, the central node is in bidirectional communication connection with the branch nodes, the ODT module is in bidirectional communication connection with the BO module, the BO module is in bidirectional communication connection with the AMS module, the PORTAL module, the ODT-VSS module and the STB module respectively, the ODT-VSS module is in bidirectional communication connection with the CACHE module, the IPQAM module and the STB module in the branch nodes respectively, the CACHE module in the branch nodes is in bidirectional communication connection with the ISS module, the IPQAM module is in single communication connection with the STB module, and the STB module is in bidirectional communication connection with the ISS module and the PORTAL module respectively.

And the ISS module is in bidirectional communication connection with a PC/PAD module.

The invention relates to an IP/IPQAM mixed scheduling streaming media service system under NGOD architecture, which is different from a typical VOD system in that an on-Demand transcoding module ODT (on Demand transcoding) and a CACHE module are added to a central node, VSS is replaced by ODT-VSS in branch nodes, original FTP CACHE is replaced by standard HTTP CACHE, and an ISS module is additionally added.

The on-demand transcoding module is a very unique module in the scheme, and has the core function of transcoding any HTTP video source into a multi-rate playlist in real time as required, the characteristic of the on-demand transcoding module is that all the playing links in the playlist are virtual links, the playing links are only virtual links before a user does not request, the system does not perform any transcoding, when the user actually views a certain video segment, the user initiates a corresponding transcoding request of the segment as required and outputs the video segment, and due to the characteristic, the system can be accessed into a massive video source and can be online with zero delay, and the certain video can be online without waiting for the completion of all transcoding of the video. Because of the characteristic, the production process of the media asset is greatly simplified, a plurality of code rates are generated without manual intervention to adapt to different terminal and network characteristics, only one original video needs to be stored in the media asset system, and other versions are all automatically generated.

The generated multi-rate playlist must include a sub-list of CBR rates for the IPQAM channel.

The ODT module supports a plurality of file packaging formats including, but not limited to, FLV, MP4, 3gp, WMV, TS, MOV, m3u8, dash, LAS, etc.

The transmission protocols supported by the ODT module comprise live and on-demand transmission protocols such as HTTP, RTSP, RTMP, DASH, LAS, UDP and the like.

The CACHE module is a standard HTTP CACHE module, and can use any CACHE engine supporting HTTP protocol, and the necessary functions include:

supporting get video data in an HTTP form and caching:

support Range request

Cache-Control max-age ═ n (seconds):

support Last-Modified: Date, If-Modified-site: Date:

support Etag: "xxxx"

Support for Expires, Date:

this module may employ a third party CDN vendor's product or service.

The ODT-VSS is a module arranged in a branch node, and the core function of the ODT-VSS is to acquire video clips in a multi-rate play list, convert the video clips into video streams and serve clients by an RTSP protocol.

From the set-top box user perspective, ODT-VSS is an RTSP service system. The stream media path can be IPQAM or IP, when the IP path is taken, the real-time bandwidth of the user side is estimated according to the feedback of RTCP, and the appropriate code rate is selected for the client side in the input multi-code rate play list at the server side, thereby achieving the characteristic of code rate self-adaption.

From the perspective of the central node's CACHE, ODT-VSS is an HTTP client.

And the other function is to interact with an IPQAM resource scheduling module of the NGOD.

The ODT-VSS is followed by a standard HTTP CACHE buffer of video clips that have been accessed by the user.

If the scheduling system determines that a user needs to be served using IPQAM, then ODT-VSS needs and the ODRM resource scheduling module is set to NGOD: and the R2 interfaces interact to acquire frequency point information. If the data path goes through IPQAM, the CBR stream needs to be selected in the multi-rate play list.

The ISS is a standard HTTP caching engine deployed on the child nodes. And the service HTTP client is an Android client, an iOS client or an OTT box supporting the HTTP protocol, a PC and the like. The ISS module may employ products or services of third party CDN vendors.

As shown in fig. 3, step 1: the set-top box initiates an RTSP request to ODT-VSS, indicating in the request that vid must be given in the request, without passing through IPQAM, e.g. by specifying the form of TS/TCP. Corresponding to arrow 1 in fig. 3.

Step 2: and the ODT-VSS queries a database according to the vid and the IP path, finds a corresponding multi-rate play list file list and requests corresponding content from the cache, and the cache is not hit when the access is accessed for the first time. A further request for this content is required from the central node CACHE, corresponding to arrow 2 in fig. 3.

And step 3: the CACHE misses, and further requests the corresponding video segment from the ODT, and triggers the ODT to perform a transcoding operation as needed, which corresponds to arrow 3 in fig. 3.

And 4, step 4: the ODT sends a Range Request to the original streaming server, where the Range Request corresponds to a virtual slice content, which corresponds to arrow 4 in fig. 3. It can be seen from this step that if the user does not request the corresponding segment, access to this segment will not occur, so the access granularity to the content is very fine, and the content in which the user is interested can be transcoded and cached.

And step 5, returning the content requested by the ODT by the original content Web server, and transcoding or trans-packaging the ODT, which corresponds to an arrow 5 in the figure 3.

And 6, transcoding the ODT while downloading the content, and outputting the content to the CACHE, wherein the two steps are simultaneous and are a process of turning the ODT while distributing the content, and no unnecessary point delay is introduced, which corresponds to the arrow 6 in the figure 3.

And 7: to this step, in view of ODT-VSS, its request response of step 2 is now returned after going through the above steps, i.e. the content of the video clip it requests returns 200OK and content. ODT-VSS since the source seen is a multi-rate playlist, this process of requesting video clips will be sent out continuously one after the other, corresponding to arrow 7 in fig. 3.

And 8: the Cache stores the content into a local Cache system of the Cache, and the ODT-VSS continuously encapsulates the received video clips into a complete video stream and sends the complete video stream to the set-top box for playing through an IP path. In response to step 1, a 200OK is sent back, which appears to the set-top box that it requests a video stream, without knowing that this stream is being subdivided into individual video segments.

It is worth pointing out that, almost all radio and television operators in china transmit video stream data in a packaging manner of TS OVER TCP at present, so that a service end of ODT-VSS can monitor real-time changes in bandwidth of TCP connection with a terminal client, and therefore, when the ODT-VSS can continuously request a subsequent video segment, that is, in step 7, the service end helps the terminal user to switch to an appropriate bitrate version in a multi-bitrate playlist file in real time according to the collected changes in user bandwidth, thereby implementing RTSP set-top box bandwidth adaptation.

As shown in fig. 4, step 1: the set-top box is firstly connected with the NGOD: the S1 interface initiates an RTSP Setup request to the SM indicating in the request MP2T/DVBC/QAM and QAM devices found by the set-top box, which clearly indicates that vid must be given in the request in order to initiate an on-demand session over the IPQAM channel. Corresponding to arrow 1 in fig. 4.

Step 2: after the SM in the BO negotiates with resource scheduling managers such as ERM and ODRM, the ODT-VSS for service is selected, and then a Setup request is sent to a certain ODT-VSS server, where the Setup command already includes UDP address and port of QAM resource, Program-Id, corresponding to arrow 2 in fig. 4.

And step 3, responding to the Setup sent out in the step 2 by the ODT-VSS.

Step 4, the SM responds to the Setup sent by the STB in step 1.

Step 5, the set-top box sends out a Play request to the ODT-VSS server address returned in the previous step, corresponding to arrow 5 in fig. 4.

And 6, inquiring a database by the ODT-VSS according to the vid, finding a corresponding multi-rate play list file list, requesting corresponding contents from a cache, and missing the cache when accessing for the first time. A further request for this content is required from the central node CACHE, corresponding to arrow 6 in fig. 4.

And 7: the CACHE misses, and further requests the corresponding TS segment from the ODT, and triggers the ODT to perform a transcoding operation as needed, which corresponds to arrow 7 in fig. 4.

And 8: the ODT sends a Range Request to the original streaming server, where the Range Request corresponds to a virtual slice content, which corresponds to arrow 8 in fig. 4. It can be seen from this step that if the user does not request the corresponding segment, access to this segment will not occur, so the access granularity to the content is very fine, and the content in which the user is interested can be transcoded and cached.

Step 9, the original content Web server returns the content requested by the ODT, and the ODT performs transcoding or transcoding package, corresponding to arrow 9 in fig. 4.

Step 10, the ODT transcodes and outputs the content to the CACHE while downloading the content, the two steps occur simultaneously, and are a process of downloading and downloading while distributing, and no unnecessary point delay is introduced, which corresponds to the arrow 10 in fig. 4:

step 11: to this step, in view of ODT-VSS, its request response of step 2 is now returned after going through the above steps, i.e. the TS clip content it requests returns 200OK and content. ODT-VSS since the source seen is a multi-rate playlist, this process of requesting video clips will be sent out continuously one after the other, corresponding to arrow 11 in fig. 4:

step 12: and the ODT-VSS stores the content into a local cache system of the ODT-VSS and continuously encapsulates the received video clips into a complete video stream to be transmitted to the set top box through an IPQAM channel for playing. In response to step 1, a 200OK is sent back, which appears to the set-top box that it requests a video stream, without knowing that this stream is being refined into a video clip on request.

It should be noted that, because the IPQAM channel has the characteristics of fixed bandwidth and QoS guarantee, the ODT-VSS in the multi-rate playlist needs to ensure that the CBR rate version in the multi-rate playlist is selected, so that the user experience issued through the IPQAM channel is guaranteed.

As shown in fig. 5, step 1: the set-top box sends an HLS request to the ISS to request a multi-code rate m3u8 list.

Step 2: the ISS is a normal Web Server, such as Nginx, Lighttpd, and requests the corresponding content from the cache according to the TS segment of the requested multi-rate m3u8 file, and when the content is accessed for the first time, the cache misses. A further request for this content is required from the central node CACHE, corresponding to arrow 2 in fig. 5.

And step 3: the CACHE misses, and further requests the corresponding TS segment from the ODT, and triggers the ODT to perform a transcoding operation as needed, which corresponds to arrow 3 in fig. 5.

And 4, step 4: the ODT sends a Range Request to the original streaming server, where the Range Request corresponds to a virtual slice content, which corresponds to arrow 4 in fig. 5. It can be seen from this step that if the user does not request the corresponding segment, access to this segment will not occur, so the access granularity to the content is very fine, and the content in which the user is interested can be transcoded and cached.

And step 5, returning the content requested by the ODT by the original content Web server, and transcoding or trans-packaging the ODT, wherein the content corresponds to an arrow 5 in the figure 5.

And 6, transcoding the ODT while downloading the content, and outputting the content to the CACHE, wherein the two steps are simultaneous and are a process of turning the ODT while distributing the content, and no unnecessary point delay is introduced, which corresponds to an arrow 6 in the figure 5.

And 7: to this end, the ISS sees that its request response of step 2 is returned after going through the above steps, i.e. the TS clip content it requests returns 200OK and content. Corresponding to arrow 7 in fig. 5.

And 8: the set-top box receives the requested video segment, and according to the download bandwidth, the HLS player can continuously request a new TS segment, and if the bandwidth changes, a version with a proper code rate is correspondingly requested.

Compared with an IP path, the IPQAM path has the characteristics of QoS guarantee and wide available bandwidth. Therefore, in consideration of business, a high-definition on-demand package can be pushed out, and when all users of the high-definition on-demand package are on demand, the users are directly dispatched to the IPQAM channel after authentication. When the set-top box accesses the Portal, when the user initiates a request, the parameter of 1 is brought in to the isipqam, the service using the IPQAM channel is automatically scheduled, only some changes are needed in the service flow, and the ODT-VSS needs to pass through the NGOD: the R2 interface and the ODRM realize joint debugging, and the method can be realized without any set-top box software upgrading and the like.

When some users with good broadband conditions need to be dispatched to an IP path, because a terminal initiates a request, a Setup request does not need to be initiated to an SM firstly (certainly, the request can also be initiated to the SM firstly, in this case, the request needs to be co-dispatched with manufacturers such as SM, ERM and the like), when Portal is generated, according to the Region ID or STB ID of the user, the two-way network reconstruction characteristics, the user-in bandwidth and the like are accurately known, and if the bandwidth conditions are good, the video-on-demand link is directly pointed to an ODT-VSS server, so that the butt joint with the SM, ERM and the like is completely avoided. The method can be realized by only re-customizing Portal without any upgrade and change of the set-top box, and when the ODT-VSS service is used, the load balancing is directly carried out by using a load balancer of the ODT-VSS.

Claims (10)

1. A stream media service system for IP and IPQAM network convergence scheduling comprises an IPQAM module, an AMS module, a PORTAL module, a central node and sub-nodes, and is characterized in that the central node is provided with an ODT module and a CACHE module, and the sub-nodes are provided with an ODT-VSS module, a CACHE module and an ISS module.

2. The system according to claim 1, wherein an origin Server module is disposed in the central node, the AMS module is connected to the origin Server module, the origin Server module is connected to the ODT module, the ODT module is connected to a CACHE module in the central node, the central node is connected to the subnode in a bidirectional communication manner, the ODT module is connected to a BO module in a bidirectional communication manner, the BO module is respectively connected to the AMS module, the tal module and the ODT-VSS module in a bidirectional communication manner, the ODT-VSS module is respectively connected to a CACHE module and an IPQAM module in the subnode in a bidirectional communication manner, and the CACHE module in the subnode is connected to the ISS module in a bidirectional communication manner.

3. The system according to claim 1 or 2, wherein the ODT module is an on-demand transcoding module, the on-demand transcoding module transcodes any HTTP video source into a multi-rate playlist on demand in real time, the playlist is a virtual link before a user requests it, the system does not transcode any video, and when a user actually views a video segment, a transcoding request of a corresponding segment is initiated on demand and the segment is output.

4. The system according to claim 3, wherein the generated multi-rate playlist includes a sub-list of CBR rates for IPQAM channel.

5. The system for streaming media service with converged scheduling of IP and IPQAM according to claims 1-2, wherein the ODT module supports file encapsulation formats including but not limited to FLV, MP4, 3gp, WMV, TS, MOV, m3u8, DASH, LAS file encapsulation formats.

6. The system for streaming media service with converged scheduling of IP and IPQAM according to claim 1 or 2, wherein the ODT module supports the transmission protocols including but not limited to HTTP, RTSP, RTMP, LAS, UDP live and on demand transmission protocols.

7. The system of claim 1 or 2, wherein the CACHE module is a standard HTTP CACHE module, the CACHE module uses any buffer engine supporting HTTP protocol, the CACHE module supports get video data in HTTP form and buffers, supports Range request, CACHE-Control max-age N (seconds), Last-Modified Date, If-Modified-site Date, Etag: "xxxx", and Expires data.

8. The IP and IPQAM network converged scheduling streaming media service system according to claim 1 or 2, wherein the ODT-VSS module is configured to obtain video clips from a multi-rate playlist, forward and encapsulate the video clips into a video stream, and serve a traditional RTSP client with RTSP protocol.

9. The system according to claim 1 or 2, wherein the ISS module is a standard HTTP cache engine deployed on a sub-node, and the ISS module serves HTTP clients, and the HTTP clients include an Android client, an iOS client, or an OTT box and a PC supporting an HTTP protocol.

10. A stream media service method of IP and IPQAM network convergence scheduling is characterized by comprising an RTSP on demand method under a data-running IP network, or an RTSP on demand method under a data-running IPQAM channel, or any video on demand method under the IP network.

Images