Method and system for reducing multi-channel concurrency of real time streaming protocol (RTSP)

Abstract

The invention discloses a method and system for reducing RTSP multi-channel concurrency, and belongs to the field of data processing.The method comprises the steps that a data packet is received from a network port; checking whether the data packet is an RTSP data packet; if yes, checking the RTSP type of the RTSP data packet, and judging whether the RTSP data packet is an RTSP request or not; if the data packet is not the RTSP data packet, checking whether a table item corresponding to a video source IP exists in a service table; checking the RTSP type of the RTSP data packet, and judging whether the RTSP data packet is an RTSP request or not; if the request is the RTSP request, creating or updating a service table according to the IP of the video source; if the response is the RTSP response, recording a port number and updating a service table; updating the timestamp of the corresponding applicant in the service table; and continuing to receive the next data packet. According to the method, only one path of source end data is provided, but the data can be accurately pushed to a needed player, the utilization rate of the data is greatly reduced, meanwhile, only various video parameters of the video pulled up for the first time need to be configured, the operation difficulty is reduced, and the method has good practical value and application prospects.

Description

Technical Field

[0001] The invention belongs to the field of data processing, and in particular relates to a method and a system for reducing RTSP multi-channel concurrency. Background Art

[0002] In existing wireless links, when multiple players play the same video source, there are many limitations. For example, when multiple players pull the same video source at the same time, if the network bandwidth is limited, it may cause network congestion. Especially during peak hours, a large number of players request the same video data at the same time, which may quickly fill up the network bandwidth, causing the video to freeze, buffer, or even fail to play. For example, in a broadband network in a community, many users watch the same popular TV series or live sports events through smart TVs or other devices at the same time during prime time in the evening, and the viewing quality may be affected due to network congestion.

[0003] Even if the network bandwidth itself is sufficient, if the export bandwidth of the video source server is limited and cannot meet the high concurrent requests of a large number of players at the same time, it will also cause network congestion problems. This may cause slow server response and increased data transmission delay, affecting the viewing experience of all players.

[0004] Secondly, the quality fluctuation of the video source has a wide impact: if the video source itself has quality problems, such as video source file damage, encoding errors, or server-side transmission failures, all players that pull the video source at the same time will be affected. In this case, it will cause large-scale playback anomalies, and users may see problems such as blurred images, distorted screens, abnormal sounds, or video interruptions, which seriously affect the user experience. Moreover, since multiple players are affected at the same time, the troubleshooting and resolution of the problem may be more complicated, and it is necessary to handle feedback and complaints from multiple users at the same time, which increases the difficulty and cost of maintenance.

[0005] In addition, if the server load of the video source is too high, the video transmission quality may be reduced in order to meet the requests of multiple players, such as reducing the video resolution, frame rate or audio quality, resulting in a decrease in the user experience of all viewers of the video and the inability to enjoy high-quality video playback effects. Summary of the invention

[0006] In view of one or more of the above defects or improvement requirements of the prior art, the present invention provides a method, system and storage medium for reducing RTSP multi-channel concurrency. The source data has only one channel, but the data can be accurately pushed to the required player, greatly reducing the data usage rate. At the same time, only the various video parameters for pulling up the video for the first time need to be configured, reducing the complexity of the operation. In addition, a private unicast protocol is used to reduce the time slot overhead, with strong adaptability, and the operation can be performed for a specific IP active port according to customer requirements.

[0007] To achieve the above object, the present invention provides a method for reducing RTSP multi-channel concurrency, the method comprising the following steps:

[0008] S100: receives data packets from the network port;

[0009] S200: Determine the data type and check whether the data packet is an RTSP data packet; if so, go to S300; if not, go to S600;

[0010] S300: Processing RTSP data packets to check the RTSP type of the RTSP data packets and determine whether it is an RTSP request; if it is an RTSP request, creating or updating a service table according to the IP of the video source; if it is not an RTSP request but an RTSP response, recording the port number and updating the service table;

[0011] S400: Update the timestamp of the applicant and update the timestamp of the corresponding applicant in the business table;

[0012] S500: Continue to receive data and return to S100 to continue receiving the next data packet;

[0013] S600: Process the RTP data packet to check whether there is an entry corresponding to the video source IP in the service table;

[0014] If it exists, check whether it is the first request for data; if it is the first request, keep the data and send it to the server via the air interface; if it is not the first request, discard the data; if it does not exist, discard the data;

[0015] S700: After receiving the request from the client, the server performs a timeout check; if the applicant timestamp is not updated for more than n1 seconds, move other applicants to the first position of the structure (if sent, only the first applicant data is sent); perform an n1 second timeout check: if the applicant timestamp is not updated for more than n2 seconds, delete the applicant table entry; perform an n3 second timeout check (for video source without applicant): if the video source has no applicant for more than n3 seconds, delete the table entry of the corresponding camera;

[0016] S800: When receiving data, the video source processing only retains the first channel of video data (based on the unique identification such as the video source IP); if necessary, modify the destination ID and the identifier and ensure that they correspond one to one;

[0017] S900: The player processes the data received from the air interface; determines whether the data is ARSP data (assuming it is processed RTSP data); if it is ARSP data, restores the IP address and port number;

[0018] S1000: The process ends.

[0019] As a further improvement of the present invention, the processing of the RTSP data packet in step S300 includes the following steps:

[0020] S301: Mark the RTP data as a request and obtain the video source IP and port number;

[0021] S302: Check whether there is an entry applicant corresponding to the video source IP in the service table; if so, go to S303; if not, go to S304;

[0022] S303: Check whether the port number is zero, if the port number is not zero, go to S307; if it is zero, go to S305;

[0023] S304: Adding a service entry;

[0024] S305: Apply for a timestamp, and update the timestamp of the corresponding applicant;

[0025] S306: Adding an ARSP table entry;

[0026] S307: Update the port number of the corresponding applicant and add an ARSP table entry.

[0027] As a further improvement of the present invention, when the timestamp is updated in step S400, the time difference is updated first, and then the timestamp is updated according to the time difference;

[0028] The time difference is the current time minus the time of the last update timestamp in the applicant table entry. After the update is completed, it is necessary to continue to check whether to perform n3 seconds, n2 seconds, and n1 seconds timeout checks.

[0029] As a further improvement of the present invention, processing the RTP data packet in step S600 includes the following steps:

[0030] S601: Add a data table entry. If it is the first request data, save the data and send it through the air interface; if not, discard the data;

[0031] S602: Check whether the ARSP table entry is empty; if not, send ARSP data; if empty, go to S603;

[0032] S603: Check whether it is necessary to send ARSP data; if the data table entry is empty, it does not need to be sent; if it is not empty, calculate the ARSP table entry number to be deleted;

[0033] S604: Delete the ARSP table entry and the corresponding applicant table entry, and update firstIndex;

[0034] S605: Update the ARSP entry timestamp;

[0035] S606: Check whether it is necessary to send ARSP data. If the data table entry is empty, it is not necessary to send it. If it is not empty, calculate the index of the ARSP data to be sent.

[0036] S607: Recover the IP address and port number from the corresponding ARSP table entry;

[0037] S608: Check whether there is an applicant for the video source: if there is an applicant for the video source, delete the ARSP table entry; if not, go to S609;

[0038] S609: Send the corresponding ARSP data packet.

[0039] As a further improvement of the present invention, in step S603, calculating the number of the ARSP entry to be deleted includes the following steps:

[0040] Mark the deletion position firstIndex, which is set to 0 by default; find the ARSP table entry position that meets the following two conditions: the difference between the time difference and the current time difference is greater than n1 seconds; the difference between the application time and the current time is greater than n1 seconds;

[0041] Update firstIndex; if the location is found, go to S604; if not found, go to S605.

[0042] As a further improvement of the present invention, in step S606, the specific calculation method of the ARSP data index includes the following steps:

[0043] Mark the sending position sendIndex, the default setting is 0;

[0044] Calculate the sending time difference: the difference between the sending time and the current time;

[0045] Find the ARSP table entry position that meets the following two conditions: the difference between the time difference and the sending time difference is greater than n1 seconds; the difference between the application time and the sending time is greater than n1 seconds, and update sendIndex;

[0046] If the location is found, go to S607; if not found, go to S607;

[0047] S607: Recover the IP address and port number from the corresponding ARSP table entry;

[0048] S608: Check whether there is an applicant for the video source: if there is an applicant for the video source, delete the ARSP table entry; if not, go to S609;

[0049] S609: Send the corresponding ARSP data packet.

[0050] As a further improvement of the present invention, the video source processing in step S800 includes the following steps:

[0051] S801: mark the send flag sendFlag, which is initialized to false by default;

[0052] S802: Determine whether RTSP control information is received. If received, go to S803; if not received, check whether sendFlag is true. If true, send the corresponding RTP data to the air interface; if false, go to S806;

[0053] S803: mark the send flag sendFlag as true;

[0054] S804: Determine whether the applicant is a live video source; if it is a live video source, directly set the send flag sendFlag to false, and go to S809; if it is not a live video source, continue to determine whether it is a multicast source, and go to S805;

[0055] S805: Determine whether it is a multicast source, and directly proceed to S806;

[0056] S806: Add video source data table entry;

[0057] S807: Check whether the video source data table is empty; if it is empty, go to S808; if it is not empty, go directly to S809;

[0058] S808: Check whether the data source needs to be modified; if it needs to be modified, go to S809;

[0059] S809: Check the data type and length, and go to S810;

[0060] S810: modify the destination ID and identifier, and go to S809;

[0061] S811: Determine whether the data has been processed; if so, go to S909; if not, go to S802.

[0062] As a further improvement of the present invention, the player processing in step S900 includes the following steps:

[0063] S901: The player receives data through the air interface;

[0064] S902: Determine whether the data is ARSP data; if yes, go to S903; if not, go to S907;

[0065] S903: Mark the ARSP data flag isARSP as true;

[0066] S904: Recover the video source information and port number from the air interface data;

[0067] S905: Update the ARSP data timestamp; S906: Determine whether the ARSP data has been processed; if it has been processed, go to S907; if not, go to S901;

[0068] S907: Determine whether isARSP is true; if true, go to S901; if not, go to S908;

[0069] S908: Search for an ARSP data table entry that meets the following conditions: the video source IP is the same as the destination IP, and the video source video port is the same as the destination port; if found, go to S909; if not found, go to S910;

[0070] S909: mark the ARSP data flag isARSP as false;

[0071] S910: Determine whether the ARSP table is empty; if it is empty, go to S911; if not empty, go to S912;

[0072] S911: Clear the ARSP data flag isARSP and jump to S901;

[0073] S912: Insert the ARSP data into the ARSP table entry.

[0074] In another aspect, the present invention further provides a system for reducing RTSP multi-channel concurrency, wherein the system is used to implement the above-mentioned method for reducing RTSP multi-channel concurrency.

[0075] The above-mentioned improved technical features can be combined with each other as long as they do not conflict with each other.

[0076] In general, compared with the prior art, the above technical solution conceived by the present invention has the following beneficial effects:

[0077] The method, system and storage medium for reducing RTSP multi-channel concurrency of the present invention have only one source end data, but can accurately push the data to the required player, greatly reducing the data usage rate. At the same time, only the various video parameters of the first video pull-up need to be configured, reducing the complexity of the operation. In addition, a private unicast protocol is used to reduce the time slot overhead, and the adaptability is strong. The operation can be performed for a specific IP active port according to customer requirements, and has good practical value and application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the structures shown in these drawings without paying creative work.

[0079] Figure 1 It is an overall flow chart of a method for reducing RTSP multi-channel concurrency in an embodiment of the present invention.

[0080] Figure 2 It is a logical relationship diagram of a method for reducing RTSP multi-channel concurrency in an embodiment of the present invention.

[0081] The realization of the purpose, functional features and advantages of the present invention will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0082] 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.

[0083] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement status, etc. between the components in a certain specific posture. If the specific posture changes, the directional indication will also change accordingly.

[0084] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features limited to "first" and "second" may explicitly or implicitly include at least one of the features. In addition, if "and / or" or "and / or" appears in the full text, its meaning includes three parallel solutions. Taking "A and / or B" as an example, it includes solution A, solution B, or solutions that satisfy both A and B. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0085] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0086] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in each embodiment of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0087] See also Figure 1 and Figure 2 The method for reducing RTSP multi-channel concurrency in a preferred embodiment of the present invention comprises the following steps:

[0088] S100: Data reception, receiving data packets from the network port.

[0089] S200: Determine the data type and check whether the data packet is an RTSP data packet; if so, go to S300; if not, go to S600.

[0090] S300: Process the RTSP data packet, check if the RTSP packet type is RTSP, and determine whether it is a request. If it is a request, create or update the service table according to the video source IP; if it is not a request (i.e., an RTSP response), record the port number and update the service table.

[0091] Further, in step S300, the specific process of processing the RTSP data packet includes the following steps:

[0092] S301: Mark the RTP data as a request and obtain the video source IP and port number;

[0093] S302: Check whether there is an entry applicant corresponding to the video source IP in the service table; if so, go to S303; if not, go to S304.

[0094] S303: Check whether the port number is zero (indicating that there is an applicant with the same video source IP); if the port number is not zero, go to S307; if it is zero, go to S305;

[0095] S304: Add a service table entry (create or update the service table according to the video source IP);

[0096] S305: Apply for a timestamp, and update the timestamp of the corresponding applicant;

[0097] S306: Adding an ARSP table entry;

[0098] S307: Update the port number of the corresponding applicant and add the ARSP table entry. To update the service table, it is necessary to perform a timestamp update.

[0099] S400: Update the timestamp of the applicant, and update the timestamp of the corresponding applicant in the business table. Specifically, when updating, first update the time difference, and then update the timestamp according to the time difference. The time difference is the current time minus the time when the timestamp in the applicant table entry was last updated. After the update is completed, it is necessary to continue to check whether to perform the 30-second, 10-second, and 3-second timeout checks.

[0100] S500: Continue to receive data, and return to S100 to continue to receive the next data packet.

[0101] S600: Processing RTP data packets: Check whether there is an entry in the service table corresponding to the video source IP. If so, check whether it is the first request for data; if so, retain the data and send it to the server through the air interface; if not, discard the data; if not, discard the data.

[0102] Furthermore, the specific steps of processing the RTP data packet in S600 include the following:

[0103] S601: Add a data table entry. If it is the first request data, save the data and send it through the air interface. If not, discard the data.

[0104] S602: Check whether the ARSP table entry is empty; if not, send ARSP data; if it is empty, go to S603.

[0105] S603: Check whether it is necessary to send ARSP data. If the data entry is empty, it does not need to be sent; if it is not empty, calculate the ARSP entry number that needs to be deleted. Specific calculation method:

[0106] 1) Mark the deletion position firstIndex, which is set to 0 by default;

[0107] 2) Find the ARSP table entry location that meets the following two conditions: the difference between the time difference and the current time difference is greater than 3 seconds; the difference between the application time and the current time is greater than 3 seconds;

[0108] 3) Update firstIndex: If the location is found, go to S604; if not found, go to S605.

[0109] S604: Delete the ARSP table entry and the corresponding applicant table entry, and update firstIndex;

[0110] S605: Update the ARSP entry timestamp;

[0111] S606: Check whether ARSP data needs to be sent. If the data table entry is empty, it does not need to be sent; if it is not empty, calculate the ARSP data index that needs to be sent; the specific calculation method is:

[0112] 1) Mark the sending position sendIndex, which is set to 0 by default;

[0113] 2) Calculate the sending time difference: the difference between the sending time and the current time;

[0114] 3) Find the ARSP table entry location that meets the following two conditions: the difference between the time difference and the sending time difference is greater than 3 seconds; the difference between the application time and the sending time is greater than 3 seconds;

[0115] 4) Update sendIndex. If the location is found, go to S607; if not found, go to S607.

[0116] S607: Recover the IP address and port number from the corresponding ARSP table entry;

[0117] S608: Check whether there is an applicant for the video source: if there is an applicant for the video source, delete the ARSP table entry; if not, go to S609;

[0118] S609: Send the corresponding ARSP data packet.

[0119] S700: Execute timeout check: Execute 3-second timeout check: If the applicant timestamp is not updated within 3 seconds, move other applicants to the first position of the structure (business table) (if sent, only send the data of the first applicant).

[0120] Perform a 10-second timeout check: If the applicant timestamp is not updated within 10 seconds, delete the applicant entry.

[0121] Perform a 30-second timeout check (for video sources with no applicants): If there is no applicant for the video source for more than 30 seconds, delete the entry for the corresponding camera.

[0122] S800: When the video source processing receives the data, only the first channel of video data is retained (based on the unique identification such as the video source IP). If necessary, the destination ID and the identifier are modified and ensured to correspond one to one. Preferably, the identifier is: nextid.

[0123] In more detail, in step S800, the specific contents of video source processing are as follows:

[0124] S801: mark the send flag sendFlag, which is initialized to false by default;

[0125] S802: Determine whether RTSP control information (ie, non-RTP data packet) is received. If received, go to S803; if not received, check whether sendFlag is true. If true, send the corresponding RTP data to the air interface; if the send flag sendFlag is false, go to S806.

[0126] S803: mark the send flag sendFlag as true;

[0127] S804: Determine whether the applicant is a live video source; if it is a live video source, directly set the send flag sendFlag to false, and go to S809; if it is not a live video source, continue to determine whether it is a multicast source, and go to S805;

[0128] S805: Determine whether it is a multicast source, and directly proceed to S806;

[0129] S806: Add video source data table entry;

[0130] S807: Check whether the video source data table is empty; if it is empty, go to S808; if it is not empty, go directly to S809;

[0131] S808: Check whether the data source needs to be modified; if it needs to be modified, go to S809;

[0132] S809: Data type and length determination, go to S810;

[0133] S810: modify the destination ID and identifier, and go to S809;

[0134] S811: Determine whether the data has been processed; if so, go to S909; if not, go to S802.

[0135] S900: Player processing: receiving data from the air interface; determining whether the data is ARSP data (assuming it is processed RTSP data); if so, recovering the IP address and port number;

[0136] The specific steps of player processing in S900 are as follows:

[0137] S901: The player receives data through the air interface;

[0138] S902: Determine whether the data is ARSP data;

[0139] If yes, go to S903; if no, go to S907;

[0140] S903: Mark the ARSP data flag isARSP as true;

[0141] S904: Recover the video source information and port number from the air interface data;

[0142] S905: Update ARSP data timestamp;

[0143] S906: Determine whether the ARSP data has been processed; if so, go to S907; if not, go to S901;

[0144] S907: Determine whether isARSP is true; if true, go to S901; if not, go to S908;

[0145] S908: Search for an ARSP data table entry that meets the following conditions: the video source IP is the same as the destination IP, and the video source video port is the same as the destination port; if found, go to S909; if not found, go to S910;

[0146] S909: mark the ARSP data flag isARSP as false;

[0147] S910: Determine whether the ARSP table is empty; if it is empty, go to S911; if not empty, go to S912;

[0148] S911: Clear the ARSP data flag isARSP and jump to 901;

[0149] S912: Insert the ARSP data into the ARSP table entry.

[0150] S1000: The process ends.

[0151] On the other hand, the present invention further provides a system for reducing RTSP multi-channel concurrency, which is used to implement the method for reducing RTSP multi-channel concurrency in the above preferred embodiment.

[0152] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the processor executes the method provided by the above embodiments, the method comprising: receiving a data packet from a network port; checking whether the data packet is an RTSP data packet; if so, checking the RTSP type of the RTSP data packet to determine whether it is an RTSP request; if it is not an RTSP data packet, checking whether there is a table entry corresponding to the video source IP in the service table; checking the RTSP type of the RTSP data packet to determine whether it is an RTSP request; if it is an RTSP request, creating or updating the service table according to the IP of the video source; if it is not an RTSP request but an RTSP response, recording the port number and updating the service table; updating the timestamp of the corresponding applicant in the service table; continuing to receive the next data packet; processing the RTP data packet to check whether the service table There is a table entry corresponding to the video source IP; if it exists, check whether it is the first time to request data; if it is the first request, retain the data and send it to the server through the air interface; if it does not exist or it is not the first request, discard the data; after receiving the client's request, the server performs a timeout check; if the applicant's timestamp is not updated for more than 3 seconds, move other applicants to the first position of the structure; perform a 10-second timeout check: if the applicant's timestamp is not updated for more than 10 seconds, delete the applicant's table entry; perform a 30-second timeout check if there is no applicant for the video source for more than 30 seconds, delete the table entry of the corresponding camera; when the video source processing receives data, only the first video data is retained; if necessary, modify the destination ID and identifier, and ensure that they correspond one to one; the player processing receives data from the air interface; determines whether the data is ARSP data; if it is ARSP data, restores the IP address and port number; the process ends.

[0153] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0154] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0155] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

[0156] The above description is only an exemplary embodiment of the present invention, and does not limit the patent scope of the present invention. All equivalent structural changes made by using the contents of the present invention and the drawings under the technical concept of the present invention, or directly / indirectly applied in other related technical fields are included in the patent protection scope of the present invention.

Claims

1. A method for reducing RTSP multi-channel concurrency, characterized in that: The method comprises the following steps: S100: receives data packets from the network port; S200: Check whether the data packet is an RTSP data packet; if so, go to S300; if not, go to S600; S300: Check the RTSP type of the RTSP data packet to determine whether it is an RTSP request; if it is an RTSP request, create or update the service table according to the IP of the video source; if it is not an RTSP request but an RTSP response, record the port number and update the service table; S400: Update the timestamp of the corresponding applicant in the business table; S500: Continue to receive data and return to S100 to continue receiving the next data packet; S600: Process the RTP data packet to check whether there is an entry corresponding to the video source IP in the service table; if so, check whether it is the first request for data; if it is the first request, retain the data and send it to the server through the air interface; if it does not exist or it is not the first request, discard the data; S700: After receiving the request from the client, the server performs a timeout check; if the applicant's timestamp is not updated for more than n1 seconds, move other applicants to the first position of the structure; perform a timeout check for n2 seconds: if the applicant's timestamp is not updated for more than n2 seconds, delete the applicant's entry; perform a timeout check for n3 seconds: if there is no applicant for the video source for more than n3 seconds, delete the entry for the corresponding camera, n1 <n2<n3; S800: when receiving data, the video source processing only retains the first channel of video data; S900: The player processes the data received from the air interface; determines whether the data is ARSP data; if it is ARSP data, restores the IP address and port number; S1000: The process ends.

2. The RTSP multi-channel concurrent reduction according to claim 1, characterized in that: The processing of the RTSP data packet in step S300 comprises the following steps: S301: Mark the RTP data as a request and obtain the video source IP and port number; S302: Check whether there is an entry applicant corresponding to the video source IP in the service table; if so, go to S303; if not, go to S304; S303: Check whether the port number is zero, if the port number is not zero, go to S307; if it is zero, go to S305; S304: Adding a service entry; S305: Apply for a timestamp, and update the timestamp of the corresponding applicant; S306: Adding an ARSP table entry; S307: Update the port number of the corresponding applicant and add an ARSP table entry.

3. The method for reducing RTSP multi-channel concurrency according to claim 1 or 2, characterized in that: When the timestamp is updated in step S400, the time difference is updated first, and then the timestamp is updated according to the time difference; The time difference is the current time minus the time of the last update timestamp in the applicant table entry. After the update is completed, it is necessary to continue to check whether to perform n3 seconds, n2 seconds, and n1 seconds timeout checks.

4. The method for reducing RTSP multi-channel concurrency according to any one of claims 1 to 3, characterized in that: Processing the RTP data packet in step S600 includes the following steps: S601: Add a data table entry. If it is the first request data, save the data and send it through the air interface; if not, discard the data; S602: Check whether the ARSP table entry is empty; if not, send ARSP data; if empty, go to S603; S603: Check whether it is necessary to send ARSP data; if the data table entry is empty, it does not need to be sent; if it is not empty, calculate the ARSP table entry number to be deleted; S604: Delete the ARSP table entry and the corresponding applicant table entry, and update firstIndex; S605: Update the ARSP entry timestamp; S606: Check whether it is necessary to send ARSP data. If the data table entry is empty, it is not necessary to send it. If it is not empty, calculate the index of the ARSP data to be sent. S607: Recover the IP address and port number from the corresponding ARSP table entry; S608: Check whether there is an applicant for the video source: if there is an applicant for the video source, delete the ARSP table entry; if not, go to S609; S609: Send the corresponding ARSP data packet.

5. The method for reducing RTSP multi-channel concurrency according to claim 4, characterized in that: In step S603, the number of the ARSP entry to be deleted is calculated, including the following steps: Mark the deletion position firstIndex, which is set to 0 by default; find the ARSP table entry position that meets the following two conditions: the difference between the time difference and the current time difference is greater than n1 seconds; the difference between the application time and the current time is greater than n1 seconds; Update firstIndex; if the location is found, go to S604; if not found, go to S605.

6. The method for reducing RTSP multi-channel concurrency according to claim 4, characterized in that: In step S606, the specific calculation method of the ARSP data index includes the following steps: Mark the sending position sendIndex, the default setting is 0; Calculate the sending time difference: the difference between the sending time and the current time; Find the ARSP table entry position that meets the following two conditions: the difference between the time difference and the sending time difference is greater than n1 seconds; the difference between the application time and the sending time is greater than n1 seconds, and update sendIndex; If the location is found, go to S607; if not found, go to S607; S607: Recover the IP address and port number from the corresponding ARSP table entry; S608: Check whether there is an applicant for the video source: if there is an applicant for the video source, delete the ARSP table entry; if not, go to S609; S609: Send the corresponding ARSP data packet.

7. The method for reducing RTSP multi-channel concurrency according to any one of claims 1 to 6, characterized in that: The video source processing in step S800 includes the following steps: S801: mark the send flag sendFlag, which is initialized to false by default; S802: Determine whether RTSP control information is received. If received, go to S803; if not received, check sendFlag: if it is true, send the corresponding RTP data to the air interface; if it is false, go to S806; S803: mark the send flag sendFlag as true; S804: Determine whether the applicant is a live video source; if it is a live video source, directly set the send flag sendFlag to false, and go to S809; if it is not a live video source, continue to determine whether it is a multicast source, and go to S805; S805: Determine whether it is a multicast source, and directly proceed to S806; S806: Add video source data table entry; S807: Check whether the video source data table is empty; if it is empty, go to S808; if it is not empty, go directly to S809; S808: Check whether the data source needs to be modified; if it needs to be modified, go to S809; S809: Data type and length determination, go to S810; S810: modify the destination ID and identifier, and go to S809; S811: Determine whether the data has been processed; if so, go to S909; if not, go to S802.

8. The method for reducing RTSP multi-channel concurrency according to any one of claims 1 to 7, characterized in that: The player processing in step S900 includes the following steps: S901: The player receives data through the air interface; S902: Determine whether the data is ARSP data; if yes, go to S903; if not, go to S907; S903: Mark the ARSP data flag isARSP as true; S904: Recover the video source information and port number from the air interface data; S905: Update the ARSP data timestamp; S906: Determine whether the ARSP data has been processed; if it has been processed, go to S907; if not, go to S901; S907: Determine whether isARSP is true; if true, go to S901; if not, go to S908; S908: Search for an ARSP data table entry that meets the following conditions: the video source IP is the same as the destination IP, and the video source video port is the same as the destination port; if found, go to S909; if not found, go to S910; S909: mark the ARSP data flag isARSP as false; S910: Determine whether the ARSP table is empty; if it is empty, go to S911; if not empty, go to S912; S911: Clear the ARSP data flag isARSP and jump to S901; S912: Insert the ARSP data into the ARSP table entry.

9. A system for reducing RTSP multi-channel concurrency, characterized in that: The system is used to implement the method for reducing RTSP multi-channel concurrency according to any one of claims 1 to 8.

Images