Media file acquisition methods, servers, terminals, and storage media
By generating a virtual bitrate in the CDN network to determine the storage path of media files, the problem of request failure caused by bitrate switching is solved, and the reliability of terminal acquisition of media files and seamless playback are achieved.
Patent Information
- Application Number
- CN202011027344.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-09-25
- Publication Date
- 2025-10-31
- Estimated Expiration
- 2040-09-25
AI Technical Summary
The existing CDN network has a problem where requests for media files fail when the terminal requests them because the storage path has not been updated due to bitrate switching.
By generating a virtual bitrate and determining the storage path information of the media file based on it, the virtual bitrate remains unchanged when the real bitrate is updated, so that the terminal can accurately locate the storage location of the media file.
It improves the reliability of the terminal in obtaining media files, reduces the number of failed requests, and provides a seamless playback experience.
Smart Images

Figure CN114254134B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and in particular to a method for acquiring media files, a server, a terminal, and a storage medium. Background Technology
[0002] Existing CDN (Content Delivery Network) networks consist of origin servers, CDN central servers, and CDN edge servers. To provide higher performance services, CDN networks typically record media files from the origin servers and store these recorded media files on central or edge servers before providing services to end users.
[0003] Since CDN networks store media files according to their corresponding bitrates, if the bitrate of the origin server changes, the storage path of the corresponding media file also changes. However, during the process of the terminal requesting the media file, the bitrate in the main index returned by the CDN network to the terminal is not updated. Therefore, when the terminal requests the media file using the old bitrate, the request will fail.
[0004] Therefore, improving the reliability of terminal acquisition of media files has become an urgent problem to be solved. Summary of the Invention
[0005] The main objective of this invention is to provide a media file acquisition method, server, terminal, and storage medium. By generating a virtual bitrate based on the real bitrate and determining the storage path information of the media file based on the virtual bitrate, the terminal can acquire the media file based on the storage path information corresponding to the virtual bitrate, thereby improving the reliability of the terminal in acquiring the media file.
[0006] In a first aspect, embodiments of the present invention provide a media file acquisition method, applied in a server, comprising:
[0007] The storage path information of the media file is determined based on the virtual bitrate corresponding to the actual bitrate of the index file, wherein the virtual bitrate is not updated when the actual bitrate is updated; when a master index request is received from the terminal, the storage path information is sent to the terminal so that the terminal can obtain the media file according to the storage path information.
[0008] Secondly, embodiments of the present invention also provide a media file acquisition method, applied in a terminal, comprising:
[0009] Send a master index request to the server; receive the storage path information of the media file returned by the server based on the master index request, wherein the storage path information is determined by the virtual bitrate corresponding to the real bitrate of the index file, and the virtual bitrate is not updated when the real bitrate is updated; obtain the media file in the server according to the storage path information.
[0010] Thirdly, embodiments of the present invention also provide a server, the server including a processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for implementing communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the media file acquisition method as described above.
[0011] Fourthly, embodiments of the present invention also provide a terminal, the terminal including a processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for implementing communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the media file acquisition method as described above.
[0012] Fifthly, embodiments of the present invention also provide a storage medium for computer-readable storage, characterized in that the storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of any media file acquisition method provided in this specification.
[0013] This invention provides a media file acquisition method, server, terminal, and storage medium. By determining the storage path information of the media file based on the virtual bitrate corresponding to the real bitrate of the index file, the virtual bitrate does not update with the real bitrate. That is, the virtual bitrate remains unchanged regardless of how the real bitrate changes. Therefore, the storage path information of the media file can be accurately determined based on the virtual bitrate. When a master index request is received from the terminal, the storage path information is sent to the terminal, enabling the terminal to accurately acquire the media file based on the storage path information. Thus, the reliability of the terminal in acquiring media files is improved.
[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description
[0015] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0016] Figure 1 This is a schematic diagram of the structure of a content delivery network provided in an embodiment of the present invention;
[0017] Figure 2 This is a schematic interactive diagram illustrating the recording of media files according to an embodiment of the present invention;
[0018] Figure 3 This is a schematic interactive diagram of another recording media file provided in an embodiment of the present invention;
[0019] Figure 4 This is a schematic diagram of the structure of a media file acquisition system provided in an embodiment of the present invention;
[0020] Figure 5 This is a schematic block diagram of a server structure provided in an embodiment of the present invention;
[0021] Figure 6 This is a schematic block diagram of the structure of a terminal provided in an embodiment of the present invention;
[0022] Figure 7 This is a schematic flowchart of a media file acquisition method provided in an embodiment of the present invention;
[0023] Figure 8 This is a schematic flowchart illustrating a sub-step for recording a media file according to an embodiment of the present invention;
[0024] Figure 9 This is a schematic flowchart illustrating the sub-steps for generating a primary index and a secondary index, provided in an embodiment of the present invention.
[0025] Figure 10 This is a schematic flowchart illustrating a sub-step of sending storage path information to a terminal, as provided in an embodiment of the present invention.
[0026] Figure 11 This is a schematic flowchart of another media file acquisition method provided in an embodiment of the present invention;
[0027] Figure 12 This is a schematic interactive diagram illustrating how a terminal acquires media files, as provided in an embodiment of the present invention. Detailed Implementation
[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0029] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.
[0030] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0031] This invention provides a media file acquisition method, a server, a terminal, and a storage medium. The media file acquisition method can be applied to a server or a terminal. By generating a virtual bitrate based on the real bitrate and determining the storage path information of the media file based on the virtual bitrate, the terminal can accurately acquire the media file based on the storage path information corresponding to the virtual bitrate, thereby improving the reliability of the terminal in acquiring media files.
[0032] The server can be a central server or an edge server in a content delivery network. The terminal can be an electronic device such as a smartphone, tablet, laptop, desktop computer, personal digital assistant, and wearable device.
[0033] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a content delivery network system provided in an embodiment of the present invention. Figure 1 As shown, the content delivery network system includes an origin server 1001, a central server 1002, and an edge server 1003. The edge server 1003 communicates with the origin server 1001 through the central server 1002.
[0034] For example, a content delivery network system may include multiple central servers 1002 and multiple edge servers 1003. The central servers 1002 and edge servers 1003 can serve as service nodes in the content delivery network.
[0035] It's important to note that a Content Delivery Network (CDN) is a new network architecture added to the existing Internet, consisting of high-performance acceleration nodes distributed globally. These high-performance service nodes store service content according to specific caching strategies. When a user requests a particular service content, the request is routed to the service node closest to the user, allowing for a rapid response and effectively reducing user access latency and improving availability.
[0036] It should be noted that the media file acquisition method in this embodiment of the invention is applied to a server, which refers to a central server 1002 or an edge server 1003.
[0037] It should be noted that the origin server 1001 is the core of the content delivery network system. Each service node needs to obtain service content from the origin server 1001 and distribute it to user terminals. When the service content in the origin server 1001 is updated, the origin server 1001 will actively push the service content to the central server 1002 and / or the edge server 1003.
[0038] In some embodiments, such as Figure 2 As shown, Figure 2 This is a schematic interactive diagram of recording media files provided in an embodiment of the present invention; when the central server 1002 has a recording module, the central server 1002 can obtain the business content, such as media files, from the source server 1001; and then store the obtained business content in a local database or in the cloud.
[0039] In other embodiments, such as Figure 3 As shown, Figure 3 This is an illustrative interactive diagram of another recording media file provided by an embodiment of the present invention; when the central server 1002 does not have a recording module, the edge server 1003 can obtain the business content in the source server 1001 through the central server 1002 in a back-to-source manner, and store the obtained business content in a local database or in the cloud.
[0040] For example, a recording module can be deployed in the origin server 1001 and / or the edge server 1003.
[0041] It should be noted that the recording module is used to copy or record the business content in the source server 1001. When the central server 1002 has a recording module, the central server 1002 can directly copy the business content in the source server 1001 according to the recording module; when the central server 1002 does not have a recording module, the edge server 1003 copies the business content in the source server 1001 through the central server 1002 according to the recording module in a transparent manner.
[0042] It is understandable that transparent transmission refers to a data transmission method that is independent of the transmission network's medium, modulation and demodulation methods, transmission methods, and transmission protocols.
[0043] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a media file acquisition system provided in an embodiment of the present invention. Figure 4 As shown, the media file acquisition system may include a source server 1001, a central server 1002, an edge server 1003, and a terminal 1004.
[0044] For example, edge server 1003 can communicate with terminal 1004 and accept service requests sent by terminal 1004. These service requests may include main index requests, secondary index requests, and media file requests, etc. It can be understood that the main index request, secondary index request, and media file request constitute a complete media file acquisition process.
[0045] It should be noted that the edge server 1003 provides the terminal 1004 with a channel to access the network and the function of communicating with other server devices. Typically, the edge server 1003 is a group of servers that perform a single function.
[0046] In some embodiments, the edge server 1003 can determine the storage path information of the media file based on the virtual bitrate corresponding to the real bitrate of the index file, wherein the virtual bitrate is not updated when the real bitrate is updated; when the edge server 1003 receives the master index request sent by the terminal 1004, it sends the storage path information to the terminal 1004 so that the terminal 1004 can obtain the media file based on the storage path information.
[0047] In other embodiments, the central server 1002 can determine the storage path information of the media file based on the virtual bitrate corresponding to the real bitrate of the index file. When the real bitrate is updated, the virtual bitrate is not updated. When the central server 1002 receives the main index request sent by the terminal 1004, it sends the storage path information to the terminal 1004 so that the terminal 1004 can obtain the media file based on the storage path information.
[0048] For example, terminal 1004 can send a service request to edge server 1003. When the local disk of edge server 1003 stores the service content corresponding to the service request, edge server 1003 can directly return the service content to terminal 1004. For example, when the local disk of edge server 1003 does not store the service content corresponding to the service request, edge server 1003 can obtain the service content corresponding to the service request stored on the local disk of central server 1002 in a back-to-origin manner; if the local disk of central server 1002 does not store the service content corresponding to the service request, edge server 1003 can obtain the service content from origin server 1001 through central server 1002 in a back-to-origin manner.
[0049] Understandably, "origin pull" means that when a terminal (1004) accesses a URL (Uniform Resource Locator), if the resolved CDN node does not have the cached business content or the cache has expired, it will retrieve the content from the origin server (1001).
[0050] In this embodiment of the invention, terminal 1004 can request media files from central server 1002 or edge server 1003 based on HLS (HTTP Live Streaming) protocol.
[0051] In some embodiments, terminal 1004 may send a master index request to the server; receive storage path information of media files returned by the server based on the master index request, wherein the storage path information is determined by the virtual bitrate corresponding to the real bitrate of the index file, and the virtual bitrate is not updated when the real bitrate is updated; and obtain the media files in the server according to the storage path information.
[0052] Please see Figure 5 , Figure 5 This is a schematic block diagram of a server structure provided in an embodiment of the present invention. The server can be a central server 1002 or an edge server 1003.
[0053] Please see Figure 5 The central server 1002 or the edge server 1003 may include a processor 11 and a memory 12, wherein the processor 11 and the memory 12 can be connected by a bus, such as an I2C (Inter-integrated Circuit) bus or any applicable bus.
[0054] The memory 12 may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any media file acquisition method.
[0055] The processor 11 provides computing and control capabilities to support the operation of the entire computer device.
[0056] In one embodiment, the processor 11 is configured to run a computer program stored in the memory 12, and to perform the following steps when executing the computer program:
[0057] The storage path information of the media file is determined based on the virtual bitrate corresponding to the actual bitrate of the index file, wherein the virtual bitrate is not updated when the actual bitrate is updated; when a master index request is received from the terminal, the storage path information is sent to the terminal so that the terminal can obtain the media file according to the storage path information.
[0058] Processor 11 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0059] Please see Figure 6 , Figure 6 This is a schematic block diagram of the structure of a terminal 1004 provided in an embodiment of the present invention.
[0060] Please see Figure 6 Terminal 1004 may include processor 13 and memory 14, wherein processor 13 and memory 14 can be connected by a bus, such as an I2C (Inter-integrated Circuit) bus or any applicable bus.
[0061] The memory 14 may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any media file acquisition method.
[0062] The processor 13 provides computing and control capabilities to support the operation of the entire computer device.
[0063] In one embodiment, the processor 13 is configured to run a computer program stored in the memory 14, and to perform the following steps when executing the computer program:
[0064] Send a master index request to the server; receive the storage path information of the media file returned by the server based on the master index request, wherein the storage path information is determined by the virtual bitrate corresponding to the real bitrate of the index file, and the virtual bitrate is not updated when the real bitrate is updated; obtain the media file in the server according to the storage path information.
[0065] Processor 13 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0066] The following detailed description of some embodiments of the present invention is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0067] Please see Figure 7 , Figure 7 This is a schematic flowchart illustrating a media file acquisition method provided in an embodiment of the present invention. This media file acquisition method can be applied to a server. By generating a virtual bitrate based on the actual bitrate and determining the storage path information of the media file based on the virtual bitrate, the terminal can accurately acquire the media file according to the storage path information corresponding to the virtual bitrate, thus improving the reliability of the terminal acquiring the media file. The media file acquisition method includes steps S101 and S102.
[0068] Step S101: Determine the storage path information of the media file based on the virtual bitrate corresponding to the real bitrate of the index file, wherein the virtual bitrate is not updated when the real bitrate is updated.
[0069] It should be noted that the index file includes the actual bitrate, and the index file can be obtained from the origin server. For example, the index file can be an M3u8 file.
[0070] Bitrate refers to the number of bits of data transmitted per unit of time during data transmission. The actual bitrate refers to the bitrate at which the media file is received from the origin server. It can be understood that bitrate is used to determine the storage path information corresponding to the media file; different bitrates correspond to different storage path information. In this embodiment of the invention, the storage path information of the media file is determined based on the virtual bitrate, not the actual bitrate. The storage path information includes the folder name on the local disk.
[0071] For example, a main folder can be created on the local disk based on the virtual bitrate; different virtual bitrates correspond to different main folders. The virtual bitrate value can be used as the name of the main folder, thus distinguishing the main folders corresponding to different virtual bitrates. Then, different levels of subfolders can be created in the main folder to store different media files.
[0072] For example, when the virtual bitrate is 1000, the corresponding storage path information is as follows: 1000 / 202008 / 130500.
[0073] It should be noted that in this embodiment of the invention, when the actual bitrate of the media file is updated, the virtual bitrate is not updated. By determining the storage path information of the media file based on the virtual bitrate corresponding to the actual bitrate of the index file, the storage path information of the media file remains unchanged when the actual bitrate changes. This ensures that when the terminal requests the media file based on the storage path information corresponding to the virtual bitrate, the request will not fail, thus improving the reliability of the terminal in obtaining the media file.
[0074] In some embodiments, before determining the storage path information of the media file based on the virtual bitrate corresponding to the actual bitrate of the index file, the method may further include: obtaining the index file in the origin server; parsing the index file to obtain the actual bitrate of the index file; and encoding the actual bitrate to obtain the virtual bitrate corresponding to the actual bitrate.
[0075] For example, the central server or edge server can retrieve the index file from the origin server via a back-to-origin approach, and then parse the index file to obtain its actual bitrate. The parsing process can be performed using a pre-defined parsing protocol or tool; the specific parsing procedure will not be elaborated upon here.
[0076] For example, the index file is parsed, and the parsed bitrate is used as the actual bitrate.
[0077] For example, when encoding the actual bitrate, different encoding values can be defined. For instance, the virtual bitrate of the first actual bitrate can be encoded as 1000, the virtual bitrate of the second actual bitrate as 1001, and so on. The actual bitrate can also be encoded using a combination of numbers and letters, etc. The specific encoding method is not limited here.
[0078] By obtaining the index file from the origin server and parsing it, the actual bitrate of the index file can be obtained. Then, the actual bitrate can be encoded to obtain the virtual bitrate corresponding to the actual bitrate.
[0079] Please see Figure 8 , Figure 8 This is a schematic flowchart of a sub-step for recording a media file provided in an embodiment of the present invention, which may specifically include step S1011 and step S1012.
[0080] Step S1011: Obtain the media file from the source server based on the actual bitrate, and record the media file.
[0081] For example, the central server or edge server can obtain the media file from the source server according to the actual bitrate, and then record the media file according to the recording module.
[0082] In this embodiment of the invention, when the central server does not have a recording module deployed, the edge server can record media files from the source server through its own recording module.
[0083] Step S1012: According to the storage path information, the recorded media file is associated with the virtual bitrate and stored.
[0084] It is understood that, in this embodiment of the invention, the storage path information is set according to the virtual bitrate corresponding to the actual bitrate of the media file. For example, for the media file 2560000_20200813_052955_053002.ts, if the virtual bitrate corresponding to the media file 2560000_20200813_052955_053002.ts is 1000, then the media file 2560000_20200813_052955_053002.ts can be stored according to the storage path information 1000 / 202008 / 130500. The file 0813_052955_053002.ts is associated with a virtual bitrate of 1000 and stored on the local disk; the storage path information for the media file 2560000_20200813_052955_053002.ts is 1000 / 202008 / 130500 / 2560000_20200813_052955_053002.ts.
[0085] By associating media files with virtual bitrates, when a terminal requests a media file later, it can retrieve the media file based on the virtual bitrate, without the terminal being unable to retrieve the media file due to the switching of the real bitrate.
[0086] In some embodiments, after obtaining the media files from the origin server based on the actual bitrate in step S1011, a primary index and a secondary index may also be generated. Please refer to [link / reference]. Figure 9 , Figure 9 This is a schematic flowchart of the sub-steps for generating a primary index and a secondary index provided by an embodiment of the present invention, which may specifically include steps S1013 and S1014.
[0087] Step S1013: Determine the media file information corresponding to the media file.
[0088] For example, after recording a media file, the media file information corresponding to the media file can be obtained. For example, the media file information may include, but is not limited to, information such as encoding identifier, bandwidth, resolution, frame rate, and encoding format.
[0089] It should be noted that, in this embodiment of the invention, media file information can be used to generate a secondary index.
[0090] Step S1014: Based on the actual bitrate, the virtual bitrate, and the media file information, generate a primary index and a secondary index corresponding to the media file, and store the primary index and the secondary index together.
[0091] For example, a primary index is generated based on the actual bitrate and the virtual bitrate. The generated primary index is as follows: bandwidth|virtualbandwidth|filename, where the bandwidth field represents the actual bitrate, the virtualbandwidth field represents the virtual bitrate, and the filename field represents the name of the secondary index.
[0092] For example, a secondary index is generated based on the actual bitrate, the virtual bitrate, and media file information. The generated secondary index is shown below:
[0093] #EXTM3U
[0094] #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2062296,RESOLUTION=1280x720,FRAME-RATE=29.970,CODECS="avc1.640029,mp4a.40.2";
[0095] sec-v1-a1.m3u8? virtualbandwidth=1000.
[0096] In this context, #EXTM3U represents the m3u file header; PROGRAM-ID represents the encoding identifier; BANDWIDTH represents the actual bitrate; RESOLUTION represents the resolution; FRAME-RATE represents the frame rate; CODECS represents the encoding format; sec-v1-a1.m3u8 represents the secondary index name; and virtualbandwidth represents the virtual bitrate.
[0097] For example, after generating the primary index and secondary indexes, they can be stored together in the local database. The secondary indexes can be identified by their names within the primary index.
[0098] It's important to note that a primary index is an index that does not allow duplicate values in a specified indexed field or expression; it serves as a unique identifier for searching media files. Secondary indexes consist of fields and their corresponding values; they can be understood as auxiliary indexes to the primary index.
[0099] By determining the media file information corresponding to the media file, a primary index and a secondary index corresponding to the media file can be generated based on the actual bitrate, virtual bitrate, and media file information. Subsequently, the primary index and the secondary index can be returned based on the primary index request and the secondary index request from the terminal.
[0100] Step S102: When a master index request is received from the terminal, the storage path information is sent to the terminal so that the terminal can obtain the media file according to the storage path information.
[0101] It should be noted that when a terminal requests a media file, it first sends a main index request to the edge server; the edge server or the central server returns the storage path information of the media file stored in the local database to the terminal, and the terminal can obtain the media file according to the storage path information.
[0102] Please see Figure 10 , Figure 10 This is a schematic flowchart of the sub-step in step S102 where the storage path information is sent to the terminal when a master index request is received from the terminal. Specifically, it may include steps S1021 to S1023.
[0103] Step S1021: When a master index request is received from the terminal, the master index is assembled according to the master index request, and the assembled master index is sent to the terminal so that the terminal generates a secondary index request containing the virtual bit rate according to the assembled master index.
[0104] It should be noted that, in this embodiment of the invention, when a main index request is received from a terminal, the edge server or the central server does not directly send the main index stored in the local database back to the terminal. Instead, it first assembles the main index to add secondary index links and virtual bitrates to the main index.
[0105] In some embodiments, assembling the primary index according to the primary index request may include: generating secondary index links based on the secondary indexes associated with the primary index, and adding the secondary index links and virtual bitrates to the primary index.
[0106] For example, the generated secondary index link can be represented as: sec-v1-a1.m3u8?.
[0107] For example, the secondary index link and virtual bitrate are added to the main index to obtain the assembled main index, as shown below: bandwidth|virtualbandwidth|filename, sec-v1-a1.m3u8?virtualbandwidth=1000.
[0108] By generating secondary index links based on secondary indexes, the terminal can generate a secondary index request based on the secondary index links in the primary index after receiving the primary index. By adding the virtual bitrate to the primary index, the terminal can add the virtual bitrate to the secondary index request, so that the edge server or the central server can determine the storage path information based on the virtual bitrate in the secondary index request.
[0109] Step S1022: Upon receiving the secondary index request sent by the terminal, query the database for the storage path information corresponding to the virtual bitrate in the secondary index request.
[0110] For example, receiving a secondary index request from a terminal can be represented as: http: / / 172.16.79.117:6610 / 001 / 2 / lv7 / sec-v1-a1.m3u8?virtualbandwidth=1000.
[0111] For example, the edge server or the central server can query the database for the storage path information corresponding to the virtual bitrate based on the virtual bitrate in the secondary index request.
[0112] It is understandable that, since the media files are pre-associated with the virtual bitrate and stored on the local disk, the specific location of the media files on the local disk can be determined based on the virtual bitrate, and then the storage path information can be determined based on the specific location of the media files. For example, the storage path information is as follows:
[0113] 1000 / 202008 / 130500 / 2560000_20200813_052955_053002.ts.
[0114] Step S1023: Add the storage path information to the secondary index, and send the secondary index with the added storage path information to the terminal.
[0115] For example, a secondary index for storing path information is added as follows:
[0116] #EXTM3U
[0117] #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2062296,RESOLUTION=1280x720,FRAME-RATE=29.970,CODECS="avc1.640029,mp4a.40.2";
[0118] sec-v1-a1.m3u8? virtualbandwidth=1000;
[0119] 1000 / 202008 / 130500 / 2560000_20200813_052955_053002.ts.
[0120] By adding storage path information to the secondary index, the terminal can generate a media file request based on the storage path information in the secondary index, thereby successfully obtaining the media file.
[0121] In some embodiments, the media file acquisition method provided by the present invention may further include: when a new bitrate after the actual bitrate switch is received from the origin server, updating the actual bitrate in the main index according to the new bitrate.
[0122] It should be noted that when the bitrate in the origin server changes, the origin server will actively push the new bitrate to the central server and / or edge servers. The central server and / or edge servers can then update the actual bitrate in the main index based on the new bitrate, while the virtual bitrate in the main index remains unchanged.
[0123] By updating the real bitrate in the main index according to the new bitrate after the actual bitrate is switched based on the real bitrate sent by the origin server, the media files in the origin server can be obtained according to the real bitrate, and the storage path of the media files does not need to be changed according to the real bitrate, which improves the efficiency of media file management. By keeping the virtual bitrate in the main index unchanged, it can be ensured that no matter how the real bitrate changes, the terminal can determine the storage path information of the media files according to the virtual bitrate, reducing the number of times the terminal fails to obtain media files.
[0124] In some embodiments, when the origin server actively pushes the new bitrate after switching to the central server, if the central server does not have a recording module deployed, the origin server will pass the index information through to the edge server so that the edge server can update the real bitrate in the main index according to the index information.
[0125] The index information may include, but is not limited to, updated bitrate and media file path. It should be noted that the media file path refers to the storage path of the media file on the origin server. Using the media file path, the edge server can retrieve the media file from the origin server based on the updated bitrate.
[0126] The media file acquisition method, server, terminal, and storage medium provided in the above embodiments can obtain the true bitrate of the index file by acquiring the index file from the source server and parsing it. This true bitrate can then be encoded to obtain the corresponding virtual bitrate. By determining the storage path information of the media file based on the virtual bitrate corresponding to the true bitrate of the index file, the storage path information remains unchanged even when the true bitrate changes. This ensures that the terminal will not fail to request the media file based on the storage path information corresponding to the virtual bitrate, improving the reliability of media file acquisition. By associating the media file with the virtual bitrate, the terminal can subsequently retrieve the media file based on the virtual bitrate when requesting it, preventing the terminal from being unable to retrieve the media file due to changes in the true bitrate. By determining the media file information corresponding to the media file, a primary index and a secondary index corresponding to the media file can be generated based on the true bitrate, virtual bitrate, and media file information. Subsequent requests can be made based on the primary index and the secondary index. The index request returns both the primary and secondary indexes. By generating secondary index links based on the secondary indexes, the terminal can generate a secondary index request based on these links after receiving the primary index. Adding the virtual bitrate to the primary index allows the terminal to include it in the secondary index request, enabling edge or central servers to determine storage path information. Adding storage path information to the secondary index allows the terminal to generate a media file request based on this information, successfully retrieving the media file. Updating the primary index with the new bitrate after a bitrate switch from the origin server allows retrieval of media files from the origin server based on the actual bitrate, without needing to change the storage path, thus improving media file management efficiency. Maintaining the virtual bitrate in the primary index ensures that the terminal can determine the media file's storage path information regardless of changes in the actual bitrate, reducing the number of failed media file retrieval attempts.
[0127] Please see Figure 11 , Figure 11 This is a schematic flowchart illustrating another media file acquisition method provided in this embodiment of the invention. This media file acquisition method can be applied to a terminal. By receiving the storage path information of the media file returned by the server based on the master index request, the terminal accurately acquires the media file according to the storage path information corresponding to the virtual bitrate, reducing the number of media file acquisition failures and improving the reliability of media file acquisition. This media file acquisition method includes steps S201 to S203.
[0128] Step S201: Send the master index request to the server.
[0129] Please see Figure 12 , Figure 12 This is a schematic interactive diagram illustrating how a terminal obtains media files according to an embodiment of the present invention. When the terminal needs to obtain media files, it first sends a primary index request to the server to obtain the primary index; then, it generates a secondary index request based on the primary index, so that the server returns a secondary index that protects the storage path information of the media files; finally, it generates a media file request based on the storage path information and sends the media file request to the server to obtain the media files from the server.
[0130] The server can be either an edge server or a central server. The terminal can communicate with the edge server to obtain the storage path information of the media files stored in the local database of the edge server or the central server.
[0131] In some embodiments, after sending the master index request to the server, the process may further include: receiving the master index returned by the server based on the master index request, wherein the master index includes secondary index links and a virtual bitrate; generating a secondary index request based on the secondary index links and adding the virtual bitrate to the secondary index request; and sending the secondary index request with the added virtual bitrate to the server so that the server determines the storage path information corresponding to the media file based on the virtual bitrate.
[0132] For example, the receiving server returns the main index based on the main index request, where the returned main index is as follows: bandwidth|virtualbandwidth|filename,sec-v1-a1.m3u8?virtualbandwidth=1000.
[0133] For example, a secondary index request can be generated based on the secondary index link in the primary index. The generated secondary index request would look like this: http: / / 172.16.79.117:6610 / 001 / 2 / lv7 / sec-v1-a1.m3u8?. Then, the virtual bitrate is added to the secondary index request. If the virtual bitrate is 1000, the secondary index request with the virtual bitrate added would look like this: http: / / 172.16.79.117:6610 / 001 / 2 / lv7 / sec-v1-a1.m3u8?virtualbandwidth=1000.
[0134] By receiving the primary index returned by the server based on the primary index request, a secondary index request can be generated based on the secondary index links in the primary index. The virtual bitrate in the primary index is added to the secondary index request, so that the server determines the storage path information corresponding to the media file based on the virtual bitrate in the secondary index request and returns the storage path information.
[0135] Step S202: Receive the storage path information of the media file returned by the server based on the main index request, wherein the storage path information is determined by the virtual bitrate corresponding to the real bitrate of the index file, and the virtual bitrate is not updated when the real bitrate is updated.
[0136] For example, the storage path information of the media file returned by the server based on the master index request is received as follows: 1000 / 202008 / 130500 / 2560000_20200813_052955_053002.ts.
[0137] By receiving the storage path information of the media file returned by the server based on the master index request, since the storage path information of the media file is determined according to the virtual bitrate corresponding to the real bitrate, and the virtual bitrate is not updated when the real bitrate is updated, the terminal can accurately determine the storage path information corresponding to the media file according to the virtual bitrate, thereby reducing the number of times the media file acquisition fails and improving the reliability of the terminal to acquire media files.
[0138] Step S203: Obtain the media file in the server according to the storage path information.
[0139] For example, after determining the storage path information, a media file request corresponding to the target media file can be generated based on the storage path information; then the media file request can be sent to the server to obtain the target media file in the server.
[0140] By retrieving media files from the server based on storage path information, the terminal can play media files without being affected by bitrate switching on the source server, enabling seamless and smooth playback and improving the user experience.
[0141] The media file acquisition method, server, terminal, and storage medium provided in the above embodiments, by receiving the main index returned by the server based on the main index request, can generate a secondary index request based on the secondary index links in the main index, and add the virtual bitrate in the main index to the secondary index request. This allows the server to determine the storage path information corresponding to the media file based on the virtual bitrate in the secondary index request and return the storage path information. By receiving the storage path information of the media file returned by the server based on the main index request, since the storage path information of the media file is determined based on the virtual bitrate corresponding to the real bitrate, and the virtual bitrate does not update when the real bitrate is updated, the terminal can accurately determine the storage path information corresponding to the media file based on the virtual bitrate, thereby reducing the number of media file acquisition failures and improving the reliability of the terminal in acquiring media files. By acquiring the media file in the server based on the storage path information, the terminal is not affected by the bitrate switching of the source server when playing media files, enabling seamless and smooth playback and improving the user experience.
[0142] This invention also provides a storage medium for computer-readable storage, wherein the storage medium stores one or more programs that can be executed by one or more processors to implement the steps of any media file acquisition method provided in the specification of this invention.
[0143] For example, when the program is loaded by the processor, it can perform the following steps:
[0144] The storage path information of the media file is determined based on the virtual bitrate corresponding to the actual bitrate of the index file, wherein the virtual bitrate is not updated when the actual bitrate is updated; when a master index request is received from the terminal, the storage path information is sent to the terminal so that the terminal can obtain the media file according to the storage path information.
[0145] For example, once the program is loaded by the processor, it can perform the following steps:
[0146] Send a master index request to the server; receive the storage path information of the media file returned by the server based on the master index request, wherein the storage path information is determined by the virtual bitrate corresponding to the real bitrate of the index file, and the virtual bitrate is not updated when the real bitrate is updated; obtain the media file in the server according to the storage path information.
[0147] The storage medium can be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device.
[0148] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware embodiments, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0149] It should be understood that the term "and / or" as used in this specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations. It should be noted that, herein, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0150] The sequence numbers of the above embodiments of the present invention are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The above descriptions are only specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for obtaining media files, the method comprising: The actual bitrate of the index file is encoded to obtain the virtual bitrate corresponding to the actual bitrate; Based on the virtual bitrate, the storage path information of the media file is determined, wherein the virtual bitrate is not updated when the actual bitrate is updated; When a master index request is received from a terminal, the storage path information is sent to the terminal so that the terminal can obtain the media file based on the storage path information.
2. The media file acquisition method according to claim 1, characterized in that, Before encoding the actual bitrate of the index file to obtain the virtual bitrate corresponding to the actual bitrate, the method further includes: Obtain the index file from the origin server; The index file is parsed to obtain the actual bitrate of the index file.
3. The media file acquisition method according to claim 1, characterized in that, The method further includes: The media file is obtained from the source server based on the actual bitrate, and the media file is recorded. According to the storage path information, the recorded media file is stored in association with the virtual bitrate.
4. The media file acquisition method according to claim 3, characterized in that, After obtaining the media file from the source server based on the actual bitrate, the process further includes: Determine the media file information corresponding to the media file; Based on the actual bitrate, the virtual bitrate, and the media file information, a primary index and a secondary index corresponding to the media file are generated, and the primary index and the secondary index are stored together.
5. The media file acquisition method according to claim 4, characterized in that, When a master index request is received from a terminal, sending the storage path information to the terminal includes: When a main index request is received from a terminal, the main index is assembled according to the main index request, and the assembled main index is sent to the terminal so that the terminal can generate a secondary index request containing the virtual bitrate based on the assembled main index. Upon receiving the secondary index request sent by the terminal, the system queries the database for the storage path information corresponding to the virtual bitrate in the secondary index request; The storage path information is added to the secondary index, and the secondary index containing the storage path information is sent to the terminal.
6. The media file acquisition method according to claim 5, characterized in that, The assembly process of the primary index according to the primary index request includes: Based on the secondary index associated with the primary index, a secondary index link is generated, and the secondary index link and the virtual bitrate are added to the primary index.
7. The media file acquisition method according to any one of claims 4-6, characterized in that, The method further includes: When the origin server sends a new bitrate after the actual bitrate switch, the actual bitrate in the main index is updated according to the new bitrate.
8. A method for obtaining media files, characterized in that, The method includes: Send a primary index request to the server; The system receives storage path information of the media file returned by the server based on the main index request. The storage path information is determined by the virtual bitrate corresponding to the actual bitrate of the index file. When the actual bitrate is updated, the virtual bitrate is not updated. The virtual bitrate is obtained by encoding the actual bitrate of the index file. Based on the storage path information, the media file in the server is obtained.
9. The media file acquisition method according to claim 8, characterized in that, After sending the main index request to the server, the process also includes: Receive the main index returned by the server according to the main index request, wherein the main index includes secondary index links and virtual bitrate; A secondary index request is generated based on the secondary index link, and the virtual bitrate is added to the secondary index request; The secondary index request with the added virtual bitrate is sent to the server so that the server can determine the storage path information corresponding to the media file based on the virtual bitrate.
10. A server, characterized in that, The server includes a processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for implementing communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the media file acquisition method as described in any one of claims 1 to 7.
11. A terminal, characterized in that, The terminal includes a processor, a memory, a computer program stored in the memory and executable by the processor, and a data bus for establishing communication between the processor and the memory, wherein the computer program, when executed by the processor, implements the media file acquisition method as described in any one of claims 8 and 9.
12. A storage medium for readable storage, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to achieve: The media file acquisition method as described in any one of claims 1 to 7; or The media file acquisition method as described in any one of claims 8 and 9.
Citation Information
Patent Citations
Method for storing and reading multi-code-rate stream file and relevant device
CN103078847A