Live broadcast microphone connection system test system and method

Abstract

The invention belongs to the technical field of live broadcast microphone connection systems, and discloses a live broadcast microphone connection system test system, which comprises a stream pushing module for video acquisition (a stream) and video acquisition (b stream), a sound network merging module (combined stream transcoding service) for sound network converging and sound network decoding, a CDN module for transmission protocol (RTMP) and transmission protocol (HLS, FLV), and a CDN audience module for IOS end display (FLV, m3u8) and Android end display (flv). The invention provides a method for quickly entering an iteration project for a QA engineer based on a topological flow chart and state code monitoring, various different states such as busy, idle, rejected and overtime among live broadcast can be judged to the greatest extent through various code state circulation, subsequent expansion can be performed according to the state code in expandability of the system, and the expandability of the system is improved. The method is convenient, friendly, popular and easy to understand, so that some problems can be solved in the early test stage, and influence on the overall project efficiency and progress due to generation of a large number of bugs in the later stage is avoided.

Description

Technical Field

[0001] The present invention belongs to the technical field of live broadcast and microphone connection systems, and specifically relates to a live broadcast and microphone connection system testing system and method. Background Art

[0002] Live interaction is a common user behavior on the C-end of the current Internet, and it is indispensable. The synchronous transmission of multi-end audio and video images is used to increase user stay and increase the user interaction atmosphere. The host initiates the user's microphone connection behavior for communication, which requires the host and the user to agree on rules for communication. The host and the user synchronize data, streaming video images, and abnormal fault tolerance in the server. This requires a detailed testing strategy based on the actual situation.

[0003] Based on the network topology diagram and status code monitoring, the interaction between the hosts in the microphone connection is realized in the initial stage of the system function and iterated in the later stage. In the early stage of development, the user end implements the scenario defined in the logical interaction diagram, and the server uses the status code monitoring to self-test each status code path. In the later test, the QA engineer verifies the function based on the logic diagram and status code, so that the front-end and back-end interactions are consistent and the functions are complete. In the implementation of complex functions such as microphone connection, this solution can quickly and effectively clear internal defects and ensure system quality. The disadvantage of this solution is that it is not suitable for microphone connection with more than six people. It is currently only suitable for microphone connection and interactive mode with two people. When it involves interactive microphone connection with more than 3 people, more complex data and logic definitions are required, such as network delay request processing and host pk delay effective time exchange. Calculate and monitor the status code method on the anchor side. In network communication, each behavior of the anchor and the anchor himself is executed based on the instructions given by the status code. Therefore, the anchors adopt the call-receive-answer method to ensure that there will be corresponding feedback on various behaviors of the anchor in the network, and the correctness of data transmission between the anchor, user, and anchor. At the same time, the status code is sent through messages, which does not occupy memory, saves user-side traffic, and makes the interaction between users and anchors smooth. The main disadvantage of this solution is that if the SEI message is lost, and the retry fails or the power is off, the anchor needs to reset the initial state of the anchor to ensure the correctness of the status code when each anchor continues to connect with different anchors. This is very inconvenient, so it needs to be improved. Summary of the invention

[0004] The purpose of the present invention is to provide a live broadcast and microphone connection system testing system and method to solve the problems raised in the above background technology.

[0005] In order to achieve the above-mentioned purpose, the present invention provides the following technical solutions: a live broadcast and microphone connection system test system, including a streaming module: video acquisition (a stream), video acquisition (b stream), an acousto-network merging module (stream confluence transcoding service): acousto-network confluence, acousto-network decoding, a CDN module: a transmission protocol (RTMP), a transmission protocol (HLS, FLV) and a CDN audience module: IOS-side display (FLV, m3u8), Android-side display (flv).

[0006] As a preferred technical solution of the present invention, the RTMP is a patented protocol of Adobe, which is a network protocol designed for real-time data communication, mainly used for audio, video and data communication between Flash / AIR platform and streaming media / interactive server supporting RTMP protocol.

[0007] As a preferred technical solution of the present invention, the HLS, namely Http Live Streaming, is a streaming media transmission protocol based on HTTP.

[0008] As a preferred technical solution of the present invention, the FLV uses the HTTP protocol to stream media content, and the FLV protocol content delay can be 2-5 seconds, and the opening speed is faster.

[0009] The method of testing the live broadcast and microphone system is as follows:

[0010] Step 1: Divide the server, anchor, and user into their own behavior scenarios, such as sending paid gifts, sending free gifts, sending barrage gifts, and following anchors. Different behaviors will give different scores to the anchors.

[0011] Step 2: On the server side, after receiving each user behavior, read the configuration table first to obtain the corresponding gift score;

[0012] Step 3: On the server side, after receiving the gift, use the getmessage interface to determine the message type. If it is a gift message, send the message to all users in the live broadcast room, and update the PK list scores of anchor B and anchor B in all live broadcast rooms;

[0013] Step 4: On the server side, use the total score acquisition interface to obtain the total score of the PK list, and perform pipeline accumulation and score addition for all received gift messages;

[0014] Step 5: On the server side, the host status is marked with 0, 1, 2, and 3 respectively. 0 indicates that the match has not started, 1 indicates that the match is in progress, 2 indicates that the match has ended, and 3 indicates the post-match talent show reward and punishment stage.

[0015] Step 6: On the server side, after the anchors compete with each other via microphone, the winner is displayed through the leaderboard scores, and the status is synchronized to the anchor and user sides;

[0016] Step 7: On the server side, define abnormal situations, such as network interruption, power failure, pause, and other unpredictable abnormalities. When the host performs PK with microphone next time, reset the PK status to 0, and 0 is marked as not started.

[0017] Step 8: On the user side, after two anchors are connected to the microphone, the layout of the connected microphone screen is synchronized through SEI messages;

[0018] Step 9: On the user side, users can increase the anchor's ranking PK value by sending free gifts, paid gifts, liking, following, and other behaviors;

[0019] Step 10: On the user side, dynamically calculate the score of the anchor PK list through the polling interface and display it to the user in real time;

[0020] Step 11: On the user side, the real-time status of the live broadcast pk is displayed, indicating that the current pk is in progress, the penalty phase, and has ended;

[0021] Step 12: On the user side, the delay processing method is used to handle the problem of asynchronous end of PK on the user side. For example, the PK session is set to 5 minutes, but there is a delay on the user side, and the received time will be later than the actual time. The total duration minus the current message receiving time is used to handle the delay, ensuring that each user views the end time of the PK session at the same time.

[0022] Step 13: On the anchor side, synchronize the behaviors of the anchors through different status codes;

[0023] Step 14: On the host side, the normal linking process is as follows: host A sends code = 101, host B receives code = 101, host B accepts the linking code = 102, host B sends a linking success receipt to host A, and returns code = 103. The handshake communication between the two parties is successful.

[0024] Step 15: On the host side, host A actively disconnects the connection and sends code=104 to interrupt the process.

[0025] Step 16: On the host side, cancel the link-in process. Host B receives the link-in request from host A. Host B chooses to cancel and sends code = 105. After receiving the code, host A cancels and retries every 10 seconds. The user side displays the current host screen.

[0026] Step 17: On the user side, both anchor A and anchor B are busy, and return code = 104, and both anchors are not idle.

[0027] As a preferred technical solution of the present invention, the SEI described in step eight is called Supplemental Enhancement Information, which refers to the coding information added to the current video.

[0028] As a preferred technical solution of the present invention, the joint microphone screen display described in step eight is divided into Android and ios, Android and ios play video streams in different formats of flv and m3u8 respectively, and multiple anchor screens are displayed through CDN distribution.

[0029] As a preferred technical solution of the present invention, the score for the user terminal sending a paid gift in step one is 0.1 gold coin equal to 10PK value, the score for sending a free gift is 10PK value, the score for sending a barrage is 10PK value, and the score for following the anchor is 300PK value.

[0030] As a preferred technical solution of the present invention, after the host interrupts the process as described in step 15, the user terminals each return to the current host's screen.

[0031] The beneficial effects of the present invention are as follows:

[0032] The present invention provides a method based on topological flow chart and status code monitoring, thereby providing QA engineers with a method for quickly entering an iterative project. For example, anchor a searches for anchor b, and anchor b searches for anchor a at the same time, and both parties are not idle, and return code=104; anchor a and anchor b are in a microphone connection, anchor c requests to connect with anchor a, and return code=201; anchor a initiates code=101, and anchor b receives the invitation code=101; at this time, anchor b can cancel and return code104=; anchor refuses coce=104, anchor b ignores code=105, and anchor agrees code=102; after anchor b agrees to anchor a's microphone connection request, it sends code=103, and anchor a receives a receipt at this time, and the handshake communication between the two parties is successful, and the screen synchronization is connected; if anchor a does not receive a receipt at this time , send a receipt again after 10s, cancel the microphone connection after three retries, and send a cancellation receipt code = 105; idle state judgment: code = 101 indicates that the microphone connection request has been received, and it is undecided whether to accept the microphone connection; Code = 104, the microphone connection can be made if the microphone connection is not idle in the rejected state; code = 105 cancels other people's microphone connection or times out, and the microphone connection can be made if it is still not idle. The above various code state flows can judge the busy, idle, rejected, timed and other different states between live broadcasts to the greatest extent. In the scalability of the system, subsequent expansion can be carried out according to the status code, which is convenient, friendly, and easy to understand, so that some problems can be solved in the early stage of testing, avoiding a large number of bugs in the later stage, affecting the overall project efficiency and progress. At the same time, this solution innovates the test pre-position, defines all front-end and back-end interactions and exceptions, and proposes solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is a functional architecture diagram of the present invention;

[0034] Figure 2 This is a topological flow chart of initiating / receiving a microphone connection in the present invention;

[0035] Figure 3 This is a topological flow chart of the front-end and back-end logical interaction of the present invention when initiating a live PK;

[0036] Figure 4 This is a display diagram of the status code monitoring of the present invention. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] like Figures 1 to 4 As shown, an embodiment of the present invention provides a live broadcast and microphone connection system test system, including a streaming module: video acquisition (a stream), video acquisition (b stream), an acousto-network merging module (stream confluence transcoding service): acousto-network confluence, acousto-network decoding, a CDN module: a transmission protocol (RTMP), a transmission protocol (HLS, FLV) and a CDN audience module: an IOS-side display (FLV, m3u8), an Android-side display (flv).

[0039] The live broadcast and microphone connection system test system provided by the present invention can timely judge various states such as busy, idle, rejected, timeout, etc. between live broadcasts through the mutual cooperation between various modules. In the scalability of the system, subsequent expansion can be performed according to the status code, thereby improving the convenience of the test system. The network topology diagram and the method of monitoring the host status code are used to ensure the quality of the microphone connection function, and ensure that hosts A and B can communicate, interact, and merge audio and video normally. It can help QA engineers to quickly cover functional tests, narrow the scope of problems from complex scenarios, and accurately and effectively locate problems when making changes in any link of the live broadcast system.

[0040] Among them, RTMP is Adobe's patented protocol, a network protocol designed for real-time data communication. It is mainly used for audio, video and data communication between Flash / AIR platforms and streaming media / interactive servers that support the RTMP protocol.

[0041] The support for RTMP protocol open source software and open source libraries is stable and complete, and the installation rate on the playback end is high. As long as the browser supports FlashPlayer, RTMP live broadcasts can be played very easily.

[0042] Among them, HLS, or Http Live Streaming, is a streaming media transmission protocol based on HTTP.

[0043] HTML5 can be opened and played directly, which means that a live broadcast link can be forwarded and shared without installing any independent APP. A browser is enough. It is very popular. For social live broadcast APP, HLS can be said to be a necessity.

[0044] Among them, FLV uses the HTTP protocol to stream media content. The FLV protocol content delay can be as short as 2-5 seconds, and the opening speed is faster.

[0045] Compared with RTMP, HTTP is simpler and more widely known, and there is no need to worry about being held hostage by Adobe's patents, because HTTP itself does not have complex state interactions. Therefore, from a latency perspective, HTTP-FLV is superior to RTMP.

[0046] The method of testing the live broadcast and microphone system is as follows:

[0047] Step 1: Divide the server, anchor, and user into their own behavior scenarios, such as sending paid gifts, sending free gifts, sending barrage gifts, and following anchors. Different behaviors will give different scores to the anchors.

[0048] Step 2: On the server side, after receiving each user behavior, read the configuration table first to obtain the corresponding gift score;

[0049] Step 3: On the server side, after receiving the gift, use the getmessage interface to determine the message type. If it is a gift message, send the message to all users in the live broadcast room, and update the PK list scores of anchor B and anchor B in all live broadcast rooms;

[0050] Step 4: On the server side, use the total score acquisition interface to obtain the total score of the PK list, and perform pipeline accumulation and score addition for all received gift messages;

[0051] Step 5: On the server side, the host status is marked with 0, 1, 2, and 3 respectively. 0 indicates that the match has not started, 1 indicates that the match is in progress, 2 indicates that the match has ended, and 3 indicates the post-match talent show reward and punishment stage.

[0052] Step 6: On the server side, after the anchors compete with each other via microphone, the winner is displayed through the leaderboard scores, and the status is synchronized to the anchor and user sides;

[0053] Step 7: On the server side, define abnormal situations, such as network interruption, power failure, pause, and other unpredictable abnormalities. When the host performs PK with microphone next time, reset the PK status to 0, and 0 is marked as not started.

[0054] Step 8: On the user side, after two anchors are connected to the microphone, the layout of the connected microphone screen is synchronized through SEI messages;

[0055] Step 9: On the user side, users can increase the anchor's ranking PK value by sending free gifts, paid gifts, liking, following, and other behaviors;

[0056] Step 10: On the user side, dynamically calculate the score of the anchor PK list through the polling interface and display it to the user in real time;

[0057] Step 11: On the user side, the real-time status of the live broadcast pk is displayed, indicating that the current pk is in progress, the penalty phase, and has ended;

[0058] Step 12: On the user side, the delay processing method is used to handle the problem of asynchronous end of PK on the user side. For example, the PK session is set to 5 minutes, but there is a delay on the user side, and the received time will be later than the actual time. The total duration minus the current message receiving time is used to handle the delay, ensuring that each user views the end time of the PK session at the same time.

[0059] Step 13: On the anchor side, synchronize the behaviors of the anchors through different status codes;

[0060] Step 14: On the host side, the normal linking process is as follows: host A sends code = 101, host B receives code = 101, host B accepts the linking code = 102, host B sends a linking success receipt to host A, and returns code = 103. The handshake communication between the two parties is successful.

[0061] Step 15: On the host side, host A actively disconnects the connection and sends code=104 to interrupt the process.

[0062] Step 16: On the host side, cancel the link-in process. Host B receives the link-in request from host A. Host B chooses to cancel and sends code = 105. After receiving the code, host A cancels and retries every 10 seconds. The user side displays the current host screen.

[0063] Step 17: On the user side, both anchor A and anchor B are busy, and return code = 104, and both anchors are not idle.

[0064] The strategy provided by the present invention is used by any QA engineer, who can participate in the pipeline business line and quickly get started with the business. The strategy has the following characteristics: 7 types of end scenarios are divided to clarify the functions of each business party, and each party performs its own duties. If a problem occurs in any link, the defect generator can be identified from the scenario diagram and quickly repaired; the start-end flow, reaction-response, and pace are consistent. The initiator of each business scenario, the final data flow, and processing have corresponding end nodes; through the status code, instructions are accurately issued between anchor a, anchor b, and a large number of users to complete each business scenario of the microphone connection; the fault-tolerant processing mechanism ensures that in the microphone connection scenario, each fault-tolerant verification is performed for disconnection, network disconnection, anchor abnormality, no response, anchor pause, anchor hang-up, and anchor process being killed, so as to ensure the robustness of the system.

[0065] Among them, the SEI in step 8 stands for Supplemental Enhancement Information, which refers to the coding information added to the current video.

[0066] SEI is mainly used for various interactive scenarios in live broadcast scenarios, which contains the layout information of the media screen in the room. The user end can view various information and pictures of the host through the above messages.

[0067] Among them, the joint microphone screen display in step eight is divided into Android and iOS. Android and iOS play video streams in different formats of flv and m3u8 respectively, and display multiple anchor screens through CDN distribution.

[0068] The division of Android and iOS can ensure that different user terminals can obtain the live screen layout in a timely manner, prevent the occurrence of asynchrony, and help improve the user terminal's viewing experience.

[0069] Among them, the score for the user end to send a paid gift in step one is 0.1 gold coin equal to 10PK value, the score for sending a free gift is 10PK value, the score for sending a barrage is 10PK value, and the score for following the anchor is 300PK value.

[0070] The upper limit score of free gifts is 100PK value, and the upper limit score of barrage is 100PK value. The host's score is calculated by dividing the scores of different user behaviors.

[0071] Among them, after the process is interrupted at the anchor end in step 15, the user ends each return to the current anchor's screen.

[0072] After the anchor hangs up, the user end will return to the current anchor screen, so that the user end will not jump to another anchor screen, which is beneficial to protecting the number of viewers of the anchor itself.

[0073] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0074] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. Live broadcast and microphone connection system test system, characterized by: It includes streaming module: video acquisition (a stream), video acquisition (b stream), Agora merging module (stream confluence transcoding service): Agora confluence, Agora decoding, CDN module: transport protocol (RTMP), transport protocol (HLS, FLV) and CDN audience module: IOS display (FLV, m3u8), Android display (flv).

2. The live broadcast and microphone connection system testing system according to claim 1, characterized in that: The RTMP is a patented protocol of Adobe and is a network protocol designed for real-time data communication. It is mainly used for audio, video and data communication between Flash / AIR platforms and streaming media / interactive servers that support the RTMP protocol.

3. The live broadcast and microphone connection system testing system according to claim 1, characterized in that: The HLS, or Http Live Streaming, is a streaming media transmission protocol based on HTTP.

4. The live broadcast and microphone connection system testing system according to claim 1, characterized in that: The FLV uses the HTTP protocol to stream media content. The FLV protocol content delay can be 2-5 seconds, and the opening speed is faster.

5. A method for testing a live broadcast and microphone system, characterized in that , the specific steps are as follows: Step 1: Divide the server, anchor, and user into their own behavior scenarios, such as sending paid gifts, sending free gifts, sending barrage gifts, and following anchors. Different behaviors will give different scores to the anchors. Step 2: On the server side, after receiving each user behavior, read the configuration table first to obtain the corresponding gift score; Step 3: On the server side, after receiving the gift, use the getmessage interface to determine the message type. If it is a gift message, send the message to all users in the live broadcast room, and update the PK list scores of anchor B and anchor B in all live broadcast rooms; Step 4: On the server side, use the total score acquisition interface to obtain the total score of the PK list, and perform pipeline accumulation and score addition for all received gift messages; Step 5: On the server side, the host status is marked with 0, 1, 2, and 3 respectively. 0 indicates that the match has not started, 1 indicates that the match is in progress, 2 indicates that the match has ended, and 3 indicates the post-match talent show reward and punishment stage. Step 6: On the server side, after the anchors compete with each other via microphone, the winner is displayed through the leaderboard scores, and the status is synchronized to the anchor and user sides; Step 7: On the server side, define abnormal situations, such as network interruption, power failure, pause, and other unpredictable abnormalities. When the host performs PK with microphone next time, reset the PK status to 0, and 0 is marked as not started. Step 8: On the user side, after two anchors are connected to the microphone, the layout of the connected microphone screen is synchronized through SEI messages; Step 9: On the user side, users can increase the anchor's ranking PK value by sending free gifts, paid gifts, liking, following, and other behaviors; Step 10: On the user side, dynamically calculate the score of the anchor PK list through the polling interface and display it to the user in real time; Step 11: On the user side, the real-time status of the live broadcast pk is displayed, indicating that the current pk is in progress, the penalty phase, and has ended; Step 12: On the user side, the delay processing method is used to handle the problem of asynchronous end of PK on the user side. For example, the PK session is set to 5 minutes, but there is a delay on the user side, and the received time will be later than the actual time. The total duration minus the current message receiving time is used to handle the delay, ensuring that each user views the end time of the PK session at the same time. Step 13: On the anchor side, synchronize the behaviors of the anchors through different status codes; Step 14: On the host side, the normal linking process is as follows: host A sends code = 101, host B receives code = 101, host B accepts the linking code = 102, host B sends a linking success receipt to host A, and returns code = 103. The handshake communication between the two parties is successful. Step 15: On the host side, host A actively disconnects the connection and sends code=104 to interrupt the process. Step 16: On the host side, cancel the link-in process. Host B receives the link-in request from host A. Host B chooses to cancel and sends code = 105. After receiving the code, host A cancels and retries every 10 seconds. The user side displays the current host screen. Step 17: On the user side, both anchor A and anchor B are busy, and return code = 104, and both anchors are not idle.

6. The method for testing a live broadcast and microphone connection system according to claim 5, characterized in that: The SEI described in step 8 is called Supplemental Enhancement Information, which refers to adding coding information to the current video.

7. The method for testing a live broadcast and microphone connection system according to claim 5, characterized in that: The live broadcast screen display described in step eight is divided into Android and iOS. Android and iOS play video streams in different formats of flv and m3u8 respectively, and display multiple anchor screens through CDN distribution.

8. The method for testing a live broadcast and microphone connection system according to claim 5, characterized in that: The score for the user end sending a paid gift described in step one is 0.1 gold coin equal to 10PK value, the score for sending a free gift is 10PK value, the score for sending a barrage is 10PK value, and the score for following the anchor is 300PK value.

9. The method for testing a live broadcast and microphone connection system according to claim 5, characterized in that: After the host interrupts the process as described in step 15, the user ends return to the current host's screen.

Images