A Baseband IP Video Data Transmission Method and System

Abstract

The present application provides a baseband IP video data transmission method and system. The baseband IP video data transmission method is based on shared memory and combines message queues to implement a global memory pool. The feature of low delay of the message queue is used as the control communication channel between processes, and the characteristics of high read / write bandwidth and low delay of the shared memory are used as the carrier for baseband data transmission. The present application uses memory data queue classification management and time-sharing read / write to achieve asynchronous access to data on both the read and write sides. Neither the read side nor the write side needs to wait due to address competition. As long as the memory address is obtained, the relevant data can be processed respectively, greatly improving the transmission and processing efficiency of baseband data.

Description

Technical Field

[0001] This application relates to the field of radio and television technology, and particularly to a baseband IP video data transmission method and system. Background Art

[0002] With the continuous improvement of the video signal resolution in the radio and television industry, the video signal format has changed from the initial 576i50 to 1080i50, and then to the ultra-high definition 2160p50 or even 4320p50 gradually applied in recent years. The amount of baseband data to be processed has increased sharply. At the same time, in order to improve the flexibility of baseband data scheduling in the system, the baseband IP upgrade transformation relying on the ST2110 protocol has also begun to be gradually applied in the radio and television industry. In the field of source coding and compression, how to flexibly and efficiently transmit and multiplex a large amount of video baseband data among various processing programs at the software level after the video signal is collected by the ST2110 capture card has become a huge challenge.

[0003] The data stream processing framework of a real-time software encoder usually follows an approximate processing flow:

[0004] (1) Acquisition: The video signal acquisition card receives the media baseband signal and stores it in the device-side DDR, which is completed by peripheral hardware, such as ST2110, SDI capture cards, etc.

[0005] (2) Transmission: The audio and video media baseband data is transmitted to the server main memory through direct memory access technology (DMA).

[0006] (3) Software processing: Audio and video preprocessing, audio and video compression coding, bitstream output, etc.

[0007] The first two steps are completed using proprietary hardware. When the baseband data enters the operating system main memory for software processing, it can usually be divided into two methods: single-process and multi-process cooperation according to the software processing framework. Since a process is the basic unit for the operating system to allocate and schedule resources, in the design of video encoding software, in order to achieve isolation of computing and storage resources and prevent other functional modules within the process from being affected by exceptions such as crashes or thread stalls, a multi-process program architecture is usually adopted, and each channel or several channels of encoding runs with an independent process as the carrier. For the transmission of signals from the device side to the host side, usually an independent software process is required to execute DMA and transmit the baseband signal to each encoding process, that is, the transmission and distribution of input baseband data among different processing processes within the operating system.

[0008] The existing inter-process communication technologies mainly include 4 categories: based on network sockets, based on pipes, based on message queues, and based on shared memory, each with its applicable usage scenarios.

[0009] Based on network sockets, using network transmission channels, it can be transmitted across processes and operating systems. The bandwidth is limited by the transmission network and the transceiver capabilities of the operating system kernel protocol stack.

[0010] Based on pipes, it is a half-duplex unidirectional transmission based on file descriptors. The transmission bandwidth is small and it is not suitable for frequently exchanging large-bandwidth data.

[0011] Based on message queues, kernel message queues have high performance and low latency. Data copying is required on both the reading and writing sides, and it is not suitable for the frequent sending and receiving of large data blocks.

[0012] Based on shared memory, the process virtual address space is mapped to the same physical memory block. The read and write latency is short, and it is necessary to handle read and write mutual exclusion to achieve memory access consistency.

[0013] An important problem that must be solved first in inter-process communication is the consistency of reading and writing data. Once the reading and writing ends operate on the same memory address, competition will occur. Common means of read and write synchronization to solve this problem are to use semaphores and mutexes, and to serialize the memory operations on both the reading and writing sides in time sequence through another global resource. However, both will introduce a certain amount of synchronization loss. For a real-time ultra-high-definition baseband signal of 50 frames per second, the latency generated by the high-frequency synchronization on both the reading and writing sides will directly affect the overall real-time performance of the encoding. In addition, common data transmission based on shared memory is a single-producer single-consumer structure and cannot achieve multi-consumer distribution and reuse after data production. Summary of the Invention

[0014] To solve one of the above technical defects, an embodiment of the present application provides a baseband IP video data transmission method and system.

[0015] In a first aspect of an embodiment of the present application, a baseband IP video data transmission method is provided. The method is applied to the proxy side and includes:

[0016] Initialize the proxy thread and establish a message queue;

[0017] Obtain the registration request from the encoding side, establish a shared memory pool according to the registration request, and establish a transmission connection with the encoding side;

[0018] Divide the shared memory pool into multiple frame storage units, allocate an ID identifier for each frame storage unit, and calculate the offset of each frame storage unit in the shared memory pool. The ID identifier and the offset form a frame handle;

[0019] Establish two frame index queues for indexing frame handles in different states, obtain the frame baseband data on the device side, process the frame baseband data and store it in the idle frame storage unit, and put the frame handle of the idle frame storage unit into the frame index queue representing the written frames. The idle frame storage unit is any one of the multiple frame storage units that has not been written with frame baseband data;

[0020] Send the frame handle of the idle frame storage unit in the frame index queue representing the written frames to the encoding side, so that the encoding side reads the frame baseband data stored in the idle frame storage unit from the shared memory pool according to the frame handle of the idle frame storage unit;

[0021] Receive the feedback information of successful reception from the encoding side, and exchange the frame handle of the idle frame storage unit in the two frame index queues after the reading and use of the idle frame storage unit are completed.

[0022] A second aspect of the embodiments of the present application provides a method for transmitting baseband IP video data. The method is applied to the encoding side, and the method includes:

[0023] Initialize the encoding process and establish a message queue;

[0024] Send a registration request to the proxy side, so that the proxy side establishes a shared memory pool according to the registration request and establishes a transmission connection with the proxy side;

[0025] Obtain the frame handle of the idle frame storage unit sent by the proxy side, and read and process the frame baseband data stored in the idle frame storage unit from the shared memory pool according to the frame handle of the idle frame storage unit. The shared memory pool includes multiple frame storage units, and the idle frame storage unit is any one of the multiple frame storage units. The frame handle includes the ID identifier of the frame storage unit and the offset of the frame storage unit in the shared memory pool;

[0026] Send feedback information to the proxy side, so that the proxy side reclaims the frame handle of the idle frame storage unit.

[0027] A third aspect of the embodiments of the present application provides a baseband IP video data transmission system, and the system includes a proxy side and an encoding side;

[0028] The proxy side includes a processor and a memory. Among them, one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the processor, the processor is caused to execute the method according to any one of claims 1 to 9;

[0029] The encoding side includes a processor and a memory. One or more computer programs are stored in the memory, and the one or more computer programs include instructions. When the instructions are executed by the processor, the processor is caused to execute the method according to any one of claims 10 to 12.

[0030] In the embodiment of the present application, the baseband IP video data transmission method provided is based on shared memory and combined with a message queue to implement a global memory pool. Using the characteristic of low delay of the message queue as the control communication channel between processes, and using the characteristics of high read / write bandwidth and low delay of the shared memory as the carrier for baseband data transmission. The present application uses memory data queue classification management and time-sharing read / write to achieve asynchronous access to data on both the read and write sides. Neither the read side nor the write side needs to wait due to address competition. As long as the memory address is obtained, the relevant data can be processed respectively, greatly improving the transmission and processing efficiency of baseband data. Description of the Drawings

[0031] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0032] Figure 1 It is a flowchart of a baseband IP video data transmission method according to Embodiment 1 of the present application;

[0033] Figure 2 It is a flowchart of a baseband IP video data transmission method according to Embodiment 2 of the present application;

[0034] Figure 3 It is a schematic diagram of the principle of a baseband IP video data transmission system according to Embodiment 3 of the present application. Detailed Embodiments

[0035] In order to make the technical solutions and advantages in the embodiments of the present application clearer and more understandable, the following further details the exemplary embodiments of the present application with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than an exhaustive list of all embodiments. It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. Embodiment 1

[0036] As Figure 1 shown, this embodiment proposes a baseband IP video data transmission method, which is applied to the proxy side. The proxy side can specifically be the carrier of the network card data DMA receiving program. The method specifically includes:

[0037] S101. Initialize the proxy thread and establish a message queue.

[0038] Specifically, after starting the proxy program on the proxy side with each network card as a unit, the initialization of the peripheral hardware on the device side is first performed, including but not limited to operations such as driver loading. The device side can be a capture card of a specific model, etc. Then, a message queue on the proxy side is established with the network card name as the global descriptor, that is, the named message queue mq_Eth, and the main thread starts listening to this named message queue mq_Eth as a message consumer.

[0039] S102. Obtain the registration request on the encoding side, establish a shared memory pool according to the registration request, and establish a transmission connection with the encoding side.

[0040] Specifically, on the encoding side, it is also necessary to use the network card as the global descriptor, but create a message queue on the encoding side as a producer, that is, the encoding side message queue mq_Eth, and send a registration request to the proxy side through this encoding side message queue. The registration request contains the multicast url address information on the network card.

[0041] After the proxy side receives the above registration request, it queries the shared resource mapping table managed by the local storage to confirm whether the multicast registration request exists, that is, to distinguish whether the multicast registration request has been requested by other encoding tasks. If it does not exist, a multicast receiving thread between the proxy side and the device side is synchronously established, a multicast request message queue mq1 between the proxy side and the encoding side is established, and a shared memory pool pool1 for storing the multicast data is established. At the same time, the descriptors of the multicast request message queue and the shared memory pool are stored for the encoding side that requests the same multicast data later to reuse the data. Then, the descriptors of the multicast request message queue and the shared memory pool are sent to the encoding side. If the multicast registration request already exists in the shared resource mapping table managed by the local storage, then directly send the descriptors of the already stored multicast request message queue and the shared memory pool to the encoding side, and the establishment process of the shared memory pool can be skipped.

[0042] Through the above process, the encoding side can obtain the access right to the shared memory pool and establish a multicast receiving message queue. After the shared memory pool pool1 is established on the proxy side, the multicast receiving thread can be started, and at the same time, the data requests from the encoding side in the multicast request message queue mq1 are listened to. When a data request from the encoding side is received, a connection is established as a producer according to the descriptor of the multicast receiving message queue mqA_recv on the encoding side contained in the data request, and the transmission connection between the proxy side and the encoding side can be realized.

[0043] Through the above process, a dedicated data communication is completely established with the proxy side as the sender and the encoding side as the receiver. The channel uses the multicast receive message queue mqA_recv to send data and the multicast request message queue mq1 to send responses. All subsequent baseband data transmissions in the shared memory pool are based on this.

[0044] S103. The shared memory pool is divided into multiple frame storage units, and each frame storage unit is assigned an ID identifier. In addition, the offset of each frame storage unit in the shared memory pool is calculated. The ID identifier and the offset form a frame handle.

[0045] Specifically, when the proxy side initially creates a shared memory pool for multicast data, it allocates a complete shared memory pool according to the preset total size of the shared memory pool. Then, the shared memory pool is divided into blocks with the single-frame capacity as the basic unit. Each block is a basic storage unit for data frames, that is, a frame storage unit. Each frame storage unit is divided into three regions: a synchronization frame header region, a metadata region, and a data payload region.

[0046] The synchronization frame header region does not change after initialization and is used for the transceiver sides to verify the data frame synchronization offset, avoiding the abnormal spread caused by damaged memory data due to out-of-bounds reading and writing.

[0047] The metadata region is used to store the attribute information of the frame data, mainly including frame attribute information such as the timestamp at the acquisition moment and the resolution.

[0048] The data payload region is used to store the actual acquired frame data.

[0049] After the proxy side completes the block division of the shared memory pool, it initializes the synchronization frame header region, writes the synchronization word, and completes the initialization of the frame storage units in the actual shared memory pool. After initialization, the proxy side assigns an ID identifier to each frame storage unit and uses its offset in the entire shared memory pool, that is, the frame index address, to establish a mapping table. The ID identifier and the offset form the frame handle of the frame storage unit, forming frame handle management. The frame storage unit of the frame data can be directly obtained by looking up the table according to the ID identifier.

[0050] S104. Two frame index queues are established to index frame handles in different states, obtain the frame baseband data on the device side, process the frame baseband data and store it in the idle frame storage unit, and put the frame handle of the idle frame storage unit into the frame index queue representing the written frames.

[0051] Specifically, in this embodiment, the idle frame storage unit is any one of the multiple frame storage units that has not been written with frame baseband data. After establishing the frame handle, two frame index queues are then established to manage the use of the shared memory pool. These two frame index queues are the in-use frame memory queue and the idle frame memory queue, as Figure 3 shown. Initially, the frame handles of all frame storage units are deposited in the idle frame memory queue. During subsequent transmissions, only the ID identifier and offset in the frame handle are required for the actual data in the channel. The encoding side can locate the currently transmitted frame storage unit based on the offset received in the message queue and access the specific address through pointer shifting to read the specific data, thus forming a transmission.

[0052] At the start of baseband data acquisition, after the device side DMA-transmits a frame of baseband data to the proxy side, the shared memory pool management thread on the proxy side grabs a frame handle from the idle frame memory queue and restores the address of the idle frame storage unit corresponding to this frame handle. After processing the frame baseband data, the attribute information of the frame baseband data is written into the metadata area of the idle frame storage unit, the actual information of the frame baseband data is written into the data payload area of the idle frame storage unit, and the frame handle of the idle frame storage unit is placed in the in-use frame memory queue.

[0053] S105. Send the frame handle of the idle frame storage unit in the frame index queue indicating that it has been written to the encoding side, so that the encoding side can read the frame baseband data stored in the idle frame storage unit in the shared memory pool according to the frame handle of the idle frame storage unit.

[0054] S106. Receive the feedback success information from the encoding side, and exchange the frame handle of the idle frame storage unit in the two frame index queues after the reading of the idle frame storage unit is completed.

[0055] Specifically, the proxy side is driven by an independent thread to send the shared memory pool. The frame handles in the in-use frame memory queue are sent to the encoding side through the multicast receive message queue of the encoding side according to the first-in, first-out principle. The encoding side receives the offset of this frame handle to obtain the actual frame baseband data. After the encoding program on the encoding side completes the encoding process of this frame baseband data, it notifies the proxy side through the multicast request message queue. The recycling thread on the proxy side puts the frame handle of the idle frame storage unit back into the idle frame memory queue for new acquired frame baseband data to be written.

[0056] Through the above process, a closed loop for the cyclic reuse of shared memory pool frame baseband data among processes is formed. Among them, the proxy side is the producer and has the write permission for data, and the encoding side is the consumer and has the read permission for data. The baseband IP video data transmission method provided in this embodiment is based on shared memory and combined with message queues, realizing a global memory pool. Using the characteristic of low delay of message queues as the control communication channel among processes, and using the characteristics of high read / write bandwidth and low delay of shared memory as the carrier for baseband data transmission. This embodiment uses memory data queue classification management and time-sharing read / write to realize asynchronous access to data on both the read and write sides. Neither the read side nor the write side needs to wait due to address competition. As long as the memory address is obtained, they can process the relevant data respectively, greatly improving the transmission and processing efficiency of baseband data.

[0057] Through the establishment of the transmission connection between the proxy side and the encoding side and the reuse of baseband data, the above process can achieve one-to-one zero-copy baseband data reading and writing. However, in actual applications, there is also a need for a single producer and multiple consumers. It is necessary to transfer the same frame of baseband data to multiple encoding sides, that is, the frame baseband data collected in the same shared memory pool is read by multiple encoding sides. For this situation, the usual solution is to use end-to-end transmission of multiple independent shared memories. Inevitably, a copy of the data to multiple shared memory blocks will be introduced in this process. In view of this, this embodiment introduces a read count mechanism on the proxy side.

[0058] Specifically, when the encoding side notifies the proxy side after using up a frame of baseband data, the frame storage unit of this frame of baseband data will be recycled for subsequent writing, that is, the life cycle of one round ends. And when there are multiple encoding sides sharing the frame storage unit of the same frame of baseband data, the life cycle of this frame storage unit depends on the encoding side that finishes using it last. Therefore, this embodiment establishes a record table of the frame storage unit corresponding to the frame handle of each frame stored in the in-use frame memory queue on the proxy side. The number of times each frame storage unit is read is recorded in this frame storage unit record table. When the in-use frame memory queue successfully sends the frame handle of an idle frame storage unit to the encoding side once, the number of times the idle frame storage unit is read will be incremented by one in this frame storage unit record table, and the process ID number will be recorded. Correspondingly, each time the information of the frame baseband data of the idle frame storage unit that has completed use is received from the encoding side, the number of times the idle frame storage unit is read will be decremented by one in this frame storage unit record table, and the record of the encoding side in the frame storage unit record table will be cleared according to the process ID number. When the number of times the idle frame storage unit is read in the frame storage unit record table is zero, it means that all encoding sides have completed the use of the idle frame storage unit. At this time, the frame handle of the idle frame storage unit is put back into the idle frame memory queue. All the increment and decrement operations of this read count are carried out on the proxy side and are driven by the sending or recycling of message queues, avoiding inter-process synchronization.

[0059] Furthermore, in actual applications, the encoding side may be unable to feedback information to the proxy side due to abnormal situations such as encoding program crashes. In this regard, this embodiment can add a forced recovery mechanism and a heartbeat mechanism.

[0060] Specifically, the forced recovery mechanism will regularly check whether the frame handle transmission process of the frame baseband data in the in-use frame memory queue has been cleared. If the transmission process has been cleared, the number of times the frame storage unit corresponding to the transmission process is read in the frame storage unit record table will be decreased by one, and the process record will be cleared.

[0061] The heartbeat mechanism needs to add a heartbeat type protocol to the communication of the message queue. When the feedback information from the encoding side is not received within a predetermined time, a heartbeat protocol is sent to the encoding side through the message queue. If the feedback information sent in response to the heartbeat protocol from the encoding side is received, no other redundant processing is done. If the feedback information sent in response to the heartbeat protocol from the encoding side is not received, it can be considered that the encoding side has entered a process freeze state or there are other abnormal situations, and the frame handles of the frame storage units are put back into the frame index queue to implement forced recovery. Embodiment 2

[0062] As Figure 2 shown, this embodiment proposes a baseband IP video data transmission method, which is applied to the encoding side. The encoding side can be a carrier of an image processing and encoding program. The method specifically includes:

[0063] S201. Initialize the encoding process and establish a message queue.

[0064] Specifically, when the encoding program of the encoding side starts, the network card configuration for this path of encoding is input. A message queue of the encoding side is established with the network card name as the global descriptor, that is, the encoding side message queue mq_Eth.

[0065] S202. Send a registration request to the proxy side so that the proxy side establishes a shared memory pool according to the registration request and establishes a transmission connection with the proxy side.

[0066] Specifically, the encoding side sends a registration request to the proxy side through the encoding side message queue mq_Eth. The registration request contains the multicast url address information on the network card. After receiving the above registration request, the proxy side queries the shared resource mapping table managed by the local storage to confirm whether the multicast registration request exists, that is, to identify whether the multicast registration request has been requested by other encoding tasks. If it does not exist, a multicast receiving thread is synchronously established with the device side, a multicast request message queue mq1 is established with the encoding side, and a shared memory pool pool1 for storing the multicast data is established. At the same time, the descriptors of the multicast request message queue and the shared memory pool are stored for the encoding side that requests the same multicast data later to reuse the data. Then, the descriptors of the multicast request message queue and the shared memory pool are sent to the encoding side. If the multicast registration request already exists in the shared resource mapping table managed by the local storage, then the descriptors of the already stored multicast request message queue and the shared memory pool can be directly sent to the encoding side, and the establishment process of the shared memory pool can be skipped.

[0067] Through the above process, the encoding side can obtain the access right to the shared memory pool and establish a multicast receiving message queue. After the shared memory pool pool1 is established, the proxy side can start the multicast receiving thread and listen to the data requests from the encoding side in the multicast request message queue mq1. When a data request from the encoding side is received, a connection is established as a producer according to the descriptor of the multicast receiving message queue mqA_recv of the encoding side contained in the data request, and the transmission connection between the proxy side and the encoding side can be realized.

[0068] Through the above process, a dedicated data communication with the proxy side as the sender and the encoding side as the receiver is completely established. The channel uses the multicast receiving message queue mqA_recv to send data and the multicast request message queue mq1 to send responses, and all subsequent baseband data transmissions in the shared memory pool are based on this.

[0069] S203. Obtain the frame handle of the idle frame storage unit sent by the proxy side, and read and process the frame baseband data stored in the idle frame storage unit in the shared memory pool according to the frame handle of the idle frame storage unit.

[0070] Specifically, in this embodiment, the shared memory pool on the proxy side includes multiple frame storage units. The idle frame storage unit is any one of the multiple frame storage units. The frame handle includes the ID identifier of the frame storage unit and the offset of the frame storage unit in the shared memory pool.

[0071] More specifically, when the proxy side initially creates a shared memory pool for multicast data, it allocates a complete shared memory pool according to the preset total size of the shared memory pool. Then, the shared memory pool is divided into blocks with the single-frame capacity as the basic unit. Each block is a basic storage unit for data frames, that is, a frame storage unit. Each frame storage unit is divided into three regions: a synchronization frame header region, a metadata region, and a data payload region.

[0072] The synchronization frame header region does not change after initialization and is used for the verification of the data frame synchronization offset between the sending and receiving sides to avoid the abnormal spread caused by the damaged memory data due to out-of-bounds reading and writing.

[0073] The metadata region is used to store the attribute information of the frame data, mainly including frame attribute information such as the timestamp at the acquisition moment and the resolution.

[0074] The data payload region is used to store the actual acquired frame data.

[0075] After the proxy side completes the block processing of the shared memory pool, it initializes the synchronization frame header region, writes the synchronization word, and completes the initialization of the frame storage unit in the actual shared memory pool. After the initialization is completed, the proxy side assigns an ID identifier to each frame storage unit and uses its offset in the entire shared memory pool, that is, the frame index address, to establish a mapping table. The ID identifier and the offset form the frame handle of the frame storage unit, forming the frame handle management. The frame storage unit of the frame data can be directly obtained by looking up the table according to the ID identifier.

[0076] After establishing the frame handle, two frame index queues are then established to manage the use of the shared memory pool. The two frame index queues are the in-use frame memory queue and the free frame memory queue, as Figure 2 shown. Initially, the frame handles of all frame storage units are stored in the free frame memory queue. During the subsequent transmission process, only the ID identifier and the offset in the frame handle are required for the actual data in the channel. The encoding side can locate the current transmitted frame storage unit according to the offset received by the message queue and access the specific address through pointer shifting to read the specific data, forming a transmission.

[0077] When the baseband data acquisition starts, after the device side DMA-transmits a frame of baseband data to the proxy side, the shared memory pool management thread of the proxy side grabs a frame handle from the free frame memory queue and restores the address of the free frame storage unit corresponding to the frame handle according to the frame handle. After processing the frame baseband data, it writes the attribute information of the frame baseband data into the metadata region of the free frame storage unit, writes the actual information of the frame baseband data into the data payload region of the free frame storage unit, and stores the frame handle of the free frame storage unit in the in-use frame memory queue.

[0078] S204. Feed back information to the proxy side so that the proxy side reclaims the frame handle of the idle frame storage unit.

[0079] The proxy side is driven by an independent thread to send the shared memory pool. The frame handles in the in-use frame memory queue are sent to the encoding side through the multicast receive message queue on the encoding side according to the first-in-first-out principle. The encoding side receives the offset of the frame handle to obtain the actual frame baseband data. After the encoding program on the encoding side completes the encoding process of this frame baseband data, it notifies the proxy side through the multicast request message queue. The reclaiming thread on the proxy side puts the frame handles of the idle frame storage unit back into the idle frame memory queue for the newly acquired frame baseband data to be written and used.

[0080] Through the above process, a closed loop for the cyclic reuse of frame baseband data in the shared memory pool among processes is formed. Among them, the proxy side is the producer and has the write permission for data, and the encoding side is the consumer and has the read permission for data. The baseband IP video data transmission method provided in this embodiment is based on shared memory and combined with message queues to implement a global memory pool. Utilize the characteristic of low delay of message queues as the control communication channel among processes, and utilize the characteristics of high read / write bandwidth and low delay of shared memory as the carrier for baseband data transmission. This embodiment uses memory data queue classification management and time-sharing read / write to achieve asynchronous access to data on both the read and write sides. Neither the read side nor the write side needs to wait due to address competition. As long as the memory address is obtained, they can process the relevant data respectively, greatly improving the transmission and processing efficiency of baseband data. Embodiment 3

[0081] As Figure 3 shown, this embodiment proposes a baseband IP video data transmission system, which includes a proxy side and an encoding side.

[0082] Specifically, the proxy side includes a processor and a memory. Among them, one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the processor, the processor is caused to execute the following methods:

[0083] Initialize the proxy thread and establish a message queue;

[0084] Obtain the registration request from the encoding side, establish a shared memory pool according to the registration request, and establish a transmission connection with the encoding side;

[0085] Divide the shared memory pool into multiple frame storage units, allocate an ID identifier for each frame storage unit, and calculate the offset of each frame storage unit in the shared memory pool. The ID identifier and the offset form a frame handle;

[0086] Establish two frame index queues for indexing frame handles in different states, obtain the frame baseband data on the device side, process the frame baseband data and store it in the idle frame storage unit, and put the frame handle of the idle frame storage unit into the frame index queue representing written frames. The idle frame storage unit is any one of the multiple frame storage units that has not been written with frame baseband data;

[0087] Send the frame handle of the idle frame storage unit in the frame index queue representing written frames to the encoding side, so that the encoding side reads the frame baseband data stored in the idle frame storage unit from the shared memory pool according to the frame handle of the idle frame storage unit;

[0088] Receive the feedback information of successful reception from the encoding side, and exchange the frame handle of the idle frame storage unit in the two frame index queues after the reading and use of the idle frame storage unit are completed.

[0089] The encoding side includes a processor and a memory. Among them, one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the processor, the processor is caused to execute the following method:

[0090] Initialize the encoding process and establish a message queue;

[0091] Send a registration request to the proxy side, so that the proxy side establishes a shared memory pool according to the registration request and establishes a transmission connection with the proxy side;

[0092] Obtain the frame handle of the idle frame storage unit sent by the proxy side, read and process the frame baseband data stored in the idle frame storage unit from the shared memory pool according to the frame handle of the idle frame storage unit. The shared memory pool includes multiple frame storage units, and the idle frame storage unit is any one of the multiple frame storage units. The frame handle includes the ID identification of the frame storage unit and the offset of the frame storage unit in the shared memory pool;

[0093] Send feedback information to the proxy side, so that the proxy side reclaims the frame handle of the idle frame storage unit.

[0094] In this embodiment, the provided baseband IP video data transmission system is based on shared memory and combined with message queues, implementing a global memory pool. Utilizing the low latency feature of message queues as the control communication channel between processes, and the high read / write bandwidth and low latency characteristics of shared memory as the baseband data transmission carrier. Based on these two points, data proxy for peripherals such as capture cards is completed. This method is not limited to data proxy for specific peripheral devices and is applicable to all cross-process large data volume transmissions with a single producer and multiple consumers. This embodiment uses memory data queue classification management and time-sharing read / write to achieve asynchronous access to data on both the read and write sides. Neither side needs to wait due to address competition. As long as the memory address is obtained, relevant data can be processed separately, greatly improving the transmission and processing efficiency of baseband data.

[0095] In this application, unless otherwise clearly defined and limited, terms such as "install", "connect", "link", "fix" and other terms should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or integrated; it can be a mechanical connection, an electrical connection or can communicate with each other; it can be directly connected, or indirectly connected through an intermediate medium, and can be the internal connection of two components or the interaction relationship between two components. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0096] Although the preferred embodiments of this application have been described, those skilled in the art can make additional changes and modifications once they know the basic creative concept. Therefore, the appended claims are intended to be interpreted to include the preferred embodiments and all changes and modifications falling within the scope of this application.

[0097] Obviously, those skilled in the art can make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalent technologies, this application is also intended to include these changes and modifications.

Claims

1. A baseband IP video data transmission method, characterized in that: The method is applied to the agent side, and the method includes: The proxy thread is initialized and the message queue is established; Obtaining a registration request from the encoding side, establishing a shared memory pool according to the registration request, and establishing a transmission connection with the encoding side; The shared memory pool is divided into blocks to form a plurality of frame storage units, and an ID is assigned to each frame storage unit, and an offset of each frame storage unit in the shared memory pool is calculated, wherein the ID and the offset constitute a frame handle; Two frame index queues are established for indexing frame handles in different states, frame baseband data on the device side is obtained, the frame baseband data is processed and stored in an idle frame storage unit, and the frame handle of the idle frame storage unit is placed in a frame index queue indicating that it has been written, wherein the idle frame storage unit is any frame storage unit among multiple frame storage units into which the frame baseband data has not been written; Sending the frame handle of the idle frame storage unit in the frame index queue that has been written to the encoding side, so that the encoding side reads the frame baseband data stored in the idle frame storage unit in the shared memory pool according to the frame handle of the idle frame storage unit; The receiving encoding side feeds back the reception success information, and exchanges the frame handle of the idle frame storage unit between two frame index queues after the idle frame storage unit is read and used; The process of obtaining a registration request from the encoding side, establishing a shared memory pool according to the registration request, and establishing a transmission connection with the encoding side includes: Obtaining a registration request sent by the encoding side to the naming message queue through the encoding side message queue, wherein the registration request includes the URL address information of the multicast on the network card; When the multicast registration request is not recorded in the shared resource mapping table of the local storage management, a multicast receiving thread is established between the device side, a multicast request message queue is established between the encoding side, and a shared memory pool is established for storing the multicast data; storing the descriptor of the multicast request message queue and the descriptor of the shared memory pool, and sending the descriptor of the multicast request message queue and the descriptor of the shared memory pool to the encoding side, so that the encoding side obtains the memory data access right of the shared memory pool by mapping the descriptor of the shared memory pool, and establishes a multicast receiving message queue; The data request sent by the encoding side through the multicast request message queue is monitored, wherein the data request includes the descriptor of the multicast receiving message queue of the encoding side, and a transmission connection is established with the encoding side according to the descriptor of the multicast receiving message queue.

2. The method according to claim 1, characterized in that The process of initializing the proxy thread and establishing the message queue includes: Start the agent program in units of network cards to initialize the peripheral hardware on the device side; A named message queue is established with the network card name as a global descriptor, and the named message queue is monitored.

3. The method according to claim 1, characterized in that The frame storage unit includes a synchronization frame header area, a metadata area and a data load area; The synchronization frame header area is used for the proxy side and the encoding side to verify the data frame synchronization offset; The metadata area is used to store attribute information of the frame data; The data payload area is used to store actual information of the frame data.

4. The method according to claim 3, characterized in that The process of establishing two frame index queues for indexing frame handles in different states, acquiring frame baseband data on the device side, storing the frame baseband data in an idle frame storage unit after processing, and placing the frame handle of the idle frame storage unit into a frame index queue indicating that it has been written includes: Establishing two frame index queues, wherein the frame index queues include an in-use frame memory queue and an idle frame memory queue, wherein the in-use frame memory queue is used to store frame handles of written frame storage units, and the idle frame memory queue is used to store frame handles of unwritten frame storage units, and the idle frame memory queue initially stores frame handles of all frame storage units; Acquire frame baseband data on the device side, capture the frame handle of the idle frame storage unit in the idle frame memory queue, and restore the address of the idle frame storage unit according to the frame handle; Processing the frame baseband data, writing attribute information of the frame baseband data into a metadata area of ​​the idle frame storage unit, and writing actual information of the frame baseband data into a data load area of ​​the idle frame storage unit; The frame handle of the idle frame storage unit with the frame baseband data attribute information and actual information written therein is stored in the in-use frame memory queue.

5. The method according to claim 4, characterized in that The process of the receiving encoding side feeding back the reception success information and exchanging the frame handle of the idle frame storage unit between two frame index queues after the idle frame storage unit is read and used includes: The receiving encoding side feeds back information about the frame baseband data that has been read and used; The frame handle of the idle frame storage unit that has been used up is taken out from the in-use frame memory queue and put back into the idle frame memory queue.

6. The method according to claim 5, characterized in that The method further comprises: Establishing a frame storage unit record table, wherein the frame storage unit record table records the number of times each frame storage unit is read; When a frame handle of an idle frame storage unit is sent to the encoding side once, the number of times the idle frame storage unit is read is increased by one in the frame storage unit record table. When the completion of using the frame baseband data information fed back by the encoding side is received, the number of times the idle frame storage unit is read is reduced by one in the frame storage unit record table until the number of times the idle frame storage unit is read is zero, and the frame handle of the idle frame storage unit is put back into the idle frame memory queue.

7. The method according to claim 6, characterized in that The method further comprises: Periodically check whether the frame handle transmission process of the frame baseband data in the frame memory queue in use has been cleared; If the transmission process has been cleared, the number of times the frame storage unit corresponding to the transmission process has been read is reduced by one in the frame storage unit record table, and the process record is cleared.

8. The method according to claim 1, characterized in that The method further comprises: When no feedback information is received from the encoding side within the predetermined time, a heartbeat protocol is sent to the encoding side through the message queue; If no feedback information sent by the encoding side in response to the heartbeat protocol is received, the frame handle of the frame storage unit is put back into the idle frame index queue.

9. A baseband IP video data transmission method, characterized in that: The method is applied to the encoding side, and the method includes: Initialize the encoding process and establish a message queue; Sending a registration request to the proxy side, so that the proxy side establishes a shared memory pool according to the registration request and establishes a transmission connection with the proxy side; Obtaining a frame handle of an idle frame storage unit sent by the proxy side, and reading and processing frame baseband data stored in the idle frame storage unit in a shared memory pool according to the frame handle of the idle frame storage unit, wherein the shared memory pool includes multiple frame storage units, the idle frame storage unit is any one of the multiple frame storage units, and the frame handle includes an ID of the frame storage unit and an offset of the frame storage unit in the shared memory pool; Feedback information to the proxy side so that the proxy side recycles the frame handle of the idle frame storage unit; The process of sending a registration request to the proxy side so that the proxy side establishes a shared memory pool according to the registration request and establishes a transmission connection with the proxy side includes: Sending a registration request to the named message queue through the encoding side message queue, wherein the registration request includes the URL address information of the multicast on the network card, so that the proxy side establishes a shared memory pool for storing the multicast data and establishes a multicast request message queue between the encoding side and the proxy side according to the registration request; Acquire the descriptor of the multicast request message queue and the descriptor of the shared memory pool, and obtain access rights to the shared memory pool according to the descriptor of the multicast request message queue and the descriptor of the shared memory pool; Establishing a multicast receiving message queue and monitoring the multicast receiving message queue; A data request is sent to the multicast request message queue of the proxy side, wherein the data request includes a descriptor of the multicast receiving message queue, so that the proxy side establishes a transmission connection with the encoding side according to the descriptor of the multicast receiving message queue.

10. The method according to claim 9, characterized in that The encoding process is initialized and the process of establishing a message queue includes: Enter the network card configuration; Create a message queue on the encoding side using the network card name as the global descriptor.

11. A baseband IP video data transmission system, characterized in that: The system includes an agent side and an encoding side; The proxy side includes a processor and a memory, wherein one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the processor, the processor executes the method according to any one of claims 1 to 8; The encoding side includes a processor and a memory, wherein one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the processor, the processor executes the method as described in any one of claims 9 to 10.

Images