Broadcast audio transmission method and device based on shared cycle frame index

Abstract

The invention discloses a broadcast audio transmission method and device based on a shared cycle frame index, and the method comprises the steps: verifying the online state of a transmitting end according to the evolution rule of an audio cycle frame index and a heartbeat cycle frame index, and if the verification is online, analyzing an audio frame, intercepting a corresponding audio load according to a target parameter, and decoding and playing the audio load. The invention provides a broadcast audio transmission method and device based on a shared cyclic frame index, and the method enables an audio frame and a heartbeat packet to share the same index space and preset index evolution rules, and enables a broadcast terminal to check the online state of a transmitting end according to the evolution rules of an audio cyclic frame index and a heartbeat cyclic frame index. The problem of misjudgment under an independent index system is avoided, the audio load is intercepted and decoded by relying on the parameters integrated by the audio frame header, and the problems that in an existing broadcast audio transmission method, due to the fact that the audio frame and the heartbeat packet adopt the independent index system, the online state of the sending end is prone to misjudgment, and the audio transmission reliability is low can be solved.

Description

A method and apparatus for broadcast audio transmission based on a shared cyclic frame index Technical Field

[0001] This invention relates to the field of multimedia broadcasting, and in particular to a broadcast audio transmission method and apparatus based on a shared cyclic frame index. Background Technology

[0002] IP broadcasting systems are widely used in scenarios such as network audio broadcasting and real-time high-definition audio transmission. In these scenarios, the demand for multi-terminal collaborative audio data transmission is increasingly prominent, placing stringent requirements on low latency and high reliability. To ensure audio transmission quality and terminal collaboration efficiency, the industry generally requires technologies such as standardized audio frame encapsulation, multi-terminal frame synchronization, data integrity verification, and terminal heartbeat keep-alive to support stable system operation. Existing audio data transmission methods mainly fall into two categories: one is a general audio transmission protocol, with frame headers containing fields such as version, payload type, sequence number, and timestamp, using UDP transmission to ensure real-time performance; the other is a vendor-specific broadcast protocol, employing variable-length frame headers, CRC32 checksums, incrementing sequence numbers without reset, independent short heartbeat packets, and sampling rate identification through the payload. The frame size needs to be calculated by the terminal based on the sampling rate and encoding format.

[0003] However, existing audio transmission methods for IP broadcast scenarios fail to fully meet the core transmission requirements of low latency and high reliability for multiple terminals. Their general protocols are not optimized for broadcast scenarios, and their proprietary protocols use independent indexing systems for audio frames and heartbeat packets, which cannot verify the sender's status through index consistency, making it prone to "false online" errors. Furthermore, the complex parsing of variable-length frame headers, the high computational cost of CRC32 verification, the lack of circularity in frame indexes leading to disorder, the need to calculate frame size tolerance, and the low flexibility in sampling rate adaptation all contribute to frequent misjudgments of the sender's online status, resulting in insufficient reliability of audio transmission. Summary of the Invention

[0004] This invention provides a broadcast audio transmission method and apparatus based on a shared cyclic frame index, to solve the problems in existing broadcast audio transmission methods where the use of independent index systems for audio frames and heartbeat packets leads to easy misjudgment of the online status of the sending end and low audio transmission reliability.

[0005] To achieve the above objectives, this application provides a broadcast audio transmission method based on a shared cyclic frame index, applicable to broadcast terminals, comprising: receiving audio frames and heartbeat packets sent by a transmitter; wherein, the audio frame is composed of an audio payload and a fixed-length audio frame header, the audio frame header integrating an audio cyclic frame index, frame size, and a checksum; the heartbeat packet contains a heartbeat cyclic frame index, and the heartbeat cyclic frame index shares the same index space with the audio cyclic frame index according to a preset index evolution rule, and both follow the index evolution rule; the online status of the transmitter is verified according to the evolution rules of the audio cyclic frame index and the heartbeat cyclic frame index; if the transmitter is online, the audio frame header of the audio frame is parsed to obtain target parameters, and the corresponding audio payload is extracted according to the target parameters and decoded for playback.

[0006] This invention abandons the separate indexing systems for audio frames and heartbeat packets, integrating their indexes into a single index space and following a unified preset index evolution rule, thus creating a strongly coupled and synchronized relationship between the two indexes. In existing technologies, independent evolution of the two indexes easily leads to inconsistent pace and distorted link status feedback. When the terminal relies on only a single index to determine the status, misjudgments and omissions often occur due to index disconnections. In this invention, however, the evolution trajectory of the heartbeat loop frame index directly characterizes the connectivity and continuity of the audio frame transmission link. By verifying the consistency of the evolution of the audio loop frame index and the heartbeat loop frame index, the terminal can accurately determine the real-time online status of the sender, completely avoiding the problem of false online status misjudgments caused by index fragmentation. Meanwhile, the audio frame structure design is optimized by integrating the audio loop frame index, frame size, and accumulated check bits into the fixed-length frame header. This design, on the one hand, uses the audio loop frame index to accurately trace the transmission order of audio frames and verify their integrity, avoiding problems such as out-of-order frames and frame loss; on the other hand, it uses the accumulated check bits to perform real-time verification of frame data, effectively intercepting anomalies such as data tampering and incompleteness caused by interference during transmission. After confirming the online status of the sending end, the terminal accurately extracts and decodes the audio payload based on the frame header parameters, further ensuring the accuracy of audio data parsing. From both the sending end status judgment and data transmission verification aspects, the reliability and stability of broadcast audio transmission are comprehensively improved.

[0007] Compared to existing technologies, this invention enables broadcast terminals to accurately verify the online status of the sending end based on the evolution rules of the heartbeat packet index by sharing the same index space and preset index evolution rules with audio frames and heartbeat packets. This avoids the misjudgment problem under independent index systems. At the same time, it relies on the parameters integrated in the audio frame header to achieve accurate interception and decoding of audio payload, thereby improving the reliability of audio transmission. Therefore, it can solve the problems of easy misjudgment of the online status of the sending end and low audio transmission reliability caused by the use of independent index systems for audio frames and heartbeat packets in existing broadcast audio transmission methods.

[0008] As a preferred embodiment, the audio frame header integrates the audio loop frame index, frame size, and accumulated checksum. Specifically, it involves: establishing a fixed-length frame header array and initializing all bytes to zero; obtaining fixed constant fields and dynamic configuration fields; wherein, the dynamic configuration fields include an audio loop frame index field and a frame size field; calculating the checksum based on the sum of the first few bytes of the frame header corresponding to the fixed constant fields and dynamic configuration fields; and encapsulating the fixed constant fields, the dynamic configuration fields, and the checksum into the fixed-length frame header array to obtain the audio frame header.

[0009] This preferred solution eliminates redundant interference in the frame header bytes by establishing a fixed-length frame header array and initializing it with zero bytes. This provides a standardized foundation for subsequent field encapsulation, avoids parsing chaos caused by frame header length fluctuations, and improves the consistency of the audio frame structure. The categorized acquisition of fixed constant fields and dynamically configured fields ensures the stability of the basic attributes of the frame header while adapting to dynamically changing parameters such as audio loop frame index and frame size, balancing protocol universality and scenario adaptability. Based on the accumulation of the first few bytes and the calculation of check bits, it can quickly detect byte loss and tampering during frame header transmission, achieving lightweight data verification without complex encryption algorithms, balancing verification accuracy and parsing efficiency. The overall encapsulation logic gives the audio frame header structured and verifiable characteristics, providing a reliable prerequisite for subsequent audio frame parsing and payload extraction, reducing the probability of decoding failures at broadcast terminals, and improving the stability of audio transmission.

[0010] As a preferred embodiment, the fixed constant fields include a frame header length field, a port field, and a total frame number segment. The specific method for obtaining each field is as follows: determine the fixed total length of the bytes in the fixed-length frame header array, convert the fixed total length of the bytes after removing the preset byte check bit into a hexadecimal value to obtain the frame header length field; select a target port suitable for the broadcast scenario, convert the target port into a hexadecimal value to obtain the port field; calculate the frame loop threshold according to the target time window and audio frame transmission period of the broadcast scenario, convert the frame loop threshold into a hexadecimal value to obtain the total frame number segment.

[0011] In this preferred scheme, the frame header length field is converted to hexadecimal by removing the checksum bit, accurately defining the effective data range of the frame header and preventing the terminal from mistakenly including the checksum bit in the effective field during parsing, thus improving the accuracy of frame header parsing. Selecting a target port suitable for the broadcast scenario and converting it to hexadecimal avoids the risk of conflicts with general ports, ensures a dedicated communication link between the broadcast terminal and the transmission end, reduces cross-scenario data interference, and enhances the compatibility of the protocol in broadcast scenarios. The total frame digital segment is calculated based on the target time window and transmission cycle, which can adapt to the needs of different broadcast durations and audio frame rates, allowing the terminal to know the frame cycle threshold in advance and avoid transmission interruptions caused by index overflow. The hexadecimal conversion of each field conforms to the byte alignment rules for data transmission, facilitating the terminal to quickly parse field values, shortening data processing time, and improving the real-time transmission effect of broadcast audio.

[0012] As a preferred embodiment, the method for obtaining the audio loop frame index field is as follows: An audio frame index is created through the index management module, and the initial value is set to zero; an index space from zero to a target threshold is established, and the sequence number in the index space is incremented by one each time it is allocated and used, and reset to zero when it reaches the target threshold, thus obtaining the index evolution rule; each time an audio frame is encapsulated, the index management module is controlled to allocate the current value of the audio frame index as a dedicated sequence number to the audio frame encapsulation module, and after allocation, the current value of the audio frame index is updated according to the index evolution rule; based on the dedicated sequence number split by bytes by the audio frame encapsulation module, the audio loop frame index field is obtained.

[0013] This preferred solution creates an audio frame index with an initial value of zero through an index management module, establishing a unified and traceable index starting point and avoiding frame identification deviations caused by initial index chaos. The same index space and the incremental zeroing evolution rule enable index reuse, eliminating the need for additional storage resources to record excessively large index values, effectively reducing terminal storage overhead and adapting to long-term continuous broadcast scenarios. A dedicated sequence number allocation and real-time update mechanism ensures that each audio frame has a unique identifier, accurately tracing the frame transmission order and resolving playback stuttering issues caused by out-of-order or dropped frames. The dedicated sequence number is split byte-by-byte to generate an audio loop frame index field, adapting to fixed-length frame header structures, facilitating rapid index parsing and restoration by the terminal, shortening data processing time, improving frame synchronization efficiency, and providing reliable support for audio frames and heartbeat packets to share the index space and evolve synchronously, further ensuring the consistency of multi-terminal broadcasts and the continuity of audio transmission.

[0014] As a preferred embodiment, the frame size field is obtained as follows: the frame size is calculated based on the audio sampling rate and frame duration corresponding to the audio payload; the frame size is converted into a four-digit hexadecimal string; then, it is split into a character segment consisting of the first two characters and a character segment consisting of the last two characters according to the character position; the two character segments are converted into hexadecimal values ​​respectively to obtain the frame size field.

[0015] This preferred solution calculates the frame size based on the audio sampling rate and frame duration, ensuring a precise match between the frame size and the original audio attributes. This avoids incomplete or redundant audio payload extraction due to unreasonable frame sizes, guaranteeing the integrity of the audio quality after decoding. The four-digit hexadecimal string splitting and conversion method adapts the frame size value to the fixed-length frame header field length, ensuring a consistent overall byte length in the frame header, conforming to fixed-length encapsulation logic, and improving compatibility across all aspects of the protocol. Splitting by character position and converting each digit to a hexadecimal value facilitates segmented parsing by the terminal, eliminating the need for overall frame size data processing, reducing parsing time, and improving the efficiency of audio payload extraction. This method is adaptable to audio scenarios with different sampling rates and frame durations, allowing adjustment of the frame size field without modifying the frame header structure. This enhances the protocol's adaptability to diverse audio data and reduces protocol iteration costs during scenario expansion.

[0016] As a preferred embodiment, the online status of the sending end is verified according to the evolution rules of the audio loop frame index and the heartbeat loop frame index. Specifically, if the number of audio frames and heartbeat packets continuously received within a preset continuous time window according to a preset transmission cycle is not less than a preset threshold, and the heartbeat loop frame index corresponding to the heartbeat packet and the audio loop frame index corresponding to the audio frame both follow the index evolution rules, then the sending end is determined to be online.

[0017] This preferred solution combines heartbeat packet reception status and index evolution rules for dual verification, overcoming the limitations of single heartbeat packet verification. It effectively identifies false online statuses caused by heartbeat packet forgery or delays, improving the accuracy of online determination at the sending end. The logic of simultaneous dual-index verification ensures consistency between heartbeat packet and audio frame transmission status. If either index violates the evolution rules, transmission anomalies can be detected promptly, link faults can be investigated in advance, and the risk of audio playback interruption can be reduced. This verification method requires no additional verification instructions and can be implemented using existing index data, balancing verification reliability and transmission efficiency. It ensures continuous and stable reception of audio data by the broadcast terminal, improving the overall availability of the broadcast system.

[0018] As a preferred embodiment, the heartbeat packet is composed of a heartbeat payload and a fixed-length heartbeat packet header.

[0019] This preferred solution designs the heartbeat packet as a structure concatenated with a heartbeat payload and a fixed-length heartbeat packet header. This allows for unified adaptation with the fixed-length header structure of audio frames, reusing the header parsing logic, index management mechanism, and verification rules of audio frames. This reduces the processing complexity of broadcast terminals for different types of data packets, decreases software and hardware development and maintenance costs, and improves overall protocol compatibility. Furthermore, the fixed-length header enables rapid heartbeat packet location and parsing, shortening the terminal's processing time for heartbeat packets, ensuring real-time online status verification, and meeting the low-latency requirements of multi-terminal synchronous transmission in broadcast scenarios. In addition, the unified header structure strengthens the synchronization consistency between the heartbeat packet index and the audio frame index, avoiding index evolution deviations caused by differences in header format, improving the accuracy of online status verification, and thus ensuring the continuity and stability of audio data transmission, effectively reducing the risk of offline misjudgment at the sending end and audio playback interruption.

[0020] This application also provides a broadcast audio transmission device based on a shared cyclic frame index, suitable for broadcast terminals, including a data receiving module and a data verification module; wherein, the data receiving module is used to receive audio frames and heartbeat packets sent by the sending end; wherein, the audio frame is composed of an audio payload and a fixed-length audio frame header, and the audio frame header integrates the audio cyclic frame index, frame size, and accumulated check bits; the heartbeat packet contains a heartbeat cyclic frame index, and the heartbeat cyclic frame index and the audio cyclic frame index share the same index space with a preset index evolution rule, and both follow the index evolution rule; the data verification module is used to verify the online status of the sending end according to the evolution rules of the audio cyclic frame index and the heartbeat cyclic frame index. If the verification shows online status, the target parameters are obtained by parsing the audio frame header of the audio frame, and the corresponding audio payload is extracted according to the target parameters and decoded for playback.

[0021] This application also provides a storage medium storing a computer program, which is invoked and executed by a computer to implement the broadcast audio transmission method based on a shared cyclic frame index as described above.

[0022] This application also provides a computer program product, including a computer program or instructions, which, when executed by a communication device, implement the broadcast audio transmission method based on a shared cyclic frame index as described above. Attached Figure Description

[0023] Figure 1 is a flowchart illustrating a broadcast audio transmission method based on a shared cyclic frame index provided in an embodiment of this application; Figure 2 is a structural diagram illustrating a broadcast audio transmission device based on a shared cyclic frame index provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In the description of this application, unless otherwise stated, "a number" means two or more.

[0026] The broadcast audio transmission method based on a shared cyclic frame index provided in this application aims to solve the following problems in existing IP broadcast audio transmission protocols: high parsing latency due to variable-length frame headers and lack of integrated core parameters; high computational complexity and unsuitability for low-computing-power terminals due to the use of CRC32 checksum; lack of a cyclic frame index mechanism, making it prone to synchronization loss due to overflow; independent indexing systems for audio frames and heartbeat packets, leading to "false online" situations at the sending end; poor fault tolerance due to the lack of direct encapsulation of frame size; and insufficient flexibility and compatibility in adapting to sampling rate identification only through payload.

[0027] Example 1: Please refer to Figure 1. This embodiment of the application provides a broadcast audio transmission method based on a shared cyclic frame index, applicable to broadcast terminals, including S1~S2. The specific implementation steps are as follows: S1, receiving audio frames and heartbeat packets sent by the sending end; wherein, the audio frame is composed of an audio payload and a fixed-length audio frame header, and the audio frame header integrates the audio cyclic frame index, frame size, and accumulated check bits; the heartbeat packet contains the heartbeat cyclic frame index, and the heartbeat cyclic frame index and the audio cyclic frame index share the same index space with the preset index evolution rule, and both follow the index evolution rule.

[0028] Step S1 in this embodiment includes S1.1 to S1.2, specifically: S1.1, at the sending end, i.e., the audio transmission terminal, audio frames and heartbeat packets are encapsulated by an audio protocol encapsulation system. The audio protocol encapsulation system includes an audio frame encapsulation module, a heartbeat packet encapsulation module, an index management module, and a verification calculation module. All modules run on the terminal, and its hardware carrier includes an IP broadcast terminal or server with a memory, processor, and network communication module, which can flexibly adapt to centralized and distributed deployment scenarios of IP broadcast systems.

[0029] The modules described above follow a clear collaborative interaction process: First, the index management module constructs a unified index space, establishes an evolution rule of "index incrementing and cyclical reset after reaching a threshold," and then assigns a unique index value conforming to this rule to the audio frames and heartbeat packets to be encapsulated. Subsequently, the audio frame encapsulation module constructs fixed-length frame headers based on audio parameters such as sampling rate and encoding type, and the heartbeat packet encapsulation module constructs frame headers according to preset heartbeat packet rules. Both types of frame headers integrate a unique terminal identification field (such as a MAC address). Next, the verification calculation module calculates and fills the verification bits for each frame header. Finally, the encapsulated frame header is concatenated with the corresponding audio payload and heartbeat payload to form a complete, transmittable audio frame and heartbeat packet, which are then sent through the network communication module according to the corresponding period of the IP broadcast protocol.

[0030] The specific encapsulation methods of audio frames and heartbeat packets are as follows: (1) Audio frame: The audio frame is composed of an audio payload and a fixed-length audio frame header. The audio payload is the actual audio data body carried in the audio frame. The audio frame header integrates the audio loop frame index, frame size and accumulated check bits. The specific method of establishing the audio frame header is as follows: establish a fixed-length frame header array and initialize all bytes to zero; obtain fixed constant fields and dynamic configuration fields; among which, the dynamic configuration fields include the terminal unique identifier field, sampling rate / encoding type field, audio loop frame index field and frame size field; calculate the check bits based on the sum of the first few bytes of the frame header corresponding to the fixed constant fields and dynamic configuration fields; encapsulate the fixed constant fields, dynamic configuration fields and check bits into the fixed-length frame header array to obtain the audio frame header.

[0031] The acquisition of the audio loop frame index field is implemented in an orderly manner through the index management module: First, dedicated indexes are built, corresponding to audio frames and heartbeat packets respectively, namely AudioHeaderIndex: audio frame index (a loop index specifically used to identify audio frames, sharing the same index space and evolution rules as the heartbeat packet index) and AudioHeartbeatIndex: heartbeat packet index (a loop index specifically used to identify heartbeat packets, following the same incrementing and cyclical reset rules as the audio frame index), and the initial values ​​of both indexes are set to 0; at the same time, an index space from zero to the target threshold 0xea60 (corresponding to the value 60000) is constructed, and an index evolution rule is formulated in this space: "the sequence number is incremented by 1 each time it is allocated and used, and automatically reset to 0 when the value reaches the target threshold", and the heartbeat packet index and the audio frame index share this index space and the same evolution rule. Whenever an audio frame encapsulation operation is performed, the index management module reads the current audio frame index value and assigns it as the unique sequence number of the audio frame to the audio frame encapsulation module. After the allocation is completed, the audio frame index automatically increments by 1 according to the predetermined evolution rule. After receiving the unique sequence number, the audio frame encapsulation module splits it into bytes and finally forms an audio loop frame index field containing four bytes of data.

[0032] The frame size field is obtained as follows: the frame size is calculated based on the audio sampling rate and frame duration corresponding to the audio payload. After converting the frame size into a four-digit hexadecimal string, it is split into a character segment consisting of the first two characters and a character segment consisting of the last two characters according to the character position. The two character segments are then converted into hexadecimal values ​​to obtain the frame size field.

[0033] The fixed constant fields include a fixed identifier field, a frame header length field, a port field, an audio channel, link sequence number and audio switching field, a total frame number field, and delay control and extension bit fields. The frame header length field, port field, and total frame number field are obtained as follows: The total fixed length of the fixed-length frame header array is determined; the total fixed length of the bytes after removing the preset byte check bits is converted to a hexadecimal value to obtain the frame header length field; a target port suitable for the broadcast scenario is selected; the target port is converted to a hexadecimal value to obtain the port field; the frame loop threshold is calculated based on the target time window and audio frame transmission period of the broadcast scenario; the frame loop threshold is converted to a hexadecimal value to obtain the total frame number field.

[0034] The following is a detailed explanation of the specific encapsulation method of the audio frame header based on the audio frame encapsulation module: Step 1: Construct a 33-byte fixed-length frame header array (defined as char head

[33] ) and initialize all bytes in the array to 0; Step 2: Fill in the fixed identifier field, which occupies the 1st to 4th bytes of the frame header, and is specifically assigned the values ​​head[0]=0x42, head[1]=0x43, head[2]=0x41, head[3]=0x01, so as to clearly identify the frame as an audio data frame; Step 3: Fill in the frame header length field, which is located in the 5th byte of the frame header and is assigned the value head[4]=0x1a, which corresponds to the effective length of 30 bytes in the 33-byte frame header without the check bit; Step 4: Fill in the terminal unique identifier field, which occupies the 6th to 11th bytes of the frame header (supports MAC address, etc.). (Identification format), specifically by traversing the input terminal unique identifier array, converting each identifier sub-segment into a hexadecimal value, and then filling it into head[5]-head

[10] in sequence; Step 5: Fill the port field, which is located in the 12th-13th byte of the frame header, and assigns the values ​​head

[11] =0x14 and head

[12] =0x00, corresponding to the 5120 port adapted for broadcast scenarios; Step 6: Fill the audio channel, link number and audio switching fields, which correspond to the 14th, 15th and 16th bytes of the frame header, respectively, and the default values ​​of the three are 0x00, 0x01 and 0x00 in sequence; Step 7: Differentiate the sampling rate / encoding type field, which occupies the frame The specific configuration rules for bytes 17-18 of the header are as follows: • If it is a 48K sampling rate and SBC encoding: head

[16] =0x04, head

[17] =0x0c; • If it is a 48K sampling rate and not encoded: head

[16] =0x01, head

[17] =0x0c; • If it is a 16K sampling rate: head

[16] =0x01, head

[17] =0x08; Step 8: Fill the audio loop frame index field, which is located in bytes 19-22 of the frame header (corresponding to array subscripts head

[18] -head

[21] ). The specific operation is as follows: First, obtain the Au allocated to the current audio frame from the index management module. dioHeaderIndex (audio frame index), then split the index value into bytes and assign values ​​in the order of "high byte to low byte". The specific rules are: head

[18] =(AudioHeaderIndex&0XFF000000)>>24、head

[19] =(AudioHeaderIndex&0X00FF0000)>>16、head

[20] =(AudioHeaderIndex&0X0000FF00)>>8、head

[21] =(AudioHeaderIndex&0X000000FF)>>0;Step 9: Fill the total frame number field. This field occupies bytes 23-26 of the frame header and is fixedly assigned the values ​​0x00, 0x00, 0xea, and 0x60, corresponding to the index loop threshold of 60000. Step 10: Fill the frame size field. This field is located in bytes 27-28 of the frame header. Specifically, the input frameSize is first converted into a 4-digit hexadecimal string, the first 2 digits and the last 2 digits are split and converted into hexadecimal values ​​respectively, and then filled into head

[26] and head

[27] . For example, fr When ameSize=960, the hexadecimal value is 0x03c0, corresponding to the values ​​head

[26] =0x03 and head

[27] =0xc0; when frameSize=320, the hexadecimal value is 0x0140, corresponding to the values ​​head

[26] =0x01 and head

[27] =0x40; Step 11: Fill the delay control and extension bit fields, where the delay control field occupies bytes 29-30 of the frame header, and the extension bit field is located in byte 31, with default values ​​for both. All are 0x00; Step 12: The verification calculation module calculates and fills the verification bits. This field occupies the 32nd-33rd bytes of the frame header. The specific calculation process is as follows: • Initialize the 16-bit verification value validation=0; • Traverse the first 31 bytes of the frame header (head[0]-head

[30] ), accumulate the value of each byte, and if the byte is negative, convert it to 256+the value; • Split the calculated validation by bytes and assign the values ​​head

[31] =(validation&0X0000FF00)>>8, head

[32] =(validation&0X000000FF)>>0; Step 13: After Step 2-12 completes the filling of all fields of the 33-byte fixed-length frame header array constructed in Step 1, the filled frame header array is converted to NSData format. At the same time, the index management module increments AudioHeaderIndex by 1 according to the unified evolution rule, and finally completes the complete encapsulation of the audio frame header.

[0035] The following example uses an audio frame encapsulated with a 48K sampling rate, SBC encoding, and frameSize=960 bytes: ① The terminal unique identifier array is [@"00",@"11",@"22",@"33",@"44",@"55"] (MAC address), and after conversion, head[5]-head

[10] are 0x00, 0x11, 0x22, 0x33, 0x44, and 0x55 respectively; ② Sampling rate / encoding field: head

[16] =0x04, head

[17] =0x0c; ③ Frame index is At 100, head

[18] =0x00, head

[19] =0x00, head

[20] =0x00, head

[21] =0x64; ④ The frame size 960 is converted to hexadecimal 0x03c0, head

[26] =0x03, head

[27] =0xc0; ⑤ The sum of the first 31 bytes is 1234 (0x04d2), then head

[31] =0x04, head

[32] =0xd2; ⑥ Finally, a 33-byte frame header is generated, which is then spliced ​​with the 960-byte audio payload and transmitted.

[0036] This embodiment eliminates redundant interference in the frame header bytes by establishing a fixed-length frame header array and initializing zero bytes, providing a standardized foundation for subsequent field encapsulation, avoiding parsing chaos caused by frame header length fluctuations, and improving the consistency of the audio frame structure. The categorized acquisition of fixed constant fields and dynamically configured fields ensures the stability of the basic attributes of the frame header while adapting to dynamically changing parameters such as audio loop frame index and frame size, balancing protocol universality and scenario adaptability. Based on the accumulation of the first few bytes and the calculation of check bits, it can quickly detect byte loss, tampering, and other problems during frame header transmission, achieving lightweight data verification without complex encryption algorithms, balancing verification accuracy and parsing efficiency. The overall encapsulation logic gives the audio frame header structured and verifiable characteristics, providing a reliable premise for subsequent audio frame parsing and payload interception, reducing the probability of decoding failures at broadcast terminals, and improving the stability of audio transmission. Furthermore, the frame header length field is converted to hexadecimal by removing the check bits, accurately defining the effective data range of the frame header, preventing the terminal from mistakenly including check bits in the effective fields during parsing, and improving the accuracy of frame header parsing. Selecting a target port suitable for the broadcast scenario and converting it to hexadecimal avoids the risk of conflicts with general ports, ensures a dedicated communication link between the broadcast terminal and the transmission end, reduces cross-scenario data interference, and enhances the compatibility of the protocol in broadcast scenarios. The total frame digital segment is calculated based on the target time window and transmission cycle, adapting to different broadcast durations and audio frame rates, allowing the terminal to know the frame loop threshold in advance and avoid transmission interruptions caused by index overflow. The hexadecimal conversion of each field conforms to the byte alignment rules for data transmission, facilitating rapid parsing of field values ​​by the terminal, shortening data processing time, and improving the real-time transmission effect of broadcast audio. Furthermore, for the audio loop frame index field, an audio frame index with an initial value of zero is created through the index management module, establishing a unified and traceable index starting benchmark and avoiding frame identification deviations caused by initial index confusion. The same index space and the incremental-to-zero evolution rule enable index reuse, eliminating the need for additional storage resources to record extremely large index values, effectively reducing terminal storage overhead, and adapting to long-term continuous broadcast scenarios. A dedicated sequence number allocation and real-time update mechanism ensures that each audio frame has a unique identifier, enabling precise tracking of frame transmission order and resolving playback stuttering issues caused by out-of-order or dropped frames. The dedicated sequence number is split byte-by-byte to generate an audio loop frame index field, which adapts to fixed-length frame header structures, facilitating rapid index parsing and restoration by the terminal, reducing data processing time, improving frame synchronization efficiency, and providing reliable support for audio frames and heartbeat packets to share index space and evolve synchronously, further ensuring the consistency of multi-terminal broadcasting and the continuity of audio transmission.

[0037] For the frame size field, the frame size is calculated based on the audio sampling rate and frame duration, ensuring a precise match between the frame size and the original audio attributes. This avoids incomplete or redundant audio payload extraction due to unreasonable frame sizes, guaranteeing the integrity of the audio quality after decoding. The four-digit hexadecimal string splitting and conversion method adapts the frame size value to the fixed-length frame header field bit length, ensuring a uniform overall byte length in the frame header, conforming to fixed-length encapsulation logic, and improving compatibility across all aspects of the protocol. Splitting by character position and converting each digit to a hexadecimal value facilitates segmented parsing by the terminal, eliminating the need for overall frame size data processing, reducing parsing time, and improving the efficiency of audio payload extraction. This method can adapt to audio scenarios with different sampling rates and frame durations, adjusting the frame size field without modifying the frame header structure, enhancing the protocol's adaptability to diverse audio data, and reducing protocol iteration costs during scenario expansion.

[0038] (2) Heartbeat Packet: The heartbeat packet adopts a splicing structure of "fixed-length frame header + heartbeat payload". Its encapsulation process is dominated by the heartbeat packet encapsulation module. The specific steps are as follows: Step 1: Construct a 20-byte fixed-length frame header array (defined as char) head

[20] ), and initialize all bytes in the array to 0, laying the foundation for subsequent field filling; Step 2: Fill the fixed identifier field, which occupies the 1st to 4th bytes of the frame header, and specifically assign the values ​​head[0]=0x42, head[1]=0x43, head[2]=0x48, head[3]=0x64, so as to clearly identify the frame as a heartbeat packet; Step 3: Fill the frame header length field, which is located in the 5th byte of the frame header, and assign the value head[4]=0x0d, corresponding to the 18-byte effective length in the 20-byte frame header without the check bit; Step 4: Fill the terminal unique identifier field, which occupies the 6th to 11th bytes of the frame header (supports MAC address and other identifier forms), and the filling method is the same as step 4 of the audio frame encapsulation, that is, traverse the input terminal unique identifier array and convert each identifier sub-segment into hexadecimal. After the base value, fill it into head[5]-head

[10] in sequence; Step 5: Fill the port field, which is located in the 12th-13th byte of the frame header. The filling method is the same as step 5 of the audio frame encapsulation. The values ​​are head

[11] =0x14 and head

[12] =0x00, which correspond to the 5120 port adapted for the broadcast scenario; Step 6: Fill the audio channel field, which is located in the 14th byte of the frame header. The default value is 0x00; Step 7: Fill the heartbeat loop frame index field, which occupies the 15th-18th byte of the frame header. First, obtain the AudioHeartbeatIndex (heartbeat packet index) allocated by the index management module, and then split the index value into 4 bytes in the order of "high byte to low byte", and fill it into head

[14] (highest byte) to head

[17] (lowest byte) in sequence.It should be clarified that the heartbeat loop frame index field in this step shares the index space and index evolution rules established above with the audio loop frame index field in audio frame encapsulation step 8. That is, both evolve synchronously according to the rule of "index incrementing and automatically resetting to 0 when the value reaches the threshold 0xea60 (decimal 60000)", ensuring that the terminal can verify the online status of the sending end through index consistency verification; Step 8: The verification calculation module calculates and fills the verification bits. This field occupies the 19th-20th bytes of the frame header. The specific process is as follows: first initialize the 16-bit verification value validation=0, and then traverse the first 18 bytes of the frame header (head[0]-head[ 17]) and accumulate the value of each byte, and finally split the calculated validation by byte and fill it into head

[18] and head

[19] respectively; Step 9: After steps 2-8 have completed filling all fields of the 20-byte frame header array constructed in step 1, first convert the filled frame header array into NSData format; at the same time, the index management module increments AudioHeartbeatIndex by 1 according to the index evolution rule; finally, the converted complete frame header and the preset heartbeat payload are spliced ​​together in the order of "frame header first, payload last" to form a complete heartbeat packet, and finally complete the encapsulation of the heartbeat packet.

[0039] This embodiment designs the heartbeat packet as a structure where the heartbeat payload is concatenated with a fixed-length heartbeat packet header. This allows for a unified adaptation with the fixed-length header structure of audio frames, reusing the header parsing logic, index management mechanism, and verification rules of audio frames. This reduces the processing complexity of broadcast terminals for different types of data packets, decreases software and hardware development and maintenance costs, and improves overall protocol compatibility. Furthermore, the fixed-length header enables rapid heartbeat packet location and parsing, shortening the terminal's processing time for heartbeat packets, ensuring the real-time nature of online status verification, and adapting to the low-latency requirements of multi-terminal synchronous transmission in broadcast scenarios. In addition, the unified header structure strengthens the synchronization consistency between the heartbeat packet index and the audio frame index, avoiding index evolution deviations caused by differences in header formats, improving the accuracy of online status verification, and thus ensuring the continuity and stability of audio data transmission, effectively reducing the risk of offline misjudgment at the sending end and audio playback interruption.

[0040] It should be noted that the index management module provides the audio frame encapsulation module and the heartbeat packet encapsulation module with index values ​​based on the same index space and unified evolution rules, so as to realize that the heartbeat packet index and the audio frame index at least partially share the index space and evolution rules; the verification calculation module provides a unified accumulation and verification method for audio frames and heartbeat packets. It only needs to pass the corresponding frame header array and the specified calculation length (the first 31 bytes for audio frames and the first 18 bytes for heartbeat packets) to output the required verification bits.

[0041] S1.2 After encapsulation, the audio frame encapsulation module and the heartbeat packet encapsulation module transmit their respective complete output data to the network communication module. The audio frame has a complete structure of "33-byte fixed-length header + audio payload," and the heartbeat packet has a complete structure of "20-byte fixed-length header + heartbeat payload." Based on the network communication module, the sending end sends this data to the broadcast terminal according to the preset transmission period of the IP broadcast protocol, specifically every 10ms for audio frames and every 1s for heartbeat packets. The broadcast terminal receives the audio frames and heartbeat packets transmitted from the sending end in real time via the network link, providing a data foundation for subsequent online status verification, audio payload parsing, and playback operations.

[0042] S2. Verify the online status of the sending end according to the evolution of the audio loop frame index and the heartbeat loop frame index. If the verification shows that the sending end is online, parse the audio frame header of the audio frame to obtain the target parameters, extract the corresponding audio payload according to the target parameters, and decode and play it.

[0043] In this embodiment, step S2 specifically involves the following steps: Within a preset continuous time window, if the broadcast terminal continuously receives audio frames and heartbeat packets from the same sender at a transmission cycle of 10ms for audio frames and 1s for heartbeat packets, and the number of such receptions is not less than the corresponding preset thresholds, and after each audio frame or heartbeat packet is received, a double check is performed: ① The sum of the check bits in the packet header is consistent with the sum of the first N bytes (N=31 for audio frames, N=18 for heartbeat packets) in the header; ② The cyclic frame index field of the packet itself follows the index evolution rule (i.e., the index value increases sequentially and is automatically reset to 0 after reaching the threshold 0xea60), and the step speed difference between the two indices within the preset continuous time window is within a preset reasonable range, then the sender is determined to be online; conversely, if any of the following situations occur, the sender is determined to be offline: ① No audio frames or heartbeat packets are continuously received within the preset continuous time window, including no reception at all, transmission interruption, or the number received not reaching the corresponding preset threshold for "continuous reception"; ② Audio frames or heartbeat packets are received, but the packet... The sum of the checksum in the frame header is inconsistent with the sum of the first N bytes of the frame header (N=31 for audio frames, N=18 for heartbeat packets); ③ Although an audio frame is received, the audio loop frame index field does not follow the above evolution rules, such as index value jumps, repetitions, not incrementing in order, or not being reset after reaching the threshold 0xea60; ④ Although a heartbeat packet is received, the heartbeat loop frame index field does not follow the above evolution rules, such as index value jumps, repetitions, not incrementing in order, or not being reset after reaching the threshold 0xea60; ⑤ Both indices follow the evolution rules respectively, and the sum... The summation and verification are consistent, but the pace is not synchronized. The index difference exceeds the preset reasonable range. For example, the preset reasonable difference range between the audio loop frame index field value in the audio frame header and the heartbeat loop frame index field value in the heartbeat packet header within 1 second is 95~105. If the heartbeat loop frame index field value in the heartbeat packet header increases from 100 to 101 within 1 second, but the audio loop frame index field value in the audio frame header increases from 200 to 350, the difference between the two field values ​​of 249 far exceeds the reasonable range, which means that the pace is not synchronized.

[0044] If the online status check passes, the sending end is determined to be online. The broadcast terminal will parse the 33-byte fixed-length header of the audio frame, extract target parameters such as frame size, sampling rate / encoding type, etc., and then accurately extract the corresponding audio payload based on the frame size parameter. After decoding based on the extracted sampling rate / encoding type, it will be played. If the online status check fails, the sending end is determined to be offline. The broadcast terminal will immediately stop audio decoding and playback to avoid outputting incomplete or garbled audio data. At the same time, it will trigger the link reconnection mechanism, initiating reconnection requests to the sending end at preset intervals until reconnection is successful or the preset maximum number of reconnections is reached. It will also clear unparsed audio frames, invalid index records, and incomplete data from the cache. Invalid data such as audio payloads are removed, freeing up terminal storage resources and computing power; offline log information is automatically recorded, including offline timestamps, reasons for offline determination, the index value of the last received heartbeat packet and audio frame index value, preset continuous time window parameters, etc., and the offline status is reported to the system management terminal through the dedicated management communication link of the IP broadcast system; if the maximum number of reconnection attempts is reached and reconnection is still unsuccessful, the terminal enters a low-power standby listening state, keeping only the core communication module running, continuously listening for valid heartbeat packets from the audio transmission terminal. Once a valid heartbeat packet is detected, the online status verification process is automatically triggered. After the verification is passed, audio frame reception, frame header parsing, payload interception and decoding playback are resumed according to normal logic.

[0045] This embodiment S2 combines heartbeat packet reception status and index evolution rules for dual verification, avoiding the limitations of single heartbeat packet verification. It effectively identifies false online statuses caused by heartbeat packet forgery or delays, improving the accuracy of online determination at the sending end. The logic of dual-index synchronous verification ensures the consistency of heartbeat packet and audio frame transmission status. If any index violates the evolution rules, transmission anomalies can be detected promptly, link faults can be investigated in advance, and the risk of audio playback interruption can be reduced. This verification method does not require additional verification instructions and can be implemented based on existing index data, balancing verification reliability and transmission efficiency, ensuring continuous and stable reception of audio data by the broadcast terminal, and improving the overall availability of the broadcast system.

[0046] It should be noted that the technical solution of this embodiment supports flexible adaptation and adjustment in multiple dimensions, while the core logic and key means remain unchanged: ① The index loop threshold can be flexibly replaced. In addition to the default 0xea60 (60000), it can also be set to 0xffff (65535) or other custom values ​​according to the actual application scenario requirements. Only by adjusting the index reset conditions in the index management module can the shared characteristics of the heartbeat packet index and the audio frame index on the same index space and evolution rules be maintained, without affecting the stability of the overall encapsulation logic.

[0047] ② The check bit calculation supports extended optimization. On the basis of the original cumulative calculation, a differentiated weight coefficient can be configured for each byte participating in the operation (such as assigning different weights according to the importance of the field before accumulating). This method still belongs to the lightweight cumulative check system, which can meet the basic check requirements of data integrity in IP broadcast scenarios without reconstructing the core check logic.

[0048] ③ Encapsulating the frame size field simplifies the process. There is no need to convert frameSize into a four-digit hexadecimal string first. Instead, it can be directly split into a 16-bit integer into high-order bytes (corresponding to head

[26] ) and low-order bytes (corresponding to head

[27] ) and filled, which effectively reduces the calculation steps and improves the encapsulation efficiency.

[0049] ④ The terminal unique identifier field supports multiple types of adaptation. In addition to MAC address, UUID, device SN code, custom logical ID and other identifier forms can also be selected. Only the parsing rules and filling process of the identifier field need to be adjusted accordingly. There is no need to change the overall structure of the frame header, so as to adapt to the terminal identification needs in different scenarios.

[0050] ⑤ The frame header length can be adjusted as needed. The audio frame header can be compressed to 32 bytes (the check bits are merged into 1 byte and the lower 8 bits of the sum are taken), and the heartbeat packet frame header can be simplified to 18 bytes (non-core extension bit fields are removed). Both adjustments retain the core functional fields of the frame header, which can better adapt to resource-constrained terminal deployment scenarios.

[0051] Furthermore, the audio transmission terminal used to send audio frames and heartbeat packets is a transmitting device equipped with an audio protocol encapsulation system. Its hardware carrier is an IP broadcast terminal or server with memory, processor, and network communication module. It can be flexibly selected according to the deployment scenario of the IP broadcast system—in centralized deployment, it can be used as an IP broadcast server to uniformly push data; in distributed / point-to-point deployment, it can be used as an IP broadcast terminal with sending function to transmit data. The broadcast terminal used to receive the audio frames and heartbeat packets sent by the transmitting end is the receiving end device responsible for receiving network transmission data in the IP broadcast system. It needs to have the capabilities of data reception, online status verification, frame header parsing, audio decoding, and playback. Specifically, it can include network broadcast speakers, IP broadcast receivers, terminal devices with integrated IP broadcast functions, etc., and can be adapted to the audio transmission protocol of this invention and complete audio playback.

[0052] It is important to note that the fact that a broadcast terminal "receives audio frames and heartbeat packets" only proves that there is instantaneous data transmission on the physical link, and cannot be directly equated to "stable online performance at the sending end." In actual IP broadcast transmission scenarios, there are often situations such as residual data in the buffer before the sending end goes offline, data packet delays / duplications caused by network congestion, index jumps caused by transmission interference, and invalid data mistakenly received across terminals. In these scenarios, although some scattered data can be received, subsequent audio transmission is prone to problems such as stuttering, decoding errors, and interruptions. This is precisely the "false online" phenomenon caused by the lack of associated indexes between heartbeat packets and audio frames in existing technologies. This invention employs a dual verification process: "continuous reception within a preset continuous time window" and "dual index synchronization following evolution rules." Essentially, it double-confirms both "link connectivity" and "data transmission reliability." The former ensures continuous link stability rather than momentary connectivity, while the latter, through the synchronous evolution characteristics of the shared index space, verifies that the received data is valid data adapted to the current terminal and that transmission is continuous. This completely avoids misjudgments caused by "judging the sending end is online simply by receiving data," providing a stable and reliable prerequisite for accurate parsing, decoding, and playback of subsequent audio frames, ultimately improving the overall reliability of broadcast audio transmission.

[0053] Overall, this embodiment has the following beneficial effects: This invention abandons the separate indexing systems for audio frames and heartbeat packets, integrating their indexes into the same index space and following a unified preset index evolution rule, thus creating a strongly coupled and synchronized relationship between the two indexes. In existing technologies, independent evolution of the two indexes easily leads to inconsistent pace and distorted link status feedback. When the terminal relies on only a single index to determine the status, misjudgments and omissions often occur due to index disconnection. In this invention, the evolution trajectory of the heartbeat loop frame index can directly characterize the continuity and interruption of the audio frame transmission link. By verifying the consistency of the evolution of the audio loop frame index and the heartbeat loop frame index, the terminal can accurately determine the real-time online status of the sending end, completely avoiding the problem of false online misjudgment caused by index fragmentation. Meanwhile, the audio frame structure design is optimized by integrating the audio loop frame index, frame size, and accumulated check bits into the fixed-length frame header. This design, on the one hand, uses the audio loop frame index to accurately trace the transmission order of audio frames and verify their integrity, avoiding problems such as out-of-order frames and frame loss; on the other hand, it uses the accumulated check bits to perform real-time verification of frame data, effectively intercepting anomalies such as data tampering and incompleteness caused by interference during transmission. After confirming the online status of the sending end, the terminal accurately extracts and decodes the audio payload based on the frame header parameters, further ensuring the accuracy of audio data parsing. From both the sending end status judgment and data transmission verification aspects, the reliability and stability of broadcast audio transmission are comprehensively improved.

[0054] In summary, this invention significantly improves the parsing efficiency and processing performance of audio transmission in IP broadcast systems through optimizations such as fixed-length frame header design, core parameter integration, unified cyclic indexing mechanism, and lightweight verification method. It also reduces the verification calculation cost to adapt to low-computing-power terminals, strengthens frame synchronization stability and the reliability of online status verification at the sending end, effectively eliminates the "false online" problem, improves frame parsing fault tolerance and adaptability to different sampling rates and encoding formats, and optimizes the bandwidth usage of heartbeat packet transmission. Overall, it comprehensively improves the low latency, high reliability, and high compatibility characteristics of audio transmission.

[0055] Example 2: Referring to Figure 2, this embodiment of the application provides a broadcast audio transmission device based on a shared cyclic frame index, suitable for broadcast terminals, including a data receiving module 10 and a data verification module 20; wherein, the data receiving module 10 is used to receive audio frames and heartbeat packets sent by the sending end; wherein, the audio frame is composed of an audio payload and a fixed-length audio frame header, and the audio frame header integrates the audio cyclic frame index, frame size, and accumulated check bits; the heartbeat packet contains a heartbeat cyclic frame index, and the heartbeat cyclic frame index and the audio cyclic frame index share the same index space with the preset index evolution rules, and both follow the index evolution rules; the data verification module 20 is used to verify the online status of the sending end according to the evolution rules of the audio cyclic frame index and the heartbeat cyclic frame index. If the verification shows that the sending end is online, the audio frame header of the audio frame is parsed to obtain the target parameters, the corresponding audio payload is extracted according to the target parameters, and then decoded and played.

[0056] It should be noted that the technical concept of this second embodiment is completely consistent with that of the first embodiment. The two maintain a high degree of synergy at the technical logic level. The specific technical details can be referred to the relevant description of the first embodiment, which will not be repeated here.

[0057] Example 3: This application provides a computer-readable storage medium, which includes a stored computer program. When the computer program runs, it controls the device containing the computer-readable storage medium to execute the aforementioned broadcast audio transmission method based on a shared cyclic frame index. The broadcast audio transmission method based on a shared cyclic frame index, if implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above-described embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0058] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0059] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A broadcast audio transmission method based on a shared cyclic frame index, characterized in that, This is applicable to broadcast terminals and includes: receiving audio frames and heartbeat packets sent by a transmitting end; wherein, the audio frame is composed of an audio payload and a fixed-length audio frame header, and the audio frame header integrates an audio loop frame index, frame size, and accumulated check bits; the heartbeat packet contains a heartbeat loop frame index, and the heartbeat loop frame index and the audio loop frame index share the same index space with a preset index evolution rule and both follow the index evolution rule; the online status of the transmitting end is verified according to the evolution rules of the audio loop frame index and the heartbeat loop frame index; if the verification shows online status, the target parameters are obtained by parsing the audio frame header of the audio frame, and the corresponding audio payload is extracted according to the target parameters and decoded for playback.

2. The broadcast audio transmission method based on a shared cyclic frame index as described in claim 1, characterized in that, The audio frame header integrates the audio loop frame index, frame size, and accumulated checksum. Specifically, it involves: establishing a fixed-length frame header array and initializing all bytes to zero; obtaining fixed constant fields and dynamic configuration fields; wherein, the dynamic configuration fields include an audio loop frame index field and a frame size field; calculating the checksum based on the sum of the first few bytes of the frame header corresponding to the fixed constant fields and dynamic configuration fields; and encapsulating the fixed constant fields, the dynamic configuration fields, and the checksum into the fixed-length frame header array to obtain the audio frame header.

3. The broadcast audio transmission method based on a shared cyclic frame index as described in claim 2, characterized in that, The fixed constant fields include a frame header length field, a port field, and a total frame number field. The specific methods for obtaining each field are as follows: determine the fixed total length of the bytes in the fixed-length frame header array, convert the fixed total length of the bytes after removing the preset byte check bit into a hexadecimal value to obtain the frame header length field; select a target port suitable for the broadcast scenario, convert the target port into a hexadecimal value to obtain the port field; calculate the frame loop threshold according to the target time window and audio frame transmission period of the broadcast scenario, convert the frame loop threshold into a hexadecimal value to obtain the total frame number field.

4. The broadcast audio transmission method based on a shared cyclic frame index as described in claim 2, characterized in that, The method for obtaining the audio loop frame index field is as follows: An audio frame index is created through the index management module, and the initial value is set to zero; an index space from zero to a target threshold is established, and the sequence number in the index space is incremented by one each time it is allocated and used, and reset to zero when it reaches the target threshold, thus obtaining the index evolution rule; each time an audio frame is encapsulated, the index management module is controlled to allocate the current value of the audio frame index as a dedicated sequence number to the audio frame encapsulation module, and after allocation, the current value of the audio frame index is updated according to the index evolution rule; based on the audio frame encapsulation module, the dedicated sequence number is split byte by byte to obtain the audio loop frame index field.

5. The broadcast audio transmission method based on a shared cyclic frame index as described in claim 2, characterized in that, The frame size field is obtained as follows: the frame size is calculated based on the audio sampling rate and frame duration corresponding to the audio payload. The frame size is then converted into a four-digit hexadecimal string and split into a character segment consisting of the first two characters and a character segment consisting of the last two characters according to the character position. The two character segments are then converted into hexadecimal values ​​respectively to obtain the frame size field.

6. The broadcast audio transmission method based on a shared cyclic frame index as described in claim 4, characterized in that, The online status of the sending end is verified according to the evolution rules of the audio loop frame index and the heartbeat loop frame index. Specifically, if the number of audio frames and heartbeat packets received continuously within a preset continuous time window according to a preset transmission period is not less than a preset threshold, and the heartbeat loop frame index corresponding to the heartbeat packet and the audio loop frame index corresponding to the audio frame both follow the index evolution rules, then the sending end is determined to be online.

7. A broadcast audio transmission method based on a shared cyclic frame index as described in any one of claims 1 to 6, characterized in that, The heartbeat packet is composed of a heartbeat payload and a fixed-length heartbeat packet header.

8. A broadcast audio transmission device based on a shared cyclic frame index, characterized in that, This is applicable to broadcast terminals and includes a data receiving module and a data verification module. The data receiving module receives audio frames and heartbeat packets sent by a transmitting end. The audio frame is composed of an audio payload and a fixed-length audio frame header, the audio frame header integrating an audio loop frame index, frame size, and a checksum. The heartbeat packet contains a heartbeat loop frame index, and the heartbeat loop frame index shares the same index space with the audio loop frame index according to a preset index evolution rule, and both follow the index evolution rule. The data verification module verifies the online status of the transmitting end based on the evolution rules of the audio loop frame index and the heartbeat loop frame index. If the verification shows online status, it parses the audio frame header of the audio frame to obtain target parameters, extracts the corresponding audio payload according to the target parameters, and decodes and plays it.

9. A storage medium, characterized in that, The storage medium stores a computer program, which is called and executed by a computer to implement a broadcast audio transmission method based on a shared cyclic frame index as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the communication device, they implement a broadcast audio transmission method based on a shared cyclic frame index as described in any one of claims 1 to 7.

Images