WO2024032363A1 - 回源处理方法、装置、计算设备及存储介质 - Google Patents

回源处理方法、装置、计算设备及存储介质 Download PDF

Info

Publication number
WO2024032363A1
WO2024032363A1 PCT/CN2023/108946 CN2023108946W WO2024032363A1 WO 2024032363 A1 WO2024032363 A1 WO 2024032363A1 CN 2023108946 W CN2023108946 W CN 2023108946W WO 2024032363 A1 WO2024032363 A1 WO 2024032363A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
media slice
media
index file
distribution system
Prior art date
Application number
PCT/CN2023/108946
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 上海哔哩哔哩科技有限公司
Publication of WO2024032363A1 publication Critical patent/WO2024032363A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • the present disclosure relates to the field of Internet technology, and specifically to a back-to-origin processing method, device, computing device and storage medium.
  • the anchor pushes the stream to the origin server, and the origin server produces the live stream to obtain media slice files, and in the media slice Update the index file after file production is complete.
  • the client needs to first request the index file, and then request the content distribution system to download the corresponding media slice file based on the index file.
  • the content distribution system does not store the media slice file requested by the client, it will go back to the origin server to download the media slice file. After the download is completed, the media slice file will be returned to the client, and the back-to-source chain
  • the path is complex and the return-to-origin process takes a long time.
  • Media file requests that fail to hit the content distribution system storage need to wait for the client to wait for the return-to-source process, resulting in long streaming times and lags in live broadcast playback.
  • the purpose of the embodiments of the present disclosure is to provide a back-to-source processing method, device, computing device, and storage medium to solve the problem in the above-mentioned prior art that the media file request fails to be stored in the content distribution system and the client needs to wait for the back-to-source processing to cause streaming.
  • the problem is that the time is too long and the live broadcast is stuck.
  • a back-to-source processing method includes:
  • a back-to-source processing method includes:
  • a back-to-source processing device wherein the device includes:
  • the first transceiver module is adapted to receive the index file request sent by the client and forward the index file request to the origin server;
  • the second transceiver module is adapted to receive the index file returned by the origin server in response to the index file request, and forward the index file to the client;
  • Parsing module suitable for parsing index files
  • the pre-origin module is adapted to initiate a return-to-origin request to the origin server for requesting at least one media slice file when the index file contains a pre-cache tag of at least one media slice file; at least one media slice file is about to be produced. media slice files;
  • the media file sending and receiving module is adapted to receive at least one media slice file returned by the origin server;
  • the storage module is adapted to store at least one media slice file.
  • a back-to-source processing device wherein the device includes:
  • the third transceiver module is adapted to receive the index file request sent by the client forwarded by the content distribution system, and transmit the index file back to the client through the content distribution system;
  • the fourth transceiver module is adapted to receive a back-to-origin request for at least one media slice file initiated by the content distribution system by parsing the index file to obtain the pre-cache tag; the at least one media slice file is a media slice file to be produced, and is sent to the content
  • the distribution system returns at least one media slice file for the content distribution system to store at least one media slice file.
  • a computing device including: a processor, a memory, a communication interface, and a communication bus.
  • the processor, the memory, and the communication interface complete interactions with each other through the communication bus.
  • the memory is used to store at least one executable instruction.
  • the executable instruction causes the processor to perform operations corresponding to the above-mentioned back-to-source processing method.
  • a non-volatile computer-readable storage medium stores at least one executable instruction.
  • the executable instruction causes the processor to execute the above-mentioned steps. Operations corresponding to the back-to-source processing method.
  • a computer program product includes a computing program stored on the above-mentioned non-volatile computer-readable storage medium.
  • an additional pre-cache tag of the media slice file to be produced is added to the index file.
  • the index file is sent back to the client and the content distribution system.
  • the content distribution system parses out the pre-cache tag in the index file, and requests the origin server to return the media slice file corresponding to the pre-cache tag.
  • the media slice is made The file is downloaded to the content distribution system before production is completed, instead of downloading it back to the source when the content distribution system does not store the corresponding media slice file when requesting the media file.
  • the client's media file requests can all hit the content distribution system storage, which can reduce the client's streaming time, reduce the client's lagging rate, and optimize the user's playback experience; on the other hand, the origin server receives the back-to-origin request from the content distribution system.
  • the media slice file is about to be produced, a communication link is established with the content distribution system to transmit the media slice file to be produced, and is disconnected after the production of the media slice file to be produced is completed, which can ensure the accuracy of data transmission and disconnect the communication in a timely manner Links can release occupied resources in a timely manner.
  • Figure 1 shows a flow chart of a back-to-source processing method provided by an embodiment of the present disclosure
  • Figure 2 shows a flow chart of a back-to-source processing method provided by another embodiment of the present disclosure
  • Figure 3 shows a schematic diagram of the back-to-source process in the prior art
  • Figure 4 shows an interaction sequence diagram of a client's live broadcast viewing process according to another embodiment of the present disclosure
  • Figure 5 shows a flow chart of a back-to-source processing method provided by another embodiment of the present disclosure
  • Figure 6 shows a schematic structural diagram of a back-to-source processing device provided by another embodiment of the present disclosure
  • Figure 7 shows a schematic structural diagram of a back-to-source processing device provided by another embodiment of the present disclosure.
  • FIG. 8 shows a schematic structural diagram of a computing device provided by an embodiment of the present disclosure.
  • Live streaming The transmission of live audio and video data, which can be transmitted as a stable and continuous stream through the network for viewers to watch.
  • Live streaming refers to the process of pulling live streams to the source site specified by the user through the live streaming cloud platform.
  • CDN Content Distribution Network
  • CDN Content Delivery Network
  • the CDN has the functions of caching, mirroring and overall load balancing, mainly caching static data in the website.
  • CDN edge nodes are used to cover server nodes for users in the corresponding area.
  • CDN origin station is the central node for gathering back-to-origin resources.
  • Origin server a service device that produces live streams into media slice files.
  • Back-to-source processing The process in which the content distribution system initiates a back-to-source request to the content provider to pull live content.
  • Index file A file used to record media file information in the HLS live broadcast protocol.
  • Media slice file a file used to store and play audio and video data in the HLS live broadcast protocol.
  • Figure 1 shows a flow chart of a back-to-origin processing method provided by an embodiment of the present disclosure.
  • the method of this embodiment is applied to a content distribution system. As shown in Figure 1, the method includes the following steps:
  • Step S110 Receive the index file request sent by the client, and forward the index file request to the origin server.
  • the client when watching the HLS live stream, the client needs to request the index file first. After requesting the index file, the client obtains the media file list in the index file, and then requests the media slice file according to the media file list and plays it. .
  • the index file is produced by the origin server.
  • the origin server slices the live stream to generate media slice files.
  • the origin server updates the file name of the media slice file that has been produced to Index files in the list of media files.
  • the origin server can continuously produce new media slice files, so the index file is constantly updated.
  • the client needs to continuously request the index file. Each time the client requests the index file, renew.
  • the index file request is used to obtain the index file.
  • the client initiates an index file request to the content distribution system, and the content distribution system forwards the client's index file request to the origin server.
  • Step S120 Receive the index file returned by the origin server in response to the index file request, and forward the index file to the client.
  • the origin server In response to the index file request forwarded by the content distribution system, the origin server returns the index file to the content distribution system, and the content distribution system forwards the index file to the client.
  • the client After receiving the index file, the client initiates a media file request to the content distribution system according to the media file list contained in the index file to obtain the corresponding media slice file.
  • Step S130 Parse the index file. If the index file contains a pre-cache tag of at least one media slice file, initiate a back-to-origin request to the origin server for requesting at least one media slice file.
  • the content distribution system parses the index file, obtains the pre-cache tag of at least one media slice file contained in the index file, and initiates a return-to-origin request to the origin server to download at least one of the media slice files corresponding to the pre-cache tag.
  • a media slice file After receiving the index file, the content distribution system parses the index file, obtains the pre-cache tag of at least one media slice file contained in the index file, and initiates a return-to-origin request to the origin server to download at least one of the media slice files corresponding to the pre-cache tag.
  • the pre-cache tag is an additional field added to the index file, which can be recognized by the content distribution system but not by the client. It is used to instruct the content distribution system to request the media slice file corresponding to the origin pre-cache tag from the origin server.
  • the origin server when the origin server makes the index file, in addition to updating the media file list of the index file based on at least one media slice file that has finished production, it also adds at least one media that is about to be produced to the index file. Precached tags for sliced files.
  • Step S140 Receive at least one media slice file returned by the source server, and store at least one media slice file.
  • the origin server In response to the back-to-origin request of the content distribution system, the origin server returns at least one media slice file corresponding to the pre-cache tag to the content distribution system, and the content distribution system stores the received at least one media slice file.
  • the media file list of the index file can only be updated after the production of the media slice file is completed.
  • the client can request media files based on the media file list of the index file, and content distribution can only be completed after returning to the source.
  • After the system stores the media slice file other clients can reuse the stored media slice file. Therefore, for the first client that uses the index file to request a media slice file, the media slice file it requests will not exist in In the content distribution system, the content distribution system needs to request the media slice file requested by the origin server from the origin server. It will not send it back to the client until the download is completed. The client needs to wait for a long time before the stream can be successfully pulled.
  • the production serial number of the media slice file is identified by a serial number.
  • the media slice files that have been produced include media slice files No. 1-3.
  • the media to be produced The slice files include media slice files No. 4-6, and the index file contains the media file list corresponding to the media slice files No. 1-3 and the pre-cache tag corresponding to the media slice files No. 4-6.
  • the client requests the index file.
  • the client requests the media slice files No. 1-3 from the content distribution system based on the index file, and the content distribution system requests the media slice files No. 4-6 from the origin server; as the origin server continues to produce, the next one is reached.
  • the media slice files currently to be produced include media slice files No. 7-9.
  • the index file contains the media file list corresponding to the media slice files No. 4-6 and 7 -The pre-cache tag corresponding to the media slice file No. 9.
  • the client requests the index file.
  • the client requests the media slice files No. 4-6.
  • the media slice files No. 4-6 have been stored in the content distribution server. In the system, the content distribution system directly returns the stored media slice files. Simply put, for any media slice file, it is returned to the content distribution system during the production process.
  • the content distribution system has already stored the media slice file, thereby avoiding the problem that the media file request cannot hit the storage of the content distribution system.
  • an additional pre-cache tag of the media slice file to be produced is added to the index file.
  • the index file It is sent back to the client and the content distribution system.
  • the content distribution system parses out the pre-cache tag in the index file and requests the origin server to return the corresponding pre-cache tag.
  • the media slice file can be downloaded to the content distribution system before the production of the media slice file is completed, instead of going back to the source to download when the content distribution system does not store the corresponding media slice file when requesting the media file. It realizes the early return of media slice files to the source, so that all media file requests from the client can hit the storage of the content distribution system, which can reduce the client's streaming time, reduce the client's lagging rate and optimize the user's playback experience.
  • Figure 2 shows a flow chart of a back-to-origin processing method provided by another embodiment of the present disclosure. The method is applied in a content distribution system. As shown in Figure 2, the method includes the following steps:
  • Step S210 Receive the index file request sent by the client, and forward the index file request to the origin server.
  • Step S220 Receive the index file returned by the origin server in response to the index file request, and forward the index file to the client.
  • Index file requests are used to obtain index files.
  • the client initiates an index file request to the content distribution system, and the content distribution system forwards the client's index file request to the origin server.
  • the origin server responds to the index file request by sending the index file back to the content distribution system, and then the content distribution system The system sends it back to the client.
  • the index file is produced by the origin server.
  • the origin server When producing the index file, the origin server not only updates the media file list of the index file based on at least one media slice file that has been produced, but also adds at least one media slice file that is about to be produced to the index file. precached tag.
  • the client After receiving the index file, the client requests the corresponding media slice file from the content distribution system according to the media file list contained therein.
  • Step S230 parse the index file, and if the index file contains a pre-cache tag of at least one media slice file, initiate a return-to-origin request to the origin server for requesting at least one media slice file; at least one media slice file is Media slice files to be produced.
  • the content distribution system parses the index file, obtains the pre-cache tag of at least one media slice file contained in the index file, and initiates a return-to-origin request to the origin server to download at least one of the media slice files corresponding to the pre-cache tag.
  • a media slice file After receiving the index file, the content distribution system parses the index file, obtains the pre-cache tag of at least one media slice file contained in the index file, and initiates a return-to-origin request to the origin server to download at least one of the media slice files corresponding to the pre-cache tag.
  • the pre-cache tag is an additional field added to the index file, which can be recognized by the content distribution system but not by the client. It is used to instruct the content distribution system to download at least one media slice file corresponding to the pre-cache tag from the origin server. At least one media slice file corresponding to the cache tag refers to a media slice file to be produced.
  • the pre-cache tag records the file name of at least one media slice file.
  • the content distribution system parses the index file and obtains the pre-cache content contained in the index file.
  • the cache tag initiates a return-to-origin request to the origin server in order to download the media slice file corresponding to the file name of at least one media slice file recorded in the pre-cache tag.
  • the content distribution system first identifies the specified characters in the index file, and then obtains the file name associated with the specified characters, that is, the file name of the media slice file that needs to be downloaded is obtained.
  • Step S240 Receive at least one media slice file returned by the origin server while producing it, and store at least one media slice file.
  • the media slice files that are about to be produced are the media slice files that have not yet been produced.
  • the origin server transmits the produced file data to the content distribution system while producing it, and the content distribution system stores the received file data.
  • At least one media slice file returned by the origin server is received through a communication link established by the origin server, where the communication link is established by the origin server after receiving the return-to-origin request.
  • Media slice files are disconnected after production ends.
  • a communication link is established to transmit the media slice files being produced, and the communication link is disconnected after the production is completed, which can ensure the accuracy of data transmission, and timely disconnection of the communication link can release the occupied resources in a timely manner.
  • Step S250 After the production of at least one media slice file is completed, the origin server updates the index file so that the media file list of the updated index file contains the file name of at least one media slice file.
  • the index file update time is reached.
  • the origin server will update the file name of the media slice file at the update time to the media file list of the index file.
  • generate a pre-cache tag based on the file name of at least one media slice file to be produced at the update timing and update it into the index file to obtain an updated index file.
  • Step S260 Receive the index file request sent by the client, forward the index file request to the origin server; receive the updated index file returned by the origin server in response to the index file request, and forward the updated index file to the client.
  • the terminal receives the media file request sent by the client based on the updated index file, and returns at least one stored media slice file to the client.
  • the client then initiates an index file request, and the content distribution system forwards the index file request to the origin server.
  • the origin server responds to the index file request by sending the updated index file back to the content distribution system, and the content distribution system then sends the updated index file back to the content distribution system.
  • the index file is sent back to the client; the client receives Extract the media file list from the updated index file, and request the media slice file corresponding to the file name contained in the media file list from the content distribution system.
  • the media slice file corresponding to the media file list of the updated index file is passed in advance.
  • the back-to-origin has been stored in the content distribution system. If the client's media file request can hit the stored content of the content distribution system, the stored media slice file will be returned to the client.
  • FIG. 3 shows a schematic diagram of the back-to-origin process in the prior art. The details are as follows: when each client requests an HLS live stream, the client will request to the CDN edge server; if the request does not hit the CDN edge server, the request will be returned to the CDN origin station. ; If the request does not hit the CDN origin site, the origin request will be returned to the origin server to download the media slice file requested by the client, and only after the media file cache is successfully built, other clients can use the cache.
  • the live stream on the anchor side is pushed to the origin server through the upstream edge server, and RTMP (Real Time Messaging Protocol) is used to push the live stream.
  • RTMP Real Time Messaging Protocol
  • the back-to-origin process needs to go back to the live broadcast source server, and at least two layers of link transmission are passed in the middle.
  • the network delay is very obvious, which greatly extends the streaming time.
  • the cache must be reused only after the user's return to origin is completed. Therefore, the return to origin processing of the existing technology will cause the client to take a long time to pull the stream and have a high live broadcast lag rate, thus affecting the user experience.
  • FIG 4 shows an interactive sequence diagram of the client's live broadcast process according to another embodiment of the present disclosure, which specifically includes the following process steps:
  • Step 1 The client sends an index file request to the CDN edge;
  • Step 2 The CDN edge forwards the index file request to the CDN origin site;
  • Step 3 The CDN origin site forwards the index file request to the origin server;
  • Step 4 The origin server returns an index file response to the CDN origin site, that is, it returns the m3u8 file. It is assumed that the origin server returns the media file list corresponding to the media slice files 1-3 that have been produced and the media slice files 4-6 that are about to be produced. The corresponding pre-cache tag is updated in the index file;
  • Step 5 The CDN origin station returns the index file response to the CDN edge, that is, the m3u8 file is returned;
  • Step 6 The CDN edge returns the index file response to the client, that is, returns the m3u8 file;
  • Step 7 The CDN edge parses the index file and determines whether the index file contains a pre-cache tag.
  • Step 8 If the pre-cache tag is included, the CDN edge requests the CDN origin site for the pre-cache file, that is, it requests to pre-cache the media slice files to be produced 4-6;
  • Step 9 The CDN origin site requests the pre-cache file from the origin server
  • Step 10 The origin server returns a media file response to the CDN origin server, that is, it returns the media slice file.
  • the CDN origin server caches the received media slice file, that is, the origin server produces the Media slice files 4-6 transmit the produced data to the CDN origin station.
  • Step 11 The CDN origin station returns a media file response to the CDN edge, that is, media slice files 4-6 are returned, and the CDN edge caches the received media slice files 4-6.
  • Step 12 Wait for the media slice file to be written at the edge of the CDN, and then update the index file. That is, after the production of the media slice file is completed, update the index file.
  • the updated index file contains the media corresponding to the media slice files 4-6 that have been produced.
  • the above steps 1 to 11 are the processing flow after the client requests the index file, which omits the process of the client requesting the media file according to the media file list of the index file.
  • the client requests the media file according to the media file list in the index file.
  • the CDN edge requests the corresponding media slice files 1-3. If the CDN caches the media slice files 1-3 requested by the client, the cached file is directly returned. On the contrary, if the CDN edge does not cache the media slice requested by the client, Files 1-3 need to be returned to the source.
  • Step 13 The client sends an index file request to the CDN edge
  • Step 14 The CDN edge forwards the index file request to the CDN origin site;
  • Step 15 The CDN origin site forwards the index file request to the origin server;
  • Step 16 The origin server returns an index file response to the CDN origin site, that is, returns the m3u8 file.
  • the index file contains the media file list corresponding to the media slice file 4-6 that has been produced and the media slice file 7- that will be produced soon. 9 corresponding pre-cache tag;
  • Step 17 The CDN origin station returns the index file response to the CDN edge, that is, returns the m3u8 file;
  • Step 18 The CDN edge returns an index file response to the client, that is, returns the m3u8 file;
  • Step 19 The client requests media files from the CDN edge based on the media file list in the index file, that is, requests media slice files 4-6;
  • Step 20 The media file request hits the CDN edge cache, and the CDN edge returns the media slice file requested by the client.
  • Media slice files 4-6 have been cached in the CDN edge, and the client's media file request can hit the CDN edge cache.
  • the above steps 13 to 20 are the processing flow after the client requests the updated index file.
  • the process of CDN requesting back to the source media slice file based on the pre-cache tag in the updated index file is omitted, that is, requesting back to the source to be produced.
  • the media file list of the updated index file corresponds to the media slice file 4-6. Therefore, the client requests the media slice file 4-6 according to the updated index file.
  • the media slice Files 4-6 have been cached in the CDN edge. Even if it is the first client to request the updated index file, its media file request can directly hit the CDN cache, thus greatly reducing the streaming time and reducing the live broadcast time. Stuttering rate improves user experience.
  • the origin server when making the index file, adds an additional pre-cache tag of the media slice file to be produced in the index file; when the client initiates an index file request, the index file is sent back to The client and the content distribution system.
  • the content distribution system parses out the pre-cache tag in the index file and initiates a back-to-origin request to the origin server based on the pre-cache tag.
  • the origin server After receiving the back-to-origin request, the origin server establishes a connection with the content distribution system.
  • Communication link and return the media slice files corresponding to the pre-cache tag while producing, so that the media slice files that have not yet been produced are stored in the content distribution system in advance, instead of requesting the media files when they cannot hit the content distribution system.
  • Back-to-origin realizes the early return-to-origin of media slice files, so that all media file requests from the client can hit the content distribution system, which can reduce the client's streaming time, reduce the client's lagging rate, and optimize the user's playback experience.
  • a communication link is established to transmit files when the return to the source is required. Once the media slice file production is completed, the communication link is disconnected, which can ensure the accuracy of data transmission and release the resources occupied by the communication link in a timely manner.
  • Figure 5 shows a flow chart of a back-to-origin processing method provided by another embodiment of the present disclosure.
  • the method in this embodiment is applied to the origin server.
  • the method includes the following steps:
  • Step S510 Receive the index file request sent by the client forwarded by the content distribution system, and return the index file to the client through the content distribution system.
  • the index file request is used to obtain the index file.
  • the client initiates an index file request to the content distribution system, and the content distribution system forwards the client's index file request to the origin server.
  • the index file is produced by the origin server.
  • the origin server slices the live stream to generate media slice files.
  • the origin server updates the file name of the media slice file that has been produced to Index files in the list of media files.
  • the origin server In response to the index file request forwarded by the content distribution system, the origin server returns the index file to the content distribution system, and the content distribution system forwards the index file to the client.
  • the client After receiving the index file, the client requests the corresponding media slice file from the content distribution system based on the media file list contained therein.
  • Step S520 Receive a back-to-origin request for at least one media slice file initiated by the content distribution system by parsing the index file to obtain the pre-cache tag.
  • at least one media slice file is a media slice file to be produced.
  • the content distribution system After receiving the index file, the content distribution system parses the index file and obtains the index file. pre-cache tag of at least one media slice file contained in the file, and initiates a return request to the origin server to download the media slice file corresponding to the pre-cache tag.
  • the pre-cache tag is an additional field added to the index file. It can be recognized by the content distribution system but not by the client. It is used to instruct the content distribution system to return the media slice file corresponding to the pre-cache tag to the origin server. It is different from The media slice files that have been produced, and the media slice files corresponding to the pre-cache tags refer to the media slice files that are about to be produced, such as the media slice files that are being produced and the media slice files that are about to be generated.
  • the origin server when the origin server makes the index file, in addition to updating the media file list of the index file based on at least one media slice file that has finished production, it also adds at least one media that is about to be produced to the index file. Precached tags for sliced files.
  • the pre-cache tag records the file name of at least one media slice file.
  • the content distribution system parses the index file, obtains the pre-cache tag contained in the index file, and initiates a back-to-origin request to the origin server. to download the media slice file corresponding to the file name of at least one media slice file recorded in the pre-cache tag.
  • the content distribution system first identifies the specified characters in the index file, and then obtains the file name associated with the specified characters, that is, the file name of the media slice file that needs to be downloaded is obtained.
  • Step S530 Return at least one media slice file to the content distribution system so that the content distribution system can store at least one media slice file.
  • the origin server In response to the back-to-origin request of the content distribution system, the origin server returns at least one media slice file corresponding to the pre-cache tag to the content distribution system, and the content distribution system stores the received at least one media slice file.
  • At least one media slice file is returned to the content distribution system during production.
  • the media slice files that are about to be produced are the media slice files that have not yet been produced.
  • the origin server transmits the produced file data to the content distribution system while producing it, and the content distribution system stores the received file data.
  • a communication link is established; through the communication link, at least one media slice file is returned to the content distribution system; after the production of at least one media slice file is completed, the communication is disconnected Link.
  • a communication link is established to transmit the media slice files being produced, and the communication link is disconnected after the production is completed, which can ensure the accuracy of data transmission, and timely disconnection of the communication link can release the occupied resources in a timely manner.
  • the index file is updated so that the media file list of the updated index file contains the file name of at least one media slice file.
  • a new index file update time is reached.
  • the origin server will update the file name of the media slice file that has been produced to the media file list of the index file.
  • a pre-cache tag is generated from the file name of at least one of the next set of media slice files to be produced and updated into the index file to obtain an updated index file.
  • the origin server when the origin server makes an index file, an additional pre-cache tag of the media slice file to be produced is added to the index file.
  • the index file When the client initiates an index file request, the index file is returned. It is transmitted to the client and the content distribution system.
  • the content distribution system parses out the pre-cache tag in the index file and requests the origin server to return the media slice file corresponding to the pre-cache tag.
  • the media slice file has not yet been produced. It is downloaded to the content distribution system instead of going back to the source when the content distribution system does not store the corresponding media slice file when requesting the media file. This realizes the early return of the media slice file to the source, making the client's media file request All can hit the content distribution system storage, which can reduce the client streaming time, reduce the client lag rate and optimize the user playback experience.
  • Figure 6 shows a schematic structural diagram of a back-to-source processing device provided by another embodiment of the present disclosure. As shown in Figure 6, the device includes:
  • the first transceiver module 61 is adapted to receive the index file request sent by the client, and forward the index file request to the origin server;
  • the second transceiver module 62 is adapted to receive the index file returned by the origin server in response to the index file request, and forward the index file to the client;
  • Parsing module 63 is suitable for parsing index files
  • the pre-return module 64 is adapted to initiate a return-to-origin request to the origin server for requesting at least one media slice file when the index file contains a pre-cache tag of at least one media slice file; at least one media slice file is about to be Produced media slice files;
  • the media file transceiving module 65 is adapted to receive at least one media slice file returned by the source server;
  • the storage module 66 is adapted to receive at least one media slice file returned by the origin server and store the at least one media slice file.
  • the media file transceiving module 65 is further adapted to: receive at least one media slice file that the origin server returns while producing;
  • the origin server updates the index file so that the media file list of the updated index file contains the file name of at least one media slice file.
  • the first transceiver module 61 is further adapted to: after the origin server updates the index file, receive the index file request sent by the client, and forward the index file request to the origin server;
  • the second transceiver module 62 is further adapted to: receive the updated index file returned by the source server in response to the index file request, and forward the updated index file to the client;
  • the media file transceiving module 65 further begins with: receiving a media file request sent by the client based on the updated index file, and transmitting at least one stored media slice file back to the client.
  • the pre-cache tag records the file name of at least one media slice file.
  • the media file transceiving module 65 is further adapted to: receive at least one media slice file returned by the origin server through a communication link established by the origin server; wherein the communication link is received by the origin server. It is established after a return-to-origin request is made and disconnected after at least one media slice file is produced.
  • Figure 7 shows a schematic structural diagram of a back-to-source processing device provided by another embodiment of the present disclosure. As shown in Figure 7, the device includes:
  • the third transceiver module 71 is adapted to receive the index file request sent by the client forwarded by the content distribution system, and return the index file to the client through the content distribution system;
  • the fourth transceiver module 72 is adapted to receive a back-to-origin request for at least one media slice file initiated by the content distribution system by parsing the index file to obtain the pre-cache tag; the at least one media slice file is a media slice file to be produced.
  • the content distribution system returns at least one media slice file for the content distribution system to store at least one media slice file.
  • the fourth transceiver module 72 is further adapted to: transmit back at least one media slice file to the content distribution system while producing;
  • the device further includes: a file update module, adapted to update the index file after the production of at least one media slice file is completed, so that the media file list of the updated index file contains the file name of at least one media slice file.
  • a file update module adapted to update the index file after the production of at least one media slice file is completed, so that the media file list of the updated index file contains the file name of at least one media slice file.
  • the device further includes: a link processing module, adapted to establish a communication link after receiving the back-to-origin request;
  • the fourth transceiver module 72 is further adapted to: transmit back at least one media slice file to the content distribution system through the communication link;
  • the link processing module is further adapted to: disconnect the communication link after the production of at least one media slice file is completed.
  • Embodiments of the present disclosure provide a non-volatile computer-readable storage medium.
  • the non-volatile computer-readable storage medium stores at least one executable instruction.
  • the computer-executable instruction can execute any of the above method embodiments. Back-to-source processing methods.
  • FIG. 8 shows a schematic structural diagram of a computing device provided by an embodiment of the disclosure.
  • the specific embodiment of the disclosure does not limit the specific implementation of the computing device.
  • the computing device may include: a processor (processor) 802, a communications interface (Communications Interface) 804, a memory (memory) 806, and a communication bus 808.
  • processor processor
  • communications interface Communication Interface
  • memory memory
  • the processor 802, the communication interface 804, and the memory 806 complete communication with each other through the communication bus 808.
  • the communication interface 804 is used to communicate with network elements of other devices such as clients or other servers.
  • the processor 802 is configured to execute the program 810. Specifically, it can execute relevant steps in the above embodiment of the back-to-source processing method for a computing device.
  • program 810 may include program code including computer operating instructions.
  • the processor 802 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present disclosure.
  • the one or more processors included in the computing device may be the same type of processor, such as one or more CPUs; or they may be different types of processors, such as one or more CPUs and one or more ASICs.
  • Memory 806 is used to store programs 810.
  • Memory 806 may include high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.
  • modules in the devices in the embodiment can be adaptively changed and arranged in one or more devices different from that in the embodiment.
  • the modules or units or components in the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All features disclosed in this specification (including accompanying claims, abstract and drawings) and any method so disclosed may be employed in any combination, except that at least some of such features and/or processes or units are mutually exclusive. All processes or units of the equipment are combined.
  • Each feature disclosed in this specification may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.
  • Various component embodiments of the present disclosure may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof.
  • a microprocessor or a digital signal processor (DSP) may be used in practice to implement some or all functions of some or all components according to embodiments of the present disclosure.
  • DSP digital signal processor
  • the present disclosure may also be implemented as an apparatus or apparatus program (eg, computer program and computer program product) for performing part or all of the methods described herein.
  • Such a program implementing the present disclosure may be stored on a computer-readable medium, or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, or provided on a carrier signal, or in any other form.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开公开了一种回源处理方法、装置、计算设备及存储介质,该方法包括:接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端;对索引文件进行解析,在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件;接收源站服务器回传的至少一个媒体切片文件,存储至少一个媒体切片文件。

Description

回源处理方法、装置、计算设备及存储介质
相关申请的交叉参考
本申请要求于2022年8月8日提交中国专利局、申请号为2022109458217、名称为“回源处理方法、装置、计算设备及存储介质”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本公开涉及互联网技术领域,具体涉及一种回源处理方法、装置、计算设备及存储介质。
背景技术
在HLS(HTTP Live Streaming,基于HTTP的自适应码率流媒体传输协议)直播体系中,主播端推流到源站服务器,源站服务器对直播流进行生产以得到媒体切片文件,并在媒体切片文件生产完成之后更新索引文件。客户端在播放HLS直播流时,需要先请求索引文件,根据索引文件向内容分发***请求下载对应的媒体切片文件。
现有技术中,如果内容分发***未存储客户端所请求的媒体切片文件,则会回源到源站服务器以下载媒体切片文件,下载完成之后再将媒体切片文件返回给客户端,回源链路复杂且回源过程耗时较长,媒体文件请求未命中内容分发***存储的客户端需要等待回源处理,导致拉流时间过长以及直播播放卡顿。
发明内容
本公开实施例的目的是提供一种回源处理方法、装置、计算设备及存储介质,以解决上述现有技术中媒体文件请求未命中内容分发***存储的客户端需要等待回源处理导致拉流时间过长以及直播播放卡顿的问题。
根据本公开的一个方面,提供了一种回源处理方法,其中,方法包括:
接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端;
对索引文件进行解析,在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件;
接收源站服务器回传的至少一个媒体切片文件,存储至少一个媒体切片文件。
根据本公开的另一方面,提供了一种回源处理方法,其中,方法包括:
接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端;
接收内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件;
向内容分发***回传至少一个媒体切片文件,以供内容分发***存储至少一个媒体切片文件。
根据本公开的另一方面,提供了一种回源处理装置,其中,装置包括:
第一收发模块,适于接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
第二收发模块,适于接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端;
解析模块,适于对索引文件进行解析;
预回源模块,适于在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件;
媒体文件收发模块,适于接收源站服务器回传的至少一个媒体切片文件;
存储模块,适于存储至少一个媒体切片文件。
根据本公开的另一方面,提供了一种回源处理装置,其中,装置包括:
第三收发模块,适于接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端;
第四收发模块,适于接收内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件,向内容分发***回传至少一个媒体切片文件,以供内容分发***存储至少一个媒体切片文件。
根据本公开的又一方面,提供了一种计算设备,包括:处理器、存储器、通信接口和通信总线,处理器、存储器和通信接口通过通信总线完成相互间 的通信;
存储器用于存放至少一可执行指令,可执行指令使处理器执行上述回源处理方法对应的操作。
根据本公开的再一方面,提供了一种非易失性计算机可读存储介质,该非易失性计算机可读存储介质中存储有至少一可执行指令,可执行指令使处理器执行如上述回源处理方法对应的操作。
根据本公开的再又一方面,提供了一种计算机程序产品,该计算机程序产品包括存储在上述非易失性计算机可读存储介质上的计算程序。
根据本公开的回源处理方法、装置、计算设备及存储介质,一方面,在制作索引文件时,在索引文件中额外添加即将生产的媒体切片文件的预缓存标签,客户端发起索引文件请求时,索引文件被回传至客户端和内容分发***,内容分发***解析出索引文件中的预缓存标签,向源站服务器请求回源预缓存标签对应的媒体切片文件,通过上述方式,使得媒体切片文件还未生产结束就下载到内容分发***中,而不是在请求媒体文件时内容分发***未存储有相应媒体切片文件的情况下再去回源下载,实现了媒体切片文件的提前回源,使得客户端的媒体文件请求都能够命中内容分发***存储,能够减少客户端拉流时间、降低客户端卡顿率以及优化用户播放体验;再一方面,源站服务器在接收到内容分发***的回源请求时,建立与内容分发***的通信链接,用以传输即将生产的媒体切片文件,并且在该即将生产的媒体切片文件生产结束后而断开,能够保证数据传输的准确性,并且及时断开通信链接能够及时释放所占用的资源。
上述说明仅是本公开技术方案的概述,为了能够更清楚了解本公开的技术手段,而可依照说明书的内容予以实施,并且为了让本公开的上述和其它目的、特征和优点能够更明显易懂,以下特举本公开的具体实施方式。
附图概述
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本公开的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了本公开实施例提供的回源处理方法的流程图;
图2示出了本公开另一实施例提供的回源处理方法的流程图;
图3示出了现有技术中回源流程的示意图;
图4示出了本公开另一实施例客户端观看直播流程的交互时序图;
图5示出了本公开另一实施例提供的回源处理方法的流程图;
图6示出了本公开另一实施例提供的回源处理装置的结构示意图;
图7示出了本公开另一实施例提供的回源处理装置的结构示意图;以及
图8示出了本公开实施例提供的计算设备的结构示意图。
本公开的较佳实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
首先,对本公开一个或多个实施例涉及的名词术语进行解释。
直播流:直播音视频数据的传输,它能够被作为一个稳定的和连续的流通过网络传输给观众观看。
直播拉流:是指通过直播云平台到用户指定的源站拉取直播流的过程。
内容分发***:即CDN(Content Delivery Network)***,是构筑在现有网络上的一种先进的流量分配网络,是现有网络中增加一层新的网络架构,将网站的内容分布到最接近用户的网络“边缘”,提高用户访问网站的响应速度,具有负载均衡的特点,CDN具有缓存、镜像以及整体负载均衡的功能,以缓存网站中的静态数据为主。
CDN边缘节点,用于覆盖对应区域用户的服务器节点。
CDN源站,回源资源汇集的中心节点。
源站服务器:将直播流生产为媒体切片文件的服务设备。
回源处理:内容分发***向内容提供者发起回源请求以拉取直播内容的过程。
索引文件:HLS直播协议中用于记录媒体文件信息的文件。
媒体切片文件:HLS直播协议中用于存储和播放音视频数据的文件。
图1示出了本公开实施例提供的回源处理方法的流程图,本实施例的方法应用于内容分发***,如图1所示,该方法包括以下步骤:
步骤S110,接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器。
在HLS直播体系中,在观看HLS直播流时,需要客户端先请求索引文件,客户端请求到索引文件之后,获取索引文件中的媒体文件列表,再根据媒体文件列表请求媒体切片文件并进行播放。
索引文件由源站服务器制作而成,源站服务器对直播流进行切片,以生成媒体切片文件,当媒体切片文件生产结束时,源站服务器就将该生产结束的媒体切片文件的文件名更新到索引文件的媒体文件列表中。随着直播端不断地推流,源站服务器能够不断地生产新的媒体切片文件,因而索引文件是不断更新的,客户端需要不断地请求索引文件,客户端每次请求的都是索引文件的更新。
其中,索引文件请求用于获取索引文件。由客户端向内容分发***发起索引文件请求,内容分发***再将客户端的索引文件请求转发至源站服务器。
步骤S120,接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端。
源站服务器响应于内容分发***所转发的索引文件请求,将索引文件回传给内容分发***,内容分发***再将索引文件转发至客户端。
其中,客户端接收到索引文件之后,根据索引文件中包含的媒体文件列表再向内容分发***发起媒体文件请求,以获取相应的媒体切片文件。
步骤S130,对索引文件进行解析,在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求。
内容分发***接收到索引文件之后,对索引文件进行解析,获取索引文件中包含的至少一个媒体切片文件的预缓存标签,并向源站服务器发起回源请求,用以下载预缓存标签对应的至少一个媒体切片文件。
其中,预缓存标签是额外添加到索引文件中的字段,内容分发***可识别,而客户端不可识别,用于指示内容分发***向源站服务器请求回源预缓存标签对应的媒体切片文件,区别于生产结束的媒体切片文件,预缓存标签所对应的媒体切片文件是指即将生产的媒体切片文件,比如正在生产中的媒体切片文件以及待生产的媒体切片文件。
本实施例的方法中,源站服务器在制作索引文件时,除了根据至少一个生产结束的媒体切片文件更新了索引文件的媒体文件列表,并且,还在索引文件中添加了至少一个即将生产的媒体切片文件的预缓存标签。
步骤S140,接收源站服务器回传的至少一个媒体切片文件,存储至少一个媒体切片文件。
源站服务器响应于内容分发***的回源请求,将预缓存标签对应的至少一个媒体切片文件回传给内容分发***,内容分发***存储接收到的至少一个媒体切片文件。
现有技术中,由于只有等待媒体切片文件生产完成之后,才能够更新到索引文件的媒体文件列表中,客户端才能根据索引文件的媒体文件列表请求媒体文件,并且,只有在回源结束内容分发***存储了媒体切片文件之后,其他客户端才能够复用存储的媒体切片文件,因此,对于第一个利用索引文件请求媒体切片文件的客户端而言,其请求的媒体切片文件不会存在于内容分发***中,内容分发***需要向源站服务器请求回源客户端所请求的媒体切片文件,下载完成之后才会向客户端回传,客户端需等待较长时间才能拉流成功。
下面以一个具体的示例说明本实施例的方法,假设以序号标识媒体切片文件的生产序号,在当前更新时机下,生产结束的媒体切片文件包括1-3号的媒体切片文件,即将生产的媒体切片文件包括4-6号的媒体切片文件,索引文件包含1-3号媒体切片文件对应的媒体文件列表以及4-6号的媒体切片文件对应的预缓存标签,此时客户端请求索引文件,客户端根据索引文件向内容分发***请求1-3号的媒体切片文件,而内容分发***向源站服务器请求回源4-6号的媒体切片文件;随着源站服务器不断生产,到达下一个更新时机时,4-6号的媒体切片文件已经生产结束,当前即将生产的媒体切片文件包括7-9号的媒体切片文件,索引文件包含4-6号媒体切片文件对应的媒体文件列表以及7-9号的媒体切片文件对应的预缓存标签,此时客户端请求索引文件,客户端根据索引文件则请求4-6号的媒体切片文件,4-6号的媒体切片文件已经存储在内容分发***中,内容分发***直接回传存储的媒体切片文件。简单来讲,对于任一媒体切片文件而言,在生产过程中就被回传到内容分发***中了,因此,当该媒体切片文件生产结束被更新到索引文件中,且客户端根据索引文件请求该媒体切片文件时,内容分发***已经存储有该媒体切片文件,从而避免了媒体文件请求无法命中内容分发***存储的问题。
综上所述,根据本实施例所提供的回源处理方法,在制作索引文件时,在索引文件中额外添加即将生产的媒体切片文件的预缓存标签,客户端发起索引文件请求时,索引文件被回传至客户端和内容分发***,内容分发***解析出索引文件中的预缓存标签,向源站服务器请求回源预缓存标签对应的 媒体切片文件,通过上述方式,使得媒体切片文件还未生产结束就下载到内容分发***中,而不是在请求媒体文件时内容分发***未存储有相应媒体切片文件的情况下再去回源下载,实现了媒体切片文件的提前回源,使得客户端的媒体文件请求都能够命中内容分发***存储,能够减少客户端拉流时间、降低客户端卡顿率以及优化用户播放体验。
图2示出了本公开另一实施例提供的回源处理方法的流程图,该方法应用于内容分发***中,如图2所示,该方法包括以下步骤:
步骤S210,接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器。
步骤S220,接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端。
索引文件请求用于获取索引文件。由客户端向内容分发***发起索引文件请求,内容分发***再将客户端的索引文件请求转发到源站服务器,源站服务器响应于索引文件请求将索引文件回传至内容分发***,再由内容分发***回传给客户端。
索引文件由源站服务器制作,源站服务器在制作索引文件时,除了根据至少一个生产结束的媒体切片文件更新索引文件的媒体文件列表,还在索引文件中添加了至少一个即将生产的媒体切片文件的预缓存标签。
其中,客户端接收到索引文件之后,根据其中包含的媒体文件列表再向内容分发***请求相应的媒体切片文件。
步骤S230,对索引文件进行解析,在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件。
内容分发***接收到索引文件之后,对索引文件进行解析,获取索引文件中包含的至少一个媒体切片文件的预缓存标签,并向源站服务器发起回源请求,用以下载预缓存标签对应的至少一个媒体切片文件。
其中,预缓存标签是额外添加到索引文件中的字段,内容分发***可识别,而客户端不可识别,用于指示内容分发***向源站服务器下载预缓存标签对应的至少一个媒体切片文件,预缓存标签所对应的至少一个媒体切片文件是指即将生产的媒体切片文件。
可选地,预缓存标签记录有至少一个媒体切片文件的文件名,内容分发***接收到索引文件之后,对索引文件进行解析,获取索引文件中包含的预 缓存标签,向源站服务器发起回源请求,以便下载预缓存标签所记录的至少一个媒体切片文件的文件名所对应的媒体切片文件。
可选地,预缓存标签由指定字符以及媒体切片文件的文件名组成,例如,EXT-X-BILI-PERFRETCH:URL=27019223.m4s?prefetch,其中,EXT-X-BILI-PERFRETCH为指定字符,URL=27019223.m4s?prefetch为媒体切片文件的文件名。内容分发***先识别出索引文件中的指定字符,再获取与指定字符相关联的文件名,即得到需要下载的媒体切片文件的文件名。
步骤S240,接收源站服务器边生产边回传的至少一个媒体切片文件,存储至少一个媒体切片文件。
其中,即将生产的媒体切片文件也就是还没有生产结束的媒体切片文件,则源站服务器一边生产一边将生产得到文件数据传输给内容分发***,内容分发***对接收到的文件数据进行存储。
具体地,通过源站服务器建立的通信链接,接收源站服务器回传的至少一个媒体切片文件,其中,通信链接由源站服务器在接收到回源请求后而建立,在上述至少一个即将生产的媒体切片文件生产结束后而断开。通过该方式,建立通信链接用以传输正在生产的媒体切片文件,并且在生产结束之后断开通信链接,能够保证数据传输的准确性,并且及时断开通信链接能够及时释放所占用的资源。
步骤S250,在至少一个媒体切片文件生产结束后,源站服务器更新索引文件,使更新后的索引文件的媒体文件列表包含至少一个媒体切片文件的文件名。
在上述至少一个即将生产的媒体切片文件生产结束时,到达索引文件更新时机,此时源站服务器会将该更新时机下的生产结束的媒体切片文件的文件名更新到索引文件的媒体文件列表中,同时,根据该更新时机下的至少一个即将生产的媒体切片文件的文件名生成预缓存标签并更新到索引文件中,得到更新后的索引文件。
步骤S260,接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;接收源站服务器响应于索引文件请求而回传的更新后的索引文件,将更新后的索引文件转发至客户端;接收客户端基于更新后的索引文件发送的媒体文件请求,将存储的至少一个媒体切片文件回传给客户端。
客户端再发起索引文件请求,内容分发***将索引文件请求转发至源站服务器,源站服务器响应于索引文件请求将更新后的索引文件回传至内容分发***,内容分发***再将更新后的索引文件回传至客户端;客户端接收到 更新后的索引文件,提取出其中的媒体文件列表,向内容分发***请求媒体文件列表所包含的文件名对应的媒体切片文件,更新后的索引文件的媒体文件列表所对应的媒体切片文件通过提前回源已经存储在内容分发***中,客户端的媒体文件请求能够命中内容分发***的存储内容,则将存储的媒体切片文件回传给客户端。
图3示出了现有技术中回源流程的示意图,具体如下:各个用户端请求HLS直播流,客户端会请求到CDN边缘服务器;如果请求未命中CDN边缘服务器,则回源到CDN源站;如果请求也未命中CDN源站,则会回源请求到源站服务器,以下载客户端所请求的媒体切片文件,并且只有等待媒体文件缓存构建成功之后,其他客户端才能够利用该缓存,其中主播端的直播流通过上行边缘服务器推送到源站服务器,采用RTMP(Real Time Messaging Protocol,实时消息传输协议)推送直播流。可见,回源过程需要回源到直播源站服务器,中间至少经过了两层链路传输,网络延迟非常明显,极大地延长了拉流时间,并且,当第一个用户回源时,其他用户必须等待该用户回源结束后,才能够复用缓存,因此,现有技术的回源处理会导致客户端拉流时间较长、直播卡顿率高,从而影响用户体验。
图4示出了本公开另一实施例客户端观看直播流程的交互时序图,具体包括如下流程步骤:
步骤1,客户端向CDN边缘发送索引文件请求;
步骤2,CDN边缘向CDN源站转发索引文件请求;
步骤3,CDN源站向源站服务器转发索引文件请求;
步骤4,源站服务器向CDN源站返回索引文件响应,即回传m3u8文件,假设源站服务器将生产结束的媒体切片文件1-3对应的媒体文件列表以及即将生产的媒体切片文件4-6对应的预缓存标签更新到了索引文件中;
步骤5,CDN源站向CDN边缘返回索引文件响应,即回传m3u8文件;
步骤6,CDN边缘向客户端返回索引文件响应,即回传m3u8文件;
步骤7,CDN边缘解析索引文件,判断索引文件是否包含预缓存标签。
步骤8,若包含预缓存标签,CDN边缘向CDN源站请求预缓存文件,即请求预缓存即将生产的媒体切片文件4-6;
步骤9,CDN源站向源站服务器请求预缓存文件;
步骤10,源站服务器向CDN源站返回媒体文件响应,即回传媒体切片文件,CDN源站对接收到的媒体切片文件进行缓存,即源站服务器一边生产 媒体切片文件4-6一边将已生产的数据传输给CDN源站。
步骤11,CDN源站向CDN边缘返回媒体文件响应,即回传媒体切片文件4-6,CDN边缘对接收到的媒体切片文件4-6进行缓存。
步骤12,等待媒体切片文件在CDN边缘写完后,更新索引文件,即在媒体切片文件生产结束之后,更新索引文件,更新后的索引文件包含已经生产结束的媒体切片文件4-6对应的媒体文件列表以及即将生产的媒体切片文件7-9对应的预缓存标签。
上述步骤1-步骤11是客户端请求索引文件后的处理流程,其中省略了客户端根据索引文件的媒体文件列表请求媒体文件的流程,具体地:客户端根据索引文件中的媒体文件列表,向CDN边缘请求相应的媒体切片文件1-3,如果CDN缓存了客户端所请求的媒体切片文件1-3,则直接回传缓存的文件,反之,如果CDN边缘未缓存客户端所请求的媒体切片文件1-3,则需要进行回源。
之后,还会有客户端请求更新后的索引文件,具体流程如下:
步骤13,客户端向CDN边缘发送索引文件请求;
步骤14,CDN边缘向CDN源站转发索引文件请求;
步骤15,CDN源站向源站服务器转发索引文件请求;
步骤16,源站服务器向CDN源站返回索引文件响应,即回传m3u8文件,此时索引文件中包含生产结束的媒体切片文件4-6对应的媒体文件列表以及即将生产的媒体切片文件7-9对应的预缓存标签;
步骤17,CDN源站向CDN边缘返回索引文件响应,即回传m3u8文件;
步骤18,CDN边缘向客户端返回索引文件响应,即回传m3u8文件;
步骤19,客户端根据索引文件中的媒体文件列表,向CDN边缘请求媒体文件,即请求媒体切片文件4-6;
步骤20,媒体文件请求命中CDN边缘缓存,CDN边缘返回客户端所请求的媒体切片文件,媒体切片文件4-6已经缓存在CDN边缘中,客户端的媒体文件请求能够命中CDN边缘缓存。
上述步骤13-步骤20是客户端请求更新后的索引文件后的处理流程,其中,省略了CDN根据更新索引文件中的预缓存标签请求回源媒体切片文件的流程,即请求回源即将生产的媒体切片文件7-9的流程,可参见前述内容,在此不进行赘述。更新后的索引文件的媒体文件列表对应于媒体切片文件4-6,因此,客户端根据更新后的索引文件请求媒体切片文件4-6,媒体切片 文件4-6已经缓存在CDN边缘中了,即便是第一个请求该更新索引文件的客户端,其媒体文件请求也能够直接命中CDN的缓存,因此极大地减少了拉流时间,能够降低直播卡顿率,提升用户体验。
根据本实施例的回源处理方法,源站服务器在制作索引文件时,在索引文件中额外添加即将生产的媒体切片文件的预缓存标签;客户端发起索引文件请求时,索引文件被回传至客户端和内容分发***,内容分发***解析出索引文件中的预缓存标签,根据预缓存标签向源站服务器发起回源请求,源站服务器接收到回源请求之后建立与内容分发***之间的通信链接,并边生产边回传预缓存标签对应的媒体切片文件,从而将还未生产完成的媒体切片文件提前存储到内容分发***,而不是请求媒体文件无法命中内容分发***的情况下再去回源,实现了媒体切片文件的提前回源,使得客户端的媒体文件请求都能够命中内容分发***,能够减少客户端拉流时间、降低客户端卡顿率以及优化用户播放体验,进一步地,有回源需求时建立通信链接用于传输文件,一旦媒体切片文件生产结束则将通信链接断开,能够保证数据传输的准确性,并且能够及时释放通信链接所占用的资源。
图5示出了本公开另一实施例提供的回源处理方法的流程图,本实施例的方法应用于源站服务器,如图5所示,该方法包括以下步骤:
步骤S510,接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端。
其中,索引文件请求用于获取索引文件。由客户端向内容分发***发起索引文件请求,内容分发***再将客户端的索引文件请求转发至源站服务器。
索引文件由源站服务器制作而成,源站服务器对直播流进行切片,以生成媒体切片文件,当媒体切片文件生产结束时,源站服务器就将该生产结束的媒体切片文件的文件名更新到索引文件的媒体文件列表中。
源站服务器响应于内容分发***所转发的索引文件请求,将索引文件回传给内容分发***,内容分发***再将索引文件转发至客户端。
客户端接收到索引文件之后,根据其中包含的媒体文件列表再向内容分发***请求相应的媒体切片文件。
步骤S520,接收内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求。其中,至少一个媒体切片文件是即将生产的媒体切片文件。
内容分发***接收到索引文件之后,对索引文件进行解析,获取索引文 件中包含的至少一个媒体切片文件的预缓存标签,并向源站服务器发起回源请求,用以下载预缓存标签对应的媒体切片文件。
其中,预缓存标签是额外添加到索引文件中的字段,内容分发***可识别,而客户端不可识别,用于指示内容分发***向源站服务器回源预缓存标签对应的媒体切片文件,区别于生产结束的媒体切片文件,预缓存标签所对应的媒体切片文件是指即将生产的媒体切片文件,比如正在生产中的媒体切片文件以及即将要生成的媒体切片文件。
本实施例的方法中,源站服务器在制作索引文件时,除了根据至少一个生产结束的媒体切片文件更新了索引文件的媒体文件列表,并且,还在索引文件中添加了至少一个即将生产的媒体切片文件的预缓存标签。
可选地,预缓存标签记录有至少一个媒体切片文件的文件名,内容分发***接收到索引文件之后,对索引文件进行解析,获取索引文件中包含预缓存标签,向源站服务器发起回源请求,以便下载预缓存标签所记录的至少一个媒体切片文件的文件名所对应的媒体切片文件。
可选地,预缓存标签由指定字符以及媒体切片文件的文件名组成,例如,EXT-X-BILI-PERFRETCH:URL=27019223.m4s?prefetch,其中,EXT-X-BILI-PERFRETCH为指定字符,URL=27019223.m4s?prefetch为媒体切片文件的文件名。内容分发***先识别出索引文件中的指定字符,再获取与指定字符相关联的文件名,即得到需要下载的媒体切片文件的文件名。
步骤S530,向内容分发***回传至少一个媒体切片文件,以供内容分发***存储至少一个媒体切片文件。
源站服务器响应于内容分发***的回源请求,将预缓存标签对应的至少一个媒体切片文件回传给内容分发***,内容分发***存储接收到的至少一个媒体切片文件。
具体地,边生产边向内容分发***回传至少一个媒体切片文件。其中,即将生产的媒体切片文件也就是还没有生产结束的媒体切片文件,则源站服务器一边生产一边将生产得到文件数据传输给内容分发***,内容分发***对接收到的文件数据进行存储。
在一种可选的方式中,在接收到回源请求之后,建立通信链接;通过通信链接,向内容分发***回传至少一个媒体切片文件;在至少一个媒体切片文件生产结束后,断开通信链接。通过该方式,建立通信链接用以传输正在生产的媒体切片文件,并且在生产结束之后断开通信链接,能够保证数据传输的准确性,并且及时断开通信链接能够及时释放所占用的资源。
在至少一个媒体切片文件生产结束后,更新索引文件,使更新后的索引文件的媒体文件列表包含至少一个媒体切片文件的文件名。在至少一个即将生产的媒体切片文件生产结束之后,到达新的索引文件更新时机,此时源站服务器会将生产结束的媒体切片文件的文件名更新到索引文件的媒体文件列表中,同时,根据下一组至少一个即将生产的媒体切片文件的文件名生成预缓存标签并更新到索引文件中,得到更新后的索引文件。
根据本实施例所提供的回源处理方法,源站服务器在制作索引文件时,在索引文件中额外添加即将生产的媒体切片文件的预缓存标签,客户端发起索引文件请求时,索引文件被回传至客户端和内容分发***,内容分发***解析出索引文件中的预缓存标签,向源站服务器请求回源预缓存标签对应的媒体切片文件,通过上述方式,使得媒体切片文件还未生产结束就下载到内容分发***中,而不是在请求媒体文件时内容分发***未存储有相应媒体切片文件的情况下再去回源下载,实现了媒体切片文件的提前回源,使得客户端的媒体文件请求都能够命中内容分发***存储,能够减少客户端拉流时间、降低客户端卡顿率以及优化用户播放体验。
图6示出了本公开另一实施例提供的回源处理装置的结构示意图,如图6所示,该装置包括:
第一收发模块61,适于接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
第二收发模块62,适于接收源站服务器响应于索引文件请求而回传的索引文件,将索引文件转发至客户端;
解析模块63,适于对索引文件进行解析;
预回源模块64,适于在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向源站服务器发起用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件;
媒体文件收发模块65,适于接收源站服务器回传的至少一个媒体切片文件;
存储模块66,适于接收源站服务器回传的至少一个媒体切片文件,存储至少一个媒体切片文件。
在一种可选的方式中,媒体文件收发模块65进一步适于:接收源站服务器边生产边回传的至少一个媒体切片文件;
其中,在存储至少一个媒体切片文件之后,在至少一个媒体切片文件生 产结束后,源站服务器更新索引文件,使更新后的索引文件的媒体文件列表包含至少一个媒体切片文件的文件名。
在一种可选的方式中,第一收发模块61进一步适于:在源站服务器更新索引文件之后,接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
第二收发模块62进一步适于:接收源站服务器响应于索引文件请求而回传的更新后的索引文件,将更新后的索引文件转发至客户端;
媒体文件收发模块65进一步始于:接收客户端基于更新后的索引文件发送的媒体文件请求,将存储的至少一个媒体切片文件回传给客户端。
在一种可选的方式中,预缓存标签记录有至少一个媒体切片文件的文件名。
在一种可选的方式中,媒体文件收发模块65进一步适于:通过源站服务器建立的通信链接,接收源站服务器回传的至少一个媒体切片文件;其中,通信链接由源站服务器在接收到回源请求后而建立,在至少一个媒体切片文件生产结束后而断开。
图7示出了本公开另一实施例提供的回源处理装置的结构示意图,如图7所示,该装置包括:
第三收发模块71,适于接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端;
第四收发模块72,适于接收内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求;至少一个媒体切片文件是即将生产的媒体切片文件,向内容分发***回传至少一个媒体切片文件,以供内容分发***存储至少一个媒体切片文件。
在一种可选的方式中,第四收发模块72进一步适于:边生产边向内容分发***回传至少一个媒体切片文件;
装置还包括:文件更新模块,适于在至少一个媒体切片文件生产结束后,更新索引文件,使更新后的索引文件的媒体文件列表包含至少一个媒体切片文件的文件名。
在一种可选的方式中,装置还包括:链接处理模块,适于在接收到回源请求之后,建立通信链接;
第四收发模块72进一步适于:通过通信链接,向内容分发***回传至少一个媒体切片文件;
链接处理模块进一步适于:在至少一个媒体切片文件生产结束后,断开通信链接。
本公开实施例提供了一种非易失性计算机可读存储介质,该非易失性计算机可读存储介质存储有至少一可执行指令,该计算机可执行指令可执行上述任意方法实施例中的回源处理方法。
图8示出了本公开实施例提供的计算设备的结构示意图,本公开具体实施例并不对计算设备的具体实现做限定。
如图8所示,该计算设备可以包括:处理器(processor)802、通信接口(Communications Interface)804、存储器(memory)806、以及通信总线808。
其中:处理器802、通信接口804、以及存储器806通过通信总线808完成相互间的通信。通信接口804,用于与其它设备比如客户端或其它服务器等的网元通信。处理器802,用于执行程序810,具体可以执行上述用于计算设备的回源处理方法实施例中的相关步骤。
具体地,程序810可以包括程序代码,该程序代码包括计算机操作指令。
处理器802可能是中央处理器CPU,或者是特定集成电路ASIC(Application Specific Integrated Circuit),或者是被配置成实施本公开实施例的一个或多个集成电路。计算设备包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。
存储器806,用于存放程序810。存储器806可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
在此提供的算法或显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述,构造这类***所要求的结构是显而易见的。此外,本公开实施例也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本公开的内容,并且上面对特定语言所做的描述是为了披露本公开的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本公开的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个公开方面中的一个 或多个,在上面对本公开的示例性实施例的描述中,本公开实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本公开要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,公开方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本公开的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本公开的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本公开实施例的一些或者全部部件的一些或者全部功能。本公开还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本公开的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本公开进行说明而不是对本公开进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开可以借助 于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤,除有特殊说明外,不应理解为对执行顺序的限定。

Claims (13)

  1. 一种回源处理方法,其中,所述方法包括:
    接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
    接收源站服务器响应于所述索引文件请求而回传的索引文件,将索引文件转发至客户端;
    对所述索引文件进行解析,在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向所述源站服务器发起用于请求所述至少一个媒体切片文件的回源请求;所述至少一个媒体切片文件是即将生产的媒体切片文件;
    接收所述源站服务器回传的所述至少一个媒体切片文件,存储所述至少一个媒体切片文件。
  2. 根据权利要求1所述的方法,其中,所述接收所述源站服务器回传的所述至少一个媒体切片文件具体为:接收所述源站服务器边生产边回传的所述至少一个媒体切片文件;
    在所述存储所述至少一个媒体切片文件之后,所述方法还包括:在所述至少一个媒体切片文件生产结束后,所述源站服务器更新索引文件,使更新后的索引文件的媒体文件列表包含所述至少一个媒体切片文件的文件名。
  3. 根据权利要求2所述的方法,其中,在所述源站服务器更新索引文件之后,所述方法还包括:
    接收客户端发送的索引文件请求,将所述索引文件请求转发至源站服务器;
    接收源站服务器响应于所述索引文件请求而回传的更新后的索引文件,将更新后的索引文件转发至客户端;
    接收客户端基于所述更新后的索引文件发送的媒体文件请求,将存储的所述至少一个媒体切片文件回传给客户端。
  4. 根据权利要求1-3中任一项所述的方法,其中,所述预缓存标签记录有所述至少一个媒体切片文件的文件名。
  5. 根据权利要求1-4中任一项所述的方法,其中,所述接收所述源站服务器回传的所述至少一个媒体切片文件进一步包括:
    通过所述源站服务器建立的通信链接,接收所述源站服务器回传的所述至少一个媒体切片文件;其中,所述通信链接由所述源站服务器在接收到所 述回源请求后而建立,在所述至少一个媒体切片文件生产结束后而断开。
  6. 一种回源处理方法,其中,所述方法包括:
    接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端;
    接收所述内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求;所述至少一个媒体切片文件是即将生产的媒体切片文件;
    向所述内容分发***回传所述至少一个媒体切片文件,以供所述内容分发***存储所述至少一个媒体切片文件。
  7. 根据权利要求6所述的方法,其中,所述向所述内容分发***回传所述至少一个媒体切片文件具体为:边生产边向所述内容分发***回传所述至少一个媒体切片文件;
    所述方法还包括:在所述至少一个媒体切片文件生产结束后,更新索引文件,使更新后的索引文件的媒体文件列表包含所述至少一个媒体切片文件的文件名。
  8. 根据权利要求6或7所述的方法,其中,所述方法还包括:在接收到回源请求之后,建立通信链接;
    所述向所述内容分发***回传所述至少一个媒体切片文件具体为:通过所述通信链接,向所述内容分发***回传所述至少一个媒体切片文件;
    所述方法还包括:在所述至少一个媒体切片文件生产结束后,断开所述通信链接。
  9. 一种回源处理装置,其中,所述装置包括:
    第一收发模块,适于接收客户端发送的索引文件请求,将索引文件请求转发至源站服务器;
    第二收发模块,适于接收源站服务器响应于所述索引文件请求而回传的索引文件,将索引文件转发至客户端;
    解析模块,适于对所述索引文件进行解析;
    预回源模块,适于在索引文件包含至少一个媒体切片文件的预缓存标签的情况下,向所述源站服务器发起用于请求所述至少一个媒体切片文件的回源请求;所述至少一个媒体切片文件是即将生产的媒体切片文件;
    媒体文件收发模块,适于接收所述源站服务器回传的所述至少一个媒体 切片文件;
    存储模块,适于存储所述至少一个媒体切片文件。
  10. 一种回源处理装置,其中,所述装置包括:
    第三收发模块,适于接收内容分发***转发的客户端发送的索引文件请求,将索引文件通过内容分发***回传给客户端;
    第四收发模块,适于接收所述内容分发***通过解析索引文件得到预缓存标签而发起的用于请求至少一个媒体切片文件的回源请求;所述至少一个媒体切片文件是即将生产的媒体切片文件,向所述内容分发***回传所述至少一个媒体切片文件,以供所述内容分发***存储所述至少一个媒体切片文件。
  11. 一种计算设备,包括:处理器、存储器、通信接口和通信总线,所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信;
    所述存储器用于存放至少一可执行指令,所述可执行指令使所述处理器执行如权利要求1-5中任一项所述的回源处理方法对应的操作,和/或,执行如权利要求6-8中任一项所述的回源处理方法对应的操作。
  12. 一种非易失性计算机可读存储介质,所述非易失性计算机可读存储介质中存储有至少一可执行指令,所述可执行指令使处理器执行如权利要求1-5中任一项所述的回源处理方法对应的操作,和/或,执行如权利要求6-8中任一项所述的回源处理方法对应的操作。
  13. 一种计算机程序产品,所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被处理器执行时,使所述处理器执行如权利要求1-5中任一项所述的回源处理方法对应的操作,和/或,执行如权利要求6-8中任一项所述的回源处理方法对应的操作。
PCT/CN2023/108946 2022-08-08 2023-07-24 回源处理方法、装置、计算设备及存储介质 WO2024032363A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210945821.7A CN115297095B (zh) 2022-08-08 2022-08-08 回源处理方法、装置、计算设备及存储介质
CN202210945821.7 2022-08-08

Publications (1)

Publication Number Publication Date
WO2024032363A1 true WO2024032363A1 (zh) 2024-02-15

Family

ID=83827461

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/108946 WO2024032363A1 (zh) 2022-08-08 2023-07-24 回源处理方法、装置、计算设备及存储介质

Country Status (2)

Country Link
CN (1) CN115297095B (zh)
WO (1) WO2024032363A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115297095B (zh) * 2022-08-08 2024-03-08 上海哔哩哔哩科技有限公司 回源处理方法、装置、计算设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130159383A1 (en) * 2011-12-16 2013-06-20 Microsoft Corporation Application-driven cdn pre-caching
KR20160083675A (ko) * 2015-01-02 2016-07-12 에스케이텔레콤 주식회사 라이브 스트리밍 컨텐츠 제공 방법, 이를 위한 라이브 스트리밍 캐시 장치 및 이를 위한 프로그램을 기록한 컴퓨터 판독 가능한 기록매체
US20160316234A1 (en) * 2015-04-27 2016-10-27 Centurylink Intellectual Property Llc Intelligent Video Streaming System
CN108540868A (zh) * 2018-05-16 2018-09-14 北京百度网讯科技有限公司 Hls直播的处理方法、装置、服务器、终端及存储介质
CN110309342A (zh) * 2018-03-28 2019-10-08 腾讯科技(深圳)有限公司 一种媒体文件获取方法、装置及存储介质
CN115297095A (zh) * 2022-08-08 2022-11-04 上海哔哩哔哩科技有限公司 回源处理方法、装置、计算设备及存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632642B (zh) * 2017-03-16 2021-09-03 杭州海康威视数字技术股份有限公司 流媒体推送方法及装置
CN110300339B (zh) * 2018-03-22 2022-03-29 贵州白山云科技股份有限公司 一种直播多媒体回播方法、装置及***
CN111372099A (zh) * 2020-03-20 2020-07-03 山东云缦智能科技有限公司 一种低延迟hls直播的实现方法
CN113329267B (zh) * 2021-05-27 2023-03-24 北京奇艺世纪科技有限公司 一种视频播放方法、装置、终端设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130159383A1 (en) * 2011-12-16 2013-06-20 Microsoft Corporation Application-driven cdn pre-caching
KR20160083675A (ko) * 2015-01-02 2016-07-12 에스케이텔레콤 주식회사 라이브 스트리밍 컨텐츠 제공 방법, 이를 위한 라이브 스트리밍 캐시 장치 및 이를 위한 프로그램을 기록한 컴퓨터 판독 가능한 기록매체
US20160316234A1 (en) * 2015-04-27 2016-10-27 Centurylink Intellectual Property Llc Intelligent Video Streaming System
CN110309342A (zh) * 2018-03-28 2019-10-08 腾讯科技(深圳)有限公司 一种媒体文件获取方法、装置及存储介质
CN108540868A (zh) * 2018-05-16 2018-09-14 北京百度网讯科技有限公司 Hls直播的处理方法、装置、服务器、终端及存储介质
CN115297095A (zh) * 2022-08-08 2022-11-04 上海哔哩哔哩科技有限公司 回源处理方法、装置、计算设备及存储介质

Also Published As

Publication number Publication date
CN115297095B (zh) 2024-03-08
CN115297095A (zh) 2022-11-04

Similar Documents

Publication Publication Date Title
US10609101B2 (en) Streaming of segmented content
EP3105903B1 (en) Requesting multiple chunks from a network node on the basis of a single request message
US10397289B2 (en) HTTP live streaming (HLS) video client synchronization
WO2017096830A1 (zh) 用于cdn平台的内容分发方法及调度代理服务器
WO2019128800A1 (zh) 一种内容服务的实现方法、装置及内容分发网络节点
US10200490B2 (en) Content-based redirection
CN110933517B (zh) 码率切换方法、客户端和计算机可读存储介质
WO2012079223A1 (zh) 内容传送网络中流媒体请求地址映射的方法及装置、缓存节点
WO2015165395A1 (en) Video playback method and apparatus
US9356985B2 (en) Streaming video to cellular phones
CN102055718B (zh) 一种在http streaming***中实现分层请求内容的方法,装置和***
US20220060532A1 (en) Method for transmitting resources and electronic device
CN108200444B (zh) 一种视频直播的方法、装置和***
WO2024032363A1 (zh) 回源处理方法、装置、计算设备及存储介质
US20100198977A1 (en) Automatic live stream trees
WO2015176470A1 (zh) 一种http协议的缓存状态更新方法和设备、处理机
WO2017101370A1 (zh) 直播视频的处理方法及装置
CN111355979B (zh) 一种在线音频快速播放方法
CN112243136B (zh) 内容播放方法、视频存储方法和设备
CN113891176B (zh) 基于hls的点播流量控制方法、装置、设备及存储介质
CN113949897B (zh) 一种mp4视频流媒体点播的分片缓存加速方法
CN117354288A (zh) 一种视频转码播放方法、装置、计算设备和存储介质
EP3292698A1 (en) Http live streaming (hls) video client synchronization

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: 23851585

Country of ref document: EP

Kind code of ref document: A1