CN114189705A - Live broadcast card pause processing method and system - Google Patents
Live broadcast card pause processing method and system Download PDFInfo
- Publication number
- CN114189705A CN114189705A CN202111493818.8A CN202111493818A CN114189705A CN 114189705 A CN114189705 A CN 114189705A CN 202111493818 A CN202111493818 A CN 202111493818A CN 114189705 A CN114189705 A CN 114189705A
- Authority
- CN
- China
- Prior art keywords
- quality
- cdn
- stream
- morton
- reach
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/218—Source of audio or video content, e.g. local disk arrays
- H04N21/2187—Live feed
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
Abstract
The application discloses a live broadcast card pause processing method, which comprises the following steps: collecting pause information of a player at a user side in real time; carrying out data classification processing on the collected jam information according to flows, and counting the jam times of a single Content Delivery Network (CDN) corresponding to each flow; judging whether transmission abnormity occurs according to the blocking times; and when the transmission abnormity is judged, inquiring the inlet quality and the outlet quality of the edge computing node and the receiving quality of the CDN in real time, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the receiving quality of the CDN reach preset conditions or not. The application also discloses a live broadcast card pause processing system, an electronic device and a computer readable storage medium. Therefore, the user does not need to feed back the card pause, the abnormal transmission is automatically solved, and the plug flow experience is optimized.
Description
Technical Field
The present application relates to the field of live broadcast technologies, and in particular, to a live broadcast morton processing method, system, electronic device, and computer-readable storage medium.
Background
In the existing live broadcast system, generally, a live broadcast stream is pushed to a live broadcast edge computing node (a service node for receiving the stream), and the edge computing node pushes the stream to another home CDN (Content Delivery Network). When the user accesses the CDN but the CDN does not have the flow, the flow is pulled back onto the edge computing node. Whether it is a forward or a backward source, the flow quality may be affected by network instability or other factors. When the stream quality is poor, the user's viewing is affected, resulting in a stuttered view by the user.
When the current user watches the card pause, the user generally feeds back the card pause to the platform, and the platform checks whether the user watches the card pause due to the abnormal condition that the CDN returns to the source or is forwarded to the CDN. If the source returning and source returning problems do exist, the link is actively disconnected and reestablished, and different network links may pass through after reconnection, so that the source returning or source returning problems are relieved. However, the scheme which simply depends on user feedback is long in the link of investigation and not timely in processing, and affects the viewing of a large number of users.
Disclosure of Invention
The present application mainly aims to provide a live broadcast stuck processing method, system, electronic device, and computer-readable storage medium, and aims to solve the problem of how to effectively adjust the CDN back-source or forward-push quality based on stuck.
In order to achieve the above object, an embodiment of the present application provides a live broadcast morton processing method, where the method includes:
collecting pause information of a player at a user side in real time;
carrying out data classification processing on the collected jam information according to flows, and counting the jam times of a single Content Delivery Network (CDN) corresponding to each flow;
judging whether transmission abnormity occurs according to the blocking times;
and when the transmission abnormity is judged, inquiring the inlet quality and the outlet quality of the edge computing node and the receiving quality of the CDN in real time, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the receiving quality of the CDN reach preset conditions or not.
Optionally, the hiton information is automatically reported by the player, and includes a name of a flow in which the hiton occurs and a name of the CDN.
Optionally, the data classifying the collected morton information according to flow includes:
classifying the pause information according to different flows to obtain pause information corresponding to each flow;
and classifying the jam information corresponding to each flow according to different CDNs to obtain the jam information corresponding to each CDN of each flow.
Optionally, the determining whether the transmission abnormality occurs according to the number of times of the stuck state includes:
obtaining a number of viewers of the stream;
calculating the number of times of blocking/watching of a single CDN;
and when the calculated ratio is larger than a first threshold value, judging that the stream has abnormal transmission.
Optionally, the querying, in real time, the ingress and egress quality of the edge computing node and the receiving quality of the CDN, and locating the cause of the abnormality according to whether the ingress quality, the egress quality, and the receiving quality of the CDN reach a preset condition includes:
inquiring the access quality and the output quality of the edge computing node and the CDN receiving quality in real time;
judging whether the feed quality does not reach a first preset condition or not;
if not, further judging whether the inlet quality does not reach a first preset condition or not;
if not, judging whether the CDN received quality does not reach a third preset condition;
if the receiving quality of the CDN does not reach a third preset condition, disconnecting the link between the edge computing node and the CDN, and reselecting a new CDN to forward.
Optionally, the evaluation criteria of the quality of the incoming signal, the quality of the outgoing signal, and the CDN reception quality are FPS jitter, and the larger the value of the FPS jitter is, the lower the corresponding quality is.
Optionally, the FPS jitter is | average FPS |/average FPS within a preset period of the FPS-preset period of the current time point corresponding to the stream.
Optionally, the determining whether the feed quality does not reach a first preset condition includes:
and when the FPS jitter corresponding to the stream received by the edge computing node is calculated to be larger than a second threshold value, judging that the feed quality does not reach a first preset condition.
Optionally, the determining whether the quality does not reach a second preset condition includes:
calculating the outgoing mass and comparing the outgoing mass with the incoming mass;
if the outlet quality is the same as the inlet quality, judging that the outlet quality does not reach a second preset condition;
and if the output quality is lower than the input quality, judging that the output quality does not reach a second preset condition.
Optionally, the determining whether the CDN reception quality does not reach a third preset condition includes:
calculating the receiving quality of the CDN and comparing the receiving quality with the output quality;
if the CDN receiving quality is the same as the output quality, judging that the CDN receiving quality does not reach a third preset condition;
if the CDN receiving quality is lower than the output quality, judging that the CDN receiving quality does not reach a third preset condition.
In addition, to achieve the above object, an embodiment of the present application further provides a live broadcast morton processing system, where the system includes:
the collection module is used for collecting pause information of the user player in real time;
the statistical module is used for carrying out data classification processing on the collected jam information according to flows and counting the jam times of a single Content Delivery Network (CDN) corresponding to each flow;
the judging module is used for judging whether transmission abnormity occurs according to the blocking times;
and the comparison module is used for inquiring the inlet quality and the outlet quality of the edge computing node and the receiving quality of the CDN in real time when the transmission abnormity is judged to occur, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the receiving quality of the CDN reach the preset condition.
In order to achieve the above object, an embodiment of the present application further provides an electronic device, including: the device comprises a memory, a processor and a live broadcast card pause processing program which is stored on the memory and can run on the processor, wherein the live broadcast card pause processing program realizes the live broadcast card pause processing method when being executed by the processor.
In order to achieve the above object, an embodiment of the present application further provides a computer-readable storage medium, where a live broadcast pause processing program is stored on the computer-readable storage medium, and when executed by a processor, the live broadcast pause processing program implements the live broadcast pause processing method as described above.
The live broadcast pause processing method, the live broadcast pause processing system, the electronic device and the computer readable storage medium provided by the embodiment of the application can automatically report pause information by a player at a user side, and the central server takes the pause of the player as a starting point, integrates state information of a stream pushing end and a CDN receiving end, judges whether the pause is caused by a network link in real time, does not need the user to feed back the pause, automatically solves transmission abnormity, and optimizes stream pushing experience.
Drawings
FIG. 1 is a diagram of an application environment architecture in which various embodiments of the present application may be implemented;
fig. 2 is a flowchart of a live broadcast morton processing method according to a first embodiment of the present application;
FIG. 3 is a detailed flowchart of step S204 in FIG. 2;
fig. 4 is a schematic diagram of a live broadcast flow and various qualities in the first embodiment;
FIG. 5 is a detailed flowchart of step S206 in FIG. 2;
FIG. 6 is a flow diagram of a particular embodiment of the live morton processing method;
fig. 7 is a schematic hardware architecture diagram of an electronic device according to a second embodiment of the present application;
fig. 8 is a block diagram of a live morton processing system according to a third embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that the descriptions relating to "first", "second", etc. in the embodiments of the present application are only for descriptive purposes and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In addition, technical solutions between various embodiments may be combined with each other, but must be realized by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, such a combination should not be considered to exist, and is not within the protection scope of the present application.
Referring to fig. 1, fig. 1 is a diagram illustrating an application environment architecture for implementing various embodiments of the present application. The present application can be applied to application environments including, but not limited to, central server 1, anchor 2, edge computing nodes 4, CDN6, and user 8. There may be a plurality of the anchor terminals 2, the edge computing nodes 4, the CDN6, and the user terminals 8.
Live audio and video data can be transmitted as a stable and continuous stream over a network to viewers for viewing. The anchor terminal 2 is generally a client terminal where the anchor is located, and is used for pushing a stream to an edge computing node 4. The edge computing node 4 is configured to forward the push stream to each CDN6 after receiving the push stream. The user end 8 is generally a client end where a live audience is located, and is used for performing pull stream viewing to a CDN 6. The CDN6 is configured to directly return to the user side 8 when the local has the stream required by the user side 8, and return to the edge computing node 4 to pull the stream when the local does not have the stream, and then return to the user side 8.
In the existing live broadcast architecture system, after the anchor 2 pushes the stream to the edge computing node 4, the edge computing node 4 pushes the stream to one or more CDNs 6 (assuming that only the stream is pushed to CDN a, but not pushed to CDN B) according to the relevant policy. If the user end 8 is distributed to the CDN a by the scheduling system for pull viewing, the CDN a directly returns the previously received stream to the user end 8. If the user end 8 is allocated to the CDN B, the CDN B needs to return to the source edge computing node 4 first, obtain the stream from the edge computing node 4, and then return the stream to the user end 8. However, both the forward and backward sources in this approach suffer from network instability, which can cause the user to watch a card when the network is jittery.
In each embodiment of the present application, the central server 1 is configured to collect the pause information of the player of the user end 8 in real time, perform data classification processing according to the stream, and count the number of times of pause of a single stream flowing down the CDN 6. And then, calculating the number of times of blocking/watching according to each CDN6, judging that abnormality occurs when the ratio is greater than a threshold value, inquiring the in-out quality of the edge calculation node 4 and the receiving quality of the CDN6 in real time, comparing, and performing corresponding processing according to a comparison result. Therefore, the player is started from the jam, the state information of the push stream end and the CDN receiving end is integrated, whether the jam is caused by the network link is judged in real time, and the abnormity is automatically solved, so that the user feedback is reduced, and the push stream experience is optimized.
The server may be a rack server, a blade server, a tower server or a cabinet server, or may be an independent server or a server cluster formed by a plurality of servers. Additionally, the server may be a cloud server.
Example one
Fig. 2 is a flowchart of a live broadcast morton processing method according to a first embodiment of the present application. It is to be understood that the flow charts in the embodiments of the present method are not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired. The method will be described below with the center server 1 as an execution subject.
The method comprises the following steps:
s200, collecting pause information of the player at the user end in real time.
When a user at a user side watches videos, a player of a live broadcast platform needs to be used. The player can judge whether the playing is jammed or not according to the network speed of the pull stream, the buffer of the player and other data. This morton is the resulting morton viewed by the user.
In this embodiment, the player automatically reports each time of the pause information to the central server, and the specific reported information is as follows:
(1) stream name: the stream viewed by the user, i.e. what stream name the anchor pushes the stream, and what stream name the user views.
(2) CDN: currently, the CDN vendor name that provides the service, such as CDN a.
The players of the user sides automatically report the jam flow and the CDN name (jam information) to the central server, and the central server collects the jam information reported by the players of the user sides in real time.
S202, performing data classification processing on the collected jam information according to flows, and counting the jam times of a single CDN corresponding to each flow.
And the central server receives the pause information reported by the player of each user side, summarizes and classifies the pause information to obtain pause times classified according to a single CDN under each flow name.
Specifically, the classification includes:
(1) and classifying the pause information according to different flows to obtain pause information corresponding to each flow.
(2) And classifying the jam information corresponding to each flow according to different CDNs to obtain the jam information corresponding to each CDN of each flow.
Therefore, the central server can count the number of times of blocking of a single CDN corresponding to each flow according to the blocking information of each CDN corresponding to each flow obtained by classification.
And S204, judging whether the transmission is abnormal or not according to the blocking times.
Specifically, further refer to fig. 3, which is a schematic view of the detailed flow of step S204. It is to be understood that the flow chart is not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired. In this embodiment, the step S204 specifically includes:
s2040, obtaining the number of watching people of the stream.
After the number of times of blocking of each single CDN is counted, the central server can also obtain the number of viewers of the stream through other ways. For example, when a user watches live video, the user side can report heartbeat regularly, and the central server can obtain the number of people watching the live video by counting the number of heartbeats in a single live room.
S2042, calculating the number of times of blocking/watching of the single CDN.
S2044, when the calculated ratio is larger than a preset threshold value, judging that the stream is abnormal in transmission.
Classifying according to the CDN, comparing the real-time number of times of the CDN is blocked with the number of watching persons corresponding to the CDN under the stream, and when the number of times of the CDN/the number of watching persons is larger than a preset threshold (a first threshold can be a preset fixed value), indicating that the watching of users in a large range is influenced, judging that the stream is transmitted abnormally in the CDN, otherwise, judging that the stream is in a normal phenomenon (the problem of part of users leads to the watching of the CDN, and the stream always exists).
S206, when the transmission abnormity is judged, inquiring the inlet and outlet quality of the edge computing node and the CDN receiving quality in real time, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the CDN receiving quality reach the preset condition.
When it is determined that the stream is abnormal in transmission in the CDN, this embodiment needs to compare the ingress and egress quality of the edge computing node with the CDN reception quality to find out the cause of the abnormality and perform corresponding processing.
Fig. 4 is a schematic diagram of the live broadcast process and the above-mentioned qualities. In a live broadcast scene, a main broadcast end pushes a stream to an edge computing node, and the edge computing node performs forwarding push to each CDN (assuming that only forwarding push is performed to CDN A, and not to CDN B) after receiving the stream. The user terminal performs pull stream watching to a CDN. And if the CDN has the stream required by the user side, directly returning the stream to the user side, and if the stream does not exist, returning the stream to the edge computing node for stream pulling, and then returning the stream to the user side.
The quality is the quality of the push flow received by the edge computing node. After receiving the pushed stream, the edge computing node needs to forward the pushed stream to the CDN, and the quality of the forwarded stream is the output quality of the edge computing node. When the CDN does not have the stream, the quality of the back-source to the edge computing node is the back-source quality, and also belongs to the outgoing quality of the edge computing node. The quality of the stream received by the CDN (forward or backward), that is, the CDN reception quality (hereinafter, the reception quality during forward is mainly used as an example, and the reception quality during backward is similar). The CDN receiving quality and the output quality are easily influenced by network fluctuation. Sometimes, abnormality occurs in the connected CDN nodes, which also results in poor reception quality of the CDN.
The central server may obtain the data of the incoming quality and the outgoing quality from the edge computing node, and the CDN reception quality requires the CDN to provide an interface for querying the streaming quality. In this embodiment, the central server obtains an FPS (Frames Per Second) value at every moment from the edge computing node or an interface provided by the CDN, and the quality evaluation criteria mainly include: the FPS dither. The FPS jitter is that when the FPS of a stream changes by a certain amplitude in a short time, the stream jitter is generated, and the user can watch the stream in a pause state. The larger the value of the FPS jitter, the lower the quality of the corresponding stream.
The reasons for using FPS as a judgment factor are: in live broadcasting, a anchor sends data to a cloud server (edge computing node) at a constant FPS transmission rate. If all the data of the cloud server are normal, the received FPS value is always constant. If the cloud server is abnormal in data or too high in load, the cloud server cannot process more frames, only part of the frames transmitted by the user can be received, and other frames can be stored in the user side until the load of the cloud server is recovered to be normal. The cloud server which recovers to normal may receive the frame number of the transmission which is not received before the instant reception, which results in a large frame rate fluctuation range of the front and back transmission.
FPS jitter is calculated as follows: with a period of time as a period, a total FPS value of the stream received within the period is calculated, and an average FPS is calculated as the total FPS value/time. If the FPS-average FPS/average FPS for the time point > 30% (a second threshold, which may be other reasonable values), then the flow is stuck at the time point, i.e., the flow quality is poor.
Specifically, further refer to fig. 5, which is a schematic view of the detailed flow of step S206. It is to be understood that the flow chart is not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired. In this embodiment, the step S206 specifically includes:
s2060, inquiring the in-out quality and CDN receiving quality of the edge computing node in real time.
When the stream is abnormal in transmission in the CDN, the information of the edge computing node corresponding to the stream is obtained, and the in-out quality and the receiving quality of the CDN of the edge computing node are inquired in real time.
In this embodiment, the above-mentioned qualities are calculated as the FPS jitter of the corresponding position at the time point. That is, with a period of time as a period, the total FPS value of the stream received within the period is calculated, and the average FPS is calculated as the total FPS value/time. If the FPS-average FPS/average FPS at that point in time > 30% (or other predetermined value), then the flow is stuck at that point in time, i.e., the flow is of poor quality.
S2062, judging whether the feed quality does not reach a first preset condition. If so, the process ends, otherwise, step S2064 is executed.
In this embodiment, the advance quality is judged first. That is to say, the FPS jitter of the edge computing node receiving the push stream is calculated in the above manner, that is, the FPS-average FPS |/average FPS of the time point is calculated, whether the calculation result is greater than the second threshold is determined, and if yes, it indicates that the advance quality of the edge computing node does not reach the first preset condition.
If the incoming quality is poor (the first preset condition is not reached), it indicates that the problem of the anchor push stream is solved, and the user watching the pause is a normal phenomenon, which is not considered in the embodiment.
S2064, judging whether the quality does not reach a second preset condition. If so, the process ends, otherwise, step S2066 is executed.
Specifically, the forwarding quality of the edge computing node forwarding CDN, that is, the outgoing quality, is calculated. In this embodiment, the quality is evaluated by calculating the FPS jitter of the stream sent by the edge computing node, i.e., calculating the FPS-average FPS |/average FPS at this point in time. And comparing the calculated result with the incoming quality, if the calculated result is the same as the incoming quality (corresponding FPS jitter), indicating that the calculated result is not the outgoing quality difference, namely the outgoing quality does not reach a second preset condition, and continuing to execute the next step. Otherwise (in general, the output quality is lower than the input quality, that is, the FPS jitter corresponding to the output quality is greater than the FPS jitter corresponding to the input quality), it indicates that the output quality is poor, that is, the output quality does not reach the second preset condition. This situation indicates that the quality of the forwarding results in a user watching the video card, and other business processes such as converting the stream protocol or actively disconnecting the link and re-forwarding are performed at this time, which is not considered in the embodiment.
S2066, determining whether the CDN reception quality does not meet a third preset condition. If so, go to step S2068, otherwise, the process ends.
And when the output quality is the same as the input quality, further comparing the CDN reception quality with the output quality. The CDN receiving quality is calculated in the following mode: the FPS jitter of the stream received by the CDN is calculated, i.e., the FPS-average FPS | at that point in time/average FPS is calculated.
(1) If the CDN reception quality is the same as the output quality, it indicates that it is not a forwarding exception (it is not the CDN reception quality is poor, that is, it is not the CDN reception quality that does not reach the third preset condition), and it may be other links, for example, a problem occurs in a link of the CDN itself, which is not considered in this embodiment.
(2) If the CDN reception quality is lower than the output quality (that is, the FPS jitter corresponding to the CDN reception quality is greater than the FPS jitter corresponding to the output quality), it indicates that the user viewing has been affected due to the fact that the forward-push quality is too poor (that is, the CDN reception quality is poor, that is, the CDN reception quality does not reach the third preset condition). At this time, the link (forwarded from the edge compute node to the CDN) is actively disconnected and then re-pushed.
S2068, disconnecting the link between the edge computing node and the CDN, and reselecting a new CDN to forward.
After re-forwarding, the link is changed, and the problem of the previous link between the point and the point can be solved.
It should be noted that, in this embodiment, the outgoing quality and the CDN receiving quality are not directly compared, because the CDN receiving quality sometimes has a poor condition, but this condition does not necessarily result in deadlock, and if the quality is poor but viewing is not affected, processing is not required, so that a problem of which link the streaming transmission occurs needs to be eliminated layer by layer.
The live broadcast pause processing method provided by this embodiment can be used for automatically reporting pause information by a user-side player, and the central server starts from the player pause, integrates state information of the stream pushing end and the CDN receiving end, and judges whether the stream is pause due to a network link in real time, without requiring a user to feed back the stream, so as to automatically solve transmission abnormalities, and optimize stream pushing experience.
In order to explain the above steps of the method more thoroughly, specific embodiments are described as examples below. Those skilled in the art should appreciate that the following detailed description is not intended to limit the inventive concepts of the present disclosure and that appropriate content divergence and extensions can be readily devised by those skilled in the art based on the following detailed description of the embodiments.
Fig. 6 is a schematic flow chart of the specific embodiment. The method comprises the following steps:
and S300, counting the number of times of blockage.
That is, the hiton information is collected in real time from the players of the respective clients, and then the data is classified according to the flows, so as to count the number of hiton times of the single CDN corresponding to each flow.
S302, judging whether the number of times of mortgage/number of people watching is larger than a threshold (the first threshold). If not, the flow ends.
Classifying according to the CDN, comparing the real-time number of times of blockage of the CDN with the number of watching persons corresponding to the CDN flowing down, and judging that the stream is abnormal in transmission in the CDN when the number of times of blockage/the number of watching persons is larger than a threshold (a first threshold). Assume here that the flow is live _123 and the CDN is a.
And S304, judging whether the quality is poor (not reaching a first preset condition).
The incoming and outgoing quality of the edge computing node (corresponding to the stream live _ 123) and the receiving quality of the cdn (cdn a) are queried in real time and compared. Firstly, calculating the advance quality of the edge calculation node, and judging whether the advance quality is poor (not reaching a first preset condition). If yes, the problem of the push stream of the anchor end is described, the phenomenon that the user watches the card pause is normal, and the process is ended. Otherwise, the next step is continued.
And S306, judging whether the quality difference exists or not (the second preset condition is not reached).
And calculating the output quality, comparing the output quality with the input quality, if the output quality is the same as the input quality, indicating that the output quality is not the difference (not the output quality does not reach a second preset condition), and continuing to execute the next step. Otherwise, the output quality is the output quality difference (the output quality does not reach the second preset condition), that is, the user watches the card pause due to the forwarding and pushing quality, and other business processing is performed at this time, and the process is ended.
And S308, judging whether the CDN receiving quality is poor (a third preset condition is not reached).
And calculating the CDN receiving quality and comparing the CDN receiving quality with the quality. If the CDN reception quality is the same as the output quality, it indicates that the process is ended if the CDN reception quality is not poor (if the CDN reception quality does not reach the second preset condition). And if the CDN receiving quality is lower than the output quality (the CDN receiving quality does not reach a second preset condition), continuing the next step.
S310, disconnecting the link and reselecting CDN forwarding.
At this time, the link (forwarded from the edge computing node to the CDN a) is actively disconnected, and a new CDN is reselected for forwarding.
Example two
Fig. 7 is a schematic diagram of a hardware architecture of an electronic device 20 according to a second embodiment of the present application. In the present embodiment, the electronic device 20 may include, but is not limited to, a memory 21, a processor 22, and a network interface 23, which are communicatively connected to each other through a system bus. It is noted that fig. 7 only shows the electronic device 20 with components 21-23, but it is to be understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead. In this embodiment, the electronic device 20 may be the center server 1.
The memory 21 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the storage 21 may be an internal storage unit of the electronic device 20, such as a hard disk or a memory of the electronic device 20. In other embodiments, the memory 21 may also be an external storage device of the electronic apparatus 20, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the electronic apparatus 20. Of course, the memory 21 may also include both an internal storage unit and an external storage device of the electronic apparatus 20. In this embodiment, the memory 21 is generally used for storing an operating system and various application software installed in the electronic device 20, such as program codes of the live morton processing system 60. Further, the memory 21 may also be used to temporarily store various types of data that have been output or are to be output.
The processor 22 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 22 is generally used to control the overall operation of the electronic device 20. In this embodiment, the processor 22 is configured to run the program code stored in the memory 21 or process data, for example, run the live morton processing system 60.
The network interface 23 may include a wireless network interface or a wired network interface, and the network interface 23 is generally used for establishing a communication connection between the electronic apparatus 20 and other electronic devices.
EXAMPLE III
Fig. 8 is a block diagram of a live morton processing system 60 according to a third embodiment of the present invention. The live morton processing system 60 may be partitioned into one or more program modules, which are stored in a storage medium and executed by one or more processors to implement embodiments of the present application. The program modules referred to in the embodiments of the present application refer to a series of computer program instruction segments capable of performing specific functions, and the following description will specifically describe the functions of each program module in the embodiments.
In this embodiment, the live morton processing system 60 includes:
the collecting module 600 is configured to collect the pause information of the user-side player in real time.
When a user at a user side watches videos, a player of a live broadcast platform needs to be used. The player can judge whether the playing is jammed or not according to the network speed of the pull stream, the buffer of the player and other data. This morton is the resulting morton viewed by the user.
In this embodiment, the player automatically reports each time of the pause information to the central server, and the specific reported information is as follows:
(1) stream name: the stream viewed by the user, i.e. what stream name the anchor pushes the stream, and what stream name the user views.
(2) CDN: currently, the CDN vendor name that provides the service, such as CDN a.
The player of the user end automatically reports the flow and the CDN name (hiton information) that each time the user ends appear to the central server, and the collection module 600 collects the hiton information reported by the player of each user end in real time.
A counting module 602, configured to perform data classification processing on the collected hiton information according to flows, and count the number of hiton times of a single CDN corresponding to each flow.
After the collection module 600 receives the pause information reported by the player of each user, the statistics module 602 summarizes and classifies the pause information to obtain the pause times for classifying according to a single CDN under each flow name.
Specifically, the classification includes:
(1) and classifying the pause information according to different flows to obtain pause information corresponding to each flow.
(2) And classifying the jam information corresponding to each flow according to different CDNs to obtain the jam information corresponding to each CDN of each flow.
Therefore, the central server can count the number of times of blocking of a single CDN corresponding to each flow according to the blocking information of each CDN corresponding to each flow obtained by classification.
The determining module 604 is configured to determine whether a transmission abnormality occurs according to the number of times of blocking.
After counting the number of times of blocking of each single CDN for each stream, the determining module 604 obtains the number of viewers of the stream through other ways, and then calculates the number of times of blocking/number of viewers of each single CDN. When the number of times of pause/number of watching people is greater than a preset threshold (a first threshold), it is indicated that watching by users in a large range is influenced, and it is determined that the stream is abnormally transmitted in the CDN, otherwise, the stream is a normal phenomenon (some users have their own problems causing watching pause, which is always present).
A comparison module 606, configured to query, in real time, the ingress and egress quality of the edge computing node, the quality of the back source from the CDN to the edge computing node, and the CDN reception quality when it is determined that the transmission is abnormal, and locate an abnormal cause according to whether the ingress quality, the egress quality, and the CDN reception quality meet preset conditions.
When it is determined that the stream is abnormal in transmission in the CDN, this embodiment needs to compare the ingress and egress quality of the edge computing node, the quality of the source returned from the CDN to the edge computing node, and the CDN reception quality to find out the cause of the abnormality, and perform corresponding processing.
The quality is the quality of the push flow received by the edge computing node. After receiving the pushed stream, the edge computing node needs to forward the pushed stream to the CDN, and the quality of the forwarded stream is the outgoing quality. And when the CDN does not have the stream, the quality from the source to the edge computing node is the source returning quality. And the quality of the stream received by the CDN is the CDN reception quality. The CDN receiving quality and the output quality are easily influenced by network fluctuation. Sometimes, abnormality occurs in the connected CDN nodes, which also results in poor reception quality of the CDN.
The comparison module 606 may obtain data of the incoming quality, the outgoing quality, and the back-to-source quality from an edge computing node, where the CDN reception quality requires a CDN to provide an interface to query the push flow quality. In this embodiment, the comparison module 606 obtains an FPS value at every moment from the edge computing node or an interface provided by the CDN, where the quality evaluation criteria mainly include: the FPS dither. The larger the value of the FPS jitter, the lower the quality of the corresponding stream.
FPS jitter is calculated as follows: with a period of time as a period, a total FPS value of the stream received within the period is calculated, and an average FPS is calculated as the total FPS value/time. If the FPS-average FPS/average FPS for the time point > 30% (a second threshold, which may be other reasonable values), then the flow is stuck at the time point, i.e., the flow quality is poor.
The comparison process of the comparison module 606 specifically includes:
(1) and inquiring the inlet and outlet quality of the edge computing node, the source returning quality from the CDN to the edge computing node and the CDN receiving quality in real time.
When the stream is abnormal in transmission in the CDN, acquiring edge computing node information corresponding to the stream, and inquiring the inlet and outlet quality of the edge computing node, the source returning quality from the CDN to the edge computing node, and the CDN receiving quality in real time.
In this embodiment, the above-mentioned qualities are calculated as the FPS jitter of the corresponding position at the time point. That is, with a period of time as a period, the total FPS value of the stream received within the period is calculated, and the average FPS is calculated as the total FPS value/time. If the FPS-average FPS/average FPS at that point in time > 30% (or other predetermined value), then the flow is stuck at that point in time, i.e., the flow is of poor quality.
(2) And judging whether the feed quality does not reach a first preset condition.
In this embodiment, the advance quality is judged first. That is to say, the FPS jitter of the edge computing node receiving the push stream is calculated in the above manner, that is, the FPS-average FPS |/average FPS of the time point is calculated, whether the calculation result is greater than the second threshold is determined, and if yes, it indicates that the advance quality of the edge computing node does not reach the first preset condition.
If the incoming quality is poor (the first preset condition is not reached), it indicates that the problem of the anchor push stream is solved, and the user watching the pause is a normal phenomenon, which is not considered in the embodiment.
(3) And judging whether the quality does not reach a second preset condition.
Specifically, the forwarding quality of the edge computing node forwarding CDN, that is, the outgoing quality, is calculated. In this embodiment, the quality is evaluated by calculating the FPS jitter of the stream sent by the edge computing node, i.e., calculating the FPS-average FPS |/average FPS at this point in time. The calculated result is compared with the input quality, and if the calculated result is the same as the input quality (corresponding FPS jitter), the result indicates that the output quality is not the difference, namely the output quality does not reach a second preset condition. Otherwise (in general, the output quality is lower than the input quality, that is, the FPS jitter corresponding to the output quality is greater than the FPS jitter corresponding to the input quality), it indicates that the output quality is poor, that is, the output quality does not reach the second preset condition. This situation indicates that the quality of the forwarding results in a user watching the video card, and other business processes such as converting the stream protocol or actively disconnecting the link and re-forwarding are performed at this time, which is not considered in the embodiment.
(4) And judging whether the CDN receiving quality does not reach a third preset condition.
And when the output quality is the same as the input quality, further comparing the CDN reception quality with the output quality. The CDN receiving quality is calculated in the following mode: the FPS jitter of the stream received by the CDN is calculated, i.e., the FPS-average FPS | at that point in time/average FPS is calculated.
If the CDN reception quality is the same as the output quality, it indicates that it is not a forwarding exception (it is not the CDN reception quality is poor, that is, it is not the CDN reception quality that does not reach the third preset condition), and it may be other links, for example, a problem occurs in a link of the CDN itself, which is not considered in this embodiment.
If the CDN reception quality is lower than the output quality (that is, the FPS jitter corresponding to the CDN reception quality is greater than the FPS jitter corresponding to the output quality), it indicates that the user viewing has been affected due to the fact that the forward-push quality is too poor (that is, the CDN reception quality is poor, that is, the CDN reception quality does not reach the third preset condition). At this time, the link (forwarded from the edge compute node to the CDN) is actively disconnected and then re-pushed.
(5) And disconnecting the link between the edge computing node and the CDN, and reselecting a new CDN to carry out forwarding and pushing.
After re-forwarding, the link is changed, and the problem of the previous link between the point and the point can be solved.
The live broadcast pause processing system provided by this embodiment can automatically report pause information by a user-side player, and the system starts with the player pause as a starting point, integrates state information of a stream pushing end and a CDN receiving end, and judges whether the stream is pause due to a network link in real time, without requiring a user to feed back the stream, so as to automatically solve transmission abnormalities, and optimize stream pushing experience.
Example four
The present application further provides another embodiment, which is to provide a computer-readable storage medium storing a live morton processing program, which is executable by at least one processor to cause the at least one processor to perform the steps of the live morton processing method as described above.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
It will be apparent to those skilled in the art that the modules or steps of the embodiments of the present application described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different from that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.
The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications that can be made by the use of the equivalent structures or equivalent processes in the specification and drawings of the present application or that can be directly or indirectly applied to other related technologies are also included in the scope of the present application.
Claims (13)
1. A live broadcast card processing method is characterized by comprising the following steps:
collecting pause information of a player at a user side in real time;
carrying out data classification processing on the collected jam information according to flows, and counting the jam times of a single Content Delivery Network (CDN) corresponding to each flow;
judging whether transmission abnormity occurs according to the blocking times;
and when the transmission abnormity is judged, inquiring the inlet quality and the outlet quality of the edge computing node and the receiving quality of the CDN in real time, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the receiving quality of the CDN reach preset conditions or not.
2. The live morton processing method according to claim 1, wherein the morton information is automatically reported by the player, and includes a name of a stream where the morton occurs and a CDN.
3. The live morton processing method according to claim 1 or 2, wherein the step of performing data classification processing on the collected morton information according to streams comprises the following steps:
classifying the pause information according to different flows to obtain pause information corresponding to each flow;
and classifying the jam information corresponding to each flow according to different CDNs to obtain the jam information corresponding to each CDN of each flow.
4. The live morton processing method according to any one of claims 1 to 3, wherein the judging whether transmission abnormality occurs according to the morton times includes:
obtaining a number of viewers of the stream;
calculating the number of times of blocking/watching of a single CDN;
and when the calculated ratio is larger than a first threshold value, judging that the stream has abnormal transmission.
5. The live broadcast stuck processing method according to any one of claims 1 to 4, wherein the querying of the ingress and egress quality of the edge computing node and the receiving quality of the CDN in real time, and the locating of the cause of the abnormality according to whether the ingress quality, the egress quality, and the receiving quality of the CDN reach preset conditions include:
inquiring the access quality and the output quality of the edge computing node and the CDN receiving quality in real time;
judging whether the feed quality does not reach a first preset condition or not;
if not, further judging whether the inlet quality does not reach a first preset condition or not;
if not, judging whether the CDN received quality does not reach a third preset condition;
if the receiving quality of the CDN does not reach a third preset condition, disconnecting the link between the edge computing node and the CDN, and reselecting a new CDN to forward.
6. The live broadcast stuck processing method according to claim 5, wherein the evaluation criteria of the incoming quality, the outgoing quality, and the CDN reception quality are FPS jitter per second, and the larger the value of the FPS jitter is, the lower the corresponding quality is.
7. The live morton processing method according to claim 6, wherein the FPS jitter is | the average FPS |/the average FPS in a preset period of the FPS-preset period of the current time point corresponding to the stream.
8. The live broadcast morton processing method according to claim 7, wherein the judging whether the advancing quality does not reach a first preset condition comprises:
and when the FPS jitter corresponding to the stream received by the edge computing node is calculated to be larger than a second threshold value, judging that the feed quality does not reach a first preset condition.
9. The live broadcast stuck processing method according to any one of claims 5 to 8, wherein the determining whether the output quality does not meet a second preset condition includes:
calculating the outgoing mass and comparing the outgoing mass with the incoming mass;
if the outlet quality is the same as the inlet quality, judging that the outlet quality does not reach a second preset condition;
and if the output quality is lower than the input quality, judging that the output quality does not reach a second preset condition.
10. The live broadcast stuck processing method according to any one of claims 5 to 9, wherein the determining whether the CDN reception quality does not meet a third preset condition includes:
calculating the receiving quality of the CDN and comparing the receiving quality with the output quality;
if the CDN receiving quality is the same as the output quality, judging that the CDN receiving quality does not reach a third preset condition;
if the CDN receiving quality is lower than the output quality, judging that the CDN receiving quality does not reach a third preset condition.
11. A live morton processing system, the system comprising:
the collection module is used for collecting pause information of the user player in real time;
the statistical module is used for carrying out data classification processing on the collected jam information according to flows and counting the jam times of a single Content Delivery Network (CDN) corresponding to each flow;
the judging module is used for judging whether transmission abnormity occurs according to the blocking times;
and the comparison module is used for inquiring the inlet quality and the outlet quality of the edge computing node and the receiving quality of the CDN in real time when the transmission abnormity is judged to occur, and positioning the reason of the abnormity according to whether the inlet quality, the outlet quality and the receiving quality of the CDN reach the preset condition.
12. An electronic device, comprising: a memory, a processor, and a live morton processing program stored on the memory and executable on the processor, the live morton processing program when executed by the processor implementing a live morton processing method as claimed in any one of claims 1 to 10.
13. A computer-readable storage medium, having stored thereon a live morton processing program which, when executed by a processor, implements a live morton processing method as claimed in any one of claims 1 to 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111493818.8A CN114189705A (en) | 2021-12-08 | 2021-12-08 | Live broadcast card pause processing method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111493818.8A CN114189705A (en) | 2021-12-08 | 2021-12-08 | Live broadcast card pause processing method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114189705A true CN114189705A (en) | 2022-03-15 |
Family
ID=80603893
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111493818.8A Pending CN114189705A (en) | 2021-12-08 | 2021-12-08 | Live broadcast card pause processing method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114189705A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114845139A (en) * | 2022-04-27 | 2022-08-02 | 抖动科技(深圳)有限公司 | Multi-level hybrid distribution method, electronic device and readable storage medium |
| CN114928758A (en) * | 2022-05-05 | 2022-08-19 | 上海哔哩哔哩科技有限公司 | Live broadcast abnormity detection processing method and device |
| CN115412430A (en) * | 2022-08-08 | 2022-11-29 | 中国电信股份有限公司 | Abnormal node positioning method and device, electronic equipment and readable storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105309A (en) * | 2017-04-25 | 2017-08-29 | 北京潘达互娱科技有限公司 | Live dispatching method and device |
| CN107196794A (en) * | 2017-05-18 | 2017-09-22 | 腾讯科技（深圳）有限公司 | A kind of abnormal analysis method of interim card and device |
| CN112584192A (en) * | 2020-12-14 | 2021-03-30 | 广州虎牙科技有限公司 | Network quality monitoring method and device and server |
| CN113094239A (en) * | 2021-04-27 | 2021-07-09 | 上海哔哩哔哩科技有限公司 | Method for determining reason of live broadcast abnormity and server |
| CN113242443A (en) * | 2021-05-28 | 2021-08-10 | 北京达佳互联信息技术有限公司 | Data stream transmission abnormity detection method and device |
| CN113630616A (en) * | 2021-08-11 | 2021-11-09 | 上海哔哩哔哩科技有限公司 | Live broadcast edge node resource control method and system |
-
2021
- 2021-12-08 CN CN202111493818.8A patent/CN114189705A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107105309A (en) * | 2017-04-25 | 2017-08-29 | 北京潘达互娱科技有限公司 | Live dispatching method and device |
| CN107196794A (en) * | 2017-05-18 | 2017-09-22 | 腾讯科技（深圳）有限公司 | A kind of abnormal analysis method of interim card and device |
| CN112584192A (en) * | 2020-12-14 | 2021-03-30 | 广州虎牙科技有限公司 | Network quality monitoring method and device and server |
| CN113094239A (en) * | 2021-04-27 | 2021-07-09 | 上海哔哩哔哩科技有限公司 | Method for determining reason of live broadcast abnormity and server |
| CN113242443A (en) * | 2021-05-28 | 2021-08-10 | 北京达佳互联信息技术有限公司 | Data stream transmission abnormity detection method and device |
| CN113630616A (en) * | 2021-08-11 | 2021-11-09 | 上海哔哩哔哩科技有限公司 | Live broadcast edge node resource control method and system |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114845139A (en) * | 2022-04-27 | 2022-08-02 | 抖动科技(深圳)有限公司 | Multi-level hybrid distribution method, electronic device and readable storage medium |
| CN114845139B (en) * | 2022-04-27 | 2024-02-13 | 抖动科技(深圳)有限公司 | Multi-layer hybrid distribution method, electronic device and readable storage medium |
| CN114928758A (en) * | 2022-05-05 | 2022-08-19 | 上海哔哩哔哩科技有限公司 | Live broadcast abnormity detection processing method and device |
| CN115412430A (en) * | 2022-08-08 | 2022-11-29 | 中国电信股份有限公司 | Abnormal node positioning method and device, electronic equipment and readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114189705A (en) | Live broadcast card pause processing method and system | |
| US10911344B1 (en) | Dynamic client logging and reporting | |
| US10897406B2 (en) | Scheduling method for content delivery network, and device | |
| CN107277160B (en) | Content distribution network node switching method and device | |
| US9521178B1 (en) | Dynamic bandwidth thresholds | |
| US11968422B2 (en) | Video stream fault detection | |
| WO2013050891A1 (en) | Http adaptive streaming server with automatic rate shaping | |
| CN108881931B (en) | Data buffering method and network equipment | |
| CN113438129B (en) | Data acquisition method and device | |
| US20170142029A1 (en) | Method for data rate adaption in online media services, electronic device, and non-transitory computer-readable storage medium | |
| CN113891175B (en) | Live broadcast push flow method, device and system | |
| CN112019873A (en) | Video code rate adjusting method and device and electronic equipment | |
| CN113630616A (en) | Live broadcast edge node resource control method and system | |
| CN110620699A (en) | Message arrival rate determination method, device, equipment and computer readable storage medium | |
| CN113747186A (en) | Data processing method, device, terminal and storage medium | |
| CN112565016B (en) | Positioning method, system and device for abnormal time delay, electronic equipment and storage medium | |
| EP3691261A1 (en) | Method and device for locating video service fault, and storage medium | |
| CN112752111B (en) | Live stream processing method and device, computer readable storage medium and electronic equipment | |
| CN116489019B (en) | Intelligent visual signaling channel management method, system and medium | |
| CN114979091B (en) | Data transmission method, related device, equipment and storage medium | |
| CN114679570A (en) | Video transmission method and device, storage medium and electronic device | |
| CN111836020B (en) | Code stream transmission method and device in monitoring system and storage medium | |
| CN114222153B (en) | Online user quantity counting method and device, electronic equipment and storage medium | |
| CN114070827B (en) | Transmission method, equipment and medium for forwarding and pushing stream data | |
| CN112911226B (en) | Method, system and storage medium for automatically adding network camera |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |