CN114173160B

CN114173160B - Live broadcast push flow method and device

Info

Publication number: CN114173160B
Application number: CN202111455765.0A
Authority: CN
Inventors: 朱翔; 许璟楠; 廖大达
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2023-11-21
Anticipated expiration: 2041-12-01
Also published as: CN114173160A

Abstract

The application provides a live broadcast plug flow method and a device, wherein the live broadcast plug flow method comprises the following steps: receiving a live broadcast request sent by a client, and determining the equipment type of the client according to the live broadcast request; obtaining equipment performance data corresponding to the equipment type according to the equipment type; and setting a start-up parameter according to the equipment performance data, and performing live broadcast push flow according to the start-up parameter. According to the scheme, the blocking of live broadcast plug flow can be reduced.

Description

Live broadcast push flow method and device

Technical Field

The application relates to the technical field of live broadcasting, in particular to a live broadcasting plug flow method. The application also relates to a live broadcast pushing device, a computing device and a computer readable storage medium.

Background

With the development of live broadcast technology, users of live broadcast streams are growing in bursts. In order to cope with the demands of a large number of users on live streams, the live streams can be obtained in a differentiated mode.

In the related art, the live stream is obtained in a differentiated manner according to different login states of the client. Specifically, if the login state of the client is logged in, acquiring a live stream by adopting a first direct-broadcasting definition; and if the login state of the client is not login, acquiring the live stream by adopting the second live definition. Wherein the first direct broadcast definition is greater than the second direct broadcast definition.

However, the login status of the client cannot reflect whether the client can support the definition of the obtained live stream. Thus, the manner described above is prone to live stream jamming caused by the inability of the client to support sharpness. Thus, there is a need to provide a more fluid solution for live push.

Disclosure of Invention

In view of the above, the embodiment of the application provides a live broadcast push method. The application also relates to a live broadcast push device, a computing device and a computer readable storage medium, so as to solve the problem of live broadcast push jamming in the prior art.

According to a first aspect of an embodiment of the present application, there is provided a live push method, including:

receiving a live broadcast request sent by a client, and determining the equipment type of the client according to the live broadcast request;

obtaining equipment performance data corresponding to the equipment type according to the equipment type;

and setting a start-up parameter according to the equipment performance data, and performing live broadcast push flow according to the start-up parameter.

According to a second aspect of an embodiment of the present application, there is provided a live push device, including:

the device type determining module is configured to receive a live broadcast request sent by a client and determine the device type of the client according to the live broadcast request;

The performance data determining module is configured to obtain equipment performance data corresponding to the equipment type according to the equipment type;

and the live broadcast pushing module is configured to set a starting parameter according to the equipment performance data and conduct live broadcast pushing according to the starting parameter.

According to a third aspect of embodiments of the present application, there is provided a computing device comprising a memory, a processor and computer instructions stored on the memory and executable on the processor, the processor implementing the steps of the live push method when executing the instructions.

According to a fourth aspect of embodiments of the present application, there is provided a computer readable storage medium storing computer instructions which, when executed by a processor, implement the steps of the live push method.

In the scheme provided by the embodiment of the application, a live broadcast request sent by a client is received, and the equipment type of the client is determined according to the live broadcast request; obtaining equipment performance data corresponding to the equipment type according to the equipment type; and setting a start-up parameter according to the equipment performance data, and performing live broadcast push flow according to the start-up parameter. If the device performance data does not accord with the preset starting conditions, the client is indicated to be incapable of supporting the preset starting parameters corresponding to the preset starting conditions, and if live broadcast pushing is performed according to the preset starting parameters, the live broadcast stream is blocked. Therefore, the starting parameters are set according to the equipment performance data, and the live broadcast pushing flow is carried out according to the starting parameters, so that the client can be ensured to support the starting parameters, the blocking of the live broadcast pushing flow is reduced, and the smoothness of the live broadcast pushing flow is improved.

Drawings

Fig. 1 is a flowchart of a live push method according to an embodiment of the present application;

fig. 2 is a diagram illustrating a structure of a live push system according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of a live broadcast plug-flow device according to an embodiment of the present application;

FIG. 4 is a block diagram of a computing device according to one embodiment of the application.

Detailed Description

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. The present application may be embodied in many other forms than those herein described, and those skilled in the art will readily appreciate that the present application may be similarly embodied without departing from the spirit or essential characteristics thereof, and therefore the present application is not limited to the specific embodiments disclosed below.

The terminology used in the one or more embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the application. As used in one or more embodiments of the application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present application refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that, although the terms first, second, etc. may be used in one or more embodiments of the application to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first may also be referred to as a second, and similarly, a second may also be referred to as a first, without departing from the scope of one or more embodiments of the application. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

First, terms related to one or more embodiments of the present application will be explained.

Live broadcast room: the anchor shows the live stream to the virtual network address of the audience, who enters the live room to watch the live stream.

Live stream: the audio and video data transmitted in live broadcast can be transmitted to the audience client through the network in the form of stable and continuous data stream.

Code rate: in the video data transmission process, the number of data bits transmitted in a unit time. The higher the code rate, the clearer the video, the lower the code rate, the coarser the video picture, and the more mosaics are present.

Frame rate): the frequency (rate) at which bitmap images in frames, referred to as units, appear continuously on the display is used to measure a measure of the number of display frames. The higher the frame rate, the smoother, or more realistic, the video or animation. The unit of frame rate is fps. Typically, 30fps is acceptable, 60fps can significantly enhance the interaction and realism, and significant fluency enhancement is generally not readily perceived beyond 75 fps.

Starting the broadcasting definition: the code rate when the live stream starts to play can represent the definition of the live stream. Different clients may have different start-up sharpness.

Video transcoding (Video Transcoding): the video code stream which is already compressed and coded is converted into another video code stream so as to adapt to different network bandwidths, different terminal processing capacities and different user demands. Video transcoding is a process of decoding and then encoding, so that the video streams before and after conversion may follow the same or different video coding standards.

Live broadcast blocking: the live stream watched by the user has the phenomena of unsmooth playing, black screen or static picture.

Content delivery network (CDN, content Delivery Network): an intelligent virtual network is built on the basis of the existing network. By means of the edge servers deployed in various places, the users can obtain the required content nearby through the load balancing, content distribution, scheduling and other functional modules of the center platform, network congestion is reduced, and response speed and hit rate to user access are improved.

Peer-to-Peer (P2P): also known as Peer-to-Peer computing (Peer-to-Peer), defined as: participants of the network share a portion of the hardware resources (processing power, storage power, network connectivity, printers, etc.) they own, which provide services and content through the network that can be accessed directly by other Peer nodes (peers) without going through intermediate entities.

In a specific application, there are often situations where different clients enter a live room to view live streams. Moreover, the device performance of the plurality of clients tends to be different, so that the support capability of different clients to the start-up parameters is likely to be different. For example, a certain client can support a start-up code rate or a start-up frame rate, and another client cannot support the same. Therefore, if the live stream is pushed to the plurality of clients based on the same start-up parameters, the problem that part of clients cannot support the start-up parameters of the live stream and live stream blocking occurs easily is caused.

In order to reduce the problem of live video clip, live video streams may be pushed based on start-up parameters that are appropriate for the client. In the present application, a live broadcast push method is provided, and the present application relates to a live broadcast push device, a computing device, and a computer readable storage medium, which are described in detail in the following embodiments one by one.

Fig. 1 shows a flowchart of a live broadcast push method according to an embodiment of the present application, which specifically includes the following steps:

s102, receiving a live broadcast request sent by a client, and determining the equipment type of the client according to the live broadcast request.

In a specific application, the live request typically carries device information for the client. Such as device identification, model. Moreover, the manner of determining the device type of the client may be various according to the live broadcast request. For example, the device information in the live broadcast request may be extracted, and the device type corresponding to the extracted device information is searched from the pre-established correspondence between the device information and the device type, so as to obtain the device type of the client. Or, illustratively, the extracted device information is input into a classification model trained in advance to obtain the device type of the client. The classification model is a model trained by using sample equipment information and equipment type labels of the sample equipment information.

The device types of the clients are obtained by dividing according to the device performance difference of the clients. Also, by way of example, the device type may specifically be in the form of a model tag that characterizes how old or new a client is. For example, the dimension labels of the old model, the normal tail model, the waist model, the head model, the top model and the like are sequentially arranged from low to high according to the degree of old and new. Alternatively, the device type may be in the form of a model identification, for example. For example, an identification OS 1M 1 representing the M1 model of the operating system OS 1; the identifier OS 2N 1 representing the model N1 of the operating system OS 2.

S104, obtaining equipment performance data corresponding to the equipment type according to the equipment type.

The device performance data may be varied in specific applications, and is described in detail below in alternative embodiments. In an alternative embodiment, the device performance data may include: and determining the performance index according to the equipment parameters of the client. Wherein the device parameters of the client may include at least one of hardware parameters, software parameters, and network parameters. For example, the hardware parameters may include screen resolution, CPU parameters, and the like; the software parameters may include operating system version information, information of video coding algorithms, and so on; the network parameters may include: network type, whether dual card dual standby, etc.

In another alternative embodiment, the device performance data may include: and determining the performance index according to the time parameter representing the new and old degree of the client.

In a specific application, the time parameter for representing the degree of freshness of the client may specifically include: the delivery time of the client, the use time of the client, etc. Moreover, the manner of determining the performance index may be varied according to the time parameter characterizing the degree of freshness of the client. For example, a time parameter that characterizes how old or new a client is may be determined as a performance indicator. The newer the client, the higher the performance of the client; and, the factory time is inversely proportional to the new and old degree of the client: the later the delivery time, the newer the client. The delivery time and the use time are proportional to the new and old degrees of the client: the larger the factory time and the usage time, the older the client. Alternatively, the above time parameter may be used to perform a weighting process on the device parameter of the client to obtain the performance index. The second exemplary embodiment will be described in detail in the following in the form of alternative embodiments for easy understanding and rational layout.

In this way, the device performance data in this embodiment may be dynamically adjusted over time, that is, with the update of the time parameter, so as to improve the matching degree between the start-up parameter set according to the device performance data and the device performance of the client. For example, over time, the device performance of a client that is longer in the factory time is lower, and correspondingly, the device performance data is lower.

Also, in an alternative embodiment, the performance index may include at least one of the following: hardware performance index, software performance index and network performance index.

In a specific application, the hardware performance index is an index that characterizes the hardware performance of the device. Similarly, the software performance index is an index for characterizing the software performance of the device, and the network performance index is an index for characterizing the network performance of the device. Thus, the embodiment improves the richness of the performance index through three dimensions of hardware, software and a network, so that the accuracy of representing the performance of the equipment is further improved through the performance index with multiple dimensions, namely the performance data of the equipment. The performance index may specifically be the parameter of each dimension, the analysis result of the parameter of each dimension, or the analysis result of the parameter of each dimension. The parameters of each dimension may include the hardware parameters, the software parameters, and the network parameters. For ease of understanding and rational layout, a specific manner of obtaining the analysis results of the parameters of each dimension will be described later in the form of alternative embodiments.

Also, the specific form of the device performance data, i.e., the performance indicators described above, may be varied. For example, the device performance data may be in the form of specific values, or performance types divided by device performance differences, or the like. And, depending on the device type, the specific manner of obtaining the device performance data corresponding to the device type may be various. For example, if the device performance data corresponding to different device types is obtained through the historical user log of the client, and a corresponding relationship between the device type and the device performance data is established according to the device performance data, the device performance data corresponding to the device type may be searched from the corresponding relationship. Alternatively, for example, the device type may be input into a performance determination model trained in advance, to obtain device performance data corresponding to the device type. The performance determination model is a model obtained by training a sample device type and a device performance data label corresponding to the sample device type. Or, for example, at least one of a hardware parameter, a software parameter and a network parameter of the client may be searched from a pre-established correspondence between a device type and a parameter, and the acquired parameter may be parsed to obtain device performance data. The first example and the last example are described in detail in the following in the form of alternative embodiments for easy understanding and rational layout.

Any manner of obtaining device performance data corresponding to a device type according to the device type may be used in the present application, which is not limited in this embodiment.

S106, setting a start-up parameter according to the equipment performance data, and carrying out live broadcast push flow according to the start-up parameter.

In particular applications, the manner in which the start-up parameters are set may be varied based on the device performance data. For example, the starting parameters corresponding to the device performance data may be searched from the pre-established correspondence between the device performance data and the starting parameters. Or, for example, if the device performance data does not meet the preset condition, the start-up parameter may be set according to the device performance data, and live broadcast push may be performed according to the start-up parameter. This is reasonable.

The preset starting conditions are conditions for determining whether the device performance of the client is suitable for the preset starting parameters. The preset starting parameters are parameters when the preset live stream starts to play. The preset start-up conditions may be various. For example, the preset start-up condition may be that the device performance data reaches a preset performance threshold. The performance threshold is equipment performance data matched with a preset starting parameter. Alternatively, the preset start-up condition may be, for example, obtaining a reference start-up parameter that matches the device performance data, where the reference start-up parameter is greater than or equal to the preset start-up parameter.

Therefore, in an alternative embodiment, the setting the start-up parameter according to the device performance data may specifically include the following steps:

searching a reference starting parameter corresponding to the equipment performance data from a pre-established corresponding relation between the equipment performance data and the starting parameter;

if the reference starting parameter is smaller than the preset starting parameter, determining that the equipment performance data does not accord with the preset starting condition;

and obtaining the starting parameters based on the reference starting parameters.

The start-up parameters are parameters when the live stream starts to play. And the reference start-up parameter is the start-up parameter matched with the performance data of the equipment. Therefore, if the reference start-up parameter is smaller than the preset start-up parameter, it indicates that the device performance of the client cannot support the preset start-up parameter, and the live broadcast push according to the preset start-up parameter may cause a clip. Therefore, it can be determined that the device performance data does not conform to the preset start-up condition.

In the scheme provided by the embodiment of the application, if the equipment performance data does not accord with the preset starting conditions, the client is indicated to be incapable of supporting the preset starting parameters corresponding to the preset starting conditions, and if live broadcast pushing is performed according to the preset starting parameters, the live broadcast stream is blocked. Therefore, the starting parameters are set according to the equipment performance data, and the live broadcast pushing flow is carried out according to the starting parameters, so that the client can be ensured to support the starting parameters, the blocking of the live broadcast pushing flow is reduced, and the smoothness of the live broadcast pushing flow is improved.

And, the start-up parameters may be various. Accordingly, the specific manner in which the start-up parameters are obtained based on the reference start-up parameters may be varied, and are described in detail below in alternative embodiments.

In an alternative embodiment, the start-up parameters may include: pushing the live stream to a transmission path of the client;

correspondingly, the obtaining the starting parameters based on the reference starting parameters specifically includes the following steps:

the reference start-up parameter is determined as the transmission path.

In a specific application, the device performance data of the application is used for representing the degree of freshness of the client. Therefore, if the performance data of the device does not meet the preset starting condition, for example, the mobile phone is not changed for 5 years, the network service devices such as the router of the user are likely to be old devices, the network environment is relatively complex and unstable, and the live broadcast push stream is easy to be blocked. Thus, the start-up parameters may comprise a transmission path for pushing the live stream to the client, such that the reference start-up parameters are in particular reference transmission paths. The reference transmission path is a transmission path matching with the device section performance data of the client. For example, the device performance characterized by the device performance data D1 and the device performance data D2 sequentially decrease. Then, the reference transmission path corresponding to the device performance data D1 may contain a P2P network and/or a content distribution network provided by the routing device of the client; the reference transmission path corresponding to the device performance data D2 may be a content distribution network dedicated to live push, and the transmission path may not include a P2P network and a content distribution network provided by a routing device of the client.

Wherein the network quality of the content distribution network dedicated for live push is generally higher than that provided by the P2P network and the routing devices of the clients. Therefore, the transmission path of the live broadcast stream with higher network quality can be set as the starting parameter by the scheme, so that the stability of the network is improved, and the blocking of the live broadcast push stream is reduced.

And, the live broadcast pushing flow is carried out according to the start-up parameters, which specifically comprises the following steps:

and transmitting the live stream corresponding to the live broadcast request to the client according to the transmission path of the live stream.

Illustratively, a transmission path of the P2P network is set for the top model, links shared by routing devices used by the client are set for the waist model and the head model, such as a content distribution network, and a transmission path of the live CDN is set for the old model and the normal tail model. Thus, the live-watching click rate of the old mobile device model is reduced by 10%.

In an alternative embodiment, the start-up parameters may include: video quality parameters representing picture quality of the live stream, and at least one of play setting parameters for setting play special effects of the live stream; the reference start-up parameters include: at least one of a reference video quality parameter and a reference play setting parameter;

determining a parameter less than or equal to the reference video quality parameter as a video quality parameter; and/or that the number of the groups of groups,

and determining the parameters which are smaller than or equal to the reference play setting parameters as play setting parameters.

In addition, when the start-up parameter includes a video quality parameter, the live push according to the start-up parameter may specifically include the following steps:

generating a live stream corresponding to the playing request according to the video quality parameter;

and pushing the live stream to the client.

In a specific application, the video quality parameter may include at least one of a code rate, a frame rate. The reference video quality parameter is illustratively a first code rate and/or a first frame rate. Then, video transcoding can be performed on the live stream with the first code rate and/or the first frame rate, and the live stream with the second code rate and/or the second frame rate is obtained and used as the live stream corresponding to the playing request. Wherein the second code rate is less than the first code rate and the second frame rate is less than the first frame rate. Or, determining the live stream with the first code rate and/or the first frame rate as the live stream corresponding to the playing request. This is reasonable. Thus, not only can live broadcast blocking be reduced and live broadcast fluency be improved, but also occupation of resources by the pushed live broadcast stream can be reduced.

In addition, when the start-up parameter includes a play setting parameter, the live push according to the start-up parameter may specifically include the following steps:

obtaining a setting instruction containing a play setting parameter;

and pushing the setting instruction and the live stream corresponding to the playing request to the client together, wherein the setting instruction is used for playing the live stream corresponding to the playing request by the client according to the playing setting parameters in the setting instruction.

The play setting parameter is used for setting a play special effect of the live stream in the client, and the play special effect can be various in particular. Illustratively, the playing setting parameters may include, in order from large to small: HDR10+, dolby effect, stereo effect, switch off HDR10+, switch off dolby effect, etc. The HDR 10-10 bitHDR10+ (10 bit) dolby vision-12 bit depth is represented by the bit depth required for each pixel in a computer, and the display is capable of displaying colors, and data of the represented colors is recorded by using a counting unit called "bit". The four-channel stereo is synthesized into two channels through a specific coding means during recording, namely 4 signals of an original left channel (L), an original right channel (R), an original center channel (C) and an original surround channel (S) are synthesized into LT and RT composite binaural signals after coding, and the coded binaural composite signals LT and RT are restored into four independent signals which are coded and are not dry mutually and are independent through a decoder during playback, and the independent signals are respectively input into a left sound box, a right sound box, an intermediate sound box and an surround sound box after amplification.

Illustratively, the reference play setting parameter is dolby sound effect. Then, any one of the dolby effect, the stereo effect, or the off dolby effect may be determined as the play setting parameter. Therefore, the client can autonomously adjust whether the screen shielding HDR10+ is needed or not, and whether the sound shielding dolby sound effect is needed or not, which is an enhancement parameter with high requirements on the model. Equivalent to adjusting the occupancy of enhancement parameters to client device capabilities. Therefore, the occupation of the enhancement parameters on the device performance of the client can be reduced under the condition that the device performance does not meet the preset starting conditions, the device performance is relatively improved, the device performance data of the client is enabled to meet the preset starting conditions as much as possible, and accordingly live broadcast blocking is reduced, and the live broadcast fluency is improved.

The specific selection of the play setting parameters may be performed according to the application requirements, and this embodiment is illustrated as an example, which is not limited.

In an optional implementation manner, the live broadcast push method provided by the embodiment of the application may further include the following steps:

acquiring a historical user log of a client, and acquiring hardware parameters of the client and time parameters representing the degree of freshness of the client based on the historical user log;

Acquiring equipment performance data of the client based on the hardware parameters and the time parameters;

according to the equipment performance data, establishing a corresponding relation between the equipment type and the equipment performance data;

correspondingly, the obtaining the device performance data corresponding to the device type according to the device type may specifically include the following steps:

and searching the equipment performance data corresponding to the determined equipment type from the corresponding relation between the equipment type and the equipment performance data.

In a specific application, the viewing behavior of the user may generate a user log, where the user log records model information of the client, such as identification of the client, factory model, and the like. By acquiring the history user log of the client, the effect that the client reports the model information to the server can be achieved, and the server is transmitted to the direct broadcasting cloud server through the data storage platform. Fitting user data by the direct broadcast cloud service end refers to that the direct broadcast cloud service end obtains different parameters from different data sources according to model information. For example, device performance metrics such as scores are obtained from data source a, factory years are obtained from data source b, and so on.

For example, the factory year, the CPU model, whether 265 decoding is supported, the screen resolution, whether the information is dimension information such as a dual-card mobile phone, etc. of the mobile phone model can be obtained from a public network, namely the internet. After obtaining the above parameters, a model library can be established: correspondence between device type and device performance data. The model capacity score is fitted according to a certain weight, and can be divided into dimension labels of a common tail model, a waist model, a head model, a top model and the like. 265 decoding is an efficient video coding scheme, specifically h.265-HEVC (High Efficiency Video Coding). Whether the mobile phone is a double-card mobile phone can be used for representing whether network switching exists, and the problem that network instability and push-stream blocking caused by network switching are likely to occur at a client side with the network switching.

On the basis, when the user watches live broadcast again and requests the direct broadcast cloud server to acquire the scheduled broadcast address through the server, the server can determine whether the client of the user cannot play the default start-up definition or not based on the pre-established equipment information base. The default starting definition is equivalent to the preset starting parameter, and may be 265 coding definition. If it is determined that whether the client of the user cannot play the default starting definition, that is, it is determined that the performance data of the device does not meet the preset starting condition, the starting parameter is reduced from 265 encoding definition to 264 encoding definition, mainly reducing possibility of starting a cartoon of the user, ensuring that a suitable user obtains the suitable definition to start playing, being an optimized option for platform experience, and if the user is not satisfied with starting definition, the starting parameter can be manually adjusted to be recovered to higher definition.

In an optional implementation manner, after searching the device performance data corresponding to the determined device type in the corresponding relationship between the slave device type and the device performance data, the live broadcast push method provided by the embodiment of the present application may further include the following steps:

And if the equipment performance data corresponding to the determined equipment type is not found, executing to acquire the historical user log of the client.

Wherein the device performance data corresponding to the determined device type is not found, indicating that the determined device type is not in a pre-established correspondence of the device type and the device performance data. For example, the pre-established correspondence between the device type and the device performance data is a model library, i.e. the determined device type is not in the model library. Thus, the determined device type is stored in the model base, waiting for the offline program to update the complete device performance data: i.e. the step of obtaining a historical user log of the client is performed. Thus, the next live request may perform the flow of the fig. 1 embodiment of the present application.

In a specific application, the timing of acquiring the historical user log of the client may be performed in real time or offline. In theory, there is no case where the determined device type is not in the model base for the large hot-machine model. For example, an IOS (operating system of a mobile terminal) client typically does not exceed one hundred models, and an android (operating system of a mobile terminal) type client typically has thousands of models, each of which can be incorporated into a model library. Typically, older models of android will have situations where the determined device type is not in the model base, but in very small amounts. Thus, the scheme of the application can hit 99% of cases.

In an alternative embodiment, the types of hardware parameters are multiple; the time parameter comprises the delivery time of the client;

correspondingly, the obtaining the device performance data of the client based on the hardware parameter and/or the time parameter may specifically include the following steps:

weighting the hardware parameters by using weights corresponding to the types of the hardware parameters to obtain basic equipment performance data of the client;

and according to a rule that the delivery duration is inversely proportional to the adaptation capability, adjusting the performance data of the basic equipment by utilizing the delivery duration to obtain the equipment performance data of the client.

In a specific application, the hardware parameter may be an average value of sampling results of a specified evaluation mechanism in the public network, and the obtained analysis result. For example, hardware parameters: processor performance data= (CPU analysis result x weight a+memory size x weight b+number of samples per month x weight c+whether or not preset value of 5G is supported) -month x weight D from now.

New models are always stronger and the new scores for all head models are progressively increasing. The month to date refers to the number of months to date from the year of shipment of the model. For example, the 18-year 1-month factory leaves the factory, and the month from the 21-year 11-month is 47 months. The factory time length, for example, the month since the date, is used for subtracting the month since the date from the basic device performance data and multiplying the month since the date by a preset weight. Thus, the longer the time, the more scores are subtracted, while the hardware parameters themselves are unchanged, and the ranking of the device performance data of the client will be progressively later. For dimension labels or device performance data of the same model, the dimension labels or device performance data should be continuously adjusted according to time change, for example, the device performance data of the model in 1 month is definitely different from the device performance data of the model in 12 months. Exemplary, model P1 device performance data is 2 parts per million, but model P13 device performance data is 8 parts per million. Therefore, more high equipment performance data gradually brushes 2 parts per million of equipment performance data to the tail part of the middle part, and 2 parts per million subtracts a month from now on to multiply the weight, so that the equipment performance data of the model P1 is lower and lower along with the increase of time, and the new model has certain advantages.

Therefore, the method and the device not only consider the hardware and software performances of the client, but also dynamically update the device performance data of the client from the time dimension, thereby realizing more accurate live broadcast plug flow.

In an alternative embodiment, the time parameter may further include: designating a time period;

correspondingly, according to the rule that the delivery duration is inversely proportional to the performance index, the basic performance index is adjusted by using the delivery duration to obtain the device performance data of the client on the start-up parameters of the live stream, which specifically comprises the following steps:

obtaining the user utilization rate of the client with the equipment type in the appointed time period;

and according to the rule that the delivery duration is inversely proportional to the adaptation capability and the rule that the user utilization rate is directly proportional to the adaptation capability, adjusting the basic performance index by utilizing the delivery duration and the user utilization rate to obtain the equipment performance data of the client.

The user usage rate of the client having the device type in the specified time period refers to the ratio of the number of users having the device type in the total number of users having the device type in the client in the specified time period. For example, the number of samples of each data of a client having a type in a specified period of time may be used as the user usage rate of a client having a device type in the specified period of time. The more the sampling times are, the client is a popular model, and the score is that the performance data of the basic equipment is added. Thus, as the client is updated, for example, the mobile phone is updated, the sampling frequency is gradually reduced, the addition component is gradually reduced, and the score is also reduced. The number of visible samples refers to the usage scale of the model. The higher the number of samples, the more people using the model.

Both the embodiment and the embodiment related to obtaining the device performance data by using the factory duration are equivalent to analyzing parameters of hardware dimensions to obtain the device performance data. The adjusted basic performance index can be regarded as a result of analyzing parameters of hardware dimension. The method of resolving the parameters of the software dimension and the network dimension is similar to the method of resolving the parameters of the hardware dimension, except that the specific parameters are adaptively the software parameters and the network parameters, and for the same parts, which are not described herein, reference may be made to the description of the embodiment and the embodiment for obtaining the device performance data by using the factory time.

The live broadcast push method provided by the application is further described by taking the application of the live broadcast push method in a live broadcast push system as an example with reference to fig. 2. Fig. 2 shows a structural example diagram of a live broadcast plug-flow system according to an embodiment of the present application, which specifically includes:

in a specific application, the viewing behavior of the user may generate a user log, where the user log records model information of the client, such as identification of the client, factory model, and the like. The client sends the history user log to the edge server, so that the effect of reporting the model information to the edge server can be achieved, and the edge server transmits the model information to the direct broadcasting cloud server through the data storage platform. The edge server is equivalent to the server above. The live content distribution network and the live cloud server belong to a live service end for providing live service for clients. And the direct broadcasting cloud service end reads the model information, namely the user data, from the data storage platform. And, fitting user data through the Internet, wherein the fitting refers to that the live cloud server acquires different equipment performance parameters from different data sources according to model information. For example, the factory year of the mobile phone model, the CPU model, whether 265 decoding is supported, the screen resolution, whether the mobile phone model is dimension information such as a dual-card mobile phone, etc. can be obtained from the public network. After the parameters are obtained, the live broadcast cloud server can obtain the device performance data of the client through the data computing platform, so that a device information base is established: correspondence between device type and device performance data. The device performance data may specifically be data reflecting the device performance. According to the difference of the performance data of the devices, that is, different clients, can be classified into dimension labels such as a common tail model, a waist model, a head model, a top model and the like.

On the basis, if the user watches live broadcast again, the client sends a live broadcast request to the live broadcast cloud server through the edge server, and the live broadcast cloud server can determine whether the client of the user cannot play the default starting definition or not based on the pre-established equipment information base. The default starting definition is equivalent to the preset starting parameter, and may be 265 coding definition. If it is determined that the client of the user cannot play the default starting definition, that is, it is determined that the device performance data does not meet the preset starting condition, the starting parameter is adjusted from the definition of 265 codes to the definition of 264 codes. Therefore, the possibility of starting the playing and blocking of the user can be reduced, the proper user is ensured to acquire proper definition to start playing, the experience of the user on the platform is optimized, and if the user is not satisfied with the starting definition, the user can manually adjust and restore to higher definition. Therefore, the live broadcast cloud server can carry out live broadcast plug flow to the client through the live broadcast content distribution network and the edge server according to the adjusted start-up parameters.

Therefore, the embodiment can judge the video consumption capability and efficiency of the user such as hardware decoding according to various hardware data dimensions of the user, and firstly pre-judge and select the definition that each user cannot get stuck in the current model, and provide the definition of live broadcast which is most suitable for the current playing condition of the user client. Therefore, users unfamiliar with the operation interface can be prevented from stopping watching due to frequent blocking and stopping at the live broadcasting room, the users can be prevented from performing trial operation of switching definition after blocking, the operation flow is reduced, the user experience is improved, and the problem of blocking watching is solved by actively replacing the users. And, provide live stream of slightly lower definition for the old model user, slightly lower definition is that low code rate can consume less bandwidth than high code rate live stream promptly, therefore, can practice thrift the cost of live platform.

Corresponding to the method embodiment, the application also provides a live broadcast pushing device embodiment, and fig. 3 shows a schematic structural diagram of a live broadcast pushing device according to an embodiment of the application. As shown in fig. 3, the apparatus includes:

the device type determining module 302 is configured to receive a live broadcast request sent by a client, and determine a device type of the client according to the live broadcast request;

a performance data determining module 304, configured to obtain, according to the device type, device performance data corresponding to the device type;

and the live broadcast pushing module 306 is configured to set a start-up parameter according to the device performance data, and perform live broadcast pushing according to the start-up parameter.

In an alternative embodiment, the device performance data includes: and determining the performance index according to the time parameter representing the new and old degree of the client.

In an alternative embodiment, the performance index includes at least one of the following: hardware performance index, software performance index and network performance index.

In an alternative embodiment, the apparatus further comprises: the corresponding relation establishing module is configured to:

acquiring a historical user log of the client, and acquiring hardware parameters of the client and time parameters representing the degree of freshness of the client based on the historical user log;

acquiring device performance data of the client based on the hardware parameters and the time parameters;

the performance data determination module 304 is further configured to:

In an alternative embodiment, the types of hardware parameters are multiple; the time parameter comprises the delivery duration of the client;

The correspondence establishing module is further configured to:

and adjusting the performance data of the basic equipment by utilizing the delivery duration according to the rule that the delivery duration is inversely proportional to the adaptive capacity, and obtaining the equipment performance data of the client.

In an alternative embodiment, the time parameter further includes: designating a time period;

the correspondence establishing module is further configured to:

obtaining the user utilization rate of the client with the equipment type in the time period;

and adjusting the basic performance index by utilizing the delivery duration and the user utilization rate according to a rule that the delivery duration is inversely proportional to the adaptation capability and a rule that the user utilization rate is directly proportional to the adaptation capability, so as to obtain the equipment performance data of the client.

In an alternative embodiment, the performance data determination module 304 is further configured to:

and after searching the equipment performance data corresponding to the determined equipment type in the corresponding relation between the equipment type and the equipment performance data, triggering the corresponding relation establishing module to execute the acquisition of the historical user log of the client if the equipment performance data corresponding to the determined equipment type is not searched.

In an alternative embodiment, the live push module 306 is further configured to:

if the reference starting parameters are smaller than preset starting parameters, determining that the equipment performance data do not accord with the preset starting conditions;

In an alternative embodiment, the start-up parameters include: pushing the live stream to a transmission path of the client;

the live push module 306 is further configured to:

and determining the reference starting parameters as the transmission paths.

In an alternative embodiment, the start-up parameters include: at least one of a video quality parameter representing the picture quality of the live stream and a play setting parameter setting the play special effect of the live stream; the reference start-up parameters include: at least one of a reference video quality parameter and a reference play setting parameter;

the live push module 306 is further configured to:

Determining a parameter less than or equal to the reference video quality parameter as the video quality parameter; and/or that the number of the groups of groups,

and determining parameters smaller than or equal to the reference play setting parameters as the play setting parameters.

The foregoing is a schematic solution of a live broadcast plug-flow device in this embodiment. It should be noted that, the technical solution of the live broadcast push device and the technical solution of the live broadcast push method belong to the same conception, and details of the technical solution of the live broadcast push device which are not described in detail can be referred to the description of the technical solution of the live broadcast push method.

Fig. 4 illustrates a block diagram of a computing device 400 provided in accordance with an embodiment of the present application. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. Processor 420 is coupled to memory 410 via bus 430 and database 450 is used to hold data.

Computing device 400 also includes access device 440, access device 440 enabling computing device 400 to communicate via one or more networks 460. Examples of such networks include public switched telephone networks (PSTN, public Switched Telephone Network), local area networks (LAN, local Area Network), wide area networks (WAN, wide Area Network), personal area networks (PAN, personal Area Network), or combinations of communication networks such as the internet. The access device 440 may include one or more of any type of network interface, wired or wireless, such as a network interface card (NIC, network Interface Controller), such as an IEEE802.11 wireless local area network (WLAN, wireless Local Area Networks) wireless interface, a worldwide interoperability for microwave access (Wi-MAX, worldwide Interoperability for Microwave Access) interface, an ethernet interface, a universal serial bus (USB, universal Serial Bus) interface, a cellular network interface, a bluetooth interface, a near field communication (NFC, near Field Communication) interface, and so forth.

In one embodiment of the application, the above-described components of computing device 400, as well as other components not shown in FIG. 4, may also be connected to each other, such as by a bus. It should be understood that the block diagram of the computing device illustrated in FIG. 4 is for exemplary purposes only and is not intended to limit the scope of the present application. Those skilled in the art may add or replace other components as desired.

Computing device 400 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), mobile phone (e.g., smart phone), wearable computing device (e.g., smart watch, smart glasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 400 may also be a mobile or stationary server.

Wherein, the processor 420 implements the steps of the live push method when executing the instructions.

The foregoing is a schematic illustration of a computing device of this embodiment. It should be noted that, the technical solution of the computing device and the technical solution of the live broadcast push method belong to the same concept, and details of the technical solution of the computing device, which are not described in detail, can be referred to the description of the technical solution of the live broadcast push method.

An embodiment of the application also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the live push method as described above.

The above is an exemplary version of a computer-readable storage medium of the present embodiment. It should be noted that, the technical solution of the storage medium and the technical solution of the live broadcast push method belong to the same concept, and details of the technical solution of the storage medium which are not described in detail can be referred to the description of the technical solution of the live broadcast push method.

The foregoing describes certain embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The computer instructions include computer program code that may be in source code form, object code form, executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth.

It should be noted that, for the sake of simplicity of description, the foregoing method embodiments are all expressed as a series of combinations of actions, but it should be understood by those skilled in the art that the present application is not limited by the order of actions described, as some steps may be performed in other order or simultaneously in accordance with the present application. Further, those skilled in the art will appreciate that the embodiments described in the specification are all preferred embodiments, and that the acts and modules referred to are not necessarily all required for the present application.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and for parts of one embodiment that are not described in detail, reference may be made to the related descriptions of other embodiments.

The preferred embodiments of the application disclosed above are intended only to assist in the explanation of the application. Alternative embodiments are not intended to be exhaustive or to limit the application to the precise form disclosed. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the application and the practical application, to thereby enable others skilled in the art to best understand and utilize the application. The application is limited only by the claims and the full scope and equivalents thereof.

Claims

1. A live push method, comprising:

receiving a live broadcast request sent by a client which enters a live broadcast room to watch a live broadcast stream, and determining the equipment type of the client according to the live broadcast request, wherein the equipment type is obtained by dividing according to the equipment performance difference of the client;

obtaining equipment performance data corresponding to the equipment type according to the equipment type, wherein the equipment performance data comprises performance indexes determined according to equipment parameters of a client and time parameters representing the degree of old and new of the client;

searching a reference starting parameter corresponding to the equipment performance data from a pre-established corresponding relation between the equipment performance data and the starting parameter; if the reference starting parameters are smaller than the preset starting parameters, determining that the equipment performance data do not accord with the preset starting conditions; based on the reference start-up parameters, obtaining the start-up parameters, and performing live broadcast push streaming according to the start-up parameters;

the starting parameters comprise transmission paths for pushing the live broadcast stream to the client, and the reference starting parameters are specifically reference transmission paths; the obtaining the starting parameters based on the reference starting parameters comprises the following steps:

And determining the reference transmission path as the transmission path, wherein the reference transmission path is a transmission path matched with the equipment performance data of the client.

2. The method as recited in claim 1, further comprising:

the obtaining, according to the device type, device performance data corresponding to the device type includes:

3. The method of claim 2, wherein the types of hardware parameters are a plurality of; the time parameter comprises the delivery duration of the client;

the obtaining the device performance data of the client based on the hardware parameter and the time parameter includes:

4. A method according to claim 3, wherein the time parameter further comprises: designating a time period;

the step of obtaining the device performance data of the client by adjusting the basic device performance data according to a rule that the factory duration is inversely proportional to the adaptive capacity and using the factory duration comprises the following steps:

obtaining the user utilization rate of the client with the equipment type in the specified time period;

and adjusting the basic equipment performance data by utilizing the factory duration and the user utilization rate according to a rule that the factory duration is inversely proportional to the adaptation capability and a rule that the user utilization rate is directly proportional to the adaptation capability, so as to obtain the equipment performance data of the client.

5. The method according to any one of claims 2 to 4, further comprising, after searching for device performance data corresponding to the determined device type from the correspondence between the device type and the device performance data:

And if the equipment performance data corresponding to the determined equipment type is not found, executing the acquisition of the historical user log of the client.

6. The method of claim 1, wherein the start-up parameters comprise: at least one of a video quality parameter representing the picture quality of the live stream and a play setting parameter setting the play special effect of the live stream; the reference start-up parameters include: at least one of a reference video quality parameter and a reference play setting parameter;

the obtaining the starting parameters based on the reference starting parameters comprises the following steps:

7. A live push device, comprising:

the device type determining module is configured to receive a live broadcast request sent by a client which enters a live broadcast room to watch live broadcast streams, and determine the device type of the client according to the live broadcast request, wherein the device type is obtained by dividing according to the device performance difference of the client;

The performance data determining module is configured to obtain equipment performance data corresponding to the equipment type according to the equipment type, wherein the equipment performance data comprises performance indexes determined according to equipment parameters of a client and time parameters representing the degree of freshness of the client, and the performance indexes comprise at least one of the following indexes: hardware performance index, software performance index and network performance index;

the live broadcast plug flow module is configured to search a reference start-up parameter corresponding to the equipment performance data from a pre-established corresponding relation between the equipment performance data and the start-up parameter; if the reference starting parameters are smaller than the preset starting parameters, determining that the equipment performance data do not accord with the preset starting conditions; based on the reference start-up parameters, obtaining the start-up parameters, and performing live broadcast push streaming according to the start-up parameters;

the starting parameters comprise transmission paths for pushing the live broadcast stream to the client, and the reference starting parameters are specifically reference transmission paths; the live broadcast plug flow module is further configured to:

8. A computing device comprising a memory, a processor, and computer instructions stored on the memory and executable on the processor, wherein the processor, when executing the instructions, implements the steps of the method of any of claims 1-6.

9. A computer readable storage medium storing computer instructions which, when executed by a processor, implement the steps of the method of any one of claims 1 to 6.