I did a time last year for a real-time video transmission on the LAN. If the server is a real-time video transmission for multiple users, in my experience: 1. Server software multi-thread: (1) Main thread: read (see you) How is the image of a PC?) A frame of video data is given to the split thread. (2) Split the thread: Receive a frame of video, start unpacking, perform a frame mark, serial number, and send it to the sending thread. (3) Send a thread: Use the RTP Socket to send the packaged data to the client. This Socket is a point-to-multipoint, one-way, a multicast socket, which is actually based on UDP derived, but he uses RTP and RTCP (real-time transfer protocols and real-time transfer control protocols) if you transfer Not real-time data, just use UDP.
2. The client software structure is typically synchronized with multiple threads and threaded event objects, and the shared data area is synchronized with a critical area object. (1) Main thread: Receive the thread of the network packet, the highest priority, can be guaranteed to ensure that the data is not lost, and the RTP protocol is also triggered with network events. After receiving the video packet, the primary thread receives the data packet into a list and then triggered the assembly thread with the event object. (2) Assembly thread: Read the packet from the list, to perform frame confirmation, sorting, etc., when all packages of one frame image are taken, then call the assembly module (can be a function), will The packet group is loaded into a complete frame and then sent to the decompression thread. (3) Several decompression play threads. Mainly considering that if your client software wants to play multi-screen, such as 4 screen images, you have to use 4 decompressed play threads. (4) As for image storage, how do you need to do your customers, if you don't need to separate threads, if you are specifying or automatically in an event, you need to separate a thread. The message is triggered by the timer to the message or this event.
