CN112104885B

CN112104885B - System and method for accelerating M3U8 initial playing speed in live broadcasting

Info

Publication number: CN112104885B
Application number: CN202010940425.6A
Authority: CN
Inventors: 魏代邦; 徐民; 张晓刚
Original assignee: Haikan Network Technology Shandong Co ltd
Current assignee: Haikan Network Technology Shandong Co ltd
Priority date: 2020-09-09
Filing date: 2020-09-09
Publication date: 2022-06-24
Anticipated expiration: 2040-09-09
Also published as: CN112104885A

Abstract

The invention relates to a system and a method for accelerating the initial play speed of M3U8 in live broadcast, wherein the system comprises a player, a buffer layer and a remote CDN server, and the buffer layer is arranged between the player and the remote CDN server; the remote CDN server is used for providing playing resources; the buffer layer downloads playing lists and ts slice playing resources from the CDN server, and controls and processes the downloaded playing lists and ts slices; the player is used to request a ts slice play resource from the buffer layer. The invention converts the mode that the player acquires the play list and ts slices from the CND under the original HLS protocol into the process that the player acquires the play list and ts slices from the CDN from the buffer layer and then returns the play list and ts slices to the player. When the player buffers the slices for the first time, the buffer layer replaces the original slices with a small slice, thereby reducing the waiting time for loading the slices. The problem of longer program buffering time when watching live broadcast in a low-bandwidth network environment is solved.

Description

System and method for accelerating M3U8 initial playing speed in live broadcasting

Technical Field

The invention relates to the technical field of network televisions, in particular to a system and a method for accelerating the initial play speed of M3U8 in live broadcast.

Background

IPTV is in a vigorous development period as a representative of new media for networks. The set-top box or other digital equipment with audio and video coding and decoding capability is used as a terminal, and various interactive multimedia services are provided for users by aggregating various streaming media service contents and value-added applications of service providers. HTTP Live Streaming (HLS) is an HTTP-based Streaming media network transport protocol proposed by apple inc. It divides the entire stream into small HTTP-based files for downloading, only a portion of each time. The video encapsulation format of the HLS protocol is TS, and the player will return a playlist of m3u8 when requesting a media asset. The playing list comprises a group of TS addresses, and the client requests each section of address to obtain TS data stream in sequence. HLS differs from the conventional RTP protocol in that it is based on the HTTP transport protocol, can traverse any firewall or proxy server that allows HTTP data to pass through, and it is also easy to use a content distribution network to transport media streams.

In a network environment with a low network bandwidth, the delay time of live video adopting the HLS protocol often cannot be reduced to less than 10 seconds, which becomes an important defect of live application adopting HLS. When the player buffers the data, the player acquires and parses an m3u8 playlist from the CDN service, and sequentially downloads ts slices in the playlist. When the downloading is completed, the player decodes the slice resources and starts playing the content. The loading duration of the player as perceived by the user is mainly determined by the time the player downloads the first ts slice. When the network speed is low, the downloading of the first slice is slow, the loading time of the player is too long, and the waiting time of the user is correspondingly prolonged. For services with sensitive live broadcast delay, too long delay time may mean the loss of clients, and how to reduce the initial delay loading time of video becomes an important issue.

The Chinese patent document discloses an online live broadcast content generation method, an online live broadcast content generation device and an online live broadcast system, and the application numbers are as follows: 201910336076.4, filing date: 2019-04-24, publication number is: 110113624A. The patent provides a set of method, device and system for recording live audio and video, transmitting and caching data, and processing and uploading slices of audio and video files. The problem solved by the patent mainly occurs in the audio and video production period and occurs at the server side. The problem solved by the patent occurs in an audio and video using client, and is secondary processing is carried out on audio and video content after the client acquires the content through an HLS protocol and before the content is used. The methods used and the environment vary greatly.

Chinese patent literature discloses a system and a method for live video broadcast in m3u8 format, and the application numbers are as follows: 201810239491.3, filing date: 2018-03-22, the publication number is: 108495151A. This patent provides a live system and method for converting rtmp live data into m3u8 format, which also occurs at the server side. The method is applied to an audio and video using client, and is used for performing secondary processing on audio and video contents after the client acquires the contents through an HLS protocol and before the contents are used. The methods used and the environment vary greatly.

The chinese patent document discloses a transmission system and method based on CDN network data, and the application number is: 201810010737.X, with the application date: 2018-01-05, with the publication number: 108174232A. This patent provides a network data transmission system based on CDN, and the realization thinking of this patent has similar part with this patent, all is after obtaining the broadcast data, and data are processed in advance through the buffer layer. However, the processing object and procedure of the patent are completely different from that of the patent, and the processing object of the patent is a video in M3U8 format based on HLS.

Disclosure of Invention

In order to overcome the defects, the invention aims to provide a method for accelerating the initial playing speed of M3U8 in live broadcasting.

The technical scheme adopted by the invention for solving the technical problems is as follows: a system for accelerating the initial playing speed of M3U8 in live broadcasting comprises a player, a buffer layer and a remote CDN server, wherein the buffer layer is arranged between the player and the remote CDN server;

the remote CDN server is used for providing playing resources;

the buffer layer downloads playing resources such as a playing list and ts slices from the CDN server, controls and processes the downloaded playing list and ts slices, controls the downloading granularity of the first ts slice, and shortens the downloading time of the first ts slice in a mode of only downloading a part of the first ts slice during first downloading, so that the loading waiting time of the player is reduced.

A method for accelerating the initial play speed of M3U8 in live broadcast includes

Step 1, when a live broadcast application program is started, a local HTTP service is started at the same time, wherein the local HTTP service is a buffer layer part;

step 2, when the live broadcast application program tries to start playing, the playing address m3u8 is transmitted to the player, the application program modifies the domain name part of the playing address to be local, and the domain name part of the original m3u8 playing address is added to the playing address in a parameter mode;

step 3, when the player requests for playing resources, the address points to a local HTTP service, namely a buffer layer, so that the player can request the local HTTP service, the local HTTP service acquires parameters representing an original domain name from a request address, assembles an original request address and then sends a request to the remote CDN server;

step 4, local HTTP service requests CDN addresses, the requests can obtain playlist addresses under different code rates according to HLS protocols, and the local HTTP service downloads and caches playlist files with corresponding code rates according to the code rates of a local environment;

step 5, the local HTTP service tries to download a first ts slice in the playlist, the downloading service obtains the file size of the first slice, and applies for the memory size of a first part a of the slice and the memory size of a second part b of the slice according to the downloading percentage configuration of the first slice;

step 6, downloading a first slice file from a remote CDN server by a download service and writing the first slice file into a, writing b after a is filled, when the size of the downloaded content exceeds the size of a cache region a, determining that the download of a first part a of the first slice is finished, simultaneously inserting a ts address in front of a first index of a downloaded playlist by a local HTTP service, wherein the domain name part of the address is a local service, returning a buffer file a when a player requests the address from the local service, simultaneously modifying a second ts address, wherein the domain name of the address is the local service, returning a buffer file b when the player requests the address from the local service, and keeping the rest ts addresses unchanged;

step 7, the local HTTP service returns the modified playlist to the player, the player reads the first ts address of the playlist and tries to load, the address is modified to the address of the local service in the previous step, and therefore the player will request the address from the local service;

step 8, the local service returns the first part a of the buffered first slice to the player, and the player obtains the slice and starts playing;

and 9, in the playing process of the slice a, the local service finishes downloading the slice b, when the player requests the slice b, the local service returns the slice b, and the subsequent slices are directly obtained from the remote CDN server by the player.

The invention has the following beneficial effects: the invention converts the mode that the player acquires the play list and ts slices from the CND under the original HLS protocol into the process that the player acquires the play list and ts slices from the CDN from the buffer layer and then returns the play list and ts slices to the player. When the player buffers the slices for the first time, the buffer layer replaces the original slices with a small slice, so that the waiting time for loading the slices is reduced. The problem of longer program buffering time when watching live broadcast in a low-bandwidth network environment is solved.

Drawings

Fig. 1 is a schematic diagram of a player requesting a resource in the prior art.

FIG. 2 is a diagram illustrating a player requesting a resource according to the present invention.

FIG. 3 is a timing diagram illustrating a process of requesting resources by a player according to the present invention.

FIG. 4 is a diagram of an m3u8 multi-rate playlist according to the present invention.

FIG. 5 is a schematic diagram of a modification of playing address insertion according to the present invention.

Detailed Description

The present invention will now be described in further detail with reference to the accompanying drawings.

As shown in fig. 1, the prior art is a schematic diagram of a player requesting resources, and before using the present invention, the player directly initiates a request to the CDN.

As shown in fig. 2, a system for accelerating the initial playing speed of M3U8 in live broadcasting includes a remote CDN server, a buffer layer, and a player, where when the player requests a resource, the player first makes a request to a local HTTP service buffer layer, and after receiving the request, the service buffer layer initiates a request to the remote CDN server, and when obtaining corresponding content, the HTTP service performs processing, and then returns the content to the player.

FIG. 2 is a timing diagram of request processing according to the present invention, the process of which is:

step 1, an application transmits an m3u8 address to a player, and the application needs to process an original playing address according to a specified format, wherein a root path of the original address replaces a path of local HTTP service, and the root path of the original path is attached to a parameter of a request address;

step 2, the player requests a local m3u8 address;

step 3, splicing the request address by the local HTTP service, and acquiring and requesting an original CDN address;

step 4 shows that the remote CDN server returns a file containing a plurality of groups of playlist addresses;

step 5, the local HTTP service selects a play list address from the play list file according to the code rate of the current environment;

step 6 shows that the local HTTP service requests a playlist from the remote CDN server;

step 7, the remote CDN server returns a playlist file, where the playlist includes a download address of a group of ts files, the specific characteristics of the group address are that the number part of the file name of the address is equal, the difference value between two adjacent files is one, and the number part of the file name increases progressively in the order from top to bottom;

step 8, as shown in the fixed directory (if not, create the corresponding directory) under the local sdcard of the local HTTP service, save the playlist file;

step 9 shows that the local HTTP service requests the remote CDN server for the first ts slice of the playlist, in this process, the configuration parameter of the application is read, the percentage of the first ts slice download is obtained, the size of the first portion a and the size of the second portion b during distributed downloading are calculated according to the size and the percentage value of the first ts slice, and a corresponding memory space is opened up;

step 10, the local HTTP service writes the first half of the first slice into buffer a until a specified percentage, and the local HTTP service writes the content of buffer a into a local file to generate a first buffer slice m, where the name of the file is the number of first slice file names minus one;

step 11, inserting a new address into the saved playlist file by the local HTTP service, where the address is located before the first index of the playlist address, the address content obtains the name of the sub path and the buffer slice m from the local service path and the local slice file, that is, after the local HTTP service inserts the first slice of the playlist to the buffer slice m of the local service;

step 12 shows that the second playing address of the playlist file is modified in the local HTTP service, and the second address in the playlist is locked by the regular expression and the root path of the second address is modified to point to the local service;

step 13, executed synchronously with steps 11 and 12, after the first half of the first slice is buffered, continuing to buffer the remaining part b and saving it to the local slice file n, where the name of the slice file is the file name of the original first slice, that is, the file name of the play address modified in step 12;

step 14, the local HTTP service returns the modified playlist file to the player;

step 15, the player parses the playlist file and requests the first ts slice from the local HTTP service;

step 16, the local HTTP service responds to the player request and returns the buffered slice m to the player;

step 17 shows that the player will continue to request a second slice from the local HTTP service in the following;

as shown in step 18, the local HTTP service will respond to the request of the player and return the buffered slice n to the player;

step 19, the player continues to request other slices in the following, and the player initiates a request to the remote CDN server;

as shown in step 20, the remote CDN server returns the corresponding slice to the player, and steps 19 and 20 are repeated until the playing of the content of the current playlist is finished.

Fig. 3 is a download address diagram of a multi-rate playlist conforming to HLS protocol:

as shown in fig. 3, the file contains multiple sets of m3u8 addresses, and BANDWIDTH of each set of addresses represents the bit rate of the respective resource, when the local HTTP service of the present invention parses the first m3u8 request, it will select the appropriate playlist address from the list according to the bit rate of the local environment, and make the request.

FIG. 5 is a comparison of the playlist content map before and after modification:

as shown in the left block diagram of fig. 5, an original playlist file is shown, in which the addresses of ts slices are in a convention form, the filename part is composed of "_" plus number, and two adjacent ts addresses are incremented by one from top to bottom;

when the buffer local HTTP service attempts to modify the original playlist, a piece of data is inserted before the first ts playlist address, the digital part of the filename of the playlist address data is subtracted from the digital part of the filename of the first piece of data of the original playlist, and the local HTTP service modifies its root path to point to the local HTTP service.

When the buffer layer local HTTP service modifies the root path of the second play address to point to the local HTTP service.

As shown in the right block diagram of fig. 5, for the modified playlist by the local HTTP service, comparing with the drawing, it can be seen that the ts content part of the playlist is added with a piece of data at the start position, the number part XXX483 of the file name of the data is obtained by subtracting the original XXX484, and the root paths of the first piece and the second piece of data point to the local HTTP service.

The present invention is not limited to the above embodiments, and any structural changes made under the teaching of the present invention shall fall within the protection scope of the present invention, which is similar or similar to the technical solutions of the present invention.

The techniques, shapes, and configurations not described in detail in the present invention are all known techniques.

Claims

1. A method for accelerating the starting playing speed of M3U8 in live broadcasting is characterized in that: the method comprises the following steps:

step 2, when the live broadcast application program tries to start playing, transmitting an m3u8 playing address to the player, modifying the domain name part of the playing address to be local by the application program, and adding the domain name part of the original m3u8 playing address to the playing address in a parameter form;

step 3, when the player requests to play resources, the address points to a local HTTP service, namely a buffer layer, the local HTTP service acquires parameters representing an original domain name from a request address, assembles an original request address and then sends a request to a remote CDN server;

step 4, according to the HLS protocol, the request can obtain playlist addresses under different code rates, the remote CDN server returns playlist files, the playlist includes download addresses of a group of ts files, the specific characteristics of the group of addresses are that the digital parts of the file names of the addresses are equal difference, the difference value of two adjacent files is one, and the digital parts of the file names are increased progressively from top to bottom;

the local HTTP service downloads and caches a playlist file with a corresponding code rate according to the code rate of a local environment, the local HEEP service modifies the playlist, two ts addresses are inserted in front of the playlist, meanwhile, a first ts slice is processed into two parts, namely a first part slice a and a second part slice b, and each ts address corresponds to the first part slice a and the second part slice b respectively;

the method for modifying the playlist includes that a local HTTP service tries to download a first ts slice in the playlist, the download service acquires the file size of the first slice, and applies for the memory size of a first part a of the slice and the memory size of a second part b of the slice according to the download percentage configuration of the first slice; downloading a first slice file from a remote CDN server by a downloading service and writing the first slice file into a, writing b when a is full, when the size of the downloaded content exceeds the size of a cache area a, determining that the first part a of the first slice is completely downloaded, simultaneously inserting a ts address in front of a first index of a downloaded playlist by a local HTTP service, wherein the domain name part of the address is a local service, returning a buffer file a when a player requests the address from the local service, simultaneously modifying a second ts address, wherein the domain name of the address is the local service, returning the buffer file b when the player requests the address from the local service, and keeping the rest ts addresses unchanged;

step 5, the local HTTP service returns the modified playlist to the player, the player reads the first ts address of the playlist and tries to load, the address is modified to the address of the local service in the last step, and therefore the player can request the address from the local HTTP service;

step 6, the local service returns the first part a of the buffered first slice to the player, and the player obtains the slice and starts playing;

and 7, in the playing process of the slice a, the local service finishes downloading the slice b, when the player requests the slice b, the local service returns the slice b, and the subsequent slices are directly obtained from the remote CDN server by the player.

2. The method of claim 1, wherein the method for increasing the starting playing speed of M3U8 in live broadcasting comprises: in step 4, after the remote CDN server returns the list, the local HTTP service stores the playlist file in the fixed directory under the local sdcard, and if not, creates a corresponding directory.