Abstract: This paper introduces a network monitoring system based on embedded Linux video, employing a Browser/Server architecture and integrating an embedded Web server within the video server. The design of the server side is emphasized. Keywords: Embedded Linux, Web server, MPEG-4, Network communication. With the rapid development of computer and network technologies, the public security and security industries are inevitably trending towards full digitalization and networking. Traditional analog closed-circuit television (CCTV) monitoring systems have many limitations: limited transmission distance, inability to network, and the storage of analog video signal data consumes a large amount of storage media (such as videotapes), making retrieval and evidence collection cumbersome. Personal computer-based video monitoring systems have powerful terminal functions but poor stability; the video front-end (such as the acquisition, compression, and communication of video signals through voltage coupling elements) is complex and unreliable. The network monitoring system based on embedded Linux video does not require a personal computer for processing analog video signals; instead, it integrates an embedded Web server within the video server and employs an embedded real-time multitasking operating system. Because video compression and web functionality are integrated into a small device, it can be directly connected to a local area network (LAN) for plug-and-play viewing, eliminating the need for complex cables and simplifying installation (requiring only IP address configuration). Users do not need to install any hardware; they can view the video using only a browser. The embedded Linux-based video network monitoring system connects the embedded Linux system to the web; that is, the video server has a built-in embedded web server. The video signals transmitted from the cameras are digitized, compressed by a high-efficiency compression chip, and transmitted to the built-in web server via an internal bus. 1 System Overall Framework The embedded Linux video network monitoring system is an organic combination of electrical and electronic devices, computer hardware and software, and network and communication technologies. It is characterized by intelligence, networking, and interactivity, and its structure is relatively complex. By utilizing the content and form of the OSI seven-layer model and organically combining the corresponding data acquisition and control module hardware, application software, and application environment, a unified system overall framework can be formed. The schematic diagram of the system overall framework is shown in Figure 1. After the video signal from the camera is digitized and compressed, it is sent to the built-in Web server via RS-232/RS485. The 10/100M Ethernet port of the embedded Linux system enables access to the Internet, sending the field signals to the client. The core of the entire system is the embedded Linux system. After the monitoring system starts, the embedded Linux system starts the Web Server service program, receives requests from authorized client browsers, and the Web Server completes the corresponding monitoring according to the communication protocol. 2 System Implementation 2.1 Hardware Platform Design This system is based on publicly available embedded Linux source code. A corresponding Bootloader program is written according to the designed embedded target board, and then a suitable kernel and file system are tailored. The target platform CPU uses the ColdFire embedded processor MFC5272 produced by Motorola. The MFC5272 uses the ColdFire V2 variable RISC processor core and Digital IDNA technology, achieving a good processing power of 63Dlnrystone 2.1MIPS at a clock speed of 66MHz. The internal SIM (System Integrated Module) unit integrates a wealth of general-purpose modules, requiring only a few external chips to implement two RS-232 serial ports and one USB Slave interface. The MFC5272 also embeds an FEC (Fast Ethernet Controller), and an external LXT971 can be used to easily implement a 100/10 BaseT Ethernet interface. It can seamlessly connect with common peripheral devices (such as SDRAM and ISDN transceivers), simplifying peripheral circuit design and reducing product cost, size, and power consumption. 2.2 Software Design and Implementation The video surveillance system software architecture adopts a browser-server (B/S) network model. The client sends requests to the server via the Web, the server responds with confirmation and executes corresponding tasks (such as sending multicast addresses, image formats, compression formats, etc. to the client), and after establishing a connection, the client can monitor the controlled point, thus achieving remote network monitoring. The software structure of the server (Web Server) side, i.e., the on-site monitoring point, includes acquisition modules, compression encoding modules, network communication modules, and control modules, as shown in Figure 2. 2.2.1 Video Acquisition Module Design Since the camera obtains analog video signals, which cannot be directly used by a computer, the video must first be digitized before it can be transmitted over the network. This system uses the Conexant Bt848 video acquisition card. This card does not require any local buffer to store video pixel data, fully utilizes the high bandwidth and inherent multimedia functions of the PCI bus system, and can interoperate with other multimedia devices. In the entire system, since the speed of video acquisition is usually higher than the speed at which application software acquires and processes data, a three-buffer structure is adopted to ensure the continuity of video data. Buffer A is the target address for Bt848 video acquisition. Under the direct control of RISC instructions, the acquired data is first stored in buffer A. Buffers B and C form a ping-pong structure that is used repeatedly. When a frame of data is acquired, an interrupt is generated. In the interrupt service routine, the data in buffer A is copied to buffer B (or C), and then the next frame is acquired. After the next frame of data is acquired, the data in buffer A is copied to buffer C (or B). When the application needs data, it reads the latest frame image from buffer B or C. Alternating between caches B and C ensures that operations reading data from the cache by the application and writing data to the cache by the driver do not conflict, avoiding data corruption and delays. 2.2.2 Video Compression Coding Design This design uses object-based MPEG-4 video coding technology. First, the input VOP sequence of arbitrary shapes is encoded using block-based hybrid coding technology. The processing order is intra-frame VOPs, then inter-frame VOPs and bidirectional prediction VOPs. After encoding the shape information of the VOPs, samples of VOPs of arbitrary shapes are obtained. Each VOP is divided into disjoint macroblocks using a macroblock raster. Each macroblock contains four 8×8 pixel blocks for motion estimation and compensation, and texture coding. Encoded VOP frames are stored in the VOP frame memory. Motion vectors are calculated between the current VOP frame and the encoded VOP frames. For the block or macroblock to be encoded, its motion compensation prediction error is calculated. The motion-compensated predicted I-VOPs and errors are encoded using 8×8 block DCT, and the DCP coefficients are quantized, followed by run-length coding and entropy coding. Finally… Shape, motion, and texture information are combined into a VOL bitstream output. This encoding method allows users to modify, add, or reposition objects in a video scene, and even transform the behavior of objects in the scene. For different bandwidth and computational complexity requirements, it is not necessary to encode separately for each case; the same video bitstream can be used, with different numbers selected to choose different layers for flexibility. It can still provide relatively coherent video images even in the event of network congestion or packet loss. The video compression encoding process stores the encoded video in the encoded video buffer queue, while simultaneously activating or waiting for the corresponding processing of the live streaming process and storage management process. 2.2.3 Network Communication Module Design The network communication module is the main part of the system, containing three data channels: a listening channel, a control channel, and a video data channel. The listening channel is used to transmit command data for controlling the front-end devices; the video data channel is used to transmit video data for each group. The three channels use different communication ports, so the data transmission of each channel is independent of each other. The network communication module design and development is implemented through a network programming interface (Windows Socket, or Winsoek for short). It follows the network transmission model of the system browser and server. On the server side, listening and control sockets of type SOCKET were established; on the client side, request and control sockets of type SOCKET were established. All of these use the UDP protocol to encapsulate and transmit data. Additionally, a multicast class (CMuhieast) is used on both the server and client sides. This class is specifically designed for video transmission and is derived from CObject. It defines SOCKET-type sockets for sending and receiving video data, as well as multicast sockets, thus enabling the transmission of UDP-encapsulated video data packets using multicast communication. The IP network data communication flow in the system is shown in Figure 3. The following is the program for establishing the listening and control sockets on the server side. ... int ret=0: BOOL bFlag=TRUE: // Set the socket to a reusable port address ret=setsoekopt(IInfo.listenSocket,SOL_SOCKET,SO_REUSE ADDR,(char)*&bFlag,sizeof(bFlag)); SOCKADDR_IN sockAddr; char*addr=severaddr.GetBuffer(0); // Define the address of the listening socket sockAddr.sin_family=AF_INET; sockAddr.sin_addr.S_un.S_addr =inet_addr(addr); sockAddr.sin_port=htons(PORT): if(bind(IInfo.listenSocket,(LPSOCKADDR) 2.2.4 The control module was designed and developed to enable users to control front-end devices such as lenses, pan-tilt units, and screen switching. After receiving control information frames from the customer center monitoring terminal, the server analyzes and processes them, then sends the data to the corresponding control component interfaces to achieve the desired control. 3. Experimental Results The web server of the video surveillance system was connected to the local area network (LAN) and then to the Internet, where an IP address was assigned. On the user terminal, since ordinary browsers can only display a single screen, which is inconvenient, a multi-screen browser software was created using Microsoft's VC6.0 and its browser controls, which only took a few minutes to complete. By directly entering the video server's address in the browser's address bar, a stable and smooth real-time image could be played on the browser page, achieving excellent monitoring results. The web server of the embedded Linux-based video network monitoring system connects directly to the network, eliminating limitations caused by cable length and signal attenuation. Furthermore, the network operates without geographical boundaries, completely overcoming geographical limitations and expanding the monitoring area. Because video compression and web functionality are integrated into a small device, it connects directly to a LAN or WAN, offering plug-and-play functionality. This significantly improves the system's real-time performance, stability, and reliability, requiring no dedicated personnel for management, making it ideal for unattended environments. With the rapid development of computer and network technologies, the demands on video surveillance systems will continue to increase. This system is believed to have broad application prospects in e-commerce, video conferencing, remote monitoring, distance learning, telemedicine, water conservancy, and power monitoring.