Apparatus and Method for Low-Latency Transmission and Reception of GVA Uncompressed Video Standard using Channel Multiplexing
Patent Information
- Application Number
- KR1020250179383
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2025-11-24
- Publication Date
- 2026-09-16
- Estimated Expiration
- 2045-11-24
Smart Images

Figure 112025131603601-PAT00001_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to a Generic Vehicle Architecture (GVA) system, and more specifically, to an apparatus and method for splitting the packet overload of video data by multiplexing video data transmitted through RFC-4175, an uncompressed video standard of GVA, into multiple channels instead of a single channel. Background Technology
[0003] Recently, there has been an increasing number of cases both domestically and internationally applying GVA systems in the development of ground combat systems to standardize hardware and software interfaces and protocols, aiming to improve compatibility between components within combat vehicles, reduce replacement costs, and simplify development and maintenance.
[0004] GVA refers to an open, modular, and scalable architectural standard approach established by the UK Ministry of Defence (UK MOD) for the installation and integration of electronic, electrical, and mechanical subsystems of military ground platforms (vehicles, etc.).
[0005] In the case of video transmission standards in the GVA system, video data must be distributed using the protocol specified in VIVOE (Vetronics Infrastructure for Video Over Ethernet) of DEF-STAN 00-082 based on the British GVA standard, and for uncompressed video, RFT-4175, the uncompressed video standard of RTP (Real-time Transport Protocol), is specified.
[0006] The RFT-4175 video standard transmits one or more lines of video data output from a camera sensor as the RTP payload. By transmitting the camera video data line by line without compression, it is an Ethernet video streaming standard optimized for low-latency video transmission and reception.
[0007] Furthermore, VIVOE specifies that a Session Announce Protocol (SAP), containing streaming channel information along with the transmission of video data, must be distributed at regular intervals.
[0008] The GVA's DEF-STAN 00-082 specification sets the Maximum Transmission Unit (MTU) to 1500 bytes and prohibits the use of jumbo packets (e.g., 9000 bytes). Therefore, if video is transmitted via the uncompressed video standard RFC-4175, for High Definition (HD) video with RGB or YUV422 color formats, a single line cannot be transmitted in one packet due to the MTU size, and at least two packets must be sent for each line. Consequently, there is a problem in that the number of transmitted packets becomes significantly large.
[0009] If the performance of the CPU (Central Processing Unit) and NIC (Network Interface Card) of the video receiving unit that needs to receive video is insufficient, video reception will be abnormal and video delay will occur. Prior art literature
[0011] U.S. Patent Publication No. 2019-0056735 (Published Feb. 21, 2019) Republic of Korea Patent Publication No. 2011-0132609 (Published Dec. 8, 2011) The problem to be solved
[0012] The present invention aims to provide an apparatus and method for dividing the packet overload of image data by multiplexing image data transmitted via RFC-4175, an uncompressed image standard of GVA, into multiple channels rather than a single channel in the implementation of image software in a ground combat system.
[0013] The present invention aims to provide an apparatus and method for transmitting and receiving a single image data through channel multiplexing for low-latency transmission and reception of the image data, while applying the uncompressed image transmission standard described in the GVA specifications.
[0014] The present invention aims to provide an apparatus and method for transmitting and receiving one video data by dividing it into two or more RTP streaming channels for low-latency video transmission and reception using RFC-4175, an uncompressed video transmission standard of GVA. means of solving the problem
[0016] A channel multiplexing device according to an embodiment of the present invention comprises: a transmitter that maps streaming channels to IP (Internet Protocol) addresses assigned to a plurality of first NICs (Network Interface Cards) to configure multiple streaming channels and transmits a Session Announcement Protocol (SAP) packet having video data input from a camera sensor and streaming channel information of the video data to the multiple streaming channels; a receiver that generates a plurality of receiving interfaces corresponding to the number of streaming channels obtained through the SAP packet and connects each streaming channel to an IP address assigned to a plurality of second NICs to receive video data through the multiple streaming channels; and an Ethernet switch connected to the first and second NICs between the transmitter and the receiver, which manages packet distribution and traffic within the network when transmitting video data transmitted from the transmitter to the receiver.
[0017] The above transmitter inserts RTP (Real-time Transport Protocol) header data into the video data input from the camera sensor and transmits it over multiple streaming channels.
[0018] The header data of the above RTP includes line metadata of the image data, including the length (Length), horizontal axis position (Offset), and vertical axis position (Line No.) of the image data.
[0019] The above-mentioned transmitter includes a plurality of transmission interfaces for multi-streaming video data; and a distribution unit that transmits an SAP packet having video streaming channel information according to the SAP standard to the receiver.
[0020] The above-mentioned transmission interface is configured to multi-stream video data according to the RFC-4175 transmission standard and is characterized by being a first UDP (User Datagram Protocol) socket.
[0021] If there are two or more of the above first NICs, multiple streaming channels are configured by connecting the IP address assigned to each first NIC to the transmission interface.
[0022] The above distribution unit distributes an SAP packet to the above receiving unit that indicates information that multiple streaming channels are a single video data.
[0023] The above distribution unit is characterized by inserting a name for each of the multiple streaming channels into the Session Description Protocol (SDP) of the SAP packet to indicate that the multiple streaming channels constitute a single video data.
[0024] The above distribution unit is characterized by inserting a combination of the same symbol and the ID of the multiple streaming channel declared by the above transmission unit after the name representing the name of the video streaming channel among the data of the SDP.
[0025] The receiver above creates a thread for each of the streaming channels and assigns a specific CPU core to each thread.
[0026] The receiving unit includes a plurality of receiving interfaces that receive video data from each streaming channel generated according to the number of streaming channels obtained through the SAP packet; and a synthesis unit that reconstructs the video data into a single frame data using line metadata of the video data obtained per channel from each streaming channel.
[0027] The above receiving interface is characterized by being a second UDP socket for receiving video.
[0028] The above synthesis unit further utilizes the metadata of the unique IDs assigned to each of the multiple streaming channels to reconstruct the corresponding video data into a single frame data.
[0029] The synthesis unit includes: a channel-specific copy frame buffer that temporarily stores video data received from each streaming channel in the correct location based on RTP headers and line metadata; and an integration frame buffer that synthesizes the data of the channel-specific copy buffer into a single final frame.
[0030] The above line metadata includes the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the image data.
[0031] The above-mentioned per-channel copy frame buffer and aggregation frame buffer are shared by multiple threads for multiple streaming channels.
[0032] A channel multiplexing method according to an embodiment of the present invention comprises: (A) a process in which, if there are two or more first NICs (Network Interface Cards), a streaming channel is mapped to an IP (Internet Protocol) address assigned to each first NIC to form multiple streaming channels, and a process in which an SAP packet having video data input from a camera sensor and streaming channel information of said video data is transmitted; and (B) a process in which, in a receiving unit, a plurality of receiving interfaces are created corresponding to the number of streaming channels obtained through the SAP (Session Announcement Protocol) packet, and each streaming channel is connected to an IP address assigned to a plurality of second NICs to receive video data through multiple streaming channels.
[0033] The above SAP packet includes streaming channel information indicating that multiple streaming channels constitute a single video data according to the SAP standard.
[0034] The above SAP packet inserts the same symbol and the ID of the multiple streaming channels declared by the transmitting unit after the name of the video streaming channel in the SDP (Session Description Protocol) data.
[0035] The above process (B) reconstructs the video data received through the multiple streaming channels into a single frame data by synthesizing it using the line metadata of the video within the RTP data obtained channel by channel from each streaming channel.
[0036] The above process (A) includes: a process of creating multiple transmission interfaces for multi-streaming the video data to a receiver; a process of configuring multiple streaming channels by mapping the IP address assigned to each of the first NICs to the transmission interfaces if there are two or more first NICs; a process of assigning a unique ID to each of the multiple streaming channels; a process of creating an SAP header having structural metadata in the SAP packet according to the SAP standard; a process of inserting a name into the SDP of the SAP packet for each of the multiple streaming channels; a process of transmitting the SAP packet to a receiver through the multiple streaming channels; a process of mapping the video data to an RTP (Real-time Transport Protocol) payload and creating an RTP header corresponding to the line data when video data is input from a camera sensor; a process of creating an RTP packet by inserting the video data into the RTP payload; and a process of transmitting the RTP packet to a receiver through the multiple streaming channels.
[0037] The above structural metadata includes the number of channels, each channel ID, the IP / port number of each channel, video resolution, line splitting method, codec information, and session information indicating that multiple streaming channels are "one video data."
[0038] The process of inserting a name within the above SDP is characterized by combining the same symbol and the ID of a multiple streaming channel declared by the transmitting unit and inserting it after the name representing the name of a video streaming channel among the data of the above SDP.
[0039] The above RTP header includes line metadata of the image data, including the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo).
[0040] The above process (B) includes: a process of obtaining the number of streaming channels through the SAP packet; a process of creating multiple receiving interfaces for receiving video data according to the number of streaming channels obtained; a process of configuring multiple streaming channels by connecting the IP address assigned to each second NIC to the receiving interface if there are two or more second NICs of the receiving unit; a process of analyzing the header data of the RTP from the video data obtained from each streaming channel when an RTP packet is received through the multiple streaming channels, and synthesizing the video data through the line metadata of the video data within the RTP data; and a process of reconstructing the synthesized video data into a single frame data.
[0041] A thread is created for each of the above streaming channels, and a specific CPU core is assigned to each thread.
[0042] The above line metadata includes the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the image data.
[0043] The process of synthesizing video data using line metadata of video data within the RTP data includes: a process of analyzing RTP header data from video data acquired from each streaming channel and copying the video data acquired through line metadata of video data within the RTP data to a specific location within a channel-specific copy frame buffer; and a process of synthesizing the video data copied within the channel-specific copy frame buffer in an integration frame buffer.
[0044] The process of reconstructing into a single frame data includes: a process of considering a frame as complete if the Maker bit of a single frame becomes 1 in all streaming channels; and a process of converting the channel-specific copy frame buffer to be used as a channel-specific copy frame buffer for video output, and converting the channel-specific copy frame buffer to be used as a channel-specific copy frame buffer for temporary storage of video. Effects of the invention
[0046] According to an embodiment of the present invention, the low-latency video reception phenomenon caused by an excessive number of packets in the CPU and NIC during video transmission and reception of the uncompressed video transmission standard of GVA can be resolved through load splitting of the NIC and efficient scheduling of the CPU.
[0047] That is, by splitting a single video data into two or more RTP streaming channels for low-latency video transmission and reception using RFC-4175, the uncompressed video transmission standard of GVA, the load on the NICs can be reduced by using multiple NICs (Network Interface Cards) in the video transmission and reception unit, thereby enabling low-latency video acquisition. Alternatively, in the case of delays caused by CPU performance, low-latency video transmission and reception can be provided through multi-core processing by receiving video data transmitted through multiple channels using different CPU cores. Brief explanation of the drawing
[0049] FIG. 1 is a diagram showing the configuration of a channel multiplexing device for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention. FIG. 2 is a diagram illustrating a channel multiplexing method for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention. FIG. 3 is a diagram for explaining in detail the channel multiplexing method of the transmitter in FIG. 2. FIG. 4 is a diagram for explaining in detail the channel multiplexing method of the receiver in FIG. 2. Specific details for implementing the invention
[0050] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings. However, the present invention is not limited to the embodiments disclosed below but may be implemented in various different forms, and the embodiments of the present invention are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention. To explain the invention in detail, the drawings may be exaggerated, and like reference numerals in the drawings refer to like elements.
[0051] FIG. 1 is a diagram showing the configuration of a channel multiplexing device for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention.
[0052] Referring to FIG. 1, a channel multiplexing device for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention comprises: a transmitting unit (200) that configures multiple streaming channels by mapping streaming channels to IP addresses assigned to a plurality of first NICs (230) and transmits video data (video line data) input from a camera sensor (100) and SAP packets having streaming channel information of said video data to the multiple streaming channels; a receiving unit (300) that creates a plurality of receiving interfaces (310) corresponding to the number of streaming channels obtained through a received SAP (Session Announcement Protocol) packet and receives video data through multiple streaming channels by connecting each streaming channel to an IP address assigned to a plurality of second NICs (330); and packet distribution and traffic within a network when transmitting video data transmitted from the transmitting unit (200) to the receiving unit (300) connected between the transmitting unit (200) and the receiving unit (300) via first and second NICs (Network Interface Cards) (230) (330). It includes an Ethernet switch (400) that manages.
[0053] At this time, the transmitting unit (200) inserts RTP header data into the video data input from the camera sensor (100) and transmits it to multiple streaming channels. The RTP header data includes line metadata of the video data, including the length (Length), horizontal axis position (Offset), and vertical axis position (Line No).
[0054] The transmitting unit (200) includes a plurality of transmitting interfaces (210) for multi-streaming video data according to the RFC-4175 transmission standard, and a distribution unit (220) that transmits SAP packets having video streaming channel information according to the SAP standard to the receiving unit (300).
[0055] The transmission interface (210) may be a first UDP (User Datagram Protocol) socket.
[0056] At this time, if there are two or more first NICs (230), multiple streaming channels are configured by connecting the IP address assigned to each first NIC (230) to the transmission interface (210). Each of the multiple streaming channels is assigned a unique identifier (Identity Document: ID). The unique ID assigned to each streaming channel is metadata for distinguishing each streaming channel and for correctly reconstructing video data distributed to each streaming channel into a single frame data at the receiver (300).
[0057] The above distribution unit (220) distributes an SAP packet to the receiving unit (300) that indicates information that multiple streaming channels are one video data. That is, the distribution unit (220) indicates that multiple streaming channels are one video data by inserting the name of each multiple streaming channel into the SDP (Payload) of the SAP packet.
[0058] To explain in more detail, the Session Description Protocol (SDP) specification, which is the payload of SAP, can assign a name to the streaming channel, and through this, multiple streaming channels can be indicated as a single video data. For example, to indicate that multiple streaming channels are a single video data, the distribution unit (220) inserts the same symbol (alphabet "S") and the ID of the multiple streaming channel declared by the transmission unit (200) after "name," which represents the name of the video streaming channel in the data of the SDP.
[0059] Additionally, the receiver (300) creates a thread for each streaming channel and assigns a specific core of the CPU to each thread. Due to this configuration, the streaming channels each have a thread and a core, and a receiving interface (310) for receiving video data.
[0060] The receiving unit (300) includes a plurality of receiving interfaces (310) that receive video data from each streaming channel generated according to the number of streaming channels obtained through the received SAP packets, and a synthesis unit (320) that reconstructs the video data into a single frame data using line metadata of the video data obtained per channel from each streaming channel. At this time, the synthesis unit (320) further reconstructs the video data into a single frame data by utilizing metadata of a unique ID assigned to each of the multiple streaming channels.
[0061] The receiving interface (310) may be a second UDP socket for receiving video, and the second UDP socket is created multiple times to receive multiple streaming of video data.
[0062] The above synthesis unit (320) has two frame buffers (not shown) for storing video data. That is, the synthesis unit (320) includes a frame buffer for channel-specific copying that temporarily stores video data received from each streaming channel in the correct location based on RTP header and line meta information, and a frame buffer for integration that synthesizes the data from the channel-specific copying buffer into one to form a final single frame. At this time, the line meta information includes the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the video data.
[0063] As such, the per-channel copy frame buffer is a buffer that stores video data, and the aggregation frame buffer is a buffer for outputting a completed final single frame by synthesizing the data from the copy buffers into one.
[0064] Meanwhile, the frame buffer for copying per channel and the frame buffer for consolidation are shared by multiple threads for multiple streaming channels.
[0065] The Ethernet switch (400) performs functions such as multi-streaming control of video data, packet distribution, and bandwidth management. That is, the Ethernet switch (400) learns the MAC address table of the transmitter (200), transmits only the stream of video data requested by the receiver (300), and simultaneously maintains real-time transmission without packet loss.
[0067] Hereinafter, a channel multiplexing method for low-latency transmission and reception of the GVA uncompressed video standard according to an embodiment of the present invention will be described. The channel multiplexing method for low-latency transmission and reception of the GVA uncompressed video standard according to an embodiment of the present invention may be a method for processing a received signal using the aforementioned channel multiplexing device for low-latency transmission and reception of the GVA uncompressed video standard. Since the aforementioned details regarding the channel multiplexing device for low-latency transmission and reception of the GVA uncompressed video standard can be applied as is, the description of redundant details may be omitted.
[0068] FIG. 2 is a diagram illustrating a channel multiplexing method for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention.
[0069] Referring to FIG. 2, a channel multiplexing method for low-latency transmission and reception of a GVA uncompressed video standard according to an embodiment of the present invention first, at a transmitting unit (200), if there are two or more first NICs (230), a streaming channel is mapped to an IP address assigned to each first NIC (230) to configure multiple streaming channels, and a SAP packet having video data (video line data) input from a camera sensor (100) and streaming channel information of the video data is transmitted (S100).
[0070] At this time, the SAP packet includes streaming channel information indicating that multiple streaming channels constitute a single video data according to the SAP standard. In the SDP standard, which is the payload of the SAP, a name can be assigned to the streaming channel, and through this, the multiple streaming channels indicate that they are a single video data. For example, in the data of the SDP, the same symbol (alphabet "S") and the ID of the multiple streaming channel declared in the transmitting unit (200) are combined and inserted into the value of "name" which represents the name of the video streaming channel.
[0071] The channel multiplexing method of the transmitter described in S100 above will be explained in detail below with reference to Fig. 3.
[0072] Next, in the receiving unit (300), a plurality of receiving interfaces (310) are created corresponding to the number of streaming channels obtained through the received SAP packet, and each streaming channel is connected to an IP address assigned to a plurality of second NICs (330) to receive video data through multiple streaming channels (S200).
[0073] At this time, video data received through multiple streaming channels is synthesized and reconstructed into a single frame data based on the line metadata of the video within the RTP data acquired per channel from each streaming channel and the metadata of the unique ID assigned to each of the multiple streaming channels.
[0075] Figure 3 is a diagram for explaining in detail the channel multiplexing method of the transmitter in Figure 2.
[0076] Referring to FIG. 3, in the case of the transmitting unit (200), first, multiple transmission interfaces (210) are created to multi-stream video data to the receiving unit (300) according to the RFC-4175 transmission standard (S101).
[0077] Next, if there are two or more first NICs (230) of the transmitting unit (200) (S102), the IP address assigned to each first NIC (230) is mapped to the transmitting interface (210) to configure multiple streaming channels (S103).
[0078] Then, a unique identifier (Identity Document: ID) is assigned to each of the multiple streaming channels (S104). At this time, the unique ID assigned to each streaming channel is metadata for distinguishing each streaming channel and for correctly reconstructing the video data distributed to each streaming channel into a single frame data at the receiving unit (300).
[0079] Next, an SAP header containing structural metadata is generated in the SAP packet according to the SAP standard (S150). At this time, the structural metadata includes the number of channels, each channel ID, the IP / port number of each channel, the resolution of the video, the line splitting method, codec information, and session information that multiple streaming channels are "one video data".
[0080] Then, names are inserted into the SDP (Payload) of the SAP packet for each multi-streaming channel (S106).
[0081] That is, the SAP packet can assign a name to the streaming channel in the Session Description Protocol (SDP) specification, which is the payload of the SAP, and through this, multiple streaming channels can indicate that they are a single video data. For example, to indicate that the name of the streaming channel is a single video data, the same symbol (alphabet "S") and the ID of the multiple streaming channel declared in the transmitter (200) are combined and inserted after "name," which represents the name of the video streaming channel in the data of the SDP.
[0082] Then, the SAP packet is transmitted to the receiver (300) through the multi-streaming channel (S107).
[0083] Subsequently, when image data (image line data) is input from one camera sensor (100) (S108), the image data is mapped to an RTP payload, and an RTP header corresponding to the line data is generated according to the RFC-4175 transmission standard (S109). At this time, the RTP header includes line metadata information of the image data, including the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the image data.
[0084] Then, video data (video line data) is inserted into the RTP payload to generate an RTP packet (S110).
[0085] Next, an RTP packet is transmitted to the receiver (300) through the multi-streaming channel (S111).
[0087] Figure 4 is a diagram for explaining in detail the channel multiplexing method of the receiver in Figure 2.
[0088] Referring to FIG. 4, in the case of the receiver (300), when an SAP packet containing video channel information is received from the transmitter (200) (S201), the number of streaming channels is obtained through the SAP packet (S202).
[0089] Then, multiple receiving interfaces (310) for receiving video data are created according to the number of acquired streaming channels (S203). At this time, the receiving unit (300) creates a thread for each streaming channel and assigns a specific core of the CPU to each thread. Due to this configuration, the streaming channels each have a thread, a core, and a receiving interface (310) for receiving video data.
[0090] Next, if there are two or more second NICs (330) of the receiver (300) (S204), the IP address assigned to each second NIC (330) is connected to the receiving interface (310) (S205) to configure multiple streaming channels (S206).
[0091] Subsequently, when an RTP packet is received through multiple streaming channels (S207), the header data of the RTP is analyzed from the video data obtained from each streaming channel, and the corresponding video data is synthesized using the line metadata of the video data within the RTP data (S208). At this time, the line metadata includes the length, horizontal axis position (Offset), and vertical axis position (LineNo) of the video data.
[0092] To explain in more detail, two frame buffers are configured to reconstruct into a single frame data. First, the RTP header data is analyzed from the video data acquired from each streaming channel, and the video data obtained through the line metadata of the video data within the RTP data is copied to a specific location within one frame buffer (a frame buffer for copying per channel). Then, the video data copied into the frame buffer for copying per channel is combined in another frame buffer for integration.
[0093] Then, the synthesized video data is reconstructed into a single frame data (S209).
[0094] For example, if the Maker bit of a frame becomes 1 in all streaming channels, that frame is considered complete. Then, the per-channel copy frame buffer is converted to be used as a per-channel copy frame buffer for video output, and the per-channel copy frame buffer is converted to be used as a per-channel copy frame buffer for temporary video storage.
[0096] In the foregoing, preferred embodiments of the present invention have been described and illustrated using specific terms, but such terms are intended solely to clarify the present invention, and it is obvious that various modifications and changes may be made to the embodiments and described terms of the present invention without departing from the technical spirit and scope of the following claims. Such modified embodiments should not be understood separately from the spirit and scope of the present invention, but should be considered to fall within the scope of the claims of the present invention. Explanation of the symbols
[0098] 100: Camera sensor 200: Transmitter 210: Transmission interface 220: Distribution unit 230: 1st NIC 300: Receiver 310: Receiving interface 320: Synthesis unit 330: 2nd NIC 400: Ethernet Switch
Claims
Claim 1 A transmitting unit that configures multiple streaming channels by mapping streaming channels to IP (Internet Protocol) addresses assigned to multiple first NICs (Network Interface Cards) and transmits a Session Announcement Protocol (SAP) packet having video data input from a camera sensor and streaming channel information of the video data to the multiple streaming channels; and a receiving unit that generates multiple receiving interfaces corresponding to the number of streaming channels obtained through the SAP packets and receives video data through the multiple streaming channels by connecting each streaming channel to an IP address assigned to multiple second NICs. A channel multiplexing device comprising: an Ethernet switch connected between the transmitting unit and the receiving unit via the first and second NICs to manage packet distribution and traffic within the network when transmitting video data transmitted from the transmitting unit to the receiving unit; wherein the receiving unit comprises a plurality of receiving interfaces that receive video data from each streaming channel generated according to the number of streaming channels obtained through the SAP packet; and a synthesis unit that reconstructs the corresponding video data into a single frame data through line metadata information of the video data obtained per channel from each streaming channel; wherein the synthesis unit comprises a channel-specific copy frame buffer that temporarily stores the video data received from each streaming channel in the correct location based on the RTP header and line metadata information; and an integration frame buffer that synthesizes the data of the channel-specific copy buffer into one to form a final single frame; and wherein, when the Maker bit of a frame in all streaming channels becomes 1, the buffer used as the channel-specific copy frame buffer is switched to the integration frame buffer to output the video, and the buffer used as the integration frame buffer is switched to the channel-specific copy frame buffer to temporarily store the video. Claim 2 In claim 1, the transmitting unit is a channel multiplexing device that inserts Real-time Transport Protocol (RTP) header data into image data input from the camera sensor and transmits it to multiple streaming channels. Claim 3 In claim 2, the RTP header data comprises line meta information of the image data including the length (Length), horizontal axis position (Offset), and vertical axis position (Line No.) of the image data, in a channel multiplexing device. Claim 4 A channel multiplexing device according to claim 1, wherein the transmitting unit comprises a plurality of transmitting interfaces for multiple streaming of video data; and a distribution unit that transmits SAP packets having streaming channel information of video according to SAP standards to the receiving unit. Claim 5 A channel multiplexing device according to claim 4, wherein the transmission interface is configured to multi-stream video data according to the RFC-4175 transmission standard and is characterized as being a first UDP (User Datagram Protocol) socket. Claim 6 In claim 5, if there are two or more first NICs, a channel multiplexing device that configures multiple streaming channels by connecting the IP address assigned to each first NIC to a transmission interface. Claim 7 In claim 4, the distribution unit is a channel multiplexing device that distributes an SAP packet indicating information that multiple streaming channels are one video data to the receiving unit. Claim 8 A channel multiplexing device according to claim 7, wherein the distribution unit inserts a name for each of the multiple streaming channels into the Session Description Protocol (SDP) of the SAP packet to indicate that the multiple streaming channels are a single video data. Claim 9 In claim 8, the channel multiplexing device is characterized in that the distribution unit inserts a combination of the same symbol and the ID of the multiple streaming channel declared by the transmission unit after a name representing the name of a video streaming channel among the data of the SDP. Claim 10 In claim 1, the receiving unit is a channel multiplexing device that creates a thread for each streaming channel and assigns a specific core of the CPU to each thread. Claim 11 delete Claim 12 A channel multiplexing device according to claim 1, characterized in that the receiving interface is a second UDP socket for receiving video. Claim 13 In claim 1, the synthesis unit is a channel multiplexing device that reconstructs the corresponding video data into a single frame data by further utilizing meta information of a unique ID assigned to each of the multiple streaming channels. Claim 14 delete Claim 15 In claim 1, the line meta information is a channel multiplexing device including the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the image data. Claim 16 Multiplexing Claim 17 (A) In a transmitting unit, if there are two or more first NICs (Network Interface Cards), a multi-streaming channel is configured by mapping streaming channels to IP (Internet Protocol) addresses assigned to each first NIC, and a Session Announcement Protocol (SAP) packet having video data input from a camera sensor and streaming channel information of the video data is transmitted;and (B) a process of receiving video data through multiple streaming channels by creating multiple receiving interfaces corresponding to the number of streaming channels obtained through the SAP packet at the receiving unit, and connecting each streaming channel to an IP address assigned to a plurality of second NICs, wherein the process (B) includes: a process of obtaining the number of streaming channels through the SAP packet; a process of creating multiple receiving interfaces for receiving video data according to the number of streaming channels obtained; if there are two or more second NICs at the receiving unit, a process of configuring multiple streaming channels by connecting an IP address assigned to each second NIC to a receiving interface; when an RTP packet is received through the multiple streaming channels, a process of analyzing the header data of the RTP from the video data obtained from each streaming channel and synthesizing the video data using the line metadata information of the video data within the RTP data; and a process of reconstructing the synthesized video data into a single frame data. The process of synthesizing the video data using the line metadata information of the video data within the RTP data includes analyzing the header data of the RTP from the video data obtained from each streaming channel and using the video data obtained through the line metadata information of the video data within the RTP data for channel-specific copying A channel multiplexing method comprising a process of copying to a specific location within a frame buffer, and a process of synthesizing video data copied into the channel-specific copy frame buffer in an integration frame buffer, wherein the process of reconstructing into a single frame data includes, when the Maker bit of a single frame in all streaming channels becomes 1, switching the buffer used as the channel-specific copy frame buffer to the integration frame buffer to output video, and switching the buffer used as the integration frame buffer to the channel-specific copy frame buffer to temporarily store video. Claim 18 In claim 17, the SAP packet is a channel multiplexing method comprising streaming channel information indicating that multiple streaming channels constitute one video data according to the SAP standard. Claim 19 In claim 18, the SAP packet is a channel multiplexing method that inserts the same symbol and the ID of multiple streaming channels declared by the transmitting unit after the name of a video streaming channel among the data of the Session Description Protocol (SDP). Claim 20 In claim 17, the above process (B) is a channel multiplexing method in which video data received by the multiple streaming channels is synthesized using line meta information of the video within the RTP data obtained channel by channel in each streaming channel and reconstructed into one frame data. Claim 21 In claim 17, the above process (A) comprises: a process of creating multiple transmission interfaces for multiple streaming of the video data to a receiver; a process of configuring multiple streaming channels by mapping the IP address assigned to each first NIC to the transmission interface if there are two or more first NICs; a process of assigning a unique ID to each of the multiple streaming channels; a process of creating an SAP header having structural metadata in an SAP packet according to the SAP standard; a process of inserting a name into the SDP of the SAP packet for each of the multiple streaming channels; a process of transmitting the SAP packet to a receiver through the multiple streaming channels; a process of mapping the video data to an RTP (Real-time Transport Protocol) payload and creating an RTP header corresponding to the line data when video data is input from a camera sensor; a process of creating an RTP packet by inserting the video data into the RTP payload; and a process of transmitting the RTP packet to a receiver through the multiple streaming channels. Claim 22 In claim 21, the structural metadata includes the number of channels, each channel ID, the IP / port number of each channel, the resolution of the video, the line splitting method, the codec information, and session information that multiple streaming channels are "one video data". Claim 23 A channel multiplexing method according to claim 21, wherein the process of inserting a name within the SDP is characterized by combining the same symbol and the ID of a multiple streaming channel declared in the transmitting unit and inserting it after a name representing the name of a video streaming channel among the data of the SDP. Claim 24 In claim 21, the channel multiplexing method wherein the RTP header includes line meta information of image data including the length (Length), horizontal axis position (Offset), and vertical axis position (LineNo) of the image data. Claim 25 delete Claim 26 In claim 17, a channel multiplexing method that creates a thread for each of the streaming channels and assigns a specific core of the CPU to each thread. Claim 27 In claim 17, the line meta information comprises a length (Length), a horizontal axis position (Offset), and a vertical axis position (LineNo) of the image data, in a channel multiplexing method. Claim 28 delete Claim 29 In claim 17, the process of reconstructing into one frame data includes a channel multiplexing method in which, if the Maker bit of one frame becomes 1 in all streaming channels, the frame is considered complete.
Citation Information
Patent Citations
Generation device and method of software code for GVA Standard Video
KR102839433B1
Method, system and article for dynamic real-time stream aggregation in a network
US20080195701A1
