A method for processing communication protocol data for space applications

Abstract

The present invention provides a method for processing communication protocol data for space applications, which can receive input communication information. The communication information includes N interconnected source packet data areas, and any source packet data area includes P interconnected initial data packets transmitted based on the RTP protocol. Each initial data packet included in any source packet data area is preprocessed to convert the data in each initial data packet included in any source packet data area into a hexadecimal format. Based on the communication information, N cycles are executed to obtain a code stream corresponding to the communication information. When the code stream corresponding to the communication information meets the preset push stream condition, the code stream corresponding to the communication information is pushed to the target device to display the relevant content of the code stream corresponding to the communication information based on the target device. The present invention can locate and restore the initial RTP data packet in the disordered RTP data in real time to ensure the orderly transmission of the RTP data packet.

Description

Technical Field

[0001] The present invention relates to the field of space application technology, and in particular to a method for processing communication protocol data oriented to space applications. Background Art

[0002] Real-time Transport Protocol (RTP) is a network protocol for processing multimedia data streams on the Internet. It can be used to achieve real-time transmission of multimedia data in a one-to-one or one-to-many network environment. Multimedia data transmitted in real time based on RTP can also be called RTP data. In the transmission process of RTP data, the sender and the receiver both send and receive a complete packet of RTP data. That is, the starting byte of the data sent by the sender at one time must be the beginning of RTP.

[0003] Since RTP is a protocol that defines the data format, RTP cannot provide a reliable transmission mechanism for sequentially transmitting RTP packets, nor can it provide flow control or congestion control for the transmission process. In other words, the orderly transmission of RTP packets cannot be ensured based on RTP. To address this problem, the Real-time Transport Control Protocol (RTCP) can be used to ensure the orderly transmission of RTP packets.

[0004] However, in space applications, since space-to-earth communications have their own unique protocols, the RTCP protocol cannot be used to transmit RTP packets in an orderly manner. Several initial RTP packets can only be spliced ​​together, cut at a fixed length, and put into a packet that complies with the space-to-earth communication protocol. In this application scenario, how to restore several mixed RTP data (disordered RTP data) spliced ​​together in real time back to the initial RTP data packet that complies with the RTP format is an urgent problem to be solved. Summary of the invention

[0005] The technical problem to be solved by the present invention is to provide a method for processing communication protocol data for space applications, which can locate and restore the initial RTP data packet in real time in the out-of-order RTP data to ensure the orderly transmission of the RTP data packet.

[0006] The technical solution of the present invention to solve the above technical problems is as follows:

[0007] In a first aspect, the present invention provides a method for processing communication protocol data for space applications, comprising:

[0008] Receive input communication information; the communication information includes N interconnected source packet data areas, N ≥ 2 and N is a positive integer; for any of the N interconnected source packet data areas, the any source packet data area includes P interconnected initial data packets transmitted based on the RTP protocol, P ≥ 1. Preprocess each initial data packet included in any of the source packet data areas to convert the data in each initial data packet included in any of the source packet data areas into a hexadecimal format. Based on the communication information, execute N loops to obtain a code stream corresponding to the communication information. When the code stream corresponding to the communication information meets the preset push stream conditions, push the code stream corresponding to the communication information to the target device to display the relevant content of the code stream corresponding to the communication information based on the target device. Wherein, in the first loop of the N loops, it includes:

[0009] Traverse the first traversal area included in the first source packet data area of ​​the N interconnected source packet data areas. The first traversal area includes the first byte to the 12th byte from the end of the corresponding data area. For any first target byte of at least one first target byte traversed in the first traversal area included in the first source packet data area, if it is determined that the next byte of any first target byte is the same as the second preset byte, obtain the byte to be checked corresponding to the any first target byte; the first target byte is the byte that is the same as the first preset byte in the first traversal area included in the first source packet data area; the byte to be checked is the 9th byte to the 12th byte after the corresponding byte.

[0010] If no historical byte group with the byte to be checked corresponding to any first target byte as a tag is detected in the first cache, a byte group corresponding to any first target byte is created in the first cache with the byte to be checked corresponding to any first target byte as a tag; if the historical byte group with the byte to be checked corresponding to any first target byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any first target byte as a tag is taken out from the first cache and stored in the second cache; the code stream corresponding to the communication information is determined based on the content included in the second cache;

[0011] All bytes traversed from any first target byte are stored in the byte group corresponding to the any first target byte, and, when the first cache includes at least one historical byte group, for any historical byte group in the at least one historical byte group, all bytes traversed from any first target byte are stored after the last byte included in the any historical byte group.

[0012] Traverse the second traversal area included in the first source packet data area. The second traversal area includes the 11th to the second to last bytes of the corresponding data area. For any second target byte of at least one second target byte traversed in the second traversal area included in the first source packet data area, if it is determined that the next byte of any second target byte is the same as the second preset byte, then determine the any second target byte as the first positioning byte in the first source packet data area; the second target byte is the byte that is the same as the first preset byte in the second traversal area included in the first source packet data area. Record the byte position of the first positioning byte included in the first source packet data area in the first source packet data area to the first list.

[0013] The penultimate byte included in the first source packet data area is read. If the penultimate byte included in the first source packet data area is the same as the first preset byte, the penultimate byte included in the first source packet data area is determined as the second positioning byte in the first source packet data area. The byte position of the second positioning byte included in the first source packet data area in the first source packet data area is recorded in the second list.

[0014] Based on the above technical solution, the present invention can also be improved as follows.

[0015] Further, in the Mth loop of the N loops, 2≤M≤N and M is a positive integer, including:

[0016] The (M-1)th source packet data area of ​​the N interconnected source packet data areas is spliced ​​before the Mth source packet data area to obtain a first spliced ​​data area. The first list is traversed, and if the first list includes the byte corresponding to at least one first positioning byte in the (M-1)th source packet data area, for any first positioning byte in the at least one first positioning byte, a byte to be checked corresponding to the any first positioning byte is obtained in the (M-1)th source packet data area.

[0017] If a historical byte group with a byte to be checked corresponding to any first positioning byte as a label is not detected in the first cache, a byte group corresponding to any first positioning byte is created in the first cache with the byte to be checked corresponding to any first positioning byte as a label; if a historical byte group with a byte to be checked corresponding to any first positioning byte as a label is detected in the first cache, the historical byte group with a byte to be checked corresponding to any first positioning byte as a label is taken out from the first cache and stored in the second cache.

[0018] All bytes traversed from any first positioning byte are stored in the byte group corresponding to the any first positioning byte, and, in the case where at least one historical byte group is included in the first cache, for any historical byte group in the at least one historical byte group, all bytes traversed from any first positioning byte are stored after the last byte included in the any historical byte group.

[0019] Traverse the second list. If the second list includes the byte corresponding to the second positioning byte in the (M-1)th source packet data area, and the next byte of the second positioning byte in the (M-1)th source packet data area in the first spliced ​​data area is the same as the second preset byte, then obtain the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area.

[0020] If a historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is not detected in the first cache, a byte group corresponding to the second positioning byte in the (M-1)th source packet data area is created in the first cache with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label; if a historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is detected in the first cache, the historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is taken out from the first cache and stored in the second cache.

[0021] All bytes traversed from the second positioning byte in the (M-1)th source packet data area are stored in the byte group corresponding to the second positioning byte in the (M-1)th source packet data area, and, when the first cache includes at least one historical byte group, for any historical byte group in the at least one historical byte group, all bytes traversed from the second positioning byte in the (M-1)th source packet data area are stored after the last byte included in any historical byte group.

[0022] The first traversal area included in the first spliced ​​data area is traversed. For any third target byte of at least one third target byte traversed in the first traversal area included in the first spliced ​​data area, if it is determined that the next byte of the any third target byte is the same as the second preset byte, the byte to be checked corresponding to the any third target byte is obtained; the third target byte is the byte that is the same as the first preset byte in the first traversal area included in the first spliced ​​data area.

[0023] If a historical byte group with a byte to be checked corresponding to any third target byte as a label is not detected in the first cache, a byte group corresponding to any third target byte is created in the first cache with the byte to be checked corresponding to any third target byte as a label; if a historical byte group with a byte to be checked corresponding to any third target byte as a label is detected in the first cache, the historical byte group with a byte to be checked corresponding to any third target byte as a label is taken out from the first cache and stored in the second cache.

[0024] All bytes traversed from any third target byte are stored in the byte group corresponding to any fourth target byte, and, when at least one historical byte group is included in the first cache, for any historical byte group in the at least one historical byte group, all bytes traversed from any third target byte are stored after the last byte included in the any historical byte group.

[0025] Clear the first list. Traverse the second traversal area included in the Mth source packet data area. For any fourth target byte of at least one fourth target byte traversed in the second traversal area included in the Mth source packet data area, if it is determined that the next byte of any fourth target byte is the same as the second preset byte, then determine the any fourth target byte as the first positioning byte in the Mth source packet data area; the fourth target byte is the byte that is the same as the first preset byte in the second traversal area included in the Mth source packet data area. Record the byte position of the first positioning byte in the Mth source packet data area to the first list. Clear the second list. Read the last byte included in the Mth source packet data area. If the last byte included in the Mth source packet data area is the same as the first preset byte, then determine the last byte included in the Mth source packet data area as the second positioning byte in the Mth source packet data area. Record the byte position of the second positioning byte in the Mth source packet data area in the Mth source packet data area to the second list.

[0026] Further, after creating the target byte group in the first cache, the target byte group becomes a historical byte group in the first cache; the target byte group includes at least one of a byte group corresponding to any first target byte, a byte group corresponding to any first positioning byte, a byte group corresponding to the second positioning byte in the (M-1)th source packet data area, and a byte group corresponding to any third target byte.

[0027] Further, when it is detected that the number of bytes in any historical byte group included in the first cache exceeds a preset number, any historical byte group included in the first cache is deleted.

[0028] Further, before traversing the second traversal area included in the first source packet data area, the first list is cleared.

[0029] Further, before reading the last byte included in the data area of ​​the first source packet, the second list is cleared, and the second list is different from the first list.

[0030] Furthermore, the first preset byte is different from the second preset byte.

[0031] Further, for any initial data packet included in any source packet data area, data in any initial data packet is converted into a hexadecimal format.

[0032] Further, based on any historical byte group stored in the second cache, a code stream corresponding to any historical byte group stored in the second cache is obtained. Based on the code streams corresponding to each historical byte group stored in the second cache, a code stream corresponding to the communication information is obtained.

[0033] Further, based on the payload type of any historical byte group stored in the second cache, bytes included in any historical byte group stored in the second cache are parsed into an H.264 code stream or an H.265 code stream.

[0034] The beneficial effects of the present invention are: solving the problem of locating the RTP protocol header in a scenario where the initial data packets transmitted based on the RTP protocol are spliced ​​in sequence and cut according to a specified length, expanding the real-time playback of RTP audio and video data in the streaming media protocol in space application scenarios, and improving playback efficiency.

[0035] In a second aspect, the present invention provides a system for processing communication protocol data for space applications, which is used to execute the method for processing communication protocol data for space applications as described in any one of the first aspects above.

[0036] In a third aspect, the present invention provides an electronic device comprising: a memory, one or more processors; the memory and the processor are coupled; wherein the memory stores computer program code, the computer program code comprises computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method for processing communication protocol data for space applications as described in any one of the first aspects above.

[0037] In a fourth aspect, a computer-readable storage medium is provided, comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method for processing communication protocol data for space applications as described in any one of the first aspects.

[0038] In a fifth aspect, a computer program product is provided. When the computer program product runs on a computer, it enables the computer to execute the method for processing communication protocol data for space applications as described in any one of the first aspects above.

[0039] It can be understood that the beneficial effects that can be achieved by the method for processing communication protocol data for space applications of the second aspect provided above, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, and the computer program product described in the fifth aspect can refer to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A schematic diagram of the structure of an RTP protocol provided by the present invention;

[0041] Figure 2 A schematic diagram of the structure of a data packet transmitted based on the RTP protocol provided by the present invention;

[0042] Figure 3 A schematic diagram of several source packet data areas provided by the present invention;

[0043] Figure 4 A schematic diagram of step 1 of the first cycle provided by the present invention;

[0044] Figure 5 A schematic diagram of step 2 of the first cycle provided by the present invention;

[0045] Figure 6 A schematic diagram of step three of the first cycle provided by the present invention;

[0046] Figure 7 A schematic diagram of step 1 of the Mth cycle provided by the present invention;

[0047] Figure 8 A schematic diagram of step 2 of the Mth cycle provided by the present invention;

[0048] Fig. 9 A schematic diagram of step three of the Mth cycle provided by the present invention;

[0049] Fig.10 Schematic diagram of step 4 of the Mth cycle provided by the present invention. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in the present application is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. And, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish between the same items or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not necessarily limit the differences. At the same time, in the embodiments of the present application, the words "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design.

[0051] Before introducing the embodiments of the present disclosure, the professional contents involved in the embodiments of the present disclosure are explained as follows:

[0052] Computer file size unit: All data in the computer is composed of 0 and 1, one 0 or 1 represents 1 bit, that is, 1 bit. Among them, 8 bits equals 1 byte, that is, 1 Byte.

[0053] Combine the following Figure 1 , introduce the structure of the RTP protocol:

[0054] Version number (V): 2 bits, used to mark the RTP version used.

[0055] Padding bit (P): 1 bit. If this bit is set, the end of the RTP packet contains additional padding bytes.

[0056] Extension bit (X): 1 bit. If this bit is set, an extension header will follow the RTP fixed header.

[0057] CSRC counter (CSRC, referred to as CC): 4 bits, containing the number of CSRCs following the fixed header.

[0058] Mark bit (M): 1 bit. The interpretation of this bit is borne by the configuration document (Profile).

[0059] Payload type (PT): 7 bits, identifies the type of RTP payload, that is, whether the data is an H.264 stream or an H.265 stream.

[0060] Sequence Number (SN): 16 bits. The sender increases the value of this field by 1 after each RTP packet is sent. The receiver can use this field to detect packet loss and restore the packet sequence. The initial value of the sequence number is random.

[0061] Timestamp: 32 bits, records the sampling time of the first byte of the data in the packet. At the beginning of a session, the timestamp is initialized to an initial value. Even when no signal is sent, the value of the timestamp will continue to increase over time (time is passing). The timestamp is indispensable for removing jitter and achieving synchronization.

[0062] Synchronization source identifier (SSRC): 32 bits, the synchronization source refers to the source of the RTP packet stream. There cannot be two identical SSRC values ​​in the same RTP session. The identifier is randomly selected. RFC1889 recommends the MD5 random algorithm.

[0063] Contribution Source List (CSRC List): 0 to 15 items, each 32 bits, used to mark the sources of all RTP packets that contribute to a new packet generated by an RTP mixer. The mixer inserts these contributing SSRC identifiers into the table. The SSRC identifiers are listed so that the receiving end can correctly identify the two parties in the conversation.

[0064] Combine the following Figure 2 , introduce the data packet structure based on RTP protocol transmission:

[0065] Device ID: The unique ID of the space station payload video acquisition device. Different devices generate video data with different encoding formats, bit rates, and resolutions.

[0066] Packet sequence number (sequenceNo): The packet sequence number of the source packet collected by each device each time it is turned on increases from 0 to 0x7FFF and then rolls over to 0;

[0067] Time code: the time when each payload source packet is collected on the space station, in microseconds;

[0068] Valid length: the length of valid data in the data field;

[0069] Data domain: The data domain stores the RTP protocol data stream;

[0070] CRC: CRC checksum.

[0071] In some embodiments, when the transmitting device sends audio and video data to the receiving device, it will end and splice several initial data packets (also referred to as RTP data packets or initial RTP data packets in the embodiments of the present application) corresponding to the audio and video data to be sent based on the packet sequence number and / or time code based on the RTP protocol to obtain communication information. After that, the transmitting device sends the communication information to the receiving device. After receiving the input communication information, the receiving device can cut the content included in the communication information to obtain the following information: Figure 3 The N source packet data areas shown are interconnected and of equal length, wherein N≥2 and N is a positive integer.

[0072] In this case, one or two of the initial data packets included in the source packet data area may be incomplete due to being cut. That is, any source packet data area includes P interconnected initial data packets transmitted based on the RTP protocol, P≥1, and P can be an integer or a fraction.

[0073] In some embodiments, each initial data packet included in any source packet data area can be preprocessed to convert the data in each initial data packet into a hexadecimal format. Afterwards, N loops can be performed based on the communication information to obtain a code stream corresponding to the communication information. When the code stream corresponding to the communication information meets the preset push stream conditions, the code stream corresponding to the communication information can be pushed to the target device to display the relevant content of the code stream corresponding to the communication information based on the target device (for example, an audio and video playback device included in the receiving device, or other audio and video playback devices independent of the receiving device) (for example, the playback audio and video corresponding to the communication information).

[0074] In some embodiments, based on the RTP protocol, it can be known that the 1-2 bits of the RTP protocol are the version number. In this scenario, the fixed bit version number is 2, that is, 10 in binary. The next 1 bit is the fill bit, which may be 0 or 1. The 4th bit extension bit may also be 0 or 1. The 5th to 8th bits are the CSRC counter, which is fixed to 0000 in this scenario. Since 8 bits are equal to 1 byte, the first byte of any initial data packet includes the following four cases: 10000000, 10100000, 10010000, and 10110000. Among them, the hexadecimal corresponding to 10000000 is 0x80; the hexadecimal corresponding to 10100000 is 0xA0; the hexadecimal corresponding to 10010000 is 0x90, and the hexadecimal corresponding to 1011 0000 is 0xB0. That is to say, the hexadecimal corresponding to the first byte of any initial data packet is any one of 0x80, 0xA0, 0x90, and 0xB0.

[0075] In addition, the 9th bit of the RTP protocol is a marker bit, which may be 0 or 1. The 10th to 16th bits of the RTP protocol are recorded as the payload type, and the payload type of the RTP protocol is fixedly represented as 110 0000 or 111 0000 in this scenario. Therefore, the second byte of any initial data packet includes the following four cases: 01100000, 01110000, 11100000, and 11110000. Among them, the hexadecimal corresponding to 01100000 is 0x60; the hexadecimal corresponding to 01110000 is 0x70; the hexadecimal corresponding to 11100000 is 0xE0; and the hexadecimal corresponding to 11110000 is 0xF0. In other words, the hexadecimal corresponding to the second byte of any initial data packet is any one of 0x60, 0x70, 0xE0, and 0xF0.

[0076] In some embodiments, the first preset byte may be set to include 0x80, 0xA0, 0x90, 0xB0, and the second preset byte may be set to include 0x60, 0x70, 0xE0, 0xF0. If there is a target byte identical to the first preset byte in any source packet data area, that is, the target byte is equal to any one of 0x80, 0xA0, 0x90, 0xB0, and the next byte of the target byte is identical to the second preset byte, that is, the next byte of the target byte is equal to any one of 0x60, 0x70, 0xE0, 0xF0, then it indicates that the target byte may be a protocol header corresponding to an initial data packet.

[0077] The present invention can execute N cycles on the bytes in the data area of ​​each source packet included in the communication information based on the first preset byte and the second preset byte to obtain a code stream corresponding to the communication information.

[0078] Combine the following Figure 4 , describing in detail the steps of executing the first cycle among N cycles in an embodiment of the present invention.

[0079] In some embodiments, the first traversal area included in the first source packet data area of ​​the N interconnected source packet data areas may be traversed. The first traversal area includes the first byte to the 12th last byte of the corresponding data area. In other words, the first traversal area included in the first source packet data area includes the first byte to the 12th last byte of the first source packet data area.

[0080] If a certain byte traversed in the first traversal area included in the first source packet data area is the same as the first preset byte, the byte can be determined as the first target byte. Afterwards, if it is determined that the next byte of the first target byte is the same as the second preset byte, the byte to be checked corresponding to the first target byte can be obtained.

[0081] It should be noted that the bytes to be checked in the present invention are the 9th to 12th bytes after the corresponding bytes. For example, the bytes to be checked corresponding to the first target byte are the 9th to 12th bytes after the first target byte. Based on the above introduction to the RTP protocol, it can be known that the 9th to 12th bytes in the RTP protocol header are SSRC. Since the SSRC of the same RTP stream is consistent, it is possible to determine whether the first target byte is the protocol header corresponding to a certain initial data packet based on whether the bytes to be checked corresponding to the first target byte appear repeatedly in the subsequent period.

[0082] In some embodiments, if a historical byte group with a byte to be checked corresponding to any first target byte as a tag is not detected in the first cache, a byte group corresponding to any first target byte is created in the first cache with the byte to be checked corresponding to the first target byte as a tag.

[0083] In some embodiments, if a historical byte group tagged with the byte to be checked corresponding to any first target byte is detected in the first cache, the historical byte group tagged with the byte to be checked corresponding to any first target byte is taken out from the first cache and stored in the second cache.

[0084] It should be noted that after any byte group (for example, a target byte group) is created in the first cache, the target byte group becomes a historical byte group in the first cache.

[0085] In some embodiments, all bytes traversed starting from any first target byte can be stored in the byte group corresponding to any first target byte in the first cache, and, when at least one historical byte group is included in the first cache, for any historical byte group in the at least one historical byte group, all bytes traversed starting from any first target byte are stored after the last byte included in any historical byte group.

[0086] Exemplarily, the data in the first traversal area included in the first source packet data area can be 0x800x60 (6 bytes omitted) SSRC13423110x900x60 (6 bytes omitted) SSRC2468465161840x800x70 (6 bytes omitted) SSRC346486854684564850x800xF0 (6 bytes omitted) SSRC216516150xA00x60 (6 bytes) SSRC415645616315.

[0087] If both the first cache and the second cache are empty before traversing the first traversal area, then during the traversal of the first traversal area, since 0x80 is the same as the first preset byte and 0x60 is the same as the second preset byte, the 9th to 12th bytes SSRC1 after 0x800x60 can be determined as the bytes to be checked corresponding to 0x800x60. Since the first cache is empty, that is, there is no historical byte group with SSRC1 as the label in the first cache, therefore, a historical byte group 1 can be created in the first cache with SSRC1 as the label, and all bytes traversed from 0x800x60 are stored in the historical byte group 1.

[0088] Among them, before traversing to 0x900x60, the data stored in the first cache is:

[0089] Historical byte group 1 (SSRC1): 0x800x60 (6 bytes omitted) SSRC1342311.

[0090] When traversing to 0x900x60, since 0x90 is the same as the first preset byte and 0x60 is the same as the second preset byte, the 9th to 12th bytes SSRC2 after 0x900x60 can be determined as the bytes to be checked corresponding to 0x900x60. Since there is no historical byte group with SSRC2 as the label in the first cache, historical byte group 2 can be created in the first cache with SSRC2 as the label, and all bytes traversed from 0x900x60 are stored in historical byte group 1.

[0091] Before traversing 0x800x70, the data stored in the first cache is:

[0092] Historical byte group 1 (SSRC1): 0x800x60 (6 bytes omitted) SSRC13423110x900x60 (6 bytes omitted) SSRC246846516184;

[0093] Historical byte group 2 (SSRC2): 0x900x60 (6 bytes omitted) SSRC246846516184.

[0094] When traversing to 0x800x70, since 0x80 is the same as the first preset byte and 0x70 is the same as the second preset byte, the 9th to 12th bytes SSRC3 after 0x800x70 can be determined as the bytes to be checked corresponding to 0x800x70. Since there is no historical byte group with SSRC3 as the label in the first cache, historical byte group 3 can be created in the first cache with SSRC3 as the label, and all bytes traversed from 0x800x70 are stored in historical byte group 1.

[0095] Before traversing 0x800xF0, the data stored in the first cache is:

[0096] Historical byte group 1 (SSRC1): 0x800x60 (6 bytes omitted) SSRC13423110x900x60 (6 bytes omitted) SSRC2468465161840x800x70 (6 bytes omitted) SSRC34648685468456485;

[0097] Historical byte group 2 (SSRC2): 0x900x60 (6 bytes omitted)SSRC2468465161840x800x70 (6 bytes omitted)SSRC34648685468456485.

[0098] Historical byte group 3 (SSRC3): 0x800x70 (6 bytes omitted) SSRC34648685468456485.

[0099] When traversing to 0x800xF0, since 0x80 is the same as the first preset byte and 0xF0 is the same as the second preset byte, the 9th to 12th bytes SSRC2 after 0x800xF0 can be determined as the bytes to be checked corresponding to 0x800xF0. Since the first cache includes the historical byte group 2 with SSRC2 as the label, the historical byte group 2 with SSRC2 as the label can be taken out from the first cache and stored in the second cache. In addition, create the historical byte group 4 in the first cache with SSRC2 as the label, and store all bytes traversed from 0x800xF0 into the historical byte group 1.

[0100] Before traversing 0xA00x60, the data stored in the first cache is:

[0101] Historical byte group 1 (SSRC1): 0x800x60 (6 bytes omitted) SSRC13423110x900x60 (6 bytes omitted) SSRC2468465161840x800x70 (6 bytes omitted) SSRC346486854684564850x800xF0 (6 bytes omitted) SSRC21651615;

[0102] Historical byte group 3 (SSRC3): 0x800x70 (6 bytes omitted) SSRC346486854684564850x800xF0 (6 bytes omitted) SSRC21651615

[0103] Historical byte group 3 (SSRC2): 0x800xF0 (6 bytes omitted) SSRC21651615.

[0104] In some embodiments, after completing the traversal of the first traversal area included in the first source packet data area, see Figure 5 , the first list can be cleared. After that, the second traversal area included in the first source packet data area can be traversed. The second traversal area includes the 11th to the second to last byte of the corresponding data area. In other words, the first traversal area included in the first source packet data area includes the 11th to the second to last byte of the first source packet data area.

[0105] In some embodiments, for any second target byte traversed in the second traversal area included in the first source packet data area, if it is determined that the next byte of the any second target byte is the same as the second preset byte, the any second target byte is determined as the first positioning byte in the first source packet data area. Afterwards, the byte position of the first positioning byte included in the first source packet data area in the first source packet data area can be recorded in the first list.

[0106] The second target byte is a byte that is the same as the first preset byte in the second traversal area included in the first source packet data area.

[0107] In some embodiments, after completing the traversal of the second traversal area included in the first source packet data area, see Figure 6, the second list can be cleared. Afterwards, the penultimate byte included in the first source packet data area can be read. If the penultimate byte included in the first source packet data area is the same as the first preset byte, the penultimate byte is determined as the second positioning byte in the first source packet data area. The byte position of the second positioning byte included in the first source packet data area in the first source packet data area can be recorded in the second list. The second list is different from the first list.

[0108] It can be seen that after executing the first cycle, the first list and the second list both store corresponding contents. The first cache and the second cache both store corresponding contents. The contents stored in the second cache can be used to determine the code stream corresponding to the communication information.

[0109] The steps of executing the Mth loop among N loops in the embodiment of the present invention are described in detail below, where 2≤M≤N and M is a positive integer.

[0110] In some embodiments, see Figure 7 , the (M-1)th source packet data area among the N mutually connected source packet data areas may be spliced ​​before the Mth source packet data area to obtain a first spliced ​​data area. Afterwards, the first list may be traversed.

[0111] If the first list includes byte positions corresponding to at least one first positioning byte in the (M-1)th source packet data area, then for any first positioning byte, the byte to be checked corresponding to the any first positioning byte is obtained in the (M-1)th source packet data area, wherein the byte to be checked corresponding to the any first positioning byte is the 9th byte to the 12th byte after the any first positioning byte in the first splicing data area.

[0112] If no historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is detected in the first cache, a byte group corresponding to any first positioning byte is created in the first cache with the byte to be checked corresponding to any first positioning byte as a tag.

[0113] If a historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is taken out from the first cache and stored in the second cache.

[0114] In some embodiments, all bytes traversed from any first positioning byte can be stored in the byte group corresponding to the any first positioning byte, and, when at least one historical byte group is included in the first cache, all bytes traversed from any first positioning byte are stored after the last byte included in each historical byte group.

[0115] In some embodiments, see Figure 7 After completing the traversal of the first list, you can also traverse the second list.

[0116] If the second list includes the byte corresponding to the second positioning byte in the (M-1)th source packet data area, and the next byte of the second positioning byte in the (M-1)th source packet data area in the first spliced ​​data area is the same as the second preset byte, then the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area is obtained.

[0117] If a historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is not detected in the first cache, a byte group corresponding to the second positioning byte in the (M-1)th source packet data area is created in the first cache with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label.

[0118] If a historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is detected in the first cache, the historical byte group with the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area as a label is taken out from the first cache and stored in the second cache.

[0119] In some embodiments, all bytes traversed starting from the second positioning byte in the (M-1)th source packet data area can be stored in the byte group corresponding to the second positioning byte in the (M-1)th source packet data area, and, when at least one historical byte group is included in the first cache, all bytes traversed starting from the second positioning byte in the (M-1)th source packet data area are stored after the last byte included in each historical byte group.

[0120] In some embodiments, after completing the traversal of the second list, see Figure 8 , and the first traversal area included in the first spliced ​​data area can also be traversed.

[0121] Among them, for any third target byte traversed in the first traversal area included in the first spliced ​​data area, if it is determined that the next byte of the any third target byte is the same as the second preset byte, then the byte to be checked corresponding to the any third target byte is obtained. The third target byte is the byte that is the same as the first preset byte in the first traversal area included in the first spliced ​​data area.

[0122] If no historical byte group with the byte to be checked corresponding to any third target byte as a tag is detected in the first cache, the byte group corresponding to any third target byte is created in the first cache with the byte to be checked corresponding to any third target byte as a tag. If a historical byte group with the byte to be checked corresponding to any third target byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any third target byte as a tag is taken out from the first cache and stored in the second cache.

[0123] In some embodiments, all bytes traversed from any third target byte can also be stored in the byte group corresponding to any fourth target byte, and, when at least one historical byte group is included in the first cache, all bytes traversed from any third target byte can be stored after the last byte included in each historical byte group.

[0124] In some embodiments, after completing the traversal of the first spliced ​​data area, see Fig. 9 , and the first list can also be cleared. Afterwards, the second traversal area included in the Mth source packet data area is traversed.

[0125] For any fourth target byte traversed in the second traversal area included in the Mth source packet data area, if it is determined that the next byte of the any fourth target byte is the same as the second preset byte, then the any fourth target byte is determined as the first positioning byte in the Mth source packet data area. The fourth target byte is the byte that is the same as the first preset byte in the second traversal area included in the Mth source packet data area. Afterwards, the byte position of the first positioning byte in the Mth source packet data area can be recorded in the first list.

[0126] In some embodiments, after completing the traversal of the second traversal area included in the Mth source packet data area, see Fig.10 , and the second list can also be cleared. Afterwards, the penultimate byte included in the data area of ​​the Mth source packet is read.

[0127] If the last byte included in the Mth source packet data area is the same as the first preset byte, the last byte included in the Mth source packet data area is determined as the second positioning byte in the Mth source packet data area. Afterwards, the byte position of the second positioning byte in the Mth source packet data area in the Mth source packet data area is recorded in the second list.

[0128] In some embodiments, the content stored in the first cache may be monitored in real time to delete any historical byte group in the first cache if the number of bytes in the historical byte group exceeds a preset number.

[0129] Exemplarily, the preset number can be set to 2000 bytes. Since the RTP protocol data has a maximum transmission unit (Max Transmission Unit) limit under its original outer layer protocol (RTSP), and the maximum length of MTU is 1500 bytes, its payLoad part generally does not exceed 1460 bytes after removing its header. Therefore, when it is found that the number of bytes of a certain historical byte group stored in the first cache is greater than 2000, it must be an erroneous historical byte group (the first byte of the historical byte group is not the header of any initial data packet). Therefore, it can be cleared in time to save memory and time complexity.

[0130] It should be noted that those skilled in the art can set the preset number based on actual scenarios and needs, for example, setting the preset number to 1600 bytes, 1500 bytes, etc., and the embodiments of the present application are not limited thereto.

[0131] In some embodiments, the bytes included in each historical byte group can be parsed into an H.264 code stream or an H.265 code stream based on the payload type of each historical byte group stored in the second cache, so that when each code stream meets the push condition, the relevant content of each code stream can be displayed based on the target device, for example, playing a video screen.

[0132] In summary, the present invention provides a method for processing communication protocol data for space applications, which solves the problem of locating the RTP protocol header in the scenario where the initial data packets transmitted based on the RTP protocol are spliced ​​in sequence and cut according to the specified length, and can locate and restore the initial RTP data packet in the disordered RTP data in real time to ensure the orderly transmission of the RTP data packet. The real-time playback of RTP audio and video data of the streaming media protocol in space application scenarios is expanded, which can improve the playback efficiency.

[0133] In some schemes, multiple embodiments of the present application can be combined, and the combined scheme can be implemented. Optionally, some operations in the process of each method embodiment are optionally combined, and / or the order of some operations is optionally changed. In addition, the execution order between the steps of each process is only exemplary and does not constitute a restriction on the execution order between the steps. There can also be other execution orders between the steps. It is not intended to indicate that the execution order is the only order in which these operations can be performed. A person of ordinary skill in the art will think of a variety of ways to reorder the operations described herein. In addition, it should be noted that the process details involved in a certain embodiment of this article are also applicable to other embodiments in a similar manner, or different embodiments can be used in combination.

[0134] In addition, some steps in the method embodiment may be equivalently replaced by other possible steps. Alternatively, some steps in the method embodiment may be optional and may be deleted in certain usage scenarios. Alternatively, other possible steps may be added to the method embodiment. Furthermore, the method embodiments may be implemented separately or in combination.

[0135] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above.

[0136] In the several embodiments provided in the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of systems or units, which can be electrical, mechanical or other forms.

[0137] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0138] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0139] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for processing communication protocol data for space applications, characterized in that: include: receiving input communication information; The communication information includes N interconnected source packet data areas, where N≥2 and N is a positive integer; For any source packet data area among the N interconnected source packet data areas, the any source packet data area includes P interconnected initial data packets transmitted based on the RTP protocol, where P≥1; Preprocessing each initial data packet included in any one of the source packet data areas to convert data in each initial data packet included in any one of the source packet data areas into a hexadecimal format; Based on the communication information, execute N cycles to obtain a code stream corresponding to the communication information; When the code stream corresponding to the communication information meets the preset push stream condition, push the code stream corresponding to the communication information to the target device, so as to display the relevant content of the code stream corresponding to the communication information based on the target device; Wherein, in the first cycle of executing the N cycles, it includes: Traversing a first traversal area included in a first source packet data area of ​​the N interconnected source packet data areas; the first traversal area includes the first byte to the 12th byte from the last byte of the corresponding data area; For any first target byte of at least one first target byte traversed in the first traversal area included in the first source packet data area, if it is determined that the next byte of the any first target byte is the same as the second preset byte, then obtain the byte to be checked corresponding to the any first target byte; the first target byte is the byte that is the same as the first preset byte in the first traversal area included in the first source packet data area; the byte to be checked is the 9th byte to the 12th byte after the corresponding byte; If no historical byte group with the byte to be checked corresponding to any first target byte as a tag is detected in the first cache, a byte group corresponding to any first target byte is created in the first cache with the byte to be checked corresponding to any first target byte as a tag; if the historical byte group with the byte to be checked corresponding to any first target byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any first target byte as a tag is taken out from the first cache and stored in the second cache; the code stream corresponding to the communication information is determined based on the content included in the second cache; storing all bytes traversed from any first target byte into a byte group corresponding to any first target byte, and, if the first cache includes at least one historical byte group, storing all bytes traversed from any first target byte after the last byte included in any historical byte group for any historical byte group in the at least one historical byte group; Traversing a second traversal area included in the first source packet data area; the second traversal area includes the 11th to the second to last byte of the corresponding data area; For any second target byte of at least one second target byte traversed in the second traversal area included in the first source packet data area, if it is determined that the next byte of the any second target byte is the same as the second preset byte, then the any second target byte is determined as the first positioning byte in the first source packet data area; the second target byte is the byte that is the same as the first preset byte in the second traversal area included in the first source packet data area; Recording the byte position of the first positioning byte included in the first source packet data area in the first source packet data area into a first list; Read the last byte included in the data area of ​​the first source packet; If the last byte included in the first source packet data area is the same as the first preset byte, determining the last byte included in the first source packet data area as the second positioning byte in the first source packet data area; The byte position of the second positioning byte included in the first source packet data area in the first source packet data area is recorded in the second list.

2. The method according to claim 1, characterized in that In the Mth loop of the N loops, 2≤M≤N and M is a positive integer, including: splicing the (M-1)th source packet data area among the N interconnected source packet data areas before the Mth source packet data area to obtain a first spliced ​​data area; Traversing the first list, if the first list includes the byte corresponding to at least one first positioning byte in the (M-1)th source packet data area, for any first positioning byte in the at least one first positioning byte, obtaining a byte to be checked corresponding to any first positioning byte in the (M-1)th source packet data area; If no historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is detected in the first cache, a byte group corresponding to any first positioning byte is created in the first cache with the byte to be checked corresponding to any first positioning byte as a tag; if the historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any first positioning byte as a tag is taken out from the first cache and stored in the second cache; storing all bytes traversed from any first positioning byte into the byte group corresponding to any first positioning byte, and, when the first cache includes at least one historical byte group, storing all bytes traversed from any first positioning byte after the last byte included in any historical byte group for any historical byte group in the at least one historical byte group; Traversing the second list, if the second list includes the byte corresponding to the second positioning byte in the (M-1)th source packet data area, and the next byte of the second positioning byte in the (M-1)th source packet data area in the first spliced ​​data area is the same as the second preset byte, then obtaining the byte to be checked corresponding to the second positioning byte in the (M-1)th source packet data area; If the historical byte group with the to-be-checked byte corresponding to the second positioning byte in the (M-1)th source packet data area as a label is not detected in the first cache, the byte group corresponding to the second positioning byte in the (M-1)th source packet data area is created in the first cache with the to-be-checked byte corresponding to the second positioning byte in the (M-1)th source packet data area as a label; if the historical byte group with the to-be-checked byte corresponding to the second positioning byte in the (M-1)th source packet data area as a label is detected in the first cache, the historical byte group with the to-be-checked byte corresponding to the second positioning byte in the (M-1)th source packet data area as a label is taken out from the first cache and stored in the second cache; storing all bytes traversed from the second positioning byte in the (M-1)th source packet data area into the byte group corresponding to the second positioning byte in the (M-1)th source packet data area, and, if the first cache includes at least one historical byte group, for any historical byte group in the at least one historical byte group, storing all bytes traversed from the second positioning byte in the (M-1)th source packet data area after the last byte included in the any historical byte group; Traversing a first traversal area included in the first spliced ​​data area; For any third target byte of at least one third target byte traversed in the first traversal area included in the first spliced ​​data area, if it is determined that the next byte of the any third target byte is the same as the second preset byte, then obtaining the byte to be checked corresponding to the any third target byte; the third target byte is the byte that is the same as the first preset byte in the first traversal area included in the first spliced ​​data area; If no historical byte group with the byte to be checked corresponding to any third target byte as a tag is detected in the first cache, a byte group corresponding to any third target byte is created in the first cache with the byte to be checked corresponding to any third target byte as a tag; if the historical byte group with the byte to be checked corresponding to any third target byte as a tag is detected in the first cache, the historical byte group with the byte to be checked corresponding to any third target byte as a tag is taken out from the first cache and stored in the second cache; storing all bytes traversed from any third target byte into a byte group corresponding to any fourth target byte, and, if the first cache includes at least one historical byte group, storing all bytes traversed from any third target byte after the last byte included in any historical byte group for any historical byte group in the at least one historical byte group; Clear the first list; Traversing the second traversal area included in the Mth source packet data area; For any fourth target byte of at least one fourth target byte traversed in the second traversal area included in the Mth source packet data area, if it is determined that the next byte of the any fourth target byte is the same as the second preset byte, then the any fourth target byte is determined as the first positioning byte in the Mth source packet data area; the fourth target byte is the byte that is the same as the first preset byte in the second traversal area included in the Mth source packet data area; Record the byte position of the first positioning byte in the data area of ​​the Mth source packet into a first list; Clear the second list; Read the last byte included in the data area of ​​the Mth source packet; If the penultimate byte included in the Mth source packet data area is the same as the first preset byte, determining the penultimate byte included in the Mth source packet data area as the second positioning byte in the Mth source packet data area; The byte position of the second positioning byte in the Mth source packet data area in the Mth source packet data area is recorded in the second list.

3. The method according to claim 2, characterized in that Also includes: After creating the target byte group in the first cache, the target byte group becomes a historical byte group in the first cache; the target byte group includes at least one of a byte group corresponding to any first target byte, a byte group corresponding to any first positioning byte, a byte group corresponding to the second positioning byte in the (M-1)th source packet data area, and a byte group corresponding to any third target byte.

4. The method according to claim 3 is characterized in that Also includes: When it is detected that the number of bytes in any historical byte group included in the first cache exceeds a preset number, any historical byte group included in the first cache is deleted.

5. The method according to claim 4, characterized in that Before traversing the second traversal area included in the first source packet data area, the method further includes: clearing the first list.

6. The method according to claim 5, characterized in that Before reading the last byte included in the data area of ​​the first source packet, the method further includes: clearing the second list, where the second list is different from the first list.

7. The method according to claim 6, characterized in that The first preset byte is different from the second preset byte.

8. The method according to claim 7, characterized in that Preprocessing each initial data packet included in any source packet data area includes: For any initial data packet among the initial data packets included in the data area of ​​any source packet, data in the any initial data packet is converted into a hexadecimal format.

9. The method according to claim 8, characterized in that The performing N cycles based on the communication information to obtain a code stream corresponding to the communication information includes: Based on any historical byte group stored in the second cache, obtaining a code stream corresponding to any historical byte group stored in the second cache; Based on the code streams corresponding to the historical byte groups stored in the second cache, the code stream corresponding to the communication information is obtained.

10. The method according to claim 9, characterized in that The obtaining, based on any historical byte group stored in the second cache, a code stream corresponding to any historical byte group stored in the second cache includes: Based on the payload type of any historical byte group stored in the second cache, bytes included in any historical byte group stored in the second cache are parsed into an H.264 code stream or an H.265 code stream.

Images